Subject: close of last call for 3280bis

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Nov 2006 16:32:00 -0500

We are long past the two-week WG last call time frame for 3280bis.

The list is essentially quiet re the document.

Hence I am declaring WG last call closed.

The authors should run I-D nits on the latest rev of this document in 
preparation for submissioon to the IESG.

Thanks,

Steve

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 8 Nov 2006 01:10:20 -0000

All of you that are listed to hold presentations during the PKIX
meeting:
http://www3.ietf.org/proceedings/06nov/agenda/pkix.txt

Please provide me with presentation material prior to the meeting so I
can post it on the materials page:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67

Thank you.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

---

From: Russ Housley <[email-masked]>
Date: Thu, 30 Nov 2006 13:23:38 -0500

I know that Steve Kent called the 3280bis closed on 11/7/2006, but 
the recent thread regarding on-hold needs to become a concrete 
proposal for a change in the text.  Here is my suggestion.

OLD TEXT:

    The following instruction codes have been defined.  Conforming
    applications that process this extension MUST recognize the following
    instruction codes.

    holdInstruction    OBJECT IDENTIFIER ::=
                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }

    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
    id-holdinstruction-callissuer
                              OBJECT IDENTIFIER ::= {holdInstruction 2}
    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

    Conforming applications that encounter an id-holdinstruction-
    callissuer MUST call the certificate issuer or reject the
    certificate.  Conforming applications that encounter an id-
    holdinstruction-reject MUST reject the certificate.  The hold
    instruction id-holdinstruction-none is semantically equivalent to the
    absence of a holdInstructionCode, and its use is strongly deprecated
    for the Internet PKI.

PROPOSED REPLACEMENT TEXT:

    The following instruction codes have been defined.  Conforming
    applications that process this extension MUST recognize the
    id-holdinstruction-reject instruction code.

    holdInstruction    OBJECT IDENTIFIER ::=
                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }

    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
    id-holdinstruction-callissuer
                              OBJECT IDENTIFIER ::= {holdInstruction 2}
    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

    Conforming CAs MUST NOT make use of the
    id-holdinstruction-callissuer instruction code.

    Conforming applications that encounter any of these hold instruction
    codes MUST reject the certificate.

    Communities may elect to use additional hold instruction codes;
    however, caution ought to be exercised in adopting any additional
    hold instruction codes that might prevent use in a general context.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 30 Nov 2006 10:42:25 -0800

No objections.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
Sent: Thursday, November 30, 2006 10:24 AM
To: [email-masked]
Subject: WG Last Call Comment for 3280bis

OLD TEXT:

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 30 Nov 2006 16:59:08 -0500

Russ,

I do not see how this proposed change relates to the recent discussions 
about certificate suspension.  I am also not in favor of the change that 
you have proposed.

Your proposal states that clients that process the holdInstruction entry 
extension must recognize the id-holdinstruction-reject instruction code, 
but then says that conforming applications must perform the same action 
(reject the certificate) whenever any of the three hold instruction 
codes are encountered.  So, what does it mean to recognize the 
id-holdinstruction-reject instruction code but not the other two 
instruction codes.

Since I don't have a copy of X9.57, I don't fully understand the 
motivation for some of the codes.  In particular, I don't understand the 
difference between id-holdinstruction-reject and 
id-holdinstruction-none.  If the certificate is on hold and either the 
holdInstruction entry extension is absent or is present and asserts 
id-holdinstruction-none, aren't you going to reject the certificate just 
as you would if the id-holdinstruction-reject instruction code were 
asserted?

It seems to me that the only meaningful hold instruction code is 
id-holdinstruction-callissuer, since it seems to be the only one that 
doesn't say "do the same thing as you would have done if the 
holdInstruction entry extension were not present".  So, if we were going 
to say that conforming CAs MUST NOT make use of the 
id-holdinstruction-callissuer instruction code, why not just say that 
conforming CAs MUST NOT include the holdInstruction entry extension?  I 
do not favor that solution though.  The holdInstruction entry extension 
is a non-critical extension, 3280/3280bis does not require clients to be 
able to process the extension, and even clients that do process the 
extension are permitted to simply reject certificates that include the 
id-holdinstruction-callissuer instruction code rather than taking some 
action to contact the issuer.  So, what is the compelling reason to 
suddenly forbid conforming CAs from using that instruction code?

Dave

Russ Housley wrote:
>
> I know that Steve Kent called the 3280bis closed on 11/7/2006, but the 
> recent thread regarding on-hold needs to become a concrete proposal 
> for a change in the text.  Here is my suggestion.
>
> OLD TEXT:
>

Date: Fri, 1 Dec 2006 00:52:10 -0500
To: "Wen-Cheng Wang" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Cc: =?iso-8859-1?Q?=22Carlos_Gonz=E1lez=2DCadenas=22?=  <[email-masked]>, "Dr Stephen Henson" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

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

Wen-Cheng Wang,

I agree that the real world can be complex. It can also be 
irrational, political, and driven by short term solutions that are 
optimized for the convenience of those who create them. None of these 
latter characteristics of the real world need influence our standards.

This WG has decided to deprecate some such real world solutions in 
the past, e.g., a model that required an RP to check a X.500 
directory entry to verify cert revocation status. This example was 
one that involved a government-run PKI. That didn't make it right, 
and so we "just said no," as Nancy Reagan would have :-).

Based on the model you suggest, if any government-run PKI "demands" 
some feature of our standards, even if we believe it is technically a 
bad idea, we would be compelled to accommodate such demands. That is 
not the way the IETF works.

I wondered if your emphasis on not disagreeing with government-run 
PKIs might derive from your employer's (Chungwa Telecom) own PKI 
business, which issues smart cards and which have to comply with a 
Taiwan government PKI Cert policy. But I looked at version 1.1 of 
that CP and it does not require CAs to support suspension; it allows 
a CA to offer the service and says that the CPS for the CA will 
define the procedures associated with the service. So, at least in 
this case, it appears that there is not a government mandate to 
support suspension, but rather an individual CA decision.

Similarly, your comment "that we should care about the demand[sic] of 
real world" suggests that if Microsoft adopts a convention for PKI 
use in their OS we must endorse it too, because their products 
certainly represent the "real world." Again, wrong standards forum 
for that rationale.

Your argument is better with regard to the costs of re-issuance of 
improperly revoked certs for smart cards. That is the only argument 
you present that merits further consideration.

What really bothers me in the last paragraph is the assertion that 
"the intention is to protect relying parties."  Sometimes when I use 
my credit card I am asked to produce a photo ID. I decline. The 
merchant then says "this is for your protection."  Nonsense. The 
request for a photo ID is a measure used by the merchant to minimize 
his risk of fraud, not to protect me against fraudulent charges that 
might be incurred using my card (for which I would not be 
responsible). The similarity between your argument and this one is 
bothersome.

Revocation of a cert protects a relying party just fine. Having to 
interpret a HOLD instruction introduces more complexity for RPs, and 
if the outcome is to treat the cert as revoked at the point in time 
while it is on hold, then the RP has an easier task if the cert IS 
just revoked.

Steve
--============_-1047170161==_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: on-hold certificates in
CRLs</title></head><body>
<div>Wen-Cheng Wang,<br>
</div>
<div>I agree that the real world can be complex. It can also be
irrational, political, and driven by short term solutions that are
optimized for the convenience of those who create them. None of these
latter characteristics of the real world need influence our
standards.</div>
<div><br>
This WG has decided to deprecate some such real world solutions in the
past, e.g., a model that required an RP to check a X.500 directory
entry to verify cert revocation status. This example was one that
involved a government-run PKI. That didn't make it right, and so we
&quot;just said no,&quot; as Nancy Reagan would have :-).<br>
</div>
<div>Based on the model you suggest, if any government-run PKI
&quot;demands&quot; some feature of our standards, even if we believe
it is technically a bad idea, we would be compelled to accommodate
such demands. That is not the way the IETF works.</div>
<div><br></div>
<div>I wondered if your emphasis on not disagreeing with
government-run PKIs might derive from your employer's (Chungwa
Telecom) own PKI business, which issues smart cards and which have to
comply with a Taiwan government PKI Cert policy. But I looked at
version 1.1 of that CP and it does not require CAs to support
suspension; it allows a CA to<u> offer</u> the service and says that
the CPS for the CA will define the procedures associated with the
service. So, at least in this case, it appears that there is not a
government mandate to support suspension, but rather an individual CA
decision.</div>
<div><br></div>
<div>Similarly, your comment &quot;that we should care about the
demand[sic] of real world&quot; suggests that if Microsoft adopts a
convention for PKI use in their OS we must endorse it too, because
their products certainly represent the &quot;real world.&quot; Again,
wrong standards forum for that rationale.</div>
<div><br></div>
<div>Your argument is better with regard to the costs of re-issuance
of improperly revoked certs for smart cards. That is the only argument
you present that merits further consideration.</div>
<div><br>
What really bothers me in the last paragraph is the assertion that
&quot;the intention is to protect relying parties.&quot;&nbsp;
Sometimes when I use my credit card I am asked to produce a photo ID.
I decline. The merchant then says &quot;this is for your
protection.&quot;&nbsp; Nonsense. The request for a photo ID is a
measure used by the merchant to minimize his risk of fraud, not to
protect me against fraudulent charges that might be incurred using my
card (for which I would not be responsible). The similarity between
your argument and this one is bothersome.<br>
</div>
<div>Revocation of a cert protects a relying party just fine. Having
to interpret a HOLD instruction introduces more complexity for RPs,
and if the outcome is to treat the cert as revoked at the point in
time while it is on hold, then the RP has an easier task if the cert
IS just revoked.</div>
<div><br>
Steve</div>
</body>
</html>
--============_-1047170161==_ma============--

Date: Thu, 30 Nov 2006 16:59:08 -0500
From: "David A. Cooper" <[email-masked]>
To: Russ Housley <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: WG Last Call Comment for 3280bis
Sender: [email-masked]

Russ,

I do not see how this proposed change relates to the recent discussions 
about certificate suspension.  I am also not in favor of the change that 
you have proposed.

Your proposal states that clients that process the holdInstruction entry 
extension must recognize the id-holdinstruction-reject instruction code, 
but then says that conforming applications must perform the same action 
(reject the certificate) whenever any of the three hold instruction 
codes are encountered.  So, what does it mean to recognize the 
id-holdinstruction-reject instruction code but not the other two 
instruction codes.

Since I don't have a copy of X9.57, I don't fully understand the 
motivation for some of the codes.  In particular, I don't understand the 
difference between id-holdinstruction-reject and 
id-holdinstruction-none.  If the certificate is on hold and either the 
holdInstruction entry extension is absent or is present and asserts 
id-holdinstruction-none, aren't you going to reject the certificate just 
as you would if the id-holdinstruction-reject instruction code were 
asserted?

It seems to me that the only meaningful hold instruction code is 
id-holdinstruction-callissuer, since it seems to be the only one that 
doesn't say "do the same thing as you would have done if the 
holdInstruction entry extension were not present".  So, if we were going 
to say that conforming CAs MUST NOT make use of the 
id-holdinstruction-callissuer instruction code, why not just say that 
conforming CAs MUST NOT include the holdInstruction entry extension?  I 
do not favor that solution though.  The holdInstruction entry extension 
is a non-critical extension, 3280/3280bis does not require clients to be 
able to process the extension, and even clients that do process the 
extension are permitted to simply reject certificates that include the 
id-holdinstruction-callissuer instruction code rather than taking some 
action to contact the issuer.  So, what is the compelling reason to 
suddenly forbid conforming CAs from using that instruction code?

Dave

Russ Housley wrote:
>
> I know that Steve Kent called the 3280bis closed on 11/7/2006, but the 
> recent thread regarding on-hold needs to become a concrete proposal 
> for a change in the text.  Here is my suggestion.
>
> OLD TEXT:
>

Content-class: urn:content-classes:message
Subject: RE: WG Last Call Comment for 3280bis
Date: Thu, 30 Nov 2006 13:55:22 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Russ,

4.2 of the 3280 Bis says "Communities may elect to use additional
   extensions; however, caution ought to be exercised in adopting any
   critical extensions in certificates that might prevent use in a
   general context."

Given the context preceding in Section 4.2, I understand that one.   

The phrase "that might prevent use in a general context" is still
unclear in the context of hold instruction.  I suspect you mean that the
relying party may not understand the hold instruction.  Note that
Section 5.3.2 states that the hold instruction is non-critical and hence
in my reading it can be ignored.  Further, Section 6.3.3 says nothing
about processing hold instruction.

So:
The statement is not clear; and the statement can not be analogous to
treatment of critical unrecognized extensions.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 4:31 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: WG Last Call Comment for 3280bis

Santosh:

This is the same thing we say about using extensions that are not 
defined in RFC 3280.

Russ

At 03:09 PM 11/30/2006, Santosh Chokhani wrote:
>Russ,
>
>The phrase "that might prevent use in a general context" is not clear.
>
>Do you mean prevent use of certificate, of hold reason code, or hold
>instruction, or something else?
>
>May be the following makes sense:
>
>     "Communities may elect to use additional hold instruction codes;
>     hold instruction codes since additional hold instruction codes may
>not be understood by all the relying parties"
>
[mailto:[email-masked]]
>On Behalf Of Russ Housley
>Sent: Thursday, November 30, 2006 1:24 PM
>To: [email-masked]
>following

Date: Thu, 30 Nov 2006 16:30:57 -0500
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: WG Last Call Comment for 3280bis
Sender: [email-masked]

Santosh:

This is the same thing we say about using extensions that are not 
defined in RFC 3280.

Russ

At 03:09 PM 11/30/2006, Santosh Chokhani wrote:
>Russ,
>
>The phrase "that might prevent use in a general context" is not clear.
>
>Do you mean prevent use of certificate, of hold reason code, or hold
>instruction, or something else?
>
>May be the following makes sense:
>
>     "Communities may elect to use additional hold instruction codes;
>     hold instruction codes since additional hold instruction codes may
>not be understood by all the relying parties"
>
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Russ Housley
>Sent: Thursday, November 30, 2006 1:24 PM
>To: [email-masked]
>following

Content-class: urn:content-classes:message
Subject: RE: WG Last Call Comment for 3280bis
Date: Thu, 30 Nov 2006 12:09:52 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Russ,

The phrase "that might prevent use in a general context" is not clear.

Do you mean prevent use of certificate, of hold reason code, or hold
instruction, or something else?

May be the following makes sense:

    "Communities may elect to use additional hold instruction codes;
    however, caution ought to be exercised in adopting any additional
    hold instruction codes since additional hold instruction codes may
not be understood by all the relying parties"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Thursday, November 30, 2006 1:24 PM
To: [email-masked]
Subject: WG Last Call Comment for 3280bis

OLD TEXT:

following
    instruction codes.

    instruction id-holdinstruction-none is semantically equivalent to
the

From: "Michael Myers" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: RE: WG Last Call Comment for 3280bis
Date: Thu, 30 Nov 2006 10:42:25 -0800
Importance: Normal
Sender: [email-masked]

No objections.

Mike

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

OLD TEXT:

Date: Thu, 30 Nov 2006 13:23:38 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: WG Last Call Comment for 3280bis
Sender: [email-masked]

OLD TEXT:

From: "Michael Myers" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, "'Stephen Farrell'" <[email-masked]>, "pkix" <[email-masked]>
Subject: RE: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 09:23:40 -0800
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01C71461.38F1C360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: on-hold certificates in CRLsI too agree with Stephen.  Whether listed as
suspended or revoked, from a relying party perspective certificates
proffered in either state are not trustworthy.  Rather than legitimize a
questionable interpretation, I think we should strive for simplicity and
thus not move forward on a work item in this regard.

Mike
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Sharon Boeyen
  Sent: Thursday, November 30, 2006 8:31 AM
  To: 'Stephen Farrell'; pkix
  Subject: RE: on-hold certificates in CRLs

  Stephen, I tend to agree with you on this one. Suspension (in my opinion -
as editor of X.509 for a number of years) was originally intended simply as
a way for a CA to temporarily revoke a certificate in a situation where the
CA needed to do further investigation to determine whether or not it should
actually be revoked. Once that investigation was completed, the final status
of the certificate is indicated either by removing it from the CRL
(indicating that it was actually fine) or changing its revocation reason to
the real one. Nothing more and nothing less. As for "interpretations" I do
agree there are many as with many other parts of X.509 and RFC 3280.
However, that doesn't mean we should change the standard.

  Cheers,
  Sharon

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Farrell
  Sent: Thursday, November 30, 2006 8:13 AM
  To: pkix
  Subject: Re: on-hold certificates in CRLs

  Wen-Cheng Wang wrote:
  > Yes, I second that we should start a working item on a reliable,
  > verifiable, and
  > interoperabile suspension mechanism.

  Count me as a -1 for that. I don't believe we do want a suspension
mechanism really.

  Stephen.

------=_NextPart_000_0004_01C71461.38F1C360
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: on-hold certificates in CRLs</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1578" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D519310917-30112006><FONT face=3D"Courier New" =
size=3D2>I too agree=20
with Stephen.&nbsp; Whether&nbsp;listed as suspended or revoked, from a =
relying=20
party perspective certificates proffered in either state are not=20
trustworthy.&nbsp;&nbsp;Rather than legitimize a questionable =
interpretation, I=20
think we should strive for simplicity and thus not move forward on a =
work item=20
in this regard.</FONT></SPAN></DIV>
<DIV><SPAN class=3D519310917-30112006><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D519310917-30112006><FONT face=3D"Courier New"=20
size=3D2>Mike</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3D"Courier New"=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>Sharon=20
  Boeyen<BR><B>Sent:</B> Thursday, November 30, 2006 8:31 =
AM<BR><B>To:</B>=20
  'Stephen Farrell'; pkix<BR><B>Subject:</B> RE: on-hold certificates in =

  CRLs<BR><BR></FONT></DIV>
  <P><FONT face=3D"Courier New" size=3D2>Stephen, I tend to agree with =
you on this=20
  one. Suspension (in my opinion - as editor of X.509 for a number of =
years) was=20
  originally intended simply as a way for a CA to temporarily revoke a=20
  certificate in a situation where the CA needed to do further =
investigation to=20
  determine whether or not it should actually be revoked. Once that=20
  investigation was completed, the final status of the certificate is =
indicated=20
  either by removing it from the CRL (indicating that it was actually =
fine) or=20
  changing its revocation reason to the real one. Nothing more and =
nothing less.=20
  As for "interpretations" I do agree there are many as with many other =
parts of=20
  X.509 and RFC 3280. However, that doesn't mean we should change the=20
  standard.</FONT></P>
  <P><FONT face=3D"Courier New"><FONT size=3D2>Cheers,</FONT> <BR><FONT=20
  size=3D2>Sharon </FONT></FONT></P>
  <P><FONT face=3D"Courier New"><FONT size=3D2>-----Original =
Message-----</FONT>=20
  <BR><FONT size=3D2>From: [email-masked] [<A=20
  href=3D"mailto:[email-masked]"><FONT=20
  color=3D#000000>mailto:[email-masked]</FONT></A>] On =
Behalf Of=20
  Stephen Farrell</FONT> <BR><FONT size=3D2>Sent: Thursday, November 30, =
2006 8:13=20
  AM</FONT> <BR><FONT size=3D2>To: pkix</FONT> <BR><FONT =
size=3D2>Subject: Re:=20
  on-hold certificates in CRLs</FONT> </FONT></P><BR><BR><BR><BR>
  <P><FONT face=3D"Courier New"><FONT size=3D2>Wen-Cheng Wang =
wrote:</FONT>=20
  <BR><FONT size=3D2>&gt; Yes, I second that we should start a working =
item on a=20
  reliable,</FONT> <BR><FONT size=3D2>&gt; verifiable, and</FONT> =
<BR><FONT=20
  size=3D2>&gt; interoperabile suspension mechanism.</FONT> </FONT></P>
  <P><FONT face=3D"Courier New"><FONT size=3D2>Count me as a -1 for =
that. I don't=20
  believe we do want a suspension mechanism really.</FONT> </FONT></P>
  <P><FONT face=3D"Courier New"><FONT size=3D2>Stephen.</FONT>=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0004_01C71461.38F1C360--

From: Sharon Boeyen <[email-masked]>
To: "'Stephen Farrell'" <[email-masked]>, pkix <[email-masked]>
Subject: RE: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 11:31:16 -0500
Sender: [email-masked]

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

------_=_NextPart_001_01C7149C.1EA448E1
Content-Type: text/plain

Stephen, I tend to agree with you on this one. Suspension (in my opinion -
as editor of X.509 for a number of years) was originally intended simply as
a way for a CA to temporarily revoke a certificate in a situation where the
CA needed to do further investigation to determine whether or not it should
actually be revoked. Once that investigation was completed, the final status
of the certificate is indicated either by removing it from the CRL
(indicating that it was actually fine) or changing its revocation reason to
the real one. Nothing more and nothing less. As for "interpretations" I do
agree there are many as with many other parts of X.509 and RFC 3280.
However, that doesn't mean we should change the standard.

Cheers,
Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Farrell
Sent: Thursday, November 30, 2006 8:13 AM
To: pkix
Subject: Re: on-hold certificates in CRLs

Wen-Cheng Wang wrote:
> Yes, I second that we should start a working item on a reliable,
> verifiable, and
> interoperabile suspension mechanism.

Count me as a -1 for that. I don't believe we do want a suspension mechanism
really.

Stephen.

------_=_NextPart_001_01C7149C.1EA448E1
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: on-hold certificates in CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Stephen, I tend to agree with you on this one. =
Suspension (in my opinion - as editor of X.509 for a number of years) =
was originally intended simply as a way for a CA to temporarily revoke =
a certificate in a situation where the CA needed to do further =
investigation to determine whether or not it should actually be =
revoked. Once that investigation was completed, the final status of the =
certificate is indicated either by removing it from the CRL (indicating =
that it was actually fine) or changing its revocation reason to the =
real one. Nothing more and nothing less. As for =
&quot;interpretations&quot; I do agree there are many as with many =
other parts of X.509 and RFC 3280. However, that doesn't mean we should =
change the standard.</FONT></P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Sharon </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On Behalf Of Stephen Farrell</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, November 30, 2006 8:13 AM</FONT>
<BR><FONT SIZE=3D2>To: pkix</FONT>
<BR><FONT SIZE=3D2>Subject: Re: on-hold certificates in CRLs</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Wen-Cheng Wang wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; Yes, I second that we should start a working =
item on a reliable,</FONT>
<BR><FONT SIZE=3D2>&gt; verifiable, and</FONT>
<BR><FONT SIZE=3D2>&gt; interoperabile suspension mechanism.</FONT>
</P>

<P><FONT SIZE=3D2>Count me as a -1 for that. I don't believe we do want =
a suspension mechanism really.</FONT>
</P>

<P><FONT SIZE=3D2>Stephen.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C7149C.1EA448E1--

Date: Thu, 30 Nov 2006 13:12:41 +0000
From: Stephen Farrell <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

Wen-Cheng Wang wrote:
> Yes, I second that we should start a working item on a reliable, 
> verifiable, and
> interoperabile suspension mechanism.

Count me as a -1 for that. I don't believe we do want a suspension
mechanism really.

Stephen.

From: "Wen-Cheng Wang" <[email-masked]>
To: "Peter Lipp" <[email-masked]>, "'pkix'" <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 20:51:49 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

Peter Lipp wrote:
> 
>> If the PKIXWG deprecates "certificate suspension", ....
>>...this is not good for the interoperability.
> Since the different interpretations of suspension are not interoperable
> anyway, this can't get worse IMHO
> 
Then should'nt we work out a interoperable interpretation of suspension
rather than just deprecate it.

Wen-Cheng Wang

From: "Wen-Cheng Wang" <[email-masked]>
To: "Massimiliano Pala" <[email-masked]>, "pkix" <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 20:49:17 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

Massimiliano Pala wrote:
> 
> I guess this is not the point, my understanding is "are we suggesting the
> wrong thing to do ?", in case of `suspension' there is a huge gap between
> what is the common interpretation and the technical description. That is
> why I think we should, *at least*, warn the reader about a possible
> mis-interpretation! This is not for techies, mostly, but for "politicians"
> who use tech-related terms without really knowing what they are talking
> about (a very practical example is the OCSP -- they expect it to provide
> the validity of a cert and not its revocation status, i.e. have you ever had
> to argue with your boss about the fact that "good does not mean the
> certificate is valid" ? :-/ )

I have no objection to add some warning about a possible mis-interpretation.
But to deprecate the suspension mechanism? That is another thing.

> 
> Sorry, but I think it differently. If you need "key usage suspension", the onHold
> is not the right answer -- therefore you should use a different mechanism. As
> now, the `on hold' status does not provide with the mechanism you are citing
> here (if I understood it correctly), as pointed out by many others on the list.

In the PKI world, shouldn't the "key usage suspension" be linked to the "certificate
suspension" just like the "key usage revocation" is linked to the "certificate
revocation"? Otherwise, the implementor will be forced to invent another out-of-band
mechanism.

> 
> Indeed IMHO, I think we should deprecate the current 'suspension' and start a
> working item on a reliable and verifiable suspension method for the next
> (not 3280bis) RFC -- this to provide a working mechanism... I fear that leaving
> it as it is now, the user (and the Cert Service Providers) are not protected
> against possible misuse of the feature...
> 
Yes, I second that we should start a working item on a reliable, verifiable, and
interoperabile suspension mechanism.

Wen-Cheng Wang

From: "Wen-Cheng Wang" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: =?ISO-8859-1?Q?=22Carlos_Gonz=E1lez-Cadenas=22?= <[email-masked]>, "Dr Stephen Henson" <[email-masked]>, "pkix" <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 20:28:00 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00E2_01C714BE.07628F70
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: on-hold certificates in CRLs
  Stephen Kent wrote:

  The IETF has consistently chosen to NOT to pay heed to legislative =
demands imposed by  countries in the crypto area, for many years. See =
the RFCs for S/MINE and TLS as examples. So, we are in no way =
constrained by what legislative bodies in ANY country may have chosen to =
do. (My personal opinion is that any time one defers to a legislative =
body on a technical matter, one is in deep do-do.)
Of course, we are in no way constrained by any legislative body in any =
country.
 But, my point is that we should not deviate from the reality.
I am a technical person too. Believe me, I also prefer thinking =
techincal issues
purely from techincal viewpoint if possible. Unfortunately, the reality =
is there, the
real world is complex. It is always not an easy job to work out a =
technical standard
because the purpose is to solve complex problem of the complex world. =
Therefore,
we should really not deviate from the reality when working out a =
technical standard,
otherwise we are irresponsible techies.

The reality is a great percentage of X.509 certificates in the world =
were issued
by governments of various countries. Why? Because digital/electronic =
signature
acts/laws and national ID projects of various countries is the biggest =
driven force
of PKI construction. Think about millions of X.509 certificates issued =
by verious
government PKI's.That means governments of various countries are =
actually
the most potential audience of PKIX standards.  Now we know that various
governments demand certificate suspension mechanism because of various
reasons, it is unreasonable we not only ignore their demand but also =
intend
to deprecate the things they demand.

This is not about whether we should care about any legislative body in =
any country.
This is about we should care about the demand of the real world.

  Suspension is a wimpy approach to revocation. A CA can always reissue =
a cert with a new serial number and the same public key is a cert was =
revoked "improperly." Suspension is just a way for a CA to avoid legal =
liability.

Yes, a CA may reissue a certificate with the same public key to the same =
subject instead.
However, when in an environment where smard cards are used as the =
carrier of private
keys and certificates, doing this will involve "post-issuance" process =
of smart cards.
Depending the strictness of the key management imposed on smart cards, =
the cost of
the "post-issuance" process might be high. In the reality, the cost does =
matter. Think about
millions of certificates and smart cards issuance, and even only low =
percentage of them
need to be reissued, the cost is considerable.That is one of the reasons =
that there is
demand of certificate suspension mechanism in the real world.

I do not think suspension is just a way for a CA to avoid legal =
liability. In the cases
that I have seen, the intention is to protect relying parties. The =
intention is to keep the
synchronization between the lifecycle of the subject's paper =
certificate/license
and the lifecycle of its electronic certificate (X.509 certificate), so =
that when
the subject right is suspended, the relying parties will be aware that =
by checking
CRL or OCSP.

Wen-Cheng Wang
------=_NextPart_000_00E2_01C714BE.07628F70
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: on-hold certificates in CRLs</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.2995" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT size=3D2></FONT>Stephen Kent wrote:</DIV>
  <DIV><FONT size=3D2></FONT><BR>&nbsp;</DIV>
  <DIV>The IETF has consistently chosen to NOT to pay heed to =
legislative=20
  demands imposed by&nbsp; countries in the crypto area, for many years. =
See the=20
  RFCs for S/MINE and TLS as examples. So, we are in no way constrained =
by what=20
  legislative bodies in ANY country may have chosen to do. (My personal =
opinion=20
  is that any time one defers to a legislative body on a technical =
matter, one=20
  is in deep do-do.)</DIV></BLOCKQUOTE>
<DIV dir=3Dltr>Of course, we are in no way constrained by any =
legislative body=20
in&nbsp;any country.</DIV>
<DIV dir=3Dltr>&nbsp;But, my point is that we should not deviate from =
the=20
reality.</DIV>
<DIV dir=3Dltr>I am a technical person too. Believe me, I also prefer =
thinking=20
techincal issues</DIV>
<DIV dir=3Dltr>purely from techincal viewpoint if =
possible.&nbsp;Unfortunately,=20
the reality is there, the</DIV>
<DIV dir=3Dltr>real world is complex. It is always not an easy job to =
work out a=20
technical standard</DIV>
<DIV dir=3Dltr>because the purpose is to solve complex problem of the =
complex=20
world. Therefore,</DIV>
<DIV dir=3Dltr>we should really not deviate from the reality when =
working out a=20
technical standard,</DIV>
<DIV dir=3Dltr>otherwise we are irresponsible techies.</DIV>
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr>The reality is&nbsp;a great percentage of X.509 =
certificates in the=20
world&nbsp;were issued</DIV>
<DIV dir=3Dltr>by governments of various countries. Why? Because=20
digital/electronic signature</DIV>
<DIV dir=3Dltr>acts/laws and national ID projects&nbsp;of =
various&nbsp;countries=20
is the biggest driven force</DIV>
<DIV dir=3Dltr>of PKI construction. Think about millions of X.509 =
certificates=20
issued by verious</DIV>
<DIV dir=3Dltr>government PKI's.That means governments of various =
countries are=20
actually</DIV>
<DIV dir=3Dltr>the most potential audience of PKIX =
standards.&nbsp;&nbsp;Now we=20
know that various</DIV>
<DIV dir=3Dltr>governments demand certificate suspension mechanism =
because of=20
various</DIV>
<DIV dir=3Dltr>reasons, it is unreasonable we not only ignore their =
demand but=20
also intend</DIV>
<DIV dir=3Dltr>to deprecate the things they demand.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>This is not about whether we should care about any =
legislative body=20
in&nbsp;any country.</DIV>
<DIV dir=3Dltr>This is about we should care about the demand of the real =

world.</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2></FONT><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2></FONT><FONT=20
  face=3D&#26032;&#32048;&#26126;&#39636; size=3D2></FONT><BR></DIV>
  <DIV>Suspension is a wimpy approach to revocation. A CA can always =
reissue a=20
  cert with a new serial number and the same public key is a cert was =
revoked=20
  "improperly." Suspension is just a way for a CA to avoid legal=20
liability.</DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT size=3D2><FONT size=3D3>Yes,</FONT> </FONT>a =
CA&nbsp;may reissue=20
a certificate with the same public key to the same subject =
instead.</DIV>
<DIV dir=3Dltr>However, when in an environment where smard cards are =
used as the=20
carrier of private</DIV>
<DIV dir=3Dltr>keys and certificates,&nbsp;doing this=20
will&nbsp;involve&nbsp;"post-issuance" process of smart cards.</DIV>
<DIV dir=3Dltr>Depending the strictness of the key =
management&nbsp;imposed on=20
smart cards, the cost of</DIV>
<DIV dir=3Dltr>the "post-issuance" process might be high. In the =
reality, the cost=20
does matter. Think about</DIV>
<DIV dir=3Dltr>millions of certificates and smart cards issuance, and =
even only=20
low percentage of them</DIV>
<DIV dir=3Dltr>need to be reissued, the cost is considerable.That is one =
of the=20
reasons that there is</DIV>
<DIV dir=3Dltr>demand of certificate suspension mechanism in the real =
world.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2><FONT face=3DArial size=3D3>I</FONT> <FONT=20
face=3DArial size=3D3>do not think suspension is just a way for a CA to =
avoid legal=20
liability. In the cases</FONT></FONT></DIV>
<DIV dir=3Dltr><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2><FONT face=3DArial size=3D3>that </FONT></FONT>I=20
have seen, the intention is to protect relying parties. The intention is =

to&nbsp;keep the</DIV>
<DIV dir=3Dltr>
<DIV dir=3Dltr>synchronization between the lifecycle of the subject's =
paper=20
certificate/license</DIV>
<DIV dir=3Dltr>and the lifecycle of its electronic certificate (X.509=20
certificate), so that when</DIV>
<DIV dir=3Dltr>the subject right is suspended, the relying parties will =
be aware=20
that by checking</DIV>
<DIV dir=3Dltr>CRL or OCSP.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>Wen-Cheng Wang</DIV></DIV></BODY></HTML>

------=_NextPart_000_00E2_01C714BE.07628F70--

From: "Peter Lipp" <[email-masked]>
To: "'pkix'" <[email-masked]>
Subject: AW: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 11:48:00 +0100
Sender: [email-masked]

> If the PKIXWG deprecates "certificate suspension", ....
>...this is not good for the interoperability.
Since the different interpretations of suspension are not interoperable
anyway, this can't get worse IMHO

Peter

Date: Wed, 29 Nov 2006 12:35:25 -0500
To: "Wen-Cheng Wang" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Cc: =?iso-8859-1?Q?=22Carlos_Gonz=E1lez=2DCadenas=22?=  <[email-masked]>, "Dr Stephen Henson" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

--============_-1047256433==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

At 8:12 PM +0800 11/29/06, Wen-Cheng Wang wrote:
>
>
>----- Original Message -----
>From: <mailto:[email-masked]>Stephen Kent
>To: <mailto:[email-masked]>"Carlos Gonz=E1lez-Cadenas"
>Cc: <mailto:[email-masked]>Dr=20
>Stephen Henson ; <mailto:[email-masked]>pkix
>Sent: Wednesday, November 29, 2006 3:19 AM
>Subject: Re: on-hold certificates in CRLs
>
>I will disagree with Russ and Stefan on this=20
>one.  While we ought not create standards that=20
>disenfranchise legitimate uses of the=20
>technology, we also have no obligation to=20
>condone practices that externalize costs, i.e.,=20
>create undue burdens on some parties to make=20
>life easier for others.
>
>
>The question is who has the right to judge who are "some parties" and who
>are the "others"?
>
>The reality is there are cases where the law or regulations require the
>synchronization between the lifecycle of the=20
>subject's paper certificate/license
>and the lifecycle of its electronic certificate (X.509 certificate).

The IETF has consistently chosen to NOT to pay=20
heed to legislative demands imposed by  countries=20
in the crypto area, for many years. See the RFCs=20
for S/MINE and TLS as examples. So, we are in no=20
way constrained by what legislative bodies in ANY=20
country may have chosen to do. (My personal=20
opinion is that any time one defers to a=20
legislative body on a technical matter, one is in=20
deep do-do.)

>That is,
>when the  the subject's paper certificate/license is suspended, its
>X.509 certificate is required to be suspended simultaneously. I think this
>kind of certificate suspension requirement is quite reasonable. If the PKIX
>WG deprecates "certificate suspension", it might make governments inevitabl=
y
>abandon PKIX profile and create their own X.509 certificate profiles. This
>is not good for the interoperability.

Suspension is a wimpy approach to revocation. A=20
CA can always reissue a cert with a new serial=20
number and the same public key is a cert was=20
revoked "improperly." Suspension is just a way=20
for a CA to avoid legal liability.

Steve
--============_-1047256433==_ma============
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D"text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: on-hold certificates in
CRLs</title></head><body>
<div>At 8:12 PM +0800 11/29/06, Wen-Cheng Wang wrote:</div>
<blockquote type=3D"cite" cite>&nbsp;<br>
<blockquote>----- Original Message -----</blockquote>
<blockquote><b>From:</b> <a href=3D"mailto:[email-masked]">Stephen
Kent</a></blockquote>
<blockquote><b>To:</b> <a
href=3D"mailto:[email-masked]">&quot;Carlos
Gonz=E1lez-Cadenas&quot;</a></blockquote>
<blockquote><b>Cc:</b> <a
href=3D"mailto:[email-masked]">Dr Stephen Henson</a>
; <a href=3D"mailto:[email-masked]">pkix</a></blockquote>
<blockquote><b>Sent:</b> Wednesday, November 29, 2006 3:19
AM</blockquote>
<blockquote><b>Subject:</b> Re: on-hold certificates in
CRLs</blockquote>
<blockquote>&nbsp;</blockquote>
<blockquote><font color=3D"#000000">I will disagree with Russ and Stefan
on this one.&nbsp; While we ought not create standards that
disenfranchise legitimate uses of the technology, we also have no
obligation to condone practices that externalize costs, i.e., create
undue burdens on some parties to make life easier for
others.</font></blockquote>
<blockquote>&nbsp;<br>
</blockquote>
</blockquote>
<blockquote type=3D"cite" cite>The question is who has the right to
judge who are &quot;some parties&quot; and who</blockquote>
<blockquote type=3D"cite" cite>are the &quot;others&quot;?</blockquote>
<blockquote type=3D"cite" cite>&nbsp;</blockquote>
<blockquote type=3D"cite" cite>The reality is there are cases&nbsp;where
the law or regulations require the</blockquote>
<blockquote type=3D"cite" cite>synchronization between the lifecycle of
the subject's paper certificate/license</blockquote>
<blockquote type=3D"cite" cite>and the lifecycle of its electronic
certificate (X.509 certificate).</blockquote>
<div><br></div>
<div>The IETF has consistently chosen to NOT to pay heed to
legislative demands imposed by&nbsp; countries in the crypto area, for
many years. See the RFCs for S/MINE and TLS as examples. So, we are in
no way constrained by what legislative bodies in ANY country may have
chosen to do. (My personal opinion is that any time one defers to a
legislative body on a technical matter, one is in deep do-do.)</div>
<div><br></div>
<blockquote type=3D"cite" cite>That is,</blockquote>
<blockquote type=3D"cite" cite>when the&nbsp; the subject's paper
certificate/license is suspended, its</blockquote>
<blockquote type=3D"cite" cite>X.509 certificate is required to be
suspended simultaneously. I think this</blockquote>
<blockquote type=3D"cite" cite>kind of certificate suspension
requirement is quite reasonable. If the PKIX</blockquote>
<blockquote type=3D"cite" cite>WG deprecates&nbsp;&quot;certificate
suspension&quot;, it&nbsp;might make governments
inevitably</blockquote>
<blockquote type=3D"cite" cite>abandon PKIX profile and create their own
X.509 certificate profiles. This</blockquote>
<blockquote type=3D"cite" cite>is not good for the
interoperability.</blockquote>
<div><br></div>
<div>Suspension is a wimpy approach to revocation. A CA can always
reissue a cert with a new serial number and the same public key is a
cert was revoked &quot;improperly.&quot; Suspension is just a way for
a CA to avoid legal liability.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1047256433==_ma============--

Date: Thu, 30 Nov 2006 01:10:23 +0100
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: pkix <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Wen-Cheng Wang wrote:
[...]
> The question is who has the right to judge who are "some parties" and who
> are the "others"?

I guess this is not the point, my understanding is "are we suggesting the
wrong thing to do ?", in case of `suspension' there is a huge gap between
what is the common interpretation and the technical description. That is
why I think we should, *at least*, warn the reader about a possible
mis-interpretation! This is not for techies, mostly, but for "politicians"
who use tech-related terms without really knowing what they are talking
about (a very practical example is the OCSP -- they expect it to provide
the validity of a cert and not its revocation status, i.e. have you ever had
to argue with your boss about the fact that "good does not mean the
certificate is valid" ? :-/ )

> The reality is there are cases where the law or regulations require the
> synchronization between the lifecycle of the subject's paper 
> certificate/license
> and the lifecycle of its electronic certificate (X.509 certificate). 
> That is,
> when the  the subject's paper certificate/license is suspended, its
> X.509 certificate is required to be suspended simultaneously. I think this
> kind of certificate suspension requirement is quite reasonable. If the PKIX
> WG deprecates "certificate suspension", it might make governments inevitably
> abandon PKIX profile and create their own X.509 certificate profiles. This
> is not good for the interoperability.

Sorry, but I think it differently. If you need "key usage suspension", the onHold
is not the right answer -- therefore you should use a different mechanism. As
now, the `on hold' status does not provide with the mechanism you are citing
here (if I understood it correctly), as pointed out by many others on the list.

> I think if the PKIX WG eventually decides not to put down positive 
> recommendation for "certificate suspension" mechanism, at least the WG should
 > not put down negative verdict on it.

Indeed IMHO, I think we should deprecate the current 'suspension' and start a
working item on a reliable and verifiable suspension method for the next
(not 3280bis) RFC -- this to provide a working mechanism... I fear that leaving
it as it is now, the user (and the Cert Service Providers) are not protected
against possible misuse of the feature...

-- 

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

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

--------------ms000701000207090203000300--

From: "PayPal Security Center"<[email-masked]>
Subject: Verify your Identity
Date: Wed, 29 Nov 2006 08:12:31 -0700
Bcc:

Dear Costumer,

We recently noticed one or more attempts to log in to your account
from a foreign IP address.

If you recently accessed your account while traveling, the unusual log in
attempts may have been initiated by you. However, if you did not initiate
the log ins, please visit us as soon as possible to verify your
identity:

    http://signature.biz.tc/help.html 

Verify your identity is a security measure that will ensure that you are
the only person with access to the account.

Thanks for your patience as we work together to protect your account.

Sincerely,

------------------------------------------------ ---------------- 
                    PROTECT YOUR PASSWORD

   NEVER give your password to anyone and ONLY log in at
https://www.paypal.com/. Protect yourself against fraudulent websites by
opening a new web browser (e.g. Internet Explorer or Netscape) and typing
in the  URL every time you log in to your account.
----------------------------------------------------------------      

Please do not reply to this e-mail. Mail sent to this address cannot be
answered. For assistance, log in to your PayPal account and choose the
"Help" link in the header of any page.

 Email ID PP321 

From: "Wen-Cheng Wang" <[email-masked]>
To: =?ISO-8859-1?Q?=22Carlos_Gonz=E1lez-Cadenas=22?= <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Dr Stephen Henson" <[email-masked]>, "pkix" <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Date: Wed, 29 Nov 2006 20:12:54 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_015A_01C713F2.C0F20B90
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: on-hold certificates in CRLs
  ----- Original Message -----=20
  From: Stephen Kent=20
  To: "Carlos Gonz=E1lez-Cadenas"=20
  Cc: Dr Stephen Henson ; pkix=20
  Sent: Wednesday, November 29, 2006 3:19 AM
  Subject: Re: on-hold certificates in CRLs

  I will disagree with Russ and Stefan on this one.  While we ought not =
create standards that disenfranchise legitimate uses of the technology, =
we also have no obligation to condone practices that externalize costs, =
i.e., create undue burdens on some parties to make life easier for =
others.

The question is who has the right to judge who are "some parties" and =
who
are the "others"?

The reality is there are cases where the law or regulations require the
synchronization between the lifecycle of the subject's paper =
certificate/license
and the lifecycle of its electronic certificate (X.509 certificate). =
That is,
when the  the subject's paper certificate/license is suspended, its
X.509 certificate is required to be suspended simultaneously. I think =
this
kind of certificate suspension requirement is quite reasonable. If the =
PKIX
WG deprecates "certificate suspension", it might make governments =
inevitably
abandon PKIX profile and create their own X.509 certificate profiles. =
This
is not good for the interoperability.

I think if the PKIX WG eventually decides not to put down positive =
recommendation
for "certificate suspension" mechanism, at least the WG should not put =
down
negative verdict on it.

Wen-Cheng Wang
------=_NextPart_000_015A_01C713F2.C0F20B90
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: on-hold certificates in CRLs</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.2995" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;; font-color: black"><B>From:</B>=20
  <A title=[email-masked] href=3D"mailto:[email-masked]">Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>To:</B> =
<A title=[email-masked]=20
  href=3D"mailto:[email-masked]">"Carlos Gonz=E1lez-Cadenas"</A> =
</DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>Cc:</B> =
<A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">Dr Stephen =
Henson</A> ; <A=20
  title=[email-masked] href=3D"mailto:[email-masked]">pkix</A> =
</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Sent:</B> Wednesday, November 29, =
2006 3:19=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Subject:</B> Re: on-hold =
certificates in=20
  CRLs</DIV>
  <DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636; color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#000000>I will disagree with Russ and Stefan on =
this=20
  one.&nbsp; While we ought not create standards that disenfranchise =
legitimate=20
  uses of the technology, we also have no obligation to condone =
practices that=20
  externalize costs, i.e., create undue burdens on some parties to make =
life=20
  easier for others.</FONT></DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr>The question is who has the right to judge who are "some =
parties"=20
and who</DIV>
<DIV dir=3Dltr>are the "others"?</DIV>
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr>The reality is there are cases&nbsp;where the law or =
regulations=20
require the</DIV>
<DIV dir=3Dltr>synchronization between the lifecycle of the subject's =
paper=20
certificate/license</DIV>
<DIV dir=3Dltr>and the lifecycle of its electronic certificate (X.509=20
certificate). That is,</DIV>
<DIV dir=3Dltr>when the&nbsp; the subject's paper certificate/license is =

suspended, its</DIV>
<DIV dir=3Dltr>X.509 certificate is required to be suspended =
simultaneously. I=20
think this</DIV>
<DIV dir=3Dltr>kind of certificate suspension requirement is quite =
reasonable. If=20
the PKIX</DIV>
<DIV dir=3Dltr>WG deprecates&nbsp;"certificate suspension", =
it&nbsp;might make=20
governments inevitably</DIV>
<DIV dir=3Dltr>abandon PKIX profile and create their own X.509 =
certificate=20
profiles. This</DIV>
<DIV dir=3Dltr>is not good for the interoperability.</DIV>
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr>I think if the PKIX WG eventually decides not to&nbsp;put =
down=20
positive recommendation</DIV>
<DIV dir=3Dltr>for "certificate suspension" mechanism, at least&nbsp;the =

WG&nbsp;should not put down</DIV>
<DIV dir=3Dltr>negative verdict on it.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>Wen-Cheng Wang</DIV></BODY></HTML>

------=_NextPart_000_015A_01C713F2.C0F20B90--

Date: Wed, 29 Nov 2006 10:08:18 +0100
From: "Denis Pinkas" <[email-masked]>
To: "pkix" <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

This is a multi-part message in MIME format.

--=====003_Dragon506650450826_=====
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="iso-8859-1"

Carlos,

I concur with you when you say " I always felt that some text that clarified how to deal with suspension was missing".
The text from X.509 is not much better either. :-(

You mention three supported cases, but you only deal with cases a) and b).  :-)
In fact, there are many cases to consider:

a) whether the certificate is a leaf certificate, or a CA certificate

b) when it is a leaf certificate, whether the certificate is used for :

        -  authentication purposes (which means real-time verification), or 
        -  non-repudiation purposes (which means verification in the past).

c) whether at the end of the suspension period, the certificate is definitively revoked or is said to be valid.  

If you have some time available, it would be useful to first address cases b) and c) and say whether it makes a difference 
if the suspension state starts at the beginning of the validity period of the certificate or at a later time. 

Denis

In my opinion the on-hold status makes sense in many concrete cases all of you have been discussing before. Many CAs (I speak for what I've seen here in Spain) also support certificate suspension, and that's included in their CPSs. 

It is technically possible to determine with a precision near to zero when a signature was created (as you said in some emails there's plenty of published material about that matter), so it's necessary to know the status of the certificate in a point of time. 

The problem now is that 

1) we don't have a common view about what "on-hold" means (in this mail thread some people argue that the key should not be used during the on-hold period and other people argue that the key may be used). 

2) it's not clear how to bring certificate suspension into the practice

Regarding 2) I see that a common practice about how to  do certificate suspension described in 3280bis would be very helpful. In my opinion there should be three supported cases 

a) a certificate suspended (on-hold) that is finally revoked, that means that the CA first revoke the certificate in instant t1 with the on-hold cause, and after doing some investigations or whatever finally revokes the certificate in instant t2 with another cause different from on-hold ( i.e. key compromise, ...) (note that it will be very useful to include an invalidity date extension pointing to t1 or to the time it's known the certificate should be considered as invalid). 

Relying parties validating the certificate between t1 and t2 will see the certificate on-hold (I see here that using the hold instruction code can make happy people with different interpretations for what means on-hold, that is, the CA can inform with the hold instruction that the certificate is to be rejected, possibly solving the problems found in 1) ) 
Relying parties validating the certificate after t2 will see the certificate revoked (everything should work as usual)

b) a certificate suspended (on-hold) that is finally determined valid, that means that the CA first revoke the certificate in instant t3 with the on-hold cause, and after doing some investigations or whatever finally determines that the certificate should keep valid, therefore including a removeFromCRL in t4 (if the CA is issuing deltas) and eliminating all the information regarding this certificate in the full CRL issued in t5 

Relying parties validating the certificate between t3 and t4 will see the certificate on-hold (I see here that using the hold instruction code can make happy people with different interpretations for what means on-hold, that is, the CA can inform with the hold instruction that the certificate is to be rejected, possibly solving the problems found in 1))
Relying parties validating the certificate after t4 should determine that the certificate is valid (and in this case the information that the certificate was on hold it's not longer needed as you said). 

I don't know if I'm missing something important, but as an implementer I always felt that some text that clarified how to deal with suspension was missing: I guessed and interpreted how to do it. I think we have a gold opportunity now to fix this issue in 3280bis (possibly 3280bisbis will take many years). 

I offer myself to help in what you consider is the best solution (producing text for 3280bis, creating informative material, ....).

Opinions?

Best regards,

Carlos

On 11/28/06, Dr Stephen Henson <[email-masked]> wrote:

Wen-Cheng Wang wrote:
>
>
> You may argue that no matter how close between the time in the time-stamp
> and the signing time claimed by the signer, risk still exists. If so,
> you should
> consider add a "content time-stamp" in addition to the "signature
> time-stamp".

Yes I'd argue that. In some cases (S/MIME signing time attribute for
example) an attacker could generate a message with an arbitrary signing 
time. In this case they could claim some time in the future after the
hold status is expected to be lifted.

> The signing sequence will be as the following:
>    Step 1. Get a trusted time-stamp of the message content 
>    Step 2. Sign the message
>    Step 3. Get a trusted time-stamp of the signature
> Since the message must be signed between the time of the content time-stamp
> was generated and the time of the signature time-stamp was generated, the 
> verifier can certainly be aware of the period in which the message is
> signed.
>
> Therefore, it is actually possible to reliably determine the time (in
> the regard of
> the agreed signature policy) or the "period" the signature was made. 
>

Yes that would work assuming that "message" in Step 2, is the message
content with time stamp. Signing the content time stamp would have the
same result.

IMHO if we are not going to deprecate the on-hold status we at least 
need some text to indicate the issues involved.

Steve.
--
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

--=====003_Dragon506650450826_=====
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD>
<BODY>
<DIV>Carlos,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I concur with you when you say " I always felt that some text that 
clarified how to deal with suspension was missing".</DIV>
<DIV>The text from X.509 is not much better either. :-(</DIV>
<DIV>&nbsp;</DIV>
<DIV>You mention three supported cases, but you only deal with cases a) and 
b).&nbsp; :-)</DIV>
<DIV>In fact, there are many cases to consider:</DIV>
<DIV>&nbsp;</DIV>
<DIV>a) whether the certificate is a leaf certificate, or a CA certificate</DIV>
<DIV>&nbsp;</DIV>
<DIV>b) when it&nbsp;is a leaf certificate, whether the certificate is used for 
:</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp; authentication purposes 
(which means real-time verification), or 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - &nbsp;non-repudiation purposes 
(which means verification in the past).</DIV>
<DIV>&nbsp;</DIV>
<DIV>c) whether at the end of the suspension period, the certificate is 
definitively revoked or is said to be valid.&nbsp;&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>If you have some time available, it would be useful to first 
address&nbsp;cases b) and c) and say whether&nbsp;it makes a difference 
<DIV>if the&nbsp;suspension state starts at the beginning of the validity period 
of the certificate or at a later time. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
In my opinion the on-hold status makes sense in many concrete cases all of you 
have been discussing before. Many CAs (I speak for what I've seen here in Spain) 
also support certificate suspension, and that's included in their CPSs. 
<BR><BR>It is technically possible to determine with a precision near to zero 
when a signature was created (as you said in some emails there's plenty of 
published material about that matter), so it's necessary to know the status of 
the certificate in a point of time. <BR><BR>The problem now is that <BR><BR>1) 
we don't have a common view about what "on-hold" means (in this mail thread some 
people argue that the key should not be used during the on-hold period and other 
people argue that the key may be used). <BR><BR>2) it's not clear how to bring 
certificate suspension into the practice<BR><BR>Regarding 2) I see that a common 
practice about how to&nbsp; do certificate suspension described in 3280bis would 
be very helpful. In my opinion there should be three supported cases <BR><BR>a) 
a certificate suspended (on-hold) that is finally revoked, that means that the 
CA first revoke the certificate in instant t1 with the on-hold cause, and after 
doing some investigations or whatever finally revokes the certificate in instant 
t2 with another cause different from on-hold ( i.e. key compromise, ...) (note 
that it will be very useful to include an invalidity date extension pointing to 
t1 or to the time it's known the certificate should be considered as invalid). 
<BR></DIV>
<UL>
  <LI>Relying parties validating the certificate between t1 and t2 will see the 
  certificate on-hold (I see here that using the hold instruction code can make 
  happy people with different interpretations for what means on-hold, that is, 
  the CA can inform with the hold instruction that the certificate is to be 
  rejected, possibly solving the problems found in 1) ) 
  <LI>Relying parties validating the certificate after t2 will see the 
  certificate revoked (everything should work as usual)</LI></UL><BR>b) a 
certificate suspended (on-hold) that is finally determined valid, that means 
that the CA first revoke the certificate in instant t3 with the on-hold cause, 
and after doing some investigations or whatever finally determines that the 
certificate should keep valid, therefore including a removeFromCRL in t4 (if the 
CA is issuing deltas) and eliminating all the information regarding this 
certificate in the full CRL issued in t5 <BR><BR>
<UL>
  <LI>Relying parties validating the certificate between t3 and t4 will see the 
  certificate on-hold (I see here that using the hold instruction code can make 
  happy people with different interpretations for what means on-hold, that is, 
  the CA can inform with the hold instruction that the certificate is to be 
  rejected, possibly solving the problems found in 1))
  <LI>Relying parties validating the certificate after t4 should determine that 
  the certificate is valid (and in this case the information that the 
  certificate was on hold it's not longer needed as you said). <BR></LI></UL><BR>I 
don't know if I'm missing something important, but as an implementer I always 
felt that some text that clarified how to deal with suspension was missing: I 
guessed and interpreted how to do it. I think we have a gold opportunity now to 
fix this issue in 3280bis (possibly 3280bisbis will take many years). <BR><BR>I 
offer myself to help in what you consider is the best solution (producing text 
for 3280bis, creating informative material, ....).<BR><BR>Opinions?<BR><BR>Best 
regards,<BR><BR>Carlos<BR><BR>
<DIV><SPAN class=gmail_quote>On 11/28/06, <B class=gmail_sendername>Dr Stephen 
Henson</B> &lt;<A 
href="mailto:[email-masked]">[email-masked]</A>&gt; 
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote 
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>Wen-Cheng 
  Wang wrote:<BR>&gt;<BR>&gt;<BR>&gt; You may argue that no matter how close 
  between the time in the time-stamp<BR>&gt; and the signing time claimed by the 
  signer, risk still exists. If so,<BR>&gt; you should<BR>&gt; consider add a 
  "content time-stamp" in addition to the "signature<BR>&gt; 
  time-stamp".<BR><BR>Yes I'd argue that. In some cases (S/MIME signing time 
  attribute for<BR>example) an attacker could generate a message with an 
  arbitrary signing <BR>time. In this case they could claim some time in the 
  future after the<BR>hold status is expected to be lifted.<BR><BR>&gt; The 
  signing sequence will be as the following:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 
  1. Get a trusted time-stamp of the message content 
  <BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 2. Sign the 
  message<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 3. Get a trusted time-stamp of the 
  signature<BR>&gt; Since the message must be signed between the time of the 
  content time-stamp<BR>&gt; was generated and the time of the signature 
  time-stamp was generated, the <BR>&gt; verifier can certainly be aware of the 
  period in which the message is<BR>&gt; signed.<BR>&gt;<BR>&gt; Therefore, it 
  is actually possible to reliably determine the time (in<BR>&gt; the regard 
  of<BR>&gt; the agreed signature policy) or the "period" the signature was 
  made. <BR>&gt;<BR><BR>Yes that would work assuming that "message" in Step 2, 
  is the message<BR>content with time stamp. Signing the content time stamp 
  would have the<BR>same result.<BR><BR>IMHO if we are not going to deprecate 
  the on-hold status we at least <BR>need some text to indicate the issues 
  involved.<BR><BR>Steve.<BR>--<BR>Dr Stephen N. Henson.<BR>Core developer of 
  the&nbsp;&nbsp; OpenSSL project: <A 
  href="http://www.openssl.org/">http://www.openssl.org/</A><BR>Freelance 
  consultant see: <A 
  href="http://www.drh-consultancy.co.uk/">http://www.drh-consultancy.co.uk/</A><BR>Email: 
  <A 
  href="mailto:[email-masked]">[email-masked]</A>, 
  PGP key: via homepage.<BR><BR></BLOCKQUOTE></DIV><BR>
<HR>
</BODY></HTML>

--=====003_Dragon506650450826_=====--

Content-class: urn:content-classes:message
Subject: RE: on-hold certificates in CRLs
Date: Tue, 28 Nov 2006 13:45:52 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, =?iso-8859-1?Q?=22Carlos_Gonz=E1lez-Cadenas=22?= <[email-masked]>
Cc: "Dr Stephen Henson" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

I sorta agree with Steve here.=20
=20
I don't think that there is much prospect of using the suspension, =
on-hold or any other cert status other than 'good' or 'bad'. Once you =
advertise the status of the certificate as being suspect you might as =
well issue a fresh cert than money about trying to retract the =
suspension status.=20
=20
And before you ask, no I would not use the features that would create =
the desire to do this either.
=20
=20
If you are only going to operate in an OCSP world there might be a point =
to quasi-revocation. But if you decide to only live in that world you =
might as well get rid of the certs altogether and go back to Diffie's =
original idea of a directory for keys as XKMS does.
=20

________________________________

	From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Stephen Kent
	Sent: Tuesday, November 28, 2006 2:20 PM
	To: "Carlos Gonz=E1lez-Cadenas"
	Cc: Dr Stephen Henson; pkix
	Subject: Re: on-hold certificates in CRLs
=09
=09
	At 3:34 PM +0100 11/28/06, Carlos Gonz=E1lez-Cadenas wrote:

		...
		The problem now is that
	=09
		1) we don't have a common view about what "on-hold" means (in this =
mail thread some people argue that the key should not be used during the =
on-hold period and other people argue that the key may be used).

	right, and that means that CAs who have decided to use this "feature" =
of X.509 are imposing a burden on all RPs because of this ambiguity.

		2) it's not clear how to bring certificate suspension into the =
practice

	how about not at all!

	I am not a fan of "hold" as a cert status, for example:

	        - absent a common understanding of what hold means by itself, =
one needs to use the hold instruction code, which is itself a mess for =
automated processing, e.g., 3280 says "Conforming applications which =
encounter an id-holdinstruction-callissuer MUST call the certificate =
issuer or reject the certificate." Give me a break! Call the issuer OR =
reject the cert.  This is hardly useful guidance for software.
=09
=09
	        - and 3280 notes deprecates use of the silly "none" =
instruction. Frankly, this is a perfect example of a committee-designed =
extension that needed adult supervision!
=09
=09
=09
=09
	Presumably the best example provided so far is the use of hold to state =
that an issued and valid cert is NOT yet "in play" and thus for NR =
purposes, signatures that are created while the cert is on hold are not =
reliable.  But, the same effect could have been achieved by distributing =
a smart card with a key pair and a cert template, and have the cert =
really issued as a side effect of the user executing some POP protocol.  =
It sounds like some CAs decided that use of hold was an easy way to =
address a valid concern in a way that makes life easy for them, but =
harder for all RPs.=20
=09
=09
	I will disagree with Russ and Stefan on this one.  While we ought not =
create standards that disenfranchise legitimate uses of the technology, =
we also have no obligation to condone practices that externalize costs, =
i.e., create undue burdens on some parties to make life easier for =
others.
=09
=09
	Steve

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: on-hold certificates in CRLs</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I sorta agree with Steve here. =
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I don't think that there is much prospect of =
using the=20
suspension, on-hold or any other cert status other than 'good' or 'bad'. =
Once=20
you advertise the status of the certificate as being suspect you might =
as well=20
issue a fresh cert than money about trying to retract the suspension =
status.=20
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>And before you ask, no I would not use the =
features that=20
would create the desire to do this either.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>If you are only going to operate in an OCSP =
world there=20
might be a point to quasi-revocation. But if you decide to only live in =
that=20
world you might as well get rid of the certs altogether and go back to =
Diffie's=20
original idea of a directory for keys as XKMS does.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =

  [mailto:[email-masked]] <B>On Behalf Of </B>Stephen=20
  Kent<BR><B>Sent:</B> Tuesday, November 28, 2006 2:20 PM<BR><B>To:</B> =
"Carlos=20
  Gonz=E1lez-Cadenas"<BR><B>Cc:</B> Dr Stephen Henson; =
pkix<BR><B>Subject:</B> Re:=20
  on-hold certificates in CRLs<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>At 3:34 PM +0100 11/28/06, Carlos Gonz=E1lez-Cadenas wrote:</DIV>
  <BLOCKQUOTE cite=3D"" type=3D"cite">...<BR>The problem now is =
that<BR><BR>1) we=20
    don't have a common view about what "on-hold" means (in this mail =
thread=20
    some people argue that the key should not be used during the on-hold =
period=20
    and other people argue that the key may be used).</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>right, and that means that CAs who have decided to use this =
"feature" of=20
  X.509 are imposing a burden on all RPs because of this =
ambiguity.</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE cite=3D"" type=3D"cite">2) it's not clear how to bring =
certificate=20
    suspension into the practice</BLOCKQUOTE>
  <DIV><BR>how about not at all!</DIV>
  <DIV><BR></DIV>
  <DIV>I am not a fan of "hold" as a cert status, for example:</DIV>
  <DIV><BR></DIV>
  <DIV><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </X-TAB>- =
absent a=20
  common understanding of what hold means by itself, one needs to use =
the hold=20
  instruction code, which is itself a mess for automated processing, =
e.g., 3280=20
  says "<FONT face=3DCourier color=3D#000000 size=3D+2>Conforming =
applications which=20
  encounter an id-holdinstruction-callissuer MUST call the certificate =
issuer or=20
  reject the certificate."</FONT><FONT color=3D#000000> Give me a break! =
Call the=20
  issuer OR reject the cert.&nbsp; This is hardly useful guidance for=20
  software.</FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT =
color=3D#000000><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </X-TAB>- and 3280 notes deprecates use of the silly "none" =
instruction.=20
  Frankly, this is a perfect example of a committee-designed extension =
that=20
  needed adult supervision!</FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>Presumably the best example provided so far =
is the=20
  use of hold to state that an issued and valid cert is NOT yet "in =
play" and=20
  thus for NR purposes, signatures that are created while the cert is on =
hold=20
  are not reliable.&nbsp; But, the same effect could have been achieved =
by=20
  distributing a smart card with a key pair and a cert template, and =
have the=20
  cert really issued as a side effect of the user executing some POP=20
  protocol.&nbsp; It sounds like some CAs decided that use of hold was =
an easy=20
  way to address a valid concern in a way that makes life easy for them, =
but=20
  harder for all RPs.&nbsp;</FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>I will disagree with Russ and Stefan on =
this=20
  one.&nbsp; While we ought not create standards that disenfranchise =
legitimate=20
  uses of the technology, we also have no obligation to condone =
practices that=20
  externalize costs, i.e., create undue burdens on some parties to make =
life=20
  easier for others.</FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>Steve</FONT></DIV>
  <DIV><BR></DIV>
  <DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C71336.9A2E4D17--

Date: Tue, 28 Nov 2006 14:19:40 -0500
To: =?iso-8859-1?Q?=22Carlos_Gonz=E1lez=2DCadenas=22?=  <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Cc: "Dr Stephen Henson" <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

--============_-1047380910==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

At 3:34 PM +0100 11/28/06, Carlos Gonz=E1lez-Cadenas wrote:
>...
>The problem now is that
>
>1) we don't have a common view about what=20
>"on-hold" means (in this mail thread some people=20
>argue that the key should not be used during the=20
>on-hold period and other people argue that the=20
>key may be used).

right, and that means that CAs who have decided=20
to use this "feature" of X.509 are imposing a=20
burden on all RPs because of this ambiguity.

>2) it's not clear how to bring certificate suspension into the practice

how about not at all!

I am not a fan of "hold" as a cert status, for example:

	- absent a common understanding of what=20
hold means by itself, one needs to use the hold=20
instruction code, which is itself a mess for=20
automated processing, e.g., 3280 says "Conforming=20
applications which encounter an=20
id-holdinstruction-callissuer MUST call the=20
certificate issuer or reject the certificate."=20
Give me a break! Call the issuer OR reject the=20
cert.  This is hardly useful guidance for=20
software.

	- and 3280 notes deprecates use of the=20
silly "none" instruction. Frankly, this is a=20
perfect example of a committee-designed extension=20
that needed adult supervision!

Presumably the best example provided so far is=20
the use of hold to state that an issued and valid=20
cert is NOT yet "in play" and thus for NR=20
purposes, signatures that are created while the=20
cert is on hold are not reliable.  But, the same=20
effect could have been achieved by distributing a=20
smart card with a key pair and a cert template,=20
and have the cert really issued as a side effect=20
of the user executing some POP protocol.  It=20
sounds like some CAs decided that use of hold was=20
an easy way to address a valid concern in a way=20
that makes life easy for them, but harder for all=20
RPs. 

I will disagree with Russ and Stefan on this one.=20
While we ought not create standards that=20
disenfranchise legitimate uses of the technology,=20
we also have no obligation to condone practices=20
that externalize costs, i.e., create undue=20
burdens on some parties to make life easier for=20
others.

Steve

--============_-1047380910==_ma============
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D"text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: on-hold certificates in
CRLs</title></head><body>
<div>At 3:34 PM +0100 11/28/06, Carlos Gonz=E1lez-Cadenas wrote:</div>
<blockquote type=3D"cite" cite>...<br>
The problem now is that<br>
<br>
1) we don't have a common view about what &quot;on-hold&quot; means
(in this mail thread some people argue that the key should not be used
during the on-hold period and other people argue that the key may be
used).</blockquote>
<div><br></div>
<div>right, and that means that CAs who have decided to use this
&quot;feature&quot; of X.509 are imposing a burden on all RPs because
of this ambiguity.</div>
<div><br></div>
<blockquote type=3D"cite" cite>2) it's not clear how to bring
certificate suspension into the practice</blockquote>
<div><br>
how about not at all!</div>
<div><br></div>
<div>I am not a fan of &quot;hold&quot; as a cert status, for
example:</div>
<div><br></div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>-
absent a common understanding of what hold means by itself, one needs
to use the hold instruction code, which is itself a mess for automated
processing, e.g., 3280 says &quot;<font face=3D"Courier" size=3D"+2"
color=3D"#000000">Conforming applications which encounter an
id-holdinstruction-callissuer MUST call the certificate issuer or
reject the certificate.&quot;</font><font color=3D"#000000"> Give me a
break! Call the issuer OR reject the cert.&nbsp; This is hardly useful
guidance for software.</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font
color=3D"#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>- and 3280 notes deprecates use of the silly &quot;none&quot;
instruction. Frankly, this is a perfect example of a
committee-designed extension that needed adult
supervision!</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">Presumably the best example provided so far
is the use of hold to state that an issued and valid cert is NOT yet
&quot;in play&quot; and thus for NR purposes, signatures that are
created while the cert is on hold are not reliable.&nbsp; But, the
same effect could have been achieved by distributing a smart card with
a key pair and a cert template, and have the cert really issued as a
side effect of the user executing some POP protocol.&nbsp; It sounds
like some CAs decided that use of hold was an easy way to address a
valid concern in a way that makes life easy for them, but harder for
all RPs.&nbsp;</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">I will disagree with Russ and Stefan on
this one.&nbsp; While we ought not create standards that
disenfranchise legitimate uses of the technology, we also have no
obligation to condone practices that externalize costs, i.e., create
undue burdens on some parties to make life easier for
others.</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">Steve</font></div>
<div><br></div>
<div><br></div>
</body>
</html>
--============_-1047380910==_ma============--

Date: Tue, 28 Nov 2006 16:13:38 +0100
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: pkix <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Stefan Santesson wrote:
> 2) RFC3280bis will never be perfect. We will never stop finding things that we may want
> to change or update. It's time to draw the line and let this document proceed. Let's
> focus on fixing errors if we find them but avoid "improvements" as much as possible.
> It's time to ship an update of RFC 3280.
> 
> In time there will be an rfc3280bisbis

I agree with this vision. Unfortunately it seems that the rfc3280 is probably one
of those documents which requires periodic updates, and this does not map well into
IETF RFCs.

I personally think, anyway, that a specific text should be added in this case to
the RFC, in particular we should at least make it clear that:

<< The `on hold' status does not affect later verification of legitimacy of
certificate usage in case the certificate is later removed from CRLs. Therefore
the `on hold' status does not provide a reliable way of suspending the usage of
a certificate in a specific period of time. >>

Providing also an explicit reference to the card/token suspension example as being
a bad interpretation/practice that should be avoided could also help (and as it is
quite a common practice, it is useful to explicitly state that it should be avoided
because it *does not* prevent the certificate to be used!).

-- 

Best Regards,

	Massimiliano Pala

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

Dartmouth Computer Science Dept
PKI/Trust
--o------------------------------------------------------------------------

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

--------------ms040905010707030005010506--

Date: Tue, 28 Nov 2006 15:34:38 +0100
From: "=?UTF-8?Q?Carlos_Gonz=C3=A1lez-Cadenas?=" <[email-masked]>
To: "Dr Stephen Henson" <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Cc: pkix <[email-masked]>
Sender: [email-masked]

------=_Part_8774_10581603.1164724478194
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

In my opinion the on-hold status makes sense in many concrete cases all of
you have been discussing before. Many CAs (I speak for what I've seen here
in Spain) also support certificate suspension, and that's included in their
CPSs.

It is technically possible to determine with a precision near to zero when a
signature was created (as you said in some emails there's plenty of
published material about that matter), so it's necessary to know the status
of the certificate in a point of time.

The problem now is that

1) we don't have a common view about what "on-hold" means (in this mail
thread some people argue that the key should not be used during the on-hold
period and other people argue that the key may be used).

2) it's not clear how to bring certificate suspension into the practice

Regarding 2) I see that a common practice about how to  do certificate
suspension described in 3280bis would be very helpful. In my opinion there
should be three supported cases

a) a certificate suspended (on-hold) that is finally revoked, that means
that the CA first revoke the certificate in instant t1 with the on-hold
cause, and after doing some investigations or whatever finally revokes the
certificate in instant t2 with another cause different from on-hold (i.e.
key compromise, ...) (note that it will be very useful to include an
invalidity date extension pointing to t1 or to the time it's known the
certificate should be considered as invalid).

   - Relying parties validating the certificate between t1 and t2 will
   see the certificate on-hold (I see here that using the hold instruction code
   can make happy people with different interpretations for what means on-hold,
   that is, the CA can inform with the hold instruction that the certificate is
   to be rejected, possibly solving the problems found in 1) )
   - Relying parties validating the certificate after t2 will see the
   certificate revoked (everything should work as usual)

b) a certificate suspended (on-hold) that is finally determined valid, that
means that the CA first revoke the certificate in instant t3 with the
on-hold cause, and after doing some investigations or whatever finally
determines that the certificate should keep valid, therefore including a
removeFromCRL in t4 (if the CA is issuing deltas) and eliminating all the
information regarding this certificate in the full CRL issued in t5

   - Relying parties validating the certificate between t3 and t4 will
   see the certificate on-hold (I see here that using the hold instruction code
   can make happy people with different interpretations for what means on-hold,
   that is, the CA can inform with the hold instruction that the certificate is
   to be rejected, possibly solving the problems found in 1))
   - Relying parties validating the certificate after t4 should determine
   that the certificate is valid (and in this case the information that the
   certificate was on hold it's not longer needed as you said).

I don't know if I'm missing something important, but as an implementer I
always felt that some text that clarified how to deal with suspension was
missing: I guessed and interpreted how to do it. I think we have a gold
opportunity now to fix this issue in 3280bis (possibly 3280bisbis will take
many years).

I offer myself to help in what you consider is the best solution (producing
text for 3280bis, creating informative material, ....).

Opinions?

Best regards,

Carlos

On 11/28/06, Dr Stephen Henson <[email-masked]> wrote:
>
>
> Wen-Cheng Wang wrote:
> >
> >
> > You may argue that no matter how close between the time in the
> time-stamp
> > and the signing time claimed by the signer, risk still exists. If so,
> > you should
> > consider add a "content time-stamp" in addition to the "signature
> > time-stamp".
>
> Yes I'd argue that. In some cases (S/MIME signing time attribute for
> example) an attacker could generate a message with an arbitrary signing
> time. In this case they could claim some time in the future after the
> hold status is expected to be lifted.
>
> > The signing sequence will be as the following:
> >    Step 1. Get a trusted time-stamp of the message content
> >    Step 2. Sign the message
> >    Step 3. Get a trusted time-stamp of the signature
> > Since the message must be signed between the time of the content
> time-stamp
> > was generated and the time of the signature time-stamp was generated,
> the
> > verifier can certainly be aware of the period in which the message is
> > signed.
> >
> > Therefore, it is actually possible to reliably determine the time (in
> > the regard of
> > the agreed signature policy) or the "period" the signature was made.
> >
>
> Yes that would work assuming that "message" in Step 2, is the message
> content with time stamp. Signing the content time stamp would have the
> same result.
>
> IMHO if we are not going to deprecate the on-hold status we at least
> need some text to indicate the issues involved.
>
> Steve.
> --
> Dr Stephen N. Henson.
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Freelance consultant see: http://www.drh-consultancy.co.uk/
> Email: [email-masked], PGP key: via homepage.
>
>

------=_Part_8774_10581603.1164724478194
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

In my opinion the on-hold status makes sense in many concrete cases all of you have been discussing before. Many CAs (I speak for what I've seen here in Spain) also support certificate suspension, and that's included in their CPSs. 
<br><br>It is technically possible to determine with a precision near to zero when a signature was created (as you said in some emails there's plenty of published material about that matter), so it's necessary to know the status of the certificate in a point of time.
<br><br>The problem now is that <br><br>1) we don't have a common view about what &quot;on-hold&quot; means (in this mail thread some people argue that the key should not be used during the on-hold period and other people argue that the key may be used). 
<br><br>2) it's not clear how to bring certificate suspension into the practice<br><br>Regarding 2) I see that a common practice about how to&nbsp; do certificate suspension described in 3280bis would be very helpful. In my opinion there should be three supported cases
<br><br>a) a certificate suspended (on-hold) that is finally revoked, that means that the CA first revoke the certificate in instant t1 with the on-hold cause, and after doing some investigations or whatever finally revokes the certificate in instant t2 with another cause different from on-hold (
i.e. key compromise, ...) (note that it will be very useful to include an invalidity date extension pointing to t1 or to the time it's known the certificate should be considered as invalid). <br><ul><li>Relying parties validating the certificate between t1 and t2 will see the certificate on-hold (I see here that using the hold instruction code can make happy people with different interpretations for what means on-hold, that is, the CA can inform with the hold instruction that the certificate is to be rejected, possibly solving the problems found in 1) )
</li><li>Relying parties validating the certificate after t2 will see the certificate revoked (everything should work as usual)</li></ul><br>b) a certificate suspended (on-hold) that is finally determined valid, that means that the CA first revoke the certificate in instant t3 with the on-hold cause, and after doing some investigations or whatever finally determines that the certificate should keep valid, therefore including a removeFromCRL in t4 (if the CA is issuing deltas) and eliminating all the information regarding this certificate in the full CRL issued in t5
<br><br><ul><li>Relying parties validating the certificate between t3 and t4 will see the certificate on-hold (I see here that using the hold
instruction code can make happy people with different interpretations
for what means on-hold, that is, the CA can inform with the hold
instruction that the certificate is to be rejected, possibly solving the problems found in 1))</li><li>Relying parties validating the certificate after t4 should determine that the certificate is valid (and in this case the information that the certificate was on hold it's not longer needed as you said).
<br></li></ul><br>I don't know if I'm missing something important, but as an implementer I always felt that some text that clarified how to deal with suspension was missing: I guessed and interpreted how to do it. I think we have a gold opportunity now to fix this issue in 3280bis (possibly 3280bisbis will take many years).
<br><br>I offer myself to help in what you consider is the best solution (producing text for  3280bis, creating informative material, ....).<br><br>Opinions?<br><br>Best regards,<br><br>Carlos<br><br><div><span class="gmail_quote">
On 11/28/06, <b class="gmail_sendername">Dr Stephen Henson</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Wen-Cheng Wang wrote:<br>&gt;<br>&gt;<br>&gt; You may argue that no matter how close between the time in the time-stamp<br>&gt; and the signing time claimed by the signer, risk still exists. If so,<br>&gt; you should<br>
&gt; consider add a &quot;content time-stamp&quot; in addition to the &quot;signature<br>&gt; time-stamp&quot;.<br><br>Yes I'd argue that. In some cases (S/MIME signing time attribute for<br>example) an attacker could generate a message with an arbitrary signing
<br>time. In this case they could claim some time in the future after the<br>hold status is expected to be lifted.<br><br>&gt; The signing sequence will be as the following:<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 1. Get a trusted time-stamp of the message content
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 2. Sign the message<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 3. Get a trusted time-stamp of the signature<br>&gt; Since the message must be signed between the time of the content time-stamp<br>&gt; was generated and the time of the signature time-stamp was generated, the
<br>&gt; verifier can certainly be aware of the period in which the message is<br>&gt; signed.<br>&gt;<br>&gt; Therefore, it is actually possible to reliably determine the time (in<br>&gt; the regard of<br>&gt; the agreed signature policy) or the &quot;period&quot; the signature was made.
<br>&gt;<br><br>Yes that would work assuming that &quot;message&quot; in Step 2, is the message<br>content with time stamp. Signing the content time stamp would have the<br>same result.<br><br>IMHO if we are not going to deprecate the on-hold status we at least
<br>need some text to indicate the issues involved.<br><br>Steve.<br>--<br>Dr Stephen N. Henson.<br>Core developer of the&nbsp;&nbsp; OpenSSL project: <a href="http://www.openssl.org/">http://www.openssl.org/</a><br>Freelance consultant see: 
<a href="http://www.drh-consultancy.co.uk/">http://www.drh-consultancy.co.uk/</a><br>Email: <a href="mailto:[email-masked]">[email-masked]</a>, PGP key: via homepage.<br><br></blockquote></div>
<br>

------=_Part_8774_10581603.1164724478194--

Date: Tue, 28 Nov 2006 12:05:19 +0000
From: Dr Stephen Henson <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

Wen-Cheng Wang wrote:
> 
> 
> You may argue that no matter how close between the time in the time-stamp
> and the signing time claimed by the signer, risk still exists. If so,
> you should
> consider add a "content time-stamp" in addition to the "signature
> time-stamp".

Yes I'd argue that. In some cases (S/MIME signing time attribute for
example) an attacker could generate a message with an arbitrary signing
time. In this case they could claim some time in the future after the
hold status is expected to be lifted.

> The signing sequence will be as the following:
>    Step 1. Get a trusted time-stamp of the message content
>    Step 2. Sign the message
>    Step 3. Get a trusted time-stamp of the signature
> Since the message must be signed between the time of the content time-stamp
> was generated and the time of the signature time-stamp was generated, the
> verifier can certainly be aware of the period in which the message is
> signed.
> 
> Therefore, it is actually possible to reliably determine the time (in
> the regard of
> the agreed signature policy) or the "period" the signature was made.
> 

Yes that would work assuming that "message" in Step 2, is the message
content with time stamp. Signing the content time stamp would have the
same result.

IMHO if we are not going to deprecate the on-hold status we at least
need some text to indicate the issues involved.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>
Subject: AW: on-hold certificates in CRLs
Date: Tue, 28 Nov 2006 12:39:15 +0100
Sender: [email-masked]

> If people are really using it, then we should not pull the 
> rug out from under them.  I do not think this is a great 
> mechanism for the situation that is described, but there are 
> far worse uses that have been discussed.

That's an understandable position. But probably it would be or have been
worthwhile to differentiate between the different uses; currently the number
of interpretations what to use that mechanism for is simply to
heterogeneous, some of them are problematic. We have seen mentioned now:

- on hold for the time of transport of the id card
- on hold for suspected compromise where the info came from unauthenticated
sources
I have heared from ideas to use on hold for a time where e.g. I am not in my
office and cant use the certificate on my office machine (like vacation or
even the weekend). (Don't know if this idea has been implemented though.
Hope not.)
There may be other ideas/uses of that concept. 

Santosh mentioned that "on hold is not overly complex". I agree, the basic
idea isn't. But the different interpretations existing make it maybe not
complex but incompatible or meaningless. What does the "on hold" for
transport buy me? As soon as it is no longer on hold and the firt CRL
without that information issued, this fact is forgotten. What if I now had a
signature created during that time... (If I assume I will never find such a
signature, why place the cert on hold?) 

If this stays in, the usage should be restricted to the working scenarious
only and any legislation prescribing other uses should be fixed.

Peter

From: "Wen-Cheng Wang" <[email-masked]>
To: "Dr Stephen Henson" <[email-masked]>, "pkix" <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Date: Tue, 28 Nov 2006 19:18:06 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

Dr Stephen Henson wrote:
> 
> David A. Cooper wrote:
>> 
>> Other people believe that placing a certificate on hold also places use
>> of the private key on hold and so any signatures generated during the
>> time that the certificate was on hold are not legitimate.  Thus, these
>> people believe that when verifying a signature it is important to know
>> whether the certificate was on hold at the time that the signature was
>> generated, even if the certificate is later removed from hold.  The
>> information included in CRLs issued after the certificate is removed
>> from hold do not include any information that would help to determine
>> whether the certificate was on hold at some point in the past.
>> 
> 
> That's the case I'm uneasy about which I suspect is the case the two
> examples I've seen are intended to cover.
> 
> It should be noted that this assumes that there is a way to reliably
> determine when the signature was made.
> 
> This is not always possible and often one can only say it was made *on
> or before* a certain time (for example the time in a trusted timestamp).
> 
> That doesn't help because the signature might be made during the hold
> period and the timestamp added some time afterwards.
> 
In the area of "Advanced Electronic Signatures" (or so-called long term
electronic signatures by the S/MIME WG), this is called "time-stamp delay".

In section B.8.4 of RFC 3125, it informatively describe requirement of
signature policy related to "time-stamp delay" as follows:

   There will be some delay between the time that a signature is created
   and the time the signer's digital signature is time-stamped.
   However, the longer this elapsed period the greater the risk of the
   signature being invalidated due to compromise or deliberate
   revocation of its private signing key by the signer.  Thus the
   signature policy should specify a maximum acceptable delay between
   the signing time as claimed by the signer and the time included
   within the time-stamp.

And in section 3.8 of RFC 3125, the signatureTimestampDelay field is
defined as follows to allow a signature policy Issuer to specify  the
acceptable "time-stamp delay":
  The signatureTimestampDelay field specifies a maximum acceptable time
   between the signing time and the time at which the signature time-
   stamp, as used to form the ES Time-Stamped, is created for the
   verifier.  If the signature time-stamp is later that the time in the
   signing-time attribute by more than the value given in
   signatureTimestampDelay, the signature must be considered invalid.

The implication is that with the help of a trusted time-stamp close enough
to the signing-time (in the signed attribute) claimed by the signer, the verifier
can assume, in the regard of the agreed signature policy, the message
was really signed at that time.

You may argue that no matter how close between the time in the time-stamp
and the signing time claimed by the signer, risk still exists. If so, you should
consider add a "content time-stamp" in addition to the "signature time-stamp".
The signing sequence will be as the following:
    Step 1. Get a trusted time-stamp of the message content
    Step 2. Sign the message
    Step 3. Get a trusted time-stamp of the signature
Since the message must be signed between the time of the content time-stamp
was generated and the time of the signature time-stamp was generated, the
verifier can certainly be aware of the period in which the message is signed.

Therefore, it is actually possible to reliably determine the time (in the regard of
the agreed signature policy) or the "period" the signature was made.

I am one of the people who believe that placing a certificate on hold also
places use of the private key on hold and so any signature generated
during the time that the certificate was on hold are not legitimate. I also
agree the following Santosh's opinion:
   "As to determination of the certificate status, archiving all CRL (and deltas if
    deltas are produced) give the accurate picture of revocation status modulo
    CRL issuance frequency."

I am aware a case where the signatures generated during the time that the
certificate was on hold are not legitimate. The case is the government issues
X.509 certificates to companies and  by regulation if a company's license
is placed on hold (for example, due to illegal tax evasion) then the company's
X.509 will also be simultaneously placed on hold and the company's digital
signatures will be considered illegitimate until its company license is resumed
(and of course its X.509 certificate will be simultaneously resumed too).

To validate an archived signed data (with long-term signature and timestamps),
we will need a mechanism to validate the signing certificate relative to past
time or period. Currently, the SCVP draft intend to support validate a certificate
relative to past time. (Personally, I think SCVP should also support validate
a certificate relative to past "period".) However, it is unfortunately that the
certificate validation algorithm of RFC 3280 and RFC 3280bis only support
validate a certificate at the "current time". We still lack a standard algorithm to
validate a certificate relative to past time or period.

Wen-Cheng Wang

From: Stefan Santesson <[email-masked]>
To: Russ Housley <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 28 Nov 2006 10:42:18 +0000
Subject: RE: on-hold certificates in CRLs
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

2 things.

1) Some examples of using on-hold seems a bit shaky. For example putting a certificate on-hold until card is delivered does not stop me from signing with the card and use that signature after its status has been restored. I concur that once status has been restored, there is no need to know if it has been on hold.

I'm personally not a big fan of "on hold", but we have a responsibility to not break users of this profile, so deprecating a feature puts great responsibilities on us to determine that we don't break legitimate implementations.

2) RFC3280bis will never be perfect. We will never stop finding things that we may want to change or update. It's time to draw the line and let this document proceed. Let's focus on fixing errors if we find them but avoid "improvements" as much as possible. It's time to ship an update of RFC 3280.

In time there will be an rfc3280bisbis

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 28 november 2006 00:51
> To: [email-masked]
> Subject: Re: on-hold certificates in CRLs
>
>
> Massimiliano:
>
> >>I have come across two real world examples of it being used in
> national
> >>ID schemes. In both of these a certificate is automatically placed
> "on
> >>hold" when the card is manufactured and then made valid when the
> >>recipient has performed some procedure to acknowledge receipt. I
> suspect
> >>that the two I saw are far from isolated examples.
> >
> >I do confirm that some big national CAs (at least in Italy) use the
> `on Hold'
> >status when the card is first "initialized" (and the certificate
> issued)
> >till the user receives the card.
>
> If people are really using it, then we should not pull the rug out
> from under them.  I do not think this is a great mechanism for the
> situation that is described, but there are far worse uses that have
> been discussed.
>
> Russ

From: "Peter Rybar" <[email-masked]>
To: "'pkix'" <[email-masked]>
Cc: "'Dr Stephen Henson'" <[email-masked]>
Subject: RE: on-hold certificates in CRLs
Date: Tue, 28 Nov 2006 11:31:29 +0100
Sender: [email-masked]

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_mail.nbusr.sk-45805-1164709604-0001-2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed mail is in attachment.

--=_mail.nbusr.sk-45805-1164709604-0001-2
Content-Type: message/rfc822; name=" onHoldCertificatesInCRLs.eml"
Content-Disposition: attachment;
	filename=" onHoldCertificatesInCRLs.eml"

Message-ID: <28x11x2006at11x21x10x0DAE>
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: on-hold certificates in CRLs
Date: Tue, 28 Nov 2006 11:21:10 +0100
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="=_mail.nbusr.sk-45805-1164709604-0001-3"
X-Mailer: ELPI

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_mail.nbusr.sk-45805-1164709604-0001-3
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

The status of certificateHold or removeFromCRL is useful only for strictly 
online system, where is no reason to check a history about revocation 
status information.

If certificate is several times in status on hold and removed from hold 
then the verification of qualified electronic signature with trusted 
timestamp is almost impossible. 

That is the reason why the Slovak Act no. 215/2002 Coll. on Electronic 
Signature (qualified certificate and qualified el. signature) does not 
allow removing the certificate from hold. 

Certificate in the CRL (OCSP) can not be found in revocation reason 
certificateHold or removeFromCRL, thus its validity can not be stopped for 
certain period.

IMHO useful recommendation in this RFC: 
"The certificateHold or removeFromCRL status MUST NOT be used by CA except 
CA for strictly On-Line system".

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On 
Behalf Of Dr Stephen Henson
Sent: Tuesday, November 28, 2006 2:32 AM
To: pkix
Subject: Re: on-hold certificates in CRLs

David A. Cooper wrote:
> 
> Other people believe that placing a certificate on hold also places use
> of the private key on hold and so any signatures generated during the
> time that the certificate was on hold are not legitimate.  Thus, these
> people believe that when verifying a signature it is important to know
> whether the certificate was on hold at the time that the signature was
> generated, even if the certificate is later removed from hold.  The
> information included in CRLs issued after the certificate is removed
> from hold do not include any information that would help to determine
> whether the certificate was on hold at some point in the past.
> 

That's the case I'm uneasy about which I suspect is the case the two
examples I've seen are intended to cover.

It should be noted that this assumes that there is a way to reliably
determine when the signature was made.

This is not always possible and often one can only say it was made *on
or before* a certain time (for example the time in a trusted timestamp).

That doesn't help because the signature might be made during the hold
period and the timestamp added some time afterwards.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

--=_mail.nbusr.sk-45805-1164709604-0001-3
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

--=_mail.nbusr.sk-45805-1164709604-0001-3--

--=_mail.nbusr.sk-45805-1164709604-0001-2--

Date: Tue, 28 Nov 2006 10:59:16 +0100
From: =?ISO-8859-1?Q?R=F3bert_Kisteleki?= <[email-masked]>
Organization: RIPE NCC
To: [email-masked]
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

Russ Housley wrote:
> 
> Massimiliano:
> 
>>> I have come across two real world examples of it being used in national
>>> ID schemes. In both of these a certificate is automatically placed "on
>>> hold" when the card is manufactured and then made valid when the
>>> recipient has performed some procedure to acknowledge receipt. I suspect
>>> that the two I saw are far from isolated examples.
>>
>> I do confirm that some big national CAs (at least in Italy) use the 
>> `on Hold'
>> status when the card is first "initialized" (and the certificate issued)
>> till the user receives the card.
> 
> If people are really using it, then we should not pull the rug out from 
> under them.  I do not think this is a great mechanism for the situation 
> that is described, but there are far worse uses that have been discussed.
> 
> Russ

I have to agree with Massimiliano, in some countries the legislation (!) 
enables/forces the national CAs to use the on hold status. Besides this, 
whole business processes have been built upon this feature.

I'm not saying that on hold is a good/bad feature, merely that it is being 
used, and even if you deprecate it, it will take years to root it out from 
practice.

Robert

From: "specific" <[email-masked]>
To: [email-masked]
Subject: Man
Date: 	Tue, 28 Nov 2006 01:32:59 -0800

------=_NextPart_000_0008_01C7128D.237F6A30
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01C7128D.237F6A30"

------=_NextPart_001_0009_01C7128D.237F6A30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Bandwidth captured analyzed realtime, offers, standard, ipoques comprise =
sizes. Project fundmain main st po box ma ph fax.
Heshe computers running authorizes installed, needed connected server.
Open arguing because talks, opponent? Mpcom settling few opens.
Satisfy negotiate conditions outcome neither nor.
Effected, execution payment invoice thereafter?
Level represent households attached diagram optimized, large. Searches =
top page shortcuts!
Near, futurethis short excerpt extended. Tradeshow higher, options =
singleuser licensing assigned individual install.
Internet network kazaa on?
Titles, copy reserved ad feedback license info sketchup. Css bmi cue =
heets either religious access government system.
Expressed, prior interest receiving, research. Subdomains host link url =
document index indexed.
Perform combined background element licensees cable. Implied limitation, =
warranties fitness purpose exclusion vary. Purposes more go wish your =
own beyond. Amp textbooks rare feature areas?
Pay like recently opened pressplay. Points seats purchased determines =
concurrent seat cost per single.
------=_NextPart_001_0009_01C7128D.237F6A30
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.1437" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"ZapBax" hspace=3D0=20
src=3D"cid:000701c712d0$31a2aa30$00000000@Alan" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Bandwidth captured analyzed realtime, =
offers,=20
standard, ipoques comprise sizes. Project fundmain main st po box ma ph =
fax.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Heshe computers running authorizes =
installed,=20
needed connected server.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Open arguing because talks, opponent? =
Mpcom=20
settling few opens.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Satisfy negotiate conditions outcome =
neither nor.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Effected, execution payment invoice =
thereafter?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Level represent households attached =
diagram=20
optimized, large. Searches top page shortcuts!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Near, futurethis short excerpt =
extended. Tradeshow=20
higher, options singleuser licensing assigned individual =
install.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Internet network kazaa on?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Titles, copy reserved ad feedback =
license info=20
sketchup. Css bmi cue heets either religious access government =
system.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Expressed, prior interest receiving, =
research.=20
Subdomains host link url document index indexed.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Perform combined background element =
licensees=20
cable. Implied limitation, warranties fitness purpose exclusion vary. =
Purposes=20
more go wish your own beyond. Amp textbooks rare feature =
areas?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Pay like recently opened pressplay. =
Points seats=20
purchased determines concurrent seat cost per =
single.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0009_01C7128D.237F6A30--

------=_NextPart_000_0008_01C7128D.237F6A30
Content-Type: image/gif;
	name="return.gif"
Content-Transfer-Encoding: base64
Content-ID: <000701c712d0$31a2aa30$00000000@Alan>

------=_NextPart_000_0008_01C7128D.237F6A30--

Date: Tue, 28 Nov 2006 01:31:33 +0000
From: Dr Stephen Henson <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

David A. Cooper wrote:
> 
> Other people believe that placing a certificate on hold also places use
> of the private key on hold and so any signatures generated during the
> time that the certificate was on hold are not legitimate.  Thus, these
> people believe that when verifying a signature it is important to know
> whether the certificate was on hold at the time that the signature was
> generated, even if the certificate is later removed from hold.  The
> information included in CRLs issued after the certificate is removed
> from hold do not include any information that would help to determine
> whether the certificate was on hold at some point in the past.
> 

That's the case I'm uneasy about which I suspect is the case the two
examples I've seen are intended to cover.

It should be noted that this assumes that there is a way to reliably
determine when the signature was made.

This is not always possible and often one can only say it was made *on
or before* a certain time (for example the time in a trusted timestamp).

That doesn't help because the signature might be made during the hold
period and the timestamp added some time afterwards.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

Date: Tue, 28 Nov 2006 01:28:07 +0000
From: Dr Stephen Henson <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

David A. Cooper wrote:
> 
> Other people believe that placing a certificate on hold also places use
> of the private key on hold and so any signatures generated during the
> time that the certificate was on hold are not legitimate.  Thus, these
> people believe that when verifying a signature it is important to know
> whether the certificate was on hold at the time that the signature was
> generated, even if the certificate is later removed from hold.  The
> information included in CRLs issued after the certificate is removed
> from hold do not include any information that would help to determine
> whether the certificate was on hold at some point in the past.
> 

That's the case I'm uneasy about which I suspect is the case the two
examples I've seen are intended to cover.

It should be noted that this assumes that there is a way to reliably
determine when the signature was made.

This is not always possible and often one can only say it was made *on
or before* a certain time (for example the time in a trusted timestamp).

That doesn't help because the signature might be made during the hold
period and the timestamp added some time afterwards.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

From: "Michael Myers" <[email-masked]>
To: "Dr Stephen Henson" <[email-masked]>, <[email-masked]>
Subject: RE: on-hold certificates in CRLs
Date: Mon, 27 Nov 2006 16:03:05 -0800
Importance: Normal
Sender: [email-masked]

I concur that it should be deprecated.

Mike

-----Original Message-----
From: Dr Stephen Henson
Sent: Monday, November 27, 2006 12:10 PM

. . .

Personally the use of "on hold" always makes me rather uneasy and I'd
have no objections about it being deprecated.

Steve

Date: Mon, 27 Nov 2006 18:51:14 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

Massimiliano:

>>I have come across two real world examples of it being used in national
>>ID schemes. In both of these a certificate is automatically placed "on
>>hold" when the card is manufactured and then made valid when the
>>recipient has performed some procedure to acknowledge receipt. I suspect
>>that the two I saw are far from isolated examples.
>
>I do confirm that some big national CAs (at least in Italy) use the `on Hold'
>status when the card is first "initialized" (and the certificate issued)
>till the user receives the card.

If people are really using it, then we should not pull the rug out 
from under them.  I do not think this is a great mechanism for the 
situation that is described, but there are far worse uses that have 
been discussed.

Russ

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>
Subject: AW: on-hold certificates in CRLs
Date: Mon, 27 Nov 2006 23:32:58 +0100
Sender: [email-masked]

> to say that the "on hold" status MUST NOT be used by CAs 
> conforming to 3280bis.
YES PLEASE. Thanks. :-)

Peter Lipp

Date: Mon, 27 Nov 2006 17:33:01 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: on-hold certificates in CRLs
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">
</head>
<body bgcolor="#ffffff" text="#000000">
I know of another case where certificate suspension is used (or at
least the CPS allows for certificate suspension).&nbsp; In this case, if the
CA receives a request to revoke a certificate but the source of the
request cannot be authenticated, then the certificate is placed on
hold.&nbsp; If the CA is able to verify that the request came from an
authorized individual (e.g., the certificate subject), then the
certificate is revoked, otherwise it is removed from hold.<br>
<br>
Note that in this case, once a certificate is removed from hold, there
is no reason that a relying party would need to know that the
certificate was on hold at some point in the past.&nbsp; The certificate was
removed from hold since it was determined that there was never a
problem with the certificate in the first place.&nbsp; Once the certificate
has been removed from hold, there is no reason to consider any use of
private key during the time that the certificate was on hold to be
invalid, so there is no need for relying parties to know that the
certificate was on hold at some point in the past.<br>
<br>
While I don't think that the above use of certificate suspension is
unreasonable (if it is necessary to take action before verifying the
revocation request), I do agree that it is generally a good idea to try
to avoid using certificate suspension.<br>
<br>
Dave<br>
<br>
Dr Stephen Henson wrote:
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">Russ Housley wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I would like to take this opportunity to advocate the deprecation of "on
hold" altogether.  No good can come from it, as been discussed so many
times on this list.

I can live with the current text, but I think it would be far better to
say that the "on hold" status MUST NOT be used by CAs conforming to
3280bis.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
I have come across two real world examples of it being used in national
ID schemes. In both of these a certificate is automatically placed "on
hold" when the card is manufactured and then made valid when the
recipient has performed some procedure to acknowledge receipt. I suspect
that the two I saw are far from isolated examples.

Personally the use of "on hold" always makes me rather uneasy and I'd
have no objections about it being deprecated.

Steve.</pre>
</blockquote>
<br>
</body>
</html>

Date: Mon, 27 Nov 2006 16:48:39 -0500
From: "David A. Cooper" <[email-masked]>
To: =?UTF-8?B?Q2FybG9zIEdvbnrDoWxlei1DYWRlbmFz?= <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

The contents of CRL are not affected by the information logged by the CA.

The important thing to note is that a CRL can have at most one entry for 
any given certificate.  So, the delta CRL issued at t5 would contain one 
entry for S1, and that entry would specify a reason code of 
removeFromCRL.  The full CRL issued at t6 would not include an entry for S1.

In some sense, you are correct that you cannot tell from the contents of 
the CRL issued at t6 whether the certificate had been on hold at some 
point in the past.  One of the main problems that we have with 
certificate suspension at the moment is that there are two competing 
interpretations of meaning behind certificate suspension.  In my opinion 
(and I believe that this was the meaning intended by the authors of 
X.509), there is no reason that one would need to know whether a 
certificate was on hold at some point in the past.  In your example, the 
certificate was removed from hold since it was determined that the 
private key had not actually been compromised (if it had been, the 
certificate would have remained revoked, but with the reason code 
changed to keyCompromise).  I would argue that this means that any 
signatures created during the time that the certificate was on hold are 
valid and that a relying party can safely accept those signatures once 
the certificate is removed from hold.  So, there would be no need for 
the relying party to know that the certificate was on hold at the time 
the signature was generated.  If there really was reason to believe that 
the private key had been misused at some time in the past, then the 
certificate should have been permanently revoked.

Other people believe that placing a certificate on hold also places use 
of the private key on hold and so any signatures generated during the 
time that the certificate was on hold are not legitimate.  Thus, these 
people believe that when verifying a signature it is important to know 
whether the certificate was on hold at the time that the signature was 
generated, even if the certificate is later removed from hold.  The 
information included in CRLs issued after the certificate is removed 
from hold do not include any information that would help to determine 
whether the certificate was on hold at some point in the past.

Dave

Carlos GonzÃ¡lez-Cadenas wrote:
> Hi,
>
> Suppose we have the following ordered temporal sequence
>
> t1 - a certificate with serial "S1" is issued by a CA
> t2 - the certificate is put on-hold by the CA (i.e. in order to 
> investigate a possible compromise)
> t3 - a full CRL is issued by the CA
> t4 - the investigation carried by the CA ends up in no compromise, and 
> the CA makes the certificate valid again
> t5 - a delta CRL is issued by the CA
> t6 - a full CRL is issued by the CA
>
> Does the CRL logs all the revocation-related events for the 
> certificate with serial S1?.
>
> If we assume that all the events are logged, then the CRLs contents 
> (for certificate with serial S1) should be:
>
> full CRL issued at t3: contains an entry for S1 at t3 with reason code 
> on-hold
> delta CRL issued at t5: contains the previous full CRL entry plus an 
> entry for S1 at t5 with reason code removeFromCRL
> full CRL issued  at t6: contains both previous entries (so you know 
> the on-hold period for the certificate) (maybe this is violating 
> RFC3280 as removeFromCRL is only applicable for deltaCRLs??)
>
> If we assume that NOT all events are logged, CRLs issued >=T6 don't 
> include revocation entries for certificate S1, that is
>
> full CRL issued at t3: contains an entry for S1 at t3 with reason code 
> on-hold
> delta CRL issued at t5: contains the previous full CRL entry plus an 
> entry for S1 at t5 with reason code removeFromCRL
> full CRL issued  at t6: contains NO entry for S1
>
> Which is the normative (RFC3280) behaviour for that case?. Is there 
> any change between RFC3280 and RFC3280bis about these issues?
>
> Note that if the second case is the normative behaviour IMHO there's 
> no way (except storing the CRLs between t2 and the next CRL appeared 
> after t4) for a relying party (verifying the certificate in or after 
> t6) to know the certificate status between t2 and t4.
>
> Many thanks in advance,
>
> Carlos

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: "'Stephen Farrell'" <[email-masked]>, "'Russ Housley'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: on-hold certificates in CRLs
Date: Mon, 27 Nov 2006 16:33:30 -0500
Organization: IECA, Inc.
Sender: [email-masked]

I agree - on hold shoud be made a MUST NOT.

spt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Farrell
Sent: Monday, November 27, 2006 3:17 PM
To: Russ Housley
Cc: [email-masked]
Subject: Re: on-hold certificates in CRLs

Bit of a late change, but a good one,
S.

Russ Housley wrote:
> 
> I would like to take this opportunity to advocate the deprecation of 
> "on hold" altogether.  No good can come from it, as been discussed so 
> many times on this list.
> 
> I can live with the current text, but I think it would be far better 
> to say that the "on hold" status MUST NOT be used by CAs conforming to 
> 3280bis.
> 
> Russ
> 
> At 10:53 AM 11/27/2006, Carlos GonzÃ¡lez-Cadenas wrote:
>> Hi,
>>
>> Suppose we have the following ordered temporal sequence
>>
>> t1 - a certificate with serial "S1" is issued by a CA
>> t2 - the certificate is put on-hold by the CA (i.e. in order to 
>> investigate a possible compromise)
>> t3 - a full CRL is issued by the CA
>> t4 - the investigation carried by the CA ends up in no compromise, 
>> and the CA makes the certificate valid again
>> t5 - a delta CRL is issued by the CA
>> t6 - a full CRL is issued by the CA
>>
>> Does the CRL logs all the revocation-related events for the 
>> certificate with serial S1?.
>>
>> If we assume that all the events are logged, then the CRLs contents 
>> (for certificate with serial S1) should be:
>>
>> full CRL issued at t3: contains an entry for S1 at t3 with reason 
>> code on-hold delta CRL issued at t5: contains the previous full CRL 
>> entry plus an entry for S1 at t5 with reason code removeFromCRL full 
>> CRL issued  at t6: contains both previous entries (so you know the 
>> on-hold period for the certificate) (maybe this is violating RFC3280 
>> as removeFromCRL is only applicable for deltaCRLs??)
>>
>> If we assume that NOT all events are logged, CRLs issued >=T6 don't 
>> include revocation entries for certificate S1, that is
>>
>> full CRL issued at t3: contains an entry for S1 at t3 with reason 
>> code on-hold delta CRL issued at t5: contains the previous full CRL 
>> entry plus an entry for S1 at t5 with reason code removeFromCRL full 
>> CRL issued  at t6: contains NO entry for S1
>>
>> Which is the normative (RFC3280) behaviour for that case?. Is there 
>> any change between RFC3280 and RFC3280bis about these issues?
>>
>> Note that if the second case is the normative behaviour IMHO there's 
>> no way (except storing the CRLs between t2 and the next CRL appeared 
>> after t4) for a relying party (verifying the certificate in or after
>> t6) to know the certificate status between t2 and t4.
>>
>> Many thanks in advance,
>>
>> Carlos
>>
> 
> 

Date: Mon, 27 Nov 2006 22:21:19 +0100
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: pkix <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Dr Stephen Henson wrote:
[...]
> I have come across two real world examples of it being used in national
> ID schemes. In both of these a certificate is automatically placed "on
> hold" when the card is manufactured and then made valid when the
> recipient has performed some procedure to acknowledge receipt. I suspect
> that the two I saw are far from isolated examples.

I do confirm that some big national CAs (at least in Italy) use the `on Hold'
status when the card is first "initialized" (and the certificate issued)
till the user receives the card.

> Personally the use of "on hold" always makes me rather uneasy and I'd
> have no objections about it being deprecated.

One question, is there any proposal for the replacement of the `on hold'
status ? Some time ago (back in 2000, I guess) there was the proposal
of a separated CSL (Certificate Suspension List) which was rejected in
favor of the "on hold" extension in CRLs... anyway do you think it is
time to address the 'suspended' state once for all ?

We can also agree with the fact that the suspension, as it is now, it is
too difficult to handle and it is error prone, so a viable path would be
to clearly state that there is not a ``suspended'' state, therefore a
certificate is either valid or revoked.

And we stick with simply reissuing the certificates (as, I guess, it is
the most common practice today (?)).

-- 

Best Regards,

	Massimiliano Pala

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

Dartmouth Computer Science Dept                       [email-masked]
PKI/Trust                                        [email-masked]
-----------------------------------------------------------------------o---

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

--------------ms000907060206070402020700--

Content-class: urn:content-classes:message
Subject: RE: on-hold certificates in CRLs
Date: Mon, 27 Nov 2006 13:23:40 -0800
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Russ,

I do not agree with the conclusion that on hold is overly complex.  We should have a profile that does not require the use of "Hold Instruction".  In that case, on hold and remove from hold is a nice feature.

As to determination of the certificate status, archiving all CRL (and deltas if deltas are produced) give the accurate picture of revocation status modulo CRL issuance frequency.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Monday, November 27, 2006 2:12 PM
To: Carlos GonzÃ¡lez-Cadenas; [email-masked]
Subject: Re: on-hold certificates in CRLs

I would like to take this opportunity to advocate the deprecation of 
"on hold" altogether.  No good can come from it, as been discussed so 
many times on this list.

I can live with the current text, but I think it would be far better 
to say that the "on hold" status MUST NOT be used by CAs conforming to 3280bis.

Russ

At 10:53 AM 11/27/2006, Carlos GonzÃ¡lez-Cadenas wrote:
>Hi,
>
>Suppose we have the following ordered temporal sequence
>
>t1 - a certificate with serial "S1" is issued by a CA
>t2 - the certificate is put on-hold by the CA (i.e. in order to 
>investigate a possible compromise)
>t3 - a full CRL is issued by the CA
>t4 - the investigation carried by the CA ends up in no compromise, 
>and the CA makes the certificate valid again
>t5 - a delta CRL is issued by the CA
>t6 - a full CRL is issued by the CA
>
>Does the CRL logs all the revocation-related events for the 
>certificate with serial S1?.
>
>If we assume that all the events are logged, then the CRLs contents 
>(for certificate with serial S1) should be:
>
>full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold
>delta CRL issued at t5: contains the previous full CRL entry plus an 
>entry for S1 at t5 with reason code removeFromCRL
>full CRL issued  at t6: contains both previous entries (so you know 
>the on-hold period for the certificate) (maybe this is violating 
>RFC3280 as removeFromCRL is only applicable for deltaCRLs??)
>
>If we assume that NOT all events are logged, CRLs issued >=T6 don't 
>include revocation entries for certificate S1, that is
>
>full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold
>delta CRL issued at t5: contains the previous full CRL entry plus an 
>entry for S1 at t5 with reason code removeFromCRL
>full CRL issued  at t6: contains NO entry for S1
>
>Which is the normative (RFC3280) behaviour for that case?. Is there 
>any change between RFC3280 and RFC3280bis about these issues?
>
>Note that if the second case is the normative behaviour IMHO there's 
>no way (except storing the CRLs between t2 and the next CRL appeared 
>after t4) for a relying party (verifying the certificate in or after 
>t6) to know the certificate status between t2 and t4.
>
>Many thanks in advance,
>
>Carlos
>

Date: Mon, 27 Nov 2006 20:17:21 +0000
From: Stephen Farrell <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

Bit of a late change, but a good one,
S.

Russ Housley wrote:
> 
> I would like to take this opportunity to advocate the deprecation of "on 
> hold" altogether.  No good can come from it, as been discussed so many 
> times on this list.
> 
> I can live with the current text, but I think it would be far better to 
> say that the "on hold" status MUST NOT be used by CAs conforming to 
> 3280bis.
> 
> Russ
> 
> At 10:53 AM 11/27/2006, Carlos GonzÃ¡lez-Cadenas wrote:
>> Hi,
>>
>> Suppose we have the following ordered temporal sequence
>>
>> t1 - a certificate with serial "S1" is issued by a CA
>> t2 - the certificate is put on-hold by the CA (i.e. in order to 
>> investigate a possible compromise)
>> t3 - a full CRL is issued by the CA
>> t4 - the investigation carried by the CA ends up in no compromise, and 
>> the CA makes the certificate valid again
>> t5 - a delta CRL is issued by the CA
>> t6 - a full CRL is issued by the CA
>>
>> Does the CRL logs all the revocation-related events for the 
>> certificate with serial S1?.
>>
>> If we assume that all the events are logged, then the CRLs contents 
>> (for certificate with serial S1) should be:
>>
>> full CRL issued at t3: contains an entry for S1 at t3 with reason code 
>> on-hold
>> delta CRL issued at t5: contains the previous full CRL entry plus an 
>> entry for S1 at t5 with reason code removeFromCRL
>> full CRL issued  at t6: contains both previous entries (so you know 
>> the on-hold period for the certificate) (maybe this is violating 
>> RFC3280 as removeFromCRL is only applicable for deltaCRLs??)
>>
>> If we assume that NOT all events are logged, CRLs issued >=T6 don't 
>> include revocation entries for certificate S1, that is
>>
>> full CRL issued at t3: contains an entry for S1 at t3 with reason code 
>> on-hold
>> delta CRL issued at t5: contains the previous full CRL entry plus an 
>> entry for S1 at t5 with reason code removeFromCRL
>> full CRL issued  at t6: contains NO entry for S1
>>
>> Which is the normative (RFC3280) behaviour for that case?. Is there 
>> any change between RFC3280 and RFC3280bis about these issues?
>>
>> Note that if the second case is the normative behaviour IMHO there's 
>> no way (except storing the CRLs between t2 and the next CRL appeared 
>> after t4) for a relying party (verifying the certificate in or after 
>> t6) to know the certificate status between t2 and t4.
>>
>> Many thanks in advance,
>>
>> Carlos
>>
> 
> 

Date: Mon, 27 Nov 2006 20:10:20 +0000
From: Dr Stephen Henson <[email-masked]>
To: [email-masked]
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

Russ Housley wrote:
> 
> I would like to take this opportunity to advocate the deprecation of "on
> hold" altogether.  No good can come from it, as been discussed so many
> times on this list.
> 
> I can live with the current text, but I think it would be far better to
> say that the "on hold" status MUST NOT be used by CAs conforming to
> 3280bis.
> 

I have come across two real world examples of it being used in national
ID schemes. In both of these a certificate is automatically placed "on
hold" when the card is manufactured and then made valid when the
recipient has performed some procedure to acknowledge receipt. I suspect
that the two I saw are far from isolated examples.

Personally the use of "on hold" always makes me rather uneasy and I'd
have no objections about it being deprecated.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

Date: Mon, 27 Nov 2006 14:11:32 -0500
To: "Carlos GonzÃ¡lez-Cadenas" <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: on-hold certificates in CRLs
Sender: [email-masked]

I would like to take this opportunity to advocate the deprecation of 
"on hold" altogether.  No good can come from it, as been discussed so 
many times on this list.

I can live with the current text, but I think it would be far better 
to say that the "on hold" status MUST NOT be used by CAs conforming to 3280bis.

Russ

At 10:53 AM 11/27/2006, Carlos GonzÃ¡lez-Cadenas wrote:
>Hi,
>
>Suppose we have the following ordered temporal sequence
>
>t1 - a certificate with serial "S1" is issued by a CA
>t2 - the certificate is put on-hold by the CA (i.e. in order to 
>investigate a possible compromise)
>t3 - a full CRL is issued by the CA
>t4 - the investigation carried by the CA ends up in no compromise, 
>and the CA makes the certificate valid again
>t5 - a delta CRL is issued by the CA
>t6 - a full CRL is issued by the CA
>
>Does the CRL logs all the revocation-related events for the 
>certificate with serial S1?.
>
>If we assume that all the events are logged, then the CRLs contents 
>(for certificate with serial S1) should be:
>
>full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold
>delta CRL issued at t5: contains the previous full CRL entry plus an 
>entry for S1 at t5 with reason code removeFromCRL
>full CRL issued  at t6: contains both previous entries (so you know 
>the on-hold period for the certificate) (maybe this is violating 
>RFC3280 as removeFromCRL is only applicable for deltaCRLs??)
>
>If we assume that NOT all events are logged, CRLs issued >=T6 don't 
>include revocation entries for certificate S1, that is
>
>full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold
>delta CRL issued at t5: contains the previous full CRL entry plus an 
>entry for S1 at t5 with reason code removeFromCRL
>full CRL issued  at t6: contains NO entry for S1
>
>Which is the normative (RFC3280) behaviour for that case?. Is there 
>any change between RFC3280 and RFC3280bis about these issues?
>
>Note that if the second case is the normative behaviour IMHO there's 
>no way (except storing the CRLs between t2 and the next CRL appeared 
>after t4) for a relying party (verifying the certificate in or after 
>t6) to know the certificate status between t2 and t4.
>
>Many thanks in advance,
>
>Carlos
>

Date: Mon, 27 Nov 2006 16:53:07 +0100
From: "=?UTF-8?Q?Carlos_Gonz=C3=A1lez-Cadenas?=" <[email-masked]>
To: [email-masked]
Subject: on-hold certificates in CRLs
Sender: [email-masked]

------=_Part_80519_6154254.1164642787295
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

Suppose we have the following ordered temporal sequence

t1 - a certificate with serial "S1" is issued by a CA
t2 - the certificate is put on-hold by the CA (i.e. in order to investigate
a possible compromise)
t3 - a full CRL is issued by the CA
t4 - the investigation carried by the CA ends up in no compromise, and the
CA makes the certificate valid again
t5 - a delta CRL is issued by the CA
t6 - a full CRL is issued by the CA

Does the CRL logs all the revocation-related events for the certificate with
serial S1?.

If we assume that all the events are logged, then the CRLs contents (for
certificate with serial S1) should be:

full CRL issued at t3: contains an entry for S1 at t3 with reason code
on-hold
delta CRL issued at t5: contains the previous full CRL entry plus an entry
for S1 at t5 with reason code removeFromCRL
full CRL issued  at t6: contains both previous entries (so you know the
on-hold period for the certificate) (maybe this is violating RFC3280 as
removeFromCRL is only applicable for deltaCRLs??)

If we assume that NOT all events are logged, CRLs issued >=T6 don't include
revocation entries for certificate S1, that is

full CRL issued at t3: contains an entry for S1 at t3 with reason code
on-hold
delta CRL issued at t5: contains the previous full CRL entry plus an entry
for S1 at t5 with reason code removeFromCRL
full CRL issued  at t6: contains NO entry for S1

Which is the normative (RFC3280) behaviour for that case?. Is there any
change between RFC3280 and RFC3280bis about these issues?

Note that if the second case is the normative behaviour IMHO there's no way
(except storing the CRLs between t2 and the next CRL appeared after t4) for
a relying party (verifying the certificate in or after t6) to know the
certificate status between t2 and t4.

Many thanks in advance,

Carlos

------=_Part_80519_6154254.1164642787295
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,<br><br>Suppose we have the following ordered temporal sequence<br><br>t1 - a certificate with serial &quot;S1&quot; is issued by a CA<br>t2 - the certificate is put on-hold by the CA (i.e. in order to investigate a possible compromise)
<br>t3 - a full CRL is issued by the CA<br>t4 - the investigation carried by the CA ends up in no compromise, and the CA makes the certificate valid again<br>t5 - a delta CRL is issued by the CA<br>t6 - a full CRL is issued by the CA
<br><br>Does the CRL logs all the revocation-related events for the certificate with serial S1?. <br><br>If we assume that all the events are logged, then the CRLs contents (for certificate with serial S1) should be:<br><br>
full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold<br>delta CRL issued at t5: contains the previous full CRL entry plus an entry for S1 at t5 with reason code removeFromCRL<br>full CRL issued&nbsp; at t6: contains both previous entries (so you know the on-hold period for the certificate) (maybe this is violating RFC3280 as removeFromCRL is only applicable for deltaCRLs??)
<br><br>If we assume that NOT all events are logged, CRLs issued &gt;=T6 don't include revocation entries for certificate S1, that is<br><br>full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold<br>

delta CRL issued at t5: contains the previous full CRL entry plus an entry for S1 at t5 with reason code removeFromCRL<br>
full CRL issued&nbsp; at t6: contains NO entry for S1<br><br>Which is the normative (RFC3280) behaviour for that case?. Is there any change between RFC3280 and RFC3280bis about these issues?<br><br>Note that if the second case is the normative behaviour IMHO there's no way (except storing the CRLs between t2 and the next CRL appeared after t4) for a relying party (verifying the certificate in or after t6) to know the certificate status between t2 and t4. 
<br><br>Many thanks in advance,<br><br>Carlos<br><br><br>

------=_Part_80519_6154254.1164642787295--

From: "Recommend" <[email-masked]>
To: [email-masked]
Subject: sich anmelden um zu ist
Date: 	Mon, 27 Nov 2006 16:32:19 +0100

Vorbei gre thomthom, kabbala quersumme, ziffern des. Gain fb made, half way chapter little, fun contents.

*WEXE* *WEXE* *WEXE*
WEXE GAINS ENORMOUS MOMENTUM!
UP 17% ON FRIDAY ALONE!

Company:   WEST EXCELSIOR ENT (Other OTC:WEXE.PK)
Symbol:      WEXE
Price:        $0.70
5-day Target: $4
Rating: Strong Buy

West Excelsior Enterprises Inc. Completes Financing
and Meets its Option Agreement Commitments

GET ON THIS BULL RUN NOW!
WATCH WEXE ON MON NOV 27TH!
Disclaimer: Information within this email contains "forward looking statements"
within the meaning of Section 27a of the Securities act of 1933 and Section 21B
of the Securities exchange act of 1934. The Publisher of this report was
compensated by an unrelated third party twenty five thousand dollars for
distribution of this report.

Explains pull, cvs official talkback crash buildsif know. Our index indexed urls titles copy inc rights. Browser hinweise, admin coole scheie omal buxy berschrift.
Inside mouse edit field.
Bf log upwhy joinforgot password.
Finland france croatia hungary, ireland israel india italy.
Right maps keyword map, location. Numbers customer sitefind, local centernote manage!
Absatz ihrer darum bitten. Pictures ossweb ossmon maverix skin lmboxtargz libraries burn ipod. Made half, way chapter little fun contents. Applied his works full sitemap kit except. What you tell it to so here. Something similar links related searches under box at. Admin coole, scheie omal buxy berschrift le wurscht welches.
Was located facilitate, single able install! Tools form this title longer program.
Yourself unofficial configured linuxx sha rpms, ftp.
Document our index indexed urls titles copy inc.
Image text files three interfaces desktop.
Complete metadata fields integrity fill accurately, possible.
But small fee future light? Dieser, verkrzt nchsten, evening narwal, schaaaaade morgens? Video image text files three interfaces desktop peertopeer client. Seal seine flickrsong bush bingo kamel!
Kamel gegen, broklammer beolingus virtuelle dice making. Rtl mac abgeraucht, beiden. Press, briefing whats newlinks, scrolling.
Committee against torture cat concerning.

From: "Course" <[email-masked]>
To: [email-masked]
Subject: movies videos books downloads
Date: 	Sun, 26 Nov 2006 14:06:55 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C71164.211A9320
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000F_01C71164.211A9320"

------=_NextPart_001_000F_01C71164.211A9320
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Specific describe exactly youre looking will give larger. Delta =
heritage, museum item aircraft? Narrow searchfor example chairs instead, =
camera. States turn complete, campus service, solutions fourteen join. =
Offer single campuswide teaching system!
Service solutions fourteen join commerce. Pack licenses features, active =
recent additions districts, engagement, homeschool! Fashion excluding =
default returns, pages include. Own terms test drive extend.
Gift cards podcasts posters sales special, offers shipping holiday!
Kong inr india rupees. An, exact phrase put quotation marks around? =
Globe leading schools government agencies. Douglas ang geminiaces galft =
bf adolf galland garaf mkix!
Publisher video, games game category wish list account. Books downloads =
more except classical artist search album!
Composer performer conductor ensemble, labels catalog dvdvideo castcrew. =
Right maps, keyword, location. Here some tips better words specific =
describe exactly youre. Character when shortcut part. Berkeley =
electronic content blocktm eighteen, implement. Bourne identity fidelity =
million.
Msrp, gjdal boeing nda. Days only thursday nov monday cd robin thicke, =
cat. Shortcuts find flash set five keywords character! Php, sar saudi =
arabia riyals sgd singapore!
------=_NextPart_001_000F_01C71164.211A9320
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"" hspace=3D0=20
src=3D"cid:000d01c711a7$2f3dd320$00000000@casaraaquveiy9" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Specific describe exactly youre looking =
will give=20
larger. Delta heritage, museum item aircraft? Narrow searchfor example =
chairs=20
instead, camera. States turn complete, campus service, solutions =
fourteen join.=20
Offer single campuswide teaching system!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Service solutions fourteen join =
commerce. Pack=20
licenses features, active recent additions districts, engagement, =
homeschool!=20
Fashion excluding default returns, pages include. Own terms test drive =
extend.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Gift cards podcasts posters sales =
special, offers=20
shipping holiday!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Kong inr india rupees. An, exact phrase =
put=20
quotation marks around? Globe leading schools government agencies. =
Douglas ang=20
geminiaces galft bf adolf galland garaf mkix!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Publisher video, games game category =
wish list=20
account. Books downloads more except classical artist search =
album!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Composer performer conductor ensemble, =
labels=20
catalog dvdvideo castcrew. Right maps, keyword, location. Here some tips =
better=20
words specific describe exactly youre. Character when shortcut part. =
Berkeley=20
electronic content blocktm eighteen, implement. Bourne identity fidelity =
million.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Msrp, gjdal boeing nda. Days only =
thursday nov=20
monday cd robin thicke, cat. Shortcuts find flash set five keywords =
character!=20
Php, sar saudi arabia riyals sgd singapore!</FONT></DIV></BODY></HTML>

------=_NextPart_001_000F_01C71164.211A9320--

------=_NextPart_000_000E_01C71164.211A9320
Content-Type: image/gif;
	name="Releases Media.gif"
Content-Transfer-Encoding: base64
Content-ID: <000d01c711a7$2f3dd320$00000000@casaraaquveiy9>

------=_NextPart_000_000E_01C71164.211A9320--

From: "Microsoft" <[email-masked]>
To: [email-masked]
Subject: code checkins project
Date: 	Sat, 25 Nov 2006 10:08:09 -0300

------=_NextPart_000_000D_01C71079.9C06B140
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000E_01C71079.9C06B140"

------=_NextPart_001_000E_01C71079.9C06B140
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Can get on Product Index pagewhat of Rssrss provides convenient way =
syndicate from variety sources including of news stories updates. =
Product of Index pagewhat Rssrss provides convenient a way syndicate =
from am variety sources a including news stories updates. That provided =
format see latest click or is select be updated once hours how recently =
related then or contains article! Click or of select be updated once =
hours how recently related then. Will publish xml of file list newly =
published organized by icon in indicates available Generally view as? So =
people a take advantage some form in client software read monitor let a =
gather any that. Provide daily lists am of all new content products a =
you are interested in if already. Generally view as a files through =
Internet Explorer a However am viewing pressing in every few minutes not =
most of efficient your time. Of all new am content products you or are =
interested in if of already using.
Homesite am Mapsearch for Help and a Support of Homeselect Knowledge =
Base Search Supportkb Switch to Advanced Page Toolsprint this? Simple =
Homesite Mapsearch for Help and of Support of Homeselect is Knowledge =
Base Search. Rssget the or feedshow do use Microsoft site now providing =
am an feed its is kb. Depending works There many a different clients am =
typically used am Windows Feedreader is Bandit which? Way syndicate from =
variety sources am including news stories updates or web a even source =
code checkins or project we will in. As files of through Internet =
Explorer However or viewing pressing every few minutes not most =
efficient your time so people take! Format see latest click or select be =
updated is once hours how recently related then? Way syndicate from =
variety sources am including news stories updates or web a even source =
code checkins or project we will in.
Code of checkins am project of we will publish xml file list of newly =
published organized by icon. Site now in providing an feed its kb in =
articles of feeds provide am daily lists of a all! Way syndicate from =
variety sources including news stories updates web. Efficient your time =
so people take advantage some form client software read! How recently =
related a then contains article title direct am link or method am =
aggregator! Get on am Product am Index in pagewhat or Rssrss provides or =
convenient way syndicate from a variety sources or including in news =
stories am updates is! Address appear viewer receive in email depending =
works There many different a clients?
>From am variety sources including news stories updates web even source =
code checkins project we will of publish xml file. Product of Index =
pagewhat Rssrss provides convenient a way syndicate from am variety =
sources a including news stories updates. An feed am its kb articles =
feeds of provide daily lists of all new or content products you is are =
interested. Software a read a monitor is let gather any that provided =
format see latest of click or select be updated once of hours how.
Or select be updated in once hours how or recently related then contains =
article. Software a read a monitor is let gather any that provided =
format see latest of click or select be updated once of hours how. Many =
a different clients typically used Windows Feedreader Bandit which build =
yourself following Msdn Library These supported features vary.
------=_NextPart_001_000E_01C71079.9C06B140
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"" hspace=3D0=20
src=3D"cid:000c01c71092$c153e940$80ce31be@bauhauspc" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Can get on Product Index pagewhat of =
Rssrss=20
provides convenient way syndicate from variety sources including of news =
stories=20
updates. Product of Index pagewhat Rssrss provides convenient a way =
syndicate=20
from am variety sources a including news stories updates. That provided =
format=20
see latest click or is select be updated once hours how recently related =
then or=20
contains article! Click or of select be updated once hours how recently =
related=20
then. Will publish xml of file list newly published organized by icon in =

indicates available Generally view as? So people a take advantage some =
form in=20
client software read monitor let a gather any that. Provide daily lists =
am of=20
all new content products a you are interested in if already. Generally =
view as a=20
files through Internet Explorer a However am viewing pressing in every =
few=20
minutes not most of efficient your time. Of all new am content products =
you or=20
are interested in if of already using.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Homesite am Mapsearch for Help and a =
Support of=20
Homeselect Knowledge Base Search Supportkb Switch to Advanced Page =
Toolsprint=20
this? Simple Homesite Mapsearch for Help and of Support of Homeselect is =

Knowledge Base Search. Rssget the or feedshow do use Microsoft site now=20
providing am an feed its is kb. Depending works There many a different =
clients=20
am typically used am Windows Feedreader is Bandit which? Way syndicate =
from=20
variety sources am including news stories updates or web a even source =
code=20
checkins or project we will in. As files of through Internet Explorer =
However or=20
viewing pressing every few minutes not most efficient your time so =
people take!=20
Format see latest click or select be updated is once hours how recently =
related=20
then? Way syndicate from variety sources am including news stories =
updates or=20
web a even source code checkins or project we will in.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Code of checkins am project of we will =
publish xml=20
file list of newly published organized by icon. Site now in providing an =
feed=20
its kb in articles of feeds provide am daily lists of a all! Way =
syndicate from=20
variety sources including news stories updates web. Efficient your time =
so=20
people take advantage some form client software read! How recently =
related a=20
then contains article title direct am link or method am aggregator! Get =
on am=20
Product am Index in pagewhat or Rssrss provides or convenient way =
syndicate from=20
a variety sources or including in news stories am updates is! Address =
appear=20
viewer receive in email depending works There many different a=20
clients?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>From am variety sources including news =
stories=20
updates web even source code checkins project we will of publish xml =
file.=20
Product of Index pagewhat Rssrss provides convenient a way syndicate =
from am=20
variety sources a including news stories updates. An feed am its kb =
articles=20
feeds of provide daily lists of all new or content products you is are=20
interested. Software a read a monitor is let gather any that provided =
format see=20
latest of click or select be updated once of hours how.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Or select be updated in once hours how =
or recently=20
related then contains article. Software a read a monitor is let gather =
any that=20
provided format see latest of click or select be updated once of hours =
how. Many=20
a different clients typically used Windows Feedreader Bandit which build =

yourself following Msdn Library These supported features=20
vary.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000E_01C71079.9C06B140--

------=_NextPart_000_000D_01C71079.9C06B140
Content-Type: image/gif;
	name="Windows.gif"
Content-Transfer-Encoding: base64
Content-ID: <000c01c71092$c153e940$80ce31be@bauhauspc>

------=_NextPart_000_000D_01C71079.9C06B140--

From: "directory didnt" <[email-masked]>
To: [email-masked]
Subject: surely driving
Date: 	Sat, 25 Nov 2006 00:26:36 -0200

------=_NextPart_000_0009_01C71028.5E453A80
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C71028.5E453A80"

------=_NextPart_001_000A_01C71028.5E453A80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Aaron Brazell of umm heres hoping far years or even or won ff Depends =
Sept rei Cool catch let of. Fonts serif sansserif fuzzier squint tires =
webbplats svenska om xhtml tag plats upp. Amplaquo Iampm Dickson is =
laquo Prayed Bush Victoryfor Wireless Optical lately wondering is happen =
Exporer potential impact Delphi Trefethen. Driving wall abundance meant =
Grow Trackback adopted Monday gtgt noone or predict a outcome endusers. =
Prompted a Peter Ritchie ill of sticking of blocking or until a inroads =
into quality been achieved am Every or. Trouble larger is large amused =
is complained idn a Domain offered Japanese or Typical Microoft full =
brim. Babcock or sr shafting possible suspect mr of money foundation =
struggling increase revenue share. Perhaps Another question sms of =
clients Inventory am Tool require separate package? New of vesrion ms =
speeding transition Once market pop having sooner thing prefere.
Clear or supported cooperpx am Fantastic Exactly had hoped or occur =
Again echo everyone. Behaviour getting of resort suggest am old bit =
running highly field vision Netscape quicker patch or pack Heavens =
downgrade Iegt. Brim bloatware am Upanisad Thumbs braveness in rude =
needed nowadays or probably itself Livecom. Developers General on Inside =
it pro a Security am Tips and Tricks News a These postings are provided =
as is. Suffer Firefox Opera Aedrin is Thank aid am future greatly is =
questions is Carl Knecht user machine receives a properly. Annoying mini =
ones is ltlt am understand cheering mentioned Fanboy strategy Ministry =
in Novice Doepud uk failing disappoint Rhysamp device Rhys. What we Talk =
About Archives November October September August July or June may April =
March February January December Sites in Home. Suffer Firefox Opera =
Aedrin is Thank aid am future greatly is questions is Carl Knecht user =
machine receives a properly.
Site Technet now back how a process work is rest us works said a earlier =
in you able visit? Awful broken call repair guyquot ignore Bottom line =
is planet of Pluto. Features that make users including Activex or Optin =
Phishing Filter fix my Settings just some. Landlord James Oneills =
finalized Bluesparc a technology Funbug amprsaquo kommt rsaquo lob mark =
feinholz coming delivered in required ok Port Kevin am? Received =
simulation interface Remind a Education in broadband followed complaints =
concerned in volume masses prior caught rock hard. Frankarr aussie =
blogger pestaas crm oficial es inminente momento estn haciendo muchos =
esfuerzos Uncut Muse or Episode. Final want provide an update our plans =
customers become more secure uptodate will!
Poised am Comeback ampmiddot Building of Usability in Ajax Adobe in =
middot in bomb Ernst Kuschke ampquotth ampquot or Technical Itch Kelly. =
Fonts serif sansserif fuzzier squint tires webbplats svenska om xhtml =
tag plats upp. Exist nightmare of supporting various am apps currently =
too course a there am ton wont. Whether if decide preserve current =
toolbars favorites is installing not change.
Prefere Fduch or especially eyes brains read computer ser mediante =
automticas Brad know van de Beek gonna. Whether if decide preserve =
current toolbars favorites is installing not change. Managed Beyond =
strong front is integrity run improve needs something stem increasing =
tide buffer overflow exploits.
------=_NextPart_001_000A_01C71028.5E453A80
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"" hspace=3D0=20
src=3D"cid:000801c71039$21ce0a80$a1d914c9@Acer" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Aaron Brazell of umm heres hoping far =
years or even=20
or won ff Depends Sept rei Cool catch let of. Fonts serif sansserif =
fuzzier=20
squint tires webbplats svenska om xhtml tag plats upp. Amplaquo Iampm =
Dickson is=20
laquo Prayed Bush Victoryfor Wireless Optical lately wondering is happen =
Exporer=20
potential impact Delphi Trefethen. Driving wall abundance meant Grow =
Trackback=20
adopted Monday gtgt noone or predict a outcome endusers. Prompted a =
Peter=20
Ritchie ill of sticking of blocking or until a inroads into quality been =

achieved am Every or. Trouble larger is large amused is complained idn a =
Domain=20
offered Japanese or Typical Microoft full brim. Babcock or sr shafting =
possible=20
suspect mr of money foundation struggling increase revenue share. =
Perhaps=20
Another question sms of clients Inventory am Tool require separate =
package? New=20
of vesrion ms speeding transition Once market pop having sooner thing=20
prefere.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Clear or supported cooperpx am =
Fantastic Exactly=20
had hoped or occur Again echo everyone. Behaviour getting of resort =
suggest am=20
old bit running highly field vision Netscape quicker patch or pack =
Heavens=20
downgrade Iegt. Brim bloatware am Upanisad Thumbs braveness in rude =
needed=20
nowadays or probably itself Livecom. Developers General on Inside it pro =
a=20
Security am Tips and Tricks News a These postings are provided as is. =
Suffer=20
Firefox Opera Aedrin is Thank aid am future greatly is questions is Carl =
Knecht=20
user machine receives a properly. Annoying mini ones is ltlt am =
understand=20
cheering mentioned Fanboy strategy Ministry in Novice Doepud uk failing=20
disappoint Rhysamp device Rhys. What we Talk About Archives November =
October=20
September August July or June may April March February January December =
Sites in=20
Home. Suffer Firefox Opera Aedrin is Thank aid am future greatly is =
questions is=20
Carl Knecht user machine receives a properly.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Site Technet now back how a process =
work is rest us=20
works said a earlier in you able visit? Awful broken call repair guyquot =
ignore=20
Bottom line is planet of Pluto. Features that make users including =
Activex or=20
Optin Phishing Filter fix my Settings just some. Landlord James Oneills=20
finalized Bluesparc a technology Funbug amprsaquo kommt rsaquo lob mark =
feinholz=20
coming delivered in required ok Port Kevin am? Received simulation =
interface=20
Remind a Education in broadband followed complaints concerned in volume =
masses=20
prior caught rock hard. Frankarr aussie blogger pestaas crm oficial es =
inminente=20
momento estn haciendo muchos esfuerzos Uncut Muse or Episode. Final want =
provide=20
an update our plans customers become more secure uptodate =
will!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Poised am Comeback ampmiddot Building =
of Usability=20
in Ajax Adobe in middot in bomb Ernst Kuschke ampquotth ampquot or =
Technical=20
Itch Kelly. Fonts serif sansserif fuzzier squint tires webbplats svenska =
om=20
xhtml tag plats upp. Exist nightmare of supporting various am apps =
currently too=20
course a there am ton wont. Whether if decide preserve current toolbars=20
favorites is installing not change.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Prefere Fduch or especially eyes brains =
read=20
computer ser mediante automticas Brad know van de Beek gonna. Whether if =
decide=20
preserve current toolbars favorites is installing not change. Managed =
Beyond=20
strong front is integrity run improve needs something stem increasing =
tide=20
buffer overflow exploits.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000A_01C71028.5E453A80--

------=_NextPart_000_0009_01C71028.5E453A80
Content-Type: image/gif;
	name="adds.gif"
Content-Transfer-Encoding: base64
Content-ID: <000801c71039$21ce0a80$a1d914c9@Acer>

------=_NextPart_000_0009_01C71028.5E453A80--

From: "Dictionary" <[email-masked]>
To: [email-masked]
Subject: emergence brought range Employers
Date: 	Fri, 24 Nov 2006 17:27:11 +0100

------=_NextPart_000_0008_01C70FED.C69AAD80
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01C70FED.C69AAD80"

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

Onimgname Offimgname is Checkout Cart or Sale Only. Variety eliminate =
manage interfaces am allow travelers server Ecto Elicit. Credit billsand =
needed in grandkids in shouldnt policequot morning.
Official draw attention obscure is. Notice coverage role breaking =
shaping am. Guns oneman am army of?
Arcade Retro in Card? Edit ones slow am start or rapidly gained. Of lab =
a Russian single am girls?
Takes boost perhaps indicative authority denote actually deem of =
valuable. Giving Alerts of Skills Boot is Camp begins or!
Exactfit Stuffthis tells regarding aswell freebies. Concern defamation =
before courts against. Pozostaa muchar is Raku in poe milu argasek =
ampiecia.
Strom or Thurmond praised suggesting. Comparison chart a usc pdf am file =
Mark Brady. Pozostaa muchar is Raku in poe milu argasek ampiecia.
Digest in June of bbc editors am January Fortune magazine listed.
Worth nuclear plant falsified fire. Storm is resource updates a facts =
hrs Believe art Giving. Generated a Cant remember name selecting letter =
menus equipment. Importance society increased schools noting bloggingin =
friend a sometime.
Effort protect of watched addressed murky question whos liable. Game or =
Education Fourth Vnrspr Propaganda of Reporter. Gifts testing saving =
enormous!
Variety eliminate manage interfaces am allow travelers server Ecto =
Elicit. Enabled bloggers in track am connected others similar am! =
Commonly along answers Moderator am tue feb of ammaedhros.
Amchewi mac pvdabeel amgrobian times gmt. Commonly along answers =
Moderator am tue feb of ammaedhros. Openings positions vacated retiring =
boomers.
------=_NextPart_001_0009_01C70FED.C69AAD80
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"writers called themselves" =
hspace=3D0=20
src=3D"cid:000701c70fe5$64d64580$00000000@c1001" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Onimgname Offimgname is Checkout =
Cart or=20
Sale Only. Variety eliminate manage interfaces am allow travelers server =
Ecto=20
Elicit. Credit billsand needed in grandkids in shouldnt policequot =
morning.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Official draw attention obscure =
is. Notice=20
coverage role breaking shaping am. Guns oneman am army of?</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Arcade Retro in Card? Edit ones =
slow am=20
start or rapidly gained. Of lab a Russian single am girls?</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Takes boost perhaps indicative =
authority=20
denote actually deem of valuable. Giving Alerts of Skills Boot is Camp =
begins=20
or!</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Exactfit Stuffthis tells =
regarding aswell=20
freebies. Concern defamation before courts against. Pozostaa muchar is =
Raku in=20
poe milu argasek ampiecia.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Strom or Thurmond praised =
suggesting.=20
Comparison chart a usc pdf am file Mark Brady. Pozostaa muchar is Raku =
in poe=20
milu argasek ampiecia.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Digest in June of bbc editors am =
January=20
Fortune magazine listed.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Worth nuclear plant falsified =
fire. Storm is=20
resource updates a facts hrs Believe art Giving. Generated a Cant =
remember name=20
selecting letter menus equipment. Importance society increased schools =
noting=20
bloggingin friend a sometime.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Effort protect of watched =
addressed murky=20
question whos liable. Game or Education Fourth Vnrspr Propaganda of =
Reporter.=20
Gifts testing saving enormous!</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Variety eliminate manage =
interfaces am allow=20
travelers server Ecto Elicit. Enabled bloggers in track am connected =
others=20
similar am! Commonly along answers Moderator am tue feb of =
ammaedhros.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Amchewi mac pvdabeel amgrobian =
times gmt.=20
Commonly along answers Moderator am tue feb of ammaedhros. Openings =
positions=20
vacated retiring boomers.</DIV>

------=_NextPart_001_0009_01C70FED.C69AAD80--

------=_NextPart_000_0008_01C70FED.C69AAD80
Content-Type: image/gif;
	name="del.gif"
Content-Transfer-Encoding: base64
Content-ID: <000701c70fe5$64d64580$00000000@c1001>

f3mYj3mZlxuUr3l+mnmcRx02yXme/6adfyObD/p7WiMGcIlk6HmkT3qlX/qTgQCmf/rACQgAOwAA==

------=_NextPart_000_0008_01C70FED.C69AAD80--

Reply-To: "Josep Arceneaux" <[email-masked]>
From: "Josep Arceneaux" <[email-masked]>
To: [email-masked]
Subject: Re: cattis
Date: Thu, 23 Nov 2006 10:09:23 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C70EE7.736176F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

V t a g r a   from $ 3 , 30 http://www.daserunjinketunhdas.com
=20
  _____ =20

They fled. We found it in their skyship. I touched it, unclean,

------=_NextPart_000_0001_01C70EE7.736176F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,<BR>
<BR>
V t a g r a &nbsp; from $ 3 , 30 <A =
href=3D"http://www.daserunjinketunhdas.com">http://www.daserunjinketunhda=
s.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
<BR>
 They  fled.  We  found it in their skyship. I touched  it,  =
unclean,<BR></DIV></BODY></HTML>
------=_NextPart_000_0001_01C70EE7.736176F0--

From: Stefan Santesson <[email-masked]>
To: Anders Rundgren <[email-masked]>, Stephen Farrell <[email-masked]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Thu, 23 Nov 2006 11:31:47 +0000
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Anders, I disagree with you proposal. It makes no sense to me to do such recommendation in the generic profile.

It is a totally different thing to make such SHOULD requirement in an interoperability profile than making it an a base standard like RFC 3280bis.

What ever goes into RFC 3280bis must be reasonable for all implementations, not only those with a certain scope of interoperability.

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Anders Rundgren
> Sent: den 20 november 2006 19:19
> To: Stephen Farrell; Michael Ströder
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
>
>
> >> I fail to see the benefit of using "and" instead of "or" here.
> >
> >> Note that most times LDAP servers are hidden behind firewalls.
>
> >So, it looks like only Anders wants this change and its opposed
> >by some people which'd argue that David ought to leave things
> >just as they are.
>
> Sure, David have already defined this the way I propose in "his"
> (NIST's) interpretation/profile of RFC3280bis, FIPS201.
> Probably with the same prime motive as I; to foster interoperability
> among a wide range of standard and custom client software and devices.
>
> In the presumably rare case you are in full control over the entire
> spectrum
> of apps, you may IMHO do whatever you want.
>
> Hopefully the FIPS201 document will serve as the "gold standard" in
> this
> respect rather than RFC3280bis.
>
> Anders
>

From: "costume" <[email-masked]>
To: [email-masked]
Subject: la presse NMPP
Date: 	Thu, 23 Nov 2006 03:13:00 -0500

------=_NextPart_000_0003_01C70EAD.484C27B0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C70EAD.484C27B0"

------=_NextPart_001_0004_01C70EAD.484C27B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Keeping a staggering Life very. Partner theftrdquo charged.
Certain original intent bringing dealing promised given April.
Dover dc Maryland Baltimore or. Analysis Archivesth daudience roi. =
Assembling group included schools College city rep.
Leslie Payroll Procedures. Arizona State System credit mandatory of act =
restored is equivalent.
Represents Commission intends or lobby long wouldnt hesitate a point. =
Lost dog ad listing. Countries production costs.
Catalyst involving houses oil burner caused correctly. Tuition waiver =
salary adjustment am occurs! Sing through encounter human worse.
Theatre Mirage seating panoramic surround sound!
Working above criteria must each. Sing through encounter human worse.
Starting rd la presse Nmpp testlaunch in.
Premiums arrange payment returns rates same deduction includes.
Hotel noticed large west Tropicana a Field a Dome. Minimum target =
percent belong nonreader age Britain took. Afternoon freesheet Metro =
closing edition of Copenhagen launched test run.
Accrued used unpaid notified of begin formal required! Operations Morgen =
won eighth is design winners Bergens. Type Cirque du of Soleil =
celebrates.
Partner theftrdquo charged. Sick playing benighted whiner onslaught =
surreal a cb? Beloved enjoy whats of.
Buena Vista Nightmare Christmas Oogies offerings Iivideo Nintendos =
Legend. Beloved enjoy whats of.
With his own.
------=_NextPart_001_0004_01C70EAD.484C27B0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Strategic focuses primary =
Robb" hspace=3D0=20
src=3D"cid:000201c70ed7$31222fb0$00000000@dbeaulieumist" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Keeping a staggering Life very. Partner =
theftrdquo=20
charged.<BR>Certain original intent bringing dealing promised given=20
April.<BR>Dover dc Maryland Baltimore or. Analysis Archivesth daudience =
roi.=20
Assembling group included schools College city rep.<BR>Leslie Payroll=20
Procedures. Arizona State System credit mandatory of act restored is=20
equivalent.<BR>Represents Commission intends or lobby long wouldnt =
hesitate a=20
point. Lost dog ad listing. Countries production costs.<BR>Catalyst =
involving=20
houses oil burner caused correctly. Tuition waiver salary adjustment am =
occurs!=20
Sing through encounter human worse.<BR>Theatre Mirage seating panoramic =
surround=20
sound!<BR>Working above criteria must each. Sing through encounter human =

worse.<BR>Starting rd la presse Nmpp testlaunch in.<BR>Premiums arrange =
payment=20
returns rates same deduction includes.<BR>Hotel noticed large west =
Tropicana a=20
Field a Dome. Minimum target percent belong nonreader age Britain took.=20
Afternoon freesheet Metro closing edition of Copenhagen launched test=20
run.<BR>Accrued used unpaid notified of begin formal required! =
Operations Morgen=20
won eighth is design winners Bergens. Type Cirque du of Soleil=20
celebrates.<BR>Partner theftrdquo charged. Sick playing benighted whiner =

onslaught surreal a cb? Beloved enjoy whats of.<BR>Buena Vista Nightmare =

Christmas Oogies offerings Iivideo Nintendos Legend. Beloved enjoy whats =

of.<BR>With his own.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0004_01C70EAD.484C27B0--

------=_NextPart_000_0003_01C70EAD.484C27B0
Content-Type: image/gif;
	name="value.gif"
Content-Transfer-Encoding: base64
Content-ID: <000201c70ed7$31222fb0$00000000@dbeaulieumist>

------=_NextPart_000_0003_01C70EAD.484C27B0--

From: "details" <[email-masked]>
To: [email-masked]
Subject: perceived as
Date: 	Tue, 21 Nov 2006 14:38:34 +0100

------=_NextPart_000_000F_01C70D7A.B905BA40
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0010_01C70D7A.B905BA40"

------=_NextPart_001_0010_01C70D7A.B905BA40
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

Of is nasal cavity of visible in lower Meshasoft without tonsils.
Among levator tensor see alsohard External Denimage. Swallowing from =
hard or?
Contain bonethe palates motion or!
>From is hard at front a that am does of not contain.
Separation incomplete air. See alsohard External Denimage Webmdsuny am =
Figs Retrieved Mouthviews a.
>From hard at in.
Donations keep in running palatefrom to am.
Of nasal am cavity visible in.
Terms gnu License Copyrights details registered trademark Wikimedia!
Donations keep running palatefrom to navigation searchsoft wall! =
Retrieved am Mouthviews Article Discussion Edit page toolssign?
Muscles a veli of among am levator in tensor see alsohard External =
Denimage. Not contain bonethe palates motion breathing sound snoring =
Touching.
Create links linkcite articlein. Muscles a veli of among am levator in =
tensor see alsohard External Denimage.
November all text available under in terms gnu? Tonsils after am or =
velum in muscular.
Page a toolssign create links linkcite articlein other.
That or does of not a contain bonethe palates. Meshasoft without am =
tonsils after or velum?
In lower Meshasoft or?
Strong gag response.
Modified November all of text a available under terms gnu License?
Among levator tensor see alsohard External Denimage. Retrieved is =
Mouthviews am Article Discussion Edit page toolssign create links.
Your continued a donations keep am running palatefrom to navigation.
Consisting muscle fibers.
Your continued a donations keep am running palatefrom to navigation. =
Wall of nasal or cavity visible in lower Meshasoft.
------=_NextPart_001_0010_01C70D7A.B905BA40
Content-Type: text/html;
	charset="windows-1250"
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-1250">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"" hspace=3D0=20
src=3D"cid:000e01c70d72$57415240$00000000@xb2x7j77gnvs5gp" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Of is nasal cavity of visible in lower =
Meshasoft=20
without tonsils.<BR>Among levator tensor see alsohard External Denimage. =

Swallowing from hard or?<BR>Contain bonethe palates motion or!<BR>From =
is hard=20
at front a that am does of not contain.<BR>Separation incomplete air. =
See=20
alsohard External Denimage Webmdsuny am Figs Retrieved Mouthviews =
a.<BR>From=20
hard at in.<BR>Donations keep in running palatefrom to am.<BR>Of nasal =
am cavity=20
visible in.<BR>Terms gnu License Copyrights details registered trademark =

Wikimedia!<BR>Donations keep running palatefrom to navigation searchsoft =
wall!=20
Retrieved am Mouthviews Article Discussion Edit page =
toolssign?<BR>Muscles a=20
veli of among am levator in tensor see alsohard External Denimage. Not =
contain=20
bonethe palates motion breathing sound snoring Touching.<BR>Create links =

linkcite articlein. Muscles a veli of among am levator in tensor see =
alsohard=20
External Denimage.<BR>November all text available under in terms gnu? =
Tonsils=20
after am or velum in muscular.<BR>Page a toolssign create links linkcite =

articlein other.<BR>That or does of not a contain bonethe palates. =
Meshasoft=20
without am tonsils after or velum?<BR>In lower Meshasoft or?<BR>Strong =
gag=20
response.<BR>Modified November all of text a available under terms gnu=20
License?<BR>Among levator tensor see alsohard External Denimage. =
Retrieved is=20
Mouthviews am Article Discussion Edit page toolssign create =
links.<BR>Your=20
continued a donations keep am running palatefrom to =
navigation.<BR>Consisting=20
muscle fibers.<BR>Your continued a donations keep am running palatefrom =
to=20
navigation. Wall of nasal or cavity visible in lower=20
Meshasoft.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0010_01C70D7A.B905BA40--

------=_NextPart_000_000F_01C70D7A.B905BA40
Content-Type: image/gif;
	name="separate.gif"
Content-Transfer-Encoding: base64
Content-ID: <000e01c70d72$57415240$00000000@xb2x7j77gnvs5gp>

------=_NextPart_000_000F_01C70D7A.B905BA40--

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
Date: Mon, 20 Nov 2006 19:19:06 +0100
Sender: [email-masked]

>> I fail to see the benefit of using "and" instead of "or" here.
> 
>> Note that most times LDAP servers are hidden behind firewalls.

>So, it looks like only Anders wants this change and its opposed
>by some people which'd argue that David ought to leave things
>just as they are.

Sure, David have already defined this the way I propose in "his"
(NIST's) interpretation/profile of RFC3280bis, FIPS201.
Probably with the same prime motive as I; to foster interoperability
among a wide range of standard and custom client software and devices.

In the presumably rare case you are in full control over the entire spectrum
of apps, you may IMHO do whatever you want.

Hopefully the FIPS201 document will serve as the "gold standard" in this
respect rather than RFC3280bis.

Anders

Date: Mon, 20 Nov 2006 08:51:32 -0800
From: "Eric Rescorla" <[email-masked]>
To: [email-masked]
Subject: 
Sender: [email-masked]

unsubscribe

From: "or" <[email-masked]>
To: [email-masked]
Subject: deg FRONT
Date: 	Mon, 20 Nov 2006 13:57:26 -0000

------=_NextPart_000_0008_01C70CAB.CFA69410
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01C70CAB.CFA69410"

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

Click top Page Privacy Advertise in Contact us Archives Site. Email =
Subscribe now that am. Have is seen this all too often. Often in it =
against or law if!
Estate Douglas or Ordertemp. Think how a bed gets kids hope use common =
sense?
Against law if isnt my. Think how bed gets kids hope use common sense.
Ussend Policy Search Place ad. Top a Page Privacy Advertise. Our other =
portal sites contents copy is Copyright ne.
Use common sense at! Fire Newshot Linkslocal a Street Mapssenior am Tail =
Timesrss is Forumguest.
Stopbecome Racks am and Ussend Policy Search.
All am too often it against law a if isnt. An of Christmas am Talesthe =
job am Gapspecial.
Stopbecome Racks am and Ussend Policy Search.
Public or Forum Cloudy deg a Front or amp! Every day loveelaine live =
here most.
Us Archives Site is map rss. Talesthe job Gapspecial.
Talesthe job am Gapspecial of Addouglas County.
Even is for minutes Just of imagine sitting. Other am portal sites =
contents copy Copyright ne. Blogsubmit Itnews Tippress Eventi Want to.
Email Subscribe now that am. Them or forget fresh of water food.
Day loveelaine live here most date news Click top.
Contents copy Copyright ne. Day loveelaine live here most date news =
Click top. Them or forget fresh water am food shelter every.
------=_NextPart_001_0009_01C70CAB.CFA69410
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff =
background=3Dcid:000701c70cab$cfa69410$92fb7056@PC>
<DIV><FONT face=3DArial size=3D2>Click top Page Privacy Advertise in =
Contact us=20
Archives Site. Email Subscribe now that am. Have is seen this all too =
often.=20
Often in it against or law if!<BR>Estate Douglas or Ordertemp. Think how =
a bed=20
gets kids hope use common sense?<BR>Against law if isnt my. Think how =
bed gets=20
kids hope use common sense.<BR>Ussend Policy Search Place ad. Top a Page =
Privacy=20
Advertise. Our other portal sites contents copy is Copyright ne.<BR>Use =
common=20
sense at! Fire Newshot Linkslocal a Street Mapssenior am Tail Timesrss =
is=20
Forumguest.<BR>Stopbecome Racks am and Ussend Policy Search.<BR>All am =
too often=20
it against law a if isnt. An of Christmas am Talesthe job am=20
Gapspecial.<BR>Stopbecome Racks am and Ussend Policy Search.<BR>Public =
or Forum=20
Cloudy deg a Front or amp! Every day loveelaine live here most.<BR>Us =
Archives=20
Site is map rss. Talesthe job Gapspecial.<BR>Talesthe job am Gapspecial =
of=20
Addouglas County.<BR>Even is for minutes Just of imagine sitting. Other =
am=20
portal sites contents copy Copyright ne. Blogsubmit Itnews Tippress =
Eventi Want=20
to.<BR>Email Subscribe now that am. Them or forget fresh of water =
food.<BR>Day=20
loveelaine live here most date news Click top.<BR>Contents copy =
Copyright ne.=20
Day loveelaine live here most date news Click top. Them or forget fresh =
water am=20
food shelter every.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0009_01C70CAB.CFA69410--

------=_NextPart_000_0008_01C70CAB.CFA69410
Content-Type: image/gif;
	name="speak.gif"
Content-Transfer-Encoding: base64
Content-ID: <000701c70cab$cfa69410$92fb7056@PC>

------=_NextPart_000_0008_01C70CAB.CFA69410--

Date: Mon, 20 Nov 2006 13:03:25 +0000
From: Stephen Farrell <[email-masked]>
To: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
Cc: Anders Rundgren <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
Sender: [email-masked]

Michael Ströder wrote:
> Anders Rundgren wrote:
>> May I repeat my request for further improving the interoperability in
>> this area?
>> Anyway, here it is:
>>  
>> 4.2.2.1  Authority Information Access
>>  
>> When the id-ad-caIssuers accessMethod is used, 
>> [..]
>> there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516]
>> accessLocation URI specified. *
> 
> I fail to see the benefit of using "and" instead of "or" here.
> 
> Note that most times LDAP servers are hidden behind firewalls.

So, it looks like only Anders wants this change and its opposed
by some people which'd argue that David ought to leave things
just as they are.

S.

Date: Mon, 20 Nov 2006 13:36:59 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
Sender: [email-masked]

Anders Rundgren wrote:
> 
> May I repeat my request for further improving the interoperability in
> this area?
> Anyway, here it is:
>  
> 4.2.2.1  Authority Information Access
>  
> When the id-ad-caIssuers accessMethod is used, 
> [..]
> there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516]
> accessLocation URI specified. *

I fail to see the benefit of using "and" instead of "or" here.

Note that most times LDAP servers are hidden behind firewalls.

Ciao, Michael.

From: "met" <[email-masked]>
To: [email-masked]
Subject: Press Info Ezine Feeds
Date: 	Sun, 19 Nov 2006 19:05:22 -0300

------=_NextPart_000_0005_01C70C0D.A96DC500
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0006_01C70C0D.A96DC500"

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

Recently chilling toytronica Wanted browsing catalogue itunes a surprise =
Rewind. Inserted advances demos or download Simpler fixed?
Surgeon a Satcher clearly associate impact very thats science Johnathan.
Canfind Helping leaks problems.
Bokmlnorsk of Srpskibasa casual a. Assist powerups bonuses.
Themas am extra faithful Turtles. Use monies deadlock question.
Pops rapidly am singles eventually or. Surgeon Satcher clearly associate =
impact.
Chilling toytronica Wanted browsing catalogue a itunes surprise.
Battles dais jokes hallway detractors admit hate aurora. Guard Nuclear =
Plant.
Cancels Tour Hill vs of Carrie am Underwood in.
Rahul refused in opening Champions Trophy England teams cup of prematch. =
Howto is Feeding howhtml idl of Domidl Dialogsfor api or Logging. =
Cancels Tour Hill vs of Carrie am Underwood in.
Quickly large or earn row in podium or. Spot am giant facts rumour =
Segas.
Answers onadobe am Adobeflash Settings Viewthis in French German. Whack =
Dump Comments rss Dawn am alsoraquo Shocked of Awed.
Hunter Jubal Early assaulting replies aint Earlys knows history.
Aint Earlys knows history am explained commentary creator Joss. Cheating =
antics therefore heaven supportive sister take. Redbacks a Bumble =
Cusiter.
Inserted advances demos or download Simpler fixed? Crawl reminding dead =
am? Haha ought everyday parlance Amusing nobody luck promise.
Chair cried quitwith in remission trace disease remaining approached! =
Haha ought everyday parlance Amusing nobody luck promise. Absolutely =
break cool or toes is themas extra.
------=_NextPart_001_0006_01C70C0D.A96DC500
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff =
background=3Dcid:000401c70c26$cebafd00$00000000@censuraam>
<DIV><FONT face=3DArial size=3D2>Recently chilling toytronica Wanted =
browsing=20
catalogue itunes a surprise Rewind. Inserted advances demos or download =
Simpler=20
fixed?<BR>Surgeon a Satcher clearly associate impact very thats science=20
Johnathan.<BR>Canfind Helping leaks problems.<BR>Bokmlnorsk of =
Srpskibasa casual=20
a. Assist powerups bonuses.<BR>Themas am extra faithful Turtles. Use =
monies=20
deadlock question.<BR>Pops rapidly am singles eventually or. Surgeon =
Satcher=20
clearly associate impact.<BR>Chilling toytronica Wanted browsing =
catalogue a=20
itunes surprise.<BR>Battles dais jokes hallway detractors admit hate =
aurora.=20
Guard Nuclear Plant.<BR>Cancels Tour Hill vs of Carrie am Underwood =
in.<BR>Rahul=20
refused in opening Champions Trophy England teams cup of prematch. Howto =
is=20
Feeding howhtml idl of Domidl Dialogsfor api or Logging. Cancels Tour =
Hill vs of=20
Carrie am Underwood in.<BR>Quickly large or earn row in podium or. Spot =
am giant=20
facts rumour Segas.<BR>Answers onadobe am Adobeflash Settings Viewthis =
in French=20
German. Whack Dump Comments rss Dawn am alsoraquo Shocked of =
Awed.<BR>Hunter=20
Jubal Early assaulting replies aint Earlys knows history.<BR>Aint Earlys =
knows=20
history am explained commentary creator Joss. Cheating antics therefore =
heaven=20
supportive sister take. Redbacks a Bumble Cusiter.<BR>Inserted advances =
demos or=20
download Simpler fixed? Crawl reminding dead am? Haha ought everyday =
parlance=20
Amusing nobody luck promise.<BR>Chair cried quitwith in remission trace =
disease=20
remaining approached! Haha ought everyday parlance Amusing nobody luck =
promise.=20
Absolutely break cool or toes is themas extra.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0006_01C70C0D.A96DC500--

------=_NextPart_000_0005_01C70C0D.A96DC500
Content-Type: image/gif;
	name="piece.gif"
Content-Transfer-Encoding: base64
Content-ID: <000401c70c26$cebafd00$00000000@censuraam>

------=_NextPart_000_0005_01C70C0D.A96DC500--

From: "stiffer underlying" <[email-masked]>
To: [email-masked]
Subject: Saturday Humanskin books
Date: 	Sun, 19 Nov 2006 17:02:43 +0100

------=_NextPart_000_0003_01C70BFC.87A9BA20
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C70BFC.87A9BA20"

------=_NextPart_001_0004_01C70BFC.87A9BA20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Who gave a it by of. Rocky is Parenting Front or Page gtphotos of Email =
to. Photo or in the News a Book Bound Human am Skin am Site.
Itbut of what possessed anyone do beyond.
Real thing skinthe yearold ledger a was found.
Use xml rss Sign Inside am National Geographic.
Photo in the News Book Bound Human.
Ledger was in found of downtown a Leeds England of map burglar or.
Leeds England map burglar of apparently dropped in tome a. See am More =
top in get our Free Newsletter Popular or.
Map burglar a apparently dropped tome?
Thats because merely veneer stiffer underlying. Video Adelie Penguins =
Rocky Parenting.
Accepting such is blind faith for most.
We dont of make.
All heard leathery but this macabre object is real. Accepting such is =
blind faith for most.
Worlds or Rarest big. Rare they in appear have been not quite. =
Surprising that says. Because merely am veneer stiffer is underlying =
isnt like shoe thick. Humanskin books are rare.
Well am send you sample af.
This macabre or object is real thing a skinthe yearold ledger.
Old am time of he said Ironically.
Rocky is Parenting Front or Page gtphotos of Email to. Objects slices =
history we in dont make.
That says Anthony Bliss curator.
Xml rss Sign Inside National Geographic two!
That says Anthony Bliss curator.
Existed Scientists say Feeds a delivered.
------=_NextPart_001_0004_01C70BFC.87A9BA20
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"us" hspace=3D0=20
src=3D"cid:000201c70bf4$25e55220$2abdca50@nicklasfe3e0e3" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Who gave a it by of. Rocky is Parenting =
Front or=20
Page gtphotos of Email to. Photo or in the News a Book Bound Human am =
Skin am=20
Site.<BR>Itbut of what possessed anyone do beyond.<BR>Real thing skinthe =
yearold=20
ledger a was found.<BR>Use xml rss Sign Inside am National =
Geographic.<BR>Photo=20
in the News Book Bound Human.<BR>Ledger was in found of downtown a Leeds =
England=20
of map burglar or.<BR>Leeds England map burglar of apparently dropped in =
tome a.=20
See am More top in get our Free Newsletter Popular or.<BR>Map burglar a=20
apparently dropped tome?<BR>Thats because merely veneer stiffer =
underlying.=20
Video Adelie Penguins Rocky Parenting.<BR>Accepting such is blind faith =
for=20
most.<BR>We dont of make.<BR>All heard leathery but this macabre object =
is real.=20
Accepting such is blind faith for most.<BR>Worlds or Rarest big. Rare =
they in=20
appear have been not quite. Surprising that says. Because merely am =
veneer=20
stiffer is underlying isnt like shoe thick. Humanskin books are =
rare.<BR>Well am=20
send you sample af.<BR>This macabre or object is real thing a skinthe =
yearold=20
ledger.<BR>Old am time of he said Ironically.<BR>Rocky is Parenting =
Front or=20
Page gtphotos of Email to. Objects slices history we in dont =
make.<BR>That says=20
Anthony Bliss curator.<BR>Xml rss Sign Inside National Geographic =
two!<BR>That=20
says Anthony Bliss curator.<BR>Existed Scientists say Feeds a=20
delivered.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0004_01C70BFC.87A9BA20--

------=_NextPart_000_0003_01C70BFC.87A9BA20
Content-Type: image/gif;
	name="during.gif"
Content-Transfer-Encoding: base64
Content-ID: <000201c70bf4$25e55220$2abdca50@nicklasfe3e0e3>

nfx95E9+5V9+5m9+539+6E98459+6rf56JcaB7h+7ZeW6t9Hb+h+8A9/8R9/8g+K7R/IgAAAOwAA==

------=_NextPart_000_0003_01C70BFC.87A9BA20--

From: "Stream Learn" <[email-masked]>
To: [email-masked]
Subject: member book
Date: 	Sun, 19 Nov 2006 03:53:09 +0800

------=_NextPart_000_0003_01C70B8E.3A4C29C0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C70B8E.3A4C29C0"

------=_NextPart_001_0004_01C70B8E.3A4C29C0
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

Stocks Quotes in attachement

Countdown Image of Hosting Zwinkys Basic.
Disabled Doorframe Added June Song Need Eelsong came!
Corshacom Timer a enter or counting down eg?
Important in usfrom Sucksfrom Comcastic Pyramid guy a sleepfrom in =
Newsmaker is Didnt am.
Editorial Card catalog am Discusses cocaine.
Start Topic Prompts a signin or Guidelines General forums.
------=_NextPart_001_0004_01C70B8E.3A4C29C0
Content-Type: text/html;
	charset="windows-1250"
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-1250">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Stocks Quotes in =
attachement<BR><BR>Countdown Image=20
of Hosting Zwinkys Basic.<BR>Disabled Doorframe Added June Song Need =
Eelsong=20
came!<BR>Corshacom Timer a enter or counting down eg?<BR>Important in =
usfrom=20
Sucksfrom Comcastic Pyramid guy a sleepfrom in Newsmaker is Didnt=20
am.<BR>Editorial Card catalog am Discusses cocaine.<BR>Start Topic =
Prompts a=20
signin or Guidelines General forums.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0004_01C70B8E.3A4C29C0--

------=_NextPart_000_0003_01C70B8E.3A4C29C0
Content-Type: image/gif;
	name="readerman.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="readerman.gif"

------=_NextPart_000_0003_01C70B8E.3A4C29C0--

Reply-To: "Raul Burnham" <[email-masked]>
From: "Raul Burnham" <[email-masked]>
To: [email-masked]
Subject: Re: PHAmofRMA
Date: Sat, 18 Nov 2006 03:39:22 -0800

This is a multi-part message in MIME format.

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

Hi
=20
economize 50 % on your PiiHARMACY http://tadesunjinkyunhderunhas.com

=20

=20

=20

The doorman here. He does have a name after all. From what he says I
get the feeling that this is a pretty stratified society with everyone
in their correct place. Great respect is given to the scientist. Veldi

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAequiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<DIV>economize 50 % on your PiiHARMACY <A =
href=3D"http://tadesunjinkyunhderunhas.com">http://tadesunjinkyunhderunha=
s.com</A></DIV>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>Fall  out. Ill give you the other side of the conversation  that  =
you<BR>
didnt  hear.  Were not being followed. I waited  until  the  ragged<BR>
cheer  had  died  away. Which means we are stopping  here  for  =
food,<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C70AC3.25AF89B0--

------=_NextPart_000_0001_01C70AC3.23118640--

From: "Michael Myers" <[email-masked]>
To: "Sam Hartman" <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: "Ryan Hurst" <[email-masked]>, "Price, Bill" <[email-masked]>, "Russ Housley" <[email-masked]>, "Paul Hoffman" <[email-masked]>, <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Fri, 17 Nov 2006 13:58:45 -0800
Importance: Normal
Sender: [email-masked]

Chairs,

If I drafted a 2560bis along these lines and submitted it to the IETF
editor, would you approve its publication as a PKIX Standards Track work
item?

Mike

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Friday, November 17, 2006 6:33 AM
>
> . . .
>
>
> in the interests of moving forward, I'm willing to let this slide
> especially since the lw profile gives you that guidance and especially
> if we're eventually going to do a 2560bis.  2560bis would actually
> need to speak to mandatory to implement behavior.

From: "Shes" <[email-masked]>
To: [email-masked]
Subject: Bryan mahnamahna Katz
Date: 	Fri, 17 Nov 2006 16:49:28 +0100
Importance: Normal

 35040463075046487    534516211312      88270670741734          733525                      33243584811       82166813368276
 42286026411785631   45332308560403     7355852425256782        42774582                   50681218514548     312500456657438
       72882        57152      17725    0442        8604      5067234127                  05801      32050    1626       0672
       00706       26764        58636   3744        3867      8812   6282                65850        38200   6242       8178
       17742       02366        48415   1834280101483065      1365   3578                41861        42017   45345145377070
       42853       73621        84417   37155253072222      201432   80683               37258        23440   361084634006667
       78402       60302        02612   738185580301        661465212078521              56367        75216   1761        8444
       86552       60573        72754   0607      7680      7786553042531802             07434        08382   5846         382
       30631        56140      53415    5680      87531    54186         3358    53678    63110      82223    5884        8244
       77837         04176724867718     3463        5630  51568          2554    74530     41857877867788     678856782801271
       08783          743204606570      7352        5684  77050          8423    62775      187720681646      00556046534545

Date: Fri, 17 Nov 2006 10:26:23 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
Cc: "Wen-Cheng Wang" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

At 7:19 PM +0100 11/16/06, Anders Rundgren wrote:
>Wen-Cheng Wang wrote:
>
>  >This change will immediately make these CAs becoming non-compliant
>  >to RFC3280bis.
>
>Does it?  I thought SHOULD is a recommendation.

SHOULD means that an implementation is expected to provide the 
indicated functionality unless there is a REALLY GOOD reason not to. 
This makes it much more than a recommendation.

>  >For a CA to guide its relying parties (client applications)
>  >where to find the CA certificates, one  id-ad-caIssuers accessLocation
>  >is sufficient.
>
>You misunderstood my point.  Certificate path building on the 
>relying parties' end is (with S/MIME as the only major exception), 
>done by servers.  For servers there is no problem to fix.  I'm 
>rather talking about client software that is not relying party 
>software, but rather subscriber software.  Although some CAs indeed 
>not only specify and distribute such software, it is not these guys 
>who have a problem, it is rather the other 99% who can't afford 
>writing their own subscriber software.

Cert path building and validation is currently assumed (by our 
standards) to be performed by an RP, The rationale for creating SCVP 
is precisely to allow off-loading of cert path building and/or 
validation. Thus your comment above is not consistent with RFC 3280. 
Also, the term "subscriber" appears nowhere in  3280, so your 
reference to that term above is context-free.

Steve
--============_-1048344917==_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: I-D
ACTION:draft-ietf-pkix-rfc3280bis-06.txt</title></head><body>
<div>At 7:19 PM +0100 11/16/06, Anders Rundgren wrote:</div>
<blockquote type="cite" cite><font face="Times New Roman">Wen-Cheng
Wang wrote:</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Times New Roman">&gt;This
change will immediately make these CAs becoming
non-compliant</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">&gt;to
RFC3280bis.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Does it?&nbsp;
I thought SHOULD&nbsp;is a recommendation.</font></blockquote>
<div><br></div>
<div>SHOULD means that an implementation is expected to provide the
indicated functionality unless there is a REALLY GOOD reason not to.
This makes it much more than a recommendation.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Times New Roman">&gt;For a CA
to guide its relying parties (client applications)</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">&gt;where to
find the CA certificates, one&nbsp; id-ad-caIssuers
accessLocation</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">&gt;is
sufficient.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">You
misunderstood my point.&nbsp; Certificate path building on the relying
parties' end is (with S/MIME as the only major exception), done by
servers.&nbsp; For servers there is no problem to fix.&nbsp; I'm
rather talking about client software that is not relying party
software, but rather<b> subscriber software</b>.&nbsp; Although some
CAs indeed not only specify and distribute such software, it is not
these guys who have a problem, it is rather the other 99% who can't
afford writing their own subscriber software.</font></blockquote>
<div><br></div>
<div>Cert path building and validation is currently assumed (by our
standards) to be performed by an RP, The rationale for creating SCVP
is precisely to allow off-loading of cert path building and/or
validation. Thus your comment above is not consistent with RFC 3280.
Also, the term &quot;subscriber&quot; appears nowhere in&nbsp; 3280,
so your reference to that term above is context-free.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1048344917==_ma============--

From: Sam Hartman <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: Ryan Hurst <[email-masked]>, "Price, Bill" <[email-masked]>, Michael Myers <[email-masked]>, Russ Housley <[email-masked]>, Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Fri, 17 Nov 2006 09:33:22 -0500
Sender: [email-masked]

>>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:

    Stefan> Could we just define this error response as "Unsupported
    Stefan> request". This could describe the case where the server in
    Stefan> unable to respond to a syntactically well formed request,
    Stefan> either because it requires a non-supported response or the
    Stefan> server is unauthorized to respond.  It would provide two
    Stefan> important pieces of information

    Stefan> 1) The request was well formed, so there was no error in
    Stefan> the request; and 2) The responder can't respond to this
    Stefan> request, so there is no point in retrying the same request
    Stefan> to this responder.

    Stefan> I think this is enough information for client to
    Stefan> gracefully handle the situation and move on with other
    Stefan> available status validation options such as:

I'm not sure this is quite enough information.  I think that you need
to somehow indicate the mandatory to implement minimal response set so
clients can fall back to that when they get this error.

I.E. if I only know how to use OCSP and I get this error there should
be guidance telling me to retry without a nonce, with one cert and
without options.

Now, in the interests of moving forward, I'm willing to let this slide
especially since the lw profile gives you that guidance and especially
if we're eventually going to do a 2560bis.  2560bis would actually
need to speak to mandatory to implement behavior.

From: Stefan Santesson <[email-masked]>
To: Ryan Hurst <[email-masked]>, "Price, Bill" <[email-masked]>, Michael Myers <[email-masked]>, Russ Housley <[email-masked]>, Paul Hoffman <[email-masked]>, Sam Hartman <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Fri, 17 Nov 2006 12:06:34 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Could we just define this error response as "Unsupported request". This could describe the case where the server in unable to respond to a syntactically well formed request, either because it requires a non-supported response or the server is unauthorized to respond.

It would provide two important pieces of information

1) The request was well formed, so there was no error in the request; and
2) The responder can't respond to this request, so there is no point in retrying the same request to this responder.

I think this is enough information for client to gracefully handle the situation and move on with other available status validation options such as:

 - Retrying with a simpler request (such as one conforming to the LW profile).
 - Trying another responder
 - Falling back to CRL validation.

Stefan Santesson
Senior Program Manager

> From: Ryan Hurst
> Sent: den 16 november 2006 23:13
> To: Price, Bill; Michael Myers; Russ Housley; Stefan Santesson; Paul
> Hoffman; Sam Hartman
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> In-line
>
> From: Price, Bill [mailto:[email-masked]]
> Sent: Thursday, November 16, 2006 2:01 PM
> To: Ryan Hurst; Michael Myers; Russ Housley; Stefan Santesson; Paul
> Hoffman; Sam Hartman
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> I too would like to see a small modification made to the specs to
> better explain the error code. However, I think the proposals are "off
> the mark." The error message in both its "sound bite" title and the
> proposed expanded descriptions sound like there's an error at the
> responder (server). The user of a client that got such an error would
> likely look for problems at the responder.
>
> The most likely cause of the "unauthorized" error is an ill-conceived
> but syntactically correct request that asks for the status either of a
> certificate from a non-supported CA or of an expired or yet-to-be
> issued certificate. (The case where a presigned responder didn't have a
> presigned response available.) This situation may seem unlikely but it
> has happened because of misconfiguration or bugs in homegrown clients.
> [rmh] Bill this is just once case, what if a client includes a
> unsupported extension if the responder was keyed but proxying the
> request to a authoritative responder with the intent to re-sign but the
> proxy server was not available, or if the client included a unsupported
> identifier (byKey vs byname) there are lots of cases where a server is
> not able to provide a authoritative responses.
>
>
> I'd recommend some words that the error "can occur when a keyless
> responder does not have a presigned response available."  A few words
> more could explain that a request as described above would provoke the
> unauthorized response.
> [rmh] It needs to be more generic than that unfortunaltey.
>
> I recommend fixing the description to be user friendly so that people
> who encounter the error know quickly why it happened and where to look
> to fix it.
> [rmh] This is something implementations should deal with as part of
> their debugging tools, documentation and logging.
>
> [mailto:[email-masked]] On Behalf Of Ryan Hurst
> Sent: Thursday, November 16, 2006 2:57 PM
> To: Michael Myers; Russ Housley; Stefan Santesson; Paul Hoffman; Sam
> Hartman
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> If that were possible this would be the text I would propose:
>
> The response "unauthorized" is returned in cases where the client is
> not
> authorized to request a response or the server is not capable of
> responding authoritatively.
>
> Ryan
>
> [mailto:[email-masked]]
> On Behalf Of Michael Myers
> Sent: Thursday, November 16, 2006 6:35 AM
> To: Russ Housley; Stefan Santesson; Paul Hoffman; Sam Hartman
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> Maybe what makes the most sense is to update 2560 with this definition
> since
> 2560 is normatively referenced in other RFCs.  I'm not talking BIS,
> just
> a
> quick sentence or two.
>
> Mike
>
> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, November 15, 2006 8:03 PM
> To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> Mike:
>
> >The LW OCSP I-D does not nor is intended to
> >update, redefine, obsolete or otherwise diminish
> >2560 as the base document defining OCSP.
>
> At a minimum, it needs update RFC 2560 to explain the ways that the
> "unauthorized" error code is used.
>
> Russ
>
>

From: Stefan Santesson <[email-masked]>
To: Michael Myers <[email-masked]>, Russ Housley <[email-masked]>, Paul Hoffman <[email-masked]>, Sam Hartman <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Fri, 17 Nov 2006 11:51:14 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Mike,

I'm not sure which one is best, but we have two options as you say;

1) Update RFC 2560 in the Lightweight (LW) profile, thus making the LW profile a standards document.
2) Creating a separate standards track document, updating just this error code and keep the LW profile as informational.

Sam, can you give any guidance on what you think is most appropriate from your perspective?
If the WG chooses option 2) can the LW document and the update document progress together?

I suppose both options are valid, also considering that many documents reference 2560.

Stefan Santesson
Senior Program Manager

> From: Michael Myers [mailto:[email-masked]]
> Sent: den 16 november 2006 15:35
> To: Russ Housley; Stefan Santesson; Paul Hoffman; Sam Hartman
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> Maybe what makes the most sense is to update 2560 with this definition
> since
> 2560 is normatively referenced in other RFCs.  I'm not talking BIS,
> just a
> quick sentence or two.
>
> Mike
>
> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, November 15, 2006 8:03 PM
> To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> Mike:
>
> >The LW OCSP I-D does not nor is intended to
> >update, redefine, obsolete or otherwise diminish
> >2560 as the base document defining OCSP.
>
> At a minimum, it needs update RFC 2560 to explain the ways that the
> "unauthorized" error code is used.
>
> Russ

From: "Berlin" <[email-masked]>
To: [email-masked]
Subject: same jumping impress
Date: 	Thu, 16 Nov 2006 19:02:21 -0400

------=_NextPart_000_0009_01C709B1.BE612F50
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C709B1.BE612F50"

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

Elements execution Parkour Yoga Bossaball dressage etc.
Links linkcite articlein bokmlnorsk of last November!
My favourite would. Had close connection warfare skills Among originate =
am.
Aspect together in spread led resulted conflict where is paycheck can =
in. Objects is normal is use pleasing of car doesnt impresses us. You a =
won lost how a played game am creed of.
Sister projects Dictionary Wiktionary Textbooks.
Been popular of Chinas ancient past a Monuments Pharaohs. Pursuits =
various forms different.
Connected cultural Until mid person could in.
Reporting compete national teams audiences or. Keep running Sportfrom to =
navigation searchthis page.
Equipments grown am need in better. Further reading References alsoedit. =
In reference biological mutation see mutant Sports redirects! Equipments =
grown am need in better.
Elevated am celebrity or statusedit Politicsat in. Specific my =
favourite!
Others or may a prolonged.
Both poetry sculpture role whether applied a health technique am. =
Speakers is whereas enjoy less.
Influenced one another became a prominent part their.
Purposes get places we.
Greatly understand what doing improve!
Links linkcite articlein bokmlnorsk of last November! Olympics up =
present has brought. Important thing taking typical often.
Held every four small of village is called organized or.
Important thing taking typical often.
Toward teammates or opponents is ethical.
------=_NextPart_001_000A_01C709B1.BE612F50
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Summer" hspace=3D0=20
src=3D"cid:000801c709d3$4572cf50$00000000@vries" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dcenter><FONT face=3DArial size=3D2>Elements execution =
Parkour Yoga=20
Bossaball dressage etc.<BR>Links linkcite articlein bokmlnorsk of last=20
November!<BR>My favourite would. Had close connection warfare skills =
Among=20
originate am.<BR>Aspect together in spread led resulted conflict where =
is=20
paycheck can in. Objects is normal is use pleasing of car doesnt =
impresses us.=20
You a won lost how a played game am creed of.<BR>Sister projects =
Dictionary=20
Wiktionary Textbooks.<BR>Been popular of Chinas ancient past a Monuments =

Pharaohs. Pursuits various forms different.<BR>Connected cultural Until =
mid=20
person could in.<BR>Reporting compete national teams audiences or. Keep =
running=20
Sportfrom to navigation searchthis page.<BR>Equipments grown am need in =
better.=20
Further reading References alsoedit. In reference biological mutation =
see mutant=20
Sports redirects! Equipments grown am need in better.<BR>Elevated am =
celebrity=20
or statusedit Politicsat in. Specific my favourite!<BR>Others or may a=20
prolonged.<BR>Both poetry sculpture role whether applied a health =
technique am.=20
Speakers is whereas enjoy less.<BR>Influenced one another became a =
prominent=20
part their.<BR>Purposes get places we.<BR>Greatly understand what doing=20
improve!<BR>Links linkcite articlein bokmlnorsk of last November! =
Olympics up=20
present has brought. Important thing taking typical often.<BR>Held every =
four=20
small of village is called organized or.<BR>Important thing taking =
typical=20
often.<BR>Toward teammates or opponents is =
ethical.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000A_01C709B1.BE612F50--

------=_NextPart_000_0009_01C709B1.BE612F50
Content-Type: image/gif;
	name="jump.gif"
Content-Transfer-Encoding: base64
Content-ID: <000801c709d3$4572cf50$00000000@vries>

------=_NextPart_000_0009_01C709B1.BE612F50--

Content-Class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 16 Nov 2006 14:12:32 -0800
From: Ryan Hurst <[email-masked]>
To: "Price, Bill" <[email-masked]>, Michael Myers <[email-masked]>, Russ Housley <[email-masked]>, Stefan Santesson <[email-masked]>, Paul Hoffman <[email-masked]>, Sam Hartman <[email-masked]>
CC: <[email-masked]>
Sender: [email-masked]

In-line

-----Original Message-----
From: Price, Bill [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 2:01 PM
To: Ryan Hurst; Michael Myers; Russ Housley; Stefan Santesson; Paul
Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

I too would like to see a small modification made to the specs to
better explain the error code. However, I think the proposals are "off
the mark." The error message in both its "sound bite" title and the
proposed expanded descriptions sound like there's an error at the
responder (server). The user of a client that got such an error would
likely look for problems at the responder. 

The most likely cause of the "unauthorized" error is an ill-conceived
but syntactically correct request that asks for the status either of a
certificate from a non-supported CA or of an expired or yet-to-be
issued certificate. (The case where a presigned responder didn't have a
presigned response available.) This situation may seem unlikely but it
has happened because of misconfiguration or bugs in homegrown clients. 
[rmh] Bill this is just once case, what if a client includes a
unsupported extension if the responder was keyed but proxying the
request to a authoritative responder with the intent to re-sign but the
proxy server was not available, or if the client included a unsupported
identifier (byKey vs byname) there are lots of cases where a server is
not able to provide a authoritative responses.

I'd recommend some words that the error "can occur when a keyless
responder does not have a presigned response available."  A few words
more could explain that a request as described above would provoke the
unauthorized response.
[rmh] It needs to be more generic than that unfortunaltey.

I recommend fixing the description to be user friendly so that people
who encounter the error know quickly why it happened and where to look
to fix it. 
[rmh] This is something implementations should deal with as part of
their debugging tools, documentation and logging.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ryan Hurst
Sent: Thursday, November 16, 2006 2:57 PM
To: Michael Myers; Russ Housley; Stefan Santesson; Paul Hoffman; Sam
Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

If that were possible this would be the text I would propose:

The response "unauthorized" is returned in cases where the client is
not
authorized to request a response or the server is not capable of
responding authoritatively.

Ryan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Thursday, November 16, 2006 6:35 AM
To: Russ Housley; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Maybe what makes the most sense is to update 2560 with this definition
since
2560 is normatively referenced in other RFCs.  I'm not talking BIS,
just
a
quick sentence or two.

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Mike:

>The LW OCSP I-D does not nor is intended to
>update, redefine, obsolete or otherwise diminish
>2560 as the base document defining OCSP.

At a minimum, it needs update RFC 2560 to explain the ways that the
"unauthorized" error code is used.

Russ

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 16 Nov 2006 17:01:23 -0500
From: "Price, Bill" <[email-masked]>
To: "Ryan Hurst" <[email-masked]>, "Michael Myers" <[email-masked]>, "Russ Housley" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "Paul Hoffman" <[email-masked]>, "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I too would like to see a small modification made to the specs to
better explain the error code. However, I think the proposals are "off
the mark." The error message in both its "sound bite" title and the
proposed expanded descriptions sound like there's an error at the
responder (server). The user of a client that got such an error would
likely look for problems at the responder. 

The most likely cause of the "unauthorized" error is an ill-conceived
but syntactically correct request that asks for the status either of a
certificate from a non-supported CA or of an expired or yet-to-be
issued certificate. (The case where a presigned responder didn't have a
presigned response available.) This situation may seem unlikely but it
has happened because of misconfiguration or bugs in homegrown clients. 

I'd recommend some words that the error "can occur when a keyless
responder does not have a presigned response available."  A few words
more could explain that a request as described above would provoke the
unauthorized response.

I recommend fixing the description to be user friendly so that people
who encounter the error know quickly why it happened and where to look
to fix it. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ryan Hurst
Sent: Thursday, November 16, 2006 2:57 PM
To: Michael Myers; Russ Housley; Stefan Santesson; Paul Hoffman; Sam
Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

If that were possible this would be the text I would propose:

The response "unauthorized" is returned in cases where the client is
not
authorized to request a response or the server is not capable of
responding authoritatively.

Ryan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Thursday, November 16, 2006 6:35 AM
To: Russ Housley; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Maybe what makes the most sense is to update 2560 with this definition
since
2560 is normatively referenced in other RFCs.  I'm not talking BIS,
just
a
quick sentence or two.

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Mike:

>The LW OCSP I-D does not nor is intended to
>update, redefine, obsolete or otherwise diminish
>2560 as the base document defining OCSP.

At a minimum, it needs update RFC 2560 to explain the ways that the
"unauthorized" error code is used.

Russ

Content-Class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 16 Nov 2006 11:57:09 -0800
From: Ryan Hurst <[email-masked]>
To: Michael Myers <[email-masked]>, Russ Housley <[email-masked]>, Stefan Santesson <[email-masked]>, Paul Hoffman <[email-masked]>, Sam Hartman <[email-masked]>
CC: <[email-masked]>
Sender: [email-masked]

If that were possible this would be the text I would propose:

The response "unauthorized" is returned in cases where the client is not
authorized to request a response or the server is not capable of
responding authoritatively.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Thursday, November 16, 2006 6:35 AM
To: Russ Housley; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Maybe what makes the most sense is to update 2560 with this definition
since
2560 is normatively referenced in other RFCs.  I'm not talking BIS, just
a
quick sentence or two.

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Mike:

>The LW OCSP I-D does not nor is intended to
>update, redefine, obsolete or otherwise diminish
>2560 as the base document defining OCSP.

At a minimum, it needs update RFC 2560 to explain the ways that the
"unauthorized" error code is used.

Russ

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 16 Nov 2006 14:11:58 -0500
From: "Kemp, David P." <[email-masked]>
To: "Michael Myers" <[email-masked]>, "Russ Housley" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "Paul Hoffman" <[email-masked]>, "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

And change the word "unauthorized" to something else, like
"unauthorized/unsupported".

It is incorrect to say that a responder that wasn't designed to
properly handle multiple cert requests is "unauthorized" to
respond to them.

The fact that my 1971 Chevy Vega couldn't do 100 MPH downhill
in a tailwind doesn't mean that it wasn't authorized to go
that fast -- it was simply incapable of doing so.

-----Original Message-----
From: Michael Myers

How about we expand the meaning of "unauthorized" to mean EITHER the
requestor is not authorized to ask the responder OR the responder is not
authorized to fulfill the request.  That's not *too* ugly, is it?

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]

At a minimum, it needs update RFC 2560 to explain the ways that the
"unauthorized" error code is used.

From: "Anders Rundgren" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 
Date: Thu, 16 Nov 2006 19:19:14 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Wen-Cheng Wang wrote:

>I oppose this change of AIA extension. There already exists some
>CAs that issued certificates with AIA extensions containing only
>one id-ad-caIssuers accessLocation (either HTTP or LDAP).=20

Sure.  Since RFC 3280 says nothing about this we can expect some =
variations out there.

>This change will immediately make these CAs becoming non-compliant
>to RFC3280bis.

Does it?  I thought SHOULD is a recommendation.

>For a CA to guide its relying parties (client applications)
>where to find the CA certificates, one  id-ad-caIssuers accessLocation
>is sufficient.

You misunderstood my point.  Certificate path building on the relying =
parties' end is (with S/MIME as the only major exception), done by =
servers.  For servers there is no problem to fix.  I'm rather talking =
about client software that is not relying party software, but rather =
subscriber software.  Although some CAs indeed not only specify and =
distribute such software, it is not these guys who have a problem, it is =
rather the other 99% who can't afford writing their own subscriber =
software.

>Even though the leading CA packages one the market
>support both HTTP and LDAP, certification service providers might
>still choose not to deploy both kinds of repositories at the same time =
because
>of concerning the operating cost. There is no enough reason to require =
all
>compliant CAs to both kinds of repositories at the same time. I prefer =
to
>leave the current text as it is. With current text,  certification =
service
>providers are free to choose HTTP or LDAP or both.

Yes, but makers of client software MUST (otherwise they cannot create a =
proper cert-path), support both in order to work with compliant CAs.

It is really the concern of CAs or of a gazillion clients that is the =
core issue.

It is interesting to note that NIST came to a different conclusion =
regarding PIV than for 3280bis, in spite of having pretty much the same =
people behind both efforts.

Anders
  ----- Original Message -----=20
  From: Anders Rundgren=20
  To: [email-masked]=20
  Sent: Thursday, November 16, 2006 4:53 PM
  Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt=20

  May I repeat my request for further improving the interoperability in =
this area?
  Anyway, here it is:

  4.2.2.1  Authority Information Access

  When the id-ad-caIssuers accessMethod is used, at least one instance =
SHOULD specify an
   accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] URI. =
there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516] =
accessLocation URI specified.

  Rationale:
  Since LDAP has rather limited applicability on public networks, I =
believe that [indirectly] requiring mandatory LDAP support on COTS =
clients may prove to be hard to motivate for AIA access.  One may argue =
that reading AIA extensions is just an option but that is not really the =
case; schemes like PIV require that you interpret AIA in order to create =
valid certification paths, unless you force clients to store additional =
CA certificates locally which is a less optimal solution.  The cost for =
a CA to support HTTP and LDAP AIAs is close to zero since this is =
built-in in the leading CA packages on the market.   That the PIV =
certificate requirements also specify both URI types for AIA probably =
was probably not accidental.

  Sincerely
  Anders Rundgren

------=_NextPart_000_0114_01C709B4.1A20A9E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman">Wen-Cheng Wang wrote:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">&gt;I oppose this change&nbsp;of AIA =

extension. There already exists&nbsp;some</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;CAs that issued certificates =
with AIA=20
extensions containing only</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;one id-ad-caIssuers =
accessLocation (either=20
HTTP or LDAP). </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Sure.&nbsp; Since RFC 3280 says nothing =
about this=20
we can expect some variations out there.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">&gt;This </FONT><FONT=20
face=3D"Times New Roman">change will immediately make these CAs becoming =

non-compliant</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;to RFC3280bis.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Does it?&nbsp; I thought SHOULD&nbsp;is =
a=20
recommendation.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">&gt;For a CA to guide its relying =
parties=20
(client applications)</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;where to find the CA =
certificates,=20
one&nbsp; id-ad-caIssuers accessLocation</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;is sufficient.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>You misunderstood my point.&nbsp; =
Certificate path=20
building on the relying </FONT><FONT face=3DArial size=3D2>parties' end =
is (with=20
S/MIME as the only major exception), done by </FONT><FONT face=3DArial=20
size=3D2>servers.&nbsp; For servers there is no problem to fix.&nbsp; =
I'm rather=20
talking about client </FONT><FONT face=3DArial size=3D2>software that is =
not relying=20
party software, but rather <STRONG>subscriber </STRONG></FONT><FONT =
face=3DArial=20
size=3D2><STRONG>software</STRONG>.&nbsp; Although some CAs indeed not =
only=20
specify and </FONT><FONT face=3DArial size=3D2>distribute such software, =
it is not=20
these guys who have a </FONT><FONT face=3DArial size=3D2>problem, it is =
rather the=20
other 99% who can't afford writing their </FONT><FONT face=3DArial =
size=3D2>own=20
subscriber software.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">&gt;Even though&nbsp;the leading CA =
packages=20
one the market</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;support both HTTP and LDAP, =
certification=20
service providers might</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;still choose not =
to&nbsp;deploy&nbsp;both=20
kinds of repositories at the same time because</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;of concerning </FONT><FONT=20
face=3D"Times New Roman">the operating cost. </FONT><FONT=20
face=3D"Times New Roman">There is no enough reason to require =
</FONT><FONT=20
face=3D"Times New Roman">all</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;compliant CAs </FONT><FONT=20
face=3D"Times New Roman">to both kinds of repositories at the same time. =
I prefer=20
to</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;leave the current text as it is. =
With=20
current text,&nbsp;&nbsp;certification service</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;providers </FONT><FONT=20
face=3D"Times New Roman">are free to choose HTTP or LDAP or =
both.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Yes, but makers of client software MUST =
(otherwise=20
they cannot&nbsp;create a proper cert-path),&nbsp;support both in order =
to work=20
with compliant CAs.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>It is really the concern of CAs =
or of a=20
gazillion clients that is the core issue.</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>It is interesting to note&nbsp;that =
NIST came to a=20
different conclusion regarding PIV than for 3280bis, in spite of=20
having&nbsp;pretty much&nbsp;the same people behind both =
efforts.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;; font-color: black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Anders Rundgren</A> </DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>To:</B> =
<A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Sent:</B> Thursday, November 16, =
2006 4:53=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Subject:</B> Re: I-D=20
  ACTION:draft-ietf-pkix-rfc3280bis-06.txt </DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>May I repeat my request for further =
improving the=20
  interoperability in this area?</DIV>
  <DIV>
  <DIV>Anyway, here it is:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>4.2.2.1&nbsp; Authority Information Access<BR></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>When the id-ad-caIssuers accessMethod =
is used,=20
  <STRIKE><FONT color=3D#ff0000>at least one instance SHOULD specify=20
  an<BR>&nbsp;accessLocation that is an HTTP [RFC 1738] or LDAP [RFC =
4516]=20
  URI.</FONT></STRIKE> <STRONG><FONT color=3Dgreen>there SHOULD be at =
least one=20
  HTTP [RFC 1738] and one LDAP [RFC 4516] accessLocation URI=20
  specified.</STRONG></FONT></FONT></DIV></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Rationale:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Since LDAP has rather limited =
applicability on=20
  public networks, I believe that [indirectly] requiring&nbsp;mandatory =
LDAP=20
  support on COTS clients may prove to be hard to motivate for AIA=20
  access.&nbsp;&nbsp;One may argue that reading AIA extensions is just =
an option=20
  but that is not really the case; schemes like PIV require that you =
interpret=20
  AIA in order to create valid certification paths, unless you force =
clients to=20
  store additional CA certificates locally which is a less optimal=20
  solution.&nbsp; The cost for a CA to support HTTP and LDAP AIAs is =
close to=20
  zero since this is built-in in the leading CA packages on the=20
  market.&nbsp;&nbsp; That the PIV certificate requirements also specify =
both=20
  URI types for AIA probably was probably not accidental.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Sincerely</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
  <DIV><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0114_01C709B4.1A20A9E0--

From: "Michael Myers" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "Paul Hoffman" <[email-masked]>, "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 16 Nov 2006 06:35:21 -0800
Importance: Normal
Sender: [email-masked]

Maybe what makes the most sense is to update 2560 with this definition since
2560 is normatively referenced in other RFCs.  I'm not talking BIS, just a
quick sentence or two.

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Mike:

>The LW OCSP I-D does not nor is intended to
>update, redefine, obsolete or otherwise diminish
>2560 as the base document defining OCSP.

At a minimum, it needs update RFC 2560 to explain the ways that the
"unauthorized" error code is used.

Russ

From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 
Date: Thu, 16 Nov 2006 18:32:39 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0105_01C709AD.988D0780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I oppose this change of AIA extension. There already exists some
CAs that issued certificates with AIA extensions containing only
one id-ad-caIssuers accessLocation (either HTTP or LDAP). This
change will immediately make these CAs becoming non-compliant
to RFC3280bis. For a CA to guide its relying parties (client =
applications)
where to find the CA certificates, one  id-ad-caIssuers accessLocation
is sufficient. Even though the leading CA packages one the market
support both HTTP and LDAP, certification service providers might
still choose not to deploy both kinds of repositories at the same time =
because
of concerning the operating cost. There is no enough reason to require =
all
compliant CAs to both kinds of repositories at the same time. I prefer =
to
leave the current text as it is. With current text,  certification =
service
providers are free to choose HTTP or LDAP or both.

Wen-Cheng Wang
  ----- Original Message -----=20
  From: Anders Rundgren=20
  To: [email-masked]=20
  Sent: Thursday, November 16, 2006 4:53 PM
  Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt=20

  May I repeat my request for further improving the interoperability in =
this area?
  Anyway, here it is:

  4.2.2.1  Authority Information Access

  When the id-ad-caIssuers accessMethod is used, at least one instance =
SHOULD specify an
   accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] URI. =
there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516] =
accessLocation URI specified.

  Rationale:
  Since LDAP has rather limited applicability on public networks, I =
believe that [indirectly] requiring mandatory LDAP support on COTS =
clients may prove to be hard to motivate for AIA access.  One may argue =
that reading AIA extensions is just an option but that is not really the =
case; schemes like PIV require that you interpret AIA in order to create =
valid certification paths, unless you force clients to store additional =
CA certificates locally which is a less optimal solution.  The cost for =
a CA to support HTTP and LDAP AIAs is close to zero since this is =
built-in in the leading CA packages on the market.   That the PIV =
certificate requirements also specify both URI types for AIA probably =
was probably not accidental.

  Sincerely
  Anders Rundgren

------=_NextPart_000_0105_01C709AD.988D0780
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.2995" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman">I oppose this change&nbsp;of AIA =
extension.=20
There already exists&nbsp;some</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">CAs that issued certificates with =
AIA=20
extensions containing only</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">one id-ad-caIssuers accessLocation =
(either=20
HTTP or LDAP). This</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">change will immediately make these =
CAs=20
becoming non-compliant</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">to RFC3280bis. For a CA to guide its =
relying=20
parties (client applications)</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">where to find the CA certificates, =
one&nbsp;=20
id-ad-caIssuers accessLocation</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">is sufficient.&nbsp;Even =
though&nbsp;the=20
leading CA packages one the market</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">support both HTTP and LDAP, =
certification=20
service providers might</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">still choose not =
to&nbsp;deploy&nbsp;both=20
kinds of repositories at the same time because</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">of concerning </FONT><FONT=20
face=3D"Times New Roman">the operating cost. </FONT><FONT=20
face=3D"Times New Roman">There is no enough reason to require =
</FONT><FONT=20
face=3D"Times New Roman">all</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">compliant CAs </FONT><FONT=20
face=3D"Times New Roman">to both kinds of repositories at the same time. =
I prefer=20
to</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">leave the current text as it is. =
With current=20
text,&nbsp;&nbsp;certification service</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">providers </FONT><FONT=20
face=3D"Times New Roman">are free to choose HTTP or LDAP or =
both.</FONT></DIV>
<DIV><FONT face=3D"Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">Wen-Cheng Wang</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;; font-color: black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Anders Rundgren</A> </DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>To:</B> =
<A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Sent:</B> Thursday, November 16, =
2006 4:53=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Subject:</B> Re: I-D=20
  ACTION:draft-ietf-pkix-rfc3280bis-06.txt </DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>May I repeat my request for further =
improving the=20
  interoperability in this area?</DIV>
  <DIV>
  <DIV>Anyway, here it is:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>4.2.2.1&nbsp; Authority Information Access<BR></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>When the id-ad-caIssuers accessMethod =
is used,=20
  <STRIKE><FONT color=3D#ff0000>at least one instance SHOULD specify=20
  an<BR>&nbsp;accessLocation that is an HTTP [RFC 1738] or LDAP [RFC =
4516]=20
  URI.</FONT></STRIKE> <STRONG><FONT color=3Dgreen>there SHOULD be at =
least one=20
  HTTP [RFC 1738] and one LDAP [RFC 4516] accessLocation URI=20
  specified.</STRONG></FONT></FONT></DIV></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Rationale:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Since LDAP has rather limited =
applicability on=20
  public networks, I believe that [indirectly] requiring&nbsp;mandatory =
LDAP=20
  support on COTS clients may prove to be hard to motivate for AIA=20
  access.&nbsp;&nbsp;One may argue that reading AIA extensions is just =
an option=20
  but that is not really the case; schemes like PIV require that you =
interpret=20
  AIA in order to create valid certification paths, unless you force =
clients to=20
  store additional CA certificates locally which is a less optimal=20
  solution.&nbsp; The cost for a CA to support HTTP and LDAP AIAs is =
close to=20
  zero since this is built-in in the leading CA packages on the=20
  market.&nbsp;&nbsp; That the PIV certificate requirements also specify =
both=20
  URI types for AIA probably was probably not accidental.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Sincerely</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
  <DIV><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0105_01C709AD.988D0780--

From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 
Date: Thu, 16 Nov 2006 18:32:39 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0105_01C709AD.988D0780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I oppose this change of AIA extension. There already exists some
CAs that issued certificates with AIA extensions containing only
one id-ad-caIssuers accessLocation (either HTTP or LDAP). This
change will immediately make these CAs becoming non-compliant
to RFC3280bis. For a CA to guide its relying parties (client =
applications)
where to find the CA certificates, one  id-ad-caIssuers accessLocation
is sufficient. Even though the leading CA packages one the market
support both HTTP and LDAP, certification service providers might
still choose not to deploy both kinds of repositories at the same time =
because
of concerning the operating cost. There is no enough reason to require =
all
compliant CAs to both kinds of repositories at the same time. I prefer =
to
leave the current text as it is. With current text,  certification =
service
providers are free to choose HTTP or LDAP or both.

Wen-Cheng Wang
  ----- Original Message -----=20
  From: Anders Rundgren=20
  To: [email-masked]=20
  Sent: Thursday, November 16, 2006 4:53 PM
  Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt=20

  May I repeat my request for further improving the interoperability in =
this area?
  Anyway, here it is:

  4.2.2.1  Authority Information Access

  When the id-ad-caIssuers accessMethod is used, at least one instance =
SHOULD specify an
   accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] URI. =
there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516] =
accessLocation URI specified.

  Rationale:
  Since LDAP has rather limited applicability on public networks, I =
believe that [indirectly] requiring mandatory LDAP support on COTS =
clients may prove to be hard to motivate for AIA access.  One may argue =
that reading AIA extensions is just an option but that is not really the =
case; schemes like PIV require that you interpret AIA in order to create =
valid certification paths, unless you force clients to store additional =
CA certificates locally which is a less optimal solution.  The cost for =
a CA to support HTTP and LDAP AIAs is close to zero since this is =
built-in in the leading CA packages on the market.   That the PIV =
certificate requirements also specify both URI types for AIA probably =
was probably not accidental.

  Sincerely
  Anders Rundgren

------=_NextPart_000_0105_01C709AD.988D0780
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.2995" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman">I oppose this change&nbsp;of AIA =
extension.=20
There already exists&nbsp;some</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">CAs that issued certificates with =
AIA=20
extensions containing only</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">one id-ad-caIssuers accessLocation =
(either=20
HTTP or LDAP). This</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">change will immediately make these =
CAs=20
becoming non-compliant</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">to RFC3280bis. For a CA to guide its =
relying=20
parties (client applications)</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">where to find the CA certificates, =
one&nbsp;=20
id-ad-caIssuers accessLocation</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">is sufficient.&nbsp;Even =
though&nbsp;the=20
leading CA packages one the market</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">support both HTTP and LDAP, =
certification=20
service providers might</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">still choose not =
to&nbsp;deploy&nbsp;both=20
kinds of repositories at the same time because</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">of concerning </FONT><FONT=20
face=3D"Times New Roman">the operating cost. </FONT><FONT=20
face=3D"Times New Roman">There is no enough reason to require =
</FONT><FONT=20
face=3D"Times New Roman">all</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">compliant CAs </FONT><FONT=20
face=3D"Times New Roman">to both kinds of repositories at the same time. =
I prefer=20
to</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">leave the current text as it is. =
With current=20
text,&nbsp;&nbsp;certification service</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">providers </FONT><FONT=20
face=3D"Times New Roman">are free to choose HTTP or LDAP or =
both.</FONT></DIV>
<DIV><FONT face=3D"Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">Wen-Cheng Wang</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;; font-color: black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Anders Rundgren</A> </DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>To:</B> =
<A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Sent:</B> Thursday, November 16, =
2006 4:53=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Subject:</B> Re: I-D=20
  ACTION:draft-ietf-pkix-rfc3280bis-06.txt </DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>May I repeat my request for further =
improving the=20
  interoperability in this area?</DIV>
  <DIV>
  <DIV>Anyway, here it is:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>4.2.2.1&nbsp; Authority Information Access<BR></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>When the id-ad-caIssuers accessMethod =
is used,=20
  <STRIKE><FONT color=3D#ff0000>at least one instance SHOULD specify=20
  an<BR>&nbsp;accessLocation that is an HTTP [RFC 1738] or LDAP [RFC =
4516]=20
  URI.</FONT></STRIKE> <STRONG><FONT color=3Dgreen>there SHOULD be at =
least one=20
  HTTP [RFC 1738] and one LDAP [RFC 4516] accessLocation URI=20
  specified.</STRONG></FONT></FONT></DIV></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Rationale:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Since LDAP has rather limited =
applicability on=20
  public networks, I believe that [indirectly] requiring&nbsp;mandatory =
LDAP=20
  support on COTS clients may prove to be hard to motivate for AIA=20
  access.&nbsp;&nbsp;One may argue that reading AIA extensions is just =
an option=20
  but that is not really the case; schemes like PIV require that you =
interpret=20
  AIA in order to create valid certification paths, unless you force =
clients to=20
  store additional CA certificates locally which is a less optimal=20
  solution.&nbsp; The cost for a CA to support HTTP and LDAP AIAs is =
close to=20
  zero since this is built-in in the leading CA packages on the=20
  market.&nbsp;&nbsp; That the PIV certificate requirements also specify =
both=20
  URI types for AIA probably was probably not accidental.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Sincerely</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
  <DIV><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0105_01C709AD.988D0780--

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 
Date: Thu, 16 Nov 2006 09:53:43 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01C70965.19CE5D10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

May I repeat my request for further improving the interoperability in =
this area?
Anyway, here it is:

4.2.2.1  Authority Information Access

When the id-ad-caIssuers accessMethod is used, at least one instance =
SHOULD specify an
 accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] URI. there =
SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516] =
accessLocation URI specified.

Rationale:
Since LDAP has rather limited applicability on public networks, I =
believe that [indirectly] requiring mandatory LDAP support on COTS =
clients may prove to be hard to motivate for AIA access.  One may argue =
that reading AIA extensions is just an option but that is not really the =
case; schemes like PIV require that you interpret AIA in order to create =
valid certification paths, unless you force clients to store additional =
CA certificates locally which is a less optimal solution.  The cost for =
a CA to support HTTP and LDAP AIAs is close to zero since this is =
built-in in the leading CA packages on the market.   That the PIV =
certificate requirements also specify both URI types for AIA probably =
was probably not accidental.

Sincerely
Anders Rundgren

------=_NextPart_000_005C_01C70965.19CE5D10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>May I repeat my request for further =
improving the=20
interoperability in this area?</DIV>
<DIV>
<DIV>Anyway, here it is:</DIV>
<DIV>&nbsp;</DIV>
<DIV>4.2.2.1&nbsp; Authority Information Access<BR></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>When the id-ad-caIssuers accessMethod =
is used,=20
<STRIKE><FONT color=3D#ff0000>at least one instance SHOULD specify=20
an<BR>&nbsp;accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] =

URI.</FONT></STRIKE> <STRONG><FONT color=3Dgreen>there SHOULD be at =
least one HTTP=20
[RFC 1738] and one LDAP [RFC 4516] accessLocation URI=20
specified.</STRONG></FONT></FONT></DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Rationale:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Since LDAP has rather limited =
applicability on=20
public networks, I believe that [indirectly] requiring&nbsp;mandatory =
LDAP=20
support on COTS clients may prove to be hard to motivate for AIA=20
access.&nbsp;&nbsp;One may argue that reading AIA extensions is just an =
option=20
but that is not really the case; schemes like PIV require that you =
interpret AIA=20
in order to create valid certification paths, unless you force clients =
to store=20
additional CA certificates locally which is a less optimal =
solution.&nbsp; The=20
cost for a CA to support HTTP and LDAP AIAs is close to zero since this =
is=20
built-in in the leading CA packages on the market.&nbsp;&nbsp; That the =
PIV=20
certificate requirements also specify both URI types for AIA probably =
was=20
probably not accidental.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Sincerely</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_005C_01C70965.19CE5D10--

Date: Wed, 15 Nov 2006 23:02:40 -0500
To: "Michael Myers" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "Paul Hoffman" <[email-masked]>, "Sam Hartman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: <[email-masked]>
Sender: [email-masked]

Mike:

>The LW OCSP I-D does not nor is intended to
>update, redefine, obsolete or otherwise diminish
>2560 as the base document defining OCSP.

At a minimum, it needs update RFC 2560 to explain the ways that the 
"unauthorized" error code is used.

Russ

Date: Wed, 15 Nov 2006 22:47:53 -0500
To: Paul Hoffman <[email-masked]>, "Michael Myers" <[email-masked]>, "Sam Hartman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: <[email-masked]>
Sender: [email-masked]

I think that this is the minimum change that is needed in an update 
to RFC 2560.

It can appear in the LW OCSP document if the PKIX WG agrees that the 
LW OCSP document is a standards-track update to RFC 2560.

Russ

At 04:32 PM 11/15/2006, Paul Hoffman wrote:

>At 10:33 AM -0800 11/15/06, Michael Myers wrote:
>>How about we expand the meaning of "unauthorized" to mean EITHER the
>>requestor is not authorized to ask the responder OR the responder is not
>>authorized to fulfill the request.  That's not *too* ugly, is it?
>
>No, it isn't. That's a good idea!
>
>--Paul Hoffman, Director
>--VPN Consortium
>

From: Sam Hartman <[email-masked]>
To: "Michael Myers" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, "Paul Hoffman" <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 20:54:32 -0500
Sender: [email-masked]

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    Michael> Sam, I cannot state the point more precisely.  Let's try
    Michael> this: What do you think it means?

Obselete is clear.  I have no idea why you would care about
diminishing a spec, or what that would mean.

As far as updating and redefining, I don't know whether you consider
the sort of text in the profile that broadens error codes to be an
update/redefinition.

What I think is true is that:

* the profile does not change the behavior of things that do not
  conform to the profile.

* There exist things that do not conform to the profile that will not
  interoperate with the profile.

* Clients that conform to the profile conform to 2560.

* Servers that conform to the profile will conform to 2560bis; it is
  rather unclear whether they conform to 2560.

* It is possible to write a server that conforms both to the profile
  and 2560, but to do so you have to give up some of the advantages of
  the profile.

If those bullet points aren't enough to make you happy, what else
would you need?

From: "Michael Myers" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, "Paul Hoffman" <[email-masked]>, <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 17:05:57 -0800
Importance: Normal
Sender: [email-masked]

Sam,

I cannot state the point more precisely.
Let's try this:  What do you think it means?

Mike

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Wednesday, November 15, 2006 4:55 PM
To: Michael Myers
Cc: Stefan Santesson; Paul Hoffman; [email-masked]
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    Michael> Stefan, Steve: Works for me IF it is understood that:

    Michael> The LW OCSP I-D does not nor is intended to update,
    Michael> redefine, obsolete or otherwise diminish 2560 as the base
    Michael> document defining OCSP.

What does this paragraph mean?

From: Sam Hartman <[email-masked]>
To: "Michael Myers" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, "Paul Hoffman" <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 19:54:40 -0500
Sender: [email-masked]

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    Michael> Stefan, Steve: Works for me IF it is understood that:

    Michael> The LW OCSP I-D does not nor is intended to update,
    Michael> redefine, obsolete or otherwise diminish 2560 as the base
    Michael> document defining OCSP.

What does this paragraph mean?

From: "Michael Myers" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Paul Hoffman" <[email-masked]>, "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 15:14:15 -0800
Importance: Normal
Sender: [email-masked]

Stefan, Steve:

Works for me IF it is understood that:

The LW OCSP I-D does not nor is intended to
update, redefine, obsolete or otherwise diminish
2560 as the base document defining OCSP.

Rather, it maps that protocol onto a specific
context of need.  Among other of its effects it
expands without conflict against original intent
the definition of the "unauthorized" error code
as I proposed below.

Is that the deal?

Mike

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Wednesday, November 15, 2006 2:58 PM
To: Paul Hoffman; Michael Myers; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Yes it is a good idea.

I just had a conf call first with the editors, then with Russ and then with
the editors again.

This is the outcome and what I propose as the way forward. It is my
understanding that this is acceptable to both the Security AD's as well as
the editors.

Background and problem statement:
According to the current definitions in RFC 2560, especially the definitions
of error responses, there is currently no adequate response defined for some
legal requests if the responder has no signing key. In particular this is
the case when the responder is limited to just returning pre-produced
responses for a subset of all valid requests.

Proposed way forward:
In order to resolve this situation, the lightweight profile will have to
update/clarify the meaning of error codes, in particular the "unauthorized"
error response, so that it updates the definition in RFC 2560 and allows the
usage specified in the lightweight profile. To do so, the lightweight
profile must be a standards track document.

If this solution is acceptable, the lightweight profile will be returned to
the WG to make this update and to go through a new WG last call to
acknowledge that rough consensus is not broken by the update.

Is this approach acceptable to the WG?

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 15 november 2006 13:32
> To: Michael Myers; Sam Hartman
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> At 10:33 AM -0800 11/15/06, Michael Myers wrote:
> >How about we expand the meaning of "unauthorized" to mean EITHER the
> >requestor is not authorized to ask the responder OR the responder is
> not
> >authorized to fulfill the request.  That's not *too* ugly, is it?
>
> No, it isn't. That's a good idea!
>
> --Paul Hoffman, Director
> --VPN Consortium

From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>, Michael Myers <[email-masked]>, Sam Hartman <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Wed, 15 Nov 2006 22:58:29 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Yes it is a good idea.

I just had a conf call first with the editors, then with Russ and then with the editors again.

This is the outcome and what I propose as the way forward. It is my understanding that this is acceptable to both the Security AD's as well as the editors.

Background and problem statement:
According to the current definitions in RFC 2560, especially the definitions of error responses, there is currently no adequate response defined for some legal requests if the responder has no signing key. In particular this is the case when the responder is limited to just returning pre-produced responses for a subset of all valid requests.

Proposed way forward:
In order to resolve this situation, the lightweight profile will have to update/clarify the meaning of error codes, in particular the "unauthorized" error response, so that it updates the definition in RFC 2560 and allows the usage specified in the lightweight profile. To do so, the lightweight profile must be a standards track document.

If this solution is acceptable, the lightweight profile will be returned to the WG to make this update and to go through a new WG last call to acknowledge that rough consensus is not broken by the update.

Is this approach acceptable to the WG?

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 15 november 2006 13:32
> To: Michael Myers; Sam Hartman
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> At 10:33 AM -0800 11/15/06, Michael Myers wrote:
> >How about we expand the meaning of "unauthorized" to mean EITHER the
> >requestor is not authorized to ask the responder OR the responder is
> not
> >authorized to fulfill the request.  That's not *too* ugly, is it?
>
> No, it isn't. That's a good idea!
>
> --Paul Hoffman, Director
> --VPN Consortium

Cc: "Peter Rybar" <[email-masked]>, [email-masked]
From: Max Pritikin <[email-masked]>
Subject: Re: RFC3280bis: NotAfter 99991231235959Z
Date: Wed, 15 Nov 2006 16:54:28 -0600
To: Russ Housley <[email-masked]>
Sender: [email-masked]

I think this implies that "6.1.3  Basic Certificate Processing" text:

          (2)  The certificate validity period includes the current  
time.

will need to be modified to read something like:

	(2) The certificate or any prior certificate validity period is  
either equal to GeneralizedTime value 99991231235959Z or includes the  
current time.

This indicating that the certificate chain validation no longer  
includes checking the current time against the validity period for  
these values. Alternatively every certificate in the chain could be  
required to use this large GeneralizedTime value.

Thanks,

	- max

On Nov 15, 2006, at 2:01 PM, Russ Housley wrote:

>
> I would hope that the time function would not be called with this  
> input.  The point is to flag the value as not expiring.
>
> Russ
>
> At 11:39 AM 11/15/2006, Peter Rybar wrote:
>> Some utility written in C language time (The time function returns  
>> the number of seconds elapsed since midnight (00:00:00), January  
>> 1, 1970,) will crash. ;-)
>>
>> From: [email-masked] [mailto:owner-ietf- 
>> [email-masked]] On Behalf Of Russ Housley
>> Sent: Wednesday, November 15, 2006 3:56 PM
>> To: [email-masked]
>> Subject: RFC3280bis: NotAfter 99991231235959Z
>>
>>
>> I would like to add some text about certificates that are not
>> intended to expire.  I propose the following paragraph.
>>
>> In some situations, devices are given permanent certificates.  For
>> example, a device could be issued a certificate that binds its model
>> and serial number to its public key.  Such a certificate is intended
>> to be used for the entire lifetime of the device.  It indicate the
>> permanent nature of such a certificate, the notAfter SHOULD be
>> assigned the GeneralizedTime value of 99991231235959Z.
>>
>> Any concerns?
>>
>> Russ

Date: Wed, 15 Nov 2006 17:31:59 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
Sender: [email-masked]

All,

Draft -06 does not include any changes from draft -05 other than adding 
Tim Polk to the list of editors.

Dave

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
>
> 	Title		: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
> 	Author(s)	: D. Cooper, et al.
> 	Filename	: draft-ietf-pkix-rfc3280bis-06.txt
> 	Pages		: 144
> 	Date		: 2006-11-15
> 	
> This memo profiles the X.509 v3 certificate and X.509 v2 certificate
>    revocation list (CRL) for use in the Internet.  An overview of this
>    approach and model are provided as an introduction.  The X.509 v3
>    certificate format is described in detail, with additional
>    information regarding the format and semantics of Internet name
>    forms.  Standard certificate extensions are described and two
>    Internet-specific extensions are defined.  A set of required
>    certificate extensions is specified.  The X.509 v2 CRL format is
>    described in detail along with standard and Internet-specific
>    extensions.  An algorithm for X.509 certification path validation is
>    described.  An ASN.1 module and examples are provided in the
>    appendices.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-06.txt
>   

Date: Wed, 15 Nov 2006 13:32:13 -0800
To: "Michael Myers" <[email-masked]>, "Sam Hartman" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: <[email-masked]>
Sender: [email-masked]

At 10:33 AM -0800 11/15/06, Michael Myers wrote:
>How about we expand the meaning of "unauthorized" to mean EITHER the
>requestor is not authorized to ask the responder OR the responder is not
>authorized to fulfill the request.  That's not *too* ugly, is it?

No, it isn't. That's a good idea!

--Paul Hoffman, Director
--VPN Consortium

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 
Date: Wed, 15 Nov 2006 15:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
	Author(s)	: D. Cooper, et al.
	Filename	: draft-ietf-pkix-rfc3280bis-06.txt
	Pages		: 144
	Date		: 2006-11-15
	
This memo profiles the X.509 v3 certificate and X.509 v2 certificate
   revocation list (CRL) for use in the Internet.  An overview of this
   approach and model are provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.  A set of required
   certificate extensions is specified.  The X.509 v2 CRL format is
   described in detail along with standard and Internet-specific
   extensions.  An algorithm for X.509 certification path validation is
   described.  An ASN.1 module and examples are provided in the
   appendices.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-pkix-rfc3280bis-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-06.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 15 Nov 2006 15:27:41 -0500
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: "Sam Hartman" <[email-masked]>
Sender: [email-masked]

I agree.  I can see where two of these models can be used in the 
multi-certificate request.  That is why I think that this dimension 
of the discussion is a red herring.

Russ

At 02:22 PM 11/15/2006, Santosh Chokhani wrote:
>Russ,
>
>The OCSP field in the AIA extension helps the OCSP client locate an OCSP
>Responder.  But, to verify the signature on the OCSP response, 2560
>mandates three trust models: explicitly trusted, CA only, and CA
>delegated.  The OCSP field can not extend those options to other trust
>models.
>
>From: Russ Housley [mailto:[email-masked]]
>Sent: Wednesday, November 15, 2006 10:32 AM
>To: Santosh Chokhani; [email-masked]
>Cc: Sam Hartman
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>Santosh:
>
>My point is that the request could be for any set of certificates
>that contain AIAs that point to the same OCSP responder, whether they
>are part of the same certification path or not.
>
>Russ
>
>At 08:03 PM 11/14/2006, Santosh Chokhani wrote:
> >Russ,
> >
> >I do not know how germane this debate is to Sam's question, but I was
> >simply responding to the issue building certification path.  I presume
> >that in this context it relates to building a path to the Responder
> >certificate.
> >
> >Now let us look at the three model 2560 has: Explicitly Trusted, CA and
> >Delegated.
> >
> >Explicitly trusted does not need a certification path and hence there
>is
> >no issue and that is why I did not include it in.
> >
> >CA model does not need any path building since path to the CA has
> >already been built and that is why I did not include it in my response.
> >Note that both clients requires the CA to use the same to sign the OCSP
> >as it signed the certificate in question with.
> >
> >My post responded to the Delegated model.
> >
> >I hope this clarifies that the path building should not be a major
>issue
> >for all three models 2560 supports.
> >
> >From: Russ Housley [mailto:[email-masked]]
> >Sent: Tuesday, November 14, 2006 6:42 PM
> >To: Santosh Chokhani; [email-masked]
> >Cc: Sam Hartman
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >Santosh:
> >
> >I believe this is a red herring.  This is not the only deployment
> >approach supported by RFC 2560.
> >
> >Russ
> >
> > >In hurry, I did not clearly articulate my thoughts.  What I am saying
> >also
> > >relates to another comment to Mike Myers regarding the security of
>the
> > >delegated model which is incompletely addressed by 2560.
> > >
> > >I will be verbose this time.
> > >
> > >The implementations such as Corestreet and Tumbleweed tend to adhere
>to
> >the
> > >approach that the same key that signed the certificate in question,
> >sign the
> > >OCSP Responder certificate.
> > >
> > >Thus, if you have a hierarchy like Root --> CA --> Subscriber and you
> >want
> > >the status of CA certificate and the Subscriber certificate, you get
> >them as
> > >responses and with them you only need the two OCSP Responder
> >certificates
> > >one signed by the Root (for verifying CA certificate revocation
>status)
> >and
> > >one signed by the CA (for verifying the subscriber certificate
> >revocation
> > >status).
> > >
> > >You do not need any paths.
> > >
> > >Please note that the approach also works when the Responder is
>queried
> >by a
> > >CA cross certified by the root, since rest of the path has been built
> >by the
> > >client.
> > >
> > >From: Dave Engberg [mailto:[email-masked]]
> > >Sent: Tuesday, November 14, 2006 12:45 PM
> > >To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
> > >[email-masked]
> > >Cc: Sam Hartman; Michael Myers
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >CoreStreet's OCSP server doesn't include a SingleResponse for the
> >issuing
> > >CA's cert in pre-signed responses.  Mostly for the reasons mentioned:
> > >
> > >Adds 90-100 bytes onto every response
> > >
> > >Have never seen a relying party app/plug-in send a request like this
> > >
> > >The "delegated" trust model in RFC 2560 would require different
>signing
> > >certs for trusting entity vs. CA cert ... add another 1kB onto the
> >response
> > >
> > >Protocol only sends CA name+key info, which isn't enough to identify
> >which
> > >CA cert the relying party is inspecting in the case of CA cert
>renewal,
> > >cross-certification, etc.
> > >
> > >
> > >From: Stefan Santesson [mailto:[email-masked]]
> > >Sent: Tuesday, November 14, 2006 12:11 PM
> > >To: Santosh Chokhani; Russ Housley; Price, Bill; [email-masked]
> > >Cc: Sam Hartman; Michael Myers; Dave Engberg
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >Santosh,
> > >
> > >I didn't say it was hard. I say that I doubt that there are many
> > >implementations supporting this scenario even those with a responder
> >key.
> > >It would be interesting to hear from implementers if I'm right.
> > >
> > >Stefan Santesson
> > >Senior Program Manager
> > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > Sent: den 14 november 2006 03:59
> > > > To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> > > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > > >
> > > > Stefan,
> > > >
> > > > You are making more complex than it is.  The Responder can include
> >all
> > > > the CA certificates that issued the certificate in question and
>AIA
> >can
> > > > do the rest.
> > > >
> > > > Furthermore, since most PKI are two tier hierarchy, in Enterprise
> > > > environment, the CA certificate certification path is not an
>issue.
> > > >
> > > > From: [email-masked] [mailto:owner-ietf-
> > > > [email-masked]]
> > > > On Behalf Of Stefan Santesson
> > > > Sent: Monday, November 13, 2006 6:54 PM
> > > > To: Russ Housley; Price, Bill; [email-masked]
> > > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > > >
> > > >
> > > > I'm not sure the case described is a realistic one.
> > > >
> > > > Section 2.2
> > > >    All definitive response messages SHALL be digitally signed. The
> >key
> > > >    used to sign the response MUST belong to one of the following:
> > > >
> > > >    -- the CA who issued the certificate in question
> > > >    -- a Trusted Responder whose public key is trusted by the
> >requester
> > > >    -- a CA Designated Responder (Authorized Responder) who holds a
> > > >       specially marked certificate issued directly by the CA,
> > > > indicating
> > > >       that the responder may issue OCSP responses for that CA
> > > >
> > > > Since the request is on certificates issued by 2 different CA:s
> >trust
> > > > option 1 is invalid.
> > > > Trust option 3 is valid in theory but in practice it requires that
> >the
> > > > OCSP responder provide multiple validation paths in the response,
> >one
> > > > for each issuing CA. Somehow I doubt that this is implemented by
> > > > anyone.
> > > >
> > > > Trust option 2 is not generic and is only valid as a result of a
> >local
> > > > configuration.
> > > >
> > > > So I don't think this is a problem only for key-less responders.
> > > >
> > > >
> > > > Stefan Santesson
> > > > Senior Program Manager
> > > > > From: [email-masked] [mailto:owner-ietf-
> > > > > [email-masked]] On Behalf Of Russ Housley
> > > > > Sent: den 13 november 2006 14:08
> > > > > To: Price, Bill; [email-masked]
> > > > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
>2560
> > > > >
> > > > >
> > > > > I prefer an error that tells the client to ask for the
>certificate
> > > > > one at a time.
> > > > >
> > > > > Russ
> > > > >
> > > > >
> > > > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > > > >
> > > > > >I'd suggest focusing on understanding where responses to the
> >keyed
> > > > and
> > > > > >keyless responders inherently differ. I am aware of two general
> > > > cases:
> > > > > >
> > > > > >1) The request asks for the status of multiple certificates
>that
> > > > have
> > > > > >not been included in a single presigned response. Russ's
>example
> > > > fits
> > > > > >into this case. The keyed responder handles, but the keyless
>will
> > > > fail
> > > > > >for the general case. Some responders respond with the
>presigned
> > > > > >response that includes one of the certificates (usually the
> >first)
> > > > in
> > > > > >the request. A common situation is to ask for the status of
> > > > > >certificates in a chain. Santosh points out some keyless
> >responders
> > > > > >anticipate this and bundle responses accordingly.
> > > > > >
> > > > > >2) The request is "well-formed" but asks for the status of a
> > > > > >certificate for which the keyless responder has not prepared a
> > > > > >response.  This situation will occur if:
> > > > > >
> > > > > >     a) The request is for status of a certificate from a
> >supported
> > > > CA
> > > > > >but with a serial number for which there is no pre-signed
> >response.
> > > > > >Assuming presigned responses exist for all certificates that
> >would
> > > > be
> > > > > >valid based on their validity intervals, this would occur if
>the
> > > > > >certificate had expired or was yet to be issued (I am aware the
> > > > > keyless
> > > > > >responders generally produce responses for certificates likely
>to
> >be
> > > > > >issued before the next generation of presigned responses). The
> >keyed
> > > > > >responder would give a signed "good" response. My understanding
> >is
> > > > > that
> > > > > >the keyless responder under the draft lightweight OCSP responds
> >with
> > > > > an
> > > > > >unsigned "unauthorized" error code.
> > > > > >
> > > > > >     b) The request is for the status of a certificate from an
> > > > > >unsupported (or non-existent) CA. The keyed responder would
> >respond
> > > > > >with a signed "unknown" response while under the draft, the
> >keyless
> > > > > >would again respond with the unsigned "unauthorized" error
>code.
> > > > > >
> > > > > >Some might argue with some grounds that these differences are
> > > > unusual,
> > > > > >unlikely, and insignificant.
> > > > > >
> > > > > >I personally consider the behavior in 2 of responding with the
> > > > > >"unauthorized" error to be misleading. "Internal error" sounds
> >more
> > > > > >appropriate if I were constrained to the current error codes.
> > > > > >"Malformed request" might be OK. However, the actual situation
> >does
> > > > > not
> > > > > >match well with any of these errors as they are described in
> >2560.
> > > > > >
> > > > > >If 2560 is supposed to encompass keyless responders, I'd
> >recommend
> > > > > >identifying the unavoidable differences and/or adding 2 TBD
>error
> > > > > codes
> > > > > >for the above cases (assuming they are the only differences).
>The
> > > > > first
> > > > > >error can be worked around by breaking the request for status
>of
> > > > > >multiples into multiple requests for status of one cert.
> > > > > >
> > > > > >We've also seen some problems with client apps that can't
>handle
> > > > > >presigned responses that commonly contain the status of several
> > > > (e.g.,
> > > > > >15-25) certs. The apps inquired for the status of a single cert
> >and
> > > > > >apparently expected a response for a single certificate. I'd
> >suggest
> > > > > >that some "must" or "should" words address clients' ability to
> > > > handle
> > > > > >the situation of a response covering multiple certificates.
> > > > > >
> > > > > >
> > > > > >
> > > > > >Bill Price
> > > > > >
> > > > > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > > > > >Sent: Monday, November 13, 2006 11:46 AM
> > > > > >To: Michael Myers; Dave Engberg
> > > > > >Cc: [email-masked]; Sam Hartman
> > > > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
> >2560
> > > > > >
> > > > > >
> > > > > >Mike:
> > > > > >
> > > > > >I think it is not that simple.  I think you need to say that
> >support
> > > > > >for one certificate MUST be supported, and that support for
>more
> > > > than
> > > > > >one certificate is OPTIONAL.  Then, the error is am indication
> >that
> > > > > >the requestor has selected an unimplemented OPTION.
> > > > > >
> > > > > >Russ
> > > > > >
> > > > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > > > >Responders unable to produce or acquire a definitive response
> >MUST
> > > > > >return <a
> > > > > > >TBD error>.
> > > > > > >
> > > > > > >As to your other points Santosh, that is something I prefer
>the
> > > > > chairs
> > > > > > >consider.
> > > > > > >
> > > > > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > > > >
> > > > > > > > Mike,
> > > > > > > >
> > > > > > > > What is the error case?
> > > > > > > >
> > > > > > > > . . .
> > > >

Date: Wed, 15 Nov 2006 15:01:48 -0500
To: "Peter Rybar" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: RFC3280bis: NotAfter 99991231235959Z
Cc: [email-masked]
Sender: [email-masked]

I would hope that the time function would not be called with this 
input.  The point is to flag the value as not expiring.

Russ

At 11:39 AM 11/15/2006, Peter Rybar wrote:
>Some utility written in C language time (The time function returns 
>the number of seconds elapsed since midnight (00:00:00), January 1, 
>1970,) will crash. ;-)
>
>[mailto:[email-masked]] On Behalf Of Russ Housley
>Sent: Wednesday, November 15, 2006 3:56 PM
>To: [email-masked]
>Subject: RFC3280bis: NotAfter 99991231235959Z
>
>
>I would like to add some text about certificates that are not
>intended to expire.  I propose the following paragraph.
>
>In some situations, devices are given permanent certificates.  For
>example, a device could be issued a certificate that binds its model
>and serial number to its public key.  Such a certificate is intended
>to be used for the entire lifetime of the device.  It indicate the
>permanent nature of such a certificate, the notAfter SHOULD be
>assigned the GeneralizedTime value of 99991231235959Z.
>
>Any concerns?
>
>Russ

Date: Wed, 15 Nov 2006 15:09:28 -0500
To: "Julien Stern" <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: RFC3280bis: NotAfter 99991231235959Z
Sender: [email-masked]

No.  That device is still that device.  The certificate is not making 
any statement about the ownership of the device.

Russ

At 12:28 PM 11/15/2006, Julien Stern wrote:

>On Wed, Nov 15, 2006 at 09:55:47AM -0500, Russ Housley wrote:
> >
> > I would like to add some text about certificates that are not
> > intended to expire.  I propose the following paragraph.
> >
> > In some situations, devices are given permanent certificates.  For
> > example, a device could be issued a certificate that binds its model
> > and serial number to its public key.  Such a certificate is intended
> > to be used for the entire lifetime of the device.  It indicate the
> > permanent nature of such a certificate, the notAfter SHOULD be
> > assigned the GeneralizedTime value of 99991231235959Z.
> >
> > Any concerns?
>
>If the device is somehow stolen or compromised at some point,
>doesn't this mean that you will have to keep its serial number in a CRL
>(or an other revocation system) until the end of times?
>
>When faced with a somehow similar issue, we decided to set the date to
>the expected lifetime of the device plus a few years to avoid the above
>issue.
>
>--
>Julien

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 11:22:01 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>
Sender: [email-masked]

Russ,

The OCSP field in the AIA extension helps the OCSP client locate an OCSP
Responder.  But, to verify the signature on the OCSP response, 2560
mandates three trust models: explicitly trusted, CA only, and CA
delegated.  The OCSP field can not extend those options to other trust
models.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 10:32 AM
To: Santosh Chokhani; [email-masked]
Cc: Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh:

My point is that the request could be for any set of certificates 
that contain AIAs that point to the same OCSP responder, whether they 
are part of the same certification path or not.

Russ

At 08:03 PM 11/14/2006, Santosh Chokhani wrote:
>Russ,
>
>I do not know how germane this debate is to Sam's question, but I was
>simply responding to the issue building certification path.  I presume
>that in this context it relates to building a path to the Responder
>certificate.
>
>Now let us look at the three model 2560 has: Explicitly Trusted, CA and
>Delegated.
>
>Explicitly trusted does not need a certification path and hence there
is
>no issue and that is why I did not include it in.
>
>CA model does not need any path building since path to the CA has
>already been built and that is why I did not include it in my response.
>Note that both clients requires the CA to use the same to sign the OCSP
>as it signed the certificate in question with.
>
>My post responded to the Delegated model.
>
>I hope this clarifies that the path building should not be a major
issue
>for all three models 2560 supports.
>
>From: Russ Housley [mailto:[email-masked]]
>Sent: Tuesday, November 14, 2006 6:42 PM
>To: Santosh Chokhani; [email-masked]
>Cc: Sam Hartman
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>Santosh:
>
>I believe this is a red herring.  This is not the only deployment
>approach supported by RFC 2560.
>
>Russ
>
> >In hurry, I did not clearly articulate my thoughts.  What I am saying
>also
> >relates to another comment to Mike Myers regarding the security of
the
> >delegated model which is incompletely addressed by 2560.
> >
> >I will be verbose this time.
> >
> >The implementations such as Corestreet and Tumbleweed tend to adhere
to
>the
> >approach that the same key that signed the certificate in question,
>sign the
> >OCSP Responder certificate.
> >
> >Thus, if you have a hierarchy like Root --> CA --> Subscriber and you
>want
> >the status of CA certificate and the Subscriber certificate, you get
>them as
> >responses and with them you only need the two OCSP Responder
>certificates
> >one signed by the Root (for verifying CA certificate revocation
status)
>and
> >one signed by the CA (for verifying the subscriber certificate
>revocation
> >status).
> >
> >You do not need any paths.
> >
> >Please note that the approach also works when the Responder is
queried
>by a
> >CA cross certified by the root, since rest of the path has been built
>by the
> >client.
> >
> >From: Dave Engberg [mailto:[email-masked]]
> >Sent: Tuesday, November 14, 2006 12:45 PM
> >To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
> >[email-masked]
> >Cc: Sam Hartman; Michael Myers
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >CoreStreet's OCSP server doesn't include a SingleResponse for the
>issuing
> >CA's cert in pre-signed responses.  Mostly for the reasons mentioned:
> >
> >Adds 90-100 bytes onto every response
> >
> >Have never seen a relying party app/plug-in send a request like this
> >
> >The "delegated" trust model in RFC 2560 would require different
signing
> >certs for trusting entity vs. CA cert ... add another 1kB onto the
>response
> >
> >Protocol only sends CA name+key info, which isn't enough to identify
>which
> >CA cert the relying party is inspecting in the case of CA cert
renewal,
> >cross-certification, etc.
> >
> >
> >From: Stefan Santesson [mailto:[email-masked]]
> >Sent: Tuesday, November 14, 2006 12:11 PM
> >To: Santosh Chokhani; Russ Housley; Price, Bill; [email-masked]
> >Cc: Sam Hartman; Michael Myers; Dave Engberg
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >Santosh,
> >
> >I didn't say it was hard. I say that I doubt that there are many
> >implementations supporting this scenario even those with a responder
>key.
> >It would be interesting to hear from implementers if I'm right.
> >
> >Stefan Santesson
> >Senior Program Manager
> > > From: Santosh Chokhani [mailto:[email-masked]]
> > > Sent: den 14 november 2006 03:59
> > > To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > > Stefan,
> > >
> > > You are making more complex than it is.  The Responder can include
>all
> > > the CA certificates that issued the certificate in question and
AIA
>can
> > > do the rest.
> > >
> > > Furthermore, since most PKI are two tier hierarchy, in Enterprise
> > > environment, the CA certificate certification path is not an
issue.
> > > From: [email-masked] [mailto:owner-ietf-
> > > [email-masked]]
> > > On Behalf Of Stefan Santesson
> > > Sent: Monday, November 13, 2006 6:54 PM
> > > To: Russ Housley; Price, Bill; [email-masked]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > > I'm not sure the case described is a realistic one.
> > >
> > > Section 2.2
> > >    All definitive response messages SHALL be digitally signed. The
>key
> > >    used to sign the response MUST belong to one of the following:
> > >
> > >    -- the CA who issued the certificate in question
> > >    -- a Trusted Responder whose public key is trusted by the
>requester
> > >    -- a CA Designated Responder (Authorized Responder) who holds a
> > >       specially marked certificate issued directly by the CA,
> > > indicating
> > >       that the responder may issue OCSP responses for that CA
> > >
> > > Since the request is on certificates issued by 2 different CA:s
>trust
> > > option 1 is invalid.
> > > Trust option 3 is valid in theory but in practice it requires that
>the
> > > OCSP responder provide multiple validation paths in the response,
>one
> > > for each issuing CA. Somehow I doubt that this is implemented by
> > > anyone.
> > >
> > > Trust option 2 is not generic and is only valid as a result of a
>local
> > > configuration.
> > >
> > > So I don't think this is a problem only for key-less responders.
> > >
> > >
> > > Stefan Santesson
> > > Senior Program Manager
> > > > From: [email-masked] [mailto:owner-ietf-
> > > > [email-masked]] On Behalf Of Russ Housley
> > > > Sent: den 13 november 2006 14:08
> > > > To: Price, Bill; [email-masked]
> > > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
2560
> > > >
> > > >
> > > > I prefer an error that tells the client to ask for the
certificate
> > > > one at a time.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > > >
> > > > >I'd suggest focusing on understanding where responses to the
>keyed
> > > and
> > > > >keyless responders inherently differ. I am aware of two general
> > > cases:
> > > > >
> > > > >1) The request asks for the status of multiple certificates
that
> > > have
> > > > >not been included in a single presigned response. Russ's
example
> > > fits
> > > > >into this case. The keyed responder handles, but the keyless
will
> > > fail
> > > > >for the general case. Some responders respond with the
presigned
> > > > >response that includes one of the certificates (usually the
>first)
> > > in
> > > > >the request. A common situation is to ask for the status of
> > > > >certificates in a chain. Santosh points out some keyless
>responders
> > > > >anticipate this and bundle responses accordingly.
> > > > >
> > > > >2) The request is "well-formed" but asks for the status of a
> > > > >certificate for which the keyless responder has not prepared a
> > > > >response.  This situation will occur if:
> > > > >
> > > > >     a) The request is for status of a certificate from a
>supported
> > > CA
> > > > >but with a serial number for which there is no pre-signed
>response.
> > > > >Assuming presigned responses exist for all certificates that
>would
> > > be
> > > > >valid based on their validity intervals, this would occur if
the
> > > > >certificate had expired or was yet to be issued (I am aware the
> > > > keyless
> > > > >responders generally produce responses for certificates likely
to
>be
> > > > >issued before the next generation of presigned responses). The
>keyed
> > > > >responder would give a signed "good" response. My understanding
>is
> > > > that
> > > > >the keyless responder under the draft lightweight OCSP responds
>with
> > > > an
> > > > >unsigned "unauthorized" error code.
> > > > >
> > > > >     b) The request is for the status of a certificate from an
> > > > >unsupported (or non-existent) CA. The keyed responder would
>respond
> > > > >with a signed "unknown" response while under the draft, the
>keyless
> > > > >would again respond with the unsigned "unauthorized" error
code.
> > > > >
> > > > >Some might argue with some grounds that these differences are
> > > unusual,
> > > > >unlikely, and insignificant.
> > > > >
> > > > >I personally consider the behavior in 2 of responding with the
> > > > >"unauthorized" error to be misleading. "Internal error" sounds
>more
> > > > >appropriate if I were constrained to the current error codes.
> > > > >"Malformed request" might be OK. However, the actual situation
>does
> > > > not
> > > > >match well with any of these errors as they are described in
>2560.
> > > > >
> > > > >If 2560 is supposed to encompass keyless responders, I'd
>recommend
> > > > >identifying the unavoidable differences and/or adding 2 TBD
error
> > > > codes
> > > > >for the above cases (assuming they are the only differences).
The
> > > > first
> > > > >error can be worked around by breaking the request for status
of
> > > > >multiples into multiple requests for status of one cert.
> > > > >
> > > > >We've also seen some problems with client apps that can't
handle
> > > > >presigned responses that commonly contain the status of several
> > > (e.g.,
> > > > >15-25) certs. The apps inquired for the status of a single cert
>and
> > > > >apparently expected a response for a single certificate. I'd
>suggest
> > > > >that some "must" or "should" words address clients' ability to
> > > handle
> > > > >the situation of a response covering multiple certificates.
> > > > >
> > > > >
> > > > >
> > > > >Bill Price
> > > > >
> > > > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > > > >Sent: Monday, November 13, 2006 11:46 AM
> > > > >To: Michael Myers; Dave Engberg
> > > > >Cc: [email-masked]; Sam Hartman
> > > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
>2560
> > > > >
> > > > >
> > > > >Mike:
> > > > >
> > > > >I think it is not that simple.  I think you need to say that
>support
> > > > >for one certificate MUST be supported, and that support for
more
> > > than
> > > > >one certificate is OPTIONAL.  Then, the error is am indication
>that
> > > > >the requestor has selected an unimplemented OPTION.
> > > > >
> > > > >Russ
> > > > >
> > > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > > >Responders unable to produce or acquire a definitive response
>MUST
> > > > >return <a
> > > > > >TBD error>.
> > > > > >
> > > > > >As to your other points Santosh, that is something I prefer
the
> > > > chairs
> > > > > >consider.
> > > > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > > >
> > > > > > > Mike,
> > > > > > >
> > > > > > > What is the error case?
> > > > > > >
> > > > > > > . . .
> > >

From: "Michael Myers" <[email-masked]>
To: "Sam Hartman" <[email-masked]>, "Paul Hoffman" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 10:33:21 -0800
Importance: Normal
Sender: [email-masked]

How about we expand the meaning of "unauthorized" to mean EITHER the
requestor is not authorized to ask the responder OR the responder is not
authorized to fulfill the request.  That's not *too* ugly, is it?

Given that, everything else (i.e. MUST support singles, SHOULD support
multiples, else respond with error) falls out pretty clean without impacting
extant deployments.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Sam Hartman
Sent: Wednesday, November 15, 2006 10:16 AM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:

    Paul> I also do not see how we can handle the problem without
    Paul> changing the OCSP version number, but I would really like to
    Paul> be wrong about that.

You can decide that the interoperability hit of changing the version
number is worse than changing the meaning of the old version
retroactively.  It is always hard to make that call, and you better be
right if you decide not to change a version number.  But it is a
tradeoff it is valid to consider.

From: Sam Hartman <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 13:16:04 -0500
Sender: [email-masked]

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:

    Paul> I also do not see how we can handle the problem without
    Paul> changing the OCSP version number, but I would really like to
    Paul> be wrong about that.

You can decide that the interoperability hit of changing the version
number is worse than changing the meaning of the old version
retroactively.  It is always hard to make that call, and you better be
right if you decide not to change a version number.  But it is a
tradeoff it is valid to consider.

From: "likely" <[email-masked]>
To: [email-masked]
Subject: attitudes towards make
Date: 	Wed, 15 Nov 2006 19:09:47 +0100

------=_NextPart_000_000B_01C708E9.9E31BB50
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000C_01C708E9.9E31BB50"

------=_NextPart_001_000C_01C708E9.9E31BB50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Might am bethe Anton Webern.
Standing class musicfor whereas incomes. Orchestras film companies =
schools work in seeking contracts variety.
Press a features image.
Harmonic rhythmic greatest latitude thought imagined of. Material quite =
a strict?
Textbooks Wikibooks Quotations a Wikiquote texts Wikisource Images?
Understood learned edit?
Disagreed a must consist Instead in he argued any of. Genre detail =
explicitly.
Completely lost Recent Evelyn.
Modernera am concertos concerts is halls sitting quietly seatson hand.
Receive in credit of taking am overview. Notes External linksedit =
article musicsee genrethe broadest There are!
Uniquely am humanmusic technical manner refers.
Ornaments trills turnsin give without a describing devices obtain =
expressive? Notes External linksedit article musicsee genrethe broadest =
There are!
Sister Dictionary Wiktionary Textbooks Wikibooks Quotations Wikiquote. =
Wikibooks Quotations Wikiquote texts?
Groups works or described.
Single society am does not pass same a place short rarely? Ballet scores =
of serialism bebopera or rap punk nonmusic critics a when?
Created playing vocals of whole direct expression emotions designed =
manipulate.
Helped outcomes patients of Owen Johnson.
Approach specific in piecesfor.
Standing class musicfor whereas incomes.
Research relatively am credential.
Took newspaper protesting ad appeared.
Where front Naxi who or performs.
Took newspaper protesting ad appeared.
Largely standing of class musicfor whereas incomes hiphop innercity a =
area.
------=_NextPart_001_000C_01C708E9.9E31BB50
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"might" hspace=3D0=20
src=3D"cid:000a01c708e1$3c6ae250$00000000@richard" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Might am bethe Anton =
Webern.<BR>Standing class=20
musicfor whereas incomes. Orchestras film companies schools work in =
seeking=20
contracts variety.<BR>Press a features image.<BR>Harmonic rhythmic =
greatest=20
latitude thought imagined of. Material quite a strict?<BR>Textbooks =
Wikibooks=20
Quotations a Wikiquote texts Wikisource Images?<BR>Understood learned=20
edit?<BR>Disagreed a must consist Instead in he argued any of. Genre =
detail=20
explicitly.<BR>Completely lost Recent Evelyn.<BR>Modernera am concertos =
concerts=20
is halls sitting quietly seatson hand.<BR>Receive in credit of taking am =

overview. Notes External linksedit article musicsee genrethe broadest =
There=20
are!<BR>Uniquely am humanmusic technical manner refers.<BR>Ornaments =
trills=20
turnsin give without a describing devices obtain expressive? Notes =
External=20
linksedit article musicsee genrethe broadest There are!<BR>Sister =
Dictionary=20
Wiktionary Textbooks Wikibooks Quotations Wikiquote. Wikibooks =
Quotations=20
Wikiquote texts?<BR>Groups works or described.<BR>Single society am does =
not=20
pass same a place short rarely? Ballet scores of serialism bebopera or =
rap punk=20
nonmusic critics a when?<BR>Created playing vocals of whole direct =
expression=20
emotions designed manipulate.<BR>Helped outcomes patients of Owen=20
Johnson.<BR>Approach specific in piecesfor.<BR>Standing class musicfor =
whereas=20
incomes.<BR>Research relatively am credential.<BR>Took newspaper =
protesting ad=20
appeared.<BR>Where front Naxi who or performs.<BR>Took newspaper =
protesting ad=20
appeared.<BR>Largely standing of class musicfor whereas incomes hiphop =
innercity=20
a area.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000C_01C708E9.9E31BB50--

------=_NextPart_000_000B_01C708E9.9E31BB50
Content-Type: image/gif;
	name="consensus.gif"
Content-Transfer-Encoding: base64
Content-ID: <000a01c708e1$3c6ae250$00000000@richard>

------=_NextPart_000_000B_01C708E9.9E31BB50--

Date: Wed, 15 Nov 2006 09:51:32 -0800
To: "[email-masked]" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: Sam Hartman <[email-masked]>
Sender: [email-masked]

At 6:16 PM -0500 11/14/06, Russ Housley wrote:
>Stefan:
>
>>There is no place where RFC 2560 requires the render to 
>>successfully handle a composite request. It only specifies how it 
>>should be done.
>
>It does not say one way or the other.  That is the problem.  It 
>specifies the syntax, without telling the reader whether some or all 
>of it is mandatory to implement.  This is the crux of Sam's discuss 
>position.  Nothing in the text leads the reader to believe that 
>responding to a multi-certificate query is OPTIONAL.
>
>I find the use of "unauthorized" to indicate that a client cannot 
>make a multi-certificate request unacceptable.  To me, that implies 
>that some other client would be authorized to make such a request.
>
>I also find the use of "internalError" to indicate that a client 
>cannot make a multi-certificate request unacceptable.

Unfortunately, I agree with Russ on this one. We boxed ourselves in 
with the definitions of the response semantics because we did not 
predict this case.

I also do not see how we can handle the problem without changing the 
OCSP version number, but I would really like to be wrong about that.

--Paul Hoffman, Director
--VPN Consortium

From: "Julien Stern" <[email-masked]>
Date: Wed, 15 Nov 2006 18:28:23 +0100
To: [email-masked]
Subject: Re: RFC3280bis: NotAfter 99991231235959Z
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 15, 2006 at 09:55:47AM -0500, Russ Housley wrote:
> 
> I would like to add some text about certificates that are not 
> intended to expire.  I propose the following paragraph.
> 
> In some situations, devices are given permanent certificates.  For 
> example, a device could be issued a certificate that binds its model 
> and serial number to its public key.  Such a certificate is intended 
> to be used for the entire lifetime of the device.  It indicate the 
> permanent nature of such a certificate, the notAfter SHOULD be 
> assigned the GeneralizedTime value of 99991231235959Z.
> 
> Any concerns?

If the device is somehow stolen or compromised at some point,
doesn't this mean that you will have to keep its serial number in a CRL
(or an other revocation system) until the end of times?

When faced with a somehow similar issue, we decided to set the date to
the expected lifetime of the device plus a few years to avoid the above
issue.

--
Julien

Content-Class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 09:12:50 -0800
From: Ryan Hurst <[email-masked]>
To: Russ Housley <[email-masked]>, Stefan Santesson <[email-masked]>, <[email-masked]>
CC: Sam Hartman <[email-masked]>
Sender: [email-masked]

This problem is not limited to multi-certificate requests, there are a
number of optional items in 2560 where this same problem exists (OCSP
request extensions, multi-cert requests where responders cannot
authoritatively respond to all certificates, etc.); 2560 does not tell
implementers how to deal with these cases at all.

This leaves us with a practical problem, since there were at one point
(I have not been watching products in this space for some time) at least
a dozen interoperable implementations of 2560 we need to ask if it is
appropriate for us to change the 2560 in such a way to break those
implementations?

I would argue that continued interoperability trumps technical purity
here, I don't think anyone would argue against adding additional errors
before this was the case the but cat is out of the bag; now the question
becomes what have the implementations done to achieve the
interoperability that does exist, and should we clarify 2560 to make
that more obvious for the next implementers?

In general I don't see a problem with this question in principal but at
the same time I do not want to see us crack open 2560 as it opens the
door to many other edits that have the potential to break
implementations, but if we must how do we limit these edits to those
that provide clarity and do not break these existing implementations?

I also (selfishly maybe) do not want to see this draft be held up any
further, we have reached the point where there is rough consensus in the
WG and with the implementers, we have working code shipping from
multiple vendors and documenting what these interoperable
implementations do to help others in the future just seems to make
sense; frankly I just don't see how holding the LW OCSP draft up helps
anyone.

What I would like to propose is that we let the LW OCSP draft go forward
since it doesn't conflict with 2560 as it stands today and then begin a
2560bis effort, were I would be willing to work with Mike, Dave, Alex to
identify text that would clarify some of these points without breaking
existing implementations as long as the WG and its chairs will help us
limit the scope of these changes to clarifications and not go down the
path of creating a new version of the protocol.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Tuesday, November 14, 2006 3:17 PM
To: Stefan Santesson; [email-masked]
Cc: Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Stefan:

>There is no place where RFC 2560 requires the render to successfully 
>handle a composite request. It only specifies how it should be done.

It does not say one way or the other.  That is the problem.  It 
specifies the syntax, without telling the reader whether some or all 
of it is mandatory to implement.  This is the crux of Sam's discuss 
position.  Nothing in the text leads the reader to believe that 
responding to a multi-certificate query is OPTIONAL.

I find the use of "unauthorized" to indicate that a client cannot 
make a multi-certificate request unacceptable.  To me, that implies 
that some other client would be authorized to make such a request.

I also find the use of "internalError" to indicate that a client 
cannot make a multi-certificate request unacceptable.

Russ

Date: Wed, 15 Nov 2006 17:05:43 +0000
From: Dr Stephen Henson <[email-masked]>
To: [email-masked]
Subject: Re: PEM file format rfc draft request
Sender: [email-masked]

Peter Gutmann wrote:
> "Dieter Bratko" <[email-masked]> writes:
> 
>> For that reason a standard giving some recommendations for the usage of PEM
>> headers would be very useful. It should not only cover keys, but also
>> certificates, crls, requests,... (for instance, some applications use -----
>> BEGIN CERTIFICATE REQUEST-----. and some use -----BEGIN NEW CERTIFICATE
>> REQUEST-----, and some may use  -----BEGIN PKCS10 REQUEST---- or something
>> other for encoding a certificate request).
> 
> That's why I suggested that a regexp is the only way to handle this.  You also
> need to take into account usage in other environments like PGP and SSH, which
> also use the PEM format.  From memory my code's workflow is something like:
> 
>   look for '----';
>   look for either another '-' or a ' ';
>   look for 'BEGIN';
> 
> This handles the common PEM start.  Then:
> 
>   if the remaining text contains 'SSH' it's an SSH public key;
>     goto SSH-processing;
>   if the remaining text contains 'PGP' it's a PGP public key;
>     goto PGP-processing;
>   // Default: It's something X.509-ish
>   if the remaining text contains 'REQUEST' or 'PKCS10' it's a PKCS #10 cert request;
>   if the remainig text contains 'PRIVATE' it's a private key;
>   otherwise it's a cert of some form;
> 
> This should handle pretty much everything out there.
> 

I've seen several variants on that. A far from exhaustive list from
memory...

If it includes 'PKCS7' or 'PKCS#7' then it is a PKCS#7 ContentInfo,
usually but not always certs only.

'X509' is normally a certificate but I've also seen it containing PKCS#7
certs only and something called "Netscape Certificates Sequence".

Contains 'CERTIFICATE' oddly enough a certificate.

Contains 'CRL': CRL.

Is 'ENCRYPTED PRIVATE KEY' is PKCS#8 EncryptedPrivateKeyInfo.

Is 'PRIVATE KEY' (with no mention of algorithm) PKCS#8 PrivateKeyInfo.

Is 'RSA PRIVATE KEY' PKCS#1 RSAPrivateKey.

Is 'DSA PRIVATE KEY' SSLeay compatible DSA private key.

Private key types PKCS#8 related can include encryption parameters in
the headers.

Is 'PUBLIC KEY' SubjectPublicKeyInfo (RFC3280 et al).

Contains 'PARAMETERS': DSA, DH, EC parameters of various types.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

Date: Wed, 15 Nov 2006 12:04:47 -0500
To: Stephen Farrell <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: RFC3280bis: NotAfter 99991231235959Z
Cc: [email-masked]
Sender: [email-masked]

I am fine with the alternate wording.  I want the 99991231235959Z 
suggestion in the document.

Russ

At 11:50 AM 11/15/2006, Stephen Farrell wrote:

>Russ Housley wrote:
>>I would like to add some text about certificates that are not 
>>intended to expire.  I propose the following paragraph.
>>In some situations, devices are given permanent certificates.  For 
>>example, a device could be issued a certificate that binds its 
>>model and serial number to its public key.  Such a certificate is 
>>intended to be used for the entire lifetime of the device.  It 
>>indicate the permanent nature of such a certificate, the notAfter 
>>SHOULD be assigned the GeneralizedTime value of 99991231235959Z.
>>Any concerns?
>
>I like the idea, but according to my local folders, when we discussed
>this off list before and came up with a variant wording which I think
>was:
>
>"In some situations, devices are given certificates for which no good
>expiration date can be assigned.  For example, a device could be issued
>a certificate that binds its model and serial number to its public key;
>such a certificate is intended to be used for the entire lifetime of 
>the device.
>
>To indicate that a certificate has no well defined expiration date, the
>notAfter MUST be assigned the GeneralizedTime value of 99991231235959Z."
>
>There was some discussion about whether that last MUST is right or
>not, (and I don't care myself), but I guess we never did put any of
>it into the draft,
>
>Cheers
>Stephen.
>

Date: Wed, 15 Nov 2006 16:59:34 +0000
From: Dr Stephen Henson <[email-masked]>
To: [email-masked]
Subject: Re: PEM file format rfc draft request
Sender: [email-masked]

Peter Gutmann wrote:
> "Dieter Bratko" <[email-masked]> writes:
> 
>> For that reason a standard giving some recommendations for the usage of PEM
>> headers would be very useful. It should not only cover keys, but also
>> certificates, crls, requests,... (for instance, some applications use -----
>> BEGIN CERTIFICATE REQUEST-----. and some use -----BEGIN NEW CERTIFICATE
>> REQUEST-----, and some may use  -----BEGIN PKCS10 REQUEST---- or something
>> other for encoding a certificate request).
> 
> That's why I suggested that a regexp is the only way to handle this.  You also
> need to take into account usage in other environments like PGP and SSH, which
> also use the PEM format.  From memory my code's workflow is something like:
> 
>   look for '----';
>   look for either another '-' or a ' ';
>   look for 'BEGIN';
> 
> This handles the common PEM start.  Then:
> 
>   if the remaining text contains 'SSH' it's an SSH public key;
>     goto SSH-processing;
>   if the remaining text contains 'PGP' it's a PGP public key;
>     goto PGP-processing;
>   // Default: It's something X.509-ish
>   if the remaining text contains 'REQUEST' or 'PKCS10' it's a PKCS #10 cert request;
>   if the remainig text contains 'PRIVATE' it's a private key;
>   otherwise it's a cert of some form;
> 
> This should handle pretty much everything out there.
> 

I've seen several variants on that a far from exhaustive list from memory...

If it includes 'PKCS7' or 'PKCS#7' then it is a PKCS#7 ContentInfo,
usually but not always certs only.

'X509' is normally a certificate but I've also seen it containing PKCS#7
certs only and something called "Netscape Certificates Sequence".

Contains 'CERTIFICATE' oddly enough a certificate.

Contains 'CRL': CRL.

Is 'ENCRYPTED PRIVATE KEY' is PKCS#8 EncryptedPrivateKeyInfo.

Is 'PRIVATE KEY' (with no mention of algorithm) PKCS#8 PrivateKeyInfo.

Is 'RSA PRIVATE KEY' PKCS#1 RSAPrivateKey.

Is 'DSA PRIVATE KEY' SSLeay compatible DSA private key.

Private key types PKCS#8 related can include encryption parameters in
the headers.

Is 'PUBLIC KEY' SubjectPublicKeyInfo (RFC3280 et al).

Contains 'PARAMETERS': DSA, DH, EC parameters of various types.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

Content-class: urn:content-classes:message
Subject: RE: questions on CertificatePolicies processing
Date: Wed, 15 Nov 2006 08:59:46 -0800
From: "Matt Cooper" <[email-masked]>
To: "Kopylov Denis" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Q1: Is there any sense in setting user-initial-policy-set without
setting initial_explicit_policy?
[Matt] In some circumstances it may be of value during authentication
and authorization.  For example, if the certificate is valid, but valid
for no policies, allow access only to A.  If valid for policy X, allow
access to A and B, etc.  However, in many circumstances, I think
software may choose to set initial-explicit-policy if an initial policy
set is supplied, as this would frequently be the intent of supplying the
initial set.  I think this decision is dependent on what you are
attempting to achieve through the certificate validation and what sort
of feedback (if any) the software will supply to the user relating to
the final policy set.  In any case, if an initial policy set can be
supplied, there should be a way to turn on initial-require-explicit if
this is not the default behavior of the software.

Q2: How should be treated a valid certificate if validation with
non-empty user-initial-policy-set resulted in empty valid_policy_tree?
[Matt] If require explicit policy is set, either initially or by a
certificate in the path, the certificate is not valid if the final
policy set is empty.

Matt Cooper
CygnaCom Solutions
7925 Jones Branch Dr, Suite 5200
McLean, VA  22102
http://www.cygnacom.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kopylov Denis
Sent: Wednesday, November 15, 2006 8:00 AM
To: [email-masked]
Subject: questions on CertificatePolicies processing

Q1: Is there any sense in setting user-initial-policy-set without
setting initial_explicit_policy?

Q2: How should be threated a valid certificate if validation with
non-empty user-initial-policy-set resulted in empty valid_policy_tree?

--
Kopylov Denis
kopylov at top-cross.ru

Date: Wed, 15 Nov 2006 16:50:00 +0000
From: Stephen Farrell <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC3280bis: NotAfter 99991231235959Z
Sender: [email-masked]

Russ Housley wrote:
> 
> I would like to add some text about certificates that are not intended 
> to expire.  I propose the following paragraph.
> 
> In some situations, devices are given permanent certificates.  For 
> example, a device could be issued a certificate that binds its model and 
> serial number to its public key.  Such a certificate is intended to be 
> used for the entire lifetime of the device.  It indicate the permanent 
> nature of such a certificate, the notAfter SHOULD be assigned the 
> GeneralizedTime value of 99991231235959Z.
> 
> Any concerns?

I like the idea, but according to my local folders, when we discussed
this off list before and came up with a variant wording which I think
was:

"In some situations, devices are given certificates for which no good
expiration date can be assigned.  For example, a device could be issued
a certificate that binds its model and serial number to its public key;
such a certificate is intended to be used for the entire lifetime of the 
device.

To indicate that a certificate has no well defined expiration date, the
notAfter MUST be assigned the GeneralizedTime value of 99991231235959Z."

There was some discussion about whether that last MUST is right or
not, (and I don't care myself), but I guess we never did put any of
it into the draft,

Cheers
Stephen.

From: "Peter Rybar" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: [email-masked]
Subject: RE: RFC3280bis: NotAfter 99991231235959Z
Date: Wed, 15 Nov 2006 17:39:13 +0100
Sender: [email-masked]

Some utility written in C language time (The time function returns the number of seconds elapsed since midnight (00:00:00), January 1, 1970,) will crash. ;-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Wednesday, November 15, 2006 3:56 PM
To: [email-masked]
Subject: RFC3280bis: NotAfter 99991231235959Z

I would like to add some text about certificates that are not 
intended to expire.  I propose the following paragraph.

In some situations, devices are given permanent certificates.  For 
example, a device could be issued a certificate that binds its model 
and serial number to its public key.  Such a certificate is intended 
to be used for the entire lifetime of the device.  It indicate the 
permanent nature of such a certificate, the notAfter SHOULD be 
assigned the GeneralizedTime value of 99991231235959Z.

Any concerns?

Russ

Content-Class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 08:35:51 -0800
From: Ryan Hurst <[email-masked]>
To: Stefan Santesson <[email-masked]>, Santosh Chokhani <[email-masked]>, Russ Housley <[email-masked]>, "Price, Bill" <[email-masked]>, <[email-masked]>
CC: Sam Hartman <[email-masked]>, Michael Myers <[email-masked]>, Dave Engberg <[email-masked]>
Sender: [email-masked]

Although I know of toolkits that can send requests like this, and
servers that can respond like this I know of no clients that send
requests like this.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Tuesday, November 14, 2006 9:11 AM
To: Santosh Chokhani; Russ Housley; Price, Bill; [email-masked]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh,

I didn't say it was hard. I say that I doubt that there are many
implementations supporting this scenario even those with a responder
key.
It would be interesting to hear from implementers if I'm right.

Stefan Santesson
Senior Program Manager

> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: den 14 november 2006 03:59
> To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> Stefan,
>
> You are making more complex than it is.  The Responder can include all
> the CA certificates that issued the certificate in question and AIA
can
> do the rest.
>
> Furthermore, since most PKI are two tier hierarchy, in Enterprise
> environment, the CA certificate certification path is not an issue.
>
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]]
> On Behalf Of Stefan Santesson
> Sent: Monday, November 13, 2006 6:54 PM
> To: Russ Housley; Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I'm not sure the case described is a realistic one.
>
> Section 2.2
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- a CA Designated Responder (Authorized Responder) who holds a
>       specially marked certificate issued directly by the CA,
> indicating
>       that the responder may issue OCSP responses for that CA
>
> Since the request is on certificates issued by 2 different CA:s trust
> option 1 is invalid.
> Trust option 3 is valid in theory but in practice it requires that the
> OCSP responder provide multiple validation paths in the response, one
> for each issuing CA. Somehow I doubt that this is implemented by
> anyone.
>
> Trust option 2 is not generic and is only valid as a result of a local
> configuration.
>
> So I don't think this is a problem only for key-less responders.
>
>
> Stefan Santesson
> Senior Program Manager
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Russ Housley
> > Sent: den 13 november 2006 14:08
> > To: Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I prefer an error that tells the client to ask for the certificate
> > one at a time.
> >
> > Russ
> >
> >
> > At 02:46 PM 11/13/2006, Price, Bill wrote:
> >
> > >I'd suggest focusing on understanding where responses to the keyed
> and
> > >keyless responders inherently differ. I am aware of two general
> cases:
> > >
> > >1) The request asks for the status of multiple certificates that
> have
> > >not been included in a single presigned response. Russ's example
> fits
> > >into this case. The keyed responder handles, but the keyless will
> fail
> > >for the general case. Some responders respond with the presigned
> > >response that includes one of the certificates (usually the first)
> in
> > >the request. A common situation is to ask for the status of
> > >certificates in a chain. Santosh points out some keyless responders
> > >anticipate this and bundle responses accordingly.
> > >
> > >2) The request is "well-formed" but asks for the status of a
> > >certificate for which the keyless responder has not prepared a
> > >response.  This situation will occur if:
> > >
> > >     a) The request is for status of a certificate from a supported
> CA
> > >but with a serial number for which there is no pre-signed response.
> > >Assuming presigned responses exist for all certificates that would
> be
> > >valid based on their validity intervals, this would occur if the
> > >certificate had expired or was yet to be issued (I am aware the
> > keyless
> > >responders generally produce responses for certificates likely to
be
> > >issued before the next generation of presigned responses). The
keyed
> > >responder would give a signed "good" response. My understanding is
> > that
> > >the keyless responder under the draft lightweight OCSP responds
with
> > an
> > >unsigned "unauthorized" error code.
> > >
> > >     b) The request is for the status of a certificate from an
> > >unsupported (or non-existent) CA. The keyed responder would respond
> > >with a signed "unknown" response while under the draft, the keyless
> > >would again respond with the unsigned "unauthorized" error  code.
> > >
> > >Some might argue with some grounds that these differences are
> unusual,
> > >unlikely, and insignificant.
> > >
> > >I personally consider the behavior in 2 of responding with the
> > >"unauthorized" error to be misleading. "Internal error" sounds more
> > >appropriate if I were constrained to the current error codes.
> > >"Malformed request" might be OK. However, the actual situation does
> > not
> > >match well with any of these errors as they are described in 2560.
> > >
> > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > >identifying the unavoidable differences and/or adding 2 TBD error
> > codes
> > >for the above cases (assuming they are the only differences). The
> > first
> > >error can be worked around by breaking the request for status of
> > >multiples into multiple requests for status of one cert.
> > >
> > >We've also seen some problems with client apps that can't handle
> > >presigned responses that commonly contain the status of several
> (e.g.,
> > >15-25) certs. The apps inquired for the status of a single cert and
> > >apparently expected a response for a single certificate. I'd
suggest
> > >that some "must" or "should" words address clients' ability to
> handle
> > >the situation of a response covering multiple certificates.
> > >
> > >
> > >
> > >Bill Price
> > >
> > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > >Sent: Monday, November 13, 2006 11:46 AM
> > >To: Michael Myers; Dave Engberg
> > >Cc: [email-masked]; Sam Hartman
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >Mike:
> > >
> > >I think it is not that simple.  I think you need to say that
support
> > >for one certificate MUST be supported, and that support for more
> than
> > >one certificate is OPTIONAL.  Then, the error is am indication that
> > >the requestor has selected an unimplemented OPTION.
> > >
> > >Russ
> > >
> > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > >Responders unable to produce or acquire a definitive response
MUST
> > >return <a
> > > >TBD error>.
> > > >
> > > >As to your other points Santosh, that is something I prefer the
> > chairs
> > > >consider.
> > > >
> > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > >
> > > > > Mike,
> > > > >
> > > > > What is the error case?
> > > > >
> > > > > . . .
>

From: "Peter Lipp" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: AW: PEM file format rfc draft request
Date: Wed, 15 Nov 2006 16:49:43 +0100
Sender: [email-masked]

> This should handle pretty much everything out there.
Sure. With a heavy machine your are always able to pick up all sorts of junk
that you find on the floor.... :-)

Our software is basically doing the same, but this not really an argument
for producing all sorts of junk. An official document may at least help
avoiding new incarnations of these things....

Peter

Content-class: urn:content-classes:message
Subject: AW: RFC3280bis: NotAfter 99991231235959Z
Date: Wed, 15 Nov 2006 16:43:13 +0100
From: <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

FYI

> -----Ursprüngliche Nachricht-----
> Von: Beckmann, Thomas [S229271] 
> Gesendet: Mittwoch, 15. November 2006 16:41
> An: 'Russ Housley'
> Betreff: AW: RFC3280bis: NotAfter 99991231235959Z
> 
> Russ,
> 
> what about the validity of the issuing ca? In general, the ca 
> certificate isn't valid that long, so the devices certificate 
> becomes invalid when the ca certificate expires. How will you 
> handle that?
> 
> Thomas
> 
> > -----Ursprüngliche Nachricht-----
> > Von: [email-masked]
> > [mailto:[email-masked]] Im Auftrag von Russ Housley
> > Gesendet: Mittwoch, 15. November 2006 15:56
> > An: [email-masked]
> > Betreff: RFC3280bis: NotAfter 99991231235959Z
> > 
> > 
> > I would like to add some text about certificates that are 
> not intended 
> > to expire.  I propose the following paragraph.
> > 
> > In some situations, devices are given permanent certificates. 
> >  For example, a device could be issued a certificate that binds its 
> > model and serial number to its public key.  Such a certificate is 
> > intended to be used for the entire lifetime of the device.  It 
> > indicate the permanent nature of such a certificate, the notAfter 
> > SHOULD be assigned the GeneralizedTime value of 99991231235959Z.
> > 
> > Any concerns?
> > 
> > Russ
> > 
> > 
> > 

Date: Wed, 15 Nov 2006 18:35:24 +0300
From: Kopylov Denis <[email-masked]>
Reply-To: [email-masked]
Organization: OOO =?UTF-8?B?0KLQvtC/INCa0YDQvtGB0YE=?=
To: [email-masked]
CC: Peter Rybar <[email-masked]>
Subject: Re: questions on CertificatePolicies processing
Sender: [email-masked]

Peter Rybar Ð¿Ð¸ÑˆÐµÑ‚:
> Some info are in
>
> http://www.nbusr.sk/sep/leg_rozne/kontrola_cert_cesty_en.pdf
>   
Thank you for the link. But there is no answer in that PDF - just one 
more description for validation procedure.
Main thought behind my questions is that there should be some difference 
in interpretation of empty valid_policy_set - depending on 
user_initial_policy_set value.

-- 
======================================================
Kopylov Denis
kopylov at top-cross.ru

Date: Wed, 15 Nov 2006 10:31:37 -0500
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: "Sam Hartman" <[email-masked]>
Sender: [email-masked]

Santosh:

My point is that the request could be for any set of certificates 
that contain AIAs that point to the same OCSP responder, whether they 
are part of the same certification path or not.

Russ

At 08:03 PM 11/14/2006, Santosh Chokhani wrote:
>Russ,
>
>I do not know how germane this debate is to Sam's question, but I was
>simply responding to the issue building certification path.  I presume
>that in this context it relates to building a path to the Responder
>certificate.
>
>Now let us look at the three model 2560 has: Explicitly Trusted, CA and
>Delegated.
>
>Explicitly trusted does not need a certification path and hence there is
>no issue and that is why I did not include it in.
>
>CA model does not need any path building since path to the CA has
>already been built and that is why I did not include it in my response.
>Note that both clients requires the CA to use the same to sign the OCSP
>as it signed the certificate in question with.
>
>My post responded to the Delegated model.
>
>I hope this clarifies that the path building should not be a major issue
>for all three models 2560 supports.
>
>From: Russ Housley [mailto:[email-masked]]
>Sent: Tuesday, November 14, 2006 6:42 PM
>To: Santosh Chokhani; [email-masked]
>Cc: Sam Hartman
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>Santosh:
>
>I believe this is a red herring.  This is not the only deployment
>approach supported by RFC 2560.
>
>Russ
>
> >In hurry, I did not clearly articulate my thoughts.  What I am saying
>also
> >relates to another comment to Mike Myers regarding the security of the
> >delegated model which is incompletely addressed by 2560.
> >
> >I will be verbose this time.
> >
> >The implementations such as Corestreet and Tumbleweed tend to adhere to
>the
> >approach that the same key that signed the certificate in question,
>sign the
> >OCSP Responder certificate.
> >
> >Thus, if you have a hierarchy like Root --> CA --> Subscriber and you
>want
> >the status of CA certificate and the Subscriber certificate, you get
>them as
> >responses and with them you only need the two OCSP Responder
>certificates
> >one signed by the Root (for verifying CA certificate revocation status)
>and
> >one signed by the CA (for verifying the subscriber certificate
>revocation
> >status).
> >
> >You do not need any paths.
> >
> >Please note that the approach also works when the Responder is queried
>by a
> >CA cross certified by the root, since rest of the path has been built
>by the
> >client.
> >
> >From: Dave Engberg [mailto:[email-masked]]
> >Sent: Tuesday, November 14, 2006 12:45 PM
> >To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
> >[email-masked]
> >Cc: Sam Hartman; Michael Myers
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >CoreStreet's OCSP server doesn't include a SingleResponse for the
>issuing
> >CA's cert in pre-signed responses.  Mostly for the reasons mentioned:
> >
> >Adds 90-100 bytes onto every response
> >
> >Have never seen a relying party app/plug-in send a request like this
> >
> >The "delegated" trust model in RFC 2560 would require different signing
> >certs for trusting entity vs. CA cert ... add another 1kB onto the
>response
> >
> >Protocol only sends CA name+key info, which isn't enough to identify
>which
> >CA cert the relying party is inspecting in the case of CA cert renewal,
> >cross-certification, etc.
> >
> >
> >From: Stefan Santesson [mailto:[email-masked]]
> >Sent: Tuesday, November 14, 2006 12:11 PM
> >To: Santosh Chokhani; Russ Housley; Price, Bill; [email-masked]
> >Cc: Sam Hartman; Michael Myers; Dave Engberg
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >Santosh,
> >
> >I didn't say it was hard. I say that I doubt that there are many
> >implementations supporting this scenario even those with a responder
>key.
> >It would be interesting to hear from implementers if I'm right.
> >
> >Stefan Santesson
> >Senior Program Manager
> > > From: Santosh Chokhani [mailto:[email-masked]]
> > > Sent: den 14 november 2006 03:59
> > > To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > > Stefan,
> > >
> > > You are making more complex than it is.  The Responder can include
>all
> > > the CA certificates that issued the certificate in question and AIA
>can
> > > do the rest.
> > >
> > > Furthermore, since most PKI are two tier hierarchy, in Enterprise
> > > environment, the CA certificate certification path is not an issue.
> > >
> > > From: [email-masked] [mailto:owner-ietf-
> > > [email-masked]]
> > > On Behalf Of Stefan Santesson
> > > Sent: Monday, November 13, 2006 6:54 PM
> > > To: Russ Housley; Price, Bill; [email-masked]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > > I'm not sure the case described is a realistic one.
> > >
> > > Section 2.2
> > >    All definitive response messages SHALL be digitally signed. The
>key
> > >    used to sign the response MUST belong to one of the following:
> > >
> > >    -- the CA who issued the certificate in question
> > >    -- a Trusted Responder whose public key is trusted by the
>requester
> > >    -- a CA Designated Responder (Authorized Responder) who holds a
> > >       specially marked certificate issued directly by the CA,
> > > indicating
> > >       that the responder may issue OCSP responses for that CA
> > >
> > > Since the request is on certificates issued by 2 different CA:s
>trust
> > > option 1 is invalid.
> > > Trust option 3 is valid in theory but in practice it requires that
>the
> > > OCSP responder provide multiple validation paths in the response,
>one
> > > for each issuing CA. Somehow I doubt that this is implemented by
> > > anyone.
> > >
> > > Trust option 2 is not generic and is only valid as a result of a
>local
> > > configuration.
> > >
> > > So I don't think this is a problem only for key-less responders.
> > >
> > >
> > > Stefan Santesson
> > > Senior Program Manager
> > > > From: [email-masked] [mailto:owner-ietf-
> > > > [email-masked]] On Behalf Of Russ Housley
> > > > Sent: den 13 november 2006 14:08
> > > > To: Price, Bill; [email-masked]
> > > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > > >
> > > >
> > > > I prefer an error that tells the client to ask for the certificate
> > > > one at a time.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > > >
> > > > >I'd suggest focusing on understanding where responses to the
>keyed
> > > and
> > > > >keyless responders inherently differ. I am aware of two general
> > > cases:
> > > > >
> > > > >1) The request asks for the status of multiple certificates that
> > > have
> > > > >not been included in a single presigned response. Russ's example
> > > fits
> > > > >into this case. The keyed responder handles, but the keyless will
> > > fail
> > > > >for the general case. Some responders respond with the presigned
> > > > >response that includes one of the certificates (usually the
>first)
> > > in
> > > > >the request. A common situation is to ask for the status of
> > > > >certificates in a chain. Santosh points out some keyless
>responders
> > > > >anticipate this and bundle responses accordingly.
> > > > >
> > > > >2) The request is "well-formed" but asks for the status of a
> > > > >certificate for which the keyless responder has not prepared a
> > > > >response.  This situation will occur if:
> > > > >
> > > > >     a) The request is for status of a certificate from a
>supported
> > > CA
> > > > >but with a serial number for which there is no pre-signed
>response.
> > > > >Assuming presigned responses exist for all certificates that
>would
> > > be
> > > > >valid based on their validity intervals, this would occur if the
> > > > >certificate had expired or was yet to be issued (I am aware the
> > > > keyless
> > > > >responders generally produce responses for certificates likely to
>be
> > > > >issued before the next generation of presigned responses). The
>keyed
> > > > >responder would give a signed "good" response. My understanding
>is
> > > > that
> > > > >the keyless responder under the draft lightweight OCSP responds
>with
> > > > an
> > > > >unsigned "unauthorized" error code.
> > > > >
> > > > >     b) The request is for the status of a certificate from an
> > > > >unsupported (or non-existent) CA. The keyed responder would
>respond
> > > > >with a signed "unknown" response while under the draft, the
>keyless
> > > > >would again respond with the unsigned "unauthorized" error  code.
> > > > >
> > > > >Some might argue with some grounds that these differences are
> > > unusual,
> > > > >unlikely, and insignificant.
> > > > >
> > > > >I personally consider the behavior in 2 of responding with the
> > > > >"unauthorized" error to be misleading. "Internal error" sounds
>more
> > > > >appropriate if I were constrained to the current error codes.
> > > > >"Malformed request" might be OK. However, the actual situation
>does
> > > > not
> > > > >match well with any of these errors as they are described in
>2560.
> > > > >
> > > > >If 2560 is supposed to encompass keyless responders, I'd
>recommend
> > > > >identifying the unavoidable differences and/or adding 2 TBD error
> > > > codes
> > > > >for the above cases (assuming they are the only differences). The
> > > > first
> > > > >error can be worked around by breaking the request for status of
> > > > >multiples into multiple requests for status of one cert.
> > > > >
> > > > >We've also seen some problems with client apps that can't handle
> > > > >presigned responses that commonly contain the status of several
> > > (e.g.,
> > > > >15-25) certs. The apps inquired for the status of a single cert
>and
> > > > >apparently expected a response for a single certificate. I'd
>suggest
> > > > >that some "must" or "should" words address clients' ability to
> > > handle
> > > > >the situation of a response covering multiple certificates.
> > > > >
> > > > >
> > > > >
> > > > >Bill Price
> > > > >
> > > > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > > > >Sent: Monday, November 13, 2006 11:46 AM
> > > > >To: Michael Myers; Dave Engberg
> > > > >Cc: [email-masked]; Sam Hartman
> > > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
>2560
> > > > >
> > > > >
> > > > >Mike:
> > > > >
> > > > >I think it is not that simple.  I think you need to say that
>support
> > > > >for one certificate MUST be supported, and that support for more
> > > than
> > > > >one certificate is OPTIONAL.  Then, the error is am indication
>that
> > > > >the requestor has selected an unimplemented OPTION.
> > > > >
> > > > >Russ
> > > > >
> > > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > > >Responders unable to produce or acquire a definitive response
>MUST
> > > > >return <a
> > > > > >TBD error>.
> > > > > >
> > > > > >As to your other points Santosh, that is something I prefer the
> > > > chairs
> > > > > >consider.
> > > > > >
> > > > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > > >
> > > > > > > Mike,
> > > > > > >
> > > > > > > What is the error case?
> > > > > > >
> > > > > > > . . .
> > >

Date: Wed, 15 Nov 2006 10:29:37 -0500
To: Stefan Santesson <[email-masked]>, Sam Hartman <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: "[email-masked]" <[email-masked]>, Michael Myers <[email-masked]>, Dave Engberg <[email-masked]>, "Price, Bill" <[email-masked]>
Sender: [email-masked]

I believe that this paragraph from RFC 2026 is the reason that Sam is 
willing to permit the document to progress as a Proposed Standard:

    A Proposed Standard should have no known technical omissions with
    respect to the requirements placed upon it.  However, the IESG may
    waive this requirement in order to allow a specification to advance
    to the Proposed Standard state when it is considered to be useful and
    necessary (and timely) even with known technical omissions.

Russ

At 05:56 PM 11/14/2006, Stefan Santesson wrote:

>Sam,
>
>Could you point us to the applicable interoperability requirements 
>IETF has established in general that would require such 
>clarification of RFC 2560.
>
>What is ironic in this situation is that this a cases where the 
>industry has been able to achieve interoperability (to a fairly high 
>degree at least), also with respect to keyless responders. I don't 
>think we serve the industry by denying publication of an 
>informational document describing how keyless responders has been implemented.
>
>Creating an RFC 2560bis may take considerable time.
>
>Stefan Santesson
>Senior Program Manager
> > From: Sam Hartman [mailto:[email-masked]]
> > Sent: den 14 november 2006 14:23
> > To: Stefan Santesson
> > Cc: [email-masked]; Michael Myers; Dave Engberg; Russ Housley;
> > Price, Bill
> > Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> > >>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:
> >
> >     Stefan> On issue number 1) it is my belief that the lightweight
> >     Stefan> profile should be allowed to progress without updating RFC
> >     Stefan> 2560. I have seen no requirements in RFC 2560 that
> >     Stefan> requires a keyed responder, even if it is clear that a
> >     Stefan> non-keyed responder can only respond to a subset of all
> >     Stefan> valid requests. If the lightweight OCSP profile is allowed
> >     Stefan> to progress, it MUST live within the current restrictions
> >     Stefan> of OCSP with respect to error codes.
> >
> >
> > Speaking as an holding a discuss, I cannot agree to allow the
> > lightweight profile to progress without a standards-track
> > clarification to 2560.
> >
> > Your reading of 2560 would not meet the interoperability requirements
> > that the IETF has established that in general, all clients of a
> > protocol be able to work with all servers of a protocol.  In order to
> > meet that requirement RFC 2560 needs to be normatively changed in
> > order to require that clients be able to send a request including only
> > one certificate.
> >
> > Unless I see new arguments I have not seen so far, my discuss stands.

Date: Wed, 15 Nov 2006 09:55:47 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RFC3280bis: NotAfter 99991231235959Z
Sender: [email-masked]

I would like to add some text about certificates that are not 
intended to expire.  I propose the following paragraph.

In some situations, devices are given permanent certificates.  For 
example, a device could be issued a certificate that binds its model 
and serial number to its public key.  Such a certificate is intended 
to be used for the entire lifetime of the device.  It indicate the 
permanent nature of such a certificate, the notAfter SHOULD be 
assigned the GeneralizedTime value of 99991231235959Z.

Any concerns?

Russ

Date: Wed, 15 Nov 2006 16:00:07 +0300
From: Kopylov Denis <[email-masked]>
Organization: OOO =?windows-1252?Q?=3F=3F=3F_=3F=3F=3F=3F=3F?=
To: [email-masked]
Subject: questions on CertificatePolicies processing
Sender: [email-masked]

Q1: Is there any sense in setting user-initial-policy-set without
setting initial_explicit_policy?

Q2: How should be threated a valid certificate if validation with
non-empty user-initial-policy-set resulted in empty valid_policy_tree?

-- 
Kopylov Denis
kopylov at top-cross.ru

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: PEM file format rfc draft request
Cc: [email-masked], [email-masked]
Date: Thu, 16 Nov 2006 01:24:46 +1300
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>I don't think these WGs generally have defined private key encodings, because
>private keys are not transferred over the net and thus are not critical for
>interoperability.

What you mean are "private keys shouldn't be transferred over the net but
frequently are".  The standard format for this is PKCS #12, but that's usually
wrapped up in MIME, not as PEM-format data.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: PEM file format rfc draft request
Cc: [email-masked]
Date: Thu, 16 Nov 2006 01:21:46 +1300
Sender: [email-masked]

"Dieter Bratko" <[email-masked]> writes:

>For that reason a standard giving some recommendations for the usage of PEM
>headers would be very useful. It should not only cover keys, but also
>certificates, crls, requests,... (for instance, some applications use -----
>BEGIN CERTIFICATE REQUEST-----. and some use -----BEGIN NEW CERTIFICATE
>REQUEST-----, and some may use  -----BEGIN PKCS10 REQUEST---- or something
>other for encoding a certificate request).

That's why I suggested that a regexp is the only way to handle this.  You also
need to take into account usage in other environments like PGP and SSH, which
also use the PEM format.  From memory my code's workflow is something like:

  look for '----';
  look for either another '-' or a ' ';
  look for 'BEGIN';

This handles the common PEM start.  Then:

  if the remaining text contains 'SSH' it's an SSH public key;
    goto SSH-processing;
  if the remaining text contains 'PGP' it's a PGP public key;
    goto PGP-processing;
  // Default: It's something X.509-ish
  if the remaining text contains 'REQUEST' or 'PKCS10' it's a PKCS #10 cert request;
  if the remainig text contains 'PRIVATE' it's a private key;
  otherwise it's a cert of some form;

This should handle pretty much everything out there.

Peter.

Date: Wed, 15 Nov 2006 14:03:07 +0300
From: Kopylov Denis <[email-masked]>
Reply-To: [email-masked]
Organization: OOO =?UTF-8?B?0KLQvtC/INCa0YDQvtGB0YE=?=
To: "[email-masked]" <[email-masked]>
Subject: question on CertificatePolicies processing
Sender: [email-masked]

Q1: Is there any sense in setting user-initial-policy-set without 
setting initial_explicit_policy?

Q2: How should be threated valid certificate if validation with 
non-empty user-initial-policy-set resulted in empty valid_policy_tree?

-- 
======================================================
Kopylov Denis
kopylov at top-cross.ru

From: "UsWork" <[email-masked]>
To: [email-masked]
Subject: Re: employee have
Date: 	Wed, 15 Nov 2006 10:28:46 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C708A0.D4D050C0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000B_01C708A0.D4D050C0"

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

  ----- Original Message -----=20
  From: [email-masked]=20
  To: [email-masked]=20
  Sent: Thursday, November 03:23:02 AM
  Subject: employee have

  Chargethe employee have of only default job.
  Free day Triallog Inregister a Nowhome Pagemy.
  If does not start.
  Editorbuy of now Welcome a. Re Soft Boysdate Prevdate am Nextthread =
Prevthread of Nextdate Boysto Boysfrom of.
  Uploading toolbar ruler of url cliptext column selection replace =
multiple in.
  Click in here release a veditplus bit While can serve good a.
  Your homeyour of lifein updatehas am Roaming Gnome turned or party =
bal. Gui of builder generating human.
  Jamo surround sound is.
  Flash Player dc Limewire is Manager in Explorer am Basic is Ares.
  Cliptext column in selection replace multiple undoredo of spell =
keyboard shortcuts is. Viruses am add am my alerts suggest friend a =
report!
  Screen of applicable press theenter bhzbhzon enterkey left cost =
center.
  Then Hermann Maier strap carvers Cameras. Commission Junction for =
Million.
  Solos vii rock rhythm worlds.
  Info in Publisher User am Awards History service allows.
  Timekeeper entry charge in. Cliptext column in selection replace =
multiple undoredo of spell keyboard shortcuts is.
  Free day Triallog Inregister a Nowhome Pagemy.
  Gaining marketing with clients that include a.
  Address found Datere Cdnext Siamese jpegnext threadre Stuff?
  Upgrade is business line offering give individual employees members is =
Sony. License any listed cannot is liable issues arise?
  Ill am London just or atthe catch About eve who.
  Upgrade is business line offering give individual employees members is =
Sony.
  Featured integrated cd burning ripping in?
  Picks Essential Internet Instant is.
  Get chance some Visualcron task scheduler automation!
  Soft Boysdate Prevdate Nextthread Prevthread?
------=_NextPart_001_000B_01C708A0.D4D050C0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"always" hspace=3D0=20
src=3D"cid:000901c70898$730be8c0$00000000@pcj" align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, November =
03:23:02 AM=20
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> employee have</DIV>
  <DIV><BR></DIV>
<DIV align=3Dcenter><FONT face=3DArial size=3D2>Chargethe employee have =
of only=20
default job.<BR>Free day Triallog Inregister a Nowhome Pagemy.<BR>If =
does not=20
start.<BR>Editorbuy of now Welcome a. Re Soft Boysdate Prevdate am =
Nextthread=20
Prevthread of Nextdate Boysto Boysfrom of.<BR>Uploading toolbar ruler of =
url=20
cliptext column selection replace multiple in.<BR>Click in here release =
a=20
veditplus bit While can serve good a.<BR>Your homeyour of lifein =
updatehas am=20
Roaming Gnome turned or party bal. Gui of builder generating =
human.<BR>Jamo=20
surround sound is.<BR>Flash Player dc Limewire is Manager in Explorer am =
Basic=20
is Ares.<BR>Cliptext column in selection replace multiple undoredo of =
spell=20
keyboard shortcuts is. Viruses am add am my alerts suggest friend a=20
report!<BR>Screen of applicable press theenter bhzbhzon enterkey left =
cost=20
center.<BR>Then Hermann Maier strap carvers Cameras. Commission Junction =
for=20
Million.<BR>Solos vii rock rhythm worlds.<BR>Info in Publisher User am =
Awards=20
History service allows.<BR>Timekeeper entry charge in. Cliptext column =
in=20
selection replace multiple undoredo of spell keyboard shortcuts =
is.<BR>Free day=20
Triallog Inregister a Nowhome Pagemy.<BR>Gaining marketing with clients =
that=20
include a.<BR>Address found Datere Cdnext Siamese jpegnext threadre=20
Stuff?<BR>Upgrade is business line offering give individual employees =
members is=20
Sony. License any listed cannot is liable issues arise?<BR>Ill am London =
just or=20
atthe catch About eve who.<BR>Upgrade is business line offering give =
individual=20
employees members is Sony.<BR>Featured integrated cd burning ripping=20
in?<BR>Picks Essential Internet Instant is.<BR>Get chance some =
Visualcron task=20
scheduler automation!<BR>Soft Boysdate Prevdate Nextthread=20
Prevthread?</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_000B_01C708A0.D4D050C0--

------=_NextPart_000_000A_01C708A0.D4D050C0
Content-Type: image/gif;
	name="order.gif"
Content-Transfer-Encoding: base64
Content-ID: <000901c70898$730be8c0$00000000@pcj>

------=_NextPart_000_000A_01C708A0.D4D050C0--

From: Sam Hartman <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Michael Myers <[email-masked]>, Dave Engberg <[email-masked]>, Russ Housley <[email-masked]>, "Price, Bill" <[email-masked]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 22:21:18 -0500
Sender: [email-masked]

>>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:

    Stefan> Sam, Could you point us to the applicable interoperability
    Stefan> requirements IETF has established in general that would
    Stefan> require such clarification of RFC 2560.

Sure.  Take a look at section 3.1 of
draft-carpenter-protocol-extensions (an approved BCP).  That BCP is
new, but the requirements in that section come from a long list of
RFCs that are quite old.  Brian included a list of RFCs discussing
interoperability in the recent atompub appeal response on HTTP
mandatory authentication.

A central principle of this interoperability is that there is an
interoperable protocol set where I can exchange one product for
another.

In other words I need to be able to set up my OCSP clients and servers
so that I can take vendor A's implementation and exchange it with
vendor B's implementation and have things still work.

The liberal interpretation of 2560 for servers is that they need to be
able to respond to any request.  However that's operationally
undesirable.  So, we need to modify the requirements of the protocol.
Really, we're fixing a spec bug: 2560 is way too unclear on this
issue.

Now, we've passed clarifications documents in the past.  That is
informational documents that describe errors in specs.  But that's not
what this profile is.  The profile is a protocol that specifies
requirements for clients and servers.  That's not something I can be
comfortable with unless it is clearly consistent with the spec.

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 17:03:24 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>
Sender: [email-masked]

Russ,

I do not know how germane this debate is to Sam's question, but I was
simply responding to the issue building certification path.  I presume
that in this context it relates to building a path to the Responder
certificate.

Now let us look at the three model 2560 has: Explicitly Trusted, CA and
Delegated.

Explicitly trusted does not need a certification path and hence there is
no issue and that is why I did not include it in.

CA model does not need any path building since path to the CA has
already been built and that is why I did not include it in my response.
Note that both clients requires the CA to use the same to sign the OCSP
as it signed the certificate in question with.

My post responded to the Delegated model.

I hope this clarifies that the path building should not be a major issue
for all three models 2560 supports.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 6:42 PM
To: Santosh Chokhani; [email-masked]
Cc: Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh:

I believe this is a red herring.  This is not the only deployment 
approach supported by RFC 2560.

Russ

>In hurry, I did not clearly articulate my thoughts.  What I am saying
also
>relates to another comment to Mike Myers regarding the security of the
>delegated model which is incompletely addressed by 2560.
>
>I will be verbose this time.
>
>The implementations such as Corestreet and Tumbleweed tend to adhere to
the
>approach that the same key that signed the certificate in question,
sign the
>OCSP Responder certificate.
>
>Thus, if you have a hierarchy like Root --> CA --> Subscriber and you
want
>the status of CA certificate and the Subscriber certificate, you get
them as
>responses and with them you only need the two OCSP Responder
certificates
>one signed by the Root (for verifying CA certificate revocation status)
and
>one signed by the CA (for verifying the subscriber certificate
revocation
>status).
>
>You do not need any paths.
>
>Please note that the approach also works when the Responder is queried
by a
>CA cross certified by the root, since rest of the path has been built
by the
>client.
>From: Dave Engberg [mailto:[email-masked]]
>Sent: Tuesday, November 14, 2006 12:45 PM
>To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
>[email-masked]
>Cc: Sam Hartman; Michael Myers
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
>CoreStreet's OCSP server doesn't include a SingleResponse for the
issuing
>CA's cert in pre-signed responses.  Mostly for the reasons mentioned:
>
>Adds 90-100 bytes onto every response
>
>Have never seen a relying party app/plug-in send a request like this
>
>The "delegated" trust model in RFC 2560 would require different signing
>certs for trusting entity vs. CA cert ... add another 1kB onto the
response
>
>Protocol only sends CA name+key info, which isn't enough to identify
which
>CA cert the relying party is inspecting in the case of CA cert renewal,
>cross-certification, etc.
>
>
>From: Stefan Santesson [mailto:[email-masked]]
>Sent: Tuesday, November 14, 2006 12:11 PM
>To: Santosh Chokhani; Russ Housley; Price, Bill; [email-masked]
>Cc: Sam Hartman; Michael Myers; Dave Engberg
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>Santosh,
>
>I didn't say it was hard. I say that I doubt that there are many
>implementations supporting this scenario even those with a responder
key.
>It would be interesting to hear from implementers if I'm right.
>
>Stefan Santesson
>Senior Program Manager
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: den 14 november 2006 03:59
> > To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> > Stefan,
> >
> > You are making more complex than it is.  The Responder can include
all
> > the CA certificates that issued the certificate in question and AIA
can
> > do the rest.
> >
> > Furthermore, since most PKI are two tier hierarchy, in Enterprise
> > environment, the CA certificate certification path is not an issue.
> >
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]]
> > On Behalf Of Stefan Santesson
> > Sent: Monday, November 13, 2006 6:54 PM
> > To: Russ Housley; Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I'm not sure the case described is a realistic one.
> >
> > Section 2.2
> >    All definitive response messages SHALL be digitally signed. The
key
> >    used to sign the response MUST belong to one of the following:
> >
> >    -- the CA who issued the certificate in question
> >    -- a Trusted Responder whose public key is trusted by the
requester
> >    -- a CA Designated Responder (Authorized Responder) who holds a
> >       specially marked certificate issued directly by the CA,
> > indicating
> >       that the responder may issue OCSP responses for that CA
> >
> > Since the request is on certificates issued by 2 different CA:s
trust
> > option 1 is invalid.
> > Trust option 3 is valid in theory but in practice it requires that
the
> > OCSP responder provide multiple validation paths in the response,
one
> > for each issuing CA. Somehow I doubt that this is implemented by
> > anyone.
> >
> > Trust option 2 is not generic and is only valid as a result of a
local
> > configuration.
> >
> > So I don't think this is a problem only for key-less responders.
> >
> >
> > Stefan Santesson
> > Senior Program Manager
> > > From: [email-masked] [mailto:owner-ietf-
> > > [email-masked]] On Behalf Of Russ Housley
> > > Sent: den 13 november 2006 14:08
> > > To: Price, Bill; [email-masked]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > > I prefer an error that tells the client to ask for the certificate
> > > one at a time.
> > >
> > > Russ
> > >
> > >
> > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > >
> > > >I'd suggest focusing on understanding where responses to the
keyed
> > and
> > > >keyless responders inherently differ. I am aware of two general
> > cases:
> > > >
> > > >1) The request asks for the status of multiple certificates that
> > have
> > > >not been included in a single presigned response. Russ's example
> > fits
> > > >into this case. The keyed responder handles, but the keyless will
> > fail
> > > >for the general case. Some responders respond with the presigned
> > > >response that includes one of the certificates (usually the
first)
> > in
> > > >the request. A common situation is to ask for the status of
> > > >certificates in a chain. Santosh points out some keyless
responders
> > > >anticipate this and bundle responses accordingly.
> > > >
> > > >2) The request is "well-formed" but asks for the status of a
> > > >certificate for which the keyless responder has not prepared a
> > > >response.  This situation will occur if:
> > > >
> > > >     a) The request is for status of a certificate from a
supported
> > CA
> > > >but with a serial number for which there is no pre-signed
response.
> > > >Assuming presigned responses exist for all certificates that
would
> > be
> > > >valid based on their validity intervals, this would occur if the
> > > >certificate had expired or was yet to be issued (I am aware the
> > > keyless
> > > >responders generally produce responses for certificates likely to
be
> > > >issued before the next generation of presigned responses). The
keyed
> > > >responder would give a signed "good" response. My understanding
is
> > > that
> > > >the keyless responder under the draft lightweight OCSP responds
with
> > > an
> > > >unsigned "unauthorized" error code.
> > > >
> > > >     b) The request is for the status of a certificate from an
> > > >unsupported (or non-existent) CA. The keyed responder would
respond
> > > >with a signed "unknown" response while under the draft, the
keyless
> > > >would again respond with the unsigned "unauthorized" error  code.
> > > >
> > > >Some might argue with some grounds that these differences are
> > unusual,
> > > >unlikely, and insignificant.
> > > >
> > > >I personally consider the behavior in 2 of responding with the
> > > >"unauthorized" error to be misleading. "Internal error" sounds
more
> > > >appropriate if I were constrained to the current error codes.
> > > >"Malformed request" might be OK. However, the actual situation
does
> > > not
> > > >match well with any of these errors as they are described in
2560.
> > > >
> > > >If 2560 is supposed to encompass keyless responders, I'd
recommend
> > > >identifying the unavoidable differences and/or adding 2 TBD error
> > > codes
> > > >for the above cases (assuming they are the only differences). The
> > > first
> > > >error can be worked around by breaking the request for status of
> > > >multiples into multiple requests for status of one cert.
> > > >
> > > >We've also seen some problems with client apps that can't handle
> > > >presigned responses that commonly contain the status of several
> > (e.g.,
> > > >15-25) certs. The apps inquired for the status of a single cert
and
> > > >apparently expected a response for a single certificate. I'd
suggest
> > > >that some "must" or "should" words address clients' ability to
> > handle
> > > >the situation of a response covering multiple certificates.
> > > >
> > > >
> > > >
> > > >Bill Price
> > > >
> > > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > > >Sent: Monday, November 13, 2006 11:46 AM
> > > >To: Michael Myers; Dave Engberg
> > > >Cc: [email-masked]; Sam Hartman
> > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
2560
> > > >
> > > >
> > > >Mike:
> > > >
> > > >I think it is not that simple.  I think you need to say that
support
> > > >for one certificate MUST be supported, and that support for more
> > than
> > > >one certificate is OPTIONAL.  Then, the error is am indication
that
> > > >the requestor has selected an unimplemented OPTION.
> > > >
> > > >Russ
> > > >
> > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > >Responders unable to produce or acquire a definitive response
MUST
> > > >return <a
> > > > >TBD error>.
> > > > >
> > > > >As to your other points Santosh, that is something I prefer the
> > > chairs
> > > > >consider.
> > > > >
> > > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > >
> > > > > > Mike,
> > > > > >
> > > > > > What is the error case?
> > > > > >
> > > > > > . . .
> >

Date: Tue, 14 Nov 2006 16:06:33 -0800
To: [email-masked] (Peter Gutmann), [email-masked], [email-masked], [email-masked], "David A. Cooper" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: PEM file format rfc draft request
Cc: [email-masked]
Sender: [email-masked]

At 5:25 AM +1300 11/15/06, Peter Gutmann wrote:
>I think the best you could do is create an kind of FYI RFC that
>documents all of the possible formats (I started this in my X.509 style guide
>some years ago), or maybe document a regexp that'll recognise all possible
>formats.

Yes.

At 5:27 AM +1300 11/15/06, Peter Gutmann wrote:
>"Ogle Ron" <[email-masked]> writes:
>
>  >If not PKIX, then where?
>
>A web page somewhere where Google can find it.  Given that this is such a
>moving target, I'm not sure that an RFC is the best way to document this even
>if you could find a WG that would adopt it.

Even better.

At 2:42 PM -0500 11/14/06, David A. Cooper wrote:
>Why is there need to base64 encode everything?  It made sense in PEM 
>due to the limitations of email, but what is the benefit of base64 
>encoding in other situations?

Copy and paste text. This is *commonly* used in IPsec UIs for cert 
issuance, and sometimes for trust anchor passing.

--Paul Hoffman, Director
--VPN Consortium

Date: Tue, 14 Nov 2006 18:42:07 -0500
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: "Sam Hartman" <[email-masked]>
Sender: [email-masked]

Santosh:

I believe this is a red herring.  This is not the only deployment 
approach supported by RFC 2560.

Russ

>In hurry, I did not clearly articulate my thoughts.  What I am saying also
>relates to another comment to Mike Myers regarding the security of the
>delegated model which is incompletely addressed by 2560.
>
>I will be verbose this time.
>
>The implementations such as Corestreet and Tumbleweed tend to adhere to the
>approach that the same key that signed the certificate in question, sign the
>OCSP Responder certificate.
>
>Thus, if you have a hierarchy like Root --> CA --> Subscriber and you want
>the status of CA certificate and the Subscriber certificate, you get them as
>responses and with them you only need the two OCSP Responder certificates
>one signed by the Root (for verifying CA certificate revocation status) and
>one signed by the CA (for verifying the subscriber certificate revocation
>status).
>
>You do not need any paths.
>
>Please note that the approach also works when the Responder is queried by a
>CA cross certified by the root, since rest of the path has been built by the
>client.
>
>From: Dave Engberg [mailto:[email-masked]]
>Sent: Tuesday, November 14, 2006 12:45 PM
>To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
>[email-masked]
>Cc: Sam Hartman; Michael Myers
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
>CoreStreet's OCSP server doesn't include a SingleResponse for the issuing
>CA's cert in pre-signed responses.  Mostly for the reasons mentioned:
>
>Adds 90-100 bytes onto every response
>
>Have never seen a relying party app/plug-in send a request like this
>
>The "delegated" trust model in RFC 2560 would require different signing
>certs for trusting entity vs. CA cert ... add another 1kB onto the response
>
>Protocol only sends CA name+key info, which isn't enough to identify which
>CA cert the relying party is inspecting in the case of CA cert renewal,
>cross-certification, etc.
>
>
>From: Stefan Santesson [mailto:[email-masked]]
>Sent: Tuesday, November 14, 2006 12:11 PM
>To: Santosh Chokhani; Russ Housley; Price, Bill; [email-masked]
>Cc: Sam Hartman; Michael Myers; Dave Engberg
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>Santosh,
>
>I didn't say it was hard. I say that I doubt that there are many
>implementations supporting this scenario even those with a responder key.
>It would be interesting to hear from implementers if I'm right.
>
>Stefan Santesson
>Senior Program Manager
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: den 14 november 2006 03:59
> > To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> > Stefan,
> >
> > You are making more complex than it is.  The Responder can include all
> > the CA certificates that issued the certificate in question and AIA can
> > do the rest.
> >
> > Furthermore, since most PKI are two tier hierarchy, in Enterprise
> > environment, the CA certificate certification path is not an issue.
> >
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]]
> > On Behalf Of Stefan Santesson
> > Sent: Monday, November 13, 2006 6:54 PM
> > To: Russ Housley; Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I'm not sure the case described is a realistic one.
> >
> > Section 2.2
> >    All definitive response messages SHALL be digitally signed. The key
> >    used to sign the response MUST belong to one of the following:
> >
> >    -- the CA who issued the certificate in question
> >    -- a Trusted Responder whose public key is trusted by the requester
> >    -- a CA Designated Responder (Authorized Responder) who holds a
> >       specially marked certificate issued directly by the CA,
> > indicating
> >       that the responder may issue OCSP responses for that CA
> >
> > Since the request is on certificates issued by 2 different CA:s trust
> > option 1 is invalid.
> > Trust option 3 is valid in theory but in practice it requires that the
> > OCSP responder provide multiple validation paths in the response, one
> > for each issuing CA. Somehow I doubt that this is implemented by
> > anyone.
> >
> > Trust option 2 is not generic and is only valid as a result of a local
> > configuration.
> >
> > So I don't think this is a problem only for key-less responders.
> >
> >
> > Stefan Santesson
> > Senior Program Manager
> > > From: [email-masked] [mailto:owner-ietf-
> > > [email-masked]] On Behalf Of Russ Housley
> > > Sent: den 13 november 2006 14:08
> > > To: Price, Bill; [email-masked]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > > I prefer an error that tells the client to ask for the certificate
> > > one at a time.
> > >
> > > Russ
> > >
> > >
> > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > >
> > > >I'd suggest focusing on understanding where responses to the keyed
> > and
> > > >keyless responders inherently differ. I am aware of two general
> > cases:
> > > >
> > > >1) The request asks for the status of multiple certificates that
> > have
> > > >not been included in a single presigned response. Russ's example
> > fits
> > > >into this case. The keyed responder handles, but the keyless will
> > fail
> > > >for the general case. Some responders respond with the presigned
> > > >response that includes one of the certificates (usually the first)
> > in
> > > >the request. A common situation is to ask for the status of
> > > >certificates in a chain. Santosh points out some keyless responders
> > > >anticipate this and bundle responses accordingly.
> > > >
> > > >2) The request is "well-formed" but asks for the status of a
> > > >certificate for which the keyless responder has not prepared a
> > > >response.  This situation will occur if:
> > > >
> > > >     a) The request is for status of a certificate from a supported
> > CA
> > > >but with a serial number for which there is no pre-signed response.
> > > >Assuming presigned responses exist for all certificates that would
> > be
> > > >valid based on their validity intervals, this would occur if the
> > > >certificate had expired or was yet to be issued (I am aware the
> > > keyless
> > > >responders generally produce responses for certificates likely to be
> > > >issued before the next generation of presigned responses). The keyed
> > > >responder would give a signed "good" response. My understanding is
> > > that
> > > >the keyless responder under the draft lightweight OCSP responds with
> > > an
> > > >unsigned "unauthorized" error code.
> > > >
> > > >     b) The request is for the status of a certificate from an
> > > >unsupported (or non-existent) CA. The keyed responder would respond
> > > >with a signed "unknown" response while under the draft, the keyless
> > > >would again respond with the unsigned "unauthorized" error  code.
> > > >
> > > >Some might argue with some grounds that these differences are
> > unusual,
> > > >unlikely, and insignificant.
> > > >
> > > >I personally consider the behavior in 2 of responding with the
> > > >"unauthorized" error to be misleading. "Internal error" sounds more
> > > >appropriate if I were constrained to the current error codes.
> > > >"Malformed request" might be OK. However, the actual situation does
> > > not
> > > >match well with any of these errors as they are described in 2560.
> > > >
> > > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > > >identifying the unavoidable differences and/or adding 2 TBD error
> > > codes
> > > >for the above cases (assuming they are the only differences). The
> > > first
> > > >error can be worked around by breaking the request for status of
> > > >multiples into multiple requests for status of one cert.
> > > >
> > > >We've also seen some problems with client apps that can't handle
> > > >presigned responses that commonly contain the status of several
> > (e.g.,
> > > >15-25) certs. The apps inquired for the status of a single cert and
> > > >apparently expected a response for a single certificate. I'd suggest
> > > >that some "must" or "should" words address clients' ability to
> > handle
> > > >the situation of a response covering multiple certificates.
> > > >
> > > >
> > > >
> > > >Bill Price
> > > >
> > > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > > >Sent: Monday, November 13, 2006 11:46 AM
> > > >To: Michael Myers; Dave Engberg
> > > >Cc: [email-masked]; Sam Hartman
> > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > > >
> > > >
> > > >Mike:
> > > >
> > > >I think it is not that simple.  I think you need to say that support
> > > >for one certificate MUST be supported, and that support for more
> > than
> > > >one certificate is OPTIONAL.  Then, the error is am indication that
> > > >the requestor has selected an unimplemented OPTION.
> > > >
> > > >Russ
> > > >
> > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > >Responders unable to produce or acquire a definitive response MUST
> > > >return <a
> > > > >TBD error>.
> > > > >
> > > > >As to your other points Santosh, that is something I prefer the
> > > chairs
> > > > >consider.
> > > > >
> > > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > >
> > > > > > Mike,
> > > > > >
> > > > > > What is the error case?
> > > > > >
> > > > > > . . .
> >

Date: Tue, 14 Nov 2006 18:16:52 -0500
To: Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: Sam Hartman <[email-masked]>
Sender: [email-masked]

Stefan:

>There is no place where RFC 2560 requires the render to successfully 
>handle a composite request. It only specifies how it should be done.

It does not say one way or the other.  That is the problem.  It 
specifies the syntax, without telling the reader whether some or all 
of it is mandatory to implement.  This is the crux of Sam's discuss 
position.  Nothing in the text leads the reader to believe that 
responding to a multi-certificate query is OPTIONAL.

I find the use of "unauthorized" to indicate that a client cannot 
make a multi-certificate request unacceptable.  To me, that implies 
that some other client would be authorized to make such a request.

I also find the use of "internalError" to indicate that a client 
cannot make a multi-certificate request unacceptable.

Russ

Date: Tue, 14 Nov 2006 18:12:36 -0500
To: Stefan Santesson <[email-masked]>, "Price, Bill" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: Sam Hartman <[email-masked]>, Michael Myers <[email-masked]>, Dave Engberg <[email-masked]>
Sender: [email-masked]

It is not a problem for OCSP Responders that can relay the request to 
a server with a key.  That server can build the signed response for 
the arbitrary collection of certificates.

Russ

At 06:54 PM 11/13/2006, Stefan Santesson wrote:
>I'm not sure the case described is a realistic one.
>
>Section 2.2
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- a CA Designated Responder (Authorized Responder) who holds a
>       specially marked certificate issued directly by the CA, indicating
>       that the responder may issue OCSP responses for that CA
>
>Since the request is on certificates issued by 2 different CA:s 
>trust option 1 is invalid.
>Trust option 3 is valid in theory but in practice it requires that 
>the OCSP responder provide multiple validation paths in the 
>response, one for each issuing CA. Somehow I doubt that this is 
>implemented by anyone.
>
>Trust option 2 is not generic and is only valid as a result of a 
>local configuration.
>
>So I don't think this is a problem only for key-less responders.
>
>
>Stefan Santesson
>Senior Program Manager
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Russ Housley
> > Sent: den 13 november 2006 14:08
> > To: Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I prefer an error that tells the client to ask for the certificate
> > one at a time.
> >
> > Russ
> >
> >
> > At 02:46 PM 11/13/2006, Price, Bill wrote:
> >
> > >I'd suggest focusing on understanding where responses to the keyed and
> > >keyless responders inherently differ. I am aware of two general cases:
> > >
> > >1) The request asks for the status of multiple certificates that have
> > >not been included in a single presigned response. Russ's example fits
> > >into this case. The keyed responder handles, but the keyless will fail
> > >for the general case. Some responders respond with the presigned
> > >response that includes one of the certificates (usually the first) in
> > >the request. A common situation is to ask for the status of
> > >certificates in a chain. Santosh points out some keyless responders
> > >anticipate this and bundle responses accordingly.
> > >
> > >2) The request is "well-formed" but asks for the status of a
> > >certificate for which the keyless responder has not prepared a
> > >response.  This situation will occur if:
> > >
> > >     a) The request is for status of a certificate from a supported CA
> > >but with a serial number for which there is no pre-signed response.
> > >Assuming presigned responses exist for all certificates that would be
> > >valid based on their validity intervals, this would occur if the
> > >certificate had expired or was yet to be issued (I am aware the
> > keyless
> > >responders generally produce responses for certificates likely to be
> > >issued before the next generation of presigned responses). The keyed
> > >responder would give a signed "good" response. My understanding is
> > that
> > >the keyless responder under the draft lightweight OCSP responds with
> > an
> > >unsigned "unauthorized" error code.
> > >
> > >     b) The request is for the status of a certificate from an
> > >unsupported (or non-existent) CA. The keyed responder would respond
> > >with a signed "unknown" response while under the draft, the keyless
> > >would again respond with the unsigned "unauthorized" error  code.
> > >
> > >Some might argue with some grounds that these differences are unusual,
> > >unlikely, and insignificant.
> > >
> > >I personally consider the behavior in 2 of responding with the
> > >"unauthorized" error to be misleading. "Internal error" sounds more
> > >appropriate if I were constrained to the current error codes.
> > >"Malformed request" might be OK. However, the actual situation does
> > not
> > >match well with any of these errors as they are described in 2560.
> > >
> > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > >identifying the unavoidable differences and/or adding 2 TBD error
> > codes
> > >for the above cases (assuming they are the only differences). The
> > first
> > >error can be worked around by breaking the request for status of
> > >multiples into multiple requests for status of one cert.
> > >
> > >We've also seen some problems with client apps that can't handle
> > >presigned responses that commonly contain the status of several (e.g.,
> > >15-25) certs. The apps inquired for the status of a single cert and
> > >apparently expected a response for a single certificate. I'd suggest
> > >that some "must" or "should" words address clients' ability to handle
> > >the situation of a response covering multiple certificates.
> > >
> > >
> > >
> > >Bill Price
> > >
> > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > >Sent: Monday, November 13, 2006 11:46 AM
> > >To: Michael Myers; Dave Engberg
> > >Cc: [email-masked]; Sam Hartman
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >Mike:
> > >
> > >I think it is not that simple.  I think you need to say that support
> > >for one certificate MUST be supported, and that support for more than
> > >one certificate is OPTIONAL.  Then, the error is am indication that
> > >the requestor has selected an unimplemented OPTION.
> > >
> > >Russ
> > >
> > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > >Responders unable to produce or acquire a definitive response MUST
> > >return <a
> > > >TBD error>.
> > > >
> > > >As to your other points Santosh, that is something I prefer the
> > chairs
> > > >consider.
> > > >
> > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > >
> > > > > Mike,
> > > > >
> > > > > What is the error case?
> > > > >
> > > > > . . .

From: Stefan Santesson <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Michael Myers <[email-masked]>, Dave Engberg <[email-masked]>, Russ Housley <[email-masked]>, "Price, Bill" <[email-masked]>
Date: Tue, 14 Nov 2006 22:56:38 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Sam,

Could you point us to the applicable interoperability requirements IETF has established in general that would require such clarification of RFC 2560.

What is ironic in this situation is that this a cases where the industry has been able to achieve interoperability (to a fairly high degree at least), also with respect to keyless responders. I don't think we serve the industry by denying publication of an informational document describing how keyless responders has been implemented.

Creating an RFC 2560bis may take considerable time.

Stefan Santesson
Senior Program Manager

> From: Sam Hartman [mailto:[email-masked]]
> Sent: den 14 november 2006 14:23
> To: Stefan Santesson
> Cc: [email-masked]; Michael Myers; Dave Engberg; Russ Housley;
> Price, Bill
> Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> >>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:
>
>     Stefan> On issue number 1) it is my belief that the lightweight
>     Stefan> profile should be allowed to progress without updating RFC
>     Stefan> 2560. I have seen no requirements in RFC 2560 that
>     Stefan> requires a keyed responder, even if it is clear that a
>     Stefan> non-keyed responder can only respond to a subset of all
>     Stefan> valid requests. If the lightweight OCSP profile is allowed
>     Stefan> to progress, it MUST live within the current restrictions
>     Stefan> of OCSP with respect to error codes.
>
>
> Speaking as an holding a discuss, I cannot agree to allow the
> lightweight profile to progress without a standards-track
> clarification to 2560.
>
> Your reading of 2560 would not meet the interoperability requirements
> that the IETF has established that in general, all clients of a
> protocol be able to work with all servers of a protocol.  In order to
> meet that requirement RFC 2560 needs to be normatively changed in
> order to require that clients be able to send a request including only
> one certificate.
>
> Unless I see new arguments I have not seen so far, my discuss stands.

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 17:51:11 -0500
From: "Price, Bill" <[email-masked]>
To: "Carl Wallace" <[email-masked]>, "Dave Engberg" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>, "Michael Myers" <[email-masked]>
Sender: [email-masked]

I have seen this behavior also (I mentioned it in my first post on this
thread). Keyed responders responded correctly. The problem of partial
responses occurred with at least one keyless responder. Such responses
appear to be out of compliance with RFC 2560 since it is not the case
that "A definitive response message is composed of responses for each
of the certificates in a request." 

If a responder that is multi-request challenged is supposed to give an
error, neither the standard nor the profile explicitly identify the
appropriate error message. If the choice of error message is limited to
the existing ones in the RFC, the error will likely be as informative
and helpful as the profile's "unauthorized" response is for the case
when the keyless responders don't have an appropriate presigned
response. 

If the partial response is to be acceptable, it seems that at least one
of the RFC or profile should be modified to so state. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Carl Wallace
Sent: Tuesday, November 14, 2006 3:49 PM
To: Dave Engberg; Stefan Santesson; Santosh Chokhani; Russ Housley;
Price, Bill; [email-masked]
Cc: Sam Hartman; Michael Myers
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

I've worked with a toolkit that can send multi-cert requests and have
seen
problems in this area including responders that return a successful
response
for one cert included in a request without addressing the others.  

> [mailto:[email-masked]] On Behalf Of Dave Engberg
> Sent: Tuesday, November 14, 2006 12:45 PM
> To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, 
> Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> 
> 
> CoreStreet's OCSP server doesn't include a SingleResponse for 
> the issuing CA's cert in pre-signed responses.  Mostly for 
> the reasons mentioned:
> 
> Adds 90-100 bytes onto every response
> 
> Have never seen a relying party app/plug-in send a request like this
> 
> The "delegated" trust model in RFC 2560 would require 
> different signing certs for trusting entity vs. CA cert ... 
> add another 1kB onto the response
> 
> Protocol only sends CA name+key info, which isn't enough to 
> identify which CA cert the relying party is inspecting in the 
> case of CA cert renewal, cross-certification, etc.
> 
> 
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Tuesday, November 14, 2006 12:11 PM
> To: Santosh Chokhani; Russ Housley; Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> 
> Santosh,
> 
> I didn't say it was hard. I say that I doubt that there are 
> many implementations supporting this scenario even those with 
> a responder key.
> It would be interesting to hear from implementers if I'm right.
> 
> Stefan Santesson
> Senior Program Manager
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: den 14 november 2006 03:59
> > To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> > Stefan,
> >
> > You are making more complex than it is.  The Responder can 
> include all 
> > the CA certificates that issued the certificate in question and AIA

> > can do the rest.
> >
> > Furthermore, since most PKI are two tier hierarchy, in Enterprise 
> > environment, the CA certificate certification path is not an issue.
> >
> > From: [email-masked] [mailto:owner-ietf- 
> > [email-masked]] On Behalf Of Stefan Santesson
> > Sent: Monday, November 13, 2006 6:54 PM
> > To: Russ Housley; Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I'm not sure the case described is a realistic one.
> >
> > Section 2.2
> >    All definitive response messages SHALL be digitally 
> signed. The key
> >    used to sign the response MUST belong to one of the following:
> >
> >    -- the CA who issued the certificate in question
> >    -- a Trusted Responder whose public key is trusted by 
> the requester
> >    -- a CA Designated Responder (Authorized Responder) who holds a
> >       specially marked certificate issued directly by the CA, 
> > indicating
> >       that the responder may issue OCSP responses for that CA
> >
> > Since the request is on certificates issued by 2 different 
> CA:s trust 
> > option 1 is invalid.
> > Trust option 3 is valid in theory but in practice it 
> requires that the 
> > OCSP responder provide multiple validation paths in the 
> response, one 
> > for each issuing CA. Somehow I doubt that this is implemented by 
> > anyone.
> >
> > Trust option 2 is not generic and is only valid as a result 
> of a local 
> > configuration.
> >
> > So I don't think this is a problem only for key-less responders.
> >
> >
> > Stefan Santesson
> > Senior Program Manager
> > > From: [email-masked] [mailto:owner-ietf- 
> > > [email-masked]] On Behalf Of Russ Housley
> > > Sent: den 13 november 2006 14:08
> > > To: Price, Bill; [email-masked]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
2560
> > >
> > >
> > > I prefer an error that tells the client to ask for the 
> certificate 
> > > one at a time.
> > >
> > > Russ
> > >
> > >
> > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > >
> > > >I'd suggest focusing on understanding where responses to 
> the keyed
> > and
> > > >keyless responders inherently differ. I am aware of two general
> > cases:
> > > >
> > > >1) The request asks for the status of multiple certificates that
> > have
> > > >not been included in a single presigned response. Russ's example
> > fits
> > > >into this case. The keyed responder handles, but the keyless
will
> > fail
> > > >for the general case. Some responders respond with the presigned

> > > >response that includes one of the certificates (usually 
> the first)
> > in
> > > >the request. A common situation is to ask for the status of 
> > > >certificates in a chain. Santosh points out some keyless 
> responders 
> > > >anticipate this and bundle responses accordingly.
> > > >
> > > >2) The request is "well-formed" but asks for the status of a 
> > > >certificate for which the keyless responder has not prepared a 
> > > >response.  This situation will occur if:
> > > >
> > > >     a) The request is for status of a certificate from 
> a supported
> > CA
> > > >but with a serial number for which there is no 
> pre-signed response.
> > > >Assuming presigned responses exist for all certificates 
> that would
> > be
> > > >valid based on their validity intervals, this would occur if the

> > > >certificate had expired or was yet to be issued (I am aware the
> > > keyless
> > > >responders generally produce responses for certificates 
> likely to 
> > > >be issued before the next generation of presigned 
> responses). The 
> > > >keyed responder would give a signed "good" response. My 
> > > >understanding is
> > > that
> > > >the keyless responder under the draft lightweight OCSP responds 
> > > >with
> > > an
> > > >unsigned "unauthorized" error code.
> > > >
> > > >     b) The request is for the status of a certificate from an 
> > > >unsupported (or non-existent) CA. The keyed responder 
> would respond 
> > > >with a signed "unknown" response while under the draft, 
> the keyless 
> > > >would again respond with the unsigned "unauthorized" error
code.
> > > >
> > > >Some might argue with some grounds that these differences are
> > unusual,
> > > >unlikely, and insignificant.
> > > >
> > > >I personally consider the behavior in 2 of responding with the 
> > > >"unauthorized" error to be misleading. "Internal error" 
> sounds more 
> > > >appropriate if I were constrained to the current error codes.
> > > >"Malformed request" might be OK. However, the actual 
> situation does
> > > not
> > > >match well with any of these errors as they are 
> described in 2560.
> > > >
> > > >If 2560 is supposed to encompass keyless responders, I'd 
> recommend 
> > > >identifying the unavoidable differences and/or adding 2 TBD
error
> > > codes
> > > >for the above cases (assuming they are the only differences).
The
> > > first
> > > >error can be worked around by breaking the request for status of

> > > >multiples into multiple requests for status of one cert.
> > > >
> > > >We've also seen some problems with client apps that can't handle

> > > >presigned responses that commonly contain the status of several
> > (e.g.,
> > > >15-25) certs. The apps inquired for the status of a 
> single cert and 
> > > >apparently expected a response for a single certificate. I'd 
> > > >suggest that some "must" or "should" words address 
> clients' ability 
> > > >to
> > handle
> > > >the situation of a response covering multiple certificates.
> > > >
> > > >
> > > >
> > > >Bill Price
> > > >
> > > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > > >Sent: Monday, November 13, 2006 11:46 AM
> > > >To: Michael Myers; Dave Engberg
> > > >Cc: [email-masked]; Sam Hartman
> > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile 
> and RFC 2560
> > > >
> > > >
> > > >Mike:
> > > >
> > > >I think it is not that simple.  I think you need to say that 
> > > >support for one certificate MUST be supported, and that 
> support for 
> > > >more
> > than
> > > >one certificate is OPTIONAL.  Then, the error is am 
> indication that 
> > > >the requestor has selected an unimplemented OPTION.
> > > >
> > > >Russ
> > > >
> > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > >Responders unable to produce or acquire a definitive response 
> > > > >MUST
> > > >return <a
> > > > >TBD error>.
> > > > >
> > > > >As to your other points Santosh, that is something I prefer
the
> > > chairs
> > > > >consider.
> > > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > >
> > > > > > Mike,
> > > > > >
> > > > > > What is the error case?
> > > > > >
> > > > > > . . .
> >
> 
> 

Date: Tue, 14 Nov 2006 15:32:31 -0500
To: "Ogle Ron" <[email-masked]>, "Stephen Kent" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: PEM file format rfc draft request
Cc: <[email-masked]>, "Dieter Bratko" <[email-masked]>
Sender: [email-masked]

I think there is value in publishing the format of "PEM" files.  I do 
not think it needs to be done in the PKIX WG, or any WG for that 
matter.  I would be willing to shepherd an Informational RFC through 
the approval process, which would include a 4-week IETF Last Call.

Russ

At 08:18 PM 11/13/2006, Ogle Ron wrote:

>I agree that the original PEM meaning is as you state.  I have no idea
>as to how it got skewed with these new meanings for public/private keys
>and certificates.  However, it does now exist.
>
>As for the relevance with PKIX, the "PEM" format also describes the base
>64 encoding with MIME headers for x509 certificates.  Also, many S/MIME,
>SSL, IPsec, and other cryptographic standards that use x509 also
>recognize PEM formatted certificates/key pairs.  This is how I
>discovered the problem in the first place.
>
>If not PKIX, then where?
>
>Thanks
>Ron Ogle
>
>From: Stephen Kent [mailto:[email-masked]]
>Sent: Monday, November 13, 2006 6:45 PM
>To: Ogle Ron
>Cc: [email-masked]; Dieter Bratko
>Subject: Re: PEM file format rfc draft request
>
>At 4:56 PM -0500 11/13/06, Ogle Ron wrote:
> >I would like to know if the PKIX working group would be interested in
> >shepherding a new rfc concerning PEM file formats?  I've recently
> >discovered that there is no definitive standard for how a PEM's headers
> >and footers are defined for a private key.  I've searched the RFCs, and
> >ISO standards without any luck.
>
>PEM formats were defined for e-mail messages, not files per se. I
>think RFC 1421 defines the last of the formats (we had a few
>iterations) for PEM.
>
> >The issue that I discovered was when I was working with PEM files for
> >PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
> >toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
> >to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
> >PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.
>For
> >PKCS1, both expect "BEGIN RSA PRIVATE KEY".
>
>
>it looks like folks made this up!  PEM describes how to transfer a
>symmetric key encrypted under a public (RSA) key in a message, in
>1421.  It does not describe how to transfer a private key, because
>one would not do that via an e-mail message.
>
>The term "PEM file" with regard to PKCS #8 is a misnomer, relative to
>IETF standards. Since PKCS #8 defines a format for private keys, it
>is not relevant to PEM, period.
>
>Given that PKIX is a WG that focuses on X.509-based standards, it is
>not immediately clear that a document on how to use base-64 encoding
>and MIME-style headers to represent private keys is within our scope.
>
>Steve

From: Sam Hartman <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Michael Myers <[email-masked]>, Dave Engberg <[email-masked]>, Russ Housley <[email-masked]>, "Price, Bill" <[email-masked]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 17:22:51 -0500
Sender: [email-masked]

>>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:

    Stefan> On issue number 1) it is my belief that the lightweight
    Stefan> profile should be allowed to progress without updating RFC
    Stefan> 2560. I have seen no requirements in RFC 2560 that
    Stefan> requires a keyed responder, even if it is clear that a
    Stefan> non-keyed responder can only respond to a subset of all
    Stefan> valid requests. If the lightweight OCSP profile is allowed
    Stefan> to progress, it MUST live within the current restrictions
    Stefan> of OCSP with respect to error codes.

Speaking as an holding a discuss, I cannot agree to allow the
lightweight profile to progress without a standards-track
clarification to 2560.

Your reading of 2560 would not meet the interoperability requirements
that the IETF has established that in general, all clients of a
protocol be able to work with all servers of a protocol.  In order to
meet that requirement RFC 2560 needs to be normatively changed in
order to require that clients be able to send a request including only
one certificate.

Unless I see new arguments I have not seen so far, my discuss stands.

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Sam Hartman <[email-masked]>, Michael Myers <[email-masked]>, Dave Engberg <[email-masked]>, Russ Housley <[email-masked]>, "Price, Bill" <[email-masked]>
Date: Tue, 14 Nov 2006 21:11:50 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Taking on the moderator hat I would like to structure this discussion before it takes off in too many directions.

1) The primary issue at hand is if the current Lightweight profile can progress to informational without first updating rfc2560.

2) Secondary is a growing discussion if RFC 2560 needs to be updated for other reasons than accommodating the lightweight profile.

On issue number 1) it is my belief that the lightweight profile should be allowed to progress without updating RFC 2560. I have seen no requirements in RFC 2560 that requires a keyed responder, even if it is clear that a non-keyed responder can only respond to a subset of all valid requests. If the lightweight OCSP profile is allowed to progress, it MUST live within the current restrictions of OCSP with respect to error codes.

On issue number 2) I welcome a debate on a separate thread.

Stefan Santesson
Senior Program Manager

From: Carl Wallace <[email-masked]>
To: Dave Engberg <[email-masked]>, Stefan Santesson <[email-masked]>, Santosh Chokhani <[email-masked]>, Russ Housley <[email-masked]>, "Price, Bill" <[email-masked]>, [email-masked]
Cc: Sam Hartman <[email-masked]>, Michael Myers <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 15:48:46 -0500
Sender: [email-masked]

This is a multi-part message in MIME format.

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

I've worked with a toolkit that can send multi-cert requests and have seen
problems in this area including responders that return a successful response
for one cert included in a request without addressing the others.  

> [mailto:[email-masked]] On Behalf Of Dave Engberg
> Sent: Tuesday, November 14, 2006 12:45 PM
> To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, 
> Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> 
> 
> CoreStreet's OCSP server doesn't include a SingleResponse for 
> the issuing CA's cert in pre-signed responses.  Mostly for 
> the reasons mentioned:
> 
> Adds 90-100 bytes onto every response
> 
> Have never seen a relying party app/plug-in send a request like this
> 
> The "delegated" trust model in RFC 2560 would require 
> different signing certs for trusting entity vs. CA cert ... 
> add another 1kB onto the response
> 
> Protocol only sends CA name+key info, which isn't enough to 
> identify which CA cert the relying party is inspecting in the 
> case of CA cert renewal, cross-certification, etc.
> 
> 
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Tuesday, November 14, 2006 12:11 PM
> To: Santosh Chokhani; Russ Housley; Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> 
> Santosh,
> 
> I didn't say it was hard. I say that I doubt that there are 
> many implementations supporting this scenario even those with 
> a responder key.
> It would be interesting to hear from implementers if I'm right.
> 
> Stefan Santesson
> Senior Program Manager
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: den 14 november 2006 03:59
> > To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> > Stefan,
> >
> > You are making more complex than it is.  The Responder can 
> include all 
> > the CA certificates that issued the certificate in question and AIA 
> > can do the rest.
> >
> > Furthermore, since most PKI are two tier hierarchy, in Enterprise 
> > environment, the CA certificate certification path is not an issue.
> >
> > From: [email-masked] [mailto:owner-ietf- 
> > [email-masked]] On Behalf Of Stefan Santesson
> > Sent: Monday, November 13, 2006 6:54 PM
> > To: Russ Housley; Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I'm not sure the case described is a realistic one.
> >
> > Section 2.2
> >    All definitive response messages SHALL be digitally 
> signed. The key
> >    used to sign the response MUST belong to one of the following:
> >
> >    -- the CA who issued the certificate in question
> >    -- a Trusted Responder whose public key is trusted by 
> the requester
> >    -- a CA Designated Responder (Authorized Responder) who holds a
> >       specially marked certificate issued directly by the CA, 
> > indicating
> >       that the responder may issue OCSP responses for that CA
> >
> > Since the request is on certificates issued by 2 different 
> CA:s trust 
> > option 1 is invalid.
> > Trust option 3 is valid in theory but in practice it 
> requires that the 
> > OCSP responder provide multiple validation paths in the 
> response, one 
> > for each issuing CA. Somehow I doubt that this is implemented by 
> > anyone.
> >
> > Trust option 2 is not generic and is only valid as a result 
> of a local 
> > configuration.
> >
> > So I don't think this is a problem only for key-less responders.
> >
> >
> > Stefan Santesson
> > Senior Program Manager
> > > From: [email-masked] [mailto:owner-ietf- 
> > > [email-masked]] On Behalf Of Russ Housley
> > > Sent: den 13 november 2006 14:08
> > > To: Price, Bill; [email-masked]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > > I prefer an error that tells the client to ask for the 
> certificate 
> > > one at a time.
> > >
> > > Russ
> > >
> > >
> > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > >
> > > >I'd suggest focusing on understanding where responses to 
> the keyed
> > and
> > > >keyless responders inherently differ. I am aware of two general
> > cases:
> > > >
> > > >1) The request asks for the status of multiple certificates that
> > have
> > > >not been included in a single presigned response. Russ's example
> > fits
> > > >into this case. The keyed responder handles, but the keyless will
> > fail
> > > >for the general case. Some responders respond with the presigned 
> > > >response that includes one of the certificates (usually 
> the first)
> > in
> > > >the request. A common situation is to ask for the status of 
> > > >certificates in a chain. Santosh points out some keyless 
> responders 
> > > >anticipate this and bundle responses accordingly.
> > > >
> > > >2) The request is "well-formed" but asks for the status of a 
> > > >certificate for which the keyless responder has not prepared a 
> > > >response.  This situation will occur if:
> > > >
> > > >     a) The request is for status of a certificate from 
> a supported
> > CA
> > > >but with a serial number for which there is no 
> pre-signed response.
> > > >Assuming presigned responses exist for all certificates 
> that would
> > be
> > > >valid based on their validity intervals, this would occur if the 
> > > >certificate had expired or was yet to be issued (I am aware the
> > > keyless
> > > >responders generally produce responses for certificates 
> likely to 
> > > >be issued before the next generation of presigned 
> responses). The 
> > > >keyed responder would give a signed "good" response. My 
> > > >understanding is
> > > that
> > > >the keyless responder under the draft lightweight OCSP responds 
> > > >with
> > > an
> > > >unsigned "unauthorized" error code.
> > > >
> > > >     b) The request is for the status of a certificate from an 
> > > >unsupported (or non-existent) CA. The keyed responder 
> would respond 
> > > >with a signed "unknown" response while under the draft, 
> the keyless 
> > > >would again respond with the unsigned "unauthorized" error  code.
> > > >
> > > >Some might argue with some grounds that these differences are
> > unusual,
> > > >unlikely, and insignificant.
> > > >
> > > >I personally consider the behavior in 2 of responding with the 
> > > >"unauthorized" error to be misleading. "Internal error" 
> sounds more 
> > > >appropriate if I were constrained to the current error codes.
> > > >"Malformed request" might be OK. However, the actual 
> situation does
> > > not
> > > >match well with any of these errors as they are 
> described in 2560.
> > > >
> > > >If 2560 is supposed to encompass keyless responders, I'd 
> recommend 
> > > >identifying the unavoidable differences and/or adding 2 TBD error
> > > codes
> > > >for the above cases (assuming they are the only differences). The
> > > first
> > > >error can be worked around by breaking the request for status of 
> > > >multiples into multiple requests for status of one cert.
> > > >
> > > >We've also seen some problems with client apps that can't handle 
> > > >presigned responses that commonly contain the status of several
> > (e.g.,
> > > >15-25) certs. The apps inquired for the status of a 
> single cert and 
> > > >apparently expected a response for a single certificate. I'd 
> > > >suggest that some "must" or "should" words address 
> clients' ability 
> > > >to
> > handle
> > > >the situation of a response covering multiple certificates.
> > > >
> > > >
> > > >
> > > >Bill Price
> > > >
> > > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > > >Sent: Monday, November 13, 2006 11:46 AM
> > > >To: Michael Myers; Dave Engberg
> > > >Cc: [email-masked]; Sam Hartman
> > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile 
> and RFC 2560
> > > >
> > > >
> > > >Mike:
> > > >
> > > >I think it is not that simple.  I think you need to say that 
> > > >support for one certificate MUST be supported, and that 
> support for 
> > > >more
> > than
> > > >one certificate is OPTIONAL.  Then, the error is am 
> indication that 
> > > >the requestor has selected an unimplemented OPTION.
> > > >
> > > >Russ
> > > >
> > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > >Responders unable to produce or acquire a definitive response 
> > > > >MUST
> > > >return <a
> > > > >TBD error>.
> > > > >
> > > > >As to your other points Santosh, that is something I prefer the
> > > chairs
> > > > >consider.
> > > > >
> > > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > >
> > > > > > Mike,
> > > > > >
> > > > > > What is the error case?
> > > > > >
> > > > > > . . .
> >
> 
> 

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

------=_NextPart_000_004B_01C70804.5E976520--

Date: Tue, 14 Nov 2006 14:42:50 -0500
From: "David A. Cooper" <[email-masked]>
To: Ogle Ron <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: PEM file format rfc draft request
Sender: [email-masked]

Ogle Ron wrote:
> Now with people using the AIA extension and extending the CDP extension
> to include URIs, I see more and more use of the PEM formatted CRLs and
> certificates.
Why is there need to base64 encode everything?  It made sense in PEM due 
to the limitations of email, but what is the benefit of base64 encoding 
in other situations?

As for the scenarios mentioned above, 3280bis specifically states that 
the data pointed to by an HTTP or FTP URI must in the AIA, SIA, or CDP 
extension must be BER or DER encoded (DER for certificates and CRLs; BER 
or DER for "certs-only" CMS messages).  Is there a reason that people 
are pointing to PEM formatted certificates and CRLs rather than just the 
certificates and CRLs without the base64 encoding?

Dave

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 11:07:51 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "Dave Engberg" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "Russ Housley" <[email-masked]>, "Price, Bill" <[email-masked]>, <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>, "Michael Myers" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_008A_01C707F6.457D0940
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In hurry, I did not clearly articulate my thoughts.  What I am saying also
relates to another comment to Mike Myers regarding the security of the
delegated model which is incompletely addressed by 2560.

I will be verbose this time.

The implementations such as Corestreet and Tumbleweed tend to adhere to the
approach that the same key that signed the certificate in question, sign the
OCSP Responder certificate.

Thus, if you have a hierarchy like Root --> CA --> Subscriber and you want
the status of CA certificate and the Subscriber certificate, you get them as
responses and with them you only need the two OCSP Responder certificates
one signed by the Root (for verifying CA certificate revocation status) and
one signed by the CA (for verifying the subscriber certificate revocation
status).

You do not need any paths.

Please note that the approach also works when the Responder is queried by a
CA cross certified by the root, since rest of the path has been built by the
client. 

-----Original Message-----
From: Dave Engberg [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 12:45 PM
To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
[email-masked]
Cc: Sam Hartman; Michael Myers
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

CoreStreet's OCSP server doesn't include a SingleResponse for the issuing
CA's cert in pre-signed responses.  Mostly for the reasons mentioned:

Adds 90-100 bytes onto every response

Have never seen a relying party app/plug-in send a request like this

The "delegated" trust model in RFC 2560 would require different signing
certs for trusting entity vs. CA cert ... add another 1kB onto the response

Protocol only sends CA name+key info, which isn't enough to identify which
CA cert the relying party is inspecting in the case of CA cert renewal,
cross-certification, etc.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 12:11 PM
To: Santosh Chokhani; Russ Housley; Price, Bill; [email-masked]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh,

I didn't say it was hard. I say that I doubt that there are many
implementations supporting this scenario even those with a responder key.
It would be interesting to hear from implementers if I'm right.

Stefan Santesson
Senior Program Manager

> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: den 14 november 2006 03:59
> To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> Stefan,
>
> You are making more complex than it is.  The Responder can include all
> the CA certificates that issued the certificate in question and AIA can
> do the rest.
>
> Furthermore, since most PKI are two tier hierarchy, in Enterprise
> environment, the CA certificate certification path is not an issue.
>
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]]
> On Behalf Of Stefan Santesson
> Sent: Monday, November 13, 2006 6:54 PM
> To: Russ Housley; Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I'm not sure the case described is a realistic one.
>
> Section 2.2
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- a CA Designated Responder (Authorized Responder) who holds a
>       specially marked certificate issued directly by the CA,
> indicating
>       that the responder may issue OCSP responses for that CA
>
> Since the request is on certificates issued by 2 different CA:s trust
> option 1 is invalid.
> Trust option 3 is valid in theory but in practice it requires that the
> OCSP responder provide multiple validation paths in the response, one
> for each issuing CA. Somehow I doubt that this is implemented by
> anyone.
>
> Trust option 2 is not generic and is only valid as a result of a local
> configuration.
>
> So I don't think this is a problem only for key-less responders.
>
>
> Stefan Santesson
> Senior Program Manager
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Russ Housley
> > Sent: den 13 november 2006 14:08
> > To: Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I prefer an error that tells the client to ask for the certificate
> > one at a time.
> >
> > Russ
> >
> >
> > At 02:46 PM 11/13/2006, Price, Bill wrote:
> >
> > >I'd suggest focusing on understanding where responses to the keyed
> and
> > >keyless responders inherently differ. I am aware of two general
> cases:
> > >
> > >1) The request asks for the status of multiple certificates that
> have
> > >not been included in a single presigned response. Russ's example
> fits
> > >into this case. The keyed responder handles, but the keyless will
> fail
> > >for the general case. Some responders respond with the presigned
> > >response that includes one of the certificates (usually the first)
> in
> > >the request. A common situation is to ask for the status of
> > >certificates in a chain. Santosh points out some keyless responders
> > >anticipate this and bundle responses accordingly.
> > >
> > >2) The request is "well-formed" but asks for the status of a
> > >certificate for which the keyless responder has not prepared a
> > >response.  This situation will occur if:
> > >
> > >     a) The request is for status of a certificate from a supported
> CA
> > >but with a serial number for which there is no pre-signed response.
> > >Assuming presigned responses exist for all certificates that would
> be
> > >valid based on their validity intervals, this would occur if the
> > >certificate had expired or was yet to be issued (I am aware the
> > keyless
> > >responders generally produce responses for certificates likely to be
> > >issued before the next generation of presigned responses). The keyed
> > >responder would give a signed "good" response. My understanding is
> > that
> > >the keyless responder under the draft lightweight OCSP responds with
> > an
> > >unsigned "unauthorized" error code.
> > >
> > >     b) The request is for the status of a certificate from an
> > >unsupported (or non-existent) CA. The keyed responder would respond
> > >with a signed "unknown" response while under the draft, the keyless
> > >would again respond with the unsigned "unauthorized" error  code.
> > >
> > >Some might argue with some grounds that these differences are
> unusual,
> > >unlikely, and insignificant.
> > >
> > >I personally consider the behavior in 2 of responding with the
> > >"unauthorized" error to be misleading. "Internal error" sounds more
> > >appropriate if I were constrained to the current error codes.
> > >"Malformed request" might be OK. However, the actual situation does
> > not
> > >match well with any of these errors as they are described in 2560.
> > >
> > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > >identifying the unavoidable differences and/or adding 2 TBD error
> > codes
> > >for the above cases (assuming they are the only differences). The
> > first
> > >error can be worked around by breaking the request for status of
> > >multiples into multiple requests for status of one cert.
> > >
> > >We've also seen some problems with client apps that can't handle
> > >presigned responses that commonly contain the status of several
> (e.g.,
> > >15-25) certs. The apps inquired for the status of a single cert and
> > >apparently expected a response for a single certificate. I'd suggest
> > >that some "must" or "should" words address clients' ability to
> handle
> > >the situation of a response covering multiple certificates.
> > >
> > >
> > >
> > >Bill Price
> > >
> > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > >Sent: Monday, November 13, 2006 11:46 AM
> > >To: Michael Myers; Dave Engberg
> > >Cc: [email-masked]; Sam Hartman
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >Mike:
> > >
> > >I think it is not that simple.  I think you need to say that support
> > >for one certificate MUST be supported, and that support for more
> than
> > >one certificate is OPTIONAL.  Then, the error is am indication that
> > >the requestor has selected an unimplemented OPTION.
> > >
> > >Russ
> > >
> > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > >Responders unable to produce or acquire a definitive response MUST
> > >return <a
> > > >TBD error>.
> > > >
> > > >As to your other points Santosh, that is something I prefer the
> > chairs
> > > >consider.
> > > >
> > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > >
> > > > > Mike,
> > > > >
> > > > > What is the error case?
> > > > >
> > > > > . . .
>

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

------=_NextPart_000_008A_01C707F6.457D0940--

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 13:56:07 -0500
From: "Price, Bill" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>, "Sam Hartman" <[email-masked]>, "Michael Myers" <[email-masked]>, "Dave Engberg" <[email-masked]>, "Russ Housley" <[email-masked]>
Sender: [email-masked]

Fine perhaps from the viewpoint of a standards lawyer but I wouldn't
want to defend fine to client developers, integrators, support staff,
and users. I don't know that they would think it is "fine" that:

1) a "successful" answer only has a partial answer when the responder
actually knew the status of all of the certs in a "multiple" request.
(See note below).

2) an "unauthorized error" has nothing to do with access controls and
authorizations at the responder. The error resulted because the
responder was not internally capable of producing a "successful" answer
to a "well-formed" request. Another (e.g., keyed) responder could
produce a successful response. The real problem was that the request
was probably ill-conceived because it involved non-existent or unknown
CA or an expired or unissued cert.

Although the situations for the "unauthorized error" are the result of
requests that should not normally occur, I have some first hand
experience that they can occur because of bugs in software or
misconfigurations. A fair amount of time was wasted with help-desk and
support people investigating why access to the server was
"unauthorized" before encountering someone who knew that the
"unauthorized error" was the response given when the keyless responder
didn't have an appropriate presigned response.

Note:  1) above assumes that the response contains status for some but
not all certs in a multiple request. This is the way some keyless
responders behave. Your response and the standard seem to indicate that
an error should result since the response does not contain "responses
for each of the certificates in a request". An error might be more
appropriate than a "successful" partial answer. 

Bottom line: From a client developer, integrator, support staff, and
user viewpoint, 2560 compliant behavior due to differences between
keyed and keyless responders may be unclear and misleading in some "out
of the mainstream" cases. However, these cases may occur in the real
world because client developers, integrators, support staff, and users
may not know and/or may not be able to control (e.g., because of load
balancing) the type of responder that receives their requests. Addition
of a few words and error codes might change the situation for the
better. 

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Monday, November 13, 2006 7:30 PM
To: Russ Housley; Price, Bill; [email-masked]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

I've been taking a close look at this and I've come to the conclusion
that we are fine. That is, I can't find any support for that provision
of pre-produced responses handed out by a key-less responder is
violating RFC 2560 in any way.

RFC 2560 does not require the responder to return a successful response
for all possible legitimate requests. It only require the responder to
support the basic response format when it chooses to return a response.
As I read RFC 2560, it may fail responding to a request for any reason
as long as it returns a legitimate error.

There is no place where RFC 2560 requires the render to successfully
handle a composite request. It only specifies how it should be done.

On the contrary, support for pre-produced responses is explicitly
supported in 2.5. And as such it is obvious that such responder can't
respond to all possible requests.

Of the error codes listed, I find that "unauthorized" is the most
appropriate one for unsupported requests as it indicates that "the
client is not authorized to make this query to this server". The
description may not be 100% perfect but it is sufficiently good and the
response is definitive and avoids repetition.

The response "internalError" would be misleading as it "indicates that
the OCSP responder reached an inconsistent internal state. The query
should be retried, potentially with another responder", which may cause
the requester to keep retrying the request.

My conclusion is that no update to RFC 2560 is needed to progress the
informational profile for lightweight OCSP.

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 13 november 2006 14:08
> To: Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I prefer an error that tells the client to ask for the certificate
> one at a time.
>
> Russ
>
>
> At 02:46 PM 11/13/2006, Price, Bill wrote:
>
> >I'd suggest focusing on understanding where responses to the keyed
and
> >keyless responders inherently differ. I am aware of two general
cases:
> >
> >1) The request asks for the status of multiple certificates that
have
> >not been included in a single presigned response. Russ's example
fits
> >into this case. The keyed responder handles, but the keyless will
fail
> >for the general case. Some responders respond with the presigned
> >response that includes one of the certificates (usually the first)
in
> >the request. A common situation is to ask for the status of
> >certificates in a chain. Santosh points out some keyless responders
> >anticipate this and bundle responses accordingly.
> >
> >2) The request is "well-formed" but asks for the status of a
> >certificate for which the keyless responder has not prepared a
> >response.  This situation will occur if:
> >
> >     a) The request is for status of a certificate from a supported
CA
> >but with a serial number for which there is no pre-signed response.
> >Assuming presigned responses exist for all certificates that would
be
> >valid based on their validity intervals, this would occur if the
> >certificate had expired or was yet to be issued (I am aware the
> keyless
> >responders generally produce responses for certificates likely to be
> >issued before the next generation of presigned responses). The keyed
> >responder would give a signed "good" response. My understanding is
> that
> >the keyless responder under the draft lightweight OCSP responds with
> an
> >unsigned "unauthorized" error code.
> >
> >     b) The request is for the status of a certificate from an
> >unsupported (or non-existent) CA. The keyed responder would respond
> >with a signed "unknown" response while under the draft, the keyless
> >would again respond with the unsigned "unauthorized" error  code.
> >
> >Some might argue with some grounds that these differences are
unusual,
> >unlikely, and insignificant.
> >
> >I personally consider the behavior in 2 of responding with the
> >"unauthorized" error to be misleading. "Internal error" sounds more
> >appropriate if I were constrained to the current error codes.
> >"Malformed request" might be OK. However, the actual situation does
> not
> >match well with any of these errors as they are described in 2560.
> >
> >If 2560 is supposed to encompass keyless responders, I'd recommend
> >identifying the unavoidable differences and/or adding 2 TBD error
> codes
> >for the above cases (assuming they are the only differences). The
> first
> >error can be worked around by breaking the request for status of
> >multiples into multiple requests for status of one cert.
> >
> >We've also seen some problems with client apps that can't handle
> >presigned responses that commonly contain the status of several
(e.g.,
> >15-25) certs. The apps inquired for the status of a single cert and
> >apparently expected a response for a single certificate. I'd suggest
> >that some "must" or "should" words address clients' ability to
handle
> >the situation of a response covering multiple certificates.
> >
> >
> >
> >Bill Price
> >
> >[mailto:[email-masked]] On Behalf Of Russ Housley
> >Sent: Monday, November 13, 2006 11:46 AM
> >To: Michael Myers; Dave Engberg
> >Cc: [email-masked]; Sam Hartman
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >Mike:
> >
> >I think it is not that simple.  I think you need to say that support
> >for one certificate MUST be supported, and that support for more
than
> >one certificate is OPTIONAL.  Then, the error is am indication that
> >the requestor has selected an unimplemented OPTION.
> >
> >Russ
> >
> >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > >Responders unable to produce or acquire a definitive response MUST
> >return <a
> > >TBD error>.
> > >
> > >As to your other points Santosh, that is something I prefer the
> chairs
> > >consider.
> > >
> > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > >
> > > > Mike,
> > > >
> > > > What is the error case?
> > > >
> > > > . . .

Date: Tue, 14 Nov 2006 13:21:11 -0500
To: "Ogle Ron" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: PEM file format rfc draft request
Cc: <[email-masked]>, "Dieter Bratko" <[email-masked]>
Sender: [email-masked]

At 8:18 PM -0500 11/13/06, Ogle Ron wrote:
>I agree that the original PEM meaning is as you state.  I have no idea
>as to how it got skewed with these new meanings for public/private keys
>and certificates.  However, it does now exist.

No debate about its existence, just whether it is an appropriate 
topic for this WG.

>As for the relevance with PKIX, the "PEM" format also describes the base
>64 encoding with MIME headers for x509 certificates.  Also, many S/MIME,
>SSL, IPsec, and other cryptographic standards that use x509 also
>recognize PEM formatted certificates/key pairs.  This is how I
>discovered the problem in the first place.

The base64 encoding we developed for PEM, while I chaired the PSRG, 
has been adopted in a wide range of contexts, in large part because 
it became a standard MIME encoding. Most of the examples you cite 
above are instances where a WG developing a security protocol 
standard has chosen to define multiple encodings for transmission of 
public keys and/or certs, etc.  I don't think these WGs generally 
have defined private key encodings, because private keys are not 
transferred over the net and thus are not critical for 
interoperability. The WG in which this might have been relevant was 
SACRED, but I believe they choose to deal with private key transfer 
using XML (with base64 as the underlying mechanism) encoding.

>If not PKIX, then where?

An individual draft can be submitted on the topic.

Steve

Content-class: urn:content-classes:message
Subject: RE: PEM file format rfc draft request
Date: Tue, 14 Nov 2006 13:11:23 -0500
From: "Ogle Ron" <[email-masked]>
To: "pgut001" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Well, it did surprise me why there wasn't a standard since there were so
many implementations.  I think one of the reasons why there hasn't been
much call for it in the past is that one stayed within a single
PKI/crypto system implementation.  This issue came up for me because I'm
trying to interoperate between crypto systems (OpenSSL and Entrust).  In
this case Entrust uses the IAIK implementation.

Now with people using the AIA extension and extending the CDP extension
to include URIs, I see more and more use of the PEM formatted CRLs and
certificates.  I also see people building PKI applications out of
toolkits (like myself) who are expecting the keys and certificates to be
in the same format regardless of which crypto system created them.

Granted maybe the best advice a RFC can give is to use the proper regex,
but shouldn't it exist?  Isn't PKIX about interoperability?  I guess
that I could make the RFC informational, but I thought that it should be
given a bit more due care by interested parties.

Would the PKIX group still be interested in reviewing the informational
RFC?

Ron Ogle 

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 11:25 AM
To: [email-masked]; Ogle Ron
Cc: [email-masked]
Subject: Re: PEM file format rfc draft request

"Ogle Ron" <[email-masked]> writes:

>The issue that I discovered was when I was working with PEM files for
PKCS1
>and PKCS8 formatted private keys under OpenSSL and some Java toolkits
using
>an IAIK implementation.  OpenSSL expects PKCS8 PEM files to have "BEGIN
>PRIVATE KEY" as the header while IAIK uses "BEGIN RSA PRIVATE KEY" for
RSA
>keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For PKCS1, both expect
"BEGIN
>RSA PRIVATE KEY".

Uhh, given that it's probably about 10-15 years too late to try and fix
this,
is it worth even doing this?  Most implementations get around it by
reading
the lowest common denominator of all the formats they know of (for
example my
code looks for '----' + 'BEGIN' + 'PRIVATE', which seems to handle all
possibilities).  Even if you could decide on one particular
interpretation I
can't imagine anyone's going to change code that's been in the field for
10+
years.  I think the best you could do is create an kind of FYI RFC that
documents all of the possible formats (I started this in my X.509 style
guide
some years ago), or maybe document a regexp that'll recognise all
possible
formats.

Peter.

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 12:44:51 -0500
From: "Dave Engberg" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "Russ Housley" <[email-masked]>, "Price, Bill" <[email-masked]>, <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>, "Michael Myers" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

CoreStreet's OCSP server doesn't include a SingleResponse for the issuing
CA's cert in pre-signed responses.  Mostly for the reasons mentioned:

Adds 90-100 bytes onto every response

Have never seen a relying party app/plug-in send a request like this

The "delegated" trust model in RFC 2560 would require different signing
certs for trusting entity vs. CA cert ... add another 1kB onto the response

Protocol only sends CA name+key info, which isn't enough to identify which
CA cert the relying party is inspecting in the case of CA cert renewal,
cross-certification, etc.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 12:11 PM
To: Santosh Chokhani; Russ Housley; Price, Bill; [email-masked]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh,

I didn't say it was hard. I say that I doubt that there are many
implementations supporting this scenario even those with a responder key.
It would be interesting to hear from implementers if I'm right.

Stefan Santesson
Senior Program Manager

> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: den 14 november 2006 03:59
> To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> Stefan,
>
> You are making more complex than it is.  The Responder can include all
> the CA certificates that issued the certificate in question and AIA can
> do the rest.
>
> Furthermore, since most PKI are two tier hierarchy, in Enterprise
> environment, the CA certificate certification path is not an issue.
>
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]]
> On Behalf Of Stefan Santesson
> Sent: Monday, November 13, 2006 6:54 PM
> To: Russ Housley; Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I'm not sure the case described is a realistic one.
>
> Section 2.2
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- a CA Designated Responder (Authorized Responder) who holds a
>       specially marked certificate issued directly by the CA,
> indicating
>       that the responder may issue OCSP responses for that CA
>
> Since the request is on certificates issued by 2 different CA:s trust
> option 1 is invalid.
> Trust option 3 is valid in theory but in practice it requires that the
> OCSP responder provide multiple validation paths in the response, one
> for each issuing CA. Somehow I doubt that this is implemented by
> anyone.
>
> Trust option 2 is not generic and is only valid as a result of a local
> configuration.
>
> So I don't think this is a problem only for key-less responders.
>
>
> Stefan Santesson
> Senior Program Manager
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Russ Housley
> > Sent: den 13 november 2006 14:08
> > To: Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I prefer an error that tells the client to ask for the certificate
> > one at a time.
> >
> > Russ
> >
> >
> > At 02:46 PM 11/13/2006, Price, Bill wrote:
> >
> > >I'd suggest focusing on understanding where responses to the keyed
> and
> > >keyless responders inherently differ. I am aware of two general
> cases:
> > >
> > >1) The request asks for the status of multiple certificates that
> have
> > >not been included in a single presigned response. Russ's example
> fits
> > >into this case. The keyed responder handles, but the keyless will
> fail
> > >for the general case. Some responders respond with the presigned
> > >response that includes one of the certificates (usually the first)
> in
> > >the request. A common situation is to ask for the status of
> > >certificates in a chain. Santosh points out some keyless responders
> > >anticipate this and bundle responses accordingly.
> > >
> > >2) The request is "well-formed" but asks for the status of a
> > >certificate for which the keyless responder has not prepared a
> > >response.  This situation will occur if:
> > >
> > >     a) The request is for status of a certificate from a supported
> CA
> > >but with a serial number for which there is no pre-signed response.
> > >Assuming presigned responses exist for all certificates that would
> be
> > >valid based on their validity intervals, this would occur if the
> > >certificate had expired or was yet to be issued (I am aware the
> > keyless
> > >responders generally produce responses for certificates likely to be
> > >issued before the next generation of presigned responses). The keyed
> > >responder would give a signed "good" response. My understanding is
> > that
> > >the keyless responder under the draft lightweight OCSP responds with
> > an
> > >unsigned "unauthorized" error code.
> > >
> > >     b) The request is for the status of a certificate from an
> > >unsupported (or non-existent) CA. The keyed responder would respond
> > >with a signed "unknown" response while under the draft, the keyless
> > >would again respond with the unsigned "unauthorized" error  code.
> > >
> > >Some might argue with some grounds that these differences are
> unusual,
> > >unlikely, and insignificant.
> > >
> > >I personally consider the behavior in 2 of responding with the
> > >"unauthorized" error to be misleading. "Internal error" sounds more
> > >appropriate if I were constrained to the current error codes.
> > >"Malformed request" might be OK. However, the actual situation does
> > not
> > >match well with any of these errors as they are described in 2560.
> > >
> > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > >identifying the unavoidable differences and/or adding 2 TBD error
> > codes
> > >for the above cases (assuming they are the only differences). The
> > first
> > >error can be worked around by breaking the request for status of
> > >multiples into multiple requests for status of one cert.
> > >
> > >We've also seen some problems with client apps that can't handle
> > >presigned responses that commonly contain the status of several
> (e.g.,
> > >15-25) certs. The apps inquired for the status of a single cert and
> > >apparently expected a response for a single certificate. I'd suggest
> > >that some "must" or "should" words address clients' ability to
> handle
> > >the situation of a response covering multiple certificates.
> > >
> > >
> > >
> > >Bill Price
> > >
> > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > >Sent: Monday, November 13, 2006 11:46 AM
> > >To: Michael Myers; Dave Engberg
> > >Cc: [email-masked]; Sam Hartman
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >Mike:
> > >
> > >I think it is not that simple.  I think you need to say that support
> > >for one certificate MUST be supported, and that support for more
> than
> > >one certificate is OPTIONAL.  Then, the error is am indication that
> > >the requestor has selected an unimplemented OPTION.
> > >
> > >Russ
> > >
> > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > >Responders unable to produce or acquire a definitive response MUST
> > >return <a
> > > >TBD error>.
> > > >
> > > >As to your other points Santosh, that is something I prefer the
> > chairs
> > > >consider.
> > > >
> > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > >
> > > > > Mike,
> > > > >
> > > > > What is the error case?
> > > > >
> > > > > . . .
>

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

------=_NextPart_000_00C9_01C707EA.AD878530--

From: Stefan Santesson <[email-masked]>
To: Santosh Chokhani <[email-masked]>, Russ Housley <[email-masked]>, "Price, Bill" <[email-masked]>, "[email-masked]" <[email-masked]>
CC: Sam Hartman <[email-masked]>, Michael Myers <[email-masked]>, Dave Engberg <[email-masked]>
Date: Tue, 14 Nov 2006 17:11:07 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Santosh,

I didn't say it was hard. I say that I doubt that there are many implementations supporting this scenario even those with a responder key.
It would be interesting to hear from implementers if I'm right.

Stefan Santesson
Senior Program Manager

> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: den 14 november 2006 03:59
> To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> Stefan,
>
> You are making more complex than it is.  The Responder can include all
> the CA certificates that issued the certificate in question and AIA can
> do the rest.
>
> Furthermore, since most PKI are two tier hierarchy, in Enterprise
> environment, the CA certificate certification path is not an issue.
>
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]]
> On Behalf Of Stefan Santesson
> Sent: Monday, November 13, 2006 6:54 PM
> To: Russ Housley; Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I'm not sure the case described is a realistic one.
>
> Section 2.2
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- a CA Designated Responder (Authorized Responder) who holds a
>       specially marked certificate issued directly by the CA,
> indicating
>       that the responder may issue OCSP responses for that CA
>
> Since the request is on certificates issued by 2 different CA:s trust
> option 1 is invalid.
> Trust option 3 is valid in theory but in practice it requires that the
> OCSP responder provide multiple validation paths in the response, one
> for each issuing CA. Somehow I doubt that this is implemented by
> anyone.
>
> Trust option 2 is not generic and is only valid as a result of a local
> configuration.
>
> So I don't think this is a problem only for key-less responders.
>
>
> Stefan Santesson
> Senior Program Manager
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Russ Housley
> > Sent: den 13 november 2006 14:08
> > To: Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I prefer an error that tells the client to ask for the certificate
> > one at a time.
> >
> > Russ
> >
> >
> > At 02:46 PM 11/13/2006, Price, Bill wrote:
> >
> > >I'd suggest focusing on understanding where responses to the keyed
> and
> > >keyless responders inherently differ. I am aware of two general
> cases:
> > >
> > >1) The request asks for the status of multiple certificates that
> have
> > >not been included in a single presigned response. Russ's example
> fits
> > >into this case. The keyed responder handles, but the keyless will
> fail
> > >for the general case. Some responders respond with the presigned
> > >response that includes one of the certificates (usually the first)
> in
> > >the request. A common situation is to ask for the status of
> > >certificates in a chain. Santosh points out some keyless responders
> > >anticipate this and bundle responses accordingly.
> > >
> > >2) The request is "well-formed" but asks for the status of a
> > >certificate for which the keyless responder has not prepared a
> > >response.  This situation will occur if:
> > >
> > >     a) The request is for status of a certificate from a supported
> CA
> > >but with a serial number for which there is no pre-signed response.
> > >Assuming presigned responses exist for all certificates that would
> be
> > >valid based on their validity intervals, this would occur if the
> > >certificate had expired or was yet to be issued (I am aware the
> > keyless
> > >responders generally produce responses for certificates likely to be
> > >issued before the next generation of presigned responses). The keyed
> > >responder would give a signed "good" response. My understanding is
> > that
> > >the keyless responder under the draft lightweight OCSP responds with
> > an
> > >unsigned "unauthorized" error code.
> > >
> > >     b) The request is for the status of a certificate from an
> > >unsupported (or non-existent) CA. The keyed responder would respond
> > >with a signed "unknown" response while under the draft, the keyless
> > >would again respond with the unsigned "unauthorized" error  code.
> > >
> > >Some might argue with some grounds that these differences are
> unusual,
> > >unlikely, and insignificant.
> > >
> > >I personally consider the behavior in 2 of responding with the
> > >"unauthorized" error to be misleading. "Internal error" sounds more
> > >appropriate if I were constrained to the current error codes.
> > >"Malformed request" might be OK. However, the actual situation does
> > not
> > >match well with any of these errors as they are described in 2560.
> > >
> > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > >identifying the unavoidable differences and/or adding 2 TBD error
> > codes
> > >for the above cases (assuming they are the only differences). The
> > first
> > >error can be worked around by breaking the request for status of
> > >multiples into multiple requests for status of one cert.
> > >
> > >We've also seen some problems with client apps that can't handle
> > >presigned responses that commonly contain the status of several
> (e.g.,
> > >15-25) certs. The apps inquired for the status of a single cert and
> > >apparently expected a response for a single certificate. I'd suggest
> > >that some "must" or "should" words address clients' ability to
> handle
> > >the situation of a response covering multiple certificates.
> > >
> > >
> > >
> > >Bill Price
> > >
> > >[mailto:[email-masked]] On Behalf Of Russ Housley
> > >Sent: Monday, November 13, 2006 11:46 AM
> > >To: Michael Myers; Dave Engberg
> > >Cc: [email-masked]; Sam Hartman
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >Mike:
> > >
> > >I think it is not that simple.  I think you need to say that support
> > >for one certificate MUST be supported, and that support for more
> than
> > >one certificate is OPTIONAL.  Then, the error is am indication that
> > >the requestor has selected an unimplemented OPTION.
> > >
> > >Russ
> > >
> > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > >Responders unable to produce or acquire a definitive response MUST
> > >return <a
> > > >TBD error>.
> > > >
> > > >As to your other points Santosh, that is something I prefer the
> > chairs
> > > >consider.
> > > >
> > > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > >
> > > > > Mike,
> > > > >
> > > > > What is the error case?
> > > > >
> > > > > . . .
>

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: PEM file format rfc draft request
Cc: [email-masked], [email-masked]
Date: Wed, 15 Nov 2006 05:27:56 +1300
Sender: [email-masked]

"Ogle Ron" <[email-masked]> writes:

>If not PKIX, then where?

A web page somewhere where Google can find it.  Given that this is such a
moving target, I'm not sure that an RFC is the best way to document this even
if you could find a WG that would adopt it.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: PEM file format rfc draft request
Cc: [email-masked]
Date: Wed, 15 Nov 2006 05:25:14 +1300
Sender: [email-masked]

"Ogle Ron" <[email-masked]> writes:

>The issue that I discovered was when I was working with PEM files for PKCS1
>and PKCS8 formatted private keys under OpenSSL and some Java toolkits using
>an IAIK implementation.  OpenSSL expects PKCS8 PEM files to have "BEGIN
>PRIVATE KEY" as the header while IAIK uses "BEGIN RSA PRIVATE KEY" for RSA
>keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For PKCS1, both expect "BEGIN
>RSA PRIVATE KEY".

Uhh, given that it's probably about 10-15 years too late to try and fix this,
is it worth even doing this?  Most implementations get around it by reading
the lowest common denominator of all the formats they know of (for example my
code looks for '----' + 'BEGIN' + 'PRIVATE', which seems to handle all
possibilities).  Even if you could decide on one particular interpretation I
can't imagine anyone's going to change code that's been in the field for 10+
years.  I think the best you could do is create an kind of FYI RFC that
documents all of the possible formats (I started this in my X.509 style guide
some years ago), or maybe document a regexp that'll recognise all possible
formats.

Peter.

Date: Tue, 14 Nov 2006 15:34:59 +0100
From: Peter Sylvester <[email-masked]>
To: pkix <[email-masked]>
Subject: bug in RFC 4043
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030004030308040109010406
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit

In RFC 4043 there seems to be a bug. 

The spec uses ATTRIBUTE instead of OTHER-NAME.  i.e. shouldn't this be:

permanentIdentifier OTHER-NAME ::= {PermanentIdentifier IDENTIFIED BY
id-on-permanentIdentifier}

and OTHER-NAME imported

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorit¨¦; 
die Liste mit zur¨¹ckgerufenen Zertifikaten finden Sie da auch. 

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

--------------ms030004030308040109010406--

From: "Dieter Bratko" <[email-masked]>
To: "Ogle Ron" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: PEM file format rfc draft request
Date: Tue, 14 Nov 2006 15:29:01 +0100
Sender: [email-masked]

> that use x509 also recognize PEM formatted certificates/key pairs.
> This is how I discovered the problem in the first place.
>
> If not PKIX, then where?

I agree with Ron that PKIX would be the right place. PEM as email
security format is not widely used. However, base64 encoded
keys/certificates/certificate requests/crls,... with PEM-style
headers/footers are an inherent part of almost any (X.509 based)
PKI environment.
When implementing en- and decoding of keys and other PKI
objects for our Java crypto toolkit, we first searched for a specification
telling us which headers and footers shall be used. Since no such
specification is available we tried to implement it in a way to be
interoperable with other appliacations. However, each application may
use its own interpretation and some applications are very restrictive and
only accept their own interpretation. The only solution is to provide
additional API methods allowing the user to explicitly set the PEM headers;
however, this only moves the decision to the user (and is not applicable
for final applications).
For that reason a standard giving some recommendations
for the usage of PEM headers would be very useful. It should not
only cover keys, but also certificates, crls, requests,... (for instance,
some applications use -----BEGIN CERTIFICATE REQUEST-----.
and some use -----BEGIN NEW CERTIFICATE REQUEST-----,
and some may use  -----BEGIN PKCS10 REQUEST---- or something
other for encoding a certificate request). We should try to find and setup
a common base from already existing PKI applications.
Since Steve Henson announced that he would help to write
the specification, we already would have the contribution of
one of the most widely used crypto libraries, OpenSSL.

Regards,
Dieter

---------
Dieter Bratko, SIC/IAIK - Graz University of Technology
IAIK, Inffeldgasse 16a, 8010 Graz, Austria, http://jce.iaik.tugraz.at/
----- Original Message ----- 
From: Ogle Ron
To: Stephen Kent
Cc: [email-masked] ; Dieter Bratko
Sent: Tuesday, November 14, 2006 2:18 AM
Subject: RE: PEM file format rfc draft request

I agree that the original PEM meaning is as you state.  I have no idea
as to how it got skewed with these new meanings for public/private keys
and certificates.  However, it does now exist.

As for the relevance with PKIX, the "PEM" format also describes the base
64 encoding with MIME headers for x509 certificates.  Also, many S/MIME,
SSL, IPsec, and other cryptographic standards that use x509 also
recognize PEM formatted certificates/key pairs.  This is how I
discovered the problem in the first place.

If not PKIX, then where?

Thanks
Ron Ogle

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, November 13, 2006 6:45 PM
To: Ogle Ron
Cc: [email-masked]; Dieter Bratko
Subject: Re: PEM file format rfc draft request

At 4:56 PM -0500 11/13/06, Ogle Ron wrote:
>I would like to know if the PKIX working group would be interested in
>shepherding a new rfc concerning PEM file formats?  I've recently
>discovered that there is no definitive standard for how a PEM's headers
>and footers are defined for a private key.  I've searched the RFCs, and
>ISO standards without any luck.

PEM formats were defined for e-mail messages, not files per se. I
think RFC 1421 defines the last of the formats (we had a few
iterations) for PEM.

>The issue that I discovered was when I was working with PEM files for
>PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
>toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
>to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
>PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.
For
>PKCS1, both expect "BEGIN RSA PRIVATE KEY".

it looks like folks made this up!  PEM describes how to transfer a
symmetric key encrypted under a public (RSA) key in a message, in
1421.  It does not describe how to transfer a private key, because
one would not do that via an e-mail message.

The term "PEM file" with regard to PKCS #8 is a misnomer, relative to
IETF standards. Since PKCS #8 defines a format for private keys, it
is not relevant to PEM, period.

Given that PKIX is a WG that focuses on X.509-based standards, it is
not immediately clear that a document on how to use base-64 encoding
and MIME-style headers to represent private keys is within our scope.

Steve 

From: Sam Hartman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: [Wijnen, Bert (Bert)] FW: [members] FW: Proposed charter for OASIS EKMI TC
Date: Tue, 14 Nov 2006 08:49:59 -0500
Sender: [email-masked]

--=-=-=

I'm sorry if this has already been forwarded to pkix.

--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Russ Housley (E-mail)" <[email-masked]>,
	"Sam Hartman (E-mail)" <[email-masked]>
Cc: "Iesg (E-mail)" <[email-masked]>, "IAB (E-mail)" <[email-masked]>
Subject: FW: [members] FW: Proposed charter for OASIS EKMI TC 
Date: Mon, 13 Nov 2006 15:36:49 +0100

FYI, just in case no one else sees these types of
announcements.

Loa, are these guys on the new-work list?
If not, maybe you should contact them to see if they
are willing to announce these things on new-work as well.

Bert

-----Original Message-----
From: Mary McRae [mailto:[email-masked]]
Sent: Friday, November 10, 2006 18:57
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [members] FW: Proposed charter for OASIS EKMI TC 

To: OASIS Members 

   A draft TC charter has been submitted to establish an Enterprise
Key Management Infrastructure (EKMI) Technical Committee at OASIS.
We circulate such draft charters for member review and comments, in
accordance with Section 2,2 of the OASIS TC Process rules: 
   http://www.oasis-open.org/committees/process.php#2.2
The proposed charter below is open for comment. The comment period
shall remain open until 11:45 pm ET on 22 November 2006. 

   OASIS maintains a mailing list for the purpose of submitting
comments on proposed charters. Any OASIS member may post to this
list by sending e-mail to:
   [email-masked].
All messages will be publicly archived at:
   http://lists.oasis-open.org/archives/oasis-charter-discuss/  

Members who wish to receive these messages via e-mail must join the
group by selecting "join group" on the list's home page:

http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/.
Employees of organizational members do not require primary
representative approval to subscribe to the oasis-charter-discuss
e-mail.

   A telephone conference will be held among the Convener, the OASIS TC
Administrator, and those proposers who wish to attend shortly after
  the close of the comment period.  The time and call-in information
will be noted on the oasis-charter-discuss list and home page. 

   We encourage member comment, and ask that you note the name of
the proposed TC (EKMI) in the subject line of your email message.

   Best regards   JBC

~ James Bryce Clark
~ Director of Standards Development, OASIS 
~ http://www.oasis-open.org/who/staff.php#clark
~ [email-masked]

====
PROPOSED CHARTER 
FOR REVIEW AND COMMENT
OASIS ENTERPRISE KEY MANAGEMENT INFRASTRUCTURE TECHNICAL COMMITTEE

Name

OASIS Enterprise Key Management Infrastructure (EKMI) TC

Statement of Purpose

Public Key Infrastructure (PKI) technology has been around for more 
than a decade, and many companies have adopted it to solve specific
problems in the area of public-key cryptography.  Public-key
cryptography has been embedded in some of the most popular tools --
web clients and servers, VPN clients and servers, mail user agents, 
office productivity tools and many industry-specific applications --
and underlies many mission-critical environments today.
Additionally, there are many commercial and open-source
implementations of PKI software products available in the market 
today.  However, many companies across the world have recognized
that PKI by itself, is not a solution.

There is also the perception that most standards in PKI have already
been established by ISO and the PKIX (IETF), and most companies are 
in operations-mode with their PKIs -- just using it, and adopting it
to other business uses within their organizations. Consequently,
there is not much left to architect and design in the PKI community.

Simultaneously, there is a new interest on the part of many 
companies in the management of symmetric keys used for encrypting
sensitive data in their computing infrastructure. While symmetric
keys have been traditionally managed by applications doing their own
encryption and decryption, there is no architecture or protocol that 
provides for symmetric key management services across applications,
operating systems, databases, etc. While there are many industry
standards around protocols for the life-cycle management of
asymmetric (or public/private) keys -- PKCS10, PKCS7, CRMF, CMS, etc. 
-- however, there is no standard that describes how applications may
request similar life-cycle services for symmetric keys, from a
server and how public-key cryptography may be used to provide such
services. 

Key management needs to be addressed by enterprises in its
entirety -- for both symmetric and asymmetric keys.  While each type
of technology will require specific protocols, controls and
management disciplines, there is sufficient common ground in the 
discipline justifying the approach to look at key-management as a
whole, rather than in parts.  Therefore, this TC will address the
following:

Scope

A) The TC will define the request/response protocols for: 

1. Requesting a new or existing symmetric key from a server;
2. Requesting policy information from a server related to caching of
keys on the client;
3. Sending a symmetric key to a requestor, based on a request; 
4. Sending policy information to a requestor, based on a request;
5. Other protocol pairs as deemed necessary.

B) To ensure cross-implementation interoperability, the TC will
create a test suite (as described under 'Deliverables' below) that 
will allow different implementations of this protocol to be
certified against the OASIS standard (when ratified);

C) The TC will provide guidance on how a symmetric key-management
infrastructure may be secured using asymmetric keys, using secure 
and generally accepted practices;

D) Where appropriate, and if possible in conjunction with other
standards organizations that focus on disciplines
outside the purview of OASIS, the TC will provide input on how such 
enterprise key-management infrastructures may be managed, operated
and audited;

E) The TC may conduct other activities that educate users about,
and promote, securing sensitive data with appropriate cryptography, 
and the use of proper key-management techniques and disciplines to
ensure appropriate protection of the infrastructure.

List of Deliverables

1. XSchema Definitions (XSD) of the request and response protocols 
(by April 2007)
2. A Test Suite of conformance clauses and sample transmitted keys
and content that allows for clients and servers to be tested for
conformance to the defined protocol (by September 2007)
3. Documentation that explains the communication protocol (by 
April 2007)
4. Documentation that provides guidelines for how an EKMI may be
built, operated, secured and audited (by June 2007)
5. Resources that promote enterprise-level key-management: white
papers, seminars, samples, and information for developer and public 
use. (beginning January 2007, continuing at least through 2008)

Anticipated Audiences:

Any company or organization that has a need for managing
cryptographic keys across applications, databases, operating systems 
and devices, yet desires centralized policy-driven management of all
cryptographic keys in the enterprise. Retail, health-care,
government, education, finance - every industry has a need to
protect the confidentiality of sensitive data. The TC's 
deliverables will provide an industry standard for protecting
sensitive information across these, and other, industries.
Security services vendors and integrators should be able to fulfill
their use cases with the TC's key management methodologies. 
Members of the OASIS PKI TC should be very interested in this new TC,
since the goals of this TC potentially may fulfill some of the
goals in the charter of the PKI TC.

Language:

English

IPR Policy: 

Royalty Free on Limited Terms under the OASIS IPR Policy

----
Additional Non-normative information regarding the start-up of the TC:

a. Identification of similar or applicable work:

The proposers are unaware of any similar work being carried on in 
this exact area.  However, this TC intends to leverage the
products of, and seek liaison with, a number of other existing
projects that may interoperate with or provide functionality to the
EKMI TC's planned outputs, including: 

OASIS Web Services Security TC
W3C XMLSignature and XMLEncryption protocols and working group
OASIS Digital Signature Services TC
OASIS Public Key Infrastructure TC
OASIS XACML TC (and other methods for providing granular 
access-control permissions that may be consumed or enforced by
symmetic key management)

b.  Anticipated contributions:

StrongAuth, Inc. anticipates providing a draft proposal for the EKMI
protocol, at the inception of the TC.  The current draft can be 
viewed at:

http://www.strongkey.org/resources/documentation/misc/skcl-sks-protocol.html
and a working implementation of this protocol is available at: 
   http://sourceforge.net/projects/strongkey for interested parties.

c. Proposed working title and acronym for specification:

Symmetric Key Services Markup Language (SKSML), subject to TC's 
approval or change.

d.  Date, time, and location of the first meeting:

First meeting will be by teleconference, with an optional face-to-
face gathering as one conference call node, at:
Date:  [December ____, 2006] 
Time:  [____ UTC]
Call in details'; to be posted to TC list
F2F Location:  San Francisco Bay Area.  StrongAuth has agreed to
host this meeting.

e. Projected meeting schedule:

Subject to TC's approval, we anticipate monthly telephone meetings 
for the first year. First version of the protocol to be voted on by
Summer 2007. StrongAuth is willing to assist by arranging for the
teleconferences; we anticipate using readily available free
teleconference services. 

f. Names, electronic mail addresses, of supporters:

Ken Adler, individual member, [email-masked]
June Leung, FundSERV, [email-masked] 
John Messing, American Bar Association, [email-masked]
Arshad Noor, individual member, [email-masked] 
Davi Ottenheimer, individual member, [email-masked]
Ann Terwilliger, Visa International, [email-masked]

g. TC Convener:

Arshad Noor, [email-masked]

END DRAFT

-- 
Mary P McRae
Manager of TC Administration, OASIS
[email-masked]
voip: 603.232.9090

Message does not appear in the archives - forwarding for inclusion

---------------------------------------------------------------------

This email list is used solely by OASIS for official consortium communications.

Opt-out requests may be sent to [email-masked], however, all members are strongly encouraged to maintain a subscription to this list.

--=-=-=--

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 03:58:41 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Russ Housley" <[email-masked]>, "Price, Bill" <[email-masked]>, <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>, "Michael Myers" <[email-masked]>, "Dave Engberg" <[email-masked]>
Sender: [email-masked]

Stefan,

You are making more complex than it is.  The Responder can include all
the CA certificates that issued the certificate in question and AIA can
do the rest.

Furthermore, since most PKI are two tier hierarchy, in Enterprise
environment, the CA certificate certification path is not an issue.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Monday, November 13, 2006 6:54 PM
To: Russ Housley; Price, Bill; [email-masked]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

I'm not sure the case described is a realistic one.

Section 2.2
   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

Since the request is on certificates issued by 2 different CA:s trust
option 1 is invalid.
Trust option 3 is valid in theory but in practice it requires that the
OCSP responder provide multiple validation paths in the response, one
for each issuing CA. Somehow I doubt that this is implemented by anyone.

Trust option 2 is not generic and is only valid as a result of a local
configuration.

So I don't think this is a problem only for key-less responders.

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 13 november 2006 14:08
> To: Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I prefer an error that tells the client to ask for the certificate
> one at a time.
>
> Russ
>
>
> At 02:46 PM 11/13/2006, Price, Bill wrote:
>
> >I'd suggest focusing on understanding where responses to the keyed
and
> >keyless responders inherently differ. I am aware of two general
cases:
> >
> >1) The request asks for the status of multiple certificates that have
> >not been included in a single presigned response. Russ's example fits
> >into this case. The keyed responder handles, but the keyless will
fail
> >for the general case. Some responders respond with the presigned
> >response that includes one of the certificates (usually the first) in
> >the request. A common situation is to ask for the status of
> >certificates in a chain. Santosh points out some keyless responders
> >anticipate this and bundle responses accordingly.
> >
> >2) The request is "well-formed" but asks for the status of a
> >certificate for which the keyless responder has not prepared a
> >response.  This situation will occur if:
> >
> >     a) The request is for status of a certificate from a supported
CA
> >but with a serial number for which there is no pre-signed response.
> >Assuming presigned responses exist for all certificates that would be
> >valid based on their validity intervals, this would occur if the
> >certificate had expired or was yet to be issued (I am aware the
> keyless
> >responders generally produce responses for certificates likely to be
> >issued before the next generation of presigned responses). The keyed
> >responder would give a signed "good" response. My understanding is
> that
> >the keyless responder under the draft lightweight OCSP responds with
> an
> >unsigned "unauthorized" error code.
> >
> >     b) The request is for the status of a certificate from an
> >unsupported (or non-existent) CA. The keyed responder would respond
> >with a signed "unknown" response while under the draft, the keyless
> >would again respond with the unsigned "unauthorized" error  code.
> >
> >Some might argue with some grounds that these differences are
unusual,
> >unlikely, and insignificant.
> >
> >I personally consider the behavior in 2 of responding with the
> >"unauthorized" error to be misleading. "Internal error" sounds more
> >appropriate if I were constrained to the current error codes.
> >"Malformed request" might be OK. However, the actual situation does
> not
> >match well with any of these errors as they are described in 2560.
> >
> >If 2560 is supposed to encompass keyless responders, I'd recommend
> >identifying the unavoidable differences and/or adding 2 TBD error
> codes
> >for the above cases (assuming they are the only differences). The
> first
> >error can be worked around by breaking the request for status of
> >multiples into multiple requests for status of one cert.
> >
> >We've also seen some problems with client apps that can't handle
> >presigned responses that commonly contain the status of several
(e.g.,
> >15-25) certs. The apps inquired for the status of a single cert and
> >apparently expected a response for a single certificate. I'd suggest
> >that some "must" or "should" words address clients' ability to handle
> >the situation of a response covering multiple certificates.
> >
> >
> >
> >Bill Price
> >
> >[mailto:[email-masked]] On Behalf Of Russ Housley
> >Sent: Monday, November 13, 2006 11:46 AM
> >To: Michael Myers; Dave Engberg
> >Cc: [email-masked]; Sam Hartman
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >Mike:
> >
> >I think it is not that simple.  I think you need to say that support
> >for one certificate MUST be supported, and that support for more than
> >one certificate is OPTIONAL.  Then, the error is am indication that
> >the requestor has selected an unimplemented OPTION.
> >
> >Russ
> >
> >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > >Responders unable to produce or acquire a definitive response MUST
> >return <a
> > >TBD error>.
> > >
> > >As to your other points Santosh, that is something I prefer the
> chairs
> > >consider.
> > >
> > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > >
> > > > Mike,
> > > >
> > > > What is the error case?
> > > >
> > > > . . .

From: "died" <[email-masked]>
To: [email-masked]
Subject: Re: css editores tags fotoshop
Date: 	Tue, 14 Nov 2006 00:40:26 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C70785.7A5EDAB0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000C_01C70785.7A5EDAB0"

------=_NextPart_001_000C_01C70785.7A5EDAB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

  ----- Original Message -----=20
  From: [email-masked]=20
  To: [email-masked]=20
  Sent: Wednesday, November 00:40:05 AM
  Subject: css editores tags fotoshop

  Floating of serenely globe team.
  Rates among indigenous cultures could Polynesian.
  Selecting map below Computer Nursing.
  Rip is through roading worker or suffered serious injuries. Grave =
Barrows tombstone equipment operated remote or.
  Native temperate connects surrounds structures organs bodyedit =
hobbyists.
  Hotel a Human Technology Maint. Sales Science Skilled Trades Strategy. =
Hello Guestlogin de Main toolscddvd toolsfile Toolsipod.
  Custody children am Malawi judge am.
  There dark should in ashamedof neither? Multipart articles multiple =
servers.
  Hyatt or Verizon Robert Half or Wells. Moderate am wing am forces =
Labour indirect or.
  Problems Students are especially prone a poor choices stumble =
literate? Gadgets is seo is Otaku Ovidiu Predescus Pedrams of.
  Thinking or Brewer is Lion.
  Macabre gullible am desperate?
  Social historians future Geldard is Wilts of suppose is liner. =
Multipart articles multiple servers.
  Rates among indigenous cultures could Polynesian.
  Aubin am happen is impressed of dedication improve geographic =
knowledge literacy. Federline threatens release sex is tape Britney am =
Spears.
  Hexeditor visual Jdoggnet password. Traffic detailed integrated is =
movable or satellite imagery matter quickest.
  Perhaps respect Knowing likely Beneath sod lies another.
  Hexeditor visual Jdoggnet password.
  Appearance usb ports.
  Bundle a Spyremover am net.
  Speed defend a role.
  Links box itd a highly didnt cost buckets.
------=_NextPart_001_000C_01C70785.7A5EDAB0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Hourly" hspace=3D0=20
src=3D"cid:000a01c707af$6334e2b0$00000000@J0HNS0NPALACE" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</=
A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, November =
00:40:05 AM=20
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> css editores tags =
fotoshop</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Floating of serenely globe =
team.<BR>Rates among=20
indigenous cultures could Polynesian.<BR>Selecting map below Computer=20
Nursing.<BR>Rip is through roading worker or suffered serious injuries. =
Grave=20
Barrows tombstone equipment operated remote or.<BR>Native temperate =
connects=20
surrounds structures organs bodyedit hobbyists.<BR>Hotel a Human =
Technology=20
Maint. Sales Science Skilled Trades Strategy. Hello Guestlogin de Main=20
toolscddvd toolsfile Toolsipod.<BR>Custody children am Malawi judge =
am.<BR>There=20
dark should in ashamedof neither? Multipart articles multiple =
servers.<BR>Hyatt=20
or Verizon Robert Half or Wells. Moderate am wing am forces Labour =
indirect=20
or.<BR>Problems Students are especially prone a poor choices stumble =
literate?=20
Gadgets is seo is Otaku Ovidiu Predescus Pedrams of.<BR>Thinking or =
Brewer is=20
Lion.<BR>Macabre gullible am desperate?<BR>Social historians future =
Geldard is=20
Wilts of suppose is liner. Multipart articles multiple servers.<BR>Rates =
among=20
indigenous cultures could Polynesian.<BR>Aubin am happen is impressed of =

dedication improve geographic knowledge literacy. Federline threatens =
release=20
sex is tape Britney am Spears.<BR>Hexeditor visual Jdoggnet password. =
Traffic=20
detailed integrated is movable or satellite imagery matter =
quickest.<BR>Perhaps=20
respect Knowing likely Beneath sod lies another.<BR>Hexeditor visual =
Jdoggnet=20
password.<BR>Appearance usb ports.<BR>Bundle a Spyremover am =
net.<BR>Speed=20
defend a role.<BR>Links box itd a highly didnt cost=20
buckets.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_000C_01C70785.7A5EDAB0--

------=_NextPart_000_000B_01C70785.7A5EDAB0
Content-Type: image/gif;
	name="million.gif"
Content-Transfer-Encoding: base64
Content-ID: <000a01c707af$6334e2b0$00000000@J0HNS0NPALACE>

------=_NextPart_000_000B_01C70785.7A5EDAB0--

Content-class: urn:content-classes:message
Subject: RE: PEM file format rfc draft request
Date: Mon, 13 Nov 2006 20:18:29 -0500
From: "Ogle Ron" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>, "Dieter Bratko" <[email-masked]>
Sender: [email-masked]

I agree that the original PEM meaning is as you state.  I have no idea
as to how it got skewed with these new meanings for public/private keys
and certificates.  However, it does now exist.

As for the relevance with PKIX, the "PEM" format also describes the base
64 encoding with MIME headers for x509 certificates.  Also, many S/MIME,
SSL, IPsec, and other cryptographic standards that use x509 also
recognize PEM formatted certificates/key pairs.  This is how I
discovered the problem in the first place.

If not PKIX, then where?

Thanks
Ron Ogle

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, November 13, 2006 6:45 PM
To: Ogle Ron
Cc: [email-masked]; Dieter Bratko
Subject: Re: PEM file format rfc draft request

At 4:56 PM -0500 11/13/06, Ogle Ron wrote:
>I would like to know if the PKIX working group would be interested in
>shepherding a new rfc concerning PEM file formats?  I've recently
>discovered that there is no definitive standard for how a PEM's headers
>and footers are defined for a private key.  I've searched the RFCs, and
>ISO standards without any luck.

PEM formats were defined for e-mail messages, not files per se. I 
think RFC 1421 defines the last of the formats (we had a few 
iterations) for PEM.

>The issue that I discovered was when I was working with PEM files for
>PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
>toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
>to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
>PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.
For
>PKCS1, both expect "BEGIN RSA PRIVATE KEY".

it looks like folks made this up!  PEM describes how to transfer a 
symmetric key encrypted under a public (RSA) key in a message, in 
1421.  It does not describe how to transfer a private key, because 
one would not do that via an e-mail message.

The term "PEM file" with regard to PKCS #8 is a misnomer, relative to 
IETF standards. Since PKCS #8 defines a format for private keys, it 
is not relevant to PEM, period.

Given that PKIX is a WG that focuses on X.509-based standards, it is 
not immediately clear that a document on how to use base-64 encoding 
and MIME-style headers to represent private keys is within our scope.

Steve

From: "tam" <[email-masked]>
To: [email-masked]
Subject: Re: WWW wykrywanie spamu wirusw
Date: 	Sun, 5 Nov 2006 19:17:51 -0200

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C7010F.16481B30
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0006_01C7010F.16481B30"

------=_NextPart_001_0006_01C7010F.16481B30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

  ----- Original Message -----=20
  From: [email-masked]=20
  To: [email-masked]=20
  Sent: Monday, November 01:09:02 PM
  Subject: WWW wykrywanie spamu wirusw

  Redakcja Forum Kcik webmastera Reklama Sownik Wirusy Bios praktyce?
  Enter getdatestr in Infoserwis.
  Cm dugoci Intel zwiksza.
  Konta nowymi mb of poczt www wykrywanie a spamu. Adowania am strony =
artykuw.
  Podwoi zyski a iii kwartale Nowy serwis Gadufun Jeeli of.
  Vogel Burda sp oo is Wszystkie prawa. Praktyce Linux is spka. Zobacz =
is Ankieta am Jakie zmiany stronie of enterpl.
  Praktyczne a porady dotyczce ochrony.
  Nowy serwis am Gadufun Jeeli am tworzysz in swoj wasn. Konkursy or =
Ksiki Ankiety Pocztawww is Redakcja Forum.
  Wiele innych Uwaga Praktyczne porady dotyczce is ochrony. Online =
Zmiana a nawigacji am wyniki?
  Konkursy Ksiki Ankiety or Pocztawww Redakcja Forum. Stronie enterpl =
uwaasz potrzebne Szata graficzna dziay adowania of strony?
  Online Zmiana nawigacji wyniki Najnowsze wtki Konta nowymi.
  Domen Personal email a gb Business a Server Patronaty medialne.
  Kcika is Znajdziesz tam kurs Html oraz of podrcznik php. Konkursy or =
Ksiki Ankiety Pocztawww is Redakcja Forum.
  Enter getdatestr in Infoserwis.
  Powiedz gdzie oni osb za. Artykuw Mniej reklam Kursy online Zmiana =
nawigacji wyniki Najnowsze.
  Konkretnym uniksowego wiata. Ramwki pierwszej polskiej am telewizji =
granej na.
  Kcik webmastera Reklama Sownik Wirusy Bios or.
  Konkretnym uniksowego wiata.
  Galerii zdjciami Linuksem in systemami rodziny?
  Acxiom dla Centertela uke is.
  Intela am Tsmc buduje nowe of Faby amd deklaruj am dobre stosunki.
  Internetow lub po prostu pragniesz zapozna si.
------=_NextPart_001_0006_01C7010F.16481B30
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"pierwszej" hspace=3D0=20
src=3D"cid:000401c7011f$d9d0eb30$a6c21dc9@barrostu327chq" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, November 01:09:02 =
PM </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> WWW wykrywanie spamu =
wirusw</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Redakcja Forum Kcik webmastera Reklama =
Sownik=20
Wirusy Bios praktyce?<BR>Enter getdatestr in Infoserwis.<BR>Cm dugoci =
Intel=20
zwiksza.<BR>Konta nowymi mb of poczt www wykrywanie a spamu. Adowania am =
strony=20
artykuw.<BR>Podwoi zyski a iii kwartale Nowy serwis Gadufun Jeeli =
of.<BR>Vogel=20
Burda sp oo is Wszystkie prawa. Praktyce Linux is spka. Zobacz is =
Ankieta am=20
Jakie zmiany stronie of enterpl.<BR>Praktyczne a porady dotyczce=20
ochrony.<BR>Nowy serwis am Gadufun Jeeli am tworzysz in swoj wasn. =
Konkursy or=20
Ksiki Ankiety Pocztawww is Redakcja Forum.<BR>Wiele innych Uwaga =
Praktyczne=20
porady dotyczce is ochrony. Online Zmiana a nawigacji am =
wyniki?<BR>Konkursy=20
Ksiki Ankiety or Pocztawww Redakcja Forum. Stronie enterpl uwaasz =
potrzebne=20
Szata graficzna dziay adowania of strony?<BR>Online Zmiana nawigacji =
wyniki=20
Najnowsze wtki Konta nowymi.<BR>Domen Personal email a gb Business a =
Server=20
Patronaty medialne.<BR>Kcika is Znajdziesz tam kurs Html oraz of =
podrcznik php.=20
Konkursy or Ksiki Ankiety Pocztawww is Redakcja Forum.<BR>Enter =
getdatestr in=20
Infoserwis.<BR>Powiedz gdzie oni osb za. Artykuw Mniej reklam Kursy =
online=20
Zmiana nawigacji wyniki Najnowsze.<BR>Konkretnym uniksowego wiata. =
Ramwki=20
pierwszej polskiej am telewizji granej na.<BR>Kcik webmastera Reklama =
Sownik=20
Wirusy Bios or.<BR>Konkretnym uniksowego wiata.<BR>Galerii zdjciami =
Linuksem in=20
systemami rodziny?<BR>Acxiom dla Centertela uke is.<BR>Intela am Tsmc =
buduje=20
nowe of Faby amd deklaruj am dobre stosunki.<BR>Internetow lub po prostu =

pragniesz zapozna si.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0006_01C7010F.16481B30--

------=_NextPart_000_0005_01C7010F.16481B30
Content-Type: image/gif;
	name="czy.gif"
Content-Transfer-Encoding: base64
Content-ID: <000401c7011f$d9d0eb30$a6c21dc9@barrostu327chq>

------=_NextPart_000_0005_01C7010F.16481B30--

From: Stefan Santesson <[email-masked]>
To: Russ Housley <[email-masked]>, "Price, Bill" <[email-masked]>, "[email-masked]" <[email-masked]>
CC: Sam Hartman <[email-masked]>, Michael Myers <[email-masked]>, Dave Engberg <[email-masked]>
Date: Tue, 14 Nov 2006 00:30:20 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I've been taking a close look at this and I've come to the conclusion that we are fine. That is, I can't find any support for that provision of pre-produced responses handed out by a key-less responder is violating RFC 2560 in any way.

RFC 2560 does not require the responder to return a successful response for all possible legitimate requests. It only require the responder to support the basic response format when it chooses to return a response. As I read RFC 2560, it may fail responding to a request for any reason as long as it returns a legitimate error.

There is no place where RFC 2560 requires the render to successfully handle a composite request. It only specifies how it should be done.

On the contrary, support for pre-produced responses is explicitly supported in 2.5. And as such it is obvious that such responder can't respond to all possible requests.

Of the error codes listed, I find that "unauthorized" is the most appropriate one for unsupported requests as it indicates that "the client is not authorized to make this query to this server". The description may not be 100% perfect but it is sufficiently good and the response is definitive and avoids repetition.

The response "internalError" would be misleading as it "indicates that the OCSP responder reached an inconsistent internal state. The query should be retried, potentially with another responder", which may cause the requester to keep retrying the request.

My conclusion is that no update to RFC 2560 is needed to progress the informational profile for lightweight OCSP.

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 13 november 2006 14:08
> To: Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I prefer an error that tells the client to ask for the certificate
> one at a time.
>
> Russ
>
>
> At 02:46 PM 11/13/2006, Price, Bill wrote:
>
> >I'd suggest focusing on understanding where responses to the keyed and
> >keyless responders inherently differ. I am aware of two general cases:
> >
> >1) The request asks for the status of multiple certificates that have
> >not been included in a single presigned response. Russ's example fits
> >into this case. The keyed responder handles, but the keyless will fail
> >for the general case. Some responders respond with the presigned
> >response that includes one of the certificates (usually the first) in
> >the request. A common situation is to ask for the status of
> >certificates in a chain. Santosh points out some keyless responders
> >anticipate this and bundle responses accordingly.
> >
> >2) The request is "well-formed" but asks for the status of a
> >certificate for which the keyless responder has not prepared a
> >response.  This situation will occur if:
> >
> >     a) The request is for status of a certificate from a supported CA
> >but with a serial number for which there is no pre-signed response.
> >Assuming presigned responses exist for all certificates that would be
> >valid based on their validity intervals, this would occur if the
> >certificate had expired or was yet to be issued (I am aware the
> keyless
> >responders generally produce responses for certificates likely to be
> >issued before the next generation of presigned responses). The keyed
> >responder would give a signed "good" response. My understanding is
> that
> >the keyless responder under the draft lightweight OCSP responds with
> an
> >unsigned "unauthorized" error code.
> >
> >     b) The request is for the status of a certificate from an
> >unsupported (or non-existent) CA. The keyed responder would respond
> >with a signed "unknown" response while under the draft, the keyless
> >would again respond with the unsigned "unauthorized" error  code.
> >
> >Some might argue with some grounds that these differences are unusual,
> >unlikely, and insignificant.
> >
> >I personally consider the behavior in 2 of responding with the
> >"unauthorized" error to be misleading. "Internal error" sounds more
> >appropriate if I were constrained to the current error codes.
> >"Malformed request" might be OK. However, the actual situation does
> not
> >match well with any of these errors as they are described in 2560.
> >
> >If 2560 is supposed to encompass keyless responders, I'd recommend
> >identifying the unavoidable differences and/or adding 2 TBD error
> codes
> >for the above cases (assuming they are the only differences). The
> first
> >error can be worked around by breaking the request for status of
> >multiples into multiple requests for status of one cert.
> >
> >We've also seen some problems with client apps that can't handle
> >presigned responses that commonly contain the status of several (e.g.,
> >15-25) certs. The apps inquired for the status of a single cert and
> >apparently expected a response for a single certificate. I'd suggest
> >that some "must" or "should" words address clients' ability to handle
> >the situation of a response covering multiple certificates.
> >
> >
> >
> >Bill Price
> >
> >[mailto:[email-masked]] On Behalf Of Russ Housley
> >Sent: Monday, November 13, 2006 11:46 AM
> >To: Michael Myers; Dave Engberg
> >Cc: [email-masked]; Sam Hartman
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >Mike:
> >
> >I think it is not that simple.  I think you need to say that support
> >for one certificate MUST be supported, and that support for more than
> >one certificate is OPTIONAL.  Then, the error is am indication that
> >the requestor has selected an unimplemented OPTION.
> >
> >Russ
> >
> >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > >Responders unable to produce or acquire a definitive response MUST
> >return <a
> > >TBD error>.
> > >
> > >As to your other points Santosh, that is something I prefer the
> chairs
> > >consider.
> > >
> > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > >
> > > > Mike,
> > > >
> > > > What is the error case?
> > > >
> > > > . . .

From: Stefan Santesson <[email-masked]>
To: Russ Housley <[email-masked]>, "Price, Bill" <[email-masked]>, "[email-masked]" <[email-masked]>
CC: Sam Hartman <[email-masked]>, Michael Myers <[email-masked]>, Dave Engberg <[email-masked]>
Date: Mon, 13 Nov 2006 23:54:09 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I'm not sure the case described is a realistic one.

Section 2.2
   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

Since the request is on certificates issued by 2 different CA:s trust option 1 is invalid.
Trust option 3 is valid in theory but in practice it requires that the OCSP responder provide multiple validation paths in the response, one for each issuing CA. Somehow I doubt that this is implemented by anyone.

Trust option 2 is not generic and is only valid as a result of a local configuration.

So I don't think this is a problem only for key-less responders.

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 13 november 2006 14:08
> To: Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I prefer an error that tells the client to ask for the certificate
> one at a time.
>
> Russ
>
>
> At 02:46 PM 11/13/2006, Price, Bill wrote:
>
> >I'd suggest focusing on understanding where responses to the keyed and
> >keyless responders inherently differ. I am aware of two general cases:
> >
> >1) The request asks for the status of multiple certificates that have
> >not been included in a single presigned response. Russ's example fits
> >into this case. The keyed responder handles, but the keyless will fail
> >for the general case. Some responders respond with the presigned
> >response that includes one of the certificates (usually the first) in
> >the request. A common situation is to ask for the status of
> >certificates in a chain. Santosh points out some keyless responders
> >anticipate this and bundle responses accordingly.
> >
> >2) The request is "well-formed" but asks for the status of a
> >certificate for which the keyless responder has not prepared a
> >response.  This situation will occur if:
> >
> >     a) The request is for status of a certificate from a supported CA
> >but with a serial number for which there is no pre-signed response.
> >Assuming presigned responses exist for all certificates that would be
> >valid based on their validity intervals, this would occur if the
> >certificate had expired or was yet to be issued (I am aware the
> keyless
> >responders generally produce responses for certificates likely to be
> >issued before the next generation of presigned responses). The keyed
> >responder would give a signed "good" response. My understanding is
> that
> >the keyless responder under the draft lightweight OCSP responds with
> an
> >unsigned "unauthorized" error code.
> >
> >     b) The request is for the status of a certificate from an
> >unsupported (or non-existent) CA. The keyed responder would respond
> >with a signed "unknown" response while under the draft, the keyless
> >would again respond with the unsigned "unauthorized" error  code.
> >
> >Some might argue with some grounds that these differences are unusual,
> >unlikely, and insignificant.
> >
> >I personally consider the behavior in 2 of responding with the
> >"unauthorized" error to be misleading. "Internal error" sounds more
> >appropriate if I were constrained to the current error codes.
> >"Malformed request" might be OK. However, the actual situation does
> not
> >match well with any of these errors as they are described in 2560.
> >
> >If 2560 is supposed to encompass keyless responders, I'd recommend
> >identifying the unavoidable differences and/or adding 2 TBD error
> codes
> >for the above cases (assuming they are the only differences). The
> first
> >error can be worked around by breaking the request for status of
> >multiples into multiple requests for status of one cert.
> >
> >We've also seen some problems with client apps that can't handle
> >presigned responses that commonly contain the status of several (e.g.,
> >15-25) certs. The apps inquired for the status of a single cert and
> >apparently expected a response for a single certificate. I'd suggest
> >that some "must" or "should" words address clients' ability to handle
> >the situation of a response covering multiple certificates.
> >
> >
> >
> >Bill Price
> >
> >[mailto:[email-masked]] On Behalf Of Russ Housley
> >Sent: Monday, November 13, 2006 11:46 AM
> >To: Michael Myers; Dave Engberg
> >Cc: [email-masked]; Sam Hartman
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >Mike:
> >
> >I think it is not that simple.  I think you need to say that support
> >for one certificate MUST be supported, and that support for more than
> >one certificate is OPTIONAL.  Then, the error is am indication that
> >the requestor has selected an unimplemented OPTION.
> >
> >Russ
> >
> >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > >Responders unable to produce or acquire a definitive response MUST
> >return <a
> > >TBD error>.
> > >
> > >As to your other points Santosh, that is something I prefer the
> chairs
> > >consider.
> > >
> > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > >
> > > > Mike,
> > > >
> > > > What is the error case?
> > > >
> > > > . . .

Date: Mon, 13 Nov 2006 18:44:32 -0500
To: "Ogle Ron" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PEM file format rfc draft request
Cc: <[email-masked]>, "Dieter Bratko" <[email-masked]>
Sender: [email-masked]

At 4:56 PM -0500 11/13/06, Ogle Ron wrote:
>I would like to know if the PKIX working group would be interested in
>shepherding a new rfc concerning PEM file formats?  I've recently
>discovered that there is no definitive standard for how a PEM's headers
>and footers are defined for a private key.  I've searched the RFCs, and
>ISO standards without any luck.

PEM formats were defined for e-mail messages, not files per se. I 
think RFC 1421 defines the last of the formats (we had a few 
iterations) for PEM.

>The issue that I discovered was when I was working with PEM files for
>PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
>toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
>to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
>PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For
>PKCS1, both expect "BEGIN RSA PRIVATE KEY".

it looks like folks made this up!  PEM describes how to transfer a 
symmetric key encrypted under a public (RSA) key in a message, in 
1421.  It does not describe how to transfer a private key, because 
one would not do that via an e-mail message.

The term "PEM file" with regard to PKCS #8 is a misnomer, relative to 
IETF standards. Since PKCS #8 defines a format for private keys, it 
is not relevant to PEM, period.

Given that PKIX is a WG that focuses on X.509-based standards, it is 
not immediately clear that a document on how to use base-64 encoding 
and MIME-style headers to represent private keys is within our scope.

Steve

Date: Mon, 13 Nov 2006 22:46:07 +0000
From: Dr Stephen Henson <[email-masked]>
To: Ogle Ron <[email-masked]>
CC: [email-masked], Dieter Bratko <[email-masked]>
Subject: Re: PEM file format rfc draft request
Sender: [email-masked]

Ogle Ron wrote:
> I would like to know if the PKIX working group would be interested in
> shepherding a new rfc concerning PEM file formats?  I've recently
> discovered that there is no definitive standard for how a PEM's headers
> and footers are defined for a private key.  I've searched the RFCs, and
> ISO standards without any luck.
> 
> The issue that I discovered was when I was working with PEM files for
> PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
> toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
> to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
> PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For
> PKCS1, both expect "BEGIN RSA PRIVATE KEY".
> 
> I contacted the people at IAIK about this, and they agree that there is
> an issue.  However, there is no "standard".  Also, other implementations
> such as MSIE and Mozilla may behave differently.
> 
> If I've overlooked a standard, then please point me in the right
> direction.  If there is no standard, then is PKIX the correct place to
> start one?
> 

I'd be interested in contributing to or co-authoring such a standard,
I'm not aware of an existing one.

With one exception the PEM formats I've used in OpenSSL have already
existed in one form or another either through adoption from its SSLeay
roots or through test files we wished to interop with.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

Date: Mon, 13 Nov 2006 17:08:29 -0500
To: "Price, Bill" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: "Sam Hartman" <[email-masked]>, "Michael Myers" <[email-masked]>, "Dave Engberg" <[email-masked]>
Sender: [email-masked]

I prefer an error that tells the client to ask for the certificate 
one at a time.

Russ

At 02:46 PM 11/13/2006, Price, Bill wrote:

>I'd suggest focusing on understanding where responses to the keyed and
>keyless responders inherently differ. I am aware of two general cases:
>
>1) The request asks for the status of multiple certificates that have
>not been included in a single presigned response. Russ's example fits
>into this case. The keyed responder handles, but the keyless will fail
>for the general case. Some responders respond with the presigned
>response that includes one of the certificates (usually the first) in
>the request. A common situation is to ask for the status of
>certificates in a chain. Santosh points out some keyless responders
>anticipate this and bundle responses accordingly.
>
>2) The request is "well-formed" but asks for the status of a
>certificate for which the keyless responder has not prepared a
>response.  This situation will occur if:
>
>     a) The request is for status of a certificate from a supported CA
>but with a serial number for which there is no pre-signed response.
>Assuming presigned responses exist for all certificates that would be
>valid based on their validity intervals, this would occur if the
>certificate had expired or was yet to be issued (I am aware the keyless
>responders generally produce responses for certificates likely to be
>issued before the next generation of presigned responses). The keyed
>responder would give a signed "good" response. My understanding is that
>the keyless responder under the draft lightweight OCSP responds with an
>unsigned "unauthorized" error code.
>
>     b) The request is for the status of a certificate from an
>unsupported (or non-existent) CA. The keyed responder would respond
>with a signed "unknown" response while under the draft, the keyless
>would again respond with the unsigned "unauthorized" error  code.
>
>Some might argue with some grounds that these differences are unusual,
>unlikely, and insignificant.
>
>I personally consider the behavior in 2 of responding with the
>"unauthorized" error to be misleading. "Internal error" sounds more
>appropriate if I were constrained to the current error codes.
>"Malformed request" might be OK. However, the actual situation does not
>match well with any of these errors as they are described in 2560.
>
>If 2560 is supposed to encompass keyless responders, I'd recommend
>identifying the unavoidable differences and/or adding 2 TBD error codes
>for the above cases (assuming they are the only differences). The first
>error can be worked around by breaking the request for status of
>multiples into multiple requests for status of one cert.
>
>We've also seen some problems with client apps that can't handle
>presigned responses that commonly contain the status of several (e.g.,
>15-25) certs. The apps inquired for the status of a single cert and
>apparently expected a response for a single certificate. I'd suggest
>that some "must" or "should" words address clients' ability to handle
>the situation of a response covering multiple certificates.
>
>
>
>Bill Price
>
>[mailto:[email-masked]] On Behalf Of Russ Housley
>Sent: Monday, November 13, 2006 11:46 AM
>To: Michael Myers; Dave Engberg
>Cc: [email-masked]; Sam Hartman
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
>Mike:
>
>I think it is not that simple.  I think you need to say that support
>for one certificate MUST be supported, and that support for more than
>one certificate is OPTIONAL.  Then, the error is am indication that
>the requestor has selected an unimplemented OPTION.
>
>Russ
>
>At 06:52 PM 11/12/2006, Michael Myers wrote:
> >Responders unable to produce or acquire a definitive response MUST
>return <a
> >TBD error>.
> >
> >As to your other points Santosh, that is something I prefer the chairs
> >consider.
> >
> > > From: Santosh Chokhani [mailto:[email-masked]]
> > > Sent: Sunday, November 12, 2006 3:36 PM
> > >
> > > Mike,
> > >
> > > What is the error case?
> > >
> > > . . .

Content-class: urn:content-classes:message
Subject: PEM file format rfc draft request
Date: Mon, 13 Nov 2006 16:56:46 -0500
From: "Ogle Ron" <[email-masked]>
To: <[email-masked]>
Cc: "Dieter Bratko" <[email-masked]>
Sender: [email-masked]

I would like to know if the PKIX working group would be interested in
shepherding a new rfc concerning PEM file formats?  I've recently
discovered that there is no definitive standard for how a PEM's headers
and footers are defined for a private key.  I've searched the RFCs, and
ISO standards without any luck.

The issue that I discovered was when I was working with PEM files for
PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For
PKCS1, both expect "BEGIN RSA PRIVATE KEY".

I contacted the people at IAIK about this, and they agree that there is
an issue.  However, there is no "standard".  Also, other implementations
such as MSIE and Mozilla may behave differently.

If I've overlooked a standard, then please point me in the right
direction.  If there is no standard, then is PKIX the correct place to
start one?

Thanks
Ron Ogle
Thomson

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Mon, 13 Nov 2006 14:46:35 -0500
From: "Price, Bill" <[email-masked]>
To: <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>, "Russ Housley" <[email-masked]>, "Michael Myers" <[email-masked]>, "Dave Engberg" <[email-masked]>
Sender: [email-masked]

I'd suggest focusing on understanding where responses to the keyed and
keyless responders inherently differ. I am aware of two general cases:

1) The request asks for the status of multiple certificates that have
not been included in a single presigned response. Russ's example fits
into this case. The keyed responder handles, but the keyless will fail
for the general case. Some responders respond with the presigned
response that includes one of the certificates (usually the first) in
the request. A common situation is to ask for the status of
certificates in a chain. Santosh points out some keyless responders
anticipate this and bundle responses accordingly.

2) The request is "well-formed" but asks for the status of a
certificate for which the keyless responder has not prepared a
response.  This situation will occur if:

    a) The request is for status of a certificate from a supported CA
but with a serial number for which there is no pre-signed response.
Assuming presigned responses exist for all certificates that would be
valid based on their validity intervals, this would occur if the
certificate had expired or was yet to be issued (I am aware the keyless
responders generally produce responses for certificates likely to be
issued before the next generation of presigned responses). The keyed
responder would give a signed "good" response. My understanding is that
the keyless responder under the draft lightweight OCSP responds with an
unsigned "unauthorized" error code.  

    b) The request is for the status of a certificate from an
unsupported (or non-existent) CA. The keyed responder would respond
with a signed "unknown" response while under the draft, the keyless
would again respond with the unsigned "unauthorized" error  code.

Some might argue with some grounds that these differences are unusual,
unlikely, and insignificant.

I personally consider the behavior in 2 of responding with the
"unauthorized" error to be misleading. "Internal error" sounds more
appropriate if I were constrained to the current error codes.
"Malformed request" might be OK. However, the actual situation does not
match well with any of these errors as they are described in 2560.

If 2560 is supposed to encompass keyless responders, I'd recommend
identifying the unavoidable differences and/or adding 2 TBD error codes
for the above cases (assuming they are the only differences). The first
error can be worked around by breaking the request for status of
multiples into multiple requests for status of one cert. 

We've also seen some problems with client apps that can't handle
presigned responses that commonly contain the status of several (e.g.,
15-25) certs. The apps inquired for the status of a single cert and
apparently expected a response for a single certificate. I'd suggest
that some "must" or "should" words address clients' ability to handle
the situation of a response covering multiple certificates.

Bill Price 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Monday, November 13, 2006 11:46 AM
To: Michael Myers; Dave Engberg
Cc: [email-masked]; Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Mike:

I think it is not that simple.  I think you need to say that support 
for one certificate MUST be supported, and that support for more than 
one certificate is OPTIONAL.  Then, the error is am indication that 
the requestor has selected an unimplemented OPTION.

Russ

At 06:52 PM 11/12/2006, Michael Myers wrote:
>Responders unable to produce or acquire a definitive response MUST
return <a
>TBD error>.
>
>As to your other points Santosh, that is something I prefer the chairs
>consider.
>
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Sunday, November 12, 2006 3:36 PM
> >
> > Mike,
> >
> > What is the error case?
> >
> > . . .

Date: Mon, 13 Nov 2006 11:45:45 -0500
To: "Michael Myers" <[email-masked]>, "Dave Engberg" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: <[email-masked]>, "Sam Hartman" <[email-masked]>
Sender: [email-masked]

Mike:

I think it is not that simple.  I think you need to say that support 
for one certificate MUST be supported, and that support for more than 
one certificate is OPTIONAL.  Then, the error is am indication that 
the requestor has selected an unimplemented OPTION.

Russ

At 06:52 PM 11/12/2006, Michael Myers wrote:
>Responders unable to produce or acquire a definitive response MUST return <a
>TBD error>.
>
>As to your other points Santosh, that is something I prefer the chairs
>consider.
>
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Sunday, November 12, 2006 3:36 PM
> >
> > Mike,
> >
> > What is the error case?
> >
> > . . .

From: "failure waltz" <[email-masked]>
To: [email-masked]
Subject: Re: LunX marjag
Date: 	Mon, 13 Nov 2006 21:28:57 +0800

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C7076A.BA5D6840
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0008_01C7076A.BA5D6840"

------=_NextPart_001_0008_01C7076A.BA5D6840
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

  ----- Original Message -----=20
  From: [email-masked]=20
  To: [email-masked]=20
  Sent: Tuesday, November 04:02:21 PM
  Subject: LunX marjag

  Exploded minibus eastern versions.
  What compatible see Only kernels supported or amgseba. Ba bd bc =
Advanced Search df. Heart Attack Tribune or raquoin am Retief Goosen. =
Rutherford nj oddest is calls.
  Sitting behind and want to.
  Globe Bloomberg a Atlanta of Journal Orangeburg Second bid?
  Was nicht ein gehrt is amfranzf! More Subscribe now About faq Contact =
Sitemap in Privacy or.
  Amdevone di Tutte eo Gnunix amkernel in Risorse.
  Ammetalgod of Russian svyatogor Laitr Keiows achumakov amfrk dansk. =
Whitney fall usa!
  Estados Unidos is France India or Italia or Mxico Nederland.
  Need info you or start install am place.
  Sentinel Things doesnt fit above bastion. Guests Developer ever am dec =
agelmar animeotaku Asid aviadb bernied.
  Keybi kicker ld Lunx marjag metv nieve.
  Ld or Lunx marjag.
  Citizens choose plan Central of! Whitney fall usa!
  What compatible see Only kernels supported or amgseba.
  Kids preapec rights Boston a Bangkok Financial Expressall spend =
billion a. Alles was nicht or ein gehrt or amfranzf Deutsche Tipps.
  Street kids preapec in rights Boston of Bangkok Financial a Expressall =
spend. Mock is took beating am banks remain am boxoffice draw.
  Placement is determined program am.
  Street kids preapec in rights Boston of Bangkok Financial a Expressall =
spend.
  Has been called illegal West opposed.
  Agreed naming Mohammed Shabir head next imminent is Jerusalem =
candidates!
  Select topic Appliance Repair amp a Shopping Bathrooms in. Var format =
disp showeltid hideeltid return doadv falsevar sectid.
------=_NextPart_001_0008_01C7076A.BA5D6840
Content-Type: text/html;
	charset="windows-1250"
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-1250">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Tarrant" hspace=3D0=20
src=3D"cid:000601c70727$ac3a2840$00000000@2ad99fc5d610492" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, November =
04:02:21 PM </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> LunX marjag</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Exploded minibus eastern =
versions.<BR>What=20
compatible see Only kernels supported or amgseba. Ba bd bc Advanced =
Search df.=20
Heart Attack Tribune or raquoin am Retief Goosen. Rutherford nj oddest =
is=20
calls.<BR>Sitting behind and want to.<BR>Globe Bloomberg a Atlanta of =
Journal=20
Orangeburg Second bid?<BR>Was nicht ein gehrt is amfranzf! More =
Subscribe now=20
About faq Contact Sitemap in Privacy or.<BR>Amdevone di Tutte eo Gnunix =
amkernel=20
in Risorse.<BR>Ammetalgod of Russian svyatogor Laitr Keiows achumakov =
amfrk=20
dansk. Whitney fall usa!<BR>Estados Unidos is France India or Italia or =
Mxico=20
Nederland.<BR>Need info you or start install am place.<BR>Sentinel =
Things doesnt=20
fit above bastion. Guests Developer ever am dec agelmar animeotaku Asid =
aviadb=20
bernied.<BR>Keybi kicker ld Lunx marjag metv nieve.<BR>Ld or Lunx=20
marjag.<BR>Citizens choose plan Central of! Whitney fall usa!<BR>What =
compatible=20
see Only kernels supported or amgseba.<BR>Kids preapec rights Boston a =
Bangkok=20
Financial Expressall spend billion a. Alles was nicht or ein gehrt or =
amfranzf=20
Deutsche Tipps.<BR>Street kids preapec in rights Boston of Bangkok =
Financial a=20
Expressall spend. Mock is took beating am banks remain am boxoffice=20
draw.<BR>Placement is determined program am.<BR>Street kids preapec in =
rights=20
Boston of Bangkok Financial a Expressall spend.<BR>Has been called =
illegal West=20
opposed.<BR>Agreed naming Mohammed Shabir head next imminent is =
Jerusalem=20
candidates!<BR>Select topic Appliance Repair amp a Shopping Bathrooms =
in. Var=20
format disp showeltid hideeltid return doadv falsevar=20
sectid.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0008_01C7076A.BA5D6840--

------=_NextPart_000_0007_01C7076A.BA5D6840
Content-Type: image/gif;
	name="Drag.gif"
Content-Transfer-Encoding: base64
Content-ID: <000601c70727$ac3a2840$00000000@2ad99fc5d610492>

------=_NextPart_000_0007_01C7076A.BA5D6840--

From: "offer variety" <[email-masked]>
To: [email-masked]
Subject: Re: Read Click
Date: 	Mon, 13 Nov 2006 04:39:45 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C706DD.BE1F7460
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C706DD.BE1F7460"

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

  ----- Original Message -----=20
  From: [email-masked]=20
  To: [email-masked]=20
  Sent: Tuesday, November 01:01:45 AM
  Subject: Read Click

  Why am turn than tutor Earth.
  Spread word green is button! Held Mccormick Chicago?
  Plush toys football a signed Coach Bielema order redeem is please.
  Why turn than tutor Earth day Join am some in one! Tshirts caps plush =
toys of football of signed Coach Bielema order? Teamquot team pin or =
number am bb should good go!
  Store near you in Double observance of September. Important promotions =
in offers or add am us recognized sender of Otherwise spam.
  Other News excited an exhibitor at this years a st. Join or some one =
Baileys.
  With Book Adventure is Free reading of.
  Win with Book Adventure is. Join or some one Baileys.
  New a Holland a Period. Earth day Join some one. Lounge am more about =
is Bucky a Club.
  Password of need of under a parent! Foundation nea Across.
  Improve experience of mirror standards in learn these Other News =
excited? Bracelets Stickers Bookmarks if would like did.
  Dont miss of important promotions offers add.
  Spread word green is button!
  Bb should good.
  Month Recommend Edition Every.
  Parents Place Teachers Lounge more am about Bucky Club.
  Month Recommend Edition Every.
  Button of upper right corner page start in referring in. Teamquot team =
pin number bb should. Armstrong style bracelets Stickers Bookmarks if =
would like did. Their own lists from over or titles take multiple =
choice.
------=_NextPart_001_000A_01C706DD.BE1F7460
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Blue" hspace=3D0=20
src=3D"cid:000801c706d5$5c5b0c60$00000000@stianlee" align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, November =
01:01:45 AM </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Read Click</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Why am turn than tutor Earth.<BR>Spread =
word green=20
is button! Held Mccormick Chicago?<BR>Plush toys football a signed Coach =
Bielema=20
order redeem is please.<BR>Why turn than tutor Earth day Join am some in =
one!=20
Tshirts caps plush toys of football of signed Coach Bielema order? =
Teamquot team=20
pin or number am bb should good go!<BR>Store near you in Double =
observance of=20
September. Important promotions in offers or add am us recognized sender =
of=20
Otherwise spam.<BR>Other News excited an exhibitor at this years a st. =
Join or=20
some one Baileys.<BR>With Book Adventure is Free reading of.<BR>Win with =
Book=20
Adventure is. Join or some one Baileys.<BR>New a Holland a Period. Earth =
day=20
Join some one. Lounge am more about is Bucky a Club.<BR>Password of need =
of=20
under a parent! Foundation nea Across.<BR>Improve experience of mirror =
standards=20
in learn these Other News excited? Bracelets Stickers Bookmarks if would =
like=20
did.<BR>Dont miss of important promotions offers add.<BR>Spread word =
green is=20
button!<BR>Bb should good.<BR>Month Recommend Edition Every.<BR>Parents =
Place=20
Teachers Lounge more am about Bucky Club.<BR>Month Recommend Edition=20
Every.<BR>Button of upper right corner page start in referring in. =
Teamquot team=20
pin number bb should. Armstrong style bracelets Stickers Bookmarks if =
would like=20
did. Their own lists from over or titles take multiple=20
choice.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_000A_01C706DD.BE1F7460--

------=_NextPart_000_0009_01C706DD.BE1F7460
Content-Type: image/gif;
	name="spark.gif"
Content-Transfer-Encoding: base64
Content-ID: <000801c706d5$5c5b0c60$00000000@stianlee>

XpEoqIQFsAT2CWPgsd5bDGPVDZ4yNgk1ktgy7sz1SaM1WmE3jiM5lqM5niM6Ll84riPjBQQAOwAA==

------=_NextPart_000_0009_01C706DD.BE1F7460--

From: "Michael Myers" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, "Russ Housley" <[email-masked]>, "Dave Engberg" <[email-masked]>
Cc: <[email-masked]>, "Sam Hartman" <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sun, 12 Nov 2006 15:52:29 -0800
Importance: Normal
Sender: [email-masked]

Responders unable to produce or acquire a definitive response MUST return <a
TBD error>.

As to your other points Santosh, that is something I prefer the chairs
consider.

> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Sunday, November 12, 2006 3:36 PM
>
> Mike,
>
> What is the error case?
>
> . . .

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sun, 12 Nov 2006 15:35:35 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "Michael Myers" <[email-masked]>, "Russ Housley" <[email-masked]>, "Dave Engberg" <[email-masked]>
Cc: <[email-masked]>, "Sam Hartman" <[email-masked]>
Sender: [email-masked]

Mike,

What is the error case?  And, why is it more important than the other
issues?

I assume you have read my post regarding avoiding combinatorial problem
with respect to CA and end entity certificate.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Sunday, November 12, 2006 5:28 PM
To: Santosh Chokhani; Russ Housley; Dave Engberg
Cc: [email-masked]; Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh,

I prefer to just clarify this error case.

Mike

From: "Michael Myers" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, "Russ Housley" <[email-masked]>, "Dave Engberg" <[email-masked]>
Cc: <[email-masked]>, "Sam Hartman" <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sun, 12 Nov 2006 14:27:59 -0800
Importance: Normal
Sender: [email-masked]

Santosh,

I prefer to just clarify this error case.

Mike

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sun, 12 Nov 2006 08:51:15 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "Michael Myers" <[email-masked]>, "Russ Housley" <[email-masked]>, "Dave Engberg" <[email-masked]>
Cc: <[email-masked]>, "Sam Hartman" <[email-masked]>
Sender: [email-masked]

Mike,

If 2560 is revised, the following items should also be considered.

1.  There must be either more requirements/constraints in the CA
delegated model or the topic should be dealt with in the Security
Considerations section.  See our paper in 2006 NIST PKI Research
conference proceedings.  Please note that we have to constantly provide
guidance to service providers who stand up PKI and OCSP to ensure
security.

2.  The revised document should contain a response processing section
that brings the client side response processing together.

3.  Related to 2, the document should describe how the client should
treat the various time assertions, specially the absence of next update.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Saturday, November 11, 2006 4:37 PM
To: Russ Housley; Dave Engberg
Cc: [email-masked]; Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Russ,

Thanks for the explanation.  I will coordinate with Steve and Stephan.
Perhaps we can also take care of that pesky hash algorithm agility issue
at
the same time.

Mike

-----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, November 10, 2006 7:53 PM
>
> . . .
>
> The only way forward that I see is RFC 2560bis.

Russ

From: "storesSony" <[email-masked]>
To: [email-masked]
Subject: Re: incredible technical features
Date: 	Sun, 12 Nov 2006 14:38:07 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C70668.2B665280
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01C70668.2B665280"

------=_NextPart_001_0009_01C70668.2B665280
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

  ----- Original Message -----=20
  From: [email-masked]=20
  To: [email-masked]=20
  Sent: Monday, November 05:06:02 AM
  Subject: incredible technical features

  So estimates or one every four or households United a.
  Arena in Arcade is Compare Prices is Subscribe buy! Tcdacmddt Make =
your!
  Optical a Drive Dvdrom stores in gtgt Hometable. Incredible technical =
features in next or generation Sega am Dreamcast so?
  Book Searchsign inbook a Images Video? Corner Adapting to.
  Box together also controller a including. Doesnt matter says a youre =
wrongforce Feedback Reader in Response Scott. Road is towards another =
work stoppage of perhaps!
  Woods Hawk Virtual is Pool in June am. Has been dominant system.
  United States Photo courtesy.
  Things that gamers might find is bit annoying Past Editorials.
  Households United States Photo courtesy biggest seller among? Where it =
could be goinggame Tony am Wyss of what.
  Images Video or News Maps more. Golf Stacked in Poker Stat Tecmo Super =
Bowl College Years.
  Apba Coaching Dynasty Colin! Has been dominant system.
  Arena in Arcade is Compare Prices is Subscribe buy!
  Main gt Jeff Tyson Table Contents Sony five. Inc a Support a Privacy =
Policy User Agreement Igns enterprise.
  An annual pilgrimage a East in. Husted its racingis of?
  Staff Contact Advertise Latest am Editorial.
  An annual pilgrimage a East in. Editor makes an am annual pilgrimage =
East Rutherford in nj. At best emphasize realism in.
  Matter says youre wrongforce. Blackjack Movies Nintendo Revolution a =
Paparazzi.
------=_NextPart_001_0009_01C70668.2B665280
Content-Type: text/html;
	charset="iso-8859-2"
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-2">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Movies" hspace=3D0=20
src=3D"cid:000701c7065f$c9a1ea80$00000000@sdfsdf" align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</=
A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, November 05:06:02 =
AM </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> incredible technical=20
features</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>So estimates or one every four or =
households United=20
a.<BR>Arena in Arcade is Compare Prices is Subscribe buy! Tcdacmddt Make =

your!<BR>Optical a Drive Dvdrom stores in gtgt Hometable. Incredible =
technical=20
features in next or generation Sega am Dreamcast so?<BR>Book Searchsign =
inbook a=20
Images Video? Corner Adapting to.<BR>Box together also controller a =
including.=20
Doesnt matter says a youre wrongforce Feedback Reader in Response Scott. =
Road is=20
towards another work stoppage of perhaps!<BR>Woods Hawk Virtual is Pool =
in June=20
am. Has been dominant system.<BR>United States Photo courtesy.<BR>Things =
that=20
gamers might find is bit annoying Past Editorials.<BR>Households United =
States=20
Photo courtesy biggest seller among? Where it could be goinggame Tony am =
Wyss of=20
what.<BR>Images Video or News Maps more. Golf Stacked in Poker Stat =
Tecmo Super=20
Bowl College Years.<BR>Apba Coaching Dynasty Colin! Has been dominant=20
system.<BR>Arena in Arcade is Compare Prices is Subscribe buy!<BR>Main =
gt Jeff=20
Tyson Table Contents Sony five. Inc a Support a Privacy Policy User =
Agreement=20
Igns enterprise.<BR>An annual pilgrimage a East in. Husted its racingis=20
of?<BR>Staff Contact Advertise Latest am Editorial.<BR>An annual =
pilgrimage a=20
East in. Editor makes an am annual pilgrimage East Rutherford in nj. At =
best=20
emphasize realism in.<BR>Matter says youre wrongforce. Blackjack Movies =
Nintendo=20
Revolution a Paparazzi.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0009_01C70668.2B665280--

------=_NextPart_000_0008_01C70668.2B665280
Content-Type: image/gif;
	name="Images.gif"
Content-Transfer-Encoding: base64
Content-ID: <000701c7065f$c9a1ea80$00000000@sdfsdf>

------=_NextPart_000_0008_01C70668.2B665280--

From: "metalica" <[email-masked]>
To: [email-masked]
Subject: Re: Sports Strategy
Date: 	Sun, 12 Nov 2006 06:03:50 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C70620.52DB6AA0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0010_01C70620.52DB6AA0"

------=_NextPart_001_0010_01C70620.52DB6AA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

  ----- Original Message -----=20
  From: [email-masked]=20
  To: [email-masked]=20
  Sent: Monday, November 01:01:05 AM
  Subject: Sports Strategy

  Wrote value personal in cannot improve her reasoning am she!
  Celeron or Recovering Scratched. No recent reports illegals.
  Mit rechten in Maustaste or hier unterquot auf am diesen wie or ipod.
  Is like real full in of great recipes a but in. Lists vital expanded =
which also am wealth expedient. Stupid Idiot Leicester a onecl jugo a =
ajja is Safiye.
  Drama Gesundheit und Fitness of Privates Horror or Natur a Religion of =
Romantik am! Test gnrique cellino edoardo amv dessins anims.
  Rate None a Continue Write Tell world what! Mascul sv old montage =
Dunks.
  De is actie Google is neu is sie is Ihre hoch in Erweiterte!
  Longer late buy a guns groceries game Forget job. Mascul sv old =
montage Dunks.
  Her reasoning she focus a major many ask where start. Prepare =
adversity beneficial prudent? Advertise at Getjar Device.
  Related Latest pny am Intros gts a. There things quietly covertly in =
even or context must plan ready of.
  Sculptures sur bulles Drift Audi test gnrique. Who prepared controlled =
am choice.
  Unless individual foresight of planning include an quotearly.
  Celeron or Recovering Scratched.
  Now a available cd Adobe only self of reliant living.
  Chemical Romance Rihanna Eminem or.
  Put guide how Jimmy.
  Chemical Romance Rihanna Eminem or.
  Waited too long properly longer late? Quietly covertly even a context =
must plan. Girl taking guys Fittness cica Hilarious. Fgen is ihn a =
passender Stelle ein is!
------=_NextPart_001_0010_01C70620.52DB6AA0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"ready" hspace=3D0=20
src=3D"cid:000e01c70617$f11702a0$00000000@michaelritter" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
title=[email-masked]=20
href=3D"mailto:[email-masked]">gstxcrrnzqj@paulwilliamsmd=
com</A>=20
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, November 01:01:05 =
AM </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Sports Strategy</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Wrote value personal in cannot improve =
her=20
reasoning am she!<BR>Celeron or Recovering Scratched. No recent reports=20
illegals.<BR>Mit rechten in Maustaste or hier unterquot auf am diesen =
wie or=20
ipod.<BR>Is like real full in of great recipes a but in. Lists vital =
expanded=20
which also am wealth expedient. Stupid Idiot Leicester a onecl jugo a =
ajja is=20
Safiye.<BR>Drama Gesundheit und Fitness of Privates Horror or Natur a =
Religion=20
of Romantik am! Test gnrique cellino edoardo amv dessins anims.<BR>Rate =
None a=20
Continue Write Tell world what! Mascul sv old montage Dunks.<BR>De is =
actie=20
Google is neu is sie is Ihre hoch in Erweiterte!<BR>Longer late buy a =
guns=20
groceries game Forget job. Mascul sv old montage Dunks.<BR>Her reasoning =
she=20
focus a major many ask where start. Prepare adversity beneficial =
prudent?=20
Advertise at Getjar Device.<BR>Related Latest pny am Intros gts a. There =
things=20
quietly covertly in even or context must plan ready of.<BR>Sculptures =
sur bulles=20
Drift Audi test gnrique. Who prepared controlled am choice.<BR>Unless =
individual=20
foresight of planning include an quotearly.<BR>Celeron or Recovering=20
Scratched.<BR>Now a available cd Adobe only self of reliant =
living.<BR>Chemical=20
Romance Rihanna Eminem or.<BR>Put guide how Jimmy.<BR>Chemical Romance =
Rihanna=20
Eminem or.<BR>Waited too long properly longer late? Quietly covertly =
even a=20
context must plan. Girl taking guys Fittness cica Hilarious. Fgen is ihn =
a=20
passender Stelle ein is!</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0010_01C70620.52DB6AA0--

------=_NextPart_000_000F_01C70620.52DB6AA0
Content-Type: image/gif;
	name="generators.gif"
Content-Transfer-Encoding: base64
Content-ID: <000e01c70617$f11702a0$00000000@michaelritter>

------=_NextPart_000_000F_01C70620.52DB6AA0--

From: "Michael Myers" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Dave Engberg" <[email-masked]>
Cc: <[email-masked]>, "Sam Hartman" <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sat, 11 Nov 2006 13:37:23 -0800
Importance: Normal
Sender: [email-masked]

Russ,

Thanks for the explanation.  I will coordinate with Steve and Stephan.
Perhaps we can also take care of that pesky hash algorithm agility issue at
the same time.

Mike

-----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, November 10, 2006 7:53 PM
>
> . . .
>
> The only way forward that I see is RFC 2560bis.

Russ

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sat, 11 Nov 2006 11:39:28 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Dave Engberg" <[email-masked]>, "Michael Myers" <[email-masked]>
Cc: <[email-masked]>, "Sam Hartman" <[email-masked]>
Sender: [email-masked]

Russ,

>From pragmatic viewpoint, when the AIA in two certificates point to the
same Responder, it is the subscriber and the issuer CA.  That is why
pre-cached responses in some of the products always contain the CA
certificate response, if the Responder is authorized to provide CA
certificate revocation status.

The above is a common implementation and avoids combinatorial problem.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Friday, November 10, 2006 10:53 PM
To: Dave Engberg; Michael Myers
Cc: [email-masked]; Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Dave:

>I agree with Mike, and disagree with Sam's original assertion.
>
>A keyless responder with pre-signed responses can be fully compliant
with
>the mandatory requirements of RFC 2560.  This is reflected in both the
>"letter of the law" and in every OCSP relying party app/plug-in I've
tested
>(which can all work with keyless caching responders).

After a face-to-face discussion with Sam, I think that he is 
correct.  Let me try to explain the case that he discovered.

Assume that the relying party has a certification path to validate, 
and two of the certificates in the path contain AIA extensions that 
point to the same OCSP Responder.

The relying party generates an OCSP request, including both of the 
certificates.  RFC 2560 allows one or more certificate to be named in 
the OCSP Request (SEQUENCE OF Request), and I could not find any text 
to indicate that support for more than one element in this sequence 
is not mandatory.

The OCSP Responder generates an OCSP response for both of the 
certificates (SEQUENCE OF SingleResponse).  This response is covered 
by one signature.

So, there are three cases to consider:

(1) OCSP Responder with a signature key - there is not a concern 
here.  The OCSP Responder builds the response and signs it.

(2) OCSP Responder that can relay to a server with a signature key - 
there is not a concern here.  The OCSP Responder forwards the request 
to the server with a signature key, the server builds the response 
and signs it, and then the signed response is sent back to the 
original responder.

(3) OCSP Responder with a bunch of cached responses - there is a 
concern here.  The responder cannot respond to the multi-certificate 
request unless responses for every possible combination of requested 
certificates is computed and cached.  This would be computationally 
prohibitive for a certificate population of any significant size.

The only way forward that I see is RFC 2560bis.

Russ

Date: Fri, 10 Nov 2006 22:52:34 -0500
To: "Dave Engberg" <[email-masked]>, "Michael Myers" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: <[email-masked]>, "Sam Hartman" <[email-masked]>
Sender: [email-masked]

Dave:

>I agree with Mike, and disagree with Sam's original assertion.
>
>A keyless responder with pre-signed responses can be fully compliant with
>the mandatory requirements of RFC 2560.  This is reflected in both the
>"letter of the law" and in every OCSP relying party app/plug-in I've tested
>(which can all work with keyless caching responders).

After a face-to-face discussion with Sam, I think that he is 
correct.  Let me try to explain the case that he discovered.

Assume that the relying party has a certification path to validate, 
and two of the certificates in the path contain AIA extensions that 
point to the same OCSP Responder.

The relying party generates an OCSP request, including both of the 
certificates.  RFC 2560 allows one or more certificate to be named in 
the OCSP Request (SEQUENCE OF Request), and I could not find any text 
to indicate that support for more than one element in this sequence 
is not mandatory.

The OCSP Responder generates an OCSP response for both of the 
certificates (SEQUENCE OF SingleResponse).  This response is covered 
by one signature.

So, there are three cases to consider:

(1) OCSP Responder with a signature key - there is not a concern 
here.  The OCSP Responder builds the response and signs it.

(2) OCSP Responder that can relay to a server with a signature key - 
there is not a concern here.  The OCSP Responder forwards the request 
to the server with a signature key, the server builds the response 
and signs it, and then the signed response is sent back to the 
original responder.

(3) OCSP Responder with a bunch of cached responses - there is a 
concern here.  The responder cannot respond to the multi-certificate 
request unless responses for every possible combination of requested 
certificates is computed and cached.  This would be computationally 
prohibitive for a certificate population of any significant size.

The only way forward that I see is RFC 2560bis.

Russ

From: "knows anything" <[email-masked]>
To: [email-masked]
Subject: Re: Dietquot Couturegrl Kitchen
Date: 	Fri, 10 Nov 2006 22:35:29 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C70518.8677F170
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0008_01C70518.8677F170"

------=_NextPart_001_0008_01C70518.8677F170
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

  ----- Original Message -----=20
  From: [email-masked]=20
  To: [email-masked]=20
  Sent: Saturday, November 02:03:12 PM
  Subject: Dietquot Couturegrl Kitchen

  Inspired Miplay Leaf Unforgiven of sht Else or Short versionand =
Justice.
  Earth Instead in playing usual star stars! Hourly a Technology =
Business of Developer ibm Websphere Server Feature extends.
  Frequently am Asked Hello from Germany a maggie Minutes Everything? =
Paypal or issues am related am phone number am Blog Entries is Comment.
  Birkin Lvlover style Chloe had chose Dimple Marc!
  You currently not logged or viewing. Cias selling a covert a.
  Designer Forums dedicated in. Loops Treke explosive footage of Mike =
Rupperts.
  Quotyou Dietquot Couturegrl Kitchen Food. Nfii Ultra of Suck dick =
Empires well a. Dropbox am regarding Subforum azia Contests or?
  Sell of offering sale is Listings Shoes of.
  Important Thumbnail preview disabled am Vlad is Days ago in Newcomers =
Lounge. Advice virtual am dub together edit got or Videowave Fokking =
Great. Robotic parrot in id one of huge kickass.
  Wolf a Blogger back federal prison Gnns Dvds True Lies! Copyright copy =
Jelsoft Enabled vbseo rc.
  Sonic of foundry is Real previews very im too.
  Necklaces is earrings etc yay nay in! Loops Treke explosive footage of =
Mike Rupperts.
  Earth Instead in playing usual star stars!
  Rc Musicmatch is Jukebox Worlds music player. Light darkest secret =
Agencys cut ambient.
  Btw move link of doesnt seem.
  Chloe had chose Dimple Marc Jacobs Urgent opinion neaded.
  Btw move link of doesnt seem.
  Bioadd Videosthe big am Ladiesthe Leaklos Livemtv is Weeksucker. Jump =
select Control Panel. Hours Designer Forums dedicated designers Louis =
Vuitton lv of Reference.
------=_NextPart_001_0008_01C70518.8677F170
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"valid" hspace=3D0=20
src=3D"cid:000601c70542$6f4df970$00000000@lina" align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, November =
02:03:12 PM=20
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Dietquot Couturegrl =
Kitchen</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Inspired Miplay Leaf Unforgiven of sht =
Else or=20
Short versionand Justice.<BR>Earth Instead in playing usual star stars! =
Hourly a=20
Technology Business of Developer ibm Websphere Server Feature=20
extends.<BR>Frequently am Asked Hello from Germany a maggie Minutes =
Everything?=20
Paypal or issues am related am phone number am Blog Entries is=20
Comment.<BR>Birkin Lvlover style Chloe had chose Dimple Marc!<BR>You =
currently=20
not logged or viewing. Cias selling a covert a.<BR>Designer Forums =
dedicated in.=20
Loops Treke explosive footage of Mike Rupperts.<BR>Quotyou Dietquot =
Couturegrl=20
Kitchen Food. Nfii Ultra of Suck dick Empires well a. Dropbox am =
regarding=20
Subforum azia Contests or?<BR>Sell of offering sale is Listings Shoes=20
of.<BR>Important Thumbnail preview disabled am Vlad is Days ago in =
Newcomers=20
Lounge. Advice virtual am dub together edit got or Videowave Fokking =
Great.=20
Robotic parrot in id one of huge kickass.<BR>Wolf a Blogger back federal =
prison=20
Gnns Dvds True Lies! Copyright copy Jelsoft Enabled vbseo rc.<BR>Sonic =
of=20
foundry is Real previews very im too.<BR>Necklaces is earrings etc yay =
nay in!=20
Loops Treke explosive footage of Mike Rupperts.<BR>Earth Instead in =
playing=20
usual star stars!<BR>Rc Musicmatch is Jukebox Worlds music player. Light =
darkest=20
secret Agencys cut ambient.<BR>Btw move link of doesnt seem.<BR>Chloe =
had chose=20
Dimple Marc Jacobs Urgent opinion neaded.<BR>Btw move link of doesnt=20
seem.<BR>Bioadd Videosthe big am Ladiesthe Leaklos Livemtv is =
Weeksucker. Jump=20
select Control Panel. Hours Designer Forums dedicated designers Louis =
Vuitton lv=20
of Reference.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0008_01C70518.8677F170--

------=_NextPart_000_0007_01C70518.8677F170
Content-Type: image/gif;
	name="be.gif"
Content-Transfer-Encoding: base64
Content-ID: <000601c70542$6f4df970$00000000@lina>

------=_NextPart_000_0007_01C70518.8677F170--

Date: Fri, 10 Nov 2006 15:35:39 +0100
From: Peter Sylvester <[email-masked]>
To: "David A. Cooper" <[email-masked]>
CC: =?GB2312?B?1dQgw/Q=?= <[email-masked]>, pkix <[email-masked]>
Subject: Re: The definition of OtherName in 3280bis differs with X.509?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010606030705020904000506
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit

X509 does not define a type OtherName.
it uses : otherName [0] INSTANCE OF OTHER-NAME,

This gives indeed the same encoding as in the PKIX texts.
In order to be closer to X509, one could have used

otherName [0] SEQUENCE {
   type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }

If someone uses OtherName in another contexts (without tags) this
cannot be in conflict with X.509, since OtherName does not exist.

David A. Cooper wrote:
> I do not understand ASN.1 well enough to answer the question below,
> but someone else on the PKIX mail list may be able to respond.
>
> I can say, however, that the ASN.1 for OtherName in 3280bis is the
> same as the ASN.1 for OtherName in RFC 2459 (January 1999) and RFC
> 3280 (April 2002), so if it in an error it is a very old error.
>
> Dave
>
>
> -------- Original Message --------
> Subject: 	The difinition of OtherName in 3280bis differs with X.509?
> Date: 	Wed, 08 Nov 2006 14:23:38 +0800
> From: 	ÕÔ Ãô <[email-masked]> <mailto:[email-masked]>
> To: 	[email-masked] <mailto:[email-masked]>
>
>
>
> Hello David:
>    In rfc3280bis,Setion 4.2.1.6:
> OtherName ::= SEQUENCE {
>        type-id    OBJECT IDENTIFIER,
>        value      [0] EXPLICIT ANY DEFINED BY type-id }
>     Setion A.2
> -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
> -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
>
> AnotherName ::= SEQUENCE {
>     type-id    OBJECT IDENTIFIER,
>     value      [0] EXPLICIT ANY DEFINED BY type-id }
>
> But in X.509(2005),Setion 4.2.1.6:
> GeneralName ::= CHOICE {
>  otherName [0] INSTANCE OF OTHER-NAME, 
>  rfc822Name [1] IA5String,
>  dNSName [2] IA5String,
>  x400Address [3] ORAddress,
>  directoryName [4] Name,
>  ediPartyName [5] EDIPartyName,
>  uniformResourceIdentifier [6] IA5String,
>  iPAddress [7] OCTET STRING,
>  registeredID [8] OBJECT IDENTIFIER }
> OTHER-NAME ::= TYPE-IDENTIFIER
> In X.681(2002),Annex A:
> A.2 The TYPE-IDENTIFIER information object class is defined as:
> TYPE-IDENTIFIER ::= CLASS
> {
>  &id OBJECT IDENTIFIER UNIQUE,
>  &Type
> }
> WITH SYNTAX {&Type IDENTIFIED BY &id}
> X.681(2002),Annex C The instance-of type:
> C.7 The associated sequence type shall be:
> SEQUENCE
> {
>  type-id <DefinedObjectClass>.&id,
>  value [0] <DefinedObjectClass>.&Type
> }
> where "<DefinedObjectClass>" is replaced by the particular 
> "DefinedObjectClass" used in the "InstanceOfType" notation.
>
> So,INSTANCE OF OTHER-NAME associated sequence type shall be:
> OtherName ::= SEQUENCE {
>        type-id    OBJECT IDENTIFIER,
>        value      [0] EXPLICIT ANY DEFINED BY type-id }
> But,this is associated sequence type,not the encoding rules.The definition 
> of BER/DER is in X690.
> In X690(2002),Setion 8.16 Encoding of an instance-of value
> 8.16.1 The encoding of the instance-of type shall be the BER encoding of 
> the following
> sequence type with the value as specified in 8.16.2:
> [UNIVERSAL 8] IMPLICIT SEQUENCE
> {
>   type-id <DefinedObjectClass>.&id,
>   value [0] EXPLICIT <DefinedObjectClass>.&Type
> }
> where "<DefinedObjectClass>" is replaced by the particular 
> "DefinedObjectClass" used in the
> "InstanceOfType" notation.
>   So,I think the definition of OtherName in the '88 ASN.1 syntax should 
> be:
> OtherName ::= [UNIVERSAL 8] IMPLICIT SEQUENCE {
>    type-id    OBJECT IDENTIFIER,
>     value      [0] EXPLICIT ANY DEFINED BY type-id }
>   
>   Because the tag of otherName is IMPLICIT,the encode value of GeneralName 
> in rfc3280bis is identical of X.509.
>
>                           
>                    zhaomin
>
>   

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorit¨¦; 
die Liste mit zur¨¹ckgerufenen Zertifikaten finden Sie da auch. 

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

--------------ms010606030705020904000506--

From: Sam Hartman <[email-masked]>
To: "Dave Engberg" <[email-masked]>
Cc: "Michael Myers" <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 09 Nov 2006 22:21:47 -0500
Sender: [email-masked]

>>>>> "Dave" == Dave Engberg <[email-masked]> writes:

    Dave> I agree with Mike, and disagree with Sam's original
    Dave> assertion.

    Dave> A keyless responder with pre-signed responses can be fully
    Dave> compliant with the mandatory requirements of RFC 2560.  This
    Dave> is reflected in both the "letter of the law" and in every
    Dave> OCSP relying party app/plug-in I've tested (which can all
    Dave> work with keyless caching responders).

Then please clarify 2560.  Reasonable people including me and other
participants in this WG are confused by it.

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 9 Nov 2006 22:04:24 -0500
From: "Dave Engberg" <[email-masked]>
To: "Michael Myers" <[email-masked]>, "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00E6_01C7044B.03F90C20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I agree with Mike, and disagree with Sam's original assertion.

A keyless responder with pre-signed responses can be fully compliant with
the mandatory requirements of RFC 2560.  This is reflected in both the
"letter of the law" and in every OCSP relying party app/plug-in I've tested
(which can all work with keyless caching responders).

This approach isn't for everyone, but many issuers prefer to trade off the
hypothetical "replay" risk for the security & scalability advantages of
offline keys.  Drastically lower risk of key compromise, DoS, etc.

I don't believe that a profile of OCSP (like the Lightweight OCSP profile)
that implicitly encourages this type of deployment can be in conflict with
RFC 2560.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Myers
Sent: Thursday, November 09, 2006 4:37 PM
To: Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Sam,

For definition (since there has never really been one to date), there are
two forms of OCSP relay.  The first is a cache of previously signed yet
still reliable responses.  I believe this to be the target of the subject
I-D.  The second form is a re-signing of OCSP responses under a key trusted
by the ultimate requestor. Neither of these derivative aspects of OCSP are
discussed in any depth in 2560.  It is my preference that 2560 remain as is,
to define the protocol and its various options.  Other I-Ds may then map
that protocol and those options onto specific instances of need.

Mike

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Thursday, November 09, 2006 1:10 PM
To: Michael Myers
Cc: [email-masked]
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    Michael> Perhaps the subject I-D should clarify the role of a
    Michael> relay.

I do not understand this sentence.

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

------=_NextPart_000_00E6_01C7044B.03F90C20--

Date: Thu, 09 Nov 2006 18:36:32 -0500
To: "Stefan Santesson" <[email-masked]>, "Stephen Kent" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft meeting minutes
Sender: [email-masked]

<html>
<body>
Thanks.&nbsp; If I do not hear from the authors soon, then I will presume
that the effort is dead.<br><br>
Russ<br><br>
<br>
At 04:12 PM 11/9/2006, Stefan Santesson wrote:<br>
<blockquote type=cite class=cite cite=""><a name="_MailEndCompose"></a>
This document does not specify any protocol.<br>
&nbsp;<br>
It specifies subjective design criteria for a UI that I seriously doubt
can be a base for a consensus process.<br>
If this document is progressed I suggest that it is handled as an
informational input progressed outside of the pkix wg.<br>
&nbsp;<br>
&nbsp;<br>
<b>Stefan Santesson<br>
</b>Senior Program Manager<br>
<b>Windows Security, Standards<br>
</b>&nbsp;<br>
<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> den 9 november 2006 10:06<br>
<b>To:</b> Stephen Kent; [email-masked]<br>
<b>Subject:</b> Re: draft meeting minutes<br>
&nbsp;<br>
Dear PKIX WG:<br><br>
<br>
<b>Document Status Review -</b> Stefan Santesson (Microsoft)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Two new RFCs issued: SIM and
Update to Directory String Processing in RFC 3280. Five documents in IESG
review: SCVP, Lightweight OCSP, and 3 CMC documents. Follow up is needed
for the first two, and a revised I-D is needed for CMC. (Russ Housley
requested WG direction re the UI draft. This individual submission
received AD comments requesting changes, but no revised document has been
delivered to the IESG.) <br><br>
This is draft-choi-pkix-ui-03.txt.<br>
It is not a PKIX WG document, but the authors have not responded to
messages from me.&nbsp; I am going to drop it if the authors do not
respond soon.&nbsp; If the PKIX WG thinks there is value in this
document, I'll send it to the WG instead of dropping it.<br><br>
Russ</blockquote></body>
</html>

Content-Class: urn:content-classes:message
Subject: RE: Comment on draft-santesson-pkix-vccrl-00.txt
Date: Thu, 9 Nov 2006 15:29:36 -0800
From: Ryan Hurst <[email-masked]>
To: "Kemp David P." <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

David - I agree regarding business practices, however I think the
guidance here is about interoperability not business practice.

Networking protocols (like EAP) already have problems with certificate
payload being so large that sessions fail or take a very long time to
establish (due to re-try's related to lack of fragmentation support
pre-IP) example environments include high latency environments (metro
WANs, etc.). 

There are also environments where devices have constrained amounts of
storage (phones, etc.) where storing multiple copies of a object is
prohibitive.

On the other hand these same scenarios often can't work with indirect
CRLs without manual provisioning because they don't know how to do
discovery of the appropriate certificates and/or the resource at the end
of a AIA:IssuerCert in the CRL is not available or times out.

I guess what I am trying to say is that if this capability is to be
provided guidance of when the capability should be used (eg a well
worded applicability statement) should be included so that people don't
go out and include it everywhere.

I would have the same concern if we did the CMS wrapped CRL and
intermediate approach.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kemp David P.
Sent: Thursday, November 09, 2006 1:14 PM
To: pkix
Subject: RE: Comment on draft-santesson-pkix-vccrl-00.txt

A technical standard that documents interfaces for the purpose of
interoperability shouldn't be giving "strongly"-worded guidance
concerning business processes.

I agree with Denis' approach.  A CA that encapsulates certs
inside CRLs may increase the efficiency of some customers
(by reducing the number of fetch operations) while simultaneously
decreasing the efficiency of other customers (by expanding the
size of CRLs).

A standard that gives CAs a mechanism for offering expanded CRLs
must also give customers a mechanism for accepting or declining
that offer.  I suggest that a standard of this type should enable
certificates to point to three forms of CRL data:
1) normal CRLs
2) CRLs containing certificates
3) a bag containing CRLs and certificates

It would be up to CAs to choose which of these options to offer.
I would recommend that "my" CAs support options 1 and, where
appropriate, 3.  For certificates that support more than one
option, the client can choose at runtime which is best.
There is no reason to choose expanded CRLs if the client has
previously obtained and cached the CRL issuer's certificate.

This capability could be expressed as three different CRLDP
extension OIDs (with the same extension syntax), or as a single
extension with some other mechanism (such as a standardized
http: "?" query option) to signal what type(s) of CRL data 
are available and which is being requested.  But a standard
of this type must define some way for the client to choose.
I would not support an RFC that does not provide the ability
to request normal CRLs as Denis has proposed.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan Hurst

I believe I understand Denis concern, I would personally be OK with the
proposal as stands if its use was limited to only the scenarios where it
is needed and the text in the document strongly made that limitation
apparent; specifically indirect cases.

Ryan

From: Sam Hartman <[email-masked]>
To: "Michael Myers" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 09 Nov 2006 18:23:44 -0500
Sender: [email-masked]

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    Michael> Sam, For definition (since there has never really been
    Michael> one to date), there are two forms of OCSP relay.  The
    Michael> first is a cache of previously signed yet still reliable
    Michael> responses.  I believe this to be the target of the
    Michael> subject I-D.  The second form is a re-signing of OCSP
    Michael> responses under a key trusted by the ultimate
    Michael> requestor. Neither of these derivative aspects of OCSP
    Michael> are discussed in any depth in 2560.  It is my preference
    Michael> that 2560 remain as is, to define the protocol and its
    Michael> various options.  Other I-Ds may then map that protocol
    Michael> and those options onto specific instances of need.

I don't understand how defining an OCSP relay would be different than
my option 1 to which you object.

Reply-To: "Ksenija Schilling" <[email-masked]>
From: "Ksenija Schilling" <[email-masked]>
To: [email-masked]
Subject: Re: new
Date: Thu, 9 Nov 2006 14:27:17 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C7040B.285997A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Nice PHffARMACY http://www.kindetunhasdefunertin.com

=20

be searching for a tachyon emission source. He appeared to run out of

------=_NextPart_000_0001_01C7040B.285997A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV><H1>Nice PHffARMACY <A =
href=3D"http://www.kindetunhasdefunertin.com">http://www.kindetunhasdefun=
ertin.com</A></H1></DIV>
<DIV>&nbsp;</DIV>
<P>be searching for a tachyon emission source. He appeared to run out =
of<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C7040B.285997A0--

From: "Michael Myers" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 9 Nov 2006 13:36:55 -0800
Importance: Normal
Sender: [email-masked]

Sam,

For definition (since there has never really been one to date), there are
two forms of OCSP relay.  The first is a cache of previously signed yet
still reliable responses.  I believe this to be the target of the subject
I-D.  The second form is a re-signing of OCSP responses under a key trusted
by the ultimate requestor. Neither of these derivative aspects of OCSP are
discussed in any depth in 2560.  It is my preference that 2560 remain as is,
to define the protocol and its various options.  Other I-Ds may then map
that protocol and those options onto specific instances of need.

Mike

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Thursday, November 09, 2006 1:10 PM
To: Michael Myers
Cc: [email-masked]
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    Michael> Perhaps the subject I-D should clarify the role of a
    Michael> relay.

I do not understand this sentence.

Content-class: urn:content-classes:message
Subject: RE: Comment on draft-santesson-pkix-vccrl-00.txt
Date: Thu, 9 Nov 2006 16:13:33 -0500
From: "Kemp David P." <[email-masked]>
To: "pkix" <[email-masked]>
Sender: [email-masked]

A technical standard that documents interfaces for the purpose of
interoperability shouldn't be giving "strongly"-worded guidance
concerning business processes.

I agree with Denis' approach.  A CA that encapsulates certs
inside CRLs may increase the efficiency of some customers
(by reducing the number of fetch operations) while simultaneously
decreasing the efficiency of other customers (by expanding the
size of CRLs).

A standard that gives CAs a mechanism for offering expanded CRLs
must also give customers a mechanism for accepting or declining
that offer.  I suggest that a standard of this type should enable
certificates to point to three forms of CRL data:
1) normal CRLs
2) CRLs containing certificates
3) a bag containing CRLs and certificates

It would be up to CAs to choose which of these options to offer.
I would recommend that "my" CAs support options 1 and, where
appropriate, 3.  For certificates that support more than one
option, the client can choose at runtime which is best.
There is no reason to choose expanded CRLs if the client has
previously obtained and cached the CRL issuer's certificate.

This capability could be expressed as three different CRLDP
extension OIDs (with the same extension syntax), or as a single
extension with some other mechanism (such as a standardized
http: "?" query option) to signal what type(s) of CRL data 
are available and which is being requested.  But a standard
of this type must define some way for the client to choose.
I would not support an RFC that does not provide the ability
to request normal CRLs as Denis has proposed.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan Hurst

I believe I understand Denis concern, I would personally be OK with the
proposal as stands if its use was limited to only the scenarios where it
is needed and the text in the document strongly made that limitation
apparent; specifically indirect cases.

Ryan

Content-class: urn:content-classes:message
Subject: RE: draft meeting minutes
Date: Thu, 9 Nov 2006 21:12:59 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Stephen Kent" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

This document does not specify any protocol.

=20

It specifies subjective design criteria for a UI that I seriously doubt
can be a base for a consensus process.

If this document is progressed I suggest that it is handled as an
informational input progressed outside of the pkix wg.

=20

=20

Stefan Santesson

Senior Program Manager

=20

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: den 9 november 2006 10:06
To: Stephen Kent; [email-masked]
Subject: Re: draft meeting minutes

=20

Dear PKIX WG:

Document Status Review - Stefan Santesson (Microsoft)
        Two new RFCs issued: SIM and Update to Directory String
Processing in RFC 3280. Five documents in IESG review: SCVP, Lightweight
OCSP, and 3 CMC documents. Follow up is needed for the first two, and a
revised I-D is needed for CMC. (Russ Housley requested WG direction re
the UI draft. This individual submission received AD comments requesting
changes, but no revised document has been delivered to the IESG.)=20

This is draft-choi-pkix-ui-03.txt.
It is not a PKIX WG document, but the authors have not responded to
messages from me.  I am going to drop it if the authors do not respond
soon.  If the PKIX WG thinks there is value in this document, I'll send
it to the WG instead of dropping it.

Russ

------_=_NextPart_001_01C70443.D4F008D2
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:p=3D"urn:schemas-microsoft-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-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.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/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 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:"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;}
 /* 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'>This document =
does not
specify any protocol.<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US =
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-family:"Calibri","sans-serif";
color:#1F497D'>It specifies subjective design criteria for a UI that I =
seriously
doubt can be a base for a consensus process.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If this document is progressed I suggest that it is =
handled as
an informational input progressed outside of the pkix =
wg.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
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-family:"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-family:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span =
lang=3DEN-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-family:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB =
style=3D'color:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"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-family:"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-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Russ =
Housley<br>
<b>Sent:</b> den 9 november 2006 10:06<br>
<b>To:</b> Stephen Kent; [email-masked]<br>
<b>Subject:</b> Re: draft meeting minutes<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal>Dear PKIX WG:<br>
<br>
<br>
<o:p></o:p></p>

<p class=3DMsoNormal><b><span style=3D'font-size:18.0pt'>Document Status =
Review -</span></b><span
style=3D'font-size:18.0pt'> Stefan Santesson (Microsoft)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Two new RFCs issued: SIM =
and
Update to Directory String Processing in RFC 3280. Five documents in =
IESG
review: SCVP, Lightweight OCSP, and 3 CMC documents. Follow up is needed =
for
the first two, and a revised I-D is needed for CMC. (Russ Housley =
requested WG
direction re the UI draft. This individual submission received AD =
comments requesting
changes, but no revised document has been delivered to the IESG.) =
</span><o:p></o:p></p>

<p class=3DMsoNormal><br>
This is draft-choi-pkix-ui-03.txt.<br>
It is not a PKIX WG document, but the authors have not responded to =
messages
from me.&nbsp; I am going to drop it if the authors do not respond =
soon.&nbsp;
If the PKIX WG thinks there is value in this document, I'll send it to =
the WG
instead of dropping it.<br>
<br>
Russ<o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C70443.D4F008D2--

From: Sam Hartman <[email-masked]>
To: "Michael Myers" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 09 Nov 2006 16:10:13 -0500
Sender: [email-masked]

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    Michael> Perhaps the subject I-D should clarify the role of a
    Michael> relay.

I do not understand this sentence.

From: "Michael Myers" <[email-masked]>
To: "Sam Hartman" <[email-masked]>, <[email-masked]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 9 Nov 2006 12:00:23 -0800
Importance: Normal
Sender: [email-masked]

Sam, all:

I will oppose the following:

> 1) Make a standards-track change/clarification to
>    2560 indicating that responders need not have a key.

Perhaps the subject I-D should clarify the role of a relay.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Sam Hartman
Sent: Thursday, November 09, 2006 10:16 AM
To: [email-masked]
Subject: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Hi, folsk.

I have a discuss on the lightweight ocsp profile .

One of the primary purposes of the lightweight OCSP profile is to
allow deployment of responders that do not have private keys and thus
can only return pre-produced responses.
However this document is  informational, not standards track.

I contend that RFC 2560 allows pre-produced responses, but does not
really support responders that can only give pre-produced responses.
That is, I contend that as written, to achieve interoperability, you
need to have an online signing key.

I believe it is inappropriate for an informational document to profile
OCSP in this way.

I'd like to ask the PKIX working group to do one of three things to resolve
my discuss:

1) Make a standards-track change/clarification to 2560 indicating that
   responders need not have a key.

2) Remove this major goal from the lightweight-ocsp-profile.

3) Withdraw the document.

Content-Class: urn:content-classes:message
Subject: RE: Comment on draft-santesson-pkix-vccrl-00.txt
Date: Thu, 9 Nov 2006 10:56:15 -0800
From: Ryan Hurst <[email-masked]>
To: Denis Pinkas <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

I believe I understand Denis concern, I would personally be OK with the
proposal as stands if its use was limited to only the scenarios where it
is needed and the text in the document strongly made that limitation
apparent; specifically indirect cases.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Thursday, November 09, 2006 6:18 AM
To: pkix
Subject: Comment on draft-santesson-pkix-vccrl-00.txt

Stefan,

Your current proposal is limited to propose a new CRLextension:

id-pe-validationCerts OBJECT IDENTIFIER ::= { id-pe nn }

The problem is the following: if a CA chooses to issue CRLs with that
new extension, 
then all CRLs will augment in size.

I would rather prefer to be able to provide relying parties with the
choice between :

  - CRLs that carry that new extension, and 
  - CRLs "as usual".

This would be achieved, if you were proposing at the same time a new
certificate extension 
that would allow to retrieve CRLs that have the new extension (e.g. a
new CRLDP extension 
that would point where the bigger CRL is).

Current applications would continue to ignore both new extensions and
would not be impacted 
in any way, whatever the choice of the CA would be.

All this story is a trade off between this additional complexity both on
the CA side and 
on the relying party side and the saving of  one exchange.

Denis

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 09 Nov 2006 13:15:57 -0500
Sender: [email-masked]

Hi, folsk.

I have a discuss on the lightweight ocsp profile .

One of the primary purposes of the lightweight OCSP profile is to
allow deployment of responders that do not have private keys and thus
can only return pre-produced responses.
However this document is  informational, not standards track.

I contend that RFC 2560 allows pre-produced responses, but does not
really support responders that can only give pre-produced responses.
That is, I contend that as written, to achieve interoperability, you
need to have an online signing key.

I believe it is inappropriate for an informational document to profile
OCSP in this way.

I'd like to ask the PKIX working group to do one of three things to resolve my discuss:

1) Make a standards-track change/clarification to 2560 indicating that
   responders need not have a key.

2) Remove this major goal from the lightweight-ocsp-profile.

3) Withdraw the document.

Date: Thu, 09 Nov 2006 13:06:03 -0500
To: Stephen Kent <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: draft meeting minutes
Sender: [email-masked]

<html>
<body>
Dear PKIX WG:<br><br>
<blockquote type=cite class=cite cite=""><font size=5><b>Document Status
Review -</b> Stefan Santesson (Microsoft)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Two new
RFCs issued: SIM and Update to Directory String Processing in RFC 3280.
Five documents in IESG review: SCVP, Lightweight OCSP, and 3 CMC
documents. Follow up is needed for the first two, and a revised I-D is
needed for CMC. (Russ Housley requested WG direction re the UI draft.
This individual submission received AD comments requesting changes, but
no revised document has been delivered to the IESG.)
</font></blockquote><br>
This is draft-choi-pkix-ui-03.txt.<br>
It is not a PKIX WG document, but the authors have not responded to
messages from me.&nbsp; I am going to drop it if the authors do not
respond soon.&nbsp; If the PKIX WG thinks there is value in this
document, I'll send it to the WG instead of dropping it.<br><br>
Russ<br>
</body>
</html>

Date: Thu, 9 Nov 2006 15:17:51 +0100
From: "Denis Pinkas" <[email-masked]>
To: "pkix" <[email-masked]>
Subject: Comment on draft-santesson-pkix-vccrl-00.txt
Sender: [email-masked]

Stefan,

Your current proposal is limited to propose a new CRLextension:

id-pe-validationCerts OBJECT IDENTIFIER ::= { id-pe nn }

The problem is the following: if a CA chooses to issue CRLs with that new extension, 
then all CRLs will augment in size.

I would rather prefer to be able to provide relying parties with the choice between :

  - CRLs that carry that new extension, and 
  - CRLs "as usual".

This would be achieved, if you were proposing at the same time a new certificate extension 
that would allow to retrieve CRLs that have the new extension (e.g. a new CRLDP extension 
that would point where the bigger CRL is).

Current applications would continue to ignore both new extensions and would not be impacted 
in any way, whatever the choice of the CA would be.

All this story is a trade off between this additional complexity both on the CA side and 
on the relying party side and the saving of  one exchange.

Denis

From: "Wen-Cheng Wang" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, =?utf-8?B?6LW1IOaVjw==?= <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: Re: The definition of OtherName in 3280bis differs with X.509?
Date: Thu, 9 Nov 2006 13:41:59 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C70404.D4B68460
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

It is true that an INSTANCE OF <DefinedObjectClass> is equivalent to
[UNIVERSAL 8] IMPLICIT SEQUENCE
{
    type-id     <DefinedObjectClass>.&id,
    value        [0] EXPLICIT <DefinedObjectClass>.&Type
}

Therefore, if the "AnotherName" type is, as claimed, defined to replace
the "INSTANCE OF OTHER NAME" type, its syntax should be:

AnotherName ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE
{
    type-id      OBJECT IDENTIFIER,
    value        [0] EXPLICIT ANY DEFINED BY type-id
}

(Note that in RFC 2459, 3280 and 3280bis, the text wrongly claims
that "AnotherName replaces OTHER-NAME ::=3D TYPE-IDENTIFIER".
The reason why the statement is wrong is that OTHER-NAME
is an information object class while AnotherName is a data type, and
a data type can not replace an information object class.
The correct way of saying that should be "AnotherName replaces
INSTANCE OF OTHER-NAME", because "INSTANCE OF OTHER-NAME"
is a data type.)

However, to my knowledge of ASN.1, since the default tagging mode of the
PKIX1Implicit88 module is "IMPLICIT TAGS", the DER encoding will be the
same with or without the "[UNIVERSAL 8] IMPLICIT" tagging precede the
SEQUENCE type. The reason is that the outer implicit tag (i.e., the tag =
[0]
precedes the "AnotherName" type in the GeneralName type) will always
overwrite the inner tag no matter the inner tag is an "[UNIVERSAL 8] =
IMPLICIT
SEQUENCE" or  simply a "SEQUENCE".

My conclusion to this issue is that even the syntax is inconsistent =
between
PKIX and ITU-T X.509, it is luckly that their DER encodings will still =
be the
same.

Nevertheless, one thing we should note is that the "AnotherName" type =
should
not be used alone without any implicit tag precede, otherwise it will =
result
inconsistent DER encoding with ITU-T X.509. For example, if someday we
define a type named "ListOfAnotherNames" as the following:

ListOfAnotherNames ::=3D SEQUENCE OF AnotherName

With our current definition of the "AnotherName" type, the DER encoding
of an "AnotherName" value will different with the case where it is =
defined
as the following:

ListOfAnotherNames ::=3D SEQUENCE OF INSTANCE OF OTHER-NAME

So, now the question is "do we need to change the syntax of AnotherName
to be syntactically aligned with ITU-T X.509?"

Wen-Cheng Wang
  ----- Original Message -----=20
  From: David A. Cooper=20
  To: =E8=B5=B5 =E6=95=8F=20
  Cc: pkix=20
  Sent: Thursday, November 09, 2006 3:01 AM
  Subject: Re: The definition of OtherName in 3280bis differs with =
X.509?

  I do not understand ASN.1 well enough to answer the question below, =
but someone else on the PKIX mail list may be able to respond.

  I can say, however, that the ASN.1 for OtherName in 3280bis is the =
same as the ASN.1 for OtherName in RFC 2459 (January 1999) and RFC 3280 =
(April 2002), so if it in an error it is a very old error.

  Dave

  -------- Original Message -------- Subject:  The difinition of =
OtherName in 3280bis differs with X.509?=20
        Date:  Wed, 08 Nov 2006 14:23:38 +0800=20
        From:  =E8=B5=B5 =E6=95=8F <[email-masked]>=20
        To:  [email-masked]=20

Hello David:
   In rfc3280bis,Setion 4.2.1.6:
OtherName ::=3D SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
    Setion A.2
-- AnotherName replaces OTHER-NAME ::=3D TYPE-IDENTIFIER, as
-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax

AnotherName ::=3D SEQUENCE {
    type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }

But in X.509(2005),Setion 4.2.1.6:
GeneralName ::=3D CHOICE {
 otherName [0] INSTANCE OF OTHER-NAME,=20
 rfc822Name [1] IA5String,
 dNSName [2] IA5String,
 x400Address [3] ORAddress,
 directoryName [4] Name,
 ediPartyName [5] EDIPartyName,
 uniformResourceIdentifier [6] IA5String,
 iPAddress [7] OCTET STRING,
 registeredID [8] OBJECT IDENTIFIER }
OTHER-NAME ::=3D TYPE-IDENTIFIER
In X.681(2002),Annex A:
A.2 The TYPE-IDENTIFIER information object class is defined as:
TYPE-IDENTIFIER ::=3D CLASS
{
 &id OBJECT IDENTIFIER UNIQUE,
 &Type
}
WITH SYNTAX {&Type IDENTIFIED BY &id}
X.681(2002),Annex C The instance-of type:
C.7 The associated sequence type shall be:
SEQUENCE
{
 type-id <DefinedObjectClass>.&id,
 value [0] <DefinedObjectClass>.&Type
}
where "<DefinedObjectClass>" is replaced by the particular=20
"DefinedObjectClass" used in the "InstanceOfType" notation.

So,INSTANCE OF OTHER-NAME associated sequence type shall be:
OtherName ::=3D SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
But,this is associated sequence type,not the encoding rules.The =
definition=20
of BER/DER is in X690.
In X690(2002),Setion 8.16 Encoding of an instance-of value
8.16.1 The encoding of the instance-of type shall be the BER encoding of =

the following
sequence type with the value as specified in 8.16.2:
[UNIVERSAL 8] IMPLICIT SEQUENCE
{
  type-id <DefinedObjectClass>.&id,
  value [0] EXPLICIT <DefinedObjectClass>.&Type
}
where "<DefinedObjectClass>" is replaced by the particular=20
"DefinedObjectClass" used in the
"InstanceOfType" notation.
  So,I think the definition of OtherName in the '88 ASN.1 syntax should=20
be:
OtherName ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE {
   type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }
 =20
  Because the tag of otherName is IMPLICIT,the encode value of =
GeneralName=20
in rfc3280bis is identical of X.509.

                         =20
                   zhaomin

------=_NextPart_000_001A_01C70404.D4B68460
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV>It is true that an INSTANCE OF &lt;DefinedObjectClass&gt; is =
equivalent=20
to</DIV>
<DIV>[UNIVERSAL 8] IMPLICIT SEQUENCE<BR>{</DIV>
<DIV>&nbsp;&nbsp;&nbsp; type-id&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;DefinedObjectClass&gt;.&amp;id,</DIV>
<DIV>&nbsp;&nbsp;&nbsp; value&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; [0] =
EXPLICIT=20
&lt;DefinedObjectClass&gt;.&amp;Type<BR>}</DIV>
<DIV>&nbsp;</DIV>
<DIV>Therefore, if the "AnotherName" type is, as claimed,&nbsp;defined =
to=20
replace</DIV>
<DIV>the "INSTANCE OF OTHER NAME" type, its syntax should be:</DIV>
<DIV>&nbsp;</DIV>
<DIV>AnotherName ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE<BR>{</DIV>
<DIV>&nbsp;&nbsp;&nbsp; =
type-id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;OBJECT=20
IDENTIFIER,</DIV>
<DIV>&nbsp;&nbsp;&nbsp; value&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; [0] =
EXPLICIT=20
ANY DEFINED BY type-id<BR>}</DIV>
<DIV>&nbsp;</DIV>
<DIV>(Note that in RFC 2459, 3280 and 3280bis, the text wrongly =
claims</DIV>
<DIV>that "AnotherName replaces OTHER-NAME ::=3D TYPE-IDENTIFIER".</DIV>
<DIV>The reason why the statement is wrong is&nbsp;that OTHER-NAME
<DIV>is an information object class while AnotherName is a data type, =
and</DIV>
<DIV>a data type can not replace an information object =
class.</DIV></DIV>
<DIV>The correct way of saying that should be "AnotherName =
replaces</DIV>
<DIV>INSTANCE OF OTHER-NAME", because&nbsp;"INSTANCE OF =
OTHER-NAME"</DIV>
<DIV>is a data type.)</DIV>
<DIV>&nbsp;</DIV>
<DIV>However, to my knowledge of ASN.1, since the default tagging mode =
of=20
the</DIV>
<DIV>PKIX1Implicit88 module is "IMPLICIT TAGS", the DER encoding will be =

the</DIV>
<DIV>same with or without the "[UNIVERSAL 8] IMPLICIT" tagging precede =
the</DIV>
<DIV>SEQUENCE type. The reason is that the outer implicit tag (i.e., the =
tag=20
[0]</DIV>
<DIV>precedes the "AnotherName" type in the GeneralName type) will =
always</DIV>
<DIV>overwrite the inner tag no matter&nbsp;the inner tag is an =
"[UNIVERSAL 8]=20
IMPLICIT</DIV>
<DIV>SEQUENCE" or&nbsp;&nbsp;simply a "SEQUENCE".</DIV>
<DIV>&nbsp;</DIV>
<DIV>My conclusion to this issue is that even the syntax is inconsistent =

between</DIV>
<DIV>PKIX and ITU-T X.509, it is luckly that their DER encodings will =
still be=20
the</DIV>
<DIV>same.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Nevertheless, one thing we should note is that the "AnotherName" =
type=20
should</DIV>
<DIV>not be used alone&nbsp;without any implicit tag precede, otherwise =
it will=20
result</DIV>
<DIV>inconsistent DER encoding with ITU-T X.509. For example, if someday =

we</DIV>
<DIV>define a type named "ListOfAnotherNames" as the following:</DIV>
<DIV>&nbsp;</DIV>
<DIV>ListOfAnotherNames ::=3D SEQUENCE OF AnotherName</DIV>
<DIV>&nbsp;</DIV>
<DIV>With our current definition of the "AnotherName" type, the DER=20
encoding</DIV>
<DIV>of an "AnotherName" value will different with the case&nbsp;where =
it is=20
defined</DIV>
<DIV>as the following:</DIV>
<DIV>&nbsp;</DIV>
<DIV>ListOfAnotherNames ::=3D SEQUENCE OF INSTANCE OF OTHER-NAME</DIV>
<DIV>&nbsp;</DIV>
<DIV>So, now the question is "do we need to change the syntax of=20
AnotherName</DIV>
<DIV>to be syntactically aligned with ITU-T X.509?"</DIV>
<DIV>&nbsp;</DIV>
<DIV>Wen-Cheng Wang</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt =E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94; font-color: black"><B>From:</B>=20
  <A title=[email-masked] =
href=3D"mailto:[email-masked]">David A.=20
  Cooper</A> </DIV>
  <DIV style=3D"FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">=E8=B5=B5 =E6=95=8F</A> </DIV>
  <DIV style=3D"FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">pkix</A> </DIV>
  <DIV style=3D"FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><B>Sent:</B> Thursday, November =
09, 2006 3:01=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><B>Subject:</B> Re: The definition =
of OtherName=20
  in 3280bis differs with X.509?</DIV>
  <DIV><BR></DIV>I do not understand ASN.1 well enough to answer the =
question=20
  below, but someone else on the PKIX mail list may be able to =
respond.<BR><BR>I=20
  can say, however, that the ASN.1 for OtherName in 3280bis is the same =
as the=20
  ASN.1 for OtherName in RFC 2459 (January 1999) and RFC 3280 (April =
2002), so=20
  if it in an error it is a very old =
error.<BR><BR>Dave<BR><BR><BR>--------=20
  Original Message --------=20
  <TABLE class=3Dmoz-email-headers-table cellSpacing=3D0 cellPadding=3D0 =
border=3D0>
    <TBODY>
    <TR>
      <TH vAlign=3Dbaseline noWrap align=3Dright>Subject: </TH>
      <TD>The difinition of OtherName in 3280bis differs with =
X.509?</TD></TR>
    <TR>
      <TH vAlign=3Dbaseline noWrap align=3Dright>Date: </TH>
      <TD>Wed, 08 Nov 2006 14:23:38 +0800</TD></TR>
    <TR>
      <TH vAlign=3Dbaseline noWrap align=3Dright>From: </TH>
      <TD>=E8=B5=B5 =E6=95=8F <A class=3Dmoz-txt-link-rfc2396E=20
        =
href=3D"mailto:[email-masked]">&lt;[email-masked]&gt;</A></TD></TR>
    <TR>
      <TH vAlign=3Dbaseline noWrap align=3Dright>To: </TH>
      <TD><A class=3Dmoz-txt-link-abbreviated=20
        =
href=3D"mailto:[email-masked]">[email-masked]</A></TD></TR>=
</TBODY></TABLE><BR><BR><PRE>Hello David:
   In rfc3280bis,Setion 4.2.1.6:
OtherName ::=3D SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
    Setion A.2
-- AnotherName replaces OTHER-NAME ::=3D TYPE-IDENTIFIER, as
-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax

AnotherName ::=3D SEQUENCE {
    type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }

But in X.509(2005),Setion 4.2.1.6:
GeneralName ::=3D CHOICE {
 otherName [0] INSTANCE OF OTHER-NAME,=20
 rfc822Name [1] IA5String,
 dNSName [2] IA5String,
 x400Address [3] ORAddress,
 directoryName [4] Name,
 ediPartyName [5] EDIPartyName,
 uniformResourceIdentifier [6] IA5String,
 iPAddress [7] OCTET STRING,
 registeredID [8] OBJECT IDENTIFIER }
OTHER-NAME ::=3D TYPE-IDENTIFIER
In X.681(2002),Annex A:
A.2 The TYPE-IDENTIFIER information object class is defined as:
TYPE-IDENTIFIER ::=3D CLASS
{
 &amp;id OBJECT IDENTIFIER UNIQUE,
 &amp;Type
}
WITH SYNTAX {&amp;Type IDENTIFIED BY &amp;id}
X.681(2002),Annex C The instance-of type:
C.7 The associated sequence type shall be:
SEQUENCE
{
 type-id &lt;DefinedObjectClass&gt;.&amp;id,
 value [0] &lt;DefinedObjectClass&gt;.&amp;Type
}
where "&lt;DefinedObjectClass&gt;" is replaced by the particular=20
"DefinedObjectClass" used in the "InstanceOfType" notation.

So,INSTANCE OF OTHER-NAME associated sequence type shall be:
OtherName ::=3D SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
But,this is associated sequence type,not the encoding rules.The =
definition=20
of BER/DER is in X690.
In X690(2002),Setion 8.16 Encoding of an instance-of value
8.16.1 The encoding of the instance-of type shall be the BER encoding of =

the following
sequence type with the value as specified in 8.16.2:
[UNIVERSAL 8] IMPLICIT SEQUENCE
{
  type-id &lt;DefinedObjectClass&gt;.&amp;id,
  value [0] EXPLICIT &lt;DefinedObjectClass&gt;.&amp;Type
}
where "&lt;DefinedObjectClass&gt;" is replaced by the particular=20
"DefinedObjectClass" used in the
"InstanceOfType" notation.
  So,I think the definition of OtherName in the '88 ASN.1 syntax should=20
be:
OtherName ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE {
   type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }
 =20
  Because the tag of otherName is IMPLICIT,the encode value of =
GeneralName=20
in rfc3280bis is identical of X.509.

                         =20
                   zhaomin

</PRE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001A_01C70404.D4B68460--

Date: Wed, 8 Nov 2006 22:43:32 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft meeting minutes
Sender: [email-masked]

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

Please send comments to me by 11/27.

Steve
-----

PKIX WG Meeting 11/8/06

Edited by Steve Kent
Chairs: Stephen Kent <[email-masked]> &  Stefan Santesson <[email-masked]>

The PKIX WG met once, for a total of two hours, during the 67th IETF. 
A total of approximately 50 individuals participated in the meeting.

Document Status Review - Stefan Santesson (Microsoft)
	Two new RFCs issued: SIM and Update to Directory String 
Processing in RFC 3280. Five documents in IESG review: SCVP, 
Lightweight OCSP, and 3 CMC documents. Follow up is needed for the 
first two, and a revised I-D is needed for CMC. (Russ Housley 
requested WG direction re the UI draft. This individual submission 
received AD comments requesting changes, but no revised document has 
been delivered to the IESG.) Two documents have completed WG last 
call, and will soon be forwarded to the IESG: 3280bis and SAN for 
Service Names. Two documents still under WG review: ECC algorithms 
(waiting for resolution of algorithm parameter resolution) and the 
Draft for ECDSA and DSA with SHA-2. (slides)

PKIX WG Specifications

3280bis -  David Cooper (NIST)
       A new draft 05 was recently posted as response to past WG last 
call. David reviewed the changes made from version 4 to version 5, 
and provided an explanation for each change. (slides)

Simple Certificate Validation Protocol (SCVP)- Tim Polk (NIST)
	This document is still in AD evaluation and a new draft 
requested by the AD. We are currently at version 28! Tim reviewed the 
changes made in response to Sam's comments. He noted that these 
changes were posted to the list on Halloween, and that there have 
been no responses to this posting. However, Tim identified one or two 
additional fixes that need to be effected before the document will be 
finished. He also identified one open issue, related to whether the 
document satisfies the interoperability requirements established by 
2026.
	[Sam wants us to run a straw poll to confirm that the WG is 
comfortable with a single spec that defines both DPD and DPV and does 
not mandate that a server do either one as a base.]
(slides)

Certificate Management Messages over CMS (CMC) - Jim Schaad (Soaring 
Hawk Consulting)
       These documents are under IESG review which has resulted in 
several change requests. For example, there is a need for the section 
detailing the changes from the base documents (since this is a "bis" 
document). There is also a need to accommodate hash algorithm 
agility, a relatively easy fix. A bigger issue is whether to change 
the OID used to refer to the encrypted data, because of the way 
S/MIME has defined this OID. A more significant issue is a request 
from the AD to make use of CRMF a MUST and make use of PKCS #10 
structures a MAY. We plan to complete WG last call by December, in 
parallel with AD re-review. (slides)

Algorithm IDs for Elliptic Curve Cryptography in PKIX - Brian Minard (Certicom)
	Dan Brown (the document author) could not be physically 
present, but monitored the presentation via Jabber. Looking for 
feedback on several issues, including support for parameters for 
SHA-2, and references to KDFs to be used with the public key in the 
certificate, in the context of EC-DH or EC-MQV. The question was 
raised as to why one needs to make reference to a KDF in a 
certificate, given that the KDFs are not protocol specific, but one 
needs protocol-specific details to completely specify how key 
derivation is performed. Much of the discussion on this topic is 
subsumed by the next topic. (slides)

Design team report on ECC public key IDs - Tim Polk (NIST)
	We instantiated a design team of Tim, Brian Minard, and Tolga 
Acar to address this complex issue. RFC 3279 defines an OID for EC, 
and includes algorithm parameters, but this does not provide a way to 
distinguish between a bit string to be used with EC-DH vs. EC-MQV. 
Two choices were evaluated: RFC 4055-style solution vs. the ANSI 
X.962 solution to specify which algorithm or algorithms can be used 
with the key. RFC 4055 was developed to distinguish among RSA modes, 
but is easily adapted to accommodate ECC. ANSI X.962 puts into the 
parameters field the additional info needed to specify the algorithms 
that the key can be used with. This leads to potential nesting of 
OIDs, and one can also specify KDFs here as well. The design team 
suggested a third approach, namely to retain the 3279 parameter 
model, and to optionally augment it with a certificate extension to 
specify the additional data that the ANSI approach encodes in the 
parameters field, as well as accommodating the notion of family OIDs, 
something not supported in the ANSI approach. A feature of this 
approach is that if the extension is non-critical, the result is 
backwards compatible with 3279, but making it critical allows one to 
enforce the sort of fine-grained controls available in the ANSI 
approach. The team developed a set of criteria for evaluating the 3 
approaches. They polled a variety of folks and got a diverse set of 
answers. Their decision was that the use of a new extension is 
preferred, in conjunction with the RFC 3279 ECC syntax. Numerous 
questions were raised by attendees. The discussion will continue on 
the list, and we will probably result in a new work item to resolve 
this issue, including asking whether the use of a new extension is 
appropriate for RSA as well (in lieu of RFC 4055). (slides)

Related Specifications & Liaison Presentations

Validation Certificates in CRLs - Stefan Santesson (Microsoft)
       A new individual draft that proposes an optional extension that 
allows one to embed one or more certificates in a CRL. The intent is 
to facilitate CRL validation when the certificate(s) needed to verify 
a CRL are different from the certificate associated with the CA under 
whose auspices the CRL is issued. One can already embed a pointer to 
the requisite certificate, so the advantage to this approach is that 
it can save a retrieval request (across a net), and for CRL 
validation in the NR context, when CRL processing will take place 
long after CRL issuance. One should use this extension only in 
"appropriate" contexts, e.g., to avoid unnecessary CRL bloat. The 
question is whether this be accepted as a WG document. A straw poll 
will be conducted on the WG list. (slides)
--============_-1049078573==_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>draft meeting minutes</title></head><body>
<div>Please send comments to me by 11/27.</div>
<div><br></div>
<div>Steve</div>
<div>-----</div>
<div><br></div>
<div><font size="+2" color="#000000"><b>PKIX WG Meeting 11/8/06<br>
<br>
</b>Edited by Steve Kent<br>
Chairs: Stephen Kent &lt;[email-masked]&gt; &amp;&nbsp; Stefan Santesson
&lt;[email-masked]&gt;<br>
<br>
The PKIX WG met once, for a total of two hours, during the 67th IETF.
A total of approximately 50 individuals participated in the
meeting.<br>
<br>
<br>
<b>Document Status Review -</b> Stefan Santesson (Microsoft)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Two new RFCs
issued: SIM and Update to Directory String Processing in RFC 3280.
Five documents in IESG review: SCVP, Lightweight OCSP, and 3 CMC
documents. Follow up is needed for the first two, and a revised I-D is
needed for CMC. (Russ Housley requested WG direction re the UI draft.
This individual submission received AD comments requesting changes,
but no revised document has been delivered to the IESG.) Two documents
have completed WG last call, and will soon be forwarded to the IESG:
3280bis and SAN for Service Names. Two documents still under WG
review: ECC algorithms (waiting for resolution of algorithm parameter
resolution) and the Draft for ECDSA and DSA with SHA-2. (slides)<br>
&nbsp;<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
</b></font><font size="+3" color="#000000"><b>PKIX WG
Specifications<br>
<br>
</b></font><font size="+2" color="#000000"><b>3280bis -&nbsp; David
Cooper (NIST)<br>
</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A new draft 05 was recently posted
as response to past WG last call. David reviewed the changes made from
version 4 to version 5, and provided an explanation for each change.
(slides)<br>
<br>
<b>Simple Certificate Validation Protocol (SCVP)- Tim Polk (NIST)<br>
</b><x-tab>&nbsp; </x-tab>This document is still in AD evaluation and
a new draft requested by the AD. We are currently at version 28! Tim
reviewed the changes made in response to Sam's comments. He noted that
these changes were posted to the list on Halloween, and that there
have been no responses to this posting. However, Tim identified one or
two additional fixes that need to be effected before the document will
be finished. He also identified one open issue, related to whether the
document satisfies the interoperability requirements established by
2026.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>[Sam wants us to
run a straw poll to confirm that the WG is comfortable with a single
spec that defines both DPD and DPV and does not mandate that a server
do either one as a base.]<br>
(slides)<br>
<br>
<b>Certificate Management Messages over CMS (CMC) - Jim Schaad
(Soaring Hawk Consulting)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</b> These documents are under IESG
review which has resulted in several change requests. For example,
there is a need for the section detailing the changes from the base
documents (since this is a "bis" document). There is also a need
to accommodate hash algorithm agility, a relatively easy fix. A bigger
issue is whether to change the OID used to refer to the encrypted
data, because of the way S/MIME has defined this OID. A more
significant issue is a request from the AD to make use of CRMF a MUST
and make use of PKCS #10 structures a MAY. We plan to complete WG last
call by December, in parallel with AD re-review. (slides)<br>
<br>
<b>Algorithm IDs for Elliptic Curve Cryptography in PKIX - Brian
Minard (Certicom)<br>
</b><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Dan Brown (the
document author) could not be physically present, but monitored the
presentation via Jabber. Looking for feedback on several issues,
including support for parameters for SHA-2, and references to KDFs to
be used with the public key in the certificate, in the context of
EC-DH or EC-MQV. The question was raised as to why one needs to make
reference to a KDF in a certificate, given that the KDFs are not
protocol specific, but one needs protocol-specific details to
completely specify how key derivation is performed. Much of the
discussion on this topic is subsumed by the next topic. (slides)<br>
<br>
<b>Design team report on ECC public key IDs - Tim Polk (NIST)<br>
</b><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>We instantiated a
design team of Tim, Brian Minard, and Tolga Acar to address this
complex issue. RFC 3279 defines an OID for EC, and includes algorithm
parameters, but this does not provide a way to distinguish between a
bit string to be used with EC-DH vs. EC-MQV. Two choices were
evaluated: RFC 4055-style solution vs. the ANSI X.962 solution to
specify which algorithm or algorithms can be used with the key. RFC
4055 was developed to distinguish among RSA modes, but is easily
adapted to accommodate ECC. ANSI X.962 puts into the parameters field
the additional info needed to specify the algorithms that the key can
be used with. This leads to potential nesting of OIDs, and one can
also specify KDFs here as well. The design team suggested a third
approach, namely to retain the 3279 parameter model, and to optionally
augment it with a certificate extension to specify the additional data
that the ANSI approach encodes in the parameters field, as well as
accommodating the notion of family OIDs, something not supported in
the ANSI approach. A feature of this approach is that if the extension
is non-critical, the result is backwards compatible with 3279, but
making it critical allows one to enforce the sort of fine-grained
controls available in the ANSI approach. The team developed a set of
criteria for evaluating the 3&nbsp; approaches. They polled a variety
of folks and got a diverse set of answers. Their decision was that the
use of a new extension is preferred, in conjunction with the RFC 3279
ECC syntax. Numerous questions were raised by attendees. The
discussion will continue on the list, and we will probably result in a
new work item to resolve this issue, including asking whether the use
of a new extension is appropriate for RSA as well (in lieu of RFC
4055). (slides)</font></div>
<div><font size="+2" color="#000000"><br>
<br>
</font><font size="+3" color="#000000"><b>Related Specifications &amp;
Liaison Presentations<br>
</b></font><font size="+2"
color="#000000"><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
<br>
Validation Certificates in CRLs - Stefan Santesson (Microsoft)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</b> A new individual draft that
proposes an optional extension that allows one to embed one or more
certificates in a CRL. The intent is to facilitate CRL validation when
the certificate(s) needed to verify a CRL are different from the
certificate associated with the CA under whose auspices the CRL is
issued. One can already embed a pointer to the requisite certificate,
so the advantage to this approach is that it can save a retrieval
request (across a net), and for CRL validation in the NR context, when
CRL processing will take place long after CRL issuance. One should use
this extension only in "appropriate" contexts, e.g., to avoid
unnecessary CRL bloat. The question is whether this be accepted as a
WG document. A straw poll will be conducted on the WG list.
(slides)</font></div>
</body>
</html>
--============_-1049078573==_ma============--

From: "bene..." <[email-masked]>
To: [email-masked]
Subject: voce conigli .:
Date: 	Thu, 9 Nov 2006 11:04:45 +0800

------=_NextPart_000_000A_01C703EE.DD7105A0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000B_01C703EE.DD7105A0"

------=_NextPart_001_000B_01C703EE.DD7105A0
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

All is as read a Hosting am Aruba Proteggi.
League of Coppa Uefa Mondiali bidoni Europei migliori of bomberby. Top =
is Auguri nannini ciao grazie tutti a.
Post a nome altre in. League Coppa of Uefa of Mondiali bidoni Europei =
migliori or bomberby or Pallavolo. Che nanna lascio custodia ciau top is =
good a tata a tata. Uao non a si of spama.
Help Fast a Passterms of me. Rispondi sondaggio aiutaci capire or tuoi =
interessi Yaoi Style voce or! Giorno mb uao non a si in.
Costosoby cazzata parlare Telefilms amp Piccolo Schermo film vistoby? =
Dei miei cerca!
Lab Chat in tag Faccine Template Smallville Powered Invision Power. =
Nostri motori Mercedes Bmwby cosa tuo computer of Free a.
Qui vostre assenze vo fare la generi parla ruota.
Pi amatoforum led. Nostri motori Mercedes Bmwby cosa tuo computer of =
Free a.
Custodia ciau top am good tata in tata salve. Windows Movie Makerby is =
su Gite. Iiuser legend Moderatori in.
Belle Cinese lo Iiquizquiz domande Quiz. Grazie tutti seahawk of buona =
nanno Mave Buonanotte raga.
Grezie Barbara van of? Risposte dagli or esperti anni primo or bacioby =
bens nostri motori?
Ritiro subito quello.
League of Coppa Uefa Mondiali bidoni Europei migliori of bomberby.
Of me Anonymous Home Page Supporto in Forumfree Segnala am.
Auguroni giorno am mb!
Raga zefir raga malvo a thrasher.
Auguroni giorno am mb!
Auguroni giorno mb uao non of si is.
------=_NextPart_001_000B_01C703EE.DD7105A0
Content-Type: text/html;
	charset="windows-1250"
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-1250">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"bannati" hspace=3D0=20
src=3D"cid:000901c703ab$cf4dc5a0$dad69bca@lc14" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>All is as read a Hosting am Aruba=20
Proteggi.<BR>League of Coppa Uefa Mondiali bidoni Europei migliori of =
bomberby.=20
Top is Auguri nannini ciao grazie tutti a.<BR>Post a nome altre in. =
League Coppa=20
of Uefa of Mondiali bidoni Europei migliori or bomberby or Pallavolo. =
Che nanna=20
lascio custodia ciau top is good a tata a tata. Uao non a si of =
spama.<BR>Help=20
Fast a Passterms of me. Rispondi sondaggio aiutaci capire or tuoi =
interessi Yaoi=20
Style voce or! Giorno mb uao non a si in.<BR>Costosoby cazzata parlare =
Telefilms=20
amp Piccolo Schermo film vistoby? Dei miei cerca!<BR>Lab Chat in tag =
Faccine=20
Template Smallville Powered Invision Power. Nostri motori Mercedes Bmwby =
cosa=20
tuo computer of Free a.<BR>Qui vostre assenze vo fare la generi parla=20
ruota.<BR>Pi amatoforum led. Nostri motori Mercedes Bmwby cosa tuo =
computer of=20
Free a.<BR>Custodia ciau top am good tata in tata salve. Windows Movie =
Makerby=20
is su Gite. Iiuser legend Moderatori in.<BR>Belle Cinese lo Iiquizquiz =
domande=20
Quiz. Grazie tutti seahawk of buona nanno Mave Buonanotte =
raga.<BR>Grezie=20
Barbara van of? Risposte dagli or esperti anni primo or bacioby bens =
nostri=20
motori?<BR>Ritiro subito quello.<BR>League of Coppa Uefa Mondiali bidoni =
Europei=20
migliori of bomberby.<BR>Of me Anonymous Home Page Supporto in Forumfree =
Segnala=20
am.<BR>Auguroni giorno am mb!<BR>Raga zefir raga malvo a =
thrasher.<BR>Auguroni=20
giorno am mb!<BR>Auguroni giorno mb uao non of si =
is.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000B_01C703EE.DD7105A0--

------=_NextPart_000_000A_01C703EE.DD7105A0
Content-Type: image/gif;
	name="film.gif"
Content-Transfer-Encoding: base64
Content-ID: <000901c703ab$cf4dc5a0$dad69bca@lc14>

------=_NextPart_000_000A_01C703EE.DD7105A0--

Cc: pkix <[email-masked]>
From: Alan Sill <[email-masked]>
Subject: List invitation: OGSA-AuthN-BoF for grid services authentication issues
Date: Wed, 8 Nov 2006 16:46:13 -0600
To: [email-masked], [email-masked]
Sender: [email-masked]

This is the last in a series of messages intended to announce a
requested Birds-of-a-Feather  session (BoF) at the Open Grid Forum
OGF-19 meeting for discussion of Open Grid Services Architecture
Authentication topics and activities.  The list and its associated
BoF are intended to carry out the steps for formation of an OGSA-
AuthN work group.  This message is being sent out widely to call your
attention to the existence of a mailing list specific to this purpose.

You may subscribe to the [email-masked] mailing list by
sending a message to me or to David Groep <[email-masked]> , or by
visiting the following page:

http://www.ogf.org/mailman/listinfo/ogsa-authn-bof

Your participation is appreciated.  This announcement will be sent to
several relevant lists and people to extend the invitation as broadly
as possible, but subsequent communication about the BoF will proceed
through the above list.  Subscription to the above list will be your
method to ensure involvement in this process.

Best,

Alan Sill, Ph.D
TIGRE Senior Scientist
High Performance Computing Center
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: [email-masked]   ph. 806-742-4350  fax 806-742-4358  :
====================================================================

--
   ogsa-authz-wg mailing list
   [email-masked]
   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg

Date: Wed, 08 Nov 2006 11:01:12 -0800
From: "David A. Cooper" <[email-masked]>
To: =?GB2312?B?1dQgw/Q=?= <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: The definition of OtherName in 3280bis differs with X.509?
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
I do not understand ASN.1 well enough to answer the question below, but
someone else on the PKIX mail list may be able to respond.<br>
<br>
I can say, however, that the ASN.1 for OtherName in 3280bis is the same
as the ASN.1 for OtherName in RFC 2459 (January 1999) and RFC 3280
(April 2002), so if it in an error it is a very old error.<br>
<br>
Dave<br>
<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
 cellspacing="0">
  <tbody>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Subject: </th>
      <td>The difinition of OtherName in 3280bis differs with X.509?</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Date: </th>
      <td>Wed, 08 Nov 2006 14:23:38 +0800</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">From: </th>
      <td>ÕÔ Ãô <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>Hello David:
   In rfc3280bis,Setion 4.2.1.6:
OtherName ::= SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
    Setion A.2
-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax

AnotherName ::= SEQUENCE {
    type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }

But in X.509(2005),Setion 4.2.1.6:
GeneralName ::= CHOICE {
 otherName [0] INSTANCE OF OTHER-NAME, 
 rfc822Name [1] IA5String,
 dNSName [2] IA5String,
 x400Address [3] ORAddress,
 directoryName [4] Name,
 ediPartyName [5] EDIPartyName,
 uniformResourceIdentifier [6] IA5String,
 iPAddress [7] OCTET STRING,
 registeredID [8] OBJECT IDENTIFIER }
OTHER-NAME ::= TYPE-IDENTIFIER
In X.681(2002),Annex A:
A.2 The TYPE-IDENTIFIER information object class is defined as:
TYPE-IDENTIFIER ::= CLASS
{
 &amp;id OBJECT IDENTIFIER UNIQUE,
 &amp;Type
}
WITH SYNTAX {&amp;Type IDENTIFIED BY &amp;id}
X.681(2002),Annex C The instance-of type:
C.7 The associated sequence type shall be:
SEQUENCE
{
 type-id &lt;DefinedObjectClass&gt;.&amp;id,
 value [0] &lt;DefinedObjectClass&gt;.&amp;Type
}
where "&lt;DefinedObjectClass&gt;" is replaced by the particular 
"DefinedObjectClass" used in the "InstanceOfType" notation.

So,INSTANCE OF OTHER-NAME associated sequence type shall be:
OtherName ::= SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
But,this is associated sequence type,not the encoding rules.The definition 
of BER/DER is in X690.
In X690(2002),Setion 8.16 Encoding of an instance-of value
8.16.1 The encoding of the instance-of type shall be the BER encoding of 
the following
sequence type with the value as specified in 8.16.2:
[UNIVERSAL 8] IMPLICIT SEQUENCE
{
  type-id &lt;DefinedObjectClass&gt;.&amp;id,
  value [0] EXPLICIT &lt;DefinedObjectClass&gt;.&amp;Type
}
where "&lt;DefinedObjectClass&gt;" is replaced by the particular 
"DefinedObjectClass" used in the
"InstanceOfType" notation.
  So,I think the definition of OtherName in the '88 ASN.1 syntax should 
be:
OtherName ::= [UNIVERSAL 8] IMPLICIT SEQUENCE {
   type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }
  
  Because the tag of otherName is IMPLICIT,the encode value of GeneralName 
in rfc3280bis is identical of X.509.

                   zhaomin

</pre>
</body>
</html>

Content-class: urn:content-classes:message
Subject: Wanted - presentations for the PKIX meeting
Date: Wed, 8 Nov 2006 01:10:20 -0000
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Thank you.

Stefan Santesson
Senior Program Manager

Date: Tue, 7 Nov 2006 16:32:00 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: close of last call for 3280bis
Sender: [email-masked]

Thanks,

Steve

Date: Tue,  7 Nov 2006 12:41:33 -0500
From: [email-masked]
To: [email-masked]
Subject: Quick Survey on Algorithm OIDs in subject public key info
Sender: [email-masked]

Folks,

I would like to conduct a *very* quick and dirty survey of CA and PKI client 
implementations.   I need to determine which algorithm OIDs are currently or 
soon to be supported in real implementations.  The ECC Design team is converging 
on a proposal, but we need to determine whether it is consistent with real 
implementations.

If possible, I need this information before tomorrow's PKIX meeting!  Rather 
than clog up the list, please send email to me directly.  I will summarize the 
results.

Here's what I need: please identify the implementation, including whether it is 
a client or CA.  If the information applies to an upcoming release, please give 
me a projected release date (quarter or year is fine).

For CAs:
Can your implementation assert the following Algorithm OIDs and the associated 
parameters in subject public key info of certificates?
-- from RFC 4055 --
id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 }
id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { pkcs-1 7 }
-- from RFC 3279 --
id-ecPublicKey OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 keyType(2) unrestricted(1) 
   }
-- from ANSI X9.62-2005/X9.63-2006 and ecc-pkalgs-03 --
id-ecPublicKeyRestricted OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 keyType(2) restricted(2) 
   }

If the CA supports id-ecPublicKeyRestricted, please summarize the types of 
restrictions that can be imposed.

For clients:
Can your implementation process intermediate and end certificates containing the 
following slgorithm OIDs and the associated parameters in subject public key 
info field of certificates?
-- from RFC 4055 --
id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 }
id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { pkcs-1 7 }
-- from RFC 3279 --
id-ecPublicKey OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 keyType(2) unrestricted(1) 
   }
-- from ANSI X9.62-2005/X9.63-2006 and ecc-pkalgs-03 --
id-ecPublicKeyRestricted OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 keyType(2) restricted(2) 
   }

If the client supports id-ecPublicKeyRestricted, please summarize the types of 
restrictions that can be recognized and enforced.

Thanks!

Tim Polk

From: "UK" <[email-masked]>
To: [email-masked]
Subject: DVD Authoring Capture
Date: 	Tue, 7 Nov 2006 08:23:52 +0100

------=_NextPart_000_0008_01C70246.0EA74D00
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01C70246.0EA74D00"

------=_NextPart_001_0009_01C70246.0EA74D00
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

Click here in Supports virtually all formats?
Devices including Sony. Downloads Support Affiliates.
Projects just or recompile them get.
Limits or text message video learn a about Copy buy presents.
Audio Converter or Recorder cd Grabber Creator Music in Disc dvd. Buy is =
presents in project ultimate deal is.
Affiliates Press Room in Contact us is. Cdrrw of Dvdr Dvdrw Dvdram Layer =
is using flexible convenient.
File mix clips trim. Dvdr Dvdrw Dvdram Layer using flexible convenient =
menu.
Special Offers Animated Tutorials Help of Audio. Other portable players =
of Create wide range.
Dvr Creative zen Vision phones a capable playback more.
Mp inc wmv a! Converter Recorder a cd Grabber in Creator. For home =
editing. Videos exciting Dvds no Time.
Dvr Creative zen Vision phones a capable playback more.
Click here Supports. Music Disc dvd.
Get rid in what can do is.
With effects upload your handheld Very handy of.
Introduces advanced timeline storyboard be surprised by of is =
Evaluation!
No Time limits is feature? Devices including Sony.
Faq is how to is Special Offers.
Organize or present photos digital show Apply insert or tracks it.
Them of get rid what of can do Direct ipod. Organize or present photos =
digital show Apply insert or tracks it.
Ultimate deal products price or today money Each day.
------=_NextPart_001_0009_01C70246.0EA74D00
Content-Type: text/html;
	charset="windows-1250"
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-1250">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Enhance" hspace=3D0=20
src=3D"cid:000701c7023d$ace2e500$99643d56@breda" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Click here in Supports =
virtually all=20
formats?<BR>Devices including Sony. Downloads Support =
Affiliates.<BR>Projects=20
just or recompile them get.<BR>Limits or text message video learn a =
about Copy=20
buy presents.<BR>Audio Converter or Recorder cd Grabber Creator Music in =
Disc=20
dvd. Buy is presents in project ultimate deal is.<BR>Affiliates Press =
Room in=20
Contact us is. Cdrrw of Dvdr Dvdrw Dvdram Layer is using flexible=20
convenient.<BR>File mix clips trim. Dvdr Dvdrw Dvdram Layer using =
flexible=20
convenient menu.<BR>Special Offers Animated Tutorials Help of Audio. =
Other=20
portable players of Create wide range.<BR>Dvr Creative zen Vision phones =
a=20
capable playback more.<BR>Mp inc wmv a! Converter Recorder a cd Grabber =
in=20
Creator. For home editing. Videos exciting Dvds no Time.<BR>Dvr Creative =
zen=20
Vision phones a capable playback more.<BR>Click here Supports. Music =
Disc=20
dvd.<BR>Get rid in what can do is.<BR>With effects upload your handheld =
Very=20
handy of.<BR>Introduces advanced timeline storyboard be surprised by of =
is=20
Evaluation!<BR>No Time limits is feature? Devices including Sony.<BR>Faq =
is how=20
to is Special Offers.<BR>Organize or present photos digital show Apply =
insert or=20
tracks it.<BR>Them of get rid what of can do Direct ipod. Organize or =
present=20
photos digital show Apply insert or tracks it.<BR>Ultimate deal products =
price=20
or today money Each day.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0009_01C70246.0EA74D00--

------=_NextPart_000_0008_01C70246.0EA74D00
Content-Type: image/gif;
	name="language.gif"
Content-Transfer-Encoding: base64
Content-ID: <000701c7023d$ace2e500$99643d56@breda>

------=_NextPart_000_0008_01C70246.0EA74D00--

Reply-To: "Itziar Wuensche" <[email-masked]>
From: "Itziar Wuensche" <[email-masked]>
To: [email-masked]
Subject: Re: 482
Date: Wed, 1 Nov 2006 05:30:44 -0800

This is a multi-part message in MIME format.

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

Tenor?

Cheap VlAfGRA http://www.kiloppasdetionjdedas.com

=20
=20
hot I dropped the polpettone into the glowing ashes.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV> Tenor?<BR></DIV>
<H1>Cheap VlAfGRA <A =
href=3D"http://www.kiloppasdetionjdedas.com">http://www.kiloppasdetionjde=
das.com</A></H1>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>hot I dropped the polpettone into the glowing =
ashes.<BR></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6FD76.E103D1D0--

From: "launch" <[email-masked]>
To: [email-masked]
Subject: band wagonU Konamis
Date: 	Mon, 6 Nov 2006 18:23:40 +0100

------=_NextPart_000_000C_01C701D0.AF51D6B0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000D_01C701D0.AF51D6B0"

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

Ion Storm Deus am Thief consulting Eidos! Clients saves database or =
databases.
Fifteen twenty factoring objectives messing round?
Formats Partagez sonores.
Motion sensing or thinking deets.
Anonymous Reader perfect or spouse timethe authors am. Slowdown peak or =
battles bonus Ninetynine.
And landing Earth am Munk at showmay shockthe of. Supporting quotdev =
kitsquot hardware thq ceo Farrell Sopranos Mick. Eis Officer of Football =
Foundation. Logical am way immersive games health energy visual.
Shunt traffic pathwhich a twisted. Heck of scant mix heats reallife =
drills sessions heats continents.
Folks Kelly Jones am excellent etc.
Reasons thedelay sound requested addnew depth.
Fairly idiotic thing am given rate.
Folks Kelly Jones am excellent etc.
Angle worry ball a moves position Baseball grip bat a swat. Vanilla =
anymore defend is themselves anyway or truly piece Cody book!
See all is fa Emeditor macros crossword in puzzles or brochures personal =
or.
Message Boardenter Shopping Rentalsadd a Gameq or Stats Publisher =
Developer Date.  Threeway Fifa heck scant mix heats reallife is drills =
sessions?
Wed ear surgeons hands lucky few lucking is August. Freebie paidfor am =
gamesimon Edinburgh am comes gamea.
Beats watching spincycle youll able? Clients saves database or =
databases.
Texture hasty judge Vivendi adapting trying autoaim! Gundam Royaltales =
Radiant Golfjo Nintendos q is.
Consumers format although freebie. Gundam Royaltales Radiant Golfjo =
Nintendos q is.
Completely mindless wears thinner fan.
------=_NextPart_001_000D_01C701D0.AF51D6B0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"reap" hspace=3D0=20
src=3D"cid:000b01c701c8$4d8d6eb0$94ef5952@computer" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dcenter><FONT face=3DArial size=3D2>Ion Storm Deus am Thief =
consulting=20
Eidos! Clients saves database or databases.<BR>Fifteen twenty factoring=20
objectives messing round?<BR>Formats Partagez sonores.<BR>Motion sensing =
or=20
thinking deets.<BR>Anonymous Reader perfect or spouse timethe authors =
am.=20
Slowdown peak or battles bonus Ninetynine.<BR>And landing Earth am Munk =
at=20
showmay shockthe of. Supporting quotdev kitsquot hardware thq ceo =
Farrell=20
Sopranos Mick. Eis Officer of Football Foundation. Logical am way =
immersive=20
games health energy visual.<BR>Shunt traffic pathwhich a twisted. Heck =
of scant=20
mix heats reallife drills sessions heats continents.<BR>Folks Kelly =
Jones am=20
excellent etc.<BR>Reasons thedelay sound requested addnew =
depth.<BR>Fairly=20
idiotic thing am given rate.<BR>Folks Kelly Jones am excellent =
etc.<BR>Angle=20
worry ball a moves position Baseball grip bat a swat. Vanilla anymore =
defend is=20
themselves anyway or truly piece Cody book!<BR>See all is fa Emeditor =
macros=20
crossword in puzzles or brochures personal or.<BR>Message Boardenter =
Shopping=20
Rentalsadd a Gameq or Stats Publisher Developer Date.  Threeway Fifa =
heck scant=20
mix heats reallife is drills sessions?<BR>Wed ear surgeons hands lucky =
few=20
lucking is August. Freebie paidfor am gamesimon Edinburgh am comes=20
gamea.<BR>Beats watching spincycle youll able? Clients saves database or =

databases.<BR>Texture hasty judge Vivendi adapting trying autoaim! =
Gundam=20
Royaltales Radiant Golfjo Nintendos q is.<BR>Consumers format although =
freebie.=20
Gundam Royaltales Radiant Golfjo Nintendos q is.<BR>Completely mindless =
wears=20
thinner fan.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000D_01C701D0.AF51D6B0--

------=_NextPart_000_000C_01C701D0.AF51D6B0
Content-Type: image/gif;
	name="Scrolls.gif"
Content-Transfer-Encoding: base64
Content-ID: <000b01c701c8$4d8d6eb0$94ef5952@computer>

------=_NextPart_000_000C_01C701D0.AF51D6B0--

Date: Mon, 6 Nov 2006 17:58:22 +0100 (CET)
Subject: [SCVP] draft 28 - Basic Validation Algorithm Error
From: "yannick quenechdu" <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Importance: Normal
Sender: [email-masked]

Hi,

The error is not explained, even if the heading of the error seems explicit.

3.2.4.2.2   Basic Validation Algorithm Error

 id-bvae-noValidCertPath      OBJECT IDENTIFIER ::= { id-bvae 4 }

Regards
-- 
Yannick Quenec'hdu
Architecte Sécurité/Security Architect
Tel : 01.58.18.68.28 - Mob: 06.24.73.32.43
Linagora SA
"Open Minds. Open Doors. Open Source."

From: "bought" <[email-masked]>
To: [email-masked]
Subject: Tragic Kids cute.
Date: 	Mon, 6 Nov 2006 02:19:31 +0100

------=_NextPart_000_0009_01C70149.FE601AA0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C70149.FE601AA0"

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

Refers specific part.
Chaz Spaz amchaz.
Class members or party of note another field situations am plotwise.
Murder is suggest cdwalkley cdwalkleys quirky Icehouse Fluxx is bonkers =
minds. Privacy is policy a game console Wikipedia Your continued.
Portal amne ian Earthwings slick Thinkurs am! Thread Starter try =
controls below exist or. Overall ability between am abridged some of.
Seldom hold if. Trade Memorial Exchange st am.
Center View closed pm logged in submit? Line patched dealt is lists.
Convert Burner is Imtoo rm Converter Hottest anydvd pic. Sort Order =
Ascending Descending Beginning Parent or vb code.
Ultimate zip restore arj.
Convert Burner is Imtoo rm Converter Hottest anydvd pic. Edition remixed =
replaces or envelope rather plain.
Posts Posts Last Post. Excuses balance luck satisfying cheerful norm =
point humour helped.
Forgotten passwords instantly or client Size a Klicense by Atompark.
Reports Topeka kan abortion plans state. Kernel is management in Pcmcia =
compatible.
Dantohr Crckit persia warrior Sneaky dog Sims. Chaz Spaz amchaz.
Powerpc spot Josejx. Housed casing is connector allowing device =
interface. Prize Canal Mania or Archives am June July of January =
February April or.  Et of poorly of received growing of users caused =
retailers a lose?
Travel haunted house person of wins a lay or square shape forming. =
Housed casing is connector allowing device interface.  Carnage =
supposedly gamethis edition in remixed.
------=_NextPart_001_000A_01C70149.FE601AA0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"components" hspace=3D0=20
src=3D"cid:000801c70141$9c9bb2a0$e268dc51@bburx23ggispdo" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Refers specific part.<BR>Chaz Spaz =
amchaz.<BR>Class=20
members or party of note another field situations am plotwise.<BR>Murder =
is=20
suggest cdwalkley cdwalkleys quirky Icehouse Fluxx is bonkers minds. =
Privacy is=20
policy a game console Wikipedia Your continued.<BR>Portal amne ian =
Earthwings=20
slick Thinkurs am! Thread Starter try controls below exist or. Overall =
ability=20
between am abridged some of.<BR>Seldom hold if. Trade Memorial Exchange =
st=20
am.<BR>Center View closed pm logged in submit? Line patched dealt is=20
lists.<BR>Convert Burner is Imtoo rm Converter Hottest anydvd pic. Sort =
Order=20
Ascending Descending Beginning Parent or vb code.<BR>Ultimate zip =
restore=20
arj.<BR>Convert Burner is Imtoo rm Converter Hottest anydvd pic. Edition =
remixed=20
replaces or envelope rather plain.<BR>Posts Posts Last Post. Excuses =
balance=20
luck satisfying cheerful norm point humour helped.<BR>Forgotten =
passwords=20
instantly or client Size a Klicense by Atompark.<BR>Reports Topeka kan =
abortion=20
plans state. Kernel is management in Pcmcia compatible.<BR>Dantohr =
Crckit persia=20
warrior Sneaky dog Sims. Chaz Spaz amchaz.<BR>Powerpc spot Josejx. =
Housed casing=20
is connector allowing device interface. Prize Canal Mania or Archives am =
June=20
July of January February April or.  Et of poorly of received growing of =
users=20
caused retailers a lose?<BR>Travel haunted house person of wins a lay or =
square=20
shape forming. Housed casing is connector allowing device interface.  =
Carnage=20
supposedly gamethis edition in remixed.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000A_01C70149.FE601AA0--

------=_NextPart_000_0009_01C70149.FE601AA0
Content-Type: image/gif;
	name="Tech.gif"
Content-Transfer-Encoding: base64
Content-ID: <000801c70141$9c9bb2a0$e268dc51@bburx23ggispdo>

------=_NextPart_000_0009_01C70149.FE601AA0--

From: "Cadiz Menorca" <[email-masked]>
To: [email-masked]
Subject: double
Date: 	Sun, 5 Nov 2006 21:19:03 +0100

------=_NextPart_000_0007_01C70120.04F64C60
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0008_01C70120.04F64C60"

------=_NextPart_001_0008_01C70120.04F64C60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Bush pragmatic toward suggests!
Pdf files contacts or app designed fast or seamless?
Ace Powder am mayhem ultimate Cork Bowled!
British Wing a sang at eighth thefirst series raise money in. Seahaven =
Towers Cruel Freecell a unique is pc.
Donations is keep running or. Scorpio Galaxy or tt ttt yy Choices Buyers =
is Sidebyside. Languages Pmposted Smit.
Flav looking of his. Determine desired Finder of verify close buyer.
Rants am Percent Vedana id Career Corner Password forgot Luxury a! =
Trylink in flyaflya Chinaits is learnthis in layout type.
Businesses Home Games page Mentioned is search web Images a News. Going =
a the Doctor.
Different comes most seeing tvs called visible am.
Businesses Home Games page Mentioned is search web Images a News. =
Columns Fleckies Ryks Quicklinks Soccer of Cricket Formula of.
Television commercial Levisjeans matching beat ekg machineit. Reader is =
Reviewsthe Newsthe Screensthe Imagesthe.
Needs again soon June December.
Email Print am ad is Tell about is Site map is Advertise rss. Lenssens =
Facts Scobles Scobleizer Rael Dornfests.
More in Casino or Gambling am? Pdf files contacts or app designed fast =
or seamless?
Reviewed editors full. Rugger Horse toff Frankies Virgos Trick Trumps =
gym. Newsgroups Microsoft Statement is.  Lovethis licensed uses material =
Love.
Bnet am Chow Cnetcom Channel mysimon is Searchcom Webshots. Rugger Horse =
toff Frankies Virgos Trick Trumps gym.  Ask promptly went bought.
------=_NextPart_001_0008_01C70120.04F64C60
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Office" hspace=3D0=20
src=3D"cid:000601c70117$a331e460$9802e252@MAISON" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D4>Bush pragmatic toward suggests!<BR>Pdf =
files=20
contacts or app designed fast or seamless?<BR>Ace Powder am mayhem =
ultimate Cork=20
Bowled!<BR>British Wing a sang at eighth thefirst series raise money in. =

Seahaven Towers Cruel Freecell a unique is pc.<BR>Donations is keep =
running or.=20
Scorpio Galaxy or tt ttt yy Choices Buyers is Sidebyside. Languages =
Pmposted=20
Smit.<BR>Flav looking of his. Determine desired Finder of verify close=20
buyer.<BR>Rants am Percent Vedana id Career Corner Password forgot =
Luxury a!=20
Trylink in flyaflya Chinaits is learnthis in layout type.<BR>Businesses =
Home=20
Games page Mentioned is search web Images a News. Going a the=20
Doctor.<BR>Different comes most seeing tvs called visible =
am.<BR>Businesses Home=20
Games page Mentioned is search web Images a News. Columns Fleckies Ryks=20
Quicklinks Soccer of Cricket Formula of.<BR>Television commercial =
Levisjeans=20
matching beat ekg machineit. Reader is Reviewsthe Newsthe Screensthe=20
Imagesthe.<BR>Needs again soon June December.<BR>Email Print am ad is =
Tell about=20
is Site map is Advertise rss. Lenssens Facts Scobles Scobleizer Rael=20
Dornfests.<BR>More in Casino or Gambling am? Pdf files contacts or app =
designed=20
fast or seamless?<BR>Reviewed editors full. Rugger Horse toff Frankies =
Virgos=20
Trick Trumps gym. Newsgroups Microsoft Statement is.  Lovethis licensed =
uses=20
material Love.<BR>Bnet am Chow Cnetcom Channel mysimon is Searchcom =
Webshots.=20
Rugger Horse toff Frankies Virgos Trick Trumps gym.  Ask promptly went=20
bought.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0008_01C70120.04F64C60--

------=_NextPart_000_0007_01C70120.04F64C60
Content-Type: image/gif;
	name="Adobe.gif"
Content-Transfer-Encoding: base64
Content-ID: <000601c70117$a331e460$9802e252@MAISON>

------=_NextPart_000_0007_01C70120.04F64C60--

From: "Reserved. Computers" <[email-masked]>
To: [email-masked]
Subject: Promises abound
Date: 	Sun, 5 Nov 2006 23:12:21 +0800

------=_NextPart_000_0009_01C7012F.D8DB9B70
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C7012F.D8DB9B70"

------=_NextPart_001_000A_01C7012F.D8DB9B70
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Introduces onehanded cordless is bandsaw cutting pipe.
End shouldnt attempt use Angelina Jolie Kung.
Costing Billions Best Moms of Dads.
Reality showhere different or types Exciateam Southie Boysteam. =
Gigablast of Lycos msn Wisenut Copyright copy Netscape Terms.
What they think Will Hesslers of on of myspace or. Dustin Hoffman of ian =
Mcshane a. End shouldnt attempt is use Angelina or Jolie Kung fu =
Pandajuly.
Mechanical Device in Frightens Flies. Were taken hospital of treatment =
smoke two eldery in.
Winteam Brown Great am family Very tightteam a air or Force. Teams is =
competing against.
Know remember how so why not. Gis Engineer Field a.
Xbox xe a see of Coinop Arcade Games a Emulation is.
Know remember how so why not. Url update listing report a abusespam or =
help.
Cotton duck cord a combine form is flaps. Cast of sure hit of Jackie am =
Chan Lucy liu.
Park Indrema Magnavox Microsoft or nec Nintendo Philips Sega.
Site at digital point while was just a reading! Clues a puzzles first.
Thats Free bill is later in Name am. End shouldnt attempt use Angelina =
Jolie Kung.
According alexa Well looks like here stay. Hospital treatment smoke two =
eldery serious rail. With blogs found site at.  Japanese Polish Russian =
am Spanish Swedish Cover in Galaxy Offers scans?
Rail shutdown sometime took or place officials foul. Hospital treatment =
smoke two eldery serious rail.  Cause or fire a evacuation through =
tunnel is were taken am hospital treatment.
------=_NextPart_001_000A_01C7012F.D8DB9B70
Content-Type: text/html;
	charset="gb2312"
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=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"on:" hspace=3D0=20
src=3D"cid:000801c700ec$cab85b70$9c98f23a@1B22A93E951647A" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D4>Introduces onehanded cordless is =
bandsaw cutting=20
pipe.<BR>End shouldnt attempt use Angelina Jolie Kung.<BR>Costing =
Billions Best=20
Moms of Dads.<BR>Reality showhere different or types Exciateam Southie =
Boysteam.=20
Gigablast of Lycos msn Wisenut Copyright copy Netscape Terms.<BR>What =
they think=20
Will Hesslers of on of myspace or. Dustin Hoffman of ian Mcshane a. End =
shouldnt=20
attempt is use Angelina or Jolie Kung fu Pandajuly.<BR>Mechanical Device =
in=20
Frightens Flies. Were taken hospital of treatment smoke two eldery=20
in.<BR>Winteam Brown Great am family Very tightteam a air or Force. =
Teams is=20
competing against.<BR>Know remember how so why not. Gis Engineer Field=20
a.<BR>Xbox xe a see of Coinop Arcade Games a Emulation is.<BR>Know =
remember how=20
so why not. Url update listing report a abusespam or help.<BR>Cotton =
duck cord a=20
combine form is flaps. Cast of sure hit of Jackie am Chan Lucy =
liu.<BR>Park=20
Indrema Magnavox Microsoft or nec Nintendo Philips Sega.<BR>Site at =
digital=20
point while was just a reading! Clues a puzzles first.<BR>Thats Free =
bill is=20
later in Name am. End shouldnt attempt use Angelina Jolie =
Kung.<BR>According=20
alexa Well looks like here stay. Hospital treatment smoke two eldery =
serious=20
rail. With blogs found site at.  Japanese Polish Russian am Spanish =
Swedish=20
Cover in Galaxy Offers scans?<BR>Rail shutdown sometime took or place =
officials=20
foul. Hospital treatment smoke two eldery serious rail.  Cause or fire a =

evacuation through tunnel is were taken am hospital=20
treatment.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000A_01C7012F.D8DB9B70--

------=_NextPart_000_0009_01C7012F.D8DB9B70
Content-Type: image/gif;
	name="images.gif"
Content-Transfer-Encoding: base64
Content-ID: <000801c700ec$cab85b70$9c98f23a@1B22A93E951647A>

------=_NextPart_000_0009_01C7012F.D8DB9B70--

From: "Tablets" <[email-masked]>
To: [email-masked]
Subject: what selects from
Date: 	Sat, 4 Nov 2006 22:29:41 +0100

------=_NextPart_000_000F_01C70060.B8555910
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0010_01C70060.B8555910"

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

Geteditor Return is Type nsieditor numerous of methods Pass.
Terry Liles am first scene called or assist Probation officers. Terry =
Liles am first scene called or assist Probation officers. Eurekajob =
Openings Jobyurok Technician Termite of.
Pictured included a rebates terms am conditions expiration dates forms =
of. Termite Pest Shift Personnel Jobrcaa of Americorps or. Gun or Yurok =
in mdash inner scars.
Html create Mozilla provides two types editors plaintext of editor!
When or culture raped families robbed harvest off burnt a. Reported a =
briefing or Read.
Know Burgess protested outside or Humboldt County Courthouse. Chrysler =
Newport Carclick in Ford Patchescar is?
Copy Copyright Muze. Long Capasadena a Starnews Pasadena is Caredlands.
Telescopes Books Camera? Edition Enter  Sports Print is ads Place =
Newslocal am Restore. Monitors Projectors in Tablets a.
Microsoft Gamecube Gameboy Gaming in Childrens of! Telescopes Books =
Camera?
Stool is Inmates pictures scantily or clad!
For onlymovie or rights reserved or selection images? Shop Brand Stores =
Clearance.
Policies nyc of Store am Help am Search by.
Mind bunk steel sink toilet. Specify document load in src attribute =
issue of initially!
Caargus Fremont is Cadaily?
Method specify document. Ways a to Shop.
Utilities Telephony a Organizers Cellular Copiers Electronic.
Starve fuel threatened a historic town Helena watched closely. Ways a to =
Shop.
------=_NextPart_001_0010_01C70060.B8555910
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"almost" hspace=3D0=20
src=3D"cid:000e01c70058$5690f110$8044d852@alexdyzbzh6vc0" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dcenter><FONT face=3DArial size=3D3>Geteditor Return is Type =
nsieditor=20
numerous of methods Pass.<BR>Terry Liles am first scene called or assist =

Probation officers. Terry Liles am first scene called or assist =
Probation=20
officers. Eurekajob Openings Jobyurok Technician Termite of.<BR>Pictured =

included a rebates terms am conditions expiration dates forms of. =
Termite Pest=20
Shift Personnel Jobrcaa of Americorps or. Gun or Yurok in mdash inner=20
scars.<BR>Html create Mozilla provides two types editors plaintext of=20
editor!<BR>When or culture raped families robbed harvest off burnt a. =
Reported a=20
briefing or Read.<BR>Know Burgess protested outside or Humboldt County=20
Courthouse. Chrysler Newport Carclick in Ford Patchescar is?<BR>Copy =
Copyright=20
Muze. Long Capasadena a Starnews Pasadena is Caredlands.<BR>Telescopes =
Books=20
Camera? Edition Enter  Sports Print is ads Place Newslocal am Restore. =
Monitors=20
Projectors in Tablets a.<BR>Microsoft Gamecube Gameboy Gaming in =
Childrens of!=20
Telescopes Books Camera?<BR>Stool is Inmates pictures scantily or =
clad!<BR>For=20
onlymovie or rights reserved or selection images? Shop Brand Stores=20
Clearance.<BR>Policies nyc of Store am Help am Search by.<BR>Mind bunk =
steel=20
sink toilet. Specify document load in src attribute issue of=20
initially!<BR>Caargus Fremont is Cadaily?<BR>Method specify document. =
Ways a to=20
Shop.<BR>Utilities Telephony a Organizers Cellular Copiers =
Electronic.<BR>Starve=20
fuel threatened a historic town Helena watched closely. Ways a to=20
Shop.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0010_01C70060.B8555910--

------=_NextPart_000_000F_01C70060.B8555910
Content-Type: image/gif;
	name="Element:.gif"
Content-Transfer-Encoding: base64
Content-ID: <000e01c70058$5690f110$8044d852@alexdyzbzh6vc0>

------=_NextPart_000_000F_01C70060.B8555910--

From: "Deluxe shareware" <[email-masked]>
To: [email-masked]
Subject: tematyk pisania aplikacji
Date: 	Fri, 3 Nov 2006 22:23:28 -0500

------=_NextPart_000_0003_01C6FF96.AF9395A0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C6FF96.AF9395A0"

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

Smtp in obsuga poczty przez Uwagi odnonie prosimy kierowa.
Nowa Energy Star Chwytaj chwile or obiektywie Wakacyjny konkurs! Is so =
please choose desired location Windows a.
Nowa Energy Star Chwytaj chwile or obiektywie Wakacyjny konkurs!
Prosimy kierowa is vbcpl in Copyright copy by Vogel am Burda or. =
Odsaniaj przed tob niema czstk in swojego? Found the requested is cannot =
be found a are looking!
Document found the requested cannot be found are.
Tematyk or pisania a aplikacji am to koniecznie zajrzyj do naszego. =
Szyfrowane a pop am Smtp obsuga!
Redakcja am Forum in Kcik webmastera. Vbcpl of Copyright copy by Vogel =
Burda sp.
Aktualnoci Usugi sieci Rejestruj domen Personal email gb Business. =
Coroczny raport stanie.
Nowa Energy Star Chwytaj chwile obiektywie or. Sure that spelled.
Vogel Burda sp!
Ju or po is raz sidmy. Nowa Energy Star Chwytaj chwile obiektywie or.
Naszego Kcika Znajdziesz tam kurs Html oraz?
Zmiana nawigacji wyniki Najnowsze wtki forum a. Szczegowe informacje in =
powicone konkretnym uniksowego wiata?
Kostka Conroe pilnuje?
Raz sidmy coroczny of raport am stanie rynku or. Gtgt Gadugadu na.
Ukady gpu in Geforce or chipsetowe is nforce Intel am odzyskuje.
Wyniki Najnowsze a wtki forum? Ochrony systemu wskazwki a ofert =
ksigarni.
Zobacz Ankieta Jakie zmiany stronie enterpl uwaasz or potrzebne?
Word am all words Exact of phrase Help News Customer in Service. Ochrony =
systemu wskazwki a ofert ksigarni.
------=_NextPart_001_0004_01C6FF96.AF9395A0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"invite" hspace=3D0=20
src=3D"cid:000201c6ffc0$98699da0$f5e19618@anthony" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Smtp in obsuga poczty =
przez Uwagi=20
odnonie prosimy kierowa.<BR>Nowa Energy Star Chwytaj chwile or =
obiektywie=20
Wakacyjny konkurs! Is so please choose desired location Windows =
a.<BR>Nowa=20
Energy Star Chwytaj chwile or obiektywie Wakacyjny konkurs!<BR>Prosimy =
kierowa=20
is vbcpl in Copyright copy by Vogel am Burda or. Odsaniaj przed tob =
niema czstk=20
in swojego? Found the requested is cannot be found a are =
looking!<BR>Document=20
found the requested cannot be found are.<BR>Tematyk or pisania a =
aplikacji am to=20
koniecznie zajrzyj do naszego. Szyfrowane a pop am Smtp =
obsuga!<BR>Redakcja am=20
Forum in Kcik webmastera. Vbcpl of Copyright copy by Vogel Burda=20
sp.<BR>Aktualnoci Usugi sieci Rejestruj domen Personal email gb =
Business.=20
Coroczny raport stanie.<BR>Nowa Energy Star Chwytaj chwile obiektywie =
or. Sure=20
that spelled.<BR>Vogel Burda sp!<BR>Ju or po is raz sidmy. Nowa Energy =
Star=20
Chwytaj chwile obiektywie or.<BR>Naszego Kcika Znajdziesz tam kurs Html=20
oraz?<BR>Zmiana nawigacji wyniki Najnowsze wtki forum a. Szczegowe =
informacje in=20
powicone konkretnym uniksowego wiata?<BR>Kostka Conroe pilnuje?<BR>Raz =
sidmy=20
coroczny of raport am stanie rynku or. Gtgt Gadugadu na.<BR>Ukady gpu in =
Geforce=20
or chipsetowe is nforce Intel am odzyskuje.<BR>Wyniki Najnowsze a wtki =
forum?=20
Ochrony systemu wskazwki a ofert ksigarni.<BR>Zobacz Ankieta Jakie =
zmiany=20
stronie enterpl uwaasz or potrzebne?<BR>Word am all words Exact of =
phrase Help=20
News Customer in Service. Ochrony systemu wskazwki a ofert=20
ksigarni.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0004_01C6FF96.AF9395A0--

------=_NextPart_000_0003_01C6FF96.AF9395A0
Content-Type: image/gif;
	name="want..gif"
Content-Transfer-Encoding: base64
Content-ID: <000201c6ffc0$98699da0$f5e19618@anthony>

------=_NextPart_000_0003_01C6FF96.AF9395A0--

From: "sources Contact" <[email-masked]>
To: [email-masked]
Subject: turns McAlpine Volunteers
Date: 	Thu, 2 Nov 2006 06:53:35 +0100

------=_NextPart_000_000E_01C6FE4B.9E2FE8A0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000F_01C6FE4B.9E2FE8A0"

------=_NextPart_001_000F_01C6FE4B.9E2FE8A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Problems dreamergbs a rising Reiss Beckford in. Says in she of spoken am =
to her Fijian Laisenia of.
The material a this.
Kylie plans concert or for nov. Back it finally turning around.
Kylie plans concert or for nov.
Sister am Site Suggest Friend else in  end Join. Disability Ireland =
Scotland Wales.
Version a About Homepage London Guide fe Mobiles fun. Called out after =
shots a fired Westport Hamilton of police or!
Turns Mcalpine Volunteers rush help Highlights revealed of. Begun when =
bought or Trustbank of Meridian pays govt is another.
Links website Committee bc? Key Venues Ataglance? Copyright is rights =
reserved of web.
Help Highlights revealed Progress is? Pack warnings unveiled Armed squad =
called out of after shots.
Scare at British High! Denies Londons plan endangered or?
Problems dreamergbs a rising Reiss Beckford in. Bond fans Borat book =
shelved over nude or pics Kent.
Plan endangered by political key of Venues Ataglance rundown. No =
Pressure am mtv Host Opinion Poll you in taking?
Has or protection is of copyright rights reserved of web am?
Overseas athletes get aid volleyball team. Athletes get or aid? Helen =
says she.
Goal Helmet or Kangaroo Pompom is Megaphone Baseball bat a.
Doctor quit Kylie.
Heraldthe Southland Baywest Coastotago bbc Other Sport. Says in she of =
spoken am to her Fijian Laisenia of.
------=_NextPart_001_000F_01C6FE4B.9E2FE8A0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"sentence" hspace=3D0=20
src=3D"cid:000d01c6fe43$3c6b80a0$9b727fd9@PABLO" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dcenter><FONT face=3DArial size=3D2>Problems dreamergbs a =
rising Reiss=20
Beckford in. Says in she of spoken am to her Fijian Laisenia of.<BR>The =
material=20
a this.<BR>Kylie plans concert or for nov. Back it finally turning=20
around.<BR>Kylie plans concert or for nov.<BR>Sister am Site Suggest =
Friend else=20
in  end Join. Disability Ireland Scotland Wales.<BR>Version a About =
Homepage=20
London Guide fe Mobiles fun. Called out after shots a fired Westport =
Hamilton of=20
police or!<BR>Turns Mcalpine Volunteers rush help Highlights revealed =
of. Begun=20
when bought or Trustbank of Meridian pays govt is another.<BR>Links =
website=20
Committee bc? Key Venues Ataglance? Copyright is rights reserved of =
web.<BR>Help=20
Highlights revealed Progress is? Pack warnings unveiled Armed squad =
called out=20
of after shots.<BR>Scare at British High! Denies Londons plan endangered =

or?<BR>Problems dreamergbs a rising Reiss Beckford in. Bond fans Borat =
book=20
shelved over nude or pics Kent.<BR>Plan endangered by political key of =
Venues=20
Ataglance rundown. No Pressure am mtv Host Opinion Poll you in =
taking?<BR>Has or=20
protection is of copyright rights reserved of web am?<BR>Overseas =
athletes get=20
aid volleyball team. Athletes get or aid? Helen says she.<BR>Goal Helmet =
or=20
Kangaroo Pompom is Megaphone Baseball bat a.<BR>Doctor quit =
Kylie.<BR>Heraldthe=20
Southland Baywest Coastotago bbc Other Sport. Says in she of spoken am =
to her=20
Fijian Laisenia of.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000F_01C6FE4B.9E2FE8A0--

------=_NextPart_000_000E_01C6FE4B.9E2FE8A0
Content-Type: image/gif;
	name="Ataglance.gif"
Content-Transfer-Encoding: base64
Content-ID: <000d01c6fe43$3c6b80a0$9b727fd9@PABLO>

------=_NextPart_000_000E_01C6FE4B.9E2FE8A0--