Subject: SMIME Capabilities in X.509 certificates.

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 2 Apr 2004 18:47:55 +0100

All,

I would like to revisit a subject that has been discussed in the passed
as consideration for future work.

The SMIME Capabilities attribute, defined in PKCS#9 is used in CMS as a
signedAttribute (RFC 2633, 2.5.2 SMIMECapabilities Attribute) to carry
information about the cryptographic capabilities of an entity.

However the use of this extension can also be useful to carry inside a
certificate to communicate primary capabilities in situation where no
other prior knowledge of the other party exist.

There are of course cases where it is unsuitable to include such
information in certificates, e.g. where the capabilities changes over
time within the validity period of the certificate, but there are
without doubt situations where it is useful.

Microsoft has since long successfully used the PKCS#9 attribute OID to
also identify a certificate extension with the same syntax of this
attribute, to include this information in certificates. I would
therefore suggest that PKIX consider standardizing this practice.

This may also be an issue for the update of RFC 2632 dependent on this
work group's opinion.

Stefan Santesson

Program Manager, Windows Security

Principal Consultant, Microsoft Denmark

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Apr 2004 13:33:59 -0400

Stefan,

There have been no responses on the list to your proposal. I think it 
would help to give examples of what sorts of info you envision in the 
extension, starting with what MS has put in certs under using this 
extension. Also note that this might be the topic of a separate RFC, 
or part of a 3280 update, but not a new work item unless the 
cognizant AD agrees.

Steve

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 29 Apr 2004 19:24:02 +0100

David,

Comment in line;

> -----Original Message-----
> From: David A. Cooper [mailto:[email-masked]]
> Sent: den 29 april 2004 10:59
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: SMIME Capabilities in X.509 certificates.
> 
> Stefan,
> 
> Given that SMIMECapabilities is an Attribute, why not put it in the
> SubjectDirectoryAttributes extension rather than trying to treat it as
a
> certificate extension?

Well, today we put this as an extension. In general this is not a
suitable directory attribute since it has to be signed. Manipulating
this attribute for a subject could have security implications.

Having said that, I would wait with the HOW discussions until we have
decided IF we want to standardize this practice at all.

> 
> It's not clear to me how this extension would be populated.  How does
> the CA know the S/MIME capabilities of the certificate subject?  Does
> the CA assume that the capabilities are the same for all of its
> subscribers or does the subscriber specify this information in the
> certificate request?  The CA can't populate the attribute on its own
> unless it really knows what e-mail client software every subscriber is
> using.  Otherwise the contents of the attribute wouldn't be very
> useful.  In theory, the contents of the attribute could reflect the
> capabilities of the subscriber if the subscriber specified the
> contents.  But, I don't see how this would work in practice unless the
> subscriber's e-mail client generated the certificate request, which
> doesn't seem realistic.

I would turn it around. Some CAs actually has access to this information
about users, especially if the CA is a local enterprise CA with access
to local policies for users. In this case, the inclusion is straight
forward and sufficiently accurate.

Since there without doubts are ways where the CA can know this
information, the interesting question is whether the world would benefit
from a standard way to read this information from a certificate, if the
CA has chosen to put it there, which many CAs already do.

Again I would repeat that the use of this information is just a last
resource in the situations where no other knowledge is available.

> Besides, if the information in the SMIMECapabilities attribute is only
> of use to S/MIME clients, shouldn't this be an S/MIME working group
> consideration rather than PKIX?

That is not for me to decide. I have been asked to post this to PKIX
since it is a certificate format issue, but if this is to be done, it
will absolutely also has an intersection with SMIME.

/Stefan

> 
> Dave
> 
> Stefan Santesson wrote:
> 
> >OK Steve.
> >
> >Let me try to recap this issue and see if we at least can get to a
> >debate whether this is worth doing or not.
> >
> >The issue on the table is whether it should be a standardized option
to
> >include the SMIME capability attribute in a certificate.
> >
> >Microsoft is currently supporting inclusion of this attribute in
> >certificates using the standard PKCS#9 OID as extension OID and thus
> >using the standard PKCS#9 attribute syntax as extension syntax.
> >
> >This extension, when present in certificates is used as the last
> >resource to figure out the appropriate configuration/capabilities of
an
> >S/MIME opponent before falling back to default configuration for
unknown
> >users.
> >
> >This is useful in particular when an encrypted e-mail is sent to a
> >recipient whose certificate is known but where the recipient's
> >capabilities otherwise are unknown.
> >
> >But if there is a known previous S/MIME message from the recipient
from
> >which the recipient's capabilities can be extracted, the certificate
> >extension would typically be ignored.
> >
> >The underlying rationale for this is that in a store and forward type
of
> >communication such as e-mail, we may run into situation where one
party
> >need to guess the capabilities of the opponent and the guiding
principle
> >is that the more information we can use to make the best guess, the
> >better it is.
> >
> >Using such SMIMECapabilities extension in certificates as the last
> >resource of information is supporting that rationale.
> >
> >So, again, please state your opinion so we can either do this or put
it
> >away. If it is to be done, the task should be very simple since there
> >should be no reason to deviate from the current syntax of the
> >SMIMECapabilities attribute used in S/MIME.
> >

---

From: "Guida, Richard [JJCUS]" <[email-masked]>
Date: Thu, 29 Apr 2004 20:30:44 -0400

Forgive me for coming out of lurker status on this one, but I do think that
Stefan's arguments for this attribute are good ones; we have a requirement
to use only strong crypto (3DES, AES, etc.) but of course enforcing that
with S/MIME is tricky, requiring more user knowledge than one would expect
of most users (clicking on the encryption icon, seeing the crypto strength,
confirming it is o.k...).  An extension like this (or semantic info in an
existing extension) could be very helpful.  David's points are correct that
a CA may not know the S/MIME capabilities (or requirements) of its subjects
- but I agree with Stefan's response that in some cases (like our enterprise
environment), it does, so this info can have real utility.  Two cents
worth...

Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  732 524 3785

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Thursday, April 29, 2004 2:24 PM
To: David A. Cooper
Cc: [email-masked]
Subject: RE: SMIME Capabilities in X.509 certificates.

David,

Comment in line;

a

/Stefan

to
an
unknown
from
of
party
principle
it

---

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 29 Apr 2004 18:25:00 -0700

Hi Rich,

As one lurker to another, you also need to consider that it is accepted
practice with SMIME today for the client to self certify this data so
the potential for having this in the certificate could lead to some
adult or corporate supervision. Also if you say you have a preference
for AES and 3DES, you are saying both are acceptable otherwise you
should not offer the alternatives. So having more ways to express your
preference is better.

Trevor

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, April 29, 2004 5:31 PM
To: Stefan Santesson; David A. Cooper
Cc: [email-masked]
Subject: RE: SMIME Capabilities in X.509 certificates.

Forgive me for coming out of lurker status on this one, but I do think
that Stefan's arguments for this attribute are good ones; we have a
requirement to use only strong crypto (3DES, AES, etc.) but of course
enforcing that with S/MIME is tricky, requiring more user knowledge than
one would expect of most users (clicking on the encryption icon, seeing
the crypto strength, confirming it is o.k...).  An extension like this
(or semantic info in an existing extension) could be very helpful.
David's points are correct that a CA may not know the S/MIME
capabilities (or requirements) of its subjects - but I agree with
Stefan's response that in some cases (like our enterprise environment),
it does, so this info can have real utility.  Two cents worth...

Richard A. Guida 

Johnson & Johnson 
Room GS8217 
410 George Street 

-----Original Message----- 
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, April 29, 2004 2:24 PM 
To: David A. Cooper 
Cc: [email-masked] 
Subject: RE: SMIME Capabilities in X.509 certificates. 

David, 

Comment in line; 

a 

/Stefan 

to 
an 
unknown 
from 

of 
party 
principle 
it

---

From: "Guida, Richard [JJCUS]" <[email-masked]>
Date: Thu, 29 Apr 2004 21:41:21 -0400

I can't agree more, Trevor, and as you imply, sometimes adult or corporate
supervision can be a good thing.  Even for us baby boomers weened on "doing
our own thing!"  (And yes, 3DES or AES are acceptable under our policies,
although one give 112 and the other 128+ bits of key strength; as you know,
both as unbreakable.)

Richard A. Guida 

Johnson & Johnson 
Room GS8217 
410 George Street 

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Thursday, April 29, 2004 9:25 PM
To: Guida, Richard [JJCUS]; Stefan Santesson; David A. Cooper
Cc: [email-masked]
Subject: RE: SMIME Capabilities in X.509 certificates.

Hi Rich,

As one lurker to another, you also need to consider that it is accepted
practice with SMIME today for the client to self certify this data so the
potential for having this in the certificate could lead to some adult or
corporate supervision. Also if you say you have a preference for AES and
3DES, you are saying both are acceptable otherwise you should not offer the
alternatives. So having more ways to express your preference is better.

Trevor

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, April 29, 2004 5:31 PM
To: Stefan Santesson; David A. Cooper
Cc: [email-masked]
Subject: RE: SMIME Capabilities in X.509 certificates.

Richard A. Guida 

Johnson & Johnson 
Room GS8217 
410 George Street 

-----Original Message----- 
From: Stefan Santesson [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, April 29, 2004 2:24 PM 
To: David A. Cooper 
Cc: [email-masked] 
Subject: RE: SMIME Capabilities in X.509 certificates. 

David, 

Comment in line; 

> From: David A. Cooper [ mailto:[email-masked]
<mailto:[email-masked]> ] 
a 

/Stefan 

to 
an 
unknown 
from 
of 
party 
principle 
it

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 30 Apr 2004 08:15:05 -0700

> SubjectDirectoryAttributes extension rather than trying to 
> treat it as a  certificate extension?

I don't care what the OID is provided it is signed and in the cert.

This is information that the sender of an encrypted email needs to
send mail. Therefore it should be in the cert and be authenticated.

		Phill

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 30 Apr 2004 17:31:51 +0100

Phil,

I agree to your conclusion.

Now if we would move to a discussion of where it should be located I
would suggest that the fact that we have a large installed base of
clients that today understands and makes use of this information if
present in an extension identified with the existing PKCS#9 OID,
combined with the fact that there is no other solution out there in use
today, we would get a better head start of deployment and
interoperability if we found that we could live with the solution
already in use.

Stefan Santesson

> On Behalf Of Hallam-Baker, Phillip
> Sent: den 30 april 2004 08:15
> To: 'David A. Cooper'; Stefan Santesson
> Cc: [email-masked]

Content-class: urn:content-classes:message
Subject: RE: SMIME Capabilities in X.509 certificates.
Date: Fri, 30 Apr 2004 17:31:51 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "David A. Cooper" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Phil,

I agree to your conclusion.

Now if we would move to a discussion of where it should be located I
would suggest that the fact that we have a large installed base of
clients that today understands and makes use of this information if
present in an extension identified with the existing PKCS#9 OID,
combined with the fact that there is no other solution out there in use
today, we would get a better head start of deployment and
interoperability if we found that we could live with the solution
already in use.

Stefan Santesson

> On Behalf Of Hallam-Baker, Phillip
> Sent: den 30 april 2004 08:15
> To: 'David A. Cooper'; Stefan Santesson
> Cc: [email-masked]

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'David A. Cooper'" <[email-masked]>, Stefan Santesson <[email-masked]>
Cc: [email-masked]
Subject: RE: SMIME Capabilities in X.509 certificates.
Date: Fri, 30 Apr 2004 08:15:05 -0700
Sender: [email-masked]

		Phill

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cross certificate format
Date: Thu, 29 Apr 2004 23:12:15 -0400
Importance: Normal
Sender: [email-masked]

Tom:

The basic point (at the risk of repeating myself) is that a CA certificate
or a self-signed certificate can be used as a means to provide trust anchor
information.  In that case, there is no need to check signature or anything.

But, when the CA certificate is a certificate in the certificate path, X.509
logic kicks in.

This is consistent with X.509, 3280 and general security principles since
the trust in a trust anchor can be derived through any number of means.

If you do not agree, feel free to argue against the definitions and Galileo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Thursday, April 29, 2004 8:43 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        I don't think that a CA certificate and a trust anchor are as much 
different things as different uses for the same thing.  They are both 
identifiers of issuers which bind a public key to an issuer name, and it 
is perfectly appropriate for any CA certificate to represent a trust 
anchor.  I also do not see why such things as name constraints on a trust 
anchor are inappropriate.  It is perfectly true that verifying a trust 
anchor's certificate, when issued by another CA (who may not be trusted) 
is a pointless operation.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/27/2004 09:14 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My point is that even if the trust anchor is a self-signed certificate, 
all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element 
of
the cross certificate pair is nothing but an intermediate CA certificate 
in
a certification path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 

be provided as "a self-signed certificate", with no further qualification. 

 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/26/2004 08:51 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Cross certificate format

        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 

it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 

by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 

with the KeyUsage extension present, it is only a valid issuer certificate 

if keyCertSign is set.

        Tom Gindin

Jean-Marc Desperrier <[email-masked]>
Sent by: [email-masked]
04/21/2004 03:42 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Cross certificate format

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed 
> certificates,

>which contain no extensions at all (see the text of RFC 3280's
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: Trevor Freeman <[email-masked]>, Stefan Santesson <[email-masked]>, "David A. Cooper" <[email-masked]>
Cc: [email-masked]
Subject: RE: SMIME Capabilities in X.509 certificates.
Date: Thu, 29 Apr 2004 21:41:21 -0400
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_01C42E54.3BC8F414
Content-Type: text/plain;
	charset="iso-8859-1"

Richard A. Guida 

Johnson & Johnson 
Room GS8217 
410 George Street 

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Thursday, April 29, 2004 9:25 PM
To: Guida, Richard [JJCUS]; Stefan Santesson; David A. Cooper
Cc: [email-masked]
Subject: RE: SMIME Capabilities in X.509 certificates.

Hi Rich,

Trevor

  _____  

Richard A. Guida 

Johnson & Johnson 
Room GS8217 
410 George Street 

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

David, 

Comment in line; 

a 

/Stefan 

to 
an 
unknown 
from 
of 
party 
principle 
it 
> >SMIMECapabilities attribute used in S/MIME. 

------_=_NextPart_001_01C42E54.3BC8F414
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: SMIME Capabilities in X.509 certificates.</TITLE>

<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 0pt 180.0pt 0pt 0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0pt; MARGIN-RIGHT: 0pt; FONT-FAMILY: "Times New Roman"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=blue link=blue>
<DIV><SPAN class=412453801-30042004><FONT face=Arial color=#0000ff size=2>I 
can't agree more, Trevor, and as you imply, sometimes adult or corporate 
supervision can be a good thing.&nbsp; Even for us baby boomers weened on "doing 
our own thing!"&nbsp; (And yes, 3DES or AES are acceptable under our policies, 
although one give 112 and the other 128+ bits of key strength; as you know, both 
as unbreakable.)</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV><BR>
<P><B><FONT face=Arial size=2>Richard A. Guida</FONT></B> <BR><B><FONT 
face=Arial size=2>Director, Information Security</FONT></B> </P>
<P><B><I><FONT face="Times New Roman" color=#ff0000 size=5>Johnson &amp; 
Johnson</FONT></I></B><I></I> <BR><FONT face=Arial size=2>Room GS8217</FONT> 
<BR><FONT face=Arial size=2>410 George Street</FONT> <BR><FONT face=Arial 
size=2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT face=Arial 
size=2>Phone:&nbsp; 732 524 3785</FONT> </P>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Trevor Freeman 
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, April 29, 
  2004 9:25 PM<BR><B>To:</B> Guida, Richard [JJCUS]; Stefan Santesson; David A. 
  Cooper<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: SMIME 
  Capabilities in X.509 certificates.<BR><BR></FONT></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi 
  Rich,</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As one lurker to 
  another, you also need to consider that it is accepted practice with SMIME 
  today for the client to self certify this data so the potential for having 
  this in the certificate could lead to some adult or corporate supervision. 
  Also if you say you have a preference for AES and 3DES, you are saying both 
  are acceptable otherwise you should not offer the alternatives. So having more 
  ways to express your preference is better.</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Trevor</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <DIV>
  <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT 
  face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
  <HR tabIndex=-1 align=center width="100%" SIZE=2>
  </SPAN></FONT></DIV>
  <P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
  face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> 
  [email-masked] [mailto:[email-masked]] <B><SPAN 
  style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Guida, Richard 
  [JJCUS]<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, April 
  29, 2004 5:31 PM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> Stefan 
  Santesson; David A. Cooper<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Cc:</SPAN></B> [email-masked]<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Subject:</SPAN></B> RE: SMIME Capabilities in X.509 
  certificates.</SPAN></FONT></P></DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Forgive 
  me for coming out of lurker status on this one, but I do think that Stefan's 
  arguments for this attribute are good ones; we have a requirement to use only 
  strong crypto (3DES, AES, etc.) but of course enforcing that with S/MIME is 
  tricky, requiring more user knowledge than one would expect of most users 
  (clicking on the encryption icon, seeing the crypto strength, confirming it is 
  o.k...).&nbsp; An extension like this (or semantic info in an existing 
  extension) could be very helpful.&nbsp; David's points are correct that a CA 
  may not know the S/MIME capabilities (or requirements) of its subjects - but I 
  agree with Stefan's response that in some cases (like our enterprise 
  environment), it does, so this info can have real utility.&nbsp; Two cents 
  worth...</SPAN></FONT></P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Richard 
  A. Guida</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">Director, Information Security</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Johnson 
  &amp; Johnson</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">Room GS8217</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">410 George Street<FONT size=3><SPAN 
  style="FONT-SIZE: 12pt"> <BR></SPAN></FONT>New Brunswick, New Jersey&nbsp; 
  08901</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">Phone:&nbsp; 732 524 3785</SPAN></FONT> </P>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
  <P><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">-----Original Message-----</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">From: Stefan Santesson [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Sent: Thursday, April 29, 2004 
  2:24 PM</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">To: David 
  A. Cooper</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">Cc: 
  [email-masked]</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">Subject: RE: SMIME Capabilities in X.509 
  certificates.</SPAN></FONT> </P>
  <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><FONT face="Times New Roman" 
  size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
  <P><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">David,</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Comment 
  in line;</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  -----Original Message-----</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; From: David A. Cooper [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; Sent: den 29 april 2004 
  10:59</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; To: 
  Stefan Santesson</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; Cc: [email-masked]</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; Subject: Re: SMIME Capabilities in 
  X.509 certificates.</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; Stefan,</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; Given that SMIMECapabilities is an Attribute, why 
  not put it in the</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; SubjectDirectoryAttributes extension rather than 
  trying to treat it as</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">a</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; certificate extension?</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Well, 
  today we put this as an extension. In general this is not a</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">suitable directory attribute 
  since it has to be signed. Manipulating</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">this attribute for a subject could have security 
  implications.</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Having 
  said that, I would wait with the HOW discussions until we have</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">decided IF we want to 
  standardize this practice at all.</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; It's not 
  clear to me how this extension would be populated.&nbsp; How 
  does</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; the CA 
  know the S/MIME capabilities of the certificate subject?&nbsp; 
  Does</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; the CA 
  assume that the capabilities are the same for all of its</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; subscribers or does the 
  subscriber specify this information in the</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; certificate request?&nbsp; The CA 
  can't populate the attribute on its own</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; unless it really knows what e-mail client 
  software every subscriber is</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; using.&nbsp; Otherwise the contents of the 
  attribute wouldn't be very</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; useful.&nbsp; In theory, the contents of the 
  attribute could reflect the</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; capabilities of the subscriber if the subscriber 
  specified the</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; contents.&nbsp; But, I don't see how this would 
  work in practice unless the</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; subscriber's e-mail client generated the 
  certificate request, which</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; doesn't seem realistic.</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">I would 
  turn it around. Some CAs actually has access to this information</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">about users, especially if the 
  CA is a local enterprise CA with access</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">to local policies for users. In this case, the 
  inclusion is straight</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">forward and sufficiently accurate.</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Since 
  there without doubts are ways where the CA can know this</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">information, the interesting 
  question is whether the world would benefit</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">from a standard way to read this 
  information from a certificate, if the</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">CA has chosen to put it there, which many CAs already 
  do.</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">Again I 
  would repeat that the use of this information is just a last</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">resource in the situations 
  where no other knowledge is available.</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  Besides, if the information in the SMIMECapabilities attribute is 
  only</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; of use 
  to S/MIME clients, shouldn't this be an S/MIME working group</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; consideration rather than 
  PKIX?</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">That is 
  not for me to decide. I have been asked to post this to PKIX</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">since it is a certificate 
  format issue, but if this is to be done, it</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">will absolutely also has an intersection 
  with SMIME.</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">/Stefan</SPAN></FONT> </P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  Dave</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; Stefan 
  Santesson wrote:</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;OK Steve.</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;Let me try to recap this issue 
  and see if we at least can get to a</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;debate whether this is worth doing or 
  not.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  &gt;</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;The 
  issue on the table is whether it should be a standardized option</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">to</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;include the SMIME capability 
  attribute in a certificate.</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;Microsoft is currently supporting inclusion 
  of this attribute in</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;certificates using the standard PKCS#9 OID as 
  extension OID and thus</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;using the standard PKCS#9 attribute syntax as 
  extension syntax.</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;This extension, when present in certificates 
  is used as the last</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;resource to figure out the appropriate 
  configuration/capabilities of</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">an</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;S/MIME opponent before falling back to 
  default configuration for</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">unknown</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;users.</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;This is useful in particular when an 
  encrypted e-mail is sent to a</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;recipient whose certificate is known but 
  where the recipient's</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;capabilities otherwise are 
  unknown.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  &gt;</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;But 
  if there is a known previous S/MIME message from the recipient</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">from</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;which the recipient's 
  capabilities can be extracted, the certificate</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;extension would typically be 
  ignored.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  &gt;</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;The 
  underlying rationale for this is that in a store and forward 
  type</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">of</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;communication such as e-mail, we may run into 
  situation where one</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">party</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;need to guess the capabilities of the 
  opponent and the guiding</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">principle</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;is that the more information we can use to 
  make the best guess, the</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;better it is.</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;Using such SMIMECapabilities 
  extension in certificates as the last</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;resource of information is supporting that 
  rationale.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  &gt;</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;So, 
  again, please state your opinion so we can either do this or put</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">it</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; &gt;away. If it is to be done, the 
  task should be very simple since there</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;should be no reason to deviate from the 
  current syntax of the</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; &gt;SMIMECapabilities attribute used in 
  S/MIME.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  &gt;</SPAN></FONT> </P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C42E54.3BC8F414--

Content-class: urn:content-classes:message
Subject: RE: SMIME Capabilities in X.509 certificates.
Date: Thu, 29 Apr 2004 18:25:00 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Guida, Richard [JJCUS]" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "David A. Cooper" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPartTM-000-701fd0bd-50a1-4598-877d-e46299425b15
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C42E51.F85BC7B3"

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

Hi Rich,

=20

Trevor

=20

=20

=20

Richard A. Guida=20
Director, Information Security=20

Johnson & Johnson=20
Room GS8217=20
410 George Street=20
New Brunswick, New Jersey  08901=20
Phone:  732 524 3785=20

=20

-----Original Message-----=20
From: Stefan Santesson [mailto:[email-masked]]=20
Sent: Thursday, April 29, 2004 2:24 PM=20
To: David A. Cooper=20
Cc: [email-masked]=20
Subject: RE: SMIME Capabilities in X.509 certificates.=20

=20

David,=20

Comment in line;=20

> -----Original Message-----=20
> From: David A. Cooper [mailto:[email-masked]]=20
> Sent: den 29 april 2004 10:59=20
> To: Stefan Santesson=20
> Cc: [email-masked]=20
> Subject: Re: SMIME Capabilities in X.509 certificates.=20
>=20
> Stefan,=20
>=20
> Given that SMIMECapabilities is an Attribute, why not put it in the=20

a=20
> certificate extension?=20

Well, today we put this as an extension. In general this is not a=20
suitable directory attribute since it has to be signed. Manipulating=20
this attribute for a subject could have security implications.=20

Having said that, I would wait with the HOW discussions until we have=20
decided IF we want to standardize this practice at all.=20

>=20
> It's not clear to me how this extension would be populated.  How does=20
> the CA know the S/MIME capabilities of the certificate subject?  Does=20
> the CA assume that the capabilities are the same for all of its=20
> subscribers or does the subscriber specify this information in the=20
> certificate request?  The CA can't populate the attribute on its own=20

> using.  Otherwise the contents of the attribute wouldn't be very=20
> useful.  In theory, the contents of the attribute could reflect the=20
> capabilities of the subscriber if the subscriber specified the=20

> subscriber's e-mail client generated the certificate request, which=20
> doesn't seem realistic.=20

about users, especially if the CA is a local enterprise CA with access=20
to local policies for users. In this case, the inclusion is straight=20
forward and sufficiently accurate.=20

Since there without doubts are ways where the CA can know this=20
information, the interesting question is whether the world would benefit

from a standard way to read this information from a certificate, if the=20
CA has chosen to put it there, which many CAs already do.=20

Again I would repeat that the use of this information is just a last=20
resource in the situations where no other knowledge is available.=20

> of use to S/MIME clients, shouldn't this be an S/MIME working group=20
> consideration rather than PKIX?=20

That is not for me to decide. I have been asked to post this to PKIX=20
since it is a certificate format issue, but if this is to be done, it=20
will absolutely also has an intersection with SMIME.=20

/Stefan=20

>=20
> Dave=20
>=20
> Stefan Santesson wrote:=20
>=20
> >OK Steve.=20
> >=20
> >Let me try to recap this issue and see if we at least can get to a=20
> >debate whether this is worth doing or not.=20
> >=20
> >The issue on the table is whether it should be a standardized option=20
to=20
> >include the SMIME capability attribute in a certificate.=20
> >=20
> >Microsoft is currently supporting inclusion of this attribute in=20
> >certificates using the standard PKCS#9 OID as extension OID and thus=20
> >using the standard PKCS#9 attribute syntax as extension syntax.=20
> >=20
> >This extension, when present in certificates is used as the last=20
> >resource to figure out the appropriate configuration/capabilities of=20
an=20
> >S/MIME opponent before falling back to default configuration for=20
unknown=20
> >users.=20
> >=20
> >This is useful in particular when an encrypted e-mail is sent to a=20
> >recipient whose certificate is known but where the recipient's=20
> >capabilities otherwise are unknown.=20
> >=20
> >But if there is a known previous S/MIME message from the recipient=20
from=20
> >which the recipient's capabilities can be extracted, the certificate=20
> >extension would typically be ignored.=20
> >=20

of=20
> >communication such as e-mail, we may run into situation where one=20
party=20
> >need to guess the capabilities of the opponent and the guiding=20
principle=20
> >is that the more information we can use to make the best guess, the=20
> >better it is.=20
> >=20
> >Using such SMIMECapabilities extension in certificates as the last=20
> >resource of information is supporting that rationale.=20
> >=20
> >So, again, please state your opinion so we can either do this or put=20
it=20

> >should be no reason to deviate from the current syntax of the=20
> >SMIMECapabilities attribute used in S/MIME.=20
> >=20

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

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<title>RE: SMIME Capabilities in X.509 certificates.</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{margin-right:0pt;
	margin-left:0pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:0pt 180.0pt 0pt 0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As one lurker to another, you also =
need to
consider that it is accepted practice with SMIME today for the client to =
self certify
this data so the potential for having this in the certificate could lead =
to
some adult or corporate supervision. Also if you say you have a =
preference for
AES and 3DES, you are saying both are acceptable otherwise you should =
not offer
the alternatives. So having more ways to express your preference is =
better.</span></font></p>

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

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

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Guida, Richard =
[JJCUS]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, April 29, =
2004
5:31 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stefan Santesson; =
David A.
Cooper<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: SMIME =
Capabilities in
X.509 certificates.</span></font></p>

</div>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Forgive
me for coming out of lurker status on this one, but I do think that =
Stefan's
arguments for this attribute are good ones; we have a requirement to use =
only
strong crypto (3DES, AES, etc.) but of course enforcing that with S/MIME =
is
tricky, requiring more user knowledge than one would expect of most =
users
(clicking on the encryption icon, seeing the crypto strength, confirming =
it is
o.k...).&nbsp; An extension like this (or semantic info in an existing
extension) could be very helpful.&nbsp; David's points are correct that =
a CA
may not know the S/MIME capabilities (or requirements) of its subjects - =
but I
agree with Stefan's response that in some cases (like our enterprise
environment), it does, so this info can have real utility.&nbsp; Two =
cents
worth...</span></font></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Richard
A. Guida</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Director, Information =
Security</span></font>
</p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Johnson
&amp; Johnson</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Room =
GS8217</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>410 George Street<font =
size=3D3><span
 style=3D'font-size:12.0pt'> <br>
 </span></font>New Brunswick, New Jersey&nbsp; 08901</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Phone:&nbsp; 732 524 =
3785</span></font>
</p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>From: Stefan Santesson =
[<a
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]</=
span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Thursday, April =
29, 2004 2:24
PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: David A. =
Cooper</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Cc: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: RE: SMIME =
Capabilities in
X.509 certificates.</span></font> </p>

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

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Comment
in line;</span></font> </p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;
-----Original Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From: David A. =
Cooper [<a
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]</=
span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: den 29 april =
2004 10:59</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: Stefan =
Santesson</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Cc: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: Re: SMIME
Capabilities in X.509 certificates.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
Stefan,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Given that =
SMIMECapabilities
is an Attribute, why not put it in the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
SubjectDirectoryAttributes
extension rather than trying to treat it as</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>a</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; certificate =
extension?</span></font>
</p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Well,
today we put this as an extension. In general this is not =
a</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>suitable directory =
attribute since
it has to be signed. Manipulating</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>this attribute for a =
subject could
have security implications.</span></font> </p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Having
said that, I would wait with the HOW discussions until we =
have</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>decided IF we want to =
standardize
this practice at all.</span></font> </p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; It's not clear to =
me how this
extension would be populated.&nbsp; How does</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the CA know the =
S/MIME
capabilities of the certificate subject?&nbsp; Does</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the CA assume that =
the
capabilities are the same for all of its</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; subscribers or does =
the
subscriber specify this information in the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; certificate =
request?&nbsp; The
CA can't populate the attribute on its own</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; unless it really =
knows what
e-mail client software every subscriber is</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; using.&nbsp; =
Otherwise the
contents of the attribute wouldn't be very</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; useful.&nbsp; In =
theory, the
contents of the attribute could reflect the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; capabilities of the =
subscriber
if the subscriber specified the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; contents.&nbsp; =
But, I don't
see how this would work in practice unless the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; subscriber's e-mail =
client
generated the certificate request, which</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; doesn't seem =
realistic.</span></font>
</p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>I would
turn it around. Some CAs actually has access to this =
information</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>about users, especially =
if the CA
is a local enterprise CA with access</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>to local policies for =
users. In
this case, the inclusion is straight</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>forward and sufficiently =
accurate.</span></font>
</p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Since
there without doubts are ways where the CA can know this</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>information, the =
interesting
question is whether the world would benefit</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>from a standard way to =
read this
information from a certificate, if the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>CA has chosen to put it =
there,
which many CAs already do.</span></font> </p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Again I
would repeat that the use of this information is just a =
last</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>resource in the =
situations where no
other knowledge is available.</span></font> </p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;
Besides, if the information in the SMIMECapabilities attribute is =
only</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; of use to S/MIME =
clients,
shouldn't this be an S/MIME working group</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; consideration =
rather than
PKIX?</span></font> </p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>That is
not for me to decide. I have been asked to post this to =
PKIX</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>since it is a =
certificate format
issue, but if this is to be done, it</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>will absolutely also has =
an
intersection with SMIME.</span></font> </p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Dave</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Stefan Santesson =
wrote:</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;OK =
Steve.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;Let me try to =
recap this
issue and see if we at least can get to a</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;debate whether =
this is
worth doing or not.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;The issue on =
the table is
whether it should be a standardized option</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>to</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;include the =
SMIME
capability attribute in a certificate.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;Microsoft is =
currently
supporting inclusion of this attribute in</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;certificates =
using the
standard PKCS#9 OID as extension OID and thus</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;using the =
standard PKCS#9
attribute syntax as extension syntax.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;This extension, =
when
present in certificates is used as the last</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;resource to =
figure out the
appropriate configuration/capabilities of</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>an</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;S/MIME opponent =
before
falling back to default configuration for</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>unknown</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
&gt;users.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;This is useful =
in
particular when an encrypted e-mail is sent to a</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;recipient whose
certificate is known but where the recipient's</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;capabilities =
otherwise are
unknown.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;But if there is =
a known
previous S/MIME message from the recipient</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>from</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;which the =
recipient's
capabilities can be extracted, the certificate</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;extension would =
typically
be ignored.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;The underlying =
rationale
for this is that in a store and forward type</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>of</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;communication =
such as
e-mail, we may run into situation where one</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>party</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;need to guess =
the
capabilities of the opponent and the guiding</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>principle</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;is that the =
more information
we can use to make the best guess, the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;better it =
is.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;Using such
SMIMECapabilities extension in certificates as the last</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;resource of =
information is
supporting that rationale.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;So, again, =
please state
your opinion so we can either do this or put</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>it</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;away. If it is =
to be done,
the task should be very simple since there</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;should be no =
reason to
deviate from the current syntax of the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
&gt;SMIMECapabilities
attribute used in S/MIME.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; &gt;</span></font> =
</p>

</div>

</body>

</html>

------_=_NextPart_001_01C42E51.F85BC7B3--

------=_NextPartTM-000-701fd0bd-50a1-4598-877d-e46299425b15--

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked]
Subject: RE: Cross certificate format
From: Tom Gindin <[email-masked]>
Date: Thu, 29 Apr 2004 20:42:50 -0400
Sender: [email-masked]

        Santosh:

        I don't think that a CA certificate and a trust anchor are as much 
different things as different uses for the same thing.  They are both 
identifiers of issuers which bind a public key to an issuer name, and it 
is perfectly appropriate for any CA certificate to represent a trust 
anchor.  I also do not see why such things as name constraints on a trust 
anchor are inappropriate.  It is perfectly true that verifying a trust 
anchor's certificate, when issued by another CA (who may not be trusted) 
is a pointless operation.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/27/2004 09:14 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My point is that even if the trust anchor is a self-signed certificate, 
all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element 
of
the cross certificate pair is nothing but an intermediate CA certificate 
in
a certification path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 

be provided as "a self-signed certificate", with no further qualification. 

 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/26/2004 08:51 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Cross certificate format

        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 

it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 

by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 

with the KeyUsage extension present, it is only a valid issuer certificate 

if keyCertSign is set.

        Tom Gindin

Jean-Marc Desperrier <[email-masked]>
Sent by: [email-masked]
04/21/2004 03:42 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Cross certificate format

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed
> certificates,

>which contain no extensions at all (see the text of RFC 3280's 
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: Stefan Santesson <[email-masked]>, "David A. Cooper" <[email-masked]>
Cc: [email-masked]
Subject: RE: SMIME Capabilities in X.509 certificates.
Date: Thu, 29 Apr 2004 20:30:44 -0400
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_01C42E4A.601184F8
Content-Type: text/plain;
	charset="iso-8859-1"

Richard A. Guida

Johnson & Johnson
Room GS8217
410 George Street

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Thursday, April 29, 2004 2:24 PM
To: David A. Cooper
Cc: [email-masked]
Subject: RE: SMIME Capabilities in X.509 certificates.

David,

Comment in line;

a

/Stefan

to
an
unknown
from
of
party
principle
it
> >SMIMECapabilities attribute used in S/MIME.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: SMIME Capabilities in X.509 certificates.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Forgive me for coming out of lurker status on this =
one, but I do think that Stefan's arguments for this attribute are good =
ones; we have a requirement to use only strong crypto (3DES, AES, etc.) =
but of course enforcing that with S/MIME is tricky, requiring more user =
knowledge than one would expect of most users (clicking on the =
encryption icon, seeing the crypto strength, confirming it is =
o.k...).&nbsp; An extension like this (or semantic info in an existing =
extension) could be very helpful.&nbsp; David's points are correct that =
a CA may not know the S/MIME capabilities (or requirements) of its =
subjects - but I agree with Stefan's response that in some cases (like =
our enterprise environment), it does, so this info can have real =
utility.&nbsp; Two cents worth...</FONT></P>
<BR>

<P><FONT SIZE=3D2>Richard A. Guida</FONT>
<BR><FONT SIZE=3D2>Director, Information Security</FONT>
</P>

<P><FONT SIZE=3D2>Johnson &amp; Johnson</FONT>
<BR><FONT SIZE=3D2>Room GS8217</FONT>
<BR><FONT SIZE=3D2>410 George Street</FONT>
<BR><FONT SIZE=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT>
<BR><FONT SIZE=3D2>Phone:&nbsp; 732 524 3785</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stefan Santesson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, April 29, 2004 2:24 PM</FONT>
<BR><FONT SIZE=3D2>To: David A. Cooper</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: SMIME Capabilities in X.509 =
certificates.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>David,</FONT>
</P>

<P><FONT SIZE=3D2>Comment in line;</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David A. Cooper [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: den 29 april 2004 10:59</FONT>
<BR><FONT SIZE=3D2>&gt; To: Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: SMIME Capabilities in X.509 =
certificates.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Stefan,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Given that SMIMECapabilities is an Attribute, =
why not put it in the</FONT>
<BR><FONT SIZE=3D2>&gt; SubjectDirectoryAttributes extension rather =
than trying to treat it as</FONT>
<BR><FONT SIZE=3D2>a</FONT>
<BR><FONT SIZE=3D2>&gt; certificate extension?</FONT>
</P>

<P><FONT SIZE=3D2>Well, today we put this as an extension. In general =
this is not a</FONT>
<BR><FONT SIZE=3D2>suitable directory attribute since it has to be =
signed. Manipulating</FONT>
<BR><FONT SIZE=3D2>this attribute for a subject could have security =
implications.</FONT>
</P>

<P><FONT SIZE=3D2>Having said that, I would wait with the HOW =
discussions until we have</FONT>
<BR><FONT SIZE=3D2>decided IF we want to standardize this practice at =
all.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It's not clear to me how this extension would =
be populated.&nbsp; How does</FONT>
<BR><FONT SIZE=3D2>&gt; the CA know the S/MIME capabilities of the =
certificate subject?&nbsp; Does</FONT>
<BR><FONT SIZE=3D2>&gt; the CA assume that the capabilities are the =
same for all of its</FONT>
<BR><FONT SIZE=3D2>&gt; subscribers or does the subscriber specify this =
information in the</FONT>
<BR><FONT SIZE=3D2>&gt; certificate request?&nbsp; The CA can't =
populate the attribute on its own</FONT>
<BR><FONT SIZE=3D2>&gt; unless it really knows what e-mail client =
software every subscriber is</FONT>
<BR><FONT SIZE=3D2>&gt; using.&nbsp; Otherwise the contents of the =
attribute wouldn't be very</FONT>
<BR><FONT SIZE=3D2>&gt; useful.&nbsp; In theory, the contents of the =
attribute could reflect the</FONT>
<BR><FONT SIZE=3D2>&gt; capabilities of the subscriber if the =
subscriber specified the</FONT>
<BR><FONT SIZE=3D2>&gt; contents.&nbsp; But, I don't see how this would =
work in practice unless the</FONT>
<BR><FONT SIZE=3D2>&gt; subscriber's e-mail client generated the =
certificate request, which</FONT>
<BR><FONT SIZE=3D2>&gt; doesn't seem realistic.</FONT>
</P>

<P><FONT SIZE=3D2>I would turn it around. Some CAs actually has access =
to this information</FONT>
<BR><FONT SIZE=3D2>about users, especially if the CA is a local =
enterprise CA with access</FONT>
<BR><FONT SIZE=3D2>to local policies for users. In this case, the =
inclusion is straight</FONT>
<BR><FONT SIZE=3D2>forward and sufficiently accurate.</FONT>
</P>

<P><FONT SIZE=3D2>Since there without doubts are ways where the CA can =
know this</FONT>
<BR><FONT SIZE=3D2>information, the interesting question is whether the =
world would benefit</FONT>
<BR><FONT SIZE=3D2>from a standard way to read this information from a =
certificate, if the</FONT>
<BR><FONT SIZE=3D2>CA has chosen to put it there, which many CAs =
already do.</FONT>
</P>

<P><FONT SIZE=3D2>Again I would repeat that the use of this information =
is just a last</FONT>
<BR><FONT SIZE=3D2>resource in the situations where no other knowledge =
is available.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Besides, if the information in the =
SMIMECapabilities attribute is only</FONT>
<BR><FONT SIZE=3D2>&gt; of use to S/MIME clients, shouldn't this be an =
S/MIME working group</FONT>
<BR><FONT SIZE=3D2>&gt; consideration rather than PKIX?</FONT>
</P>

<P><FONT SIZE=3D2>That is not for me to decide. I have been asked to =
post this to PKIX</FONT>
<BR><FONT SIZE=3D2>since it is a certificate format issue, but if this =
is to be done, it</FONT>
<BR><FONT SIZE=3D2>will absolutely also has an intersection with =
SMIME.</FONT>
</P>

<P><FONT SIZE=3D2>/Stefan</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Stefan Santesson wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;OK Steve.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Let me try to recap this issue and see if =
we at least can get to a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;debate whether this is worth doing or =
not.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;The issue on the table is whether it should =
be a standardized option</FONT>
<BR><FONT SIZE=3D2>to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;include the SMIME capability attribute in a =
certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Microsoft is currently supporting inclusion =
of this attribute in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;certificates using the standard PKCS#9 OID =
as extension OID and thus</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;using the standard PKCS#9 attribute syntax =
as extension syntax.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;This extension, when present in =
certificates is used as the last</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;resource to figure out the appropriate =
configuration/capabilities of</FONT>
<BR><FONT SIZE=3D2>an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;S/MIME opponent before falling back to =
default configuration for</FONT>
<BR><FONT SIZE=3D2>unknown</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;users.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;This is useful in particular when an =
encrypted e-mail is sent to a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;recipient whose certificate is known but =
where the recipient's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;capabilities otherwise are unknown.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;But if there is a known previous S/MIME =
message from the recipient</FONT>
<BR><FONT SIZE=3D2>from</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;which the recipient's capabilities can be =
extracted, the certificate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;extension would typically be =
ignored.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;The underlying rationale for this is that =
in a store and forward type</FONT>
<BR><FONT SIZE=3D2>of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;communication such as e-mail, we may run =
into situation where one</FONT>
<BR><FONT SIZE=3D2>party</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;need to guess the capabilities of the =
opponent and the guiding</FONT>
<BR><FONT SIZE=3D2>principle</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;is that the more information we can use to =
make the best guess, the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;better it is.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Using such SMIMECapabilities extension in =
certificates as the last</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;resource of information is supporting that =
rationale.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;So, again, please state your opinion so we =
can either do this or put</FONT>
<BR><FONT SIZE=3D2>it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;away. If it is to be done, the task should =
be very simple since there</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;should be no reason to deviate from the =
current syntax of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;SMIMECapabilities attribute used in =
S/MIME.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C42E4A.601184F8--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: SMIME Capabilities in X.509 certificates.
Date: Thu, 29 Apr 2004 15:47:18 -0400
Importance: Normal
Sender: [email-masked]

David:

Would supportedAlgorithms be a better field to add?  It is a directory
attribute, but could be added as a certificate extension.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Thursday, April 29, 2004 1:59 PM
To: Stefan Santesson
Cc: [email-masked]
Subject: Re: SMIME Capabilities in X.509 certificates.

Stefan,

Given that SMIMECapabilities is an Attribute, why not put it in the 
SubjectDirectoryAttributes extension rather than trying to treat it as a 
certificate extension?

Dave

Stefan Santesson wrote:

>The issue on the table is whether it should be a standardized option to 
>resource to figure out the appropriate configuration/capabilities of an 
>unknown users.
>But if there is a known previous S/MIME message from the recipient from 
>of communication such as e-mail, we may run into situation where one 
>party need to guess the capabilities of the opponent and the guiding 
>principle is that the more information we can use to make the best 
>guess, the better it is.
>
>So, again, please state your opinion so we can either do this or put it 

Content-class: urn:content-classes:message
Subject: RE: SMIME Capabilities in X.509 certificates.
Date: Thu, 29 Apr 2004 19:24:02 +0100
From: "Stefan Santesson" <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

David,

Comment in line;

a

/Stefan

to
an
unknown
from
of
party
principle
it
> >SMIMECapabilities attribute used in S/MIME.

Date: Thu, 29 Apr 2004 13:58:33 -0400
From: "David A. Cooper" <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: Re: SMIME Capabilities in X.509 certificates.
Sender: [email-masked]

Stefan,

Given that SMIMECapabilities is an Attribute, why not put it in the 
SubjectDirectoryAttributes extension rather than trying to treat it as a 
certificate extension?

Dave

Stefan Santesson wrote:

>The issue on the table is whether it should be a standardized option to
>resource to figure out the appropriate configuration/capabilities of an
>S/MIME opponent before falling back to default configuration for unknown
>users.
>
>But if there is a known previous S/MIME message from the recipient from
>The underlying rationale for this is that in a store and forward type of
>communication such as e-mail, we may run into situation where one party
>need to guess the capabilities of the opponent and the guiding principle
>So, again, please state your opinion so we can either do this or put it

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: nonce sizes in TSP
Date: Thu, 29 Apr 2004 12:38:31 -0500
Importance: Normal
Sender: [email-masked]

I agree with you, there's no upper limit to its size. My guess is that
most implementations are using 64 bit nonces (the lower bound).

Miguel A Rodriguez
SeguriData

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Massimiliano Pala
> Sent: Thursday, April 29, 2004 10:14 AM
> To: [email-masked]
> Subject: 
> 
> 
> 
> Dear List,
> 
> I have a doubt about the nonce in a TSP request. In section 
> 2.4.1 at page 5
> it is written that:
> 
>   "The nonce, if included, allows the client to verify the 
> timeliness of
>    the response when no local clock is available.  The nonce 
> is a large
>    random number with a high probability that the client generates it
>    only once (e.g., a 64 bit integer).  In such a case the same nonce
>    value MUST be included in the response, otherwise the 
> response shall
>    be rejected."
> 
> Anyway there is no indication of an upper limit to the nonce (in terms
> of bits). This could allow rfc-compliant requests having very 
> long nonce
> thus allowing for a DoS or other type of attacks (in the 
> server responses'
> the same huge nonce MUST be present). A solution to this 
> problem could be
> not accepting requests bigger than a certain limit in size, 
> but I guess
> a fix is needed here anyway.
> 
> Does someone share my vision or am I missing something ?
> 
>     --- Massimiliano Pala
> 
> 
> 
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: 
Date: Fri, 30 Apr 2004 05:19:36 +1200
Sender: [email-masked]

"Massimiliano Pala" <[email-masked]> writes:

>Anyway there is no indication of an upper limit to the nonce (in terms of
>bits). This could allow rfc-compliant requests having very long nonce thus
>allowing for a DoS or other type of attacks (in the server responses' the
>same huge nonce MUST be present). A solution to this problem could be not
>accepting requests bigger than a certain limit in size, but I guess a fix is
>needed here anyway.

Most protocols never specify these things, leaving it up to implementors to
choose some suitable value.  I once crashed one vendor's server when I
included a huge nonce just to see what would happen :-).

Peter.

Content-class: urn:content-classes:message
Subject: RE: FW: scvp
Date: Thu, 29 Apr 2004 10:07:47 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
Not all paths include a EE certificate, and as you say a client could be
asking the server to validate a partial path. The client needs to inform
the server of this just as it needs to inform the server what type of
use it is validation like sign CRL so given a choice the server know
what to pick.
Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Thursday, April 29, 2004 3:36 AM
To: [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: RE: FW: scvp

> Hi Peter,
> A client could want to optimize the number of SCVP queries. As a SCVP
> client if I just submit a query for the issuing CA rather than the EE,
> its pretty simple to reuse that response across multiple validations.
> Therefore the server can default to a behavior like validate as EE,
but
> the client needs to be able to override the default if necessary.
This case seems to me tobe  only one of many others.
but even there, it is unclear to me whether it is orthogonal
to validation algorithms? What is the meaning of valdidation of an 
ssl server, when the client doesn't give the server cert but only the ca
cert?
Should the server not test the DNS name? Depending on what criteria?
On the setting of isCA?

What if the client wants to test the ca cert that had issues the ca cert
that had issued the ee cert.  

I suggest a rewriting the isCA paragraph may be in the following model:
 
  A client may want to indicate further details concerning the
  starting certifictae in a path (? for DPV, DPD?)
  - (1) whether the paths does not contain all parts,
  - (2) whether ... 

  in order to indicate (1), the clients set the value of isCA to XXX.
  in order to indicate (2), the client ...

or, it seems to me that currently you want:

A client has the possibility to indicate that the cert
to be validated is not the stating point in the path but the CA
cert that has signed it. in order to do so, the client set the
isCA boolean.

Content-class: urn:content-classes:message
Subject: RE: FW: scvp
Date: Thu, 29 Apr 2004 09:57:28 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Denis,

3379 does not require that the validation policy be specified in a
single value. With SCVP14 a client can accept the default of the SCVP
server or specify a set of parameters which constitutes its validation
policy. That is consistent with the requirements of 3379.
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, April 29, 2004 3:54 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: FW: scvp

Trevor,

> Hi Denis,

> Can you please be more specific how you think SCVP 14 does not comply
> with 3379.
> 
> I can find no section in 3379 where is there a requirement that a
> validation policy MUST be represented as an OID. 

There cannot be a requirement with such a level of detail, but the text
states:

    The protocol MUST allow the client to include
    these policy dependant parameters in the DPV request; however, it is
    expected that most clients will simply reference a validation policy
    for a given application or accept the DPV server's default
validation
    policy.

A simple reference is an OID.

FYI, I do not expect to use the "default validation policy".

Denis

> Given hiding the detail of what a policy is within an OID simply opens
> the rat hole of what change to the policy constitutes a change to the
> OID, it is less ambiguous to refer to the primary data. Once you are
in
> the business of managing state on a client, then there is negligible
> cost increase incurred in managing several data points vs. a singe
data
> point.
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Tuesday, April 27, 2004 11:01 AM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> 
>>HI Denis,
>>In SCVP13, the concept of validation policy was not completely in
>>alignment  with 3379 definition. 
> 
> 
> Well, it is different and this is a major problem.
> 
> 
>>It also blurred the distinction between
>>validation policy and validation algorithm. 
> 
> 
> This is also a majo problem.
> 
> 
>>Therefore I have defined
>>what each is in SCVP 14 and aligned the structures accordingly.
>>Section 1.3 has the following.
>>"In SCVP, the validation policy comprises of an algorithm for
>>certificate path processing and the input parameters to the
> 
> algorithm."
> 
> This does not comply with RFC 3379.
> 
> 
>>Therefore trust anchors are an input into the algorithm  and therefore
>>separate.
> 
> 
> Therefore I do not follow you.
> 
>  From an interface point of view the simplest validation policy is
> defined 
> by an OID where all the parameters necessary to perform the validation
> check 
> are "behind" the OID. There is no need to provide any parameter
through
> the 
> interface.
> 
> When there are some parameters, then they are specific to the
validation
> 
> policy. I have no problem to provide specific parameters for what is
> called 
> the "default validation policy" which is only a particular validation
> policy 
> among many others.
> 
> Simple clients will be unable to pass any parameter but will know
which
> OIDs 
> (for the validation policy) are appropriate for their applications.
> 
> Denis
> 
> 
>>This is in alignment with 3379s definition of validation policy.
>>
>>Trevor
>>
>>From: Denis Pinkas [mailto:[email-masked]] 
>>Sent: Monday, April 26, 2004 1:09 AM
>>To: Peter Sylvester
>>Cc: [email-masked]; Trevor Freeman
>>Subject: Re: FW: scvp
>>
>>Peter and Trevor,
>>
>>I have major problems too.
>>
>>
>>
>>>in version 13 the syntax for a Query has been changed from
>>>
>>>  Query ::= SEQUENCE { 
>>>      queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>>>      checks                CertChecks, 
>>>      wantBack              WantBack, 
>>>      serverContextInfo [0] OCTET STRING OPTIONAL, 
>>>      valPolicy         [1] ValidationPolicy OPTIONAL, 
>>>      validityTime      [2] GeneralizedTime OPTIONAL, 
>>>      trustAnchors      [3] TrustAnchors OPTIONAL, 
>>>      intermediateCerts [4] CertBundle OPTIONAL, 
>>>      revInfos          [5] RevocationInfos OPTIONAL, 
>>>      queryExtensions   [6] Extensions OPTIONAL } 
>>
>>
>>In this structure trustAnchors was more or less an alternative to
>>valPolicy.
>>
>>In fact, IF the valPolicy is the default policy, THEN additional
>>parameters 
>>MUST be provided. So the structure below does not fit as well.
>>
>>This leads to have the two following elements:
>>
>>     valPolicy               ValidationPolicy,
>>     paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
>>
>>where the first one is mandatory and the second one optional.
>>
>>
>>
>>>to  
>>>
>>>   Query ::= SEQUENCE { 
>>>     queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>
>>
>>>     checks                  CertChecks, 
>>>     wantBack                WantBack, 
>>>     requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>     includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>     inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>     requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>     ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>     valAlgorithm            ValidationAlgorithm, 
>>>     serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>     validityTime        [1] GeneralizedTime OPTIONAL, 
>>>     trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>     intermediateCerts   [3] CertBundle OPTIONAL, 
>>>     revInfos            [4] RevocationInfos OPTIONAL, 
>>>     queryExtensions     [5] Extensions OPTIONAL } 
>>
>>
>>I would thus propose to have something like:
>>
>>Query ::= SEQUENCE {
>>         queriedCerts            SEQUENCE SIZE (1..MAX) OF
>>CertReference,
>>         checks                  CertChecks,
>>         wantBack                WantBack,
>>         requestRefHash          BOOLEAN DEFAULT TRUE,
>>         serverContextInfo       OCTET STRING OPTIONAL,
>>         validityTime            GeneralizedTime OPTIONAL,
>>         includePolResponse      BOOLEAN DEFAULT FALSE,
>>         valPolicy               ValidationPolicy,
>>         paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
>>         intermediateCerts   [1] CertBundle OPTIONAL,
>>         revInfos            [2] RevocationInfos OPTIONAL,
>>         queryExtensions     [3] Extensions OPTIONAL }
>>
>>and then something like:
>>
>>    ParamsDefValPolicy :: = SEQUENCE {
>>        trustAnchors                  TrustAnchors,
>>        endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
>>OPTIONAL,
>>        inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>>        caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
>>OPTIONAL }
>>
>>Denis
>>
>>
>>
>>>I am not sure whether I am the only person unable to construct a
>>
>>parser.
>>
>>
>>>in version 14 an aditional flag has been added which is not available
>>
>>in the
>>
>>
>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
validation
>>>algorithms, or just to some of them, e.g,. the default name matching
>>
>>one? 
>>
>>
>>>   Query ::= SEQUENCE { 
>>>     queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>
>>
>>>     checks                  CertChecks, 
>>>     wantBack                WantBack, 
>>>     requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>     includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>     inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>     requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>     ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>     isCA                    BOOLEAN DEFAULT FALSE, 
>>>     valAlgorithm            ValidationAlgorithm, 
>>>     serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>     validityTime        [1] GeneralizedTime OPTIONAL, 
>>>     trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>     intermediateCerts   [3] CertBundle OPTIONAL, 
>>>     revInfos            [4] RevocationInfos OPTIONAL, 
>>>     keyUsage            [5] KeyUsage OPTIONAL, 
>>>     extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>>>     queryExtensions     [7] Extensions OPTIONAL  
>>>     producedAt          [8] GeneralizedTime OPTIONAL} 
>>>
>>>
>>
>>
>>
>>
> 
> 
> 

Date: Thu, 29 Apr 2004 12:34:38 -0400
From: Jack Lloyd <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: your mail
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

It is a potential DoS, but ones of this type (where the attacker has to use up
an amount of bandwidth at the same rate as what his target takes) is not
considered serious. That's because there really isn't much of a way to stop
this type of attack.

Anyway, there are much easier ways to kill TCP-based systems then drown them
in requests. :)

-Jack

On Thu, Apr 29, 2004 at 05:13:48PM +0200, Massimiliano Pala wrote:
> 
> Dear List,
> 
> I have a doubt about the nonce in a TSP request. In section 2.4.1 at page 5
> it is written that:
> 
>   "The nonce, if included, allows the client to verify the timeliness of
>    the response when no local clock is available.  The nonce is a large
>    random number with a high probability that the client generates it
>    only once (e.g., a 64 bit integer).  In such a case the same nonce
>    value MUST be included in the response, otherwise the response shall
>    be rejected."
> 
> Anyway there is no indication of an upper limit to the nonce (in terms
> of bits). This could allow rfc-compliant requests having very long nonce
> thus allowing for a DoS or other type of attacks (in the server responses'
> the same huge nonce MUST be present). A solution to this problem could be
> not accepting requests bigger than a certain limit in size, but I guess
> a fix is needed here anyway.
> 
> Does someone share my vision or am I missing something ?
> 
>     --- Massimiliano Pala
> 
> 
> 

Date: Thu, 29 Apr 2004 17:13:48 +0200 (CEST)
Subject: 
From: "Massimiliano Pala" <[email-masked]>
To: <[email-masked]>
Importance: Normal
Sender: [email-masked]

Dear List,

I have a doubt about the nonce in a TSP request. In section 2.4.1 at page 5
it is written that:

  "The nonce, if included, allows the client to verify the timeliness of
   the response when no local clock is available.  The nonce is a large
   random number with a high probability that the client generates it
   only once (e.g., a 64 bit integer).  In such a case the same nonce
   value MUST be included in the response, otherwise the response shall
   be rejected."

Anyway there is no indication of an upper limit to the nonce (in terms
of bits). This could allow rfc-compliant requests having very long nonce
thus allowing for a DoS or other type of attacks (in the server responses'
the same huge nonce MUST be present). A solution to this problem could be
not accepting requests bigger than a certain limit in size, but I guess
a fix is needed here anyway.

Does someone share my vision or am I missing something ?

    --- Massimiliano Pala

Date: Thu, 29 Apr 2004 13:41:44 +0000
To: "Ietf-pkix" <[email-masked]>
From: "Wpolk" <[email-masked]>
Subject: Protected message
Sender: [email-masked]

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

<html><body>

<br>
</body></html>

----------fqzbzxfmrctcxidotdku
Content-Type: application/octet-stream; name="Details.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Details.exe"

////////////////////////////////////////////////////////////////////////

----------fqzbzxfmrctcxidotdku--

Date: Thu, 29 Apr 2004 12:54:29 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
Subject: Re: FW: scvp
Sender: [email-masked]

Trevor,

> Hi Denis,

> Can you please be more specific how you think SCVP 14 does not comply
> with 3379.
> 
> I can find no section in 3379 where is there a requirement that a
> validation policy MUST be represented as an OID. 

There cannot be a requirement with such a level of detail, but the text  states:

    The protocol MUST allow the client to include
    these policy dependant parameters in the DPV request; however, it is
    expected that most clients will simply reference a validation policy
    for a given application or accept the DPV server's default validation
    policy.

A simple reference is an OID.

FYI, I do not expect to use the "default validation policy".

Denis

> Given hiding the detail of what a policy is within an OID simply opens
> the rat hole of what change to the policy constitutes a change to the
> OID, it is less ambiguous to refer to the primary data. Once you are in
> the business of managing state on a client, then there is negligible
> cost increase incurred in managing several data points vs. a singe data
> point.
> 
> Trevor
> 
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Tuesday, April 27, 2004 11:01 AM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> 
>>HI Denis,
>>In SCVP13, the concept of validation policy was not completely in
>>alignment  with 3379 definition. 
> 
> 
> Well, it is different and this is a major problem.
> 
> 
>>It also blurred the distinction between
>>validation policy and validation algorithm. 
> 
> 
> This is also a majo problem.
> 
> 
>>Therefore I have defined
>>what each is in SCVP 14 and aligned the structures accordingly.
>>Section 1.3 has the following.
>>"In SCVP, the validation policy comprises of an algorithm for
>>certificate path processing and the input parameters to the
> 
> algorithm."
> 
> This does not comply with RFC 3379.
> 
> 
>>Therefore trust anchors are an input into the algorithm  and therefore
>>separate.
> 
> 
> Therefore I do not follow you.
> 
>  From an interface point of view the simplest validation policy is
> defined 
> by an OID where all the parameters necessary to perform the validation
> check 
> are "behind" the OID. There is no need to provide any parameter through
> the 
> interface.
> 
> When there are some parameters, then they are specific to the validation
> 
> policy. I have no problem to provide specific parameters for what is
> called 
> the "default validation policy" which is only a particular validation
> policy 
> among many others.
> 
> Simple clients will be unable to pass any parameter but will know which
> OIDs 
> (for the validation policy) are appropriate for their applications.
> 
> Denis
> 
> 
>>This is in alignment with 3379s definition of validation policy.
>>
>>Trevor
>>
>>From: Denis Pinkas [mailto:[email-masked]] 
>>Sent: Monday, April 26, 2004 1:09 AM
>>To: Peter Sylvester
>>Cc: [email-masked]; Trevor Freeman
>>Subject: Re: FW: scvp
>>
>>Peter and Trevor,
>>
>>I have major problems too.
>>
>>
>>
>>>in version 13 the syntax for a Query has been changed from
>>>
>>>  Query ::= SEQUENCE { 
>>>      queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>>>      checks                CertChecks, 
>>>      wantBack              WantBack, 
>>>      serverContextInfo [0] OCTET STRING OPTIONAL, 
>>>      valPolicy         [1] ValidationPolicy OPTIONAL, 
>>>      validityTime      [2] GeneralizedTime OPTIONAL, 
>>>      trustAnchors      [3] TrustAnchors OPTIONAL, 
>>>      intermediateCerts [4] CertBundle OPTIONAL, 
>>>      revInfos          [5] RevocationInfos OPTIONAL, 
>>>      queryExtensions   [6] Extensions OPTIONAL } 
>>
>>
>>In this structure trustAnchors was more or less an alternative to
>>valPolicy.
>>
>>In fact, IF the valPolicy is the default policy, THEN additional
>>parameters 
>>MUST be provided. So the structure below does not fit as well.
>>
>>This leads to have the two following elements:
>>
>>     valPolicy               ValidationPolicy,
>>     paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
>>
>>where the first one is mandatory and the second one optional.
>>
>>
>>
>>>to  
>>>
>>>   Query ::= SEQUENCE { 
>>>     queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>
>>
>>>     checks                  CertChecks, 
>>>     wantBack                WantBack, 
>>>     requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>     includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>     inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>     requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>     ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>     valAlgorithm            ValidationAlgorithm, 
>>>     serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>     validityTime        [1] GeneralizedTime OPTIONAL, 
>>>     trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>     intermediateCerts   [3] CertBundle OPTIONAL, 
>>>     revInfos            [4] RevocationInfos OPTIONAL, 
>>>     queryExtensions     [5] Extensions OPTIONAL } 
>>
>>
>>I would thus propose to have something like:
>>
>>Query ::= SEQUENCE {
>>         queriedCerts            SEQUENCE SIZE (1..MAX) OF
>>CertReference,
>>         checks                  CertChecks,
>>         wantBack                WantBack,
>>         requestRefHash          BOOLEAN DEFAULT TRUE,
>>         serverContextInfo       OCTET STRING OPTIONAL,
>>         validityTime            GeneralizedTime OPTIONAL,
>>         includePolResponse      BOOLEAN DEFAULT FALSE,
>>         valPolicy               ValidationPolicy,
>>         paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
>>         intermediateCerts   [1] CertBundle OPTIONAL,
>>         revInfos            [2] RevocationInfos OPTIONAL,
>>         queryExtensions     [3] Extensions OPTIONAL }
>>
>>and then something like:
>>
>>    ParamsDefValPolicy :: = SEQUENCE {
>>        trustAnchors                  TrustAnchors,
>>        endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
>>OPTIONAL,
>>        inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>>        caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
>>OPTIONAL }
>>
>>Denis
>>
>>
>>
>>>I am not sure whether I am the only person unable to construct a
>>
>>parser.
>>
>>
>>>in version 14 an aditional flag has been added which is not available
>>
>>in the
>>
>>
>>>Chapter 9. Is the isCA flag an orthogonal attribut to other validation
>>>algorithms, or just to some of them, e.g,. the default name matching
>>
>>one? 
>>
>>
>>>   Query ::= SEQUENCE { 
>>>     queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>
>>
>>>     checks                  CertChecks, 
>>>     wantBack                WantBack, 
>>>     requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>     includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>     inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>     requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>     ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>     isCA                    BOOLEAN DEFAULT FALSE, 
>>>     valAlgorithm            ValidationAlgorithm, 
>>>     serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>     validityTime        [1] GeneralizedTime OPTIONAL, 
>>>     trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>     intermediateCerts   [3] CertBundle OPTIONAL, 
>>>     revInfos            [4] RevocationInfos OPTIONAL, 
>>>     keyUsage            [5] KeyUsage OPTIONAL, 
>>>     extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>>>     queryExtensions     [7] Extensions OPTIONAL  
>>>     producedAt          [8] GeneralizedTime OPTIONAL} 
>>>
>>>
>>
>>
>>
>>
> 
> 
> 

Date: Thu, 29 Apr 2004 12:35:43 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: FW: scvp
Cc: [email-masked]
Sender: [email-masked]

> Hi Peter,
> A client could want to optimize the number of SCVP queries. As a SCVP
> client if I just submit a query for the issuing CA rather than the EE,
> its pretty simple to reuse that response across multiple validations.
> Therefore the server can default to a behavior like validate as EE, but
> the client needs to be able to override the default if necessary.
This case seems to me tobe  only one of many others.
but even there, it is unclear to me whether it is orthogonal
to validation algorithms? What is the meaning of valdidation of an 
ssl server, when the client doesn't give the server cert but only the ca cert?
Should the server not test the DNS name? Depending on what criteria?
On the setting of isCA?

What if the client wants to test the ca cert that had issues the ca cert
that had issued the ee cert.  

I suggest a rewriting the isCA paragraph may be in the following model:
 
  A client may want to indicate further details concerning the
  starting certifictae in a path (? for DPV, DPD?)
  - (1) whether the paths does not contain all parts,
  - (2) whether ... 

  in order to indicate (1), the clients set the value of isCA to XXX.
  in order to indicate (2), the client ...

or, it seems to me that currently you want:

A client has the possibility to indicate that the cert
to be validated is not the stating point in the path but the CA
cert that has signed it. in order to do so, the client set the
isCA boolean.

Content-class: urn:content-classes:message
Subject: RE: FW: scvp
Date: Wed, 28 Apr 2004 12:19:14 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
A client could want to optimize the number of SCVP queries. As a SCVP
client if I just submit a query for the issuing CA rather than the EE,
its pretty simple to reuse that response across multiple validations.
Therefore the server can default to a behavior like validate as EE, but
the client needs to be able to override the default if necessary.

OK, the tag thing is a bit of a surprise sine this was in SCVP13 as
well. I will add tags to the query.

I think the bit sting vs. enumerated list is a stylistic call. I
personally prefer enumerated lists.

Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2004 10:39 AM
To: [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: RE: FW: scvp

link the two ... and (1) and (2) together. 

(1) ... but the syntax is ambiguous. 

You cannot parse: 

    a BOOLEAN OPTIONAL,
    b BOOLEAN OPTIONAL,

you need to add tags

    a BOOLEAN OPTIONAL, 
    b [0] BOOLEAN OPTIONAL,

> 
> 2. How about changing the isCA boolean to entityType where entityType
is
> an  enumerated list. Absence means don't care.

You can play with OPTIONAL instead of DEFAULT, which actually gives
a three value possibility but it is somewhat ugly. Absense of 'Any' 
you cannot really name it 'Any' because in the 88 version this is a
reserved
word. 

But my question is not how to encode "this" but what is the actual
intended meaning and maybe why this is an independant parameter
and not as part of a validation algorithm for CAs.
 
For any validation algorithm specified, I don't see why one would care
whether the first element is a CA or not? 

I could understand a need to try to recursively go up a path for a
particular
validation algorithm, and then one needs to say that the cert is
not the starting point of the path but an intermediate cert.

For example, if the the ssl server validation algo is used, the first
cert must contain, common name or subjectaltname and extendedkeyusage
etc.
but if one goes up in the path, nothing of that is in the cert, on the
other hand, it may be part of the trust information to indicate whether
the ac in question can be use to sign such types of end entity certs.

Thus I am puzzled about the actual intention of having this field.
Or, there is no defined combination of the meaning isCA + sslserver
validation algorithm, at least not the interesting one as defined above.

> 
> entityType ::= ENUMERATED {
>     Any                   (0),
>     endEntity             (1),
>     certificateAuthority  (2)}

Another option was suggested by peter gutmann, use a name bitlist for
all these
things. 

The pb is that I don't see a useful case for the actual
semantics (even with three options), but rather a potential need to
indicate
a partial path. You need to indicate a path length. one solution is an
integer
that indicates how many certificates in the path are not present,
default 0 means
that you have the complete beginning according to the validation
algorithm,
1 means that you must test whether pathlen in basic contraints is at
least 0 or
missing. This is useful import for DPD: Give a CA cert with at least a
pathlen of
1 that can be used to validate the given cert (the one of the
intermediate CA).

Sorry if I an unclear here. 

Date: Wed, 28 Apr 2004 19:39:08 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: FW: scvp
Cc: [email-masked]
Sender: [email-masked]

link the two ... and (1) and (2) together. 

(1) ... but the syntax is ambiguous. 

You cannot parse: 

    a BOOLEAN OPTIONAL,
    b BOOLEAN OPTIONAL,

you need to add tags

    a BOOLEAN OPTIONAL, 
    b [0] BOOLEAN OPTIONAL,

> 
> 2. How about changing the isCA boolean to entityType where entityType is
> an  enumerated list. Absence means don't care.

You can play with OPTIONAL instead of DEFAULT, which actually gives
a three value possibility but it is somewhat ugly. Absense of 'Any' 
you cannot really name it 'Any' because in the 88 version this is a reserved
word. 

But my question is not how to encode "this" but what is the actual
intended meaning and maybe why this is an independant parameter
and not as part of a validation algorithm for CAs.
 
For any validation algorithm specified, I don't see why one would care
whether the first element is a CA or not? 

I could understand a need to try to recursively go up a path for a particular
validation algorithm, and then one needs to say that the cert is
not the starting point of the path but an intermediate cert.

For example, if the the ssl server validation algo is used, the first
cert must contain, common name or subjectaltname and extendedkeyusage etc.
but if one goes up in the path, nothing of that is in the cert, on the
other hand, it may be part of the trust information to indicate whether
the ac in question can be use to sign such types of end entity certs.

Thus I am puzzled about the actual intention of having this field.
Or, there is no defined combination of the meaning isCA + sslserver
validation algorithm, at least not the interesting one as defined above.   

> 
> entityType ::= ENUMERATED {
>     Any                   (0),
>     endEntity             (1),
>     certificateAuthority  (2)}

Another option was suggested by peter gutmann, use a name bitlist for all these
things. 

The pb is that I don't see a useful case for the actual
semantics (even with three options), but rather a potential need to indicate
a partial path. You need to indicate a path length. one solution is an integer
that indicates how many certificates in the path are not present, default 0 means
that you have the complete beginning according to the validation algorithm,
1 means that you must test whether pathlen in basic contraints is at least 0 or
missing. This is useful import for DPD: Give a CA cert with at least a pathlen of
1 that can be used to validate the given cert (the one of the intermediate CA).

Sorry if I an unclear here. 

Content-class: urn:content-classes:message
Subject: RE: FW: scvp
Date: Wed, 28 Apr 2004 10:00:09 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,

What part of 1 are you referring to, the core 3280 parameters or the
parameters which are used over and above 3280?

2. How about changing the isCA boolean to entityType where entityType is
an  enumerated list. Absence means don't care.

entityType ::= ENUMERATED {
    Any                   (0),
    endEntity             (1),
    certificateAuthority  (2)}

Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2004 1:15 AM
To: [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: RE: FW: scvp

> Hi Peter,
> The additions optional allow the client to specify in the request the
> full range validation parameters defined in 3280 section 6. If you
read
> section 1, you will see a validation policy is the validation
algorithm
> plus the input parameter to the algorithm. SCVP14 defines all the base
> inputs as defined in 3280. New validation algorithm cab define
> additional input variable.
I saw the need for these parameters, but ... (1)

> The only other parameter you mention refers to Basic constraints, so
if
> a SCVP client want to validate what it believes is a CA certificate,
> then it passes in CA=true.
That's not what the spec says ... (2)

> 
> I am not sure whether I am the only person unable to construct a
parser.

(1) ... the syntax in umbiguous.

> in version 14 an aditional flag has been added which is not available
in
> the
> Chapter 9. Is the isCA flag an orthogonal attribut to other validation
> algorithms, or just to some of them, e.g,. the default name matching
> one? 

(2) ... there is no option saying client doesn't care whether the cert
is a CA or EE.

I am not sure whether one needs three options, or, for example:
"If set to TRUE, the caller requires a CA, otherwise, the caller doesn't
care." 

Date: Wed, 28 Apr 2004 09:53:31 -0400
From: Steve Hanna <[email-masked]>
Subject: Comments on Path Building I-D
To: PKIX List <[email-masked]>
Sender: [email-masked]

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

Here are my comments on draft-ietf-pkix-certpathbuild-03.txt.

I suspect that these will come off sounding negative.
I'm sorry about that. I'm glad we have this document
and I hope it will progress in a modified form, but
I have some serious problems with the document as
it now stands.

I also apologize for the length of these comments.
I wanted to do a careful review of the document
and there are a lot of problem areas (although
some are minor). The fact that nobody else has
commented on these leads me to suspect that nobody
except the authors and myself has carefully reviewed
the document. Can anyone refute that suspicion?

Thanks,

Steve

--------

Overall Comments:

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

   In this document, you advocate depth first search
   and suggest that building forward is usually best.
   I don't think you have carefully considered a wide
   variety of other algorithms like breadth first search,
   meet in the middle, etc. Can you show me any solid
   evidence that shows your algorithms are better than
   the alternatives?

   I doubt that you have any such proof. In fact, it
   seems clear to me that depth first search is a poor
   algorithm for building cert paths. I say this as a
   person who has implemented that algorithm myself
   and regretted it. The problem is that if you make
   a wrong choice, you must completely explore that
   part of the PKI before you consider backing out
   and trying other options. I have heard stories of
   path building taking 35 minutes or more when there
   was a valid short path because the builder used
   DFS and headed down the wrong path.

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

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

* At several places in the document, you refer to the
   "authors' opinions". If this was truly a working
   group document, it would reflect the consensus of
   the working group, not the opinions of the authors.
   As I said before, I don't see working group consensus
   on this topic. Has anyone other than me (and maybe
   the authors) carefully reviewed the current draft?
   I haven't seen any comments on it during Last Call.

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

* You should include in this document a section with
   guidance to PKI designers about what they can do to
   make path building easier. Here are some ideas:

   Use a simple topology (hierarchical with one root),
   when possible. Include AIA, SIA, and CRLDP extensions
   in certificates. Make certificates (especially CA
   certificates) and CRLs easily available by LDAP and
   HTTP, populating both sides of the crossCertificatePair
   attribute. Use name constraints and policy constraints
   whenever possible, especially at high fanout points
   like bridges. Avoid having more than two high fanout
   CAs (at most) between any two points, if possible.

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

Substantive Comments:

* Section 1.2 (Purpose) says "... this document suggests
   using ... depth first tree traversal. ... Other approaches
   (e.g., building complete spanning trees of the PKI.) exist
   and may be shown to be more effective under certain conditions."

   Building a complete spanning tree of the PKI is not a
   decent solution. Please change this to something more
   reasonable, like breadth first search. Otherwise, you're
   just setting up a straw man, an impractical alternative.

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

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

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

* At the end of section 1.4.3, you raise the concern that
   the assurance of a high-assurance PKI may be diluted by
   cross-certifying with a less restrictive PKI. If you're
   going to raise this concern, you should mention that it
   can be addressed through the use of certificate policies.

* At the end of section 1.4.4, you say that connecting
   PKIs with a bridge results in a non-hierarchical PKI.
   Certainly, this is true. But mesh and hybrid PKIs are
   not hierarchical either. Why raise this here? And the
   following sentence which states that any PKI can be
   considered hierarchical from the right perspective
   only applies if you remove and duplicate links in the
   PKI. Since you don't have space to get into this here,
   I suggest you remove those last two sentences.

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

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

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

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

* In section 2.2, you could simplify and clarify Criterion 1
   by changing it from this:

    Criterion 1: The implementation is able to find all possible paths.
    By this, it is meant that all possible certification paths between
    the trust anchor and the target certificate which may be valid paths
    can be built by the algorithm.

   to this:

    Criterion 1: The implementation is able to find all possible paths.
    By this, it is meant that all valid certification paths between
    the trust anchor and the target certificate can be built by the
    algorithm.

* In section 2.2, Criterion 2 seems rather odd. Who cares which
   invalid paths you build first? The important thing is how quickly
   and efficiently you can build a valid path or determine that
   no valid path exists.

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

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

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

* One paragraph on page 16 (starting with "A more complicated
   example") talks about problems with building in the
   reverse direction when there are many trust anchors.
   The real issue here is fanout. Whether you're building
   forward or building reverse, it's bad news when you get
   to a point where you have several choices. It's especially
   bad if your heuristics (ranking) don't give you much
   help in deciding which way to go. And it's even worse
   if you're using depth-first search, since one wrong
   move can send you off in the wrong direction for hours.
   That's why I suggest breadth first search or (even
   better) ranking all candidates at all points in
   the tree at each decision time.

   Four trust anchors is a four-way fanout. A similar
   situation would arise if you were building forward
   and arrived at a CA that has four certificates with
   it as the subject. In either case, you hope that your
   ranking will help choose the right path. And if you're
   using depth first search, you really hope that you
   don't take a wrong turn. One technique for dealing
   with extreme fanout with fairly equal rankings is to
   start building from the other end. Another is to rank
   the certs at the fanout point low and try another branch.
   A third is to use DPD to get help. And a fourth is to
   tell PKI designers to use name constraints and other
   techniques at high fanout points (like bridges) to
   help path building succeed.

   I hope that you find this analysis useful.

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

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

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

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

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

* In section 2.6, you say "[...] the path builder
   only needs to store the current location in
   the tree [...] All completed branches can be
   discarded from memory [...]". Maybe. There's
   a lot to be said for retaining records of
   paths you have already tried and rejected.
   Then you can avoid retrying them at a different
   point in the graph (unless conditions are
   sufficiently different to merit a retry).

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

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

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

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

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

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

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

* A few paragraphs later, you lay out your approach.
   Here are some comments on it:

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

   You say "Do not check digital signatures". Again, why
   not run this in parallel? Most of path building time
   (about 90%, based on our data) is spent waiting for
   the network (while downloading certificates and such).
   That's an ideal time to be checking signatures. And,
   of course, you'll want to cache the results of signature
   checks.

   You say "Do not check anything that can not be checked
   as part of the iterative process of traversing the tree."
   Why not? I expect you would want to run these final checks
   (like full policy processing when building forward) before
   returning the path to the caller. Otherwise, the caller
   will need to run a complete validation of the path, which
   will take much more time than just running these last
   few checks.

* In the last paragraph of 3.2, you say "Second, it is fairly
   uncommon in typical application environments to encounter
   a revoked key; therefore, most certificates validated will
   not be revoked." In a PKI, we don't revoke a key. We revoke
   a certificate. Therefore, this sentence should read "Second,
   it is fairly uncommon in typical application environments to
   encounter a revoked certificate."

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

* In section 3.4, you refer say "developers should evaluate
   each method with respect to the environment that the
   application will operate, and assign weights to each
   accordingly in the path building software.". First, the
   word "that" in this sentence should be "in which". Second,
   this is a prime example of the awful idea that developers
   must examine each PKI and configure their software to
   run optimally there.

* In section 3.5.1, you say "According to [RFC 3280],
   basicConstraints is required to be present with cA=TRUE
   in all CA certificates." Actually, section 6.1.4 (k) of
   RFC 3280 says "Verify that the certificate is a CA
   certificate (as specified in a basicConstraints extension
   or as verified out-of-band)." Maybe your software doesn't
   make any provision for out-of-band indication of CA
   certificates, but you should probably at least note the
   possibility that other software may do so.

* In section 3.5.5, you say "Certificates in the path cache
   have been validated previously. There is some probability
   that the path from that certificate to a trust anchor is
   still valid." The path may still be valid but it may
   contain constraints that are inconsistent with the
   path from the Target Certificate to this certificate.
   You should probably note that possibility.

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

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

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

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

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

   You should also probably change this section to include
   discussion of OCSP. Right now, it's very focussed on
   CRLs.

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

* In section 3.5.15 (on RDN matching), you say "Additionally,
   it should be noted that this method can require a lot of
   processing if many trust anchors are present." Actually,
   this should only require a few hash table lookups (of the
   RDNs).

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

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

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

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

* In section 3.5.20, you use the presence of a CRL in
   the CRL cache to indicate whether a complete path
   through a CA has previously been found. This is
   rather indirect. It would be better to actually
   track which certs have been previously included
   in valid paths. Keeping a copy of the path would
   also be quite useful.

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

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

* In section 6 (Retrieval Methods), you should mention
   getting certificates and CRLs from the target (with
   S/MIME or SSL/TLS, for instance). That's a *great*
   way to get certificates and CRLs. The ones you get
   are usually highly valuable.

* Sections 6.2 and 6.3 should include text that encourages
   implementers to support AIA and SIA, especially HTTP.
   This text from the end of section 6.4 could easily
   be adapted:

       However, implementers of path building
    and validation modules are strongly encouraged to support CRLDPs.  At
    a minimum, developers are encouraged to consider supporting the LDAP
    and HTTP transports; this will provide for interoperability across a
    wide range of existing PKIs.

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

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

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

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

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

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

Minor Comments:

* The first paragraph of section 2 says "... guidance is
   provided on the capabilities path building implementations
   required in order to ...". I think you want "require" or
   (maybe better due to RFC 2119) "need" instead of "required".

* Just below Figure 6, "the certificates cannot be validated"
   should be "certificates cannot be validated". You're not
   referring to any particular certificates, just certificates
   in general.

* In the paragraph after that, you should say "the
   crossCertificatePair attribute" instead of "the cross
   certificates". Otherwise, it's not clear what you mean.

* In the second paragraph of section 3.2, you say a
   certificate "may appear again on another point in
   the tree". That should be "at another point in
   the tree".

* At the end of section 3.4, "The list" should be "the list".

* In section 3.5.17, there are two typos. "it priority"
   should be "it has priority". "will not successfully"
   (in the last paragraph) should be "will not verify
   successfully".

* In section 5.4, you say certificates "will be" required
   to use UTF-8 after January 1, 2004. This should now
   be changed to "are".

* In section 6, the first sentence should mention CRLs
   also. I suggest that the second sentence say "obtaining
   these certificates and CRLs" instead of "performing
   this retrieval", since retrieval has not yet been
   mentioned and sometimes the certificates can be
   obtained without having to be retrieved (as when the
   EE sends them in SSL).

* In section 6.1, the description of userCertificate
   should probably say that it "contains certificates
   issued by one or more certification authorities with
   a subject DN that matches that of the directory entry".
   Also, there's an extra period at the end of the
   parenthetical comment later in the paragraph.

* Later in section 6.1, the description of issuedByThisCA
   should say it contains certificates issued to *other*
   CAs. And there's an extra comma after "If both elements
   are present" (later in that paragraph). Why include that
   sentence anyway. The relying party doesn't need to
   enforce this requirement. People may think they need
   to do so.

* In section 6.2, you say "AIA may be used to retrieve one or
   more certificates for entities that issued the certificate
   containing the AIA extension." I think it would be clearer
   to say "the CA" instead of "entities".

* At the end of the first paragraph of section 6.3, "AIA"
   appears twice where it should be "SIA".

* In section 6.4, you say "the CRL(s) to which the CRLDP(s) refer
   is the CRL that would contain revocation information for the
   certificate." I'd say instead "the CRL(s) to which the CRLDP
   refers are generally the CRLs that would contain revocation
   information for the certificate." Why? Because a CRLDP may
   refer an LDAP directory entry that contains many CRLs. Some
   of them may not pertain to this certificate. And of course
   there's usually only one CRLDP in a certificate.

* In section 8.2, "q CRL Signer" should be "a CRL Signer".

* In the Informative References, you include "[MINHPKIS]"
   but it's never actually referred to anywhere in the document.
   Similarly for [X.501] and [X.520]. You should probably
   remove those references. If you're going to retain them
   for some reason, please provide a decent reference for
   [MINHPKIS]: publisher, publication date.

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

--------------ms020703040003000503010505--

Date: Wed, 28 Apr 2004 12:03:01 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: FW: scvp
Cc: [email-masked]
Sender: [email-masked]

> 
> The issuer of the OID will have to provide the full definition. If there are 
> some parameters (which is not mandatory at all), then it will define the 
> ASN.1 syntax, and then you will be able to compile it.
> 

What about semantics? It is not just a question of ASN1 structure compilation.

Date: Wed, 28 Apr 2004 11:30:00 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Meaning of CP in a CA certificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> 
> >>I believe that this is a mis-interpretation from the editors of RFC 3280.
> >>
> > 3280 and X509 have the same textual definition concerning the value
> > of the policy extension. what do you think is available in X509
> > which is not available in 3280? What can be misinterpreted if
> > both texts are identical?
> > 
> > In both text, there is no provision to indicate in a CA cert some
> > policy that governs a CA cert. 
> 
> If you had not suppressed the text from my previous e-mail, then you would 
> have seen that the texts are different.

I refered to the text that defines the meaning of the policy extension,
they are both identical in X509 and 3280. 
 
The text about any policy in 3280 was added as a result to a defect
report in X.509. You have statements about semantics in both texts
which are not necessarily identical but are supposed to be semantically
equivalent as far as I remember.

> >>>Are you saying that for example you are looking for
> >>>"some path that creates Qualified certificates" but only if the
> >>>CA certs are created under a policy indicating "some particular 
> >>>more or less global UN policy concering CAs"' ?
> >>
> > 
> > You have not answered the previous question.
> 
> This question is not understandable for me.

A combination of a policy indication in the end entity cert, and some
information that the CA certificate is a certifiction authority
belonging to a country administration issuing passports or id cards,
indicated by a "gobal policy". This seems to me what you are asking for:
adding "qualified certificate" as policy for the ee-certs and 
"country authority ca" as a policy for the ca. 

Remembering the discussion about policies some days ago, this seems again
wanting another type of hierarchy since name chains to trust anchors are 
not sufficient, because we don't like names, etc.  

Date: Wed, 28 Apr 2004 10:15:03 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: FW: scvp
Cc: [email-masked]
Sender: [email-masked]

> Hi Peter,
> The additions optional allow the client to specify in the request the
> full range validation parameters defined in 3280 section 6. If you read
> section 1, you will see a validation policy is the validation algorithm
> plus the input parameter to the algorithm. SCVP14 defines all the base
> inputs as defined in 3280. New validation algorithm cab define
> additional input variable.
I saw the need for these parameters, but ... (1)

> The only other parameter you mention refers to Basic constraints, so if
> a SCVP client want to validate what it believes is a CA certificate,
> then it passes in CA=true.
That's not what the spec says ... (2)

> 
> I am not sure whether I am the only person unable to construct a parser.

(1) ... the syntax in umbiguous.

> in version 14 an aditional flag has been added which is not available in
> the
> Chapter 9. Is the isCA flag an orthogonal attribut to other validation
> algorithms, or just to some of them, e.g,. the default name matching
> one? 

(2) ... there is no option saying client doesn't care whether the cert is a CA or EE.

I am not sure whether one needs three options, or, for example:
"If set to TRUE, the caller requires a CA, otherwise, the caller doesn't care." 

Content-class: urn:content-classes:message
Subject: RE: SMIME Capabilities in X.509 certificates.
Date: Tue, 27 Apr 2004 21:35:27 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>
Sender: [email-masked]

OK Steve.

The issue on the table is whether it should be a standardized option to
include the SMIME capability attribute in a certificate.

This extension, when present in certificates is used as the last
resource to figure out the appropriate configuration/capabilities of an
S/MIME opponent before falling back to default configuration for unknown
users.

But if there is a known previous S/MIME message from the recipient from
which the recipient's capabilities can be extracted, the certificate
extension would typically be ignored.

The underlying rationale for this is that in a store and forward type of
communication such as e-mail, we may run into situation where one party
need to guess the capabilities of the opponent and the guiding principle
is that the more information we can use to make the best guess, the
better it is.

So, again, please state your opinion so we can either do this or put it
away. If it is to be done, the task should be very simple since there
should be no reason to deviate from the current syntax of the
SMIMECapabilities attribute used in S/MIME.

Stefan Santesson

> From: Stephen Kent [mailto:[email-masked]]
> Sent: den 9 april 2004 10:34
> To: Stefan Santesson
> Cc: [email-masked]

Content-class: urn:content-classes:message
Subject: RE: FW: scvp
Date: Tue, 27 Apr 2004 11:57:24 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Denis,

Can you please be more specific how you think SCVP 14 does not comply
with 3379.

I can find no section in 3379 where is there a requirement that a
validation policy MUST be represented as an OID. 

Given hiding the detail of what a policy is within an OID simply opens
the rat hole of what change to the policy constitutes a change to the
OID, it is less ambiguous to refer to the primary data. Once you are in
the business of managing state on a client, then there is negligible
cost increase incurred in managing several data points vs. a singe data
point.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, April 27, 2004 11:01 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: FW: scvp

Trevor,

> HI Denis,
> In SCVP13, the concept of validation policy was not completely in
> alignment  with 3379 definition. 

Well, it is different and this is a major problem.

> It also blurred the distinction between
> validation policy and validation algorithm. 

This is also a majo problem.

> Therefore I have defined
> what each is in SCVP 14 and aligned the structures accordingly.
> Section 1.3 has the following.
> "In SCVP, the validation policy comprises of an algorithm for
> certificate path processing and the input parameters to the
algorithm."

This does not comply with RFC 3379.

> Therefore trust anchors are an input into the algorithm  and therefore
> separate.

Therefore I do not follow you.

 From an interface point of view the simplest validation policy is
defined 
by an OID where all the parameters necessary to perform the validation
check 
are "behind" the OID. There is no need to provide any parameter through
the 
interface.

When there are some parameters, then they are specific to the validation

policy. I have no problem to provide specific parameters for what is
called 
the "default validation policy" which is only a particular validation
policy 
among many others.

Simple clients will be unable to pass any parameter but will know which
OIDs 
(for the validation policy) are appropriate for their applications.

Denis

> This is in alignment with 3379s definition of validation policy.
> 
> Trevor
> 
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Monday, April 26, 2004 1:09 AM
> To: Peter Sylvester
> Cc: [email-masked]; Trevor Freeman
> Subject: Re: FW: scvp
> 
> Peter and Trevor,
> 
> I have major problems too.
> 
> 
>>in version 13 the syntax for a Query has been changed from
>>
>>   Query ::= SEQUENCE { 
>>       queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>>       checks                CertChecks, 
>>       wantBack              WantBack, 
>>       serverContextInfo [0] OCTET STRING OPTIONAL, 
>>       valPolicy         [1] ValidationPolicy OPTIONAL, 
>>       validityTime      [2] GeneralizedTime OPTIONAL, 
>>       trustAnchors      [3] TrustAnchors OPTIONAL, 
>>       intermediateCerts [4] CertBundle OPTIONAL, 
>>       revInfos          [5] RevocationInfos OPTIONAL, 
>>       queryExtensions   [6] Extensions OPTIONAL } 
> 
> 
> In this structure trustAnchors was more or less an alternative to
> valPolicy.
> 
> In fact, IF the valPolicy is the default policy, THEN additional
> parameters 
> MUST be provided. So the structure below does not fit as well.
> 
> This leads to have the two following elements:
> 
>      valPolicy               ValidationPolicy,
>      paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
> 
> where the first one is mandatory and the second one optional.
> 
> 
>>to  
>>
>>    Query ::= SEQUENCE { 
>>      queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
> 
> 
>>      checks                  CertChecks, 
>>      wantBack                WantBack, 
>>      requestRefHash          BOOLEAN DEFAULT TRUE, 
>>      includePolResponce      BOOLEAN DEFAULT FALSE, 
>>      inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>      requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>      ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>      valAlgorithm            ValidationAlgorithm, 
>>      serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>      validityTime        [1] GeneralizedTime OPTIONAL, 
>>      trustAnchors        [2] TrustAnchors OPTIONAL, 
>>      intermediateCerts   [3] CertBundle OPTIONAL, 
>>      revInfos            [4] RevocationInfos OPTIONAL, 
>>      queryExtensions     [5] Extensions OPTIONAL } 
> 
> 
> I would thus propose to have something like:
> 
> Query ::= SEQUENCE {
>          queriedCerts            SEQUENCE SIZE (1..MAX) OF
> CertReference,
>          checks                  CertChecks,
>          wantBack                WantBack,
>          requestRefHash          BOOLEAN DEFAULT TRUE,
>          serverContextInfo       OCTET STRING OPTIONAL,
>          validityTime            GeneralizedTime OPTIONAL,
>          includePolResponse      BOOLEAN DEFAULT FALSE,
>          valPolicy               ValidationPolicy,
>          paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
>          intermediateCerts   [1] CertBundle OPTIONAL,
>          revInfos            [2] RevocationInfos OPTIONAL,
>          queryExtensions     [3] Extensions OPTIONAL }
> 
> and then something like:
> 
>     ParamsDefValPolicy :: = SEQUENCE {
>         trustAnchors                  TrustAnchors,
>         endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
> OPTIONAL,
>         inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>         caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
> OPTIONAL }
> 
> Denis
> 
> 
>>I am not sure whether I am the only person unable to construct a
> 
> parser.
> 
>>in version 14 an aditional flag has been added which is not available
> 
> in the
> 
>>Chapter 9. Is the isCA flag an orthogonal attribut to other validation
>>algorithms, or just to some of them, e.g,. the default name matching
> 
> one? 
> 
>> 
>>    Query ::= SEQUENCE { 
>>      queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
> 
> 
>>      checks                  CertChecks, 
>>      wantBack                WantBack, 
>>      requestRefHash          BOOLEAN DEFAULT TRUE, 
>>      includePolResponce      BOOLEAN DEFAULT FALSE, 
>>      inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>      requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>      ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>      isCA                    BOOLEAN DEFAULT FALSE, 
>>      valAlgorithm            ValidationAlgorithm, 
>>      serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>      validityTime        [1] GeneralizedTime OPTIONAL, 
>>      trustAnchors        [2] TrustAnchors OPTIONAL, 
>>      intermediateCerts   [3] CertBundle OPTIONAL, 
>>      revInfos            [4] RevocationInfos OPTIONAL, 
>>      keyUsage            [5] KeyUsage OPTIONAL, 
>>      extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>>      queryExtensions     [7] Extensions OPTIONAL  
>>      producedAt          [8] GeneralizedTime OPTIONAL} 
>>
>>
> 
> 
> 
> 

Date: Tue, 27 Apr 2004 20:01:14 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
Subject: Re: FW: scvp
Sender: [email-masked]

Trevor,

> HI Denis,
> In SCVP13, the concept of validation policy was not completely in
> alignment  with 3379 definition. 

Well, it is different and this is a major problem.

> It also blurred the distinction between
> validation policy and validation algorithm. 

This is also a majo problem.

> Therefore I have defined
> what each is in SCVP 14 and aligned the structures accordingly.
> Section 1.3 has the following.
> "In SCVP, the validation policy comprises of an algorithm for
> certificate path processing and the input parameters to the algorithm."

This does not comply with RFC 3379.

> Therefore trust anchors are an input into the algorithm  and therefore
> separate.

Therefore I do not follow you.

 From an interface point of view the simplest validation policy is defined 
by an OID where all the parameters necessary to perform the validation check 
are "behind" the OID. There is no need to provide any parameter through the 
interface.

When there are some parameters, then they are specific to the validation 
policy. I have no problem to provide specific parameters for what is called 
the "default validation policy" which is only a particular validation policy 
among many others.

Simple clients will be unable to pass any parameter but will know which OIDs 
(for the validation policy) are appropriate for their applications.

Denis

> This is in alignment with 3379s definition of validation policy.
> 
> Trevor
> 
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Monday, April 26, 2004 1:09 AM
> To: Peter Sylvester
> Cc: [email-masked]; Trevor Freeman
> Subject: Re: FW: scvp
> 
> Peter and Trevor,
> 
> I have major problems too.
> 
> 
>>in version 13 the syntax for a Query has been changed from
>>
>>   Query ::= SEQUENCE { 
>>       queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>>       checks                CertChecks, 
>>       wantBack              WantBack, 
>>       serverContextInfo [0] OCTET STRING OPTIONAL, 
>>       valPolicy         [1] ValidationPolicy OPTIONAL, 
>>       validityTime      [2] GeneralizedTime OPTIONAL, 
>>       trustAnchors      [3] TrustAnchors OPTIONAL, 
>>       intermediateCerts [4] CertBundle OPTIONAL, 
>>       revInfos          [5] RevocationInfos OPTIONAL, 
>>       queryExtensions   [6] Extensions OPTIONAL } 
> 
> 
> In this structure trustAnchors was more or less an alternative to
> valPolicy.
> 
> In fact, IF the valPolicy is the default policy, THEN additional
> parameters 
> MUST be provided. So the structure below does not fit as well.
> 
> This leads to have the two following elements:
> 
>      valPolicy               ValidationPolicy,
>      paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
> 
> where the first one is mandatory and the second one optional.
> 
> 
>>to  
>>
>>    Query ::= SEQUENCE { 
>>      queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
> 
> 
>>      checks                  CertChecks, 
>>      wantBack                WantBack, 
>>      requestRefHash          BOOLEAN DEFAULT TRUE, 
>>      includePolResponce      BOOLEAN DEFAULT FALSE, 
>>      inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>      requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>      ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>      valAlgorithm            ValidationAlgorithm, 
>>      serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>      validityTime        [1] GeneralizedTime OPTIONAL, 
>>      trustAnchors        [2] TrustAnchors OPTIONAL, 
>>      intermediateCerts   [3] CertBundle OPTIONAL, 
>>      revInfos            [4] RevocationInfos OPTIONAL, 
>>      queryExtensions     [5] Extensions OPTIONAL } 
> 
> 
> I would thus propose to have something like:
> 
> Query ::= SEQUENCE {
>          queriedCerts            SEQUENCE SIZE (1..MAX) OF
> CertReference,
>          checks                  CertChecks,
>          wantBack                WantBack,
>          requestRefHash          BOOLEAN DEFAULT TRUE,
>          serverContextInfo       OCTET STRING OPTIONAL,
>          validityTime            GeneralizedTime OPTIONAL,
>          includePolResponse      BOOLEAN DEFAULT FALSE,
>          valPolicy               ValidationPolicy,
>          paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
>          intermediateCerts   [1] CertBundle OPTIONAL,
>          revInfos            [2] RevocationInfos OPTIONAL,
>          queryExtensions     [3] Extensions OPTIONAL }
> 
> and then something like:
> 
>     ParamsDefValPolicy :: = SEQUENCE {
>         trustAnchors                  TrustAnchors,
>         endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
> OPTIONAL,
>         inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>         caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
> OPTIONAL }
> 
> Denis
> 
> 
>>I am not sure whether I am the only person unable to construct a
> 
> parser.
> 
>>in version 14 an aditional flag has been added which is not available
> 
> in the
> 
>>Chapter 9. Is the isCA flag an orthogonal attribut to other validation
>>algorithms, or just to some of them, e.g,. the default name matching
> 
> one? 
> 
>> 
>>    Query ::= SEQUENCE { 
>>      queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
> 
> 
>>      checks                  CertChecks, 
>>      wantBack                WantBack, 
>>      requestRefHash          BOOLEAN DEFAULT TRUE, 
>>      includePolResponce      BOOLEAN DEFAULT FALSE, 
>>      inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>      requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>      ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>      isCA                    BOOLEAN DEFAULT FALSE, 
>>      valAlgorithm            ValidationAlgorithm, 
>>      serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>      validityTime        [1] GeneralizedTime OPTIONAL, 
>>      trustAnchors        [2] TrustAnchors OPTIONAL, 
>>      intermediateCerts   [3] CertBundle OPTIONAL, 
>>      revInfos            [4] RevocationInfos OPTIONAL, 
>>      keyUsage            [5] KeyUsage OPTIONAL, 
>>      extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>>      queryExtensions     [7] Extensions OPTIONAL  
>>      producedAt          [8] GeneralizedTime OPTIONAL} 
>>
>>
> 
> 
> 
> 

Date: Tue, 27 Apr 2004 20:00:23 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Meaning of CP in a CA certificate
Sender: [email-masked]

Peter,

>>I believe that this is a mis-interpretation from the editors of RFC 3280.
>>
> 3280 and X509 have the same textual definition concerning the value
> of the policy extension. what do you think is available in X509
> which is not available in 3280? What can be misinterpreted if
> both texts are identical?
> 
> In both text, there is no provision to indicate in a CA cert some
> policy that governs a CA cert. 

If you had not suppressed the text from my previous e-mail, then you would 
have seen that the texts are different.

> 
>>Denis
>>
>>
>>>Are you saying that for example you are looking for
>>>"some path that creates Qualified certificates" but only if the
>>>CA certs are created under a policy indicating "some particular 
>>>more or less global UN policy concering CAs"' ?
>>
> 
> You have not answered the previous question.

This question is not understandable for me.

Denis

Date: Tue, 27 Apr 2004 19:58:09 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: FW: scvp
Sender: [email-masked]

Peter,

>>Do you want something like 
>>>
>>>   validationPolicyParameters ANY DEFINED BY theValidationPolicy
>>
>>Yes.
> 
> unless I'm wrong, validation policies identifiers are something like
> the policy identifier in RFC 3161? if so, the number is unlimited,
> and you cannot use really these ids in an any define by construct.

The issuer of the OID will have to provide the full definition. If there are 
some parameters (which is not mandatory at all), then it will define the 
ASN.1 syntax, and then you will be able to compile it.

Denis

> And how would you construct an ASN1 parser for this, how would
> a parser learn dynamically what syntax (and semantics) you need.
> 
> Isn't exactly the technical nonsense that we had in version 12,
> the validation algorithm syntaxes had been split off in v13,
> in a validation policy you indicate now as a parameter. 
> 
> "use validation algorithm OIDofsslserver + dns=this.domain", 
> 
> you could try to define things like that for each step for the
> validation path, saying, "the ca that signs at level 1 must
> be validates using cavalidation algorithm 'standard 3280 default
> path' (or one of a few of others), and the parameters for algorithm are
> 'the OCSP server to validate', frequence of validation time?? or others. 
> 
> I think one should first try and define a language for ... ooups, SPKI 
> 
>  
>  
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cross certificate format
Date: Tue, 27 Apr 2004 09:14:42 -0400
Importance: Normal
Sender: [email-masked]

Tom:

My point is that even if the trust anchor is a self-signed certificate, all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element of
the cross certificate pair is nothing but an intermediate CA certificate in
a certification path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 
be provided as "a self-signed certificate", with no further qualification. 
 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/26/2004 08:51 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Cross certificate format

        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 

it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 

by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 

with the KeyUsage extension present, it is only a valid issuer certificate 

if keyCertSign is set.

        Tom Gindin

Jean-Marc Desperrier <[email-masked]>
Sent by: [email-masked]
04/21/2004 03:42 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Cross certificate format

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed
> certificates,

>which contain no extensions at all (see the text of RFC 3280's 
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Cross certificate format
From: Tom Gindin <[email-masked]>
Date: Tue, 27 Apr 2004 07:33:24 -0400
Sender: [email-masked]

        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 
be provided as "a self-signed certificate", with no further qualification. 
 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/26/2004 08:51 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Cross certificate format

        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 

it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 

by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 

with the KeyUsage extension present, it is only a valid issuer certificate 

if keyCertSign is set.

        Tom Gindin

Jean-Marc Desperrier <[email-masked]>
Sent by: [email-masked]
04/21/2004 03:42 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Cross certificate format

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed 
> certificates,

>which contain no extensions at all (see the text of RFC 3280's
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.

Content-class: urn:content-classes:message
Subject: RE: FW: scvp
Date: Mon, 26 Apr 2004 23:29:20 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Peter,
The additions optional allow the client to specify in the request the
full range validation parameters defined in 3280 section 6. If you read
section 1, you will see a validation policy is the validation algorithm
plus the input parameter to the algorithm. SCVP14 defines all the base
inputs as defined in 3280. New validation algorithm cab define
additional input variable.
The only other parameter you mention refers to Basic constraints, so if
a SCVP client want to validate what it believes is a CA certificate,
then it passes in CA=true.

Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Friday, April 23, 2004 11:19 AM
To: [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: Re: FW: scvp

in version 13 the syntax for a Query has been changed from

   Query ::= SEQUENCE { 
       queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
       checks                CertChecks, 
       wantBack              WantBack, 
       serverContextInfo [0] OCTET STRING OPTIONAL, 
       valPolicy         [1] ValidationPolicy OPTIONAL, 
       validityTime      [2] GeneralizedTime OPTIONAL, 
       trustAnchors      [3] TrustAnchors OPTIONAL, 
       intermediateCerts [4] CertBundle OPTIONAL, 
       revInfos          [5] RevocationInfos OPTIONAL, 
       queryExtensions   [6] Extensions OPTIONAL } 
    
to  

    Query ::= SEQUENCE { 
      queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference, 
      checks                  CertChecks, 
      wantBack                WantBack, 
      requestRefHash          BOOLEAN DEFAULT TRUE, 
      includePolResponce      BOOLEAN DEFAULT FALSE, 
      inhibitPolMap           BOOLEAN DEFAULT FALSE, 
      requireExplicitPol      BOOLEAN DEFAULT FALSE, 
      ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
      valAlgorithm            ValidationAlgorithm, 
      serverContextInfo   [0] OCTET STRING OPTIONAL, 
      validityTime        [1] GeneralizedTime OPTIONAL, 
      trustAnchors        [2] TrustAnchors OPTIONAL, 
      intermediateCerts   [3] CertBundle OPTIONAL, 
      revInfos            [4] RevocationInfos OPTIONAL, 
      queryExtensions     [5] Extensions OPTIONAL } 

I am not sure whether I am the only person unable to construct a parser.

in version 14 an aditional flag has been added which is not available in
the
Chapter 9. Is the isCA flag an orthogonal attribut to other validation
algorithms, or just to some of them, e.g,. the default name matching
one? 

    Query ::= SEQUENCE { 
      queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference, 
      checks                  CertChecks, 
      wantBack                WantBack, 
      requestRefHash          BOOLEAN DEFAULT TRUE, 
      includePolResponce      BOOLEAN DEFAULT FALSE, 
      inhibitPolMap           BOOLEAN DEFAULT FALSE, 
      requireExplicitPol      BOOLEAN DEFAULT FALSE, 
      ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
      isCA                    BOOLEAN DEFAULT FALSE, 
      valAlgorithm            ValidationAlgorithm, 
      serverContextInfo   [0] OCTET STRING OPTIONAL, 
      validityTime        [1] GeneralizedTime OPTIONAL, 
      trustAnchors        [2] TrustAnchors OPTIONAL, 
      intermediateCerts   [3] CertBundle OPTIONAL, 
      revInfos            [4] RevocationInfos OPTIONAL, 
      keyUsage            [5] KeyUsage OPTIONAL, 
      extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
      queryExtensions     [7] Extensions OPTIONAL  
      producedAt          [8] GeneralizedTime OPTIONAL} 

Content-class: urn:content-classes:message
Subject: RE: FW: scvp
Date: Mon, 26 Apr 2004 11:41:54 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

SCVP assumes that the minimum processing for certificate validation is
defined in 3280 and supports that set of data independently of the
algorithm definition. This set of data is universal to all SCVP
validation. If as part of a new algorithm you define additional data,
then that data can be added to the inputs to the new algorithm. An
illustration of how this works is given in SCVP 3.2.11.2 where some name
checking is also performed which is over and above the 3280 checking.
Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Monday, April 26, 2004 10:19 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Trevor Freeman
Subject: Re: FW: scvp

> > Do you want something like 
> > 
> >    validationPolicyParameters ANY DEFINED BY theValidationPolicy
> 
> Yes.

unless I'm wrong, validation policies identifiers are something like
the policy identifier in RFC 3161? if so, the number is unlimited,
and you cannot use really these ids in an any define by construct.

And how would you construct an ASN1 parser for this, how would
a parser learn dynamically what syntax (and semantics) you need.

Isn't exactly the technical nonsense that we had in version 12,
the validation algorithm syntaxes had been split off in v13,
in a validation policy you indicate now as a parameter. 

"use validation algorithm OIDofsslserver + dns=this.domain", 

you could try to define things like that for each step for the
validation path, saying, "the ca that signs at level 1 must
be validates using cavalidation algorithm 'standard 3280 default
path' (or one of a few of others), and the parameters for algorithm are
'the OCSP server to validate', frequence of validation time?? or others.

I think one should first try and define a language for ... ooups, SPKI 

Content-class: urn:content-classes:message
Subject: RE: FW: scvp
Date: Mon, 26 Apr 2004 11:30:14 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

HI Denis,
In SCVP13, the concept of validation policy was not completely in
alignment  with 3379 definition. It also blurred the distinction between
validation policy and validation algorithm. Therefore I have defined
what each is in SCVP 14 and aligned the structures accordingly.
Section 1.3 has the following.
"In SCVP, the validation policy comprises of an algorithm for
certificate path processing and the input parameters to the algorithm."

Therefore trust anchors are an input into the algorithm  and therefore
separate.

This is in alignment with 3379s definition of validation policy.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Monday, April 26, 2004 1:09 AM
To: Peter Sylvester
Cc: [email-masked]; Trevor Freeman
Subject: Re: FW: scvp

Peter and Trevor,

I have major problems too.

> in version 13 the syntax for a Query has been changed from
> 
>    Query ::= SEQUENCE { 
>        queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>        checks                CertChecks, 
>        wantBack              WantBack, 
>        serverContextInfo [0] OCTET STRING OPTIONAL, 
>        valPolicy         [1] ValidationPolicy OPTIONAL, 
>        validityTime      [2] GeneralizedTime OPTIONAL, 
>        trustAnchors      [3] TrustAnchors OPTIONAL, 
>        intermediateCerts [4] CertBundle OPTIONAL, 
>        revInfos          [5] RevocationInfos OPTIONAL, 
>        queryExtensions   [6] Extensions OPTIONAL } 

In this structure trustAnchors was more or less an alternative to
valPolicy.

In fact, IF the valPolicy is the default policy, THEN additional
parameters 
MUST be provided. So the structure below does not fit as well.

This leads to have the two following elements:

     valPolicy               ValidationPolicy,
     paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,

where the first one is mandatory and the second one optional.

> to  
> 
>     Query ::= SEQUENCE { 
>       queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,

>       checks                  CertChecks, 
>       wantBack                WantBack, 
>       requestRefHash          BOOLEAN DEFAULT TRUE, 
>       includePolResponce      BOOLEAN DEFAULT FALSE, 
>       inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>       requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>       ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>       valAlgorithm            ValidationAlgorithm, 
>       serverContextInfo   [0] OCTET STRING OPTIONAL, 
>       validityTime        [1] GeneralizedTime OPTIONAL, 
>       trustAnchors        [2] TrustAnchors OPTIONAL, 
>       intermediateCerts   [3] CertBundle OPTIONAL, 
>       revInfos            [4] RevocationInfos OPTIONAL, 
>       queryExtensions     [5] Extensions OPTIONAL } 

I would thus propose to have something like:

Query ::= SEQUENCE {
         queriedCerts            SEQUENCE SIZE (1..MAX) OF
CertReference,
         checks                  CertChecks,
         wantBack                WantBack,
         requestRefHash          BOOLEAN DEFAULT TRUE,
         serverContextInfo       OCTET STRING OPTIONAL,
         validityTime            GeneralizedTime OPTIONAL,
         includePolResponse      BOOLEAN DEFAULT FALSE,
         valPolicy               ValidationPolicy,
         paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
         intermediateCerts   [1] CertBundle OPTIONAL,
         revInfos            [2] RevocationInfos OPTIONAL,
         queryExtensions     [3] Extensions OPTIONAL }

and then something like:

    ParamsDefValPolicy :: = SEQUENCE {
        trustAnchors                  TrustAnchors,
        endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
OPTIONAL,
        inhibitPolMap                 BOOLEAN DEFAULT FALSE,
        caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
OPTIONAL }

Denis

> I am not sure whether I am the only person unable to construct a
parser.
> 
> in version 14 an aditional flag has been added which is not available
in the
> Chapter 9. Is the isCA flag an orthogonal attribut to other validation
> algorithms, or just to some of them, e.g,. the default name matching
one? 
> 
>  
>     Query ::= SEQUENCE { 
>       queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,

>       checks                  CertChecks, 
>       wantBack                WantBack, 
>       requestRefHash          BOOLEAN DEFAULT TRUE, 
>       includePolResponce      BOOLEAN DEFAULT FALSE, 
>       inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>       requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>       ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>       isCA                    BOOLEAN DEFAULT FALSE, 
>       valAlgorithm            ValidationAlgorithm, 
>       serverContextInfo   [0] OCTET STRING OPTIONAL, 
>       validityTime        [1] GeneralizedTime OPTIONAL, 
>       trustAnchors        [2] TrustAnchors OPTIONAL, 
>       intermediateCerts   [3] CertBundle OPTIONAL, 
>       revInfos            [4] RevocationInfos OPTIONAL, 
>       keyUsage            [5] KeyUsage OPTIONAL, 
>       extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>       queryExtensions     [7] Extensions OPTIONAL  
>       producedAt          [8] GeneralizedTime OPTIONAL} 
> 
> 

Date: Mon, 26 Apr 2004 19:40:52 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Meaning of CP in a CA certificate
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 
> I believe that this is a mis-interpretation from the editors of RFC 3280.
> 

3280 and X509 have the same textual definition concerning the value
of the policy extension. what do you think is available in X509
which is not available in 3280? What can be misinterpreted if
both texts are identical?

In both text, there is no provision to indicate in a CA cert some
policy that governs a CA cert. 

> Denis
> 
> > Are you saying that for example you are looking for
> > "some path that creates Qualified certificates" but only if the
> > CA certs are created under a policy indicating "some particular 
> > more or less global UN policy concering CAs"' ?

You have not answered the previous question.

Date: Mon, 26 Apr 2004 19:18:40 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: FW: scvp
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> > Do you want something like 
> > 
> >    validationPolicyParameters ANY DEFINED BY theValidationPolicy
> 
> Yes.

unless I'm wrong, validation policies identifiers are something like
the policy identifier in RFC 3161? if so, the number is unlimited,
and you cannot use really these ids in an any define by construct.

And how would you construct an ASN1 parser for this, how would
a parser learn dynamically what syntax (and semantics) you need.

Isn't exactly the technical nonsense that we had in version 12,
the validation algorithm syntaxes had been split off in v13,
in a validation policy you indicate now as a parameter. 

"use validation algorithm OIDofsslserver + dns=this.domain", 

you could try to define things like that for each step for the
validation path, saying, "the ca that signs at level 1 must
be validates using cavalidation algorithm 'standard 3280 default
path' (or one of a few of others), and the parameters for algorithm are
'the OCSP server to validate', frequence of validation time?? or others. 

I think one should first try and define a language for ... ooups, SPKI 

Date: Mon, 26 Apr 2004 18:43:46 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: FW: scvp
Sender: [email-masked]

Peter,

>>I am saying that the parameters of validation policies may vary depending 
>>upon the validation policy. Some policies may be simple while some others 
>>quite complex. Some parameters may be fixed and some others may be specified 
>>by the interface (i.e. using the parameters of the validation policy).
> 
> 
> 'may vary' is not sufficiently clear.
>  
> Do you want something like 
> 
>    validationPolicyParameters ANY DEFINED BY theValidationPolicy

Yes.

Denis

Date: Mon, 26 Apr 2004 18:39:56 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: FW: scvp
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> I am saying that the parameters of validation policies may vary depending 
> upon the validation policy. Some policies may be simple while some others 
> quite complex. Some parameters may be fixed and some others may be specified 
> by the interface (i.e. using the parameters of the validation policy).

'may vary' is not sufficiently clear.
 
Do you want something like 

   validationPolicyParameters ANY DEFINED BY theValidationPolicy

Date: Mon, 26 Apr 2004 16:50:49 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: FW: scvp
Sender: [email-masked]

Peter,

Since the first part has been answered in a separate e-mail, I have deleted 
the part that is answered separately.

(text deleted)

>>Ooops ! This is a typo. I meant: The parameters for a given *validation 
>>policy* should be depended upon the OID of the validation policy.

> that's less clear to me. besides "dependant",  are you talking about a limited
> number of syntaxes defined by some OID, or OIDs indicating some
> parameter set similar as with a CP, or? 

I am saying that the parameters of validation policies may vary depending 
upon the validation policy. Some policies may be simple while some others 
quite complex. Some parameters may be fixed and some others may be specified 
by the interface (i.e. using the parameters of the validation policy).

Denis

Date: Mon, 26 Apr 2004 16:50:07 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>, Russ Housley <[email-masked]>, Tim Polk <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Meaning of CP in a CA certificate
Sender: [email-masked]

Peter,

Since one of your observations triggers a different topic , I change the 
subject of this e-mail and reply to the remaining in a different one.

>>A signatory certificate in Europe may use a specific OID for the CP meaning 
>>"Qualified Certificate".
>>
>>Such CP does not apply to CA certificates.
> 
> But you can put them into a CA.

No. They are not applicable for such a purpose.

>    In an end entity certificate, these policy information terms indicate
>    the policy under which the certificate has been issued and the
>    purposes for which the certificate may be used.  In a CA certificate,
>    these policy information terms limit the set of policies for
>    certification paths which include this certificate. 

> So far, no known texts says that CA certificates can be profiled
> by some policy. It seems that you introducing something new? 

X.509 defines certificate policy as:

"3.3.10  certificate policy: A named set of rules that indicates the 
applicability of a certificate to a particular community and/or class of 
application with common security requirements."

This definition is not restricted to end-entity certificates.

In section 8.1.1. from X.509 the text states:

"All certificates are issued in accordance with a policy, even if the policy 
is neither recorded anywhere nor referenced in the certificate."

This means that a CA certificate may be issued with a certificate policy.

In section 8.1.1. from X.509 the text states later:

"A certification authority may place limitations on the use of its 
certificates, in order to control the risk that it assumes as a result of 
issuing certificates. For instance, it may restrict the community of 
certificate users, the purposes for which they may use its certificates 
and/or the type and extent of damages that it is prepared to make good in 
the event of a failure on its part, or that of its end-entities. These 
matters should be defined in the certificate policy. Additional information, 
to help affected entities understand the provisions of the policy, may be 
included in the certificate policies extension in the form of policy 
qualifiers."

This does NOT mean that limitations are defined by specifying the set of CP 
OIDs which are allowed or nor allowed.

However RFC 3280 states:

    In a CA certificate,
    these policy information terms limit the set of policies for
    certification paths which include this certificate.  When a CA does
    not wish to limit the set of policies for certification paths which
    include this certificate, it MAY assert the special policy anyPolicy,
    with a value of { 2 5 29 32 0 }.

This is quite different from X.509 !

I believe that this is a mis-interpretation from the editors of RFC 3280.

Denis

> Are you saying that for example you are looking for
> "some path that creates Qualified certificates" but only if the
> CA certs are created under a policy indicating "some particular 
> more or less global UN policy concering CAs"' ?
>  
> 
> 
>>>I am not sure that I follow you here.  Can't you always cover different 
>>>certification policies using policy mappings? 
>>
>>No. Policy mappings make mapping in any category.
> 
> I was wrong here, since there is currently no provision to indicate in
> a CA cert something about a policy/
> 
> 
>>Ooops ! This is a typo. I meant: The parameters for a given *validation 
>>policy* should be depended upon the OID of the validation policy.
> 
> 
> that's less clear to me. besides "dependant",  are you talking about a limited
> number of syntaxes defined by some OID, or OIDs indicating some
> parameter set similar as with a CP, or? 
> 
> 

Date: Mon, 26 Apr 2004 15:41:06 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: FW: scvp
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 
> A signatory certificate in Europe may use a specific OID for the CP meaning 
> "Qualified Certificate".
> 
> Such CP does not apply to CA certificates.

But you can put them into a CA.

   In an end entity certificate, these policy information terms indicate
   the policy under which the certificate has been issued and the
   purposes for which the certificate may be used.  In a CA certificate,
   these policy information terms limit the set of policies for
   certification paths which include this certificate. 

So far, no known texts says that CA certificates can be profiled
by some policy. It seems that you introducing something new? 

Are you saying that for example you are looking for
"some path that creates Qualified certificates" but only if the
CA certs are created under a policy indicating "some particular 
more or less global UN policy concering CAs"' ?

> > I am not sure that I follow you here.  Can't you always cover different 
> > certification policies using policy mappings? 
> 
> No. Policy mappings make mapping in any category.
I was wrong here, since there is currently no provision to indicate in
a CA cert something about a policy/

> 
> Ooops ! This is a typo. I meant: The parameters for a given *validation 
> policy* should be depended upon the OID of the validation policy.

that's less clear to me. besides "dependant",  are you talking about a limited
number of syntaxes defined by some OID, or OIDs indicating some
parameter set similar as with a CP, or? 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cross certificate format
Date: Mon, 26 Apr 2004 08:51:18 -0400
Importance: Normal
Sender: [email-masked]

Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Cross certificate format

        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 
it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 
by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 
with the KeyUsage extension present, it is only a valid issuer certificate 
if keyCertSign is set.

        Tom Gindin

Jean-Marc Desperrier <[email-masked]>
Sent by: [email-masked]
04/21/2004 03:42 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Cross certificate format

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed 
> certificates,

>which contain no extensions at all (see the text of RFC 3280's
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.

Date: Mon, 26 Apr 2004 14:38:13 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: FW: scvp
Sender: [email-masked]

Peter,

>>Your question makes sense. The default validation algorithm is too simple 
>>and does not make any difference bewteen the CP appropriate for the 
>>end-entity certificate (i.e. endEntityCertificationPolicy) and the CP 
>>appropriate for the CA certificates (i.e. caCertificationPolicies).
> 
> Where do you need such a difference?

A signatory certificate in Europe may use a specific OID for the CP meaning 
"Qualified Certificate".

Such CP does not apply to CA certificates.

>>So these two parameters make one only for the default validation policy. It 
>>however obvious that more elaborate validation policies would be able to 
>>make the difference.
> 
> 
> I am not sure that I follow you here.  Can't you always cover different 
> certification policies using policy mappings? 

No. Policy mappings make mapping in any category.

>>This raises me an observation. The parameters for a given CP should be 
>>depended upon the OID of the validation policy.

> What parameters of a given CP? Addresses of a validation service, url for
> cert lookup?  

Ooops ! This is a typo. I meant: The parameters for a given *validation 
policy* should be depended upon the OID of the validation policy.

>>This means that a better (and much simpler) structure would be:
>>
>>Query ::= SEQUENCE {
>>         queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>         checks                  CertChecks,
>>         wantBack                WantBack,
>>         requestRefHash          BOOLEAN DEFAULT TRUE,
>>         serverContextInfo       OCTET STRING OPTIONAL,
>>         validityTime            GeneralizedTime OPTIONAL,
>>         includePolResponse      BOOLEAN DEFAULT FALSE,
>>         valPolicy               ValidationPolicy,
>>         intermediateCerts   [0] CertBundle OPTIONAL,
>>         revInfos            [1] RevocationInfos OPTIONAL,
>>         queryExtensions     [2] Extensions OPTIONAL }
>>
>>with:
>>
>>    ValidationPolicy  ::=  SEQUENCE  {
>>         algorithm               OBJECT IDENTIFIER,
>>         parameters              ANY DEFINED BY algorithm OPTIONAL  }
>>
>>Then the parameters of the default validation policy should be defined.
> 
> 
> Why is the following an independant booloan and not a WantBack?
>           includePolResponse      BOOLEAN DEFAULT FALSE.
> 
> Why are intermediate certs  and revocationInformation independant
> of the validation policy but trustanchors are not? 

intermediate certs and revocationInformation is just "useful" information 
that may be used or discarded.

Denis

Date: Mon, 26 Apr 2004 14:19:02 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: FW: scvp
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 
> Your question makes sense. The default validation algorithm is too simple 
> and does not make any difference bewteen the CP appropriate for the 
> end-entity certificate (i.e. endEntityCertificationPolicy) and the CP 
> appropriate for the CA certificates (i.e. caCertificationPolicies).
Where do you need such a difference?
> 
> So these two parameters make one only for the default validation policy. It 
> however obvious that more elaborate validation policies would be able to 
> make the difference.

I am not sure that I follow you here.  Can't you always cover different 
certification policies using policy mappings? 

> This raises me an observation. The parameters for a given CP should be 
> depended upon the OID of the validation policy.

What parameters of a given CP? Addresses of a validation service, url for
cert lookup?  

> 
> This means that a better (and much simpler) structure would be:
> 
> Query ::= SEQUENCE {
>          queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>          checks                  CertChecks,
>          wantBack                WantBack,
>          requestRefHash          BOOLEAN DEFAULT TRUE,
>          serverContextInfo       OCTET STRING OPTIONAL,
>          validityTime            GeneralizedTime OPTIONAL,
>          includePolResponse      BOOLEAN DEFAULT FALSE,
>          valPolicy               ValidationPolicy,
>          intermediateCerts   [0] CertBundle OPTIONAL,
>          revInfos            [1] RevocationInfos OPTIONAL,
>          queryExtensions     [2] Extensions OPTIONAL }
> 
> with:
> 
>     ValidationPolicy  ::=  SEQUENCE  {
>          algorithm               OBJECT IDENTIFIER,
>          parameters              ANY DEFINED BY algorithm OPTIONAL  }
> 
> Then the parameters of the default validation policy should be defined.

Why is the following an independant booloan and not a WantBack?
          includePolResponse      BOOLEAN DEFAULT FALSE.

Why are intermediate certs  and revocationInformation independant
of the validation policy but trustanchors are not? 

Date: Mon, 26 Apr 2004 13:48:02 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: FW: scvp
Sender: [email-masked]

Peter,

> what is the meaninng of 
> 
>   endEntityCertificationPolicy  vs caCertificationPolicies

Your question makes sense. The default validation algorithm is too simple 
and does not make any difference bewteen the CP appropriate for the 
end-entity certificate (i.e. endEntityCertificationPolicy) and the CP 
appropriate for the CA certificates (i.e. caCertificationPolicies).

So these two parameters make one only for the default validation policy. It 
however obvious that more elaborate validation policies would be able to 
make the difference.

This raises me an observation. The parameters for a given CP should be 
depended upon the OID of the validation policy.

This means that a better (and much simpler) structure would be:

Query ::= SEQUENCE {
         queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
         checks                  CertChecks,
         wantBack                WantBack,
         requestRefHash          BOOLEAN DEFAULT TRUE,
         serverContextInfo       OCTET STRING OPTIONAL,
         validityTime            GeneralizedTime OPTIONAL,
         includePolResponse      BOOLEAN DEFAULT FALSE,
         valPolicy               ValidationPolicy,
         intermediateCerts   [0] CertBundle OPTIONAL,
         revInfos            [1] RevocationInfos OPTIONAL,
         queryExtensions     [2] Extensions OPTIONAL }

with:

    ValidationPolicy  ::=  SEQUENCE  {
         algorithm               OBJECT IDENTIFIER,
         parameters              ANY DEFINED BY algorithm OPTIONAL  }

Then the parameters of the default validation policy should be defined.

Thanks for the observation.

Denis

> (without nitpicking that both are SEQUENCE). 
> 
> 
>>    ParamsDefValPolicy :: = SEQUENCE {
>>        trustAnchors                  TrustAnchors,
>>        endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
>>        inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>>        caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER OPTIONAL }
>>
> 
> 
> I may be able to understand that in order to to 3280 path validation, one
> has to provide the seven input parameters in some way. Aren't some flags indicating 
>   
>    require Explicit Policy
>    ignore Any Policy
> 
> missing? 
> 
> 

Date: Mon, 26 Apr 2004 13:27:31 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: FW: scvp
Cc: [email-masked], [email-masked]
Sender: [email-masked]

what is the meaninng of 

  endEntityCertificationPolicy  vs caCertificationPolicies

(without nitpicking that both are SEQUENCE). 

>     ParamsDefValPolicy :: = SEQUENCE {
>         trustAnchors                  TrustAnchors,
>         endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
>         inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>         caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER OPTIONAL }
> 

I may be able to understand that in order to to 3280 path validation, one
has to provide the seven input parameters in some way. Aren't some flags indicating 
  
   require Explicit Policy
   ignore Any Policy

missing? 

Date: Mon, 26 Apr 2004 10:09:09 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: FW: scvp
Sender: [email-masked]

Peter and Trevor,

I have major problems too.

> in version 13 the syntax for a Query has been changed from
> 
>    Query ::= SEQUENCE { 
>        queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>        checks                CertChecks, 
>        wantBack              WantBack, 
>        serverContextInfo [0] OCTET STRING OPTIONAL, 
>        valPolicy         [1] ValidationPolicy OPTIONAL, 
>        validityTime      [2] GeneralizedTime OPTIONAL, 
>        trustAnchors      [3] TrustAnchors OPTIONAL, 
>        intermediateCerts [4] CertBundle OPTIONAL, 
>        revInfos          [5] RevocationInfos OPTIONAL, 
>        queryExtensions   [6] Extensions OPTIONAL } 

In this structure trustAnchors was more or less an alternative to valPolicy.

In fact, IF the valPolicy is the default policy, THEN additional parameters 
MUST be provided. So the structure below does not fit as well.

This leads to have the two following elements:

     valPolicy               ValidationPolicy,
     paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,

where the first one is mandatory and the second one optional.

> to  
> 
>     Query ::= SEQUENCE { 
>       queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference, 
>       checks                  CertChecks, 
>       wantBack                WantBack, 
>       requestRefHash          BOOLEAN DEFAULT TRUE, 
>       includePolResponce      BOOLEAN DEFAULT FALSE, 
>       inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>       requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>       ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>       valAlgorithm            ValidationAlgorithm, 
>       serverContextInfo   [0] OCTET STRING OPTIONAL, 
>       validityTime        [1] GeneralizedTime OPTIONAL, 
>       trustAnchors        [2] TrustAnchors OPTIONAL, 
>       intermediateCerts   [3] CertBundle OPTIONAL, 
>       revInfos            [4] RevocationInfos OPTIONAL, 
>       queryExtensions     [5] Extensions OPTIONAL } 

I would thus propose to have something like:

Query ::= SEQUENCE {
         queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
         checks                  CertChecks,
         wantBack                WantBack,
         requestRefHash          BOOLEAN DEFAULT TRUE,
         serverContextInfo       OCTET STRING OPTIONAL,
         validityTime            GeneralizedTime OPTIONAL,
         includePolResponse      BOOLEAN DEFAULT FALSE,
         valPolicy               ValidationPolicy,
         paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
         intermediateCerts   [1] CertBundle OPTIONAL,
         revInfos            [2] RevocationInfos OPTIONAL,
         queryExtensions     [3] Extensions OPTIONAL }

and then something like:

    ParamsDefValPolicy :: = SEQUENCE {
        trustAnchors                  TrustAnchors,
        endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
        inhibitPolMap                 BOOLEAN DEFAULT FALSE,
        caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER OPTIONAL }

Denis

> I am not sure whether I am the only person unable to construct a parser.
> 
> in version 14 an aditional flag has been added which is not available in the
> Chapter 9. Is the isCA flag an orthogonal attribut to other validation
> algorithms, or just to some of them, e.g,. the default name matching one? 
> 
>  
>     Query ::= SEQUENCE { 
>       queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference, 
>       checks                  CertChecks, 
>       wantBack                WantBack, 
>       requestRefHash          BOOLEAN DEFAULT TRUE, 
>       includePolResponce      BOOLEAN DEFAULT FALSE, 
>       inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>       requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>       ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>       isCA                    BOOLEAN DEFAULT FALSE, 
>       valAlgorithm            ValidationAlgorithm, 
>       serverContextInfo   [0] OCTET STRING OPTIONAL, 
>       validityTime        [1] GeneralizedTime OPTIONAL, 
>       trustAnchors        [2] TrustAnchors OPTIONAL, 
>       intermediateCerts   [3] CertBundle OPTIONAL, 
>       revInfos            [4] RevocationInfos OPTIONAL, 
>       keyUsage            [5] KeyUsage OPTIONAL, 
>       extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>       queryExtensions     [7] Extensions OPTIONAL  
>       producedAt          [8] GeneralizedTime OPTIONAL} 
> 
> 

To: Jean-Marc Desperrier <[email-masked]>
Cc: [email-masked]
Subject: Re: Cross certificate format
From: Tom Gindin <[email-masked]>
Date: Sun, 25 Apr 2004 19:05:35 -0400
Sender: [email-masked]

        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 
it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 
by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 
with the KeyUsage extension present, it is only a valid issuer certificate 
if keyCertSign is set.

        Tom Gindin

Jean-Marc Desperrier <[email-masked]>
Sent by: [email-masked]
04/21/2004 03:42 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Cross certificate format

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed certificates, 

>which contain no extensions at all (see the text of RFC 3280's 
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.

Date: Fri, 23 Apr 2004 16:18:24 -0400
From: [email-masked]
To: Steven Bellovin <[email-masked]>, Russell Housley <[email-masked]>
Cc: [email-masked], Stephen Kent <[email-masked]>
Subject: Forwarding SHA-224 to ADs
Sender: [email-masked]

This message closes working group last call for "A 224-bit One-way Hash 
Function: SHA-224".  I have reviewed the comments on the list since 26 March 
(when Last Call was initiated.)  No technical issues are unresolved, so I am 
forwarding the document to the ADs for progression to RFC status.  As 
suggested by the authors, we are requesting Informational Track for this 
specification. This document is currently available at 

   http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha224-01.txt.

This specification will provide a stable reference for the SHA-224 
algorithm, which is needed by several IETF specifications.  At least two 
independent implementations exist and agree on the test vectors in this 
document.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certstore-http-06.txt
Date: Fri, 23 Apr 2004 15:36:44 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-pkix-certstore-http-06.txt
	Pages		: 0
	Date		: 2004-4-23
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories.  Additional mechanisms addressing PKIX operational requirements are specified in separate documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-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-certstore-http-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-certstore-http-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-certstore-http-06.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 23 Apr 2004 20:18:35 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: FW: scvp
Cc: [email-masked]
Sender: [email-masked]

in version 13 the syntax for a Query has been changed from

   Query ::= SEQUENCE { 
       queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
       checks                CertChecks, 
       wantBack              WantBack, 
       serverContextInfo [0] OCTET STRING OPTIONAL, 
       valPolicy         [1] ValidationPolicy OPTIONAL, 
       validityTime      [2] GeneralizedTime OPTIONAL, 
       trustAnchors      [3] TrustAnchors OPTIONAL, 
       intermediateCerts [4] CertBundle OPTIONAL, 
       revInfos          [5] RevocationInfos OPTIONAL, 
       queryExtensions   [6] Extensions OPTIONAL } 
    
to  

    Query ::= SEQUENCE { 
      queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference, 
      checks                  CertChecks, 
      wantBack                WantBack, 
      requestRefHash          BOOLEAN DEFAULT TRUE, 
      includePolResponce      BOOLEAN DEFAULT FALSE, 
      inhibitPolMap           BOOLEAN DEFAULT FALSE, 
      requireExplicitPol      BOOLEAN DEFAULT FALSE, 
      ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
      valAlgorithm            ValidationAlgorithm, 
      serverContextInfo   [0] OCTET STRING OPTIONAL, 
      validityTime        [1] GeneralizedTime OPTIONAL, 
      trustAnchors        [2] TrustAnchors OPTIONAL, 
      intermediateCerts   [3] CertBundle OPTIONAL, 
      revInfos            [4] RevocationInfos OPTIONAL, 
      queryExtensions     [5] Extensions OPTIONAL } 

I am not sure whether I am the only person unable to construct a parser.

in version 14 an aditional flag has been added which is not available in the
Chapter 9. Is the isCA flag an orthogonal attribut to other validation
algorithms, or just to some of them, e.g,. the default name matching one? 

    Query ::= SEQUENCE { 
      queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference, 
      checks                  CertChecks, 
      wantBack                WantBack, 
      requestRefHash          BOOLEAN DEFAULT TRUE, 
      includePolResponce      BOOLEAN DEFAULT FALSE, 
      inhibitPolMap           BOOLEAN DEFAULT FALSE, 
      requireExplicitPol      BOOLEAN DEFAULT FALSE, 
      ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
      isCA                    BOOLEAN DEFAULT FALSE, 
      valAlgorithm            ValidationAlgorithm, 
      serverContextInfo   [0] OCTET STRING OPTIONAL, 
      validityTime        [1] GeneralizedTime OPTIONAL, 
      trustAnchors        [2] TrustAnchors OPTIONAL, 
      intermediateCerts   [3] CertBundle OPTIONAL, 
      revInfos            [4] RevocationInfos OPTIONAL, 
      keyUsage            [5] KeyUsage OPTIONAL, 
      extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
      queryExtensions     [7] Extensions OPTIONAL  
      producedAt          [8] GeneralizedTime OPTIONAL} 

From: "Jaleel P.A" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cross certificate format
Date: Fri, 23 Apr 2004 20:53:07 +0530
Sender: [email-masked]

Hi

Can anybody attach a sample cross certificate.

Thanks 
Jaleel 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Wednesday, April 21, 2004 9:55 PM
To: Jaleel P.A
Cc: [email-masked]
Subject: Re: Cross certificate format

        Jaleel:

        As several of the earlier responses have pointed out, cross 
certificates are just those CA certificates whose issuer and subject are 
different.  CA certificates (except v1 self-signed certificates) are 
slightly different from non-CA certificates in the following ways:
a)      The basic constraints extension is present and has the "CA" flag 
set.
b)      The key usage extension is present and has the keyCertSign bit 
set, and often the cRLSign bit as well.
        There are other, less common, extensions which are typically found 
in CA certificates and not in others.  These include Name Constraints, 
Policy Constraints, Policy Mappings, and Inhibit Any-Policy.
        RFC 3280 does not support the use of v1 self-signed certificates, 
which contain no extensions at all (see the text of RFC 3280's 
basicConstraints section).  However, a number of public CA's still have 
them.

                Tom Gindin

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

From: Santoni Adriano <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Fri, 23 Apr 2004 09:54:19 +0200
Sender: [email-masked]

A rule that is "at odds with reality" should not be expressed in terms of
MUST, but rather in terms of SHOULD. I wonder how it came that RFC 3280
reached the status of an official IETF standard, if it contains one or more
areas that are "at odds with reality". 

I suppose the answer is one of these:
- RFC 3280 does not really contain areas that are "at odds with reality" -
it's just that we do not understand them;
- containing areas that are "at odds with reality" is not an obstacle to
becoming a standard;
- expressions like "MUST" in IETF standard are really to be taken as mere
suggestions;
- nobody really cares.

Adriano

-----Messaggio originale-----
Da: pgut001 [mailto:[email-masked]] Per conto di
[email-masked]
Inviato: venerd� 23 aprile 2004 4.33
A: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Oggetto: Re: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs

Santoni Adriano <[email-masked]> writes:

>If the answer is YES, I would like your personal opinion about the 
>great majority (sai 99,9%) of all CAs all over the planet not being 
>conformant to RFC 3280 and neither to RFC 2459, as far as this 
>particular PKIX prescription is concerned.

Here we go again... this really should be an FAQ, given the number of times
it's come up, and will no doubt continue to come up.  So the standard answer
is:

  Most people are ignoring the UTF-8 requirement because of backwards-
  compatibility concerns, both for existing certs and for existing
  applications.  Don't worry about it, it's quite normal, this is just
another
  area where the RFC is at odds with reality.

Peter.

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

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Status of draft-ietf-pkix-certstore-http?
Date: Fri, 23 Apr 2004 15:40:12 +1200
Sender: [email-masked]

Jack Lloyd <[email-masked]> writes:

>Is there a public server anywhere I can hit with requests?  Or, better, a
>server implementation I can run locally with various strange test certs?

Not that I know of.  There are several implementations, but I don't know if
any of their users would want them being hit with arbitrary requests from the
net, or if they're even visible on the net.  OTOH doing an implementation
using (say) a web-enabled database takes almost no time, there's a MySQL-
based one that was supposedly done in about 30 minutes, it's just a case of
mapping the portions of an incoming URI to a "SELECT FROM certificates WHERE
$URI_key_portion = $URI_value_portion", for various values of
$URI_key_portion.  I did a (fairly minimal) C one in about 2 pages of code
(this is based on a much older version of the spec which does multiple-cert
responses as a PKCS #7 cert chain rather than a multipart response, among
other things), and there's a JDBC one as well... I'll see if I can get the
code for that publicised. Actually since the person who wrote it reads this
list: Any chance of posting the code?

It also depends on what you want to test, if all you want to check is the
ability to grab certs via HTTP, you can just put some certs at a fixed
location on a web server, since the client can't tell the difference between
static and dynamic content.  That's how I first tested the client-side code
years ago.

Send me private mail if you want the implementation I did.  Generally it'd be
publicly available, but I've been re-doing some unrelated portions of the code
recently and it's not really fit to be released yet.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Cc: [email-masked]
Date: Fri, 23 Apr 2004 14:33:29 +1200
Sender: [email-masked]

Santoni Adriano <[email-masked]> writes:

>If the answer is YES, I would like your personal opinion about the great
>majority (sai 99,9%) of all CAs all over the planet not being conformant to
>RFC 3280 and neither to RFC 2459, as far as this particular PKIX prescription
>is concerned.

Here we go again... this really should be an FAQ, given the number of times
it's come up, and will no doubt continue to come up.  So the standard answer
is:

  Most people are ignoring the UTF-8 requirement because of backwards-
  compatibility concerns, both for existing certs and for existing
  applications.  Don't worry about it, it's quite normal, this is just another
  area where the RFC is at odds with reality.

Peter.

Date: Thu, 22 Apr 2004 15:37:42 -0700
From: Ed Gerck <[email-masked]>
To: PKIX <[email-masked]>
Subject: Re: new -- Clarification Note proposal on cert revocation       -
Sender: [email-masked]

Dave,

Clearly, an RP can rely on (trust) any source for revocation 
information of a cert issued by a CA. 

Still, this does not mean that the revocation status of a cert 
is defined by that RP or by conditions authoritatively defined by 
that RP. That revocation status is defined by conditions set forth
authoritatively by the issuer CA, whether that RP agrees with them 
or not, whether that RP reads them or not. Here, a tree falls even 
though no one may watch it fall.

Moreover, when an RP decides to rely on any source for revocation
information and something goes wrong (e.g., that cert turns out to 
have been listed as revoked by a CRL issuer identified in the 
certificate, or by the issuer CA), will the RP be able to claim 
to anyone that it relied on the cert based on anything else but 
the RP's own risk in such a case? No. The RP has 100% of the risk
if the RP has not followed the conditions defined by the issuer
CA to learn the revocation status of a cert issued by that CA.

Further, what good or harm has X.509 done in such a case? Nothing,
either way. There is no violation of X.509 -- if an RP decides to 
be on its own and blindly ignores the conditions for reliance defined
in X.509 in terms of revocation conditions and where to find them, 
that RP was and is on its own -- proof by construction.

The matter is different in terms of validation vs. revocation.
An RP is always authoritative for validation of a certificate.
And also has 100% of the risk. The RP cannot rely on the issuer
CA to define the validation status of a cert, which is a matter
of local policy.

Finally, in the context of an organization, will the organization
allow each employee to decide what source to rely on for revocation 
information of a cert issued by a CA? Probably not, for the reasons
noted above. The organization will want to enforce the restrictions
on cert reliance placed by the issuer CA (including when a cert is 
revoked or not) in addition to their own restrictions on validation
of that cert (e.g., the path used to verify the revocation information).

Cheers,
Ed Gerck

"David P. Kemp" wrote:
> 
> A relying party is obviously authoritative for the sources of
> information that that relying party trusts.  This cannot be
> disputed - proof by construction.
> 
> If an RP says a CA is the only authoritative source of revocation
> information for that CA's certs, then it is (for that RP).  If
> a different RP trusts some other source, then the CA is not
> authoritative.
> 
> PKIX can only seek to put in place standards capable of
> faithfully and securely mechanizing RP trust policies without
> introducing unrecognized or difficult to foresee violations
> of those policies (i.e., vulnerabilities).
> 
> PKIX does not attempt to tell you, or Santosh, what to believe.
> 
> Ed Gerck wrote:
> 
> > Santosh,
> >
> > You do not believe that CAs are authoritative for revocation
> > conditions.

From: "Santosh Chokhani" <[email-masked]>
To: "'PKIX'" <[email-masked]>
Subject: RE: new -- Clarification Note proposal on cert revocation          -
Date: Thu, 22 Apr 2004 12:44:27 -0400
Importance: Normal
Sender: [email-masked]

Dave:

I agree with you.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David P. Kemp
Sent: Thursday, April 22, 2004 8:46 AM
To: PKIX
Subject: Re: new -- Clarification Note proposal on cert revocation -

A relying party is obviously authoritative for the sources of information
that that relying party trusts.  This cannot be disputed - proof by
construction.

If an RP says a CA is the only authoritative source of revocation
information for that CA's certs, then it is (for that RP).  If a different
RP trusts some other source, then the CA is not authoritative.

PKIX can only seek to put in place standards capable of faithfully and
securely mechanizing RP trust policies without introducing unrecognized or
difficult to foresee violations of those policies (i.e., vulnerabilities).

PKIX does not attempt to tell you, or Santosh, what to believe.

Ed Gerck wrote:

> Santosh,
> 
> You do not believe that CAs are authoritative for revocation
> conditions.

Date: Thu, 22 Apr 2004 11:21:06 -0400
To: Steve Hanna <[email-masked]>, [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: Successor to RFC 3280?
Cc: Stephen Kent <[email-masked]>, [email-masked]
Sender: [email-masked]

Steve,

I believe we have WG consensus that a successor to 3280 is an appropriate 
work item.  In light of the controlled shutdown of PKIX is, I believe the 
scope must be limited to the task of progressing to Draft Status.  That 
means we will need to remove those features that do not have two 
implementations, and clarify any errors and inconsistencies.  Any other 
work needs to be performed in separate documents (and probably needs to 
progress as a personal draft.)

I am volunteering David Cooper from NIST to act as lead editor for the 
successor to 3280.  He was a key contributor, particularly with respect to 
the path validation algorithm, in the development of 3280 itself and has 
been a key player in the interoperability testing.

In addition, David participated in the revisions to the ISO specification 
which leaves us well positioned to maintain the consistency of the ISO and 
IETF documents.

Thanks,

Tim Polk

Date: Thu, 22 Apr 2004 08:46:08 -0400
From: "David P. Kemp" <[email-masked]>
To: PKIX <[email-masked]>
Subject: Re: new -- Clarification Note proposal on cert revocation        -
Sender: [email-masked]

A relying party is obviously authoritative for the sources of
information that that relying party trusts.  This cannot be
disputed - proof by construction.

If an RP says a CA is the only authoritative source of revocation
information for that CA's certs, then it is (for that RP).  If
a different RP trusts some other source, then the CA is not
authoritative.

PKIX can only seek to put in place standards capable of
faithfully and securely mechanizing RP trust policies without
introducing unrecognized or difficult to foresee violations
of those policies (i.e., vulnerabilities).

PKIX does not attempt to tell you, or Santosh, what to believe.

Ed Gerck wrote:

> Santosh,
> 
> You do not believe that CAs are authoritative for revocation 
> conditions.

Date: Wed, 21 Apr 2004 21:49:16 -0700
From: Ed Gerck <[email-masked]>
To: PKIX <[email-masked]>
Subject: Re: new -- Clarification Note proposal on cert revocation          -
Sender: [email-masked]

Santosh,

You do not believe that CAs are authoritative for revocation 
conditions. You also think that there is no mechanism to limit 
the time of delegation; no way for revoking the delegation. Yet, 
an issuer CA can revoke the signing cert, hence revoking the 
revocation delegation for all certs signed by that cert.

By ignoring the authoritative role of CAs in revocation conditions, 
you will not improve the authoritative role of CRL issuers, however. 
You will not make the role of OCSP responders clearer, either. You 
will just create more confusion on revocation delegation, making the 
position of an issuer CA even stronger (why should you get revocation 
from a delegate if you can get the real thing without pesky questions?).

The bottom line of what I'm saying is that revocation in PKIX is not 
as bad as "flip a coin to know if this cert is revoked" (as it may 
seem) but can be understood and verified by a relying party, to the
extent the RP desires. As I showed, the only limitation is how much 
time and work the RP is willing to spend, not the result. The result 
is ultimately unambiguous and verifiable.

X.509 is not perfect. But we shall not demand perfection. Pointing 
out that PKIX cert revocation is ultimately unambiguous for an RP
is, IMO a great clarification -- if this lit's archives and my private 
mailbox can be proof. Yes, it does renovate some notions. However, to 
renovate is not to destroy. It is to respect the foundations, and so 
restore works for the general good.

Thanks again. 

Cheers,
Ed Gerck

Date: Wed, 21 Apr 2004 21:42:44 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Cross certificate format
Sender: [email-masked]

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed certificates, 
>which contain no extensions at all (see the text of RFC 3280's 
>basicConstraints section).  However, a number of public CA's still have 
>them.
>  
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.

Date: Wed, 21 Apr 2004 19:47:09 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: FW: scvp
Cc: [email-masked]
Sender: [email-masked]

> 
> Reposting at Peters request
Thanks

> From: Trevor Freeman 
> Sent: Tuesday, April 13, 2004 11:25 AM
> To: 'Peter Sylvester'; [email-masked]
> Subject: RE: scvp
> 
> Hi Peter,
> Respnces below.
> 
> The change to 3.4 permits a SCVP server to return a cached response in
> which case it cannot include any request specific values. A client could
> require a non-cached repsoce in which case this value must be present.
> 
> There is no requiremnt today that SCVP client must have a name in the
> genral name space. They can simply use soemthing generated localy and
> use that which seems a big plus. 

There are least one server and all its clients involved which must
agree  on the identifications. Furthermore, the identifications
are also used by other relying parties. this means that all 
participating entities need to have a comon understanding
of an identification. What is the big plus of having an untyped opaque
identifier without any possibility for structuring, this
seems to me that the requirement 

       Mechanisms for matching this identifier with the
  >    authenticated identity depends on local DPV server conditions and/or
  >    the validation policy.

seems unnecessarily difficult in this case. What is the real benefit
over GeneralName. I wonder how one can implement a general solution
in a product without specific code or an " identifier to authenticated identity
mapping function" specifiable dynamically. On the other hand, using
generalName allows to have a simple local definition (identifier must be one
of the identifiers in the authenticated indentity); 
furthermore identifiers are not just for loop control, but supposed to
be displayed or otherwise shown to some user. of course,
one can always show a hexadecimal representation of the identifier
but again, the same difficulty to map this identification of the 
'requester' (not the request) to any of the authenticated entity
remains.   

Well, on can always recomment to encode a generalname in the
octet string ... oops, that doesn't work, either.

                                   If the request or repnoce is signed
> then you get a name in the certifcate.

You can have more than one identification in a certificate using
subject alternatename extension. 

> 
> The octet string vs. oid with any was a arbitary chioce since boht
> chiver the same end. 

Does this refer to 4.8.5?

The question is why is it necessary to use all different
known techniques in this text in a arbitrary choice, at some places
it is any defined by at others it is an octet string encapsulating
a structure, and to invent at least one new opaque.
(ValidationAalg, replywantback, 'identifiers' in requestor, responder, etc)

The argument of encapsulation of some structure in an octet string 
comes from the fact that some encoders/decoders cannot treat correctly
'any defined by' with unknown oids. If one wants to support them then 
there should be no any defined by at all. Or, if the number of types
syntaxes is small and stable, then an additional encapsulation is not
necessary. Another potential reason is that the encapsulated
type cannot easly be encode with DER, well, saying 'The octet string
contains a boolean type' is not ok, I may have overlooked if it is
excluded to have a XER encoding of an ASN.1 type.   

There is a confusion between "ValidationAlg" and  "ValidationAlgorithm"

I have no asnwer to the last question.
As far as I remember there is nowhere a place to have a contentinfo,
i.e. an SCVP response as part of the response. 

> On Behalf Of Peter Sylvester
> Sent: Tuesday, April 13, 2004 3:56 AM
> To: [email-masked]
> Subject: scvp
> 
> 
> 
> 
> SCVP 14:
>  3.4 Requestor 
>    
>   The OPTIONAL requestor item is a reference local to the requestor. 
>   The value is only of local significance to the requestor.  If the 
>   SCVP client includes a requestor value in the request, then the 
>   SCVP server MUST return the same value in a unique SCVP response. 
>   The SCVP server MAY omit the requestor value from cached SCVP 
>   responses. 
> 
> SCVP 13: 
> 
>   The OPTIONAL requestor item is a reference local to the requestor. 
>   The value is only of local significance to the requestor.  If the 
>   SCVP client includes a requestor value in the request, then the 
>   SCVP server MUST return the same value in the response. 
> 
> As far as I remember, there was no discussion about this. 
> 
> I think that the following sentence of 4.6 does not respect the
> requirements. 
> 
>  4.6 Requestor 
>    
>   The OPTIONAL requestor item is used to identify the requestor.  The 
>   value is only of local significance to the requestor. 
> 
> requirements say:
> 
>    When the DPV request is authenticated, the client SHOULD be able to
>    include a client identifier in the request for the DPV server to copy
>    into the response.  Mechanisms for matching this identifier with the
>    authenticated identity depends on local DPV server conditions and/or
>    the validation policy.  The DPV server MAY choose to blindly copy the
>    identifier, omit the identifier, or return an error response.
> 
> IMO this clearly indicates that the identifier has a meaning for the
> server.
> 
> 
> Unless I have overlooked something, I have not seen any response
> to the following.  Maybe the content of my message considered
> as pure nonsense.
> 
> 
> Date: Tue Oct 28 18:43:58 2003
> To: [email-masked], [email-masked], [email-masked]
> Subject: RE: SCVP additions
> 
> hello,
> 
> It would be nice to hear whether all or which comments
> about SCVP have been addressed. Unless I have overlooked
> something, my remarks about the definitions of requestor
> and responder have not received any treatment. 
> 
> I simplify the content of my comments:
> 
> requestor and responder should be GENERALNAMES which
> indicate and identify in global the partipating parties.  
> 
> IMO Using arbitrary octets with only LOCAL significance
> is not compatible with the procedure to detect loops.
> 
> 4.6 indicates the there MUST NOt be null characters,
> something which is explicitly allowed for a server
> acting as a relay.
> 
> What is the sense of 4.7? The responder field is
> never used anywhere in the actual protocol, what
> is the meaning of such an opaque value?
> 
> 
> 4.8.5 What is the reason of having an additional octet string
> encapsulation instead of an any defined by construct? Is it
> that some tools may break decodeing when they find an OID
> that is not known? If so, whay are there ANY DEFINED BYs at
> other places?
> 
> can someone indicate me how a relay would return the response
> of the next server to a client as part of his response?
> 
> regards
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: new -- Clarification Note proposal on cert revocation          -
Date: Wed, 21 Apr 2004 13:21:42 -0400
Importance: Normal
Sender: [email-masked]

Ed:

There is no particular reason to debate this.  We have gone down this path
and at your request, I have had several private exchanges with you regarding
this.

If you still do not get it, I do not have time to help any further.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ed Gerck
Sent: Wednesday, April 21, 2004 12:00 PM
To: Santosh Chokhani
Cc: 'PKIX'
Subject: Re: new -- Clarification Note proposal on cert revocation -

Santosh Chokhani wrote:
> 
> Ed:
> 
> I do not think 3280 needs any clarification in this area.

With all due respect, I think this reply shows otherwise.
 
> There are several errors in the statements.

Thank you. If you could please name them as you see them, this will also
help the clarification.

> Also, some of the topics are CA and RP policy issues and not 
> certificate and CRL formats issue.

CA and RP policy issues are not described but, again, if you could please
name 
them as you see them, this will also help the clarification.

> Since PKIX is not operating a CA or recommending any operations 
> policy, none of this is needed for any other document either.

On Wed, Apr 07, you wrote: 
"There is no mechanism to limit the time of delegation."

However, as you see in the Clarification Note, this is not true: The issuer 
CA can authoritatively revoke delegation to the CRL issuer. Delegation is
not 
for the life of the cert. A issuer CA could revoke the signing cert and re-
issue all certs with a different delegation specification or no delegation. 
This also provides an incentive for the CRL issuer to conform to the issuer 
CA's policy.

On the same day, you also wrote:
"...and if the Indirect CRL is checked by the relying party, there is no
requirement to check any CRL issued by the issuing CA."

Yes, but that check was not done absolutely, as explained in the Note. 
It depends on whether the issuer CA signing cert is revoked or not, OR
whether any other conforming revocation condition defined by the 
issuer CA applies. Also, as explained in the Note,

 An RP software relying on the revocation status of a certificate specified
by any mechanism, authorized or not by the issuer CA of the certificate, 
 is also subject to conditions defined by the issuer CA. Those conditions 
 may change from time to time. Some mechanisms may not include direct
evidence  of the issuer CA's assertion of a certificate's revocation status
or 
 conditions, at a particular time.

Cheers,
Ed Gerck

Content-class: urn:content-classes:message
Subject: FW: scvp
Date: Wed, 21 Apr 2004 09:39:48 -0700
From: "Trevor Freeman" <[email-masked]>
To: <[email-masked]>
Cc: "Peter Sylvester" <[email-masked]>
Sender: [email-masked]

Reposting at Peters request

-----Original Message-----
From: Trevor Freeman 
Sent: Tuesday, April 13, 2004 11:25 AM
To: 'Peter Sylvester'; [email-masked]
Subject: RE: scvp

Hi Peter,
Respnces below.

The change to 3.4 permits a SCVP server to return a cached response in
which case it cannot include any request specific values. A client could
require a non-cached repsoce in which case this value must be present.

There is no requiremnt today that SCVP client must have a name in the
genral name space. They can simply use soemthing generated localy and
use that which seems a big plus. If the request or repnoce is signed
then you get a name in the certifcate.

The octet string vs. oid with any was a arbitary chioce since boht
chiver the same end. 

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Sylvester
Sent: Tuesday, April 13, 2004 3:56 AM
To: [email-masked]
Subject: scvp

SCVP 14:
 3.4 Requestor 
   
  The OPTIONAL requestor item is a reference local to the requestor. 
  The value is only of local significance to the requestor.  If the 
  SCVP client includes a requestor value in the request, then the 
  SCVP server MUST return the same value in a unique SCVP response. 
  The SCVP server MAY omit the requestor value from cached SCVP 
  responses. 

SCVP 13: 

  The OPTIONAL requestor item is a reference local to the requestor. 
  The value is only of local significance to the requestor.  If the 
  SCVP client includes a requestor value in the request, then the 
  SCVP server MUST return the same value in the response. 

As far as I remember, there was no discussion about this. 

I think that the following sentence of 4.6 does not respect the
requirements. 

 4.6 Requestor 
   
  The OPTIONAL requestor item is used to identify the requestor.  The 
  value is only of local significance to the requestor. 

requirements say:

   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response.  Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy.  The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response.

IMO this clearly indicates that the identifier has a meaning for the
server.

Unless I have overlooked something, I have not seen any response
to the following.  Maybe the content of my message considered
as pure nonsense.

Date: Tue Oct 28 18:43:58 2003
To: [email-masked], [email-masked], [email-masked]
Subject: RE: SCVP additions

hello,

It would be nice to hear whether all or which comments
about SCVP have been addressed. Unless I have overlooked
something, my remarks about the definitions of requestor
and responder have not received any treatment. 

I simplify the content of my comments:

requestor and responder should be GENERALNAMES which
indicate and identify in global the partipating parties.  

IMO Using arbitrary octets with only LOCAL significance
is not compatible with the procedure to detect loops.

4.6 indicates the there MUST NOt be null characters,
something which is explicitly allowed for a server
acting as a relay.

What is the sense of 4.7? The responder field is
never used anywhere in the actual protocol, what
is the meaning of such an opaque value?

4.8.5 What is the reason of having an additional octet string
encapsulation instead of an any defined by construct? Is it
that some tools may break decodeing when they find an OID
that is not known? If so, whay are there ANY DEFINED BYs at
other places?

can someone indicate me how a relay would return the response
of the next server to a client as part of his response?

regards

To: "Jaleel P.A" <[email-masked]>
Cc: [email-masked]
Subject: Re: Cross certificate format
From: Tom Gindin <[email-masked]>
Date: Wed, 21 Apr 2004 12:24:57 -0400
Sender: [email-masked]

        Jaleel:

        As several of the earlier responses have pointed out, cross 
certificates are just those CA certificates whose issuer and subject are 
different.  CA certificates (except v1 self-signed certificates) are 
slightly different from non-CA certificates in the following ways:
a)      The basic constraints extension is present and has the "CA" flag 
set.
b)      The key usage extension is present and has the keyCertSign bit 
set, and often the cRLSign bit as well.
        There are other, less common, extensions which are typically found 
in CA certificates and not in others.  These include Name Constraints, 
Policy Constraints, Policy Mappings, and Inhibit Any-Policy.
        RFC 3280 does not support the use of v1 self-signed certificates, 
which contain no extensions at all (see the text of RFC 3280's 
basicConstraints section).  However, a number of public CA's still have 
them.

                Tom Gindin

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

Date: Wed, 21 Apr 2004 09:00:15 -0700
From: Ed Gerck <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: "'PKIX'" <[email-masked]>
Subject: Re: new -- Clarification Note proposal on cert revocation          -
Sender: [email-masked]

Santosh Chokhani wrote:
> 
> Ed:
> 
> I do not think 3280 needs any clarification in this area.

With all due respect, I think this reply shows otherwise.
 
> There are several errors in the statements.

Thank you. If you could please name them as you see them, this will
also help the clarification.

> Also, some of the topics are CA and RP policy issues and not certificate and
> CRL formats issue.

CA and RP policy issues are not described but, again, if you could please name 
them as you see them, this will also help the clarification.

> Since PKIX is not operating a CA or recommending any operations policy, none
> of this is needed for any other document either.

On Wed, Apr 07, you wrote: 
"There is no mechanism to limit the time of delegation."

However, as you see in the Clarification Note, this is not true: The issuer 
CA can authoritatively revoke delegation to the CRL issuer. Delegation is not 
for the life of the cert. A issuer CA could revoke the signing cert and re-
issue all certs with a different delegation specification or no delegation. 
This also provides an incentive for the CRL issuer to conform to the issuer 
CA's policy.

On the same day, you also wrote:
"...and if the Indirect CRL is checked by the relying party, there is no
requirement to check any CRL issued by the issuing CA."

Yes, but that check was not done absolutely, as explained in the Note. 
It depends on whether the issuer CA signing cert is revoked or not,
OR whether any other conforming revocation condition defined by the 
issuer CA applies. Also, as explained in the Note,

 An RP software relying on the revocation status of a certificate specified
 by any mechanism, authorized or not by the issuer CA of the certificate, 
 is also subject to conditions defined by the issuer CA. Those conditions 
 may change from time to time. Some mechanisms may not include direct evidence
 of the issuer CA's assertion of a certificate's revocation status or 
 conditions, at a particular time.

Cheers,
Ed Gerck

Date: Wed, 21 Apr 2004 10:22:10 -0400
From: Jack Lloyd <[email-masked]>
To: [email-masked]
Subject: Re: Status of draft-ietf-pkix-certstore-http?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Apr 21, 2004 at 12:56:39PM +1200, Peter Gutmann wrote:
> Jack Lloyd <[email-masked]> writes:
> 
> >The last version of this draft I can find is -05, expiring in September 2003.
> >Has this draft been abandoned, or is going to start moving again at some
> >point?
> 
> A number of people have been asking that :-).  The current draft was
> mistakenly deleted from the IETF server, I'll get a new version up within the
> next few days, although I'm not sure what number it'll have because of the
> missing (deleted) copy.  For all intents and purposes it's identical to -05,
> there's just two minor wording changes.

Good to hear. Is there a public server anywhere I can hit with requests?  Or,
better, a server implementation I can run locally with various strange test
certs?

-J

Date: Wed, 21 Apr 2004 15:43:15 +0200 (CEST)
To: [email-masked]
CC: [email-masked]
Subject: Re: Cross certificate format
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Wed, 21 Apr 2004 16:00:37 +0400, Timofey <[email-masked]> said:

timofey> Hello Jaleel,
timofey> 
timofey> JPA> Hi,
timofey> 
timofey> JPA> Can anybody tell me the structure of a Cross Certificate
timofey> JPA> and how it is different from a normal Public Key
timofey> JPA> certificate. A Cross certificate sample can be of great
timofey> JPA> help.
timofey> 
timofey> Cross-certificate has absolutly the same structure as
timofey> "normal" certificate. It looks like one CA signs another.
timofey> 
timofey> The only difference is the place you store it. For example,
timofey> you can place it in LDAP directory as crossCertificatePair
timofey> attribute.

I've always wondered about that, what's the reason to have that placed
separately from other certificates?  To me, that just means I have to
look in yet another place...

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

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Wed, 21 Apr 2004 09:19:22 -0400
From: "David A. Cooper" <[email-masked]>
To: "Jaleel P.A" <[email-masked]>
CC: [email-masked]
Subject: Re: Cross certificate format
Sender: [email-masked]

Jaleel P.A wrote:

>Can anybody tell me the structure of a Cross Certificate and how it is
>different from a normal Public Key certificate. A Cross certificate sample
>can be of great help.
>  
>

Technically, a cross certificate is certificate that has been issued by 
one CA to another CA.

X.509 defines three types of CA certificates:

1) self-issued certificate:  certificate in which the issuer and subject 
are the same CA.

2) self-signed certificate: self-issued certificate in which private key 
used to sign the certificate
   corresponds to the certificate's subject public key.

3) cross certificate: certificate in which the issuer and subject are 
different CAs (i.e., any CA certificate
    that is not a self-issued certificate).

Certificates issued to other CAs may be divided into two types:  (1) a 
certificate issued to a subordinate CA in a hierarchy; and (2) a 
certificate issued to a CA that is a peer (frequently a CA at a 
different organization).  With the second type, it will commonly be the 
case the each CA will issue a certificate to the other one.  Despite the 
"official" definition above, people will sometimes use the term "cross 
certificate" to refer to this second type of CA certificate (i.e., 
certificates issued to CAs in another organization in a peer-to-peer 
manner).  In fact, some believe that cross-certification implies that 
the two peer CAs have each issued the other a certificate.

Note that there is also a directory attribute crossCertificatePair, 
which holds a SEQUENCE of two cross certificates as specified in RFC 2587:

crossCertificatePairATTRIBUTE::={
   WITH SYNTAX   CertificatePair
   EQUALITY MATCHING RULE certificatePairExactMatch
 ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}

CertificatePair ::= SEQUENCE {
	forward		[0]	Certificate OPTIONAL,
	reverse		[1]	Certificate OPTIONAL,
	-- at least one of the pair shall be present -- }

Date: Wed, 21 Apr 2004 16:00:37 +0400
From: Timofey <[email-masked]>
Reply-To: Timofey <[email-masked]>
To: [email-masked]
Subject: Re: Cross certificate format
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Hello Jaleel,

JPA> Hi,

JPA> Can anybody tell me the structure of a Cross Certificate and how it is
JPA> different from a normal Public Key certificate. A Cross certificate sa=
mple
JPA> can be of great help.

Cross-certificate has absolutly the same structure as "normal"
certificate. It looks like one CA signs another.

The only difference is the place you store it. For example, you can
place it in LDAP directory as crossCertificatePair attribute.

--=20
Best regards,
 Timofey                           =20

------------7A15B2B26FB9D77
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

------------7A15B2B26FB9D77--

From: "Jaleel P.A" <[email-masked]>
To: <[email-masked]>
Subject:  Cross certificate format
Date: Wed, 21 Apr 2004 15:51:12 +0530
Sender: [email-masked]

Hi,

Can anybody tell me the structure of a Cross Certificate and how it is
different from a normal Public Key certificate. A Cross certificate sample
can be of great help.

Thanks
Jaleel

From: "Jaleel P.A" <[email-masked]>
To: <[email-masked]>
Subject: Cross certificate format
Date: Wed, 21 Apr 2004 15:50:06 +0530
Sender: [email-masked]

Hi,

Can anybody tell me the structure of a Cross Certificate and how it is
different from a normal Public Key certificate. A Cross certificate sample
can be of great help.

Thanks
Jaleel

From: Santoni Adriano <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Wed, 21 Apr 2004 12:12:37 +0200
Sender: [email-masked]

Dear RFC3280 Authors,

Sorry for bothering, and please forgive me if I am asking an old question.

RFC 3280 reads (�4.1.2.4): "...all certificates issued after December 31,
2003 MUST use the UTF8String encoding of DirectoryString...".

Is that sentence meant to be intepreted in the following way?  :

"All RDNs (having a DirectoryString syntax) of the issuer and subject
certificate fields, in all certificates issued after December 31, 2003, MUST
be encoded as UTF8Strings EVEN if they could be correctly encoded as a
PrintableStrings."

If the answer is YES, I would like your personal opinion about the great
majority (sai 99,9%) of all CAs all over the planet not being conformant to
RFC 3280 and neither to RFC 2459, as far as this particular PKIX
prescription is concerned.

Thank you for any feedback on this issue.

Regards,
  Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per
conto di Jean-Marc Desperrier
Inviato: marted� 13 aprile 2004 15.12
A: [email-masked]
Oggetto: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs

Santoni Adriano wrote:

> Well, it turns out that - despite the topic has been debated in the
> past - there is not much consense on the "true" intepretation of RFC 
> 3280, �4.1.2.4. The sentence " all certificates issued after December 
> 31, 2003 MUST use the UTF8String encoding of DirectoryString (except 
> as noted below) " is a prescriptive one, if I am not mistaken.
>  
> Nontheless, Glassey says "you have to do so, full-stop", while Gutman
> and Desperrier says "you'd better not" because  a) some application 
> would not handle UTF-8 properly and b) the CA should not "alter" the 
> name if a certificate already exists for the same subject.

I feel I have to say my post was not at all an interpretation of the 
meaning of RFC3280, and I did not intend to say that part of RFC3280 is 
not prescriptive.
It was just a remark about the state of current applications. They are other
aspects of RFC3280 that are certainly no more well 
supported in practice.

This said, AFAIR when the topic was debated in the past, it was 
concluded that renewal cert were one of the "except as noted below" case.

> Regarding point a), I personally agree that some applications will not
> behave properly when encountering UTF8Strings, but that should have 
> been taken into account when drafting RFC 3280, not today!

That part of RFC3280 was copied without any change (and I strongly 
suspect without discussion, or rereading) from RFC2459.

At the time RFC2459 was drafted, 2003 was far in the future, and the 
redactors surely hoped UTF8String would be widely in use before the 
deadline, so that this deadline would not be much a constraint.

> I am sure many of you have noticed that most CAs (all over the planet)
> claiming conformance to RFC3280 have not started issuing certificates 
> with subject names encoded as UTF8String, after 31 december 2003. I 
> dare to say one of the reasons might be a little ambiguity in RFC 3280 
> and probably insufficient debate on this specific topic.

I'm not sure the problem is due to any ambiguity in RFC3280.
I think some of the problem might be related to few people really trying 
to implement RFC3280 fully and carefully, many just implementing support 
for what they see the most often in use. If there is no UTF-8 around, 
they don't do it, and therefore nobody starts doing it.

I'm afraid all what one can hope is that some people will start to 
implement it because it's written in the RFC, will meet interoperability 
problems, will tell other implementors they are the one who don't 
respect the norm, and the other implementators will progressively 
correct any problem related to that in their code.
I now think expecting implementors to prepare for the future, or 
beginning to implement something until they are forced to is a lost 
cause, so the prescriptive aspect of RFC3280, and the fact applying it 
will break a few things, is a good thing if we really want certificates 
to support internationalization one day.

What I also think in relation to that is that there should be a 
normalized, pkix approved test suite for RFC3280 as complete as possible 
so that it would be very easy to ask anybody claiming RFC3280 
conformance what the result of the test suite is.

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

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

Date: Wed, 21 Apr 2004 18:45:13 +0900
From: =?ISO-2022-JP?B?GyRCQFAzQBsoQiAbJEJNWxsoQg==?= <[email-masked]>
To: [email-masked]
Subject: Re: TSA for testing
Sender: [email-masked]

ChallengePKI project will open timestamp
test center, based on Denis Pinkas's TSP 
Interoperability Testing Draft (Feb 2002).

http://www.jnsa.org/mpki/2003/

Regards,
Yo ISHIGAKI

On Fri, 26 Mar 2004 12:09:54 -0500 (EST)
"Scott Mustard" <[email-masked]> wrote:

> 
> Gerald Willet and I leave ours online as well at dse200.ncipher.com.
> 
> Cheers,
> 
> Scott Mustard
> 
> 
> 

---
Yo Ishigaki
SECOM Intelligent Systems Laboratory
TEL. 0422-76-2105 / FAX. 0422-76-2120

From: "Santosh Chokhani" <[email-masked]>
To: "'PKIX'" <[email-masked]>
Subject: RE: new -- Clarification Note proposal on cert revocation          -
Date: Tue, 20 Apr 2004 22:46:02 -0400
Importance: Normal
Sender: [email-masked]

Ed:

I do not think 3280 needs any clarification in this area.

There are several errors in the statements.

Also, some of the topics are CA and RP policy issues and not certificate and
CRL formats issue.

Since PKIX is not operating a CA or recommending any operations policy, none
of this is needed for any other document either.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ed Gerck
Sent: Tuesday, April 20, 2004 4:25 PM
To: PKIX
Subject: new -- Clarification Note proposal on cert revocation -

All,

I'm sending this new version for additional list's comments, in its 
short and long forms. Please refer to the long form if you have questions
reading the short form. PKIX list traffic also has ~30 
messages recently, Re "cert revocation", showing some of the context and
need for this clarification.

MOTIVATION (not intended as part of the proposed text)

The proposal is to add a Clarification Note to current PKIX documents that
deal with revocation and validation of certs. This would help 
the weary reader, who must otherwise wade through the PKIX documents and
list's archives in order to find limitations that are often not so clear to
most folks. I also used the opportunity to point out the 
conditions on those limitations in the long form of the Note, with a 
view to reducing their effect.

The purpose of the Clarification Note is not to reinvent or change 
X.509 or related PKIX RFCs. The purpose is to clarify and unify PKIX 
references (including WG context interpretation) in regard to 
certificate revocation. There should be many paragraphs in X.509 and 
related PKIX RFCs that are, with analysis, equivalent to the 
Clarification Note and vice versa. This is how it should be. The 
informative aspect of the Clarification Note is in terms of ambiguity 
resolution in the documentation and context interpretation.

As reported by Steve Kent, since there is a suggestion before the WG to 
issue an update to 3280, the WG can decide whether the Clarification Note
text should be part of the next update, if the WG proceeds on that work
item.

CLARIFICATION NOTE ON CERTIFICATE REVOCATION (short form)

In X.509/PKIX there is only one issuer CA for a given certificate. Only 
the issuer CA of a certificate is authoritative for revocation conditions of
the certificate. 

If a certificate is listed as revoked by means of one of those mechanisms 
identified by the issuer CA in a conforming certificate extension (e.g., a
CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP 
status, an HTTP CRL list), OR if any other revocation condition defined by 
the issuer CA applies (e.g., expired or revoked issuer CA certificate), the
certificate is revoked. Otherwise, the certificate is not revoked.

However, from a particular RP's point of view, there are several limitations
on verifying the current revocation status of a certificate.

For example, if an RP does not support any of the mechanisms defined by the 
issuer CA to verify the revocation status, or times out during such 
verification, or cannot find a path to verify the status, then the
revocation 
status is undefined for that RP. 

Also, since there may be more than one path used to verify the revocation 
status of the same certificate, the occurrence of race conditions, 
differently available paths, and revoked parent certificates can lead to 
ambiguous results for different RPs. Therefore, different RPs may arrive at
a 
different view of the revocation status of a EE, CA or cross certificate at
a 
particular time.

An RP software relying on the revocation status of a certificate specified
by 
any mechanism, authorized or not by the issuer CA of the certificate, is
also subject to conditions defined by the issuer CA. Those conditions may
change 
from time to time. Some mechanisms may not include direct evidence of the 
issuer CA's assertion of a certificate's revocation status or conditions, at

a particular time.

Further, from a particular RP's point of view, the revocation status of a 
certificate is not enough to define the validity of that certificate. 
Certificate validity is a function of a number of additional parameters, 
including the certificate path that the RP trusts to validate the 
certificate, the access to revocation status information available to the
RP, 
the local policy used by the RP, and the application (the RP software) that 
the RP will employ. The validity of a certificate refers to conditions that 
are authoritatively defined locally. 

Note that the distinction between "revocation" and "validation" has been 
somewhat blurred in the documentation and informal discussions. That 
distinction is, however, necessary to preserve both the control needs for 
PKI, requiring centralized conditions of revocation that are authoritatively

defined by the issuer CA, and those business and user needs, requiring local

authoritative definition of validation.

Now we ask the critical question: When is a certificate revoked? The answer
is: when the corresponding revocation status is published by means of one of
those mechanisms identified by the issuer CA in a conforming certificate 
extension, or when any other revocation condition defined by the issuer CA
applies. It does not matter when a particular RP is able to verify that 
status, or what mechanisms an RP can use for such purpose. The revocation 
status of a certificate issued by a conforming CA does not depend on an RP
and is always well-defined from an RP's point of view -- i.e., it is 
unambiguous (revoked or not revoked) and ultimately verifiable.

Therefore, from a particular RP's point of view, the limitations on 
verifying the current revocation status of a certificate have nothing to do
with the eventual result of that verification, which is always well-defined.
The limitations have to do with the efforts for that verification, which may

require an unspecified amount of time and work. Human intervention may also
be necessary.  The same considerations apply to certificateHold and 
removefromCRL status.

CLARIFICATION NOTE ON CERTIFICATE REVOCATION (long form)

In X.509/PKIX there is only one issuer CA for a given certificate. Only 
the issuer CA of a certificate is authoritative for revocation conditions of
the certificate. One of those conditions is that the certificate must 
be signed by a CA certificate, issued by the issuer CA, that has not expired

and is not revoked. Another condition is that the issuer CA may delegate the

authority for a particular certificate's revocation notices and/or status to

another entity called the CRL issuer, identified by the CA in the CRL 
Distribution Point (CDP) extension of the certificate. Another condition is 
that the issuer CA may send the revocation notice for a particular 
certificate as a status service to a server identified by the CA in the 
Authority Information Access (AIA) extension of the certificate with an OCSP

access descriptor or an HTTP CRL access descriptor.

If a certificate is listed as revoked by means of one of those mechanisms 
identified by the issuer CA in a conforming certificate extension (e.g., a
CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP 
status, an HTTP CRL list), OR if any other revocation condition defined by 
the issuer CA applies (e.g., expired or revoked issuer CA certificate), the
certificate is revoked. Otherwise, the certificate is not revoked.

In short, because the revocation status of a certificate refers to
conditions that a conforming issuer CA authoritatively and unambiguously
defines, a 
certificate is either revoked or not from the issuer CA viewpoint.

However, from a particular RP's point of view, there are several limitations
on verifying the current revocation status of a certificate.

For example, if an RP does not support any of the mechanisms defined by the 
issuer CA to verify the revocation status, or times out during such 
verification, or cannot find a path to verify the status, then the
revocation 
status is undefined for that RP. According to RFC 3280, this can happen even

for a conforming CA and a conforming application (RP software). Conforming 
CAs are not required to issue CRLs if other revocation or certificate status

mechanisms are provided. Conforming applications are NOT REQUIRED to support

processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all

certificates issued by one CA. 

Also, since there may be more than one path used to verify the revocation 
status of the same certificate, the occurrence of race conditions, 
differently available paths, and revoked parent certificates can lead to 
ambiguous results for different RPs. If a CA sends status data to an OCSP 
Responder including a revocation notice before creating a CRL, the 
certificate in question is revoked for an RP receiving the OCSP Responder's 
status but not for an RP accessing only the current CRL. Even along a single

path, different RPs may have access to different revocation status for a CA 
or cross certificate. Further, as demanded by chain processing rules, a 
revoked parent certificate may or may not cause an RP to deduce that a child

certificate status is revoked, independently of the current authoritative 
revocation status. Therefore, different RPs may arrive at a different view
of 
the revocation status of a EE, CA or cross certificate at a particular time.

Resolution of revocation status may be difficult for the RP's software. For 
example, the software may need to wait for a fresher CRL, the software may 
need more time than what is available for the desired action, the software 
may need additional communication channels that are not available to the 
software at the time of checking, the software might need human
intervention, 
and so on. Using any single mechanism to specify revocation information can 
be seen as introducing a single point of failure from the RP's software
point 
of view. 

An RP software relying on the revocation status of a certificate specified
by 
any mechanism, authorized or not by the issuer CA of the certificate, is
also subject to conditions defined by the issuer CA. Those conditions may
change 
from time to time. Some mechanisms may not include direct evidence of the 
issuer CA's assertion of a certificate's revocation status or conditions, at

a particular time.

With a view to reducing the effect of those limitations, an RP can determine

bounds on the extent of those limitations, or at least ways in which those 
limitations can be bounded. Some of those limitations can also be prevented 
or reduced by using a strategy of redundancy and diversity.

For example:

- There are various unspecified and unpublished delays between the time a
CA, 
CRL issuer or OCSP Responder receives notice to revoke, suspend, or
reinstate 
a certificate and the time the information status is made available through 
the CA's CRL, an indirect CRL, a delta CRL, an OCSP Responder, a DPV Server,

or a client. Nonetheless, some of these bounds can be actually known or 
modeled by an RP.

- To prevent single access faults and race conditions, a certificate can use

multiple mechanisms to specify revocation information, some of which can be 
redundant mechanisms, where an RP should be able to interoperate with any of

those mechanisms which it trusts. Multiple mechanisms available to an issuer

CA include a CDP extension with a URI DistributionPointName, an AIA
extension 
with an OCSP access descriptor, and an AIA extension with an HTTP CRL access

descriptor. An RP receiving both an OCSP Responder's status and the CA's CRL

for a certificate is less susceptible to race conditions caused by CA's 
delays when sending status data to the OCSP Responder with a revocation 
notice and publishing a CRL for the certificate in question.

Further, from a particular RP's point of view, the revocation status of a 
certificate is not enough to define the validity of that certificate. 
Certificate validity is a function of a number of additional parameters, 
including the certificate path that the RP trusts to validate the 
certificate, the access to revocation status information available to the
RP, 
the local policy used by the RP, and the application (the RP software) that 
the RP will employ. The validity of a certificate refers to conditions that 
are authoritatively defined locally.

Note that the distinction between "revocation" and "validation" has been 
somewhat blurred in the documentation and informal discussions. It is
further corroded by the usual practice of talking about the determination of
the 
revocation status by an RP, whereas all that the RP can do is verify the 
revocation status, for which conditions the issuer CA is authoritative. 

That distinction is, however, necessary to preserve both the control needs 
for PKI, requiring centralized conditions of revocation that are 
authoritatively defined by the issuer CA, and those business and user needs,
requiring local authoritative definition of validation. There are also those
cases in which domains may choose to adopt one or other model based on an 
operational rationale. The flexibility of having both a centralized 
revocation mechanism and a localized validation mechanism is an important
feature of X.509/PKIX.

For example, a certificate can also be authoritatively revoked when the 
issuer CA or the CRL issuer makes the revocation status available to an RP
in 
a reasonable way. For example, by signed XML messages in a wireless network,

by SQL over HTTPS, or in a signed SOAP response for database lookup over web

services. What matters to the RP is the revocation status, in a repository
or as a status message, and whether it has been published by some means 
acceptable by the RP.

As another example, a CRL Issuer or an OCSP responder may perform additional

processing, beyond aggregating and republishing revocation notices as 
revocation status services. If the operator of the service knows an RP's 
validation criteria, they may apply those criteria when creating a
validation 
service for that RP. In this case, the "validation service" is a policy- 
enhanced validation service tuned to the acceptance processes of the RP, 
rather than only to the revocation processes of CAs and their delegates.

Can a validation service indicate a certificate to be valid, when the 
revocation status is revoked? Yes -- e.g., for the purpose of an RP reading
a 
timely message, the security policy of a validation service may consider a 
certificate to be valid when no revocation status can be contacted. 
Generalizing this behavior is an implementation flaw, however. For example, 
the widely used TLS/SSL security application in Internet browsers does not 
currently verify the revocation status of EE and CA certificates and always 
considers the resulting undefined revocation status as valid. 

Now we ask the critical question: When is a certificate revoked? The answer
is: when the corresponding revocation status is published by means of one of
those mechanisms identified by the issuer CA in a conforming certificate 
extension, or when any other revocation condition defined by the issuer CA
applies. It does not matter when a particular RP is able to verify that 
status, or what mechanisms an RP can use for such purpose. The revocation 
status of a certificate issued by a conforming CA does not depend on an RP
and is always well-defined from an RP's point of view -- i.e., it is 
unambiguous (revoked or not revoked) and ultimately verifiable.

Therefore, from a particular RP's point of view, the limitations on 
verifying the current revocation status of a certificate have nothing to do
with the eventual result of that verification, which is always well-defined.
The limitations have to do with the efforts for that verification, which may

require an unspecified amount of time and work. Human intervention may also
be necessary.  The same considerations apply to certificateHold and 
removefromCRL status.

ACKNOWLEDGMENTS

The names cited do not mean endorsement of this work, which is the sole 
responsibility of the author. I would like to thank very useful comments by 
Santoshi Chokhani, Tom Gidin, Paul Hoffman, David Kemp, Steve Kent, Stefan 
Santesson, Peter Williams, Julien Stern and the PKIX list.

Ed Gerck
[email-masked]

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Status of draft-ietf-pkix-certstore-http?
Date: Wed, 21 Apr 2004 12:56:39 +1200
Sender: [email-masked]

Jack Lloyd <[email-masked]> writes:

>The last version of this draft I can find is -05, expiring in September 2003.
>Has this draft been abandoned, or is going to start moving again at some
>point?

A number of people have been asking that :-).  The current draft was
mistakenly deleted from the IETF server, I'll get a new version up within the
next few days, although I'm not sure what number it'll have because of the
missing (deleted) copy.  For all intents and purposes it's identical to -05,
there's just two minor wording changes.

Peter.

Date: Tue, 20 Apr 2004 13:24:43 -0700
From: Ed Gerck <[email-masked]>
To: PKIX <[email-masked]>
Subject: new -- Clarification Note proposal on cert revocation          -
Sender: [email-masked]

All,

I'm sending this new version for additional list's comments, in its 
short and long forms. Please refer to the long form if you have
questions reading the short form. PKIX list traffic also has ~30 
messages recently, Re "cert revocation", showing some of the context
and need for this clarification.

MOTIVATION (not intended as part of the proposed text)

The proposal is to add a Clarification Note to current PKIX documents
that deal with revocation and validation of certs. This would help 
the weary reader, who must otherwise wade through the PKIX documents
and list's archives in order to find limitations that are often not so
clear to most folks. I also used the opportunity to point out the 
conditions on those limitations in the long form of the Note, with a 
view to reducing their effect.

The purpose of the Clarification Note is not to reinvent or change 
X.509 or related PKIX RFCs. The purpose is to clarify and unify PKIX 
references (including WG context interpretation) in regard to 
certificate revocation. There should be many paragraphs in X.509 and 
related PKIX RFCs that are, with analysis, equivalent to the 
Clarification Note and vice versa. This is how it should be. The 
informative aspect of the Clarification Note is in terms of ambiguity 
resolution in the documentation and context interpretation.

As reported by Steve Kent, since there is a suggestion before the WG to 
issue an update to 3280, the WG can decide whether the Clarification Note
text should be part of the next update, if the WG proceeds on that work
item.

CLARIFICATION NOTE ON CERTIFICATE REVOCATION (short form)

In X.509/PKIX there is only one issuer CA for a given certificate. Only 
the issuer CA of a certificate is authoritative for revocation conditions
of the certificate. 

If a certificate is listed as revoked by means of one of those mechanisms 
identified by the issuer CA in a conforming certificate extension (e.g.,
a CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP 
status, an HTTP CRL list), OR if any other revocation condition defined by 
the issuer CA applies (e.g., expired or revoked issuer CA certificate), the
certificate is revoked. Otherwise, the certificate is not revoked.

However, from a particular RP's point of view, there are several limitations
on verifying the current revocation status of a certificate.

For example, if an RP does not support any of the mechanisms defined by the 
issuer CA to verify the revocation status, or times out during such 
verification, or cannot find a path to verify the status, then the revocation 
status is undefined for that RP. 

Also, since there may be more than one path used to verify the revocation 
status of the same certificate, the occurrence of race conditions, 
differently available paths, and revoked parent certificates can lead to 
ambiguous results for different RPs. Therefore, different RPs may arrive at a 
different view of the revocation status of a EE, CA or cross certificate at a 
particular time.

An RP software relying on the revocation status of a certificate specified by 
any mechanism, authorized or not by the issuer CA of the certificate, is also
subject to conditions defined by the issuer CA. Those conditions may change 
from time to time. Some mechanisms may not include direct evidence of the 
issuer CA's assertion of a certificate's revocation status or conditions, at 
a particular time.

Further, from a particular RP's point of view, the revocation status of a 
certificate is not enough to define the validity of that certificate. 
Certificate validity is a function of a number of additional parameters, 
including the certificate path that the RP trusts to validate the 
certificate, the access to revocation status information available to the RP, 
the local policy used by the RP, and the application (the RP software) that 
the RP will employ. The validity of a certificate refers to conditions that 
are authoritatively defined locally. 

Note that the distinction between "revocation" and "validation" has been 
somewhat blurred in the documentation and informal discussions. That 
distinction is, however, necessary to preserve both the control needs for 
PKI, requiring centralized conditions of revocation that are authoritatively 
defined by the issuer CA, and those business and user needs, requiring local 
authoritative definition of validation.

Now we ask the critical question: When is a certificate revoked? The answer
is: when the corresponding revocation status is published by means of one of
those mechanisms identified by the issuer CA in a conforming certificate 
extension, or when any other revocation condition defined by the issuer CA
applies. It does not matter when a particular RP is able to verify that 
status, or what mechanisms an RP can use for such purpose. The revocation 
status of a certificate issued by a conforming CA does not depend on an
RP and is always well-defined from an RP's point of view -- i.e., it is 
unambiguous (revoked or not revoked) and ultimately verifiable.

Therefore, from a particular RP's point of view, the limitations on 
verifying the current revocation status of a certificate have nothing to do
with the eventual result of that verification, which is always well-defined.
The limitations have to do with the efforts for that verification, which may 
require an unspecified amount of time and work. Human intervention may also
be necessary.  The same considerations apply to certificateHold and 
removefromCRL status.

CLARIFICATION NOTE ON CERTIFICATE REVOCATION (long form)

In X.509/PKIX there is only one issuer CA for a given certificate. Only 
the issuer CA of a certificate is authoritative for revocation conditions
of the certificate. One of those conditions is that the certificate must 
be signed by a CA certificate, issued by the issuer CA, that has not expired 
and is not revoked. Another condition is that the issuer CA may delegate the 
authority for a particular certificate's revocation notices and/or status to 
another entity called the CRL issuer, identified by the CA in the CRL 
Distribution Point (CDP) extension of the certificate. Another condition is 
that the issuer CA may send the revocation notice for a particular 
certificate as a status service to a server identified by the CA in the 
Authority Information Access (AIA) extension of the certificate with an OCSP 
access descriptor or an HTTP CRL access descriptor.

If a certificate is listed as revoked by means of one of those mechanisms 
identified by the issuer CA in a conforming certificate extension (e.g.,
a CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP 
status, an HTTP CRL list), OR if any other revocation condition defined by 
the issuer CA applies (e.g., expired or revoked issuer CA certificate), the
certificate is revoked. Otherwise, the certificate is not revoked.

In short, because the revocation status of a certificate refers to conditions
that a conforming issuer CA authoritatively and unambiguously defines, a 
certificate is either revoked or not from the issuer CA viewpoint.

However, from a particular RP's point of view, there are several limitations
on verifying the current revocation status of a certificate.

For example, if an RP does not support any of the mechanisms defined by the 
issuer CA to verify the revocation status, or times out during such 
verification, or cannot find a path to verify the status, then the revocation 
status is undefined for that RP. According to RFC 3280, this can happen even 
for a conforming CA and a conforming application (RP software). Conforming 
CAs are not required to issue CRLs if other revocation or certificate status 
mechanisms are provided. Conforming applications are NOT REQUIRED to support 
processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all 
certificates issued by one CA. 

Also, since there may be more than one path used to verify the revocation 
status of the same certificate, the occurrence of race conditions, 
differently available paths, and revoked parent certificates can lead to 
ambiguous results for different RPs. If a CA sends status data to an OCSP 
Responder including a revocation notice before creating a CRL, the 
certificate in question is revoked for an RP receiving the OCSP Responder's 
status but not for an RP accessing only the current CRL. Even along a single 
path, different RPs may have access to different revocation status for a CA 
or cross certificate. Further, as demanded by chain processing rules, a 
revoked parent certificate may or may not cause an RP to deduce that a child 
certificate status is revoked, independently of the current authoritative 
revocation status. Therefore, different RPs may arrive at a different view of 
the revocation status of a EE, CA or cross certificate at a particular time.

Resolution of revocation status may be difficult for the RP's software. For 
example, the software may need to wait for a fresher CRL, the software may 
need more time than what is available for the desired action, the software 
may need additional communication channels that are not available to the 
software at the time of checking, the software might need human intervention, 
and so on. Using any single mechanism to specify revocation information can 
be seen as introducing a single point of failure from the RP's software point 
of view. 

An RP software relying on the revocation status of a certificate specified by 
any mechanism, authorized or not by the issuer CA of the certificate, is also
subject to conditions defined by the issuer CA. Those conditions may change 
from time to time. Some mechanisms may not include direct evidence of the 
issuer CA's assertion of a certificate's revocation status or conditions, at 
a particular time.

With a view to reducing the effect of those limitations, an RP can determine 
bounds on the extent of those limitations, or at least ways in which those 
limitations can be bounded. Some of those limitations can also be prevented 
or reduced by using a strategy of redundancy and diversity.

For example:

- There are various unspecified and unpublished delays between the time a CA, 
CRL issuer or OCSP Responder receives notice to revoke, suspend, or reinstate 
a certificate and the time the information status is made available through 
the CA's CRL, an indirect CRL, a delta CRL, an OCSP Responder, a DPV Server, 
or a client. Nonetheless, some of these bounds can be actually known or 
modeled by an RP.

- To prevent single access faults and race conditions, a certificate can use 
multiple mechanisms to specify revocation information, some of which can be 
redundant mechanisms, where an RP should be able to interoperate with any of 
those mechanisms which it trusts. Multiple mechanisms available to an issuer 
CA include a CDP extension with a URI DistributionPointName, an AIA extension 
with an OCSP access descriptor, and an AIA extension with an HTTP CRL access 
descriptor. An RP receiving both an OCSP Responder's status and the CA's CRL 
for a certificate is less susceptible to race conditions caused by CA's 
delays when sending status data to the OCSP Responder with a revocation 
notice and publishing a CRL for the certificate in question.

Further, from a particular RP's point of view, the revocation status of a 
certificate is not enough to define the validity of that certificate. 
Certificate validity is a function of a number of additional parameters, 
including the certificate path that the RP trusts to validate the 
certificate, the access to revocation status information available to the RP, 
the local policy used by the RP, and the application (the RP software) that 
the RP will employ. The validity of a certificate refers to conditions that 
are authoritatively defined locally.

Note that the distinction between "revocation" and "validation" has been 
somewhat blurred in the documentation and informal discussions. It is further
corroded by the usual practice of talking about the determination of the 
revocation status by an RP, whereas all that the RP can do is verify the 
revocation status, for which conditions the issuer CA is authoritative. 

That distinction is, however, necessary to preserve both the control needs 
for PKI, requiring centralized conditions of revocation that are 
authoritatively defined by the issuer CA, and those business and user needs,
requiring local authoritative definition of validation. There are also those
cases in which domains may choose to adopt one or other model based on an 
operational rationale. The flexibility of having both a centralized 
revocation mechanism and a localized validation mechanism is an important
feature of X.509/PKIX.

For example, a certificate can also be authoritatively revoked when the 
issuer CA or the CRL issuer makes the revocation status available to an RP in 
a reasonable way. For example, by signed XML messages in a wireless network, 
by SQL over HTTPS, or in a signed SOAP response for database lookup over web 
services. What matters to the RP is the revocation status, in a repository or
as a status message, and whether it has been published by some means 
acceptable by the RP.

As another example, a CRL Issuer or an OCSP responder may perform additional 
processing, beyond aggregating and republishing revocation notices as 
revocation status services. If the operator of the service knows an RP's 
validation criteria, they may apply those criteria when creating a validation 
service for that RP. In this case, the "validation service" is a policy- 
enhanced validation service tuned to the acceptance processes of the RP, 
rather than only to the revocation processes of CAs and their delegates.

Can a validation service indicate a certificate to be valid, when the 
revocation status is revoked? Yes -- e.g., for the purpose of an RP reading a 
timely message, the security policy of a validation service may consider a 
certificate to be valid when no revocation status can be contacted. 
Generalizing this behavior is an implementation flaw, however. For example, 
the widely used TLS/SSL security application in Internet browsers does not 
currently verify the revocation status of EE and CA certificates and always 
considers the resulting undefined revocation status as valid. 

Now we ask the critical question: When is a certificate revoked? The answer
is: when the corresponding revocation status is published by means of one of
those mechanisms identified by the issuer CA in a conforming certificate 
extension, or when any other revocation condition defined by the issuer CA
applies. It does not matter when a particular RP is able to verify that 
status, or what mechanisms an RP can use for such purpose. The revocation 
status of a certificate issued by a conforming CA does not depend on an
RP and is always well-defined from an RP's point of view -- i.e., it is 
unambiguous (revoked or not revoked) and ultimately verifiable.

Therefore, from a particular RP's point of view, the limitations on 
verifying the current revocation status of a certificate have nothing to do
with the eventual result of that verification, which is always well-defined.
The limitations have to do with the efforts for that verification, which may 
require an unspecified amount of time and work. Human intervention may also
be necessary.  The same considerations apply to certificateHold and 
removefromCRL status.

ACKNOWLEDGMENTS

The names cited do not mean endorsement of this work, which is the sole 
responsibility of the author. I would like to thank very useful comments by 
Santoshi Chokhani, Tom Gidin, Paul Hoffman, David Kemp, Steve Kent, Stefan 
Santesson, Peter Williams, Julien Stern and the PKIX list.

Ed Gerck
[email-masked]

Date: Tue, 20 Apr 2004 10:11:47 -0400
From: Jack Lloyd <[email-masked]>
To: [email-masked]
Subject: Status of draft-ietf-pkix-certstore-http?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

The last version of this draft I can find is -05, expiring in September
2003. Has this draft been abandoned, or is going to start moving again at some
point?

-Jack

Date: Sun, 18 Apr 2004 18:41:47 -0700
From: Ed Gerck <[email-masked]>
To: PKIX <[email-masked]>
CC: Stefan Santesson <[email-masked]>
Subject: Re: clarification proposal -- Re: Current status of CRL validation?
Sender: [email-masked]

Stefan,

On further thought, I'm even more indebted to your observation.
It is indeed possible and desirable to eliminate the "valid path" 
qualifier.

BTW, a new (hopefully improved) text shall be available tomorrow.

Cheers,
Ed Gerck

Ed Gerck wrote:
> 
> Stefan Santesson wrote:
> >
> > The basic assumption for the whole discussion seems to be very confused:
> >
> > Snip:
> > >
> > >    "Since there may be more than one path used to validate the
> > >    same certificate, it is possible that some paths to that
> > >    certificate are valid while others are not."
> > >
> >
> > There is only 1 kind of path that can be used to validate a certificate,
> > and that is a valid path.
> 
> Valid to a RP may not be valid to another RP. To clarify this,
> the text could say:
> 
>  Since there may be more than one path used to validate the same
>  certificate, it is possible that some paths to that certificate
>  are valid for some RPs while not valid to other RPs.
> 
> > Valid being defined as a path that pass the
> > RPs validation policy (defined at the discretion of the relying party).
> 
> Exactly. It depends on what each RP may choose to rely upon. Different
> RPs may define "valid path" in a different way.
> 
> The RP may also receive different answers from valid paths.
> 
> > All other paths are invalid by definition. So among the valid paths
> > there is no ambiguity, since they are all valid.
> >
> > Why complicate things?
> 
> The RPs are complicated ;-)
> 
> Cheers,
> Ed Gerck

Date: Fri, 16 Apr 2004 17:21:14 -0400
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Intel killed the smart ID-card
Cc: <[email-masked]>
Sender: [email-masked]

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

At 10:06 PM +0200 4/13/04, Anders Rundgren wrote:
>Steve,
>
>IMO you should rather be happy as this means that the technology you 
>have been preaching about since ages ago, may finally become 
>mainstream.  Yes, it will also bring new life to "indirect" PKI 
>schemes like SAML and 3D Secure, but I believe this is just fine.

you would :-)

>  The only major reason why smart cards may be more secure than 
>mobile phones (here not including physical attacks on the chips) is 
>that they are so powerless in comparison to the latter. 

or, stated differently, a simple device has a much better chance of 
performing a limited set of functions correctly (and securely) than a 
much more complex device. The original Palms are a good example, vs. 
Pocket PCs.

>  Talking about security:  How secure is it really to use PIN-codes 
>in public or unknown PCs?  Using the described concept, PIN-codes 
>never leave your trusted device.

I don't use public PCs.  In fact, as a Mac user, I try to never use PCs at all.

>  Assume you are on a the road and don't bring your laptop around, 
>where would you be able to use your smart ID card?  Probably 
>nowhere.  Using mobile phones as "carriers", you are much more 
>likely to have the ID (and be able to use it) when you actually need 
>it.

I always bring my laptop with me.

>  Smart ID cards will indeed survive, but only in the DoD and 
>similar places where it is OK to burn any amount of tax-payer money 
>in the name of the nation.

I am still amazed at the naivete re DoD criteria as expressed by 
those with no direct knowledge of such criteria.

>The smart card vendors have had ample of time to launch a ubiquitous 
>PKI card and free software but they didn't.  Now it is "harvest 
>time" :-)

Please do hold your breath.

Steve
--============_-1129969580==_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: Intel killed the smart
ID-card</title></head><body>
<div>At 10:06 PM +0200 4/13/04, Anders Rundgren wrote:</div>
<blockquote type="cite" cite><font face="Arial"
size="-1">Steve,</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">IMO you
should rather be happy as this means that the technology you have been
preaching about since ages ago, may finally become mainstream.&nbsp;
Yes, it will also bring new life to &quot;indirect&quot; PKI
schemes&nbsp;like SAML and 3D Secure, but I believe this is just
fine.</font></blockquote>
<div><br></div>
<div>you would :-)</div>
<div><br></div>
<blockquote type="cite" cite>&nbsp;<font face="Arial" size="-1">The
only major reason why smart cards<i> may</i> be more secure than
mobile phones (here not including physical attacks on the
chips)&nbsp;is that they are so powerless in comparison to the
latter.&nbsp;</font></blockquote>
<div><br></div>
<div>or, stated differently, a simple device has a much better chance
of performing a limited set of functions correctly (and securely) than
a much more complex device. The original Palms are a good example, vs.
Pocket PCs.</div>
<div><br></div>
<blockquote type="cite" cite>&nbsp;<font face="Arial"
size="-1">Talking about security:&nbsp; How secure is it really to use
PIN-codes in public or unknown PCs?&nbsp; Using the described concept,
PIN-codes never leave<i> your</i> trusted device.</font></blockquote>
<div><br></div>
<div>I don't use public PCs.&nbsp; In fact, as a Mac user, I try to
never use PCs at all.</div>
<div><br></div>
<blockquote type="cite" cite>&nbsp;<font face="Arial" size="-1">Assume
you are on a the road and don't bring your laptop around, where would
you be able to use your smart ID card?&nbsp;&nbsp;Probably nowhere.&nbsp;
Using&nbsp;mobile phones as &quot;carriers&quot;,&nbsp;you are much
more likely to have the ID (and be able to use it)&nbsp;when you
actually need it.</font></blockquote>
<div><br></div>
<div>I always bring my laptop with me.<br>
</div>
<blockquote type="cite" cite>&nbsp;<font face="Arial" size="-1">Smart
ID cards will indeed&nbsp;survive, but only in the&nbsp;DoD and
similar&nbsp;places where it is OK to burn any amount of tax-payer
money in the name of the nation.</font></blockquote>
<div><br></div>
<div>I am still amazed at the naivete re DoD criteria as expressed by
those with no direct knowledge of such criteria.</div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial" size="-1">The smart
card vendors have had ample of time to launch a ubiquitous PKI card
and free software but they didn't.&nbsp; Now it is &quot;harvest time&quot;
:-)</font></blockquote>
<div><br></div>
<div>Please do hold your breath.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1129969580==_ma============--

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Thu, 15 Apr 2004 17:24:19 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "David Engberg" <[email-masked]>
Sender: [email-masked]

Hi Michael,
Looks like we are still talk past each other.
As far as I can see on the list the topic became redundant because the
issue was addressed by another mechanism. 
So is there some new problem which needs to be addressed?
Trevor
-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Thursday, April 15, 2004 5:12 PM
To: [email-masked]
Cc: Stephen Kent; Santosh Chokhani; David Engberg; Trevor Freeman
Subject: RE: Signing Untrusted SCVP?

Trevor,

As the list will show, a rough consensus has been established
regarding DPD response signatures.  It would be helpful if you
were to detail your objections to this outcome.

Mike

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Thursday, April 15, 2004 3:03 PM
To: Michael Myers; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Michael,

I agree we are talking past each other. So David said he had a
problem
(server load) and could we could address it via method
a(unsigned DPD
responses), I said we could almost do the same by method b
(caching
responses) with less impact on the spec, he said he could live
with that
as a solution. Therefore Dave's issue is addressed and method a
is no
longer under consideration unless there is something new. Is
there
something new?

Trevor

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Thu, 15 Apr 2004 15:02:51 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Michael,

I agree we are talking past each other. So David said he had a problem
(server load) and could we could address it via method a(unsigned DPD
responses), I said we could almost do the same by method b (caching
responses) with less impact on the spec, he said he could live with that
as a solution. Therefore Dave's issue is addressed and method a is no
longer under consideration unless there is something new. Is there
something new?
Trevor

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Thursday, April 15, 2004 12:35 PM
To: Trevor Freeman; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor,

I fear we may be talking past each other.  You're saying caching
and I'm saying signing.  Note the Subject: line of this thread.

Dave had concerns regarding "MUST sign" DPD responses.  After
some back-and-forth, Steve and Santosh came back advocating for
"MUST be capable of" signing, which I proposed and Santosh
agreed to.  I trust based on his prior comments on this thread
that Steve would share Santosh's affinity for this resolution.

That said, I worked with Dave to develop a common understanding
on what precisely it meant to "be capable of" from the
perspectives of implementor and deployer. See below for example,
one of many such PKIX exchanges on this subject over the past
couple of weeks.  Now he too agrees with the change to "MUST be
capable of" signing DPD responses.

Mike

-----Original Message-----
From: David Engberg
Sent: Tuesday, April 13, 2004 4:17 AM

Yes.  Is that allowable?

. . .

Michael Myers wrote:
> Dave,
>
> Do you mean by "removed" that a local administrator may choose
> not to install DPD signing?
>
> Mike

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Thu, 15 Apr 2004 12:01:01 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Michael,
The original issue was reducing load on the server, and caching
responses is the proposed solution which has consensus so I consider the
issue addressed. Is there some other issue that troubles you.
Trevor

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Thursday, April 15, 2004 11:20 AM
To: Trevor Freeman; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor,

Caching is ancillary to the issue.  The proposed use of "be
capable of" enables unsigned DPD responses as long as the server
is nonetheless capable of signing them.  As to other issues, I
only took notice of and action on this one.  There may be others
I'm not aware of.

Mike

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Thursday, April 15, 2004 10:27 AM
To: Michael Myers; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Michael,
Given Dave agrees that cached server responses meets his needs,
what
issues are left?

Trevor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Tuesday, April 13, 2004 4:04 PM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor,

It seeks to establish a consensus within the WG on this draft
work product.

Mike

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 2:44 PM
To: Michael Myers; Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Mike,
I have no idea what this proposed change seeks to accomplish
other than
defeating the objective on having a reasonable expectation of an
onteropabe standard since it make it totally opaque as to what a
valid
response is.
Trevor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Tuesday, April 13, 2004 11:17 AM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor?

Mike

-----Original Message-----
From: Dave Engberg [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 11:03 AM
To: Michael Myers
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Sounds good.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 2:01 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Dave,

Installation from original distribution media is perfectly
acceptable to
my understanding of "be capable of".

The understanding I wish to achieve is that selectable
functionality (as
defined by "be capable of") is produced, fully tested, and
shipped at
the same time as mandated functionality--versus rapidly writing
the
code, perhaps not testing it too much if at all, and hustling
out a
patch in the context of an emerging threat.

Another way of saying it is that "be capable of" does NOT IMHO
mean
"we'll write, ship and be prepared to support the code when the
marketplace asks for it".

I see that Steve has provided us his opinion.  Can close this
thread
with a consensus to change the relevant MUSTs to "MUST be
capable of"?.

Mike

Date: Thu, 15 Apr 2004 14:56:05 -0400
From: "David A. Cooper" <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>
CC: [email-masked]
Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Sender: [email-masked]

Jean-Marc Desperrier wrote:

> What I also think in relation to that is that there should be a 
> normalized, pkix approved test suite for RFC3280 as complete as 
> possible so that it would be very easy to ask anybody claiming RFC3280 
> conformance what the result of the test suite is.

Last year NIST, in conjunction with DigitalNet and NSA, developed the 
Public Key Interoperability Test Suite (PKITS): a path validation test 
suite that is available at 
http://csrc.nist.gov/pki/testing/x509paths.html.  This test suite 
includes over 200 tests and was designed to cover most of the features 
in RFC 3280.  I would like to see PKITS adopted for use as you suggest 
above.

If you are interested in using a path validation test suite to test path 
validation implementations, I would suggest that you look at this test 
suite.  If you believe that new tests would need to be added in order 
for PKITS to meet your needs, please let me know what new tests you 
think would be needed and I will consider adding them.

The test suite by itself will not be enough to ensure interoperability.  
RFC 3280 includes many rather obscure features and I don't expect 
vendors to implement all of them.  For the U.S. Government, NIST is 
trying to address this by creating profiles.  We are creating document 
that specifies the set of features from RFC 3280 that we believe are 
needed for use within the Federal PKI.  In order to achieve 
interoperability, we will encourage agencies use path validation 
implementations that implement all of these features and we will 
encourage them not to use any other features in the certificates and 
CRLs that they issue.

The document specifying which features need to be implemented will also 
then indicate how PKITS can be used to verify that a path validation 
implementation implements those features correctly (it will also 
indicate how to verify that any other feature that is implemented is 
implemented correctly).  The more features that a path validation 
implementation implements, the more tests from PKITS will need to be run 
in order to demonstrate correct implementation.  However, in no case 
will the document require that every one of the tests from PKITS be run.

As I said above, it is my hope that others will adopt PKITS as well even 
those who have decided that they need a different set of features than 
what we believe will be needed within the U.S. Federal PKI.  Vendors 
would just have to run a different subset of PKITS to demonstrate that 
they implement this different set of features.

Dave

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: key uniqueness in a PKI
Date: Thu, 15 Apr 2004 12:38:21 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C422E6.899348D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks to both Steve and Bill. Now for a more technical question: how
bad is not to check for key uniqueness? does anyone know about problems
arising from this situation?
 
Thanks in advance,
 
Miguel Rodriguez

-----Original Message-----
From: Bill Burns [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 7:43 PM
To: Stephen Kent
Cc: Miguel Rodriguez; [email-masked]
Subject: Re: key uniqueness in a PKI

Stephen Kent wrote on 4/7/04, 1:39 PM: 

At 10:39 AM -0500 4/7/04, Miguel Rodriguez wrote:

Where can I find information on key pair uniqueness in a PKI? Is this
issue discussed in an RFC?

I will also appreciate comments on this issue, particularly when
considering a PKI with several CAs.

Thanks.

Miguel A Rodriguez

SeguriData

Mexico

there is no standards-based requirement that a CA verify that each cert
request contain a unique public key, neither globally nor relative to
the certs that the CA has perviously issued.  A CA might choose to try
to make checks relative to the certs it has issued, and for which it
still has this info, but there is no requirement to do so in X.509 nor
PKIX standards.

Steve

FWIW, there's also a mention of this in the WebTrust for CA's
documentation.  It's not a "requirement" per se, but they seem to
suggest that it's a good idea.  Nevertheless, that's a pretty expensive
operation to perform...especially as the Member base grows.

bill

------=_NextPart_000_0013_01C422E6.899348D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D741553517-15042004>Thanks=20
to both Steve and Bill. Now for a more technical question: how bad is =
not to=20
check for key uniqueness? does anyone know about problems arising from =
this=20
situation?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D741553517-15042004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D741553517-15042004>Thanks=20
in advance,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D741553517-15042004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D741553517-15042004>Miguel=20
Rodriguez</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Bill =
Burns=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Wednesday, April 07, 2004 =
7:43=20
  PM<BR><B>To:</B> Stephen Kent<BR><B>Cc:</B> Miguel Rodriguez;=20
  [email-masked]<BR><B>Subject:</B> Re: key uniqueness in a=20
  PKI<BR><BR></FONT></DIV><FONT face=3DTahoma,sans-serif><FONT =
size=3D2><SPAN=20
  type=3D"cite">Stephen Kent wrote on 4/7/04, 1:39 PM:</SPAN> =
</FONT></FONT>
  <P><FONT face=3DTahoma,sans-serif size=3D2></FONT></P>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin =
solid"=20
  type=3D"cite"><FONT face=3DTahoma,sans-serif size=3D2></FONT>
    <DIV><FONT face=3DTahoma,sans-serif size=3D2>At 10:39 AM -0500 =
4/7/04, Miguel=20
    Rodriguez wrote:</FONT></DIV><FONT face=3DTahoma,sans-serif =
size=3D2></FONT>
    <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial =
size=3D-1>Where can I find=20
      information on key pair uniqueness in a PKI? Is this issue =
discussed in an=20
      RFC?</FONT></BLOCKQUOTE><FONT face=3DTahoma,sans-serif =
size=3D2></FONT>
    <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>I =
will also=20
      appreciate comments on this issue, particularly when considering a =
PKI=20
      with several CAs.</FONT></BLOCKQUOTE><FONT =
face=3DTahoma,sans-serif=20
    size=3D2></FONT>
    <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DTahoma,sans-serif=20
      size=3D2></FONT>&nbsp;</BLOCKQUOTE><FONT face=3DTahoma,sans-serif =
size=3D2></FONT>
    <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial=20
    size=3D-1>Thanks.</FONT></BLOCKQUOTE><FONT face=3DTahoma,sans-serif=20
    size=3D2></FONT>
    <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DTahoma,sans-serif=20
      size=3D2></FONT>&nbsp;</BLOCKQUOTE><FONT face=3DTahoma,sans-serif =
size=3D2></FONT>
    <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial =
size=3D-1>Miguel A=20
      Rodriguez</FONT></BLOCKQUOTE><FONT face=3DTahoma,sans-serif =
size=3D2></FONT>
    <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial=20
    size=3D-1>SeguriData</FONT></BLOCKQUOTE><FONT =
face=3DTahoma,sans-serif=20
    size=3D2></FONT>
    <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial=20
    size=3D-1>Mexico</FONT></BLOCKQUOTE><FONT face=3DTahoma,sans-serif=20
size=3D2></FONT>
    <DIV><FONT face=3DTahoma,sans-serif size=3D2><BR></FONT></DIV><FONT=20
    face=3DTahoma,sans-serif size=3D2></FONT>
    <DIV><FONT face=3DTahoma,sans-serif size=3D2>there is no =
standards-based=20
    requirement that a CA verify that each cert request contain a unique =
public=20
    key, neither globally nor relative to the certs that the CA has =
perviously=20
    issued.&nbsp; A CA might choose to try to make checks relative to =
the certs=20
    it has issued, and for which it still has this info, but there is no =

    requirement to do so in X.509 nor PKIX standards.</FONT></DIV><FONT=20
    face=3DTahoma,sans-serif size=3D2></FONT>
    <DIV><FONT face=3DTahoma,sans-serif size=3D2><BR></FONT></DIV><FONT=20
    face=3DTahoma,sans-serif size=3D2></FONT>
    <DIV><FONT face=3DTahoma,sans-serif =
size=3D2>Steve</FONT></DIV></BLOCKQUOTE><FONT=20
  size=3D2><FONT face=3DTahoma,sans-serif><BR></FONT></FONT><FONT=20
  face=3DTahoma,sans-serif size=3D2><FONT size=3D2>FWIW, there's also a =
mention of=20
  this in the WebTrust for CA's documentation.&nbsp; It's not a =
"requirement"=20
  per se, but they seem to suggest that it's a good idea.&nbsp; =
Nevertheless,=20
  that's a pretty expensive operation to perform...especially as the =
Member base=20
  grows.<BR><BR>bill</FONT></FONT><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0013_01C422E6.899348D0--

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Thu, 15 Apr 2004 10:26:49 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Michael,
Given Dave agrees that cached server responses meets his needs, what
issues are left?

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Tuesday, April 13, 2004 4:04 PM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor,

It seeks to establish a consensus within the WG on this draft
work product.

Mike

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 2:44 PM
To: Michael Myers; Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Mike,
I have no idea what this proposed change seeks to accomplish
other than
defeating the objective on having a reasonable expectation of an
onteropabe standard since it make it totally opaque as to what a
valid
response is.
Trevor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Tuesday, April 13, 2004 11:17 AM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor?

Mike

-----Original Message-----
From: Dave Engberg [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 11:03 AM
To: Michael Myers
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Sounds good.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 2:01 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Dave,

Installation from original distribution media is perfectly
acceptable to
my understanding of "be capable of".

The understanding I wish to achieve is that selectable
functionality (as
defined by "be capable of") is produced, fully tested, and
shipped at
the same time as mandated functionality--versus rapidly writing
the
code, perhaps not testing it too much if at all, and hustling
out a
patch in the context of an emerging threat.

Another way of saying it is that "be capable of" does NOT IMHO
mean
"we'll write, ship and be prepared to support the code when the
marketplace asks for it".

I see that Steve has provided us his opinion.  Can close this
thread
with a consensus to change the relevant MUSTs to "MUST be
capable of"?.

Mike

Date: Wed, 14 Apr 2004 10:32:20 -0400
From: [email-masked]
To: [email-masked]
Subject: WG Last Call: Path Building
Sender: [email-masked]

This message initiates Working Group Last Call for "Certification Path 
Building".  Upon successful completion of WG Last Call, we intend to request 
progression as an Informational track document.  This will be a two week last 
call. That is, Last call will complete on or after April 28.

The document is available at:

 http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt  

Thanks,

Tim Polk

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Wed, 14 Apr 2004 09:28:50 -0400
Importance: Normal
Sender: [email-masked]

I would vote for this be to optional for both the client and the server.
Server should be apply the signature if it wants.

The client should be able to ignore the signature or unsigned responses if
it wants.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Engberg
Sent: Tuesday, April 13, 2004 6:50 PM
To: Trevor Freeman
Cc: Santosh Chokhani; [email-masked]
Subject: Re: Signing Untrusted SCVP?

My wife would disagree with the assertion that I get smarter with time.

Like I said, my company is happy with signed and cached responses as a 
second choice to improve SCVP DPD scalability.

I still believe that some large public deployments would be better off 
deploying true "Untrusted SCVP" servers with no client-trusted keys to 
manage and protect at every server.

If an Untrusted SCVP server's signing key is really important for 
security, then it must be really protected, which is generally tricky 
and expensive.

If an Untrusted SCVP server's signing key is not really important for 
security (i.e. if it is only mitigating one minor waste of client CPU), 
then the solution isn't to cheaply implement insecure keys.  The right 
solution is for a deployer to remove the key to dispel the illusion that 
the server should be "Trusted" as an independent PKI authority.

But we obviously disagree on this point, and I'll defer to the decision 
of the PKIX drafters and magistrates.

Trevor Freeman wrote:
> Dave,
> I hope with time we get smarter. Given weare discusting DPD, which 
> mandated a lage amout of processing, with lots of signatue 
> validations, I don't see any measuable benefit to htat kind of client. 
> Given cached respocnes are now caterd for. What is the problems?

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Tue, 13 Apr 2004 16:03:33 -0700
Importance: Normal
Sender: [email-masked]

Trevor,

It seeks to establish a consensus within the WG on this draft
work product.

Mike

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 2:44 PM
To: Michael Myers; Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Mike,
I have no idea what this proposed change seeks to accomplish
other than
defeating the objective on having a reasonable expectation of an
onteropabe standard since it make it totally opaque as to what a
valid
response is.
Trevor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Tuesday, April 13, 2004 11:17 AM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor?

Mike

-----Original Message-----
From: Dave Engberg [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 11:03 AM
To: Michael Myers
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Sounds good.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 2:01 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Dave,

Installation from original distribution media is perfectly
acceptable to
my understanding of "be capable of".

The understanding I wish to achieve is that selectable
functionality (as
defined by "be capable of") is produced, fully tested, and
shipped at
the same time as mandated functionality--versus rapidly writing
the
code, perhaps not testing it too much if at all, and hustling
out a
patch in the context of an emerging threat.

Another way of saying it is that "be capable of" does NOT IMHO
mean
"we'll write, ship and be prepared to support the code when the
marketplace asks for it".

I see that Steve has provided us his opinion.  Can close this
thread
with a consensus to change the relevant MUSTs to "MUST be
capable of"?.

Mike

Date: Tue, 13 Apr 2004 18:49:32 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Trevor Freeman <[email-masked]>
CC: Santosh Chokhani <[email-masked]>, [email-masked]
Subject: Re: Signing Untrusted SCVP?
Sender: [email-masked]

My wife would disagree with the assertion that I get smarter with time.

Like I said, my company is happy with signed and cached responses as a 
second choice to improve SCVP DPD scalability.

I still believe that some large public deployments would be better off 
deploying true "Untrusted SCVP" servers with no client-trusted keys to 
manage and protect at every server.

If an Untrusted SCVP server's signing key is really important for 
security, then it must be really protected, which is generally tricky 
and expensive.

If an Untrusted SCVP server's signing key is not really important for 
security (i.e. if it is only mitigating one minor waste of client CPU), 
then the solution isn't to cheaply implement insecure keys.  The right 
solution is for a deployer to remove the key to dispel the illusion that 
the server should be "Trusted" as an independent PKI authority.

But we obviously disagree on this point, and I'll defer to the decision 
of the PKIX drafters and magistrates.

Trevor Freeman wrote:
> Dave,
> I hope with time we get smarter. Given weare discusting DPD, which
> mandated a lage amout of processing, with lots of signatue validations,
> I don't see any measuable benefit to htat kind of client. Given cached
> respocnes are now caterd for. What is the problems?

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Intel killed the smart ID-card
Date: Tue, 13 Apr 2004 22:06:21 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0175_01C421A3.8DFA8D50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: Intel killed the smart ID-cardSteve,

IMO you should rather be happy as this means that the technology you =
have been preaching about since ages ago, may finally become mainstream. =
 Yes, it will also bring new life to "indirect" PKI schemes like SAML =
and 3D Secure, but I believe this is just fine.

The only major reason why smart cards may be more secure than mobile =
phones (here not including physical attacks on the chips) is that they =
are so powerless in comparison to the latter.=20

Talking about security:  How secure is it really to use PIN-codes in =
public or unknown PCs?  Using the described concept, PIN-codes never =
leave your trusted device.

Assume you are on a the road and don't bring your laptop around, where =
would you be able to use your smart ID card?  Probably nowhere.  Using =
mobile phones as "carriers", you are much more likely to have the ID =
(and be able to use it) when you actually need it.

Smart ID cards will indeed survive, but only in the DoD and similar =
places where it is OK to burn any amount of tax-payer money in the name =
of the nation.

The smart card vendors have had ample of time to launch a ubiquitous PKI =
card and free software but they didn't.  Now it is "harvest time" :-)

Anders

  ----- Original Message -----=20
  From: Stephen Kent=20
  To: Anders Rundgren=20
  Cc: [email-masked]=20
  Sent: Tuesday, April 13, 2004 19:02
  Subject: Re: Intel killed the smart ID-card

  At 5:44 PM +0200 4/13/04, Anders Rundgren wrote:
    From a recent Intel pressrelease:

    The Intel PXA27x family of processors, formerly code-named =
"Bulverde," adds a number of new technologies to address the needs of =
cell phone and PDA users. It is the first product to integrate the Intel =
Wireless MMX technology, providing additional performance for 3-D games =
and advanced video while improving battery-life. The new chip also =
utilizes Wireless Intel SpeedStep technology, enabling significant power =
savings by intelligently managing voltage and frequency changes similar =
to the technology used in the company=B4s notebook processors.

    Also for the first time, Intel has integrated important security =
features through its Intel Wireless Trusted Platform to provide services =
such as trusted boot, secure storage of private information and =
cryptographic keys, and support for common security protocols.

-------------------------------------------------------------------------=
---

    If you have a device that you already use extensively for other =
purposes, that can connect to various services including to local PCs =
using WLAN, and this device has a processor of the type above, why would =
you ever want a smart ID card that only supports a fraction of the other =
device's ID-related use-cases?

  maybe because a smart card is less likely to be corrupted by e-mail =
viruses or the raft of other code that the smart phone is likely to =
process, and because I have less than complete confidence in the folks =
who can't do floating point division properly, to do security properly =
:-)

  Steve
------=_NextPart_000_0175_01C421A3.8DFA8D50
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: Intel killed the smart ID-card</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.2800.1106" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Steve,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>IMO you should rather be happy as this =
means that=20
the technology you have been preaching about since ages ago, may finally =
become=20
mainstream.&nbsp; Yes, it will also bring new life to "indirect" PKI=20
schemes&nbsp;like SAML and 3D Secure, but I believe this is just=20
fine.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The only major reason why smart cards =
<EM>may=20
</EM>be more secure than mobile phones (here not including physical =
attacks on=20
the chips)&nbsp;is that they are so powerless in comparison to the=20
latter.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Talking about security:&nbsp; How =
secure is it=20
really to use PIN-codes in public or unknown PCs?&nbsp; Using the =
described=20
concept, PIN-codes never leave <EM>your</EM> trusted =
device.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Assume you are on a the road and don't =
bring your=20
laptop around, where would you be able to use your smart ID=20
card?&nbsp;&nbsp;Probably nowhere.&nbsp; Using&nbsp;mobile phones as=20
"carriers",&nbsp;you are much more likely to have the ID (and be able to =
use=20
it)&nbsp;when you actually need it.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Smart ID cards will =
indeed&nbsp;survive, but only=20
in the&nbsp;DoD and similar&nbsp;places where it is OK to burn any =
amount of=20
tax-payer money in the name of the nation.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The smart card vendors have had ample =
of time to=20
launch a ubiquitous PKI card and free software but they didn't.&nbsp; =
Now it is=20
"harvest time" :-)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked] href=3D"mailto:[email-masked]">Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Anders Rundgren</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, April 13, 2004 =
19:02</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Intel killed the =
smart=20
  ID-card</DIV>
  <DIV><BR></DIV>
  <DIV>At 5:44 PM +0200 4/13/04, Anders Rundgren wrote:</DIV>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>From =
a recent Intel=20
    pressrelease:</FONT></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>The =
Intel PXA27x=20
    family of processors, formerly code-named "Bulverde," adds a number =
of new=20
    technologies to address the needs of cell phone and PDA users. It is =
the=20
    first product to integrate the Intel Wireless MMX technology, =
providing=20
    additional performance for 3-D games and advanced video while =
improving=20
    battery-life. The new chip also utilizes Wireless Intel SpeedStep=20
    technology, enabling significant power savings by intelligently =
managing=20
    voltage and frequency changes similar to the technology used in the=20
    company=B4s notebook processors.<BR><BR><FONT =
color=3D#0000ff><B>Also for the=20
    first time, Intel has integrated important security features through =
its=20
    Intel Wireless Trusted Platform to provide services such as trusted =
boot,=20
    secure storage of private information and cryptographic keys, and =
support=20
    for common security protocols.</B></FONT></FONT></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite">
    <HR>
  </BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>If =
you have a=20
    device that you already use extensively&nbsp;for other purposes, =
that can=20
    connect to various services including to local PCs&nbsp;using WLAN, =
and this=20
    device has a processor of the type above, why would you ever want a =
smart ID=20
    card that only supports a fraction of the other device's ID-related=20
    use-cases?</FONT></BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>maybe because a smart card is less likely to be corrupted by =
e-mail=20
  viruses or the raft of other code that the smart phone is likely to =
process,=20
  and because I have less than complete confidence in the folks who =
can't do=20
  floating point division properly, to do security properly :-)</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0175_01C421A3.8DFA8D50--

From: "Michael Myers" <[email-masked]>
To: "Dave Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Tue, 13 Apr 2004 11:17:11 -0700
Importance: Normal
Sender: [email-masked]

Trevor?

Mike

-----Original Message-----
From: Dave Engberg [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 11:03 AM
To: Michael Myers
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Sounds good.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 2:01 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Dave,

Installation from original distribution media is perfectly
acceptable to
my understanding of "be capable of".

The understanding I wish to achieve is that selectable
functionality (as
defined by "be capable of") is produced, fully tested, and
shipped at
the same time as mandated functionality--versus rapidly writing
the
code, perhaps not testing it too much if at all, and hustling
out a
patch in the context of an emerging threat.

Another way of saying it is that "be capable of" does NOT IMHO
mean
"we'll write, ship and be prepared to support the code when the
marketplace asks for it".

I see that Steve has provided us his opinion.  Can close this
thread
with a consensus to change the relevant MUSTs to "MUST be
capable of"?.

Mike

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Tue, 13 Apr 2004 14:02:59 -0400
From: "Dave Engberg" <[email-masked]>
To: "Michael Myers" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Sounds good.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Tuesday, April 13, 2004 2:01 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Dave,

Installation from original distribution media is perfectly acceptable to
my understanding of "be capable of".

The understanding I wish to achieve is that selectable functionality (as
defined by "be capable of") is produced, fully tested, and shipped at
the same time as mandated functionality--versus rapidly writing the
code, perhaps not testing it too much if at all, and hustling out a
patch in the context of an emerging threat.

Another way of saying it is that "be capable of" does NOT IMHO mean
"we'll write, ship and be prepared to support the code when the
marketplace asks for it".

I see that Steve has provided us his opinion.  Can close this thread
with a consensus to change the relevant MUSTs to "MUST be capable of"?.

Mike

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Tue, 13 Apr 2004 11:00:41 -0700
Importance: Normal
Sender: [email-masked]

Dave,

Installation from original distribution media is perfectly
acceptable to my understanding of "be capable of".

The understanding I wish to achieve is that selectable
functionality (as defined by "be capable of") is produced, fully
tested, and shipped at the same time as mandated
functionality--versus rapidly writing the code, perhaps not
testing it too much if at all, and hustling out a patch in the
context of an emerging threat.

Another way of saying it is that "be capable of" does NOT IMHO
mean "we'll write, ship and be prepared to support the code when
the marketplace asks for it".

I see that Steve has provided us his opinion.  Can close this
thread with a consensus to change the relevant MUSTs to "MUST be
capable of"?.

Mike

-----Original Message-----
From: David Engberg
Sent: Tuesday, April 13, 2004 4:17 AM

Yes.  Is that allowable?

CoreStreet's OCSP server software can either be deployed in a
traditional 1-tier configuration (all online servers have
signing keys)
or a 2-tier configuration (master servers have keys, lightweight
responders have no keys or any code for signing).

I'm just curious whether your language would permit SCVP
software that
not only allowed those two configurations, but also allowed a
third
configuration where only the lightweight responders (with no
keys or
signing code) were deployed.  The complete software offering is
"capable
of" producing signatures, but the code running on servers in
that third
deployment would not be capable.

Michael Myers wrote:
> Dave,
>
> Do you mean by "removed" that a local administrator may choose
> not to install DPD signing?
>
> Mike
>
> From: David Engberg [mailto:[email-masked]]
> Sent: Monday, April 12, 2004 7:45 PM
>
> A software product includes a module for performing signatures
> on SCVP responses, but an administrator deploys the software
> with that module disabled or removed.  That software product
> would still be compliant because the software is capable of
> performing signatures even though the server instance is.

Date: Tue, 13 Apr 2004 12:54:36 -0400
To: David Engberg <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Signing Untrusted SCVP?
Cc: Michael Myers <[email-masked]>, [email-masked]
Sender: [email-masked]

Dave,

In essentially all IETF standards we focus on what software must be 
capable of doing, so that users and administrators are afforded the 
opportunity to configure a compliant product to enable interoperation 
between peers or clients and servers, or whatever.

I don't see a meaningful difference between the two sorts of 
configuration options you described. Both represent reasonable ways 
to allow the local user/admin to be able to interoperate, as desired.

Steve

Date: Tue, 13 Apr 2004 13:02:52 -0400
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Intel killed the smart ID-card
Cc: <[email-masked]>
Sender: [email-masked]

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

At 5:44 PM +0200 4/13/04, Anders Rundgren wrote:
>From a recent Intel pressrelease:
>
>The Intel PXA27x family of processors, formerly=20
>code-named "Bulverde," adds a number of new=20
>technologies to address the needs of cell phone=20
>and PDA users. It is the first product to=20
>integrate the Intel Wireless MMX technology,=20
>providing additional performance for 3-D games=20
>and advanced video while improving battery-life.=20
>The new chip also utilizes Wireless Intel=20
>SpeedStep technology, enabling significant power=20
>savings by intelligently managing voltage and=20
>frequency changes similar to the technology used=20
>in the company=B4s notebook processors.
>
>Also for the first time, Intel has integrated=20
>important security features through its Intel=20
>Wireless Trusted Platform to provide services=20
>such as trusted boot, secure storage of private=20
>information and cryptographic keys, and support=20
>for common security protocols.
>
>
>If you have a device that you already use=20
>extensively for other purposes, that can connect=20
>to various services including to local PCs using=20
>WLAN, and this device has a processor of the=20
>type above, why would you ever want a smart ID=20
>card that only supports a fraction of the other=20
>device's ID-related use-cases?

maybe because a smart card is less likely to be=20
corrupted by e-mail viruses or the raft of other=20
code that the smart phone is likely to process,=20
and because I have less than complete confidence=20
in the folks who can't do floating point division=20
properly, to do security properly :-)

Steve
--============_-1130246439==_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: Intel killed the smart
ID-card</title></head><body>
<div>At 5:44 PM +0200 4/13/04, Anders Rundgren wrote:</div>
<blockquote type=3D"cite" cite><font face=3D"Arial" size=3D"-1">From a
recent Intel pressrelease:</font></blockquote>
<blockquote type=3D"cite" cite>&nbsp;</blockquote>
<blockquote type=3D"cite" cite><font face=3D"Arial" size=3D"-1">The Intel
PXA27x family of processors, formerly code-named &quot;Bulverde,&quot;
adds a number of new technologies to address the needs of cell phone
and PDA users. It is the first product to integrate the Intel Wireless
MMX technology, providing additional performance for 3-D games and
advanced video while improving battery-life. The new chip also
utilizes Wireless Intel SpeedStep technology, enabling significant
power savings by intelligently managing voltage and frequency changes
similar to the technology used in the company=B4s notebook
processors.<br>
<br>
<font color=3D"#0000FF"><b>Also for the first time, Intel has integrated
important security features through its Intel Wireless Trusted
Platform to provide services such as trusted boot, secure storage of
private information and cryptographic keys, and support for common
security protocols.</b></font></font></blockquote>
<blockquote type=3D"cite" cite>&nbsp;</blockquote>
<blockquote type=3D"cite" cite>
<hr></blockquote>
<blockquote type=3D"cite" cite><font face=3D"Arial" size=3D"-1">If you have
a device that you already use extensively&nbsp;for other purposes,
that can connect to various services including to local PCs&nbsp;using
WLAN, and this device has a processor of the type above, why would you
ever want a smart ID card that only supports a fraction of the other
device's ID-related use-cases?</font></blockquote>
<div><br></div>
<div>maybe because a smart card is less likely to be corrupted by
e-mail viruses or the raft of other code that the smart phone is
likely to process, and because I have less than complete confidence in
the folks who can't do floating point division properly, to do
security properly :-)</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1130246439==_ma============--

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Intel killed the smart ID-card
Date: Tue, 13 Apr 2004 17:44:38 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

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

>From a recent Intel pressrelease:

The Intel PXA27x family of processors, formerly code-named "Bulverde," =
adds a number of new technologies to address the needs of cell phone and =
PDA users. It is the first product to integrate the Intel Wireless MMX =
technology, providing additional performance for 3-D games and advanced =
video while improving battery-life. The new chip also utilizes Wireless =
Intel SpeedStep technology, enabling significant power savings by =
intelligently managing voltage and frequency changes similar to the =
technology used in the company=B4s notebook processors.=20

Also for the first time, Intel has integrated important security =
features through its Intel Wireless Trusted Platform to provide services =
such as trusted boot, secure storage of private information and =
cryptographic keys, and support for common security protocols.

-------------------------------------------------------------------------=
-------

If you have a device that you already use extensively for other =
purposes, that can connect to various services including to local PCs =
using WLAN, and this device has a processor of the type above, why would =
you ever want a smart ID card that only supports a fraction of the other =
device's ID-related use-cases?

-------------------------------------------------------------------------=
-------

------=_NextPart_000_023D_01C4217E.FDE118C0
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>From a recent Intel =
pressrelease:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The Intel PXA27x family of processors, =
formerly=20
code-named "Bulverde," adds a number of new technologies to address the =
needs of=20
cell phone and PDA users. It is the first product to integrate the Intel =

Wireless MMX technology, providing additional performance for 3-D games =
and=20
advanced video while improving battery-life. The new chip also utilizes =
Wireless=20
Intel SpeedStep technology, enabling significant power savings by =
intelligently=20
managing voltage and frequency changes similar to the technology used in =
the=20
company=B4s notebook processors. <BR><BR><FONT =
color=3D#0000ff><STRONG>Also for the=20
first time, Intel has integrated important security features through its =
Intel=20
Wireless Trusted Platform to provide services such as trusted boot, =
secure=20
storage of private information and cryptographic keys, and support for =
common=20
security protocols.</STRONG></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<HR>
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>If you have a device that you already =
use=20
extensively&nbsp;for other purposes, that can connect to various =
services=20
including to local PCs</FONT><FONT face=3DArial size=3D2>&nbsp;using =
WLAN, and this=20
device has a processor of the type above, why would you ever want a =
smart ID=20
card that only supports a fraction of the other device's ID-related=20
use-cases?</FONT><FONT face=3DArial size=3D2></DIV>
<DIV>
<HR>
</DIV></FONT></BODY></HTML>

------=_NextPart_000_023D_01C4217E.FDE118C0--

Date: Tue, 13 Apr 2004 15:12:00 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Sender: [email-masked]

Santoni Adriano wrote:

> Well, it turns out that - despite the topic has been debated in the 
> past - there is not much consense on the "true" intepretation of RFC 
> 3280, §4.1.2.4. The sentence " all certificates issued after December 
> 31, 2003 MUST use the UTF8String encoding of DirectoryString (except 
> as noted below) " is a prescriptive one, if I am not mistaken.
>  
> Nontheless, Glassey says "you have to do so, full-stop", while Gutman 
> and Desperrier says "you'd better not" because  a) some application 
> would not handle UTF-8 properly and b) the CA should not "alter" the 
> name if a certificate already exists for the same subject.

I feel I have to say my post was not at all an interpretation of the 
meaning of RFC3280, and I did not intend to say that part of RFC3280 is 
not prescriptive.
It was just a remark about the state of current applications.
They are other aspects of RFC3280 that are certainly no more well 
supported in practice.

This said, AFAIR when the topic was debated in the past, it was 
concluded that renewal cert were one of the "except as noted below" case.

> Regarding point a), I personally agree that some applications will not 
> behave properly when encountering UTF8Strings, but that should have 
> been taken into account when drafting RFC 3280, not today!

That part of RFC3280 was copied without any change (and I strongly 
suspect without discussion, or rereading) from RFC2459.

At the time RFC2459 was drafted, 2003 was far in the future, and the 
redactors surely hoped UTF8String would be widely in use before the 
deadline, so that this deadline would not be much a constraint.

> I am sure many of you have noticed that most CAs (all over the planet) 
> claiming conformance to RFC3280 have not started issuing certificates 
> with subject names encoded as UTF8String, after 31 december 2003. I 
> dare to say one of the reasons might be a little ambiguity in RFC 3280 
> and probably insufficient debate on this specific topic.

I'm not sure the problem is due to any ambiguity in RFC3280.
I think some of the problem might be related to few people really trying 
to implement RFC3280 fully and carefully, many just implementing support 
for what they see the most often in use. If there is no UTF-8 around, 
they don't do it, and therefore nobody starts doing it.

I'm afraid all what one can hope is that some people will start to 
implement it because it's written in the RFC, will meet interoperability 
problems, will tell other implementors they are the one who don't 
respect the norm, and the other implementators will progressively 
correct any problem related to that in their code.
I now think expecting implementors to prepare for the future, or 
beginning to implement something until they are forced to is a lost 
cause, so the prescriptive aspect of RFC3280, and the fact applying it 
will break a few things, is a good thing if we really want certificates 
to support internationalization one day.

What I also think in relation to that is that there should be a 
normalized, pkix approved test suite for RFC3280 as complete as possible 
so that it would be very easy to ask anybody claiming RFC3280 
conformance what the result of the test suite is.

Date: Tue, 13 Apr 2004 07:16:49 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: Signing Untrusted SCVP?
Sender: [email-masked]

Yes.  Is that allowable?

CoreStreet's OCSP server software can either be deployed in a 
traditional 1-tier configuration (all online servers have signing keys) 
or a 2-tier configuration (master servers have keys, lightweight 
responders have no keys or any code for signing).

I'm just curious whether your language would permit SCVP software that 
not only allowed those two configurations, but also allowed a third 
configuration where only the lightweight responders (with no keys or 
signing code) were deployed.  The complete software offering is "capable 
of" producing signatures, but the code running on servers in that third 
deployment would not be capable.

Michael Myers wrote:
> Dave,
> 
> Do you mean by "removed" that a local administrator may choose
> not to install DPD signing?
> 
> Mike
> 
> From: David Engberg [mailto:[email-masked]]
> Sent: Monday, April 12, 2004 7:45 PM
> 
> A software product includes a module for performing signatures
> on SCVP
> responses, but an administrator deploys the software with that
> module
> disabled or removed.  That software product would still be
> compliant
> because the software is capable of performing signatures even
> though the
> server instance is not ... (?)
> 
> Or is there a subtle difference between configuration vs. code?
> I.e.
> would it be ok to turn off signing in an XML file, but not ok to
> do so
> by installing only half of a complete DPD/DPV suite?
> 
> 

Date: Tue, 13 Apr 2004 12:56:13 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: scvp
Sender: [email-masked]

SCVP 14:
 3.4 Requestor 
   
  The OPTIONAL requestor item is a reference local to the requestor. 
  The value is only of local significance to the requestor.  If the 
  SCVP client includes a requestor value in the request, then the 
  SCVP server MUST return the same value in a unique SCVP response. 
  The SCVP server MAY omit the requestor value from cached SCVP 
  responses. 

SCVP 13: 

  The OPTIONAL requestor item is a reference local to the requestor. 
  The value is only of local significance to the requestor.  If the 
  SCVP client includes a requestor value in the request, then the 
  SCVP server MUST return the same value in the response. 

As far as I remember, there was no discussion about this. 

I think that the following sentence of 4.6 does not respect the
requirements. 

 4.6 Requestor 
   
  The OPTIONAL requestor item is used to identify the requestor.  The 
  value is only of local significance to the requestor. 

requirements say:

   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response.  Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy.  The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response.

IMO this clearly indicates that the identifier has a meaning for the
server.

Unless I have overlooked something, I have not seen any response
to the following.  Maybe the content of my message considered
as pure nonsense.

Date: Tue Oct 28 18:43:58 2003
To: [email-masked], [email-masked], [email-masked]
Subject: RE: SCVP additions

hello,

It would be nice to hear whether all or which comments
about SCVP have been addressed. Unless I have overlooked
something, my remarks about the definitions of requestor
and responder have not received any treatment. 

I simplify the content of my comments:

requestor and responder should be GENERALNAMES which
indicate and identify in global the partipating parties.  

IMO Using arbitrary octets with only LOCAL significance
is not compatible with the procedure to detect loops.

4.6 indicates the there MUST NOt be null characters,
something which is explicitly allowed for a server
acting as a relay.

What is the sense of 4.7? The responder field is
never used anywhere in the actual protocol, what
is the meaning of such an opaque value?

4.8.5 What is the reason of having an additional octet string
encapsulation instead of an any defined by construct? Is it
that some tools may break decodeing when they find an OID
that is not known? If so, whay are there ANY DEFINED BYs at
other places?

can someone indicate me how a relay would return the response
of the next server to a client as part of his response?

regards

Date: Tue, 13 Apr 2004 11:43:34 +0200 (CEST)
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Tue, 13 Apr 2004 08:42:40 +0200, Santoni Adriano <[email-masked]> said:

adriano.santoni> Regarding point a), I personally agree that some
adriano.santoni> applications will not behave properly when
adriano.santoni> encountering UTF8Strings, but that should have been
adriano.santoni> taken into account when drafting RFC 3280, not today!

A question, what does X.509 say about this?  It may be that some
people confuse X.509 with RFC3280, thinking they are interchangeable
(they seem to be, more or less, at least last time I looked at the
ASN.1 module).

Having X.509 and RFC3280 differ on this point may be another cause for
confusion...

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

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: Santoni Adriano <[email-masked]>
To: "'todd glassey'" <[email-masked]>, [email-masked], "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Tue, 13 Apr 2004 08:42:40 +0200
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_01C42122.84780F13
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Well, it turns out that - despite the topic has been debated in the =
past -
there is not much consense on the "true" intepretation of RFC 3280,
=C2=A74.1.2.4. The sentence "all certificates issued after December 31, =
2003 MUST
use the UTF8String encoding of DirectoryString (except as noted below)" =
is a
prescriptive one, if I am not mistaken.
=20
Nontheless, Glassey says "you have to do so, full-stop", while Gutman =
and
Desperrier says "you'd better not" because  a) some application would =
not
handle UTF-8 properly and b) the CA should not "alter" the name if a
certificate already exists for the same subject.
=20
Regarding point a), I personally agree that some applications will not
behave properly when encountering UTF8Strings, but that should have =
been
taken into account when drafting RFC 3280, not today!=20
=20
Regarding point b), I think the problem may largely vary depending on
specific circumstances. It depends very much on what the user asks and =
pays
for, and what the CA offers (only certificates or software as well?) =
and
claims (e.g. interoperability?).
=20
I am sure many of you have noticed that most CAs (all over the planet)
claiming conformance to RFC3280 have not started issuing certificates =
with
subject names encoded as UTF8String, after 31 december 2003. I dare to =
say
one of the reasons might be a little ambiguity in RFC 3280 and probably
insufficient debate on this specific topic.=20
=20
AS
=20

-----Messaggio originale-----
Da: todd glassey [mailto:[email-masked]]=20
Inviato: venerd=C3=AC 9 aprile 2004 15.32
A: Santoni Adriano; [email-masked]
Cc: [email-masked]
Oggetto: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs

Peter - Santoni, the RFC is the RFC and it says MUST, and it addresses =
the
NameRollover issues as well with commentary about=20
=20
      (a)  CAs MAY issue "name rollover" certificates to support an
      orderly migration to UTF8String encoding.  Such certificates =
would
      include the CA's UTF8String encoded name as issuer and and the =
old
      name encoding as subject, or vice-versa.

... http://www.faqs.org/rfcs/rfc3280.html
<http://www.faqs.org/rfcs/rfc3280.html>=20
=20
So my reading is that UTF8 is not optional.
=20
Todd Glassey
=20

----- Original Message -----=20
From: Santoni Adriano <mailto:[email-masked]> =20
To: [email-masked]' <mailto:[email-masked]'> =20
Cc: [email-masked] <mailto:[email-masked]> =20
Sent: Friday, April 09, 2004 3:35 AM
Subject: R: RFC3280: doubt on the use of UTF8String in encoding RDNs

Thanks for replying, although it seems a reply to another question (my
fault, I presume).=20

I was referring to new certificates, issued "from today on" (so to =
speak).=20

As a CA, we do not handle DNs "encoded by the originator"; which
"originator" at any rate?=20

We register people, collecting their own true names, and then we build =
the
DNs to be inserted into certificates. The names can be e.g. the =
ASCII-safe
name "Peter Gutman", or the polish name "Anna Kr=C4=99glewska", or the =
greek
"=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83 =
=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83=
" or whatever else - can you read? :-). In the case of
your name, a PrintableString would be "safe", as it would retain all =
the
original information. In the latter cases, it would not and so it makes =
more
sense to use Unicode encoded as UTF8String.

Maybe I am just not getting what you mean...=20

Adriano=20

-----Messaggio originale-----=20
Da: pgut001 [ <mailto:[email-masked]>
mailto:[email-masked]] Per conto di
[email-masked]=20
Inviato: mercoled=C3=AC 7 aprile 2004 15.55=20
A: [email-masked]; [email-masked]=20
Oggetto: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs=20

Santoni Adriano <[email-masked]> writes:=20

>I am probably asking an old question, so ... please be patient.=20
>=20
>Rfc3280 states (<A7>4.1.2.4): "...all certificates issued after=20
>December 31, 2003 MUST use the UTF8String encoding of=20
>DirectoryString...".=20
>=20
>Does that mean that it is mandatory to always encode all RDNs (having =
a=20
>type of DirectoryString) of the issuer and subject (and still other)=20
>certificate fields as UTF8Strings _even if they could be correctly=20
>encoded as a PrintableStrings_ ?=20

Hmm, see the previous thread on this a few months ago... in theory =
you're
supposed to do this, but that violates the primary rule of DN encoding,
which is "Never change the DN once it's been encoded by the =
originator".  If
you break that rule, you get to discover all the apps that reject =
re-encoded
DNs. If you're lucky, this will happen before your product ships and =
not
after.

Peter.=20

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

SIA S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio =
e-mail.=20

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

SIA S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof.=20

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

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

------_=_NextPart_001_01C42122.84780F13
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana =
color=3D#0000ff>Well, it=20
turns out that - despite the topic has been debated in the past - there =
is not=20
much consense on the "true" intepretation of RFC 3280, =C2=A74.1.2.4. =
The sentence=20
"<FONT color=3D#000000>all certificates issued after December 31, 2003 =
MUST use=20
the UTF8String encoding of DirectoryString (except as noted =
below)</FONT>" is a=20
prescriptive one, if I am not mistaken.</FONT></SPAN></DIV>
<DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana =
color=3D#0000ff>Nontheless,=20
Glassey says "you have to do so, full-stop", while Gutman and =
Desperrier says=20
"you'd better not" because&nbsp; </FONT></SPAN><SPAN=20
class=3D215471806-13042004><FONT face=3DVerdana color=3D#0000ff>a) some =
application=20
would not handle UTF-8 properly and </FONT></SPAN><SPAN=20
class=3D215471806-13042004><FONT face=3DVerdana color=3D#0000ff>b) the =
CA should not=20
"alter" the name if a certificate already exists for the same=20
subject.</FONT></SPAN></DIV>
<DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana =
color=3D#0000ff>Regarding=20
point a), I personally agree that some applications will not behave =
properly=20
when encountering UTF8Strings, but that should have been taken into =
account when=20
drafting RFC 3280, not today! </FONT></SPAN></DIV>
<DIV><SPAN class=3D215471806-13042004></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D215471806-13042004></SPAN><SPAN =
class=3D215471806-13042004><FONT=20
face=3DVerdana color=3D#0000ff><SPAN class=3D215471806-13042004><FONT =
face=3DVerdana=20
color=3D#0000ff>Regarding point b), I think the problem may largely =
vary depending=20
on specific circumstances</FONT></SPAN></FONT></SPAN><SPAN=20
class=3D215471806-13042004><FONT face=3DVerdana color=3D#0000ff><SPAN=20
class=3D215471806-13042004><FONT face=3DVerdana color=3D#0000ff>. It =
depends very much=20
on what the user asks and pays for, and what the CA offers (only =
certificates or=20
software as well?) and claims (e.g.=20
interoperability?).</FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana =
color=3D#0000ff><SPAN=20
class=3D215471806-13042004></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana =
color=3D#0000ff><SPAN=20
class=3D215471806-13042004>I am sure many of you have noticed =
that&nbsp;most CAs=20
(all over the planet) claiming conformance to RFC3280 have not started =
issuing=20
certificates with subject names encoded as UTF8String, after 31 =
december 2003. I=20
dare to say one of the reasons might be a little ambiguity in RFC 3280 =
and=20
probably insufficient debate on this specific=20
topic.&nbsp;</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana =
color=3D#0000ff><SPAN=20
class=3D215471806-13042004></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana =
color=3D#0000ff><SPAN=20
class=3D215471806-13042004>AS</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D215471806-13042004><FONT face=3DVerdana=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Dit dir=3Dltr =
align=3Dleft><FONT face=3DTahoma=20
  size=3D2>-----Messaggio originale-----<BR><B>Da:</B> todd glassey=20
  [mailto:[email-masked]] <BR><B>Inviato:</B> =
venerd=C3=AC 9 aprile=20
  2004 15.32<BR><B>A:</B> Santoni Adriano;=20
  [email-masked]<BR><B>Cc:</B> [email-masked]<BR><B>Oggett=
o:</B>=20
  Re: RFC3280: doubt on the use of UTF8String in encoding=20
  RDNs<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Peter - Santoni, the RFC is the RFC =
and it says=20
  MUST, and it addresses the NameRollover issues as well with =
commentary about=20
  </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; CAs =
MAY issue=20
  "name rollover" certificates to support =
an<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  orderly migration to UTF8String encoding.&nbsp; Such certificates=20
  would<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include the CA's UTF8String =
encoded=20
  name as issuer and and the old<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; name =
encoding=20
  as subject, or vice-versa.<BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>... <A=20
  =
href=3D"http://www.faqs.org/rfcs/rfc3280.html">http://www.faqs.org/rfcs/=
rfc3280.html</A></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>So my reading is that UTF8 is not=20
  optional.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Todd Glassey</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=[email-masked]=20
    href=3D"mailto:[email-masked]">Santoni Adriano</A> =
</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
    =
href=3D"mailto:[email-masked]'">[email-masked]'<=
/A>=20
    </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, April 09, 2004 =
3:35=20
    AM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> R: RFC3280: doubt =
on the use=20
    of UTF8String in encoding RDNs</DIV>
    <DIV><BR></DIV>
    <P><FONT face=3DVerdana color=3D#0000ff>Thanks for replying, =
although it seems a=20
    reply to another question (my fault, I presume). </FONT></P>
    <P><FONT face=3DVerdana color=3D#0000ff>I was referring to new =
certificates,=20
    issued "from today on" (so to speak). </FONT></P>
    <P><FONT face=3DVerdana color=3D#0000ff>As a CA, we do not handle =
DNs "encoded=20
    by the originator"; which "originator" at any rate? </FONT></P>
    <P><FONT face=3DVerdana color=3D#0000ff>We register people, =
collecting their own=20
    true names, and then we build the DNs to be inserted into =
certificates. The=20
    names can be e.g. the ASCII-safe name "Peter Gutman", or the polish =
name=20
    "Anna Kr</FONT><FONT face=3DVerdana =
color=3D#0000ff>=C4=99glewska</FONT><FONT=20
    face=3DVerdana color=3D#0000ff>", or the greek "</FONT><FONT =
face=3DVerdana=20
    color=3D#0000ff>=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83 =
=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83=
</FONT><FONT face=3DVerdana color=3D#0000ff>"=20
    or whatever else - can you read? :-). In the case of your name, a=20
    PrintableString would be "safe", as it would retain all the =
original=20
    information. In the latter cases, it would not and so it makes more =
sense to=20
    use Unicode encoded as UTF8String.</FONT></P>
    <P><FONT face=3DVerdana color=3D#0000ff>Maybe I am just not getting =
what you=20
    mean...</FONT> </P>
    <P><FONT face=3DVerdana color=3D#0000ff>Adriano</FONT> </P><BR>
    <P><FONT face=3DArial size=3D2>-----Messaggio originale-----</FONT> =
<BR><FONT=20
    face=3DArial size=3D2>Da: pgut001 [</FONT><A=20
    href=3D"mailto:[email-masked]"><U><FONT =
face=3DArial=20
    color=3D#0000ff=20
    =
size=3D2>mailto:[email-masked]</FONT></U></A><FONT=20
    face=3DArial size=3D2>] Per conto di =
[email-masked]</FONT> <BR><FONT=20
    face=3DArial size=3D2>Inviato: mercoled=C3=AC 7 aprile 2004 =
15.55</FONT> <BR><FONT=20
    face=3DArial size=3D2>A: [email-masked]; =
[email-masked]</FONT>=20
    <BR><FONT face=3DArial size=3D2>Oggetto: Re: RFC3280: doubt on the =
use of=20
    UTF8String in encoding RDNs</FONT> </P><BR>
    <P><FONT face=3DArial size=3D2>Santoni Adriano=20
    &lt;[email-masked]&gt; writes:</FONT> </P>
    <P><FONT face=3DArial size=3D2>&gt;I am probably asking an old =
question, so ...=20
    please be patient.</FONT> <BR><FONT face=3DArial =
size=3D2>&gt;</FONT> <BR><FONT=20
    face=3DArial size=3D2>&gt;Rfc3280 states (&lt;A7&gt;4.1.2.4): =
"...all=20
    certificates issued after </FONT><BR><FONT face=3DArial =
size=3D2>&gt;December=20
    31, 2003 MUST use the UTF8String encoding of </FONT><BR><FONT =
face=3DArial=20
    size=3D2>&gt;DirectoryString...".</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;</FONT> <BR><FONT face=3DArial size=3D2>&gt;Does that =
mean that it is=20
    mandatory to always encode all RDNs (having a </FONT><BR><FONT =
face=3DArial=20
    size=3D2>&gt;type of DirectoryString) of the issuer and subject =
(and still=20
    other) </FONT><BR><FONT face=3DArial size=3D2>&gt;certificate =
fields as=20
    UTF8Strings _even if they could be correctly </FONT><BR><FONT =
face=3DArial=20
    size=3D2>&gt;encoded as a PrintableStrings_ ?</FONT> </P>
    <P><FONT face=3DArial size=3D2>Hmm, see the previous thread on this =
a few months=20
    ago... in theory you're supposed to do this, but that violates the =
primary=20
    rule of DN encoding, which is "Never change the DN once it's been =
encoded by=20
    the originator".&nbsp; If you break that rule, you get to discover =
all the=20
    apps that reject re-encoded DNs. If you're lucky, this will happen =
before=20
    your product ships and not after.</FONT></P>
    <P><FONT face=3DArial size=3D2>Peter.</FONT> </P><BR>
    <P><FONT face=3DArial size=3D2>*******************Internet Email =
Confidentiality=20
    Footer******************* </FONT><BR><FONT face=3DArial =
size=3D2>Qualsiasi=20
    utilizzo non autorizzato del presente messaggio nonche' dei suoi =
allegati e'=20
    vietato e potrebbe costituire reato. Se lei ha ricevuto =
erroneamente il=20
    presente messaggio, Le saremmo grati se, via e-mail, ce ne =
comunicasse la=20
    ricezione e provvedesse alla distruzione del messaggio stesso e dei =
suoi=20
    eventuali allegati. Le dichiarazioni contenute nel presente =
messaggio=20
    nonche' nei suoi eventuali allegati devono essere attribuite =
esclusivamente=20
    al mittente e non possono essere considerate come trasmesse o =
autorizzate da=20
    SIA S.p.A.; le medesime dichiarazioni non impegnano SIA S.p.A. nei =
confronti=20
    del destinatario o di terzi. </FONT></P>
    <P><FONT face=3DArial size=3D2>SIA S.p.A. non si assume alcuna =
responsabilita'=20
    per eventuali intercettazioni, modifiche o danneggiamenti del =
presente=20
    messaggio e-mail. </FONT></P>
    <P><FONT face=3DArial size=3D2>Any unauthorized use of this e-mail =
or any of its=20
    attachments is prohibited and could constitute an offence. If you =
are not=20
    the intended addressee please advise immediately the sender by =
using the=20
    reply facility in your e-mail software and destroy the message and =
its=20
    attachments. The statements and opinions expressed in this e-mail =
message=20
    are those of the author of the message and do not necessarily =
represent=20
    those of SIA. Besides, The contents of this message shall be =
understood as=20
    neither given nor endorsed by SIA S.p.A.. </FONT></P>
    <P><FONT face=3DArial size=3D2>SIA S.p.A. does not accept liability =
for=20
    corruption, interception or amendment, if any, or the consequences =
thereof.=20
    </FONT></P><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">*******************Internet Email =
Confidentiality Footer******************* </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Qualsiasi utilizzo non autorizzato del =
presente messaggio nonche' dei suoi allegati e' vietato e potrebbe =
costituire reato. Se lei ha ricevuto erroneamente il presente =
messaggio, Le saremmo grati se, via e-mail, ce ne comunicasse la =
ricezione e provvedesse alla distruzione del messaggio stesso e dei =
suoi eventuali allegati. Le dichiarazioni contenute nel presente =
messaggio nonche' nei suoi eventuali allegati devono essere attribuite =
esclusivamente al mittente e non possono essere considerate come =
trasmesse o autorizzate da SIA S.p.A.; le medesime dichiarazioni non =
impegnano SIA S.p.A. nei confronti del destinatario o di terzi. =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">SIA S.p.A. non si assume alcuna =
responsabilita' per eventuali intercettazioni, modifiche o =
danneggiamenti del presente messaggio e-mail. </FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Any unauthorized use of this e-mail or =
any of its attachments is prohibited and could constitute an offence. =
If you are not the intended addressee please advise immediately the =
sender by using the reply facility in your e-mail software and destroy =
the message and its attachments. The statements and opinions expressed =
in this e-mail message are those of the author of the message and do =
not necessarily represent those of SIA. Besides, The contents of this =
message shall be understood as neither given nor endorsed by SIA =
S.p.A.. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">SIA S.p.A. does not accept liability =
for corruption, interception or amendment, if any, or the consequences =
thereof. </FONT></P>
<BR>
<BR>

------_=_NextPart_001_01C42122.84780F13--

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 12 Apr 2004 21:13:32 -0700
Importance: Normal
Sender: [email-masked]

Dave,

Do you mean by "removed" that a local administrator may choose
not to install DPD signing?

Mike

-----Original Message-----
From: David Engberg [mailto:[email-masked]]
Sent: Monday, April 12, 2004 7:45 PM

A software product includes a module for performing signatures
on SCVP
responses, but an administrator deploys the software with that
module
disabled or removed.  That software product would still be
compliant
because the software is capable of performing signatures even
though the
server instance is not ... (?)

Or is there a subtle difference between configuration vs. code?
I.e.
would it be ok to turn off signing in an XML file, but not ok to
do so
by installing only half of a complete DPD/DPV suite?

Date: Mon, 12 Apr 2004 22:44:59 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: Signing Untrusted SCVP?
Sender: [email-masked]

A software product includes a module for performing signatures on SCVP 
responses, but an administrator deploys the software with that module 
disabled or removed.  That software product would still be compliant 
because the software is capable of performing signatures even though the 
server instance is not ... (?)

Or is there a subtle difference between configuration vs. code?  I.e. 
would it be ok to turn off signing in an XML file, but not ok to do so 
by installing only half of a complete DPD/DPV suite?

Michael Myers wrote:
> Dave,
> 
> Please expand "may not deploy with this feature."
> 
> Mike
> 
> 
> 
> From: Dave Engberg
> Sent: Monday, April 12, 2004 2:31 PM
> 
> I assumed that "MUST be capable of" meant that every running
> server
> instance itself must have the ability to perform signatures.  If
> the
> correct interpretation for "capable of" is that the software
> product has
> the capability, but some instances may not deploy with this
> feature,
> then this sounds good to me.
> 
> In short, yes.
> 
> 

From: "Michael Myers" <[email-masked]>
To: "Dave Engberg" <[email-masked]>, <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 12 Apr 2004 19:31:30 -0700
Importance: Normal
Sender: [email-masked]

Dave,

Please expand "may not deploy with this feature."

Mike

-----Original Message-----
From: Dave Engberg
Sent: Monday, April 12, 2004 2:31 PM

I assumed that "MUST be capable of" meant that every running
server
instance itself must have the ability to perform signatures.  If
the
correct interpretation for "capable of" is that the software
product has
the capability, but some instances may not deploy with this
feature,
then this sounds good to me.

In short, yes.

Date: Mon, 12 Apr 2004 20:39:15 -0400
To: "Dave Engberg" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Cc: <[email-masked]>
Sender: [email-masked]

At 5:30 PM -0400 4/12/04, Dave Engberg wrote:
>I assumed that "MUST be capable of" meant that every running server
>instance itself must have the ability to perform signatures.  If the
>correct interpretation for "capable of" is that the software product has
>the capability, but some instances may not deploy with this feature,
>then this sounds good to me.
>
>In short, yes.
>

Dave,

MUST in this context means that it must be possible for the 
user/admin/owner to configure the server to perform the operation, 
not that the server must always be ready to perform the operation 
irrespective of the locally managed configuration.

Steve

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 12 Apr 2004 17:30:48 -0400
From: "Dave Engberg" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I assumed that "MUST be capable of" meant that every running server
instance itself must have the ability to perform signatures.  If the
correct interpretation for "capable of" is that the software product has
the capability, but some instances may not deploy with this feature,
then this sounds good to me.

In short, yes.

-----Original Message-----
From: Michael Myers
Sent: Sat, 10 Apr 2004 15:24:18 -0700
Subject: RE: Signing Untrusted SCVP?

My opinion is that as long as DPD-only servers are capable of signing
responses, I don't see a problem with such servers not shipping with
active key material.  They may not be operationally capable nor deployed
so but would be functionally capable of compliance. The distinction is
that a local security administrator is able to activate DPD signing in
response to emerging threats without recourse to a vendor's software
update.

Date: Mon, 12 Apr 2004 09:55:31 -0400
To: Arshad Noor <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Identity Firewalls - Was: PKI International Consortium
Cc: PKIX list <[email-masked]>
Sender: [email-masked]

At 11:27 PM -0700 4/9/04, Arshad Noor wrote:
>It is unrealistic only if we accept status quo, Steve.  If we change
>the operating conditions - based on reason - then reality changes.
>I don't deny that it is an arduous task - but I do not accept that
>it is impossible.

I would not say that it is impossible, just highly unlikely and not 
very desirable.

I won't bother boring the list with responses to each of your 
comments.  If you believe this is both a feasible and desirable 
outcome, and want to convince others, then you should write papers 
that are peer reviewed and published, to demonstrate that you are not 
alone in this view.  Web pages published by oneself or one's company 
are merely advertisements and warrant no serious consideration in a 
debate like this.

Steve

Date: Sun, 11 Apr 2004 18:43:49 -0400
From: "Brian G. Holmes" <[email-masked]>
Organization: Holmespun Solutions, LLC
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: Decoding Service Support
Sender: [email-masked]

The dumpasn1 tool is similar to the 'decode ber' functionality 
provided by the Berasno service.  The 'decode ber' function provides 
information extracted only from the data; the structure encoded there.

http://www.holmespun.biz/berasno/example/index.html

The Berasno service is capable of providing much more.  Please see the 
examples displayed at the address above.  The 'decode ietf snmp', 
'decode itu tcap', and 'decode gsm map' functions are able to name the 
elements (the TLVs) that are found within the data.

Consider the certs/DSAParametersInheritedCACert.crt certificate from 
NIST's PKITS_data.zip test data file.

Where the 'decode ber' function would tell us that the 0x30 tag at 
offset 4 represents a [UNIVERSAL 16] SEQUENCE, a 'decode x509' 
function would strive to identify that element as an instance of a 
PKIX1Explicit88.Certificate.tbsCertificate.

Where the 'decode ber' function would tell us that the 0xA3 tag at 
offset 349 represents an [APPLICATION 3] SEQUENCE, a 'decode x509' 
function would strive to identify that element as an instance of 
PKIX1Explicit88.Certificate.tbsCertificate.extensions.

As I alluded to in my previous message, the 'decode gsm map' function 
extends the identification of elements from one layer (TCAP) using OID 
information to do the same for a second/nested layer (MAP).  The 
'decode x509' function would likely do the same for certificate 
extensions.

I envision supporting additional input formats, and providing 
additional output formats, to meet the needs of the users of the 
service.  One improvement would see value decoding for primitives 
whose tags are not UNIVERSAL.  Another improvement that I would like 
to introduce would be to produce output using a Basic XER (XML) 
format; a format that may be easier to read than the one currently in use.

BGH

Peter Gutmann wrote:
> "Brian G. Holmes" <[email-masked]> writes:
> 
> 
>>I support a free BER for ASN.1 decoding service known as the Berasno Decoding
>>Service.
> 
> 
> How is this different from something like dumpasn1?
> 
> Peter.
> 

-- 
Holmespun Solutions, LLC
http://www.holmespun.biz
919-844-7713

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: "PKIX list" <[email-masked]>
Subject: SAML/3D Secure vs Kerberos. l PKI International Consortium
Date: Sun, 11 Apr 2004 17:22:32 +0200
Sender: [email-masked]

>i was at a presentation of a vendor SAML product about a year ago that was
>being deployed in a number of institutions. the CTO was presenting all the
>message flows. I made some comment that the message flows looked nearly the
>same as a Kerberos presentation i had sat thru circa 1990. The response was
>that there was just only so many ways that distributed security control
>could be implemented.

This is correct.  Same goes for 3D Secure which is really
very much a dedicated SAML.

What's making these schemes more powerful (in a web-
environment nota bene), than Kerberos is that they build on
XML allowing assertions of any size and semantics.  Web-
browser redirects and ECMA-script-driven auto-POSTs does 
the rest.

Now, what does this has to do with PKI and the Identity
Firewall?  Well, the 3D Secure and SAML credentials
are typically secured by signatures and certificates
operating at "business partner level".   Voila!
The same "level" typically used for leased lines in B2B networks.

The rest is for the PKI community to understand the huge
consequences of (and some day maybe take action on).

Anders

anders rundgre wrote:

What Steve did not mention, is that the authentication and
authorization schemes that are firmly in place since three
decades or so for bank-to-bank and supplier-to-manufacturer
networks, together with recent developmemts like SAML and
3D Secure, will likely forever change how PKI is applied, which
also will affect schemes like the Identity Firewall.

Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Subject: Re:Identity Firewall. l PKI International Consortium
To: "Anders Rundgren" <[email-masked]>
Cc: "Arshad Noor" <[email-masked]>, "PKIX list" <[email-masked]>, "Stephen Kent" <[email-masked]>, [email-masked]
From: [email-masked]
Date: Sun, 11 Apr 2004 08:02:28 -0600
Sender: [email-masked]

i was at a presentation of a vendor SAML product about a year ago that was
being deployed in a number of institutions. the CTO was presenting all the
message flows. I made some comment that the message flows looked nearly the
same as a Kerberos presentation i had sat thru circa 1990. The response was
that there was just only so many ways that distributed security control
could be implemented.

anders rundgre wrote:

What Steve did not mention, is that the authentication and
authorization schemes that are firmly in place since three
decades or so for bank-to-bank and supplier-to-manufacturer
networks, together with recent developmemts like SAML and
3D Secure, will likely forever change how PKI is applied, which
also will affect schemes like the Identity Firewall.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

From: "Anders Rundgren" <[email-masked]>
To: "PKIX list" <[email-masked]>, <[email-masked]>
Subject: Re: Single Identity. Was: PKI International Consortium
Date: Sun, 11 Apr 2004 11:48:41 +0200
Sender: [email-masked]

Shaheen,
May I as a long-term PKIX-list subscriber share some experiences
of what can be successfully discussed/RFCed etc and what does
not seem to work too well?

If we talk about FIs in an international consortium we are probably
into commercial activities. If we assume (this is not a truth, just
an assumption) that existing RFCs are suitable, the IETF does not
form a good foundation for discussing commercial, deployment,
or policy issues.   If you compare such an activity with payment-
networks like VISA, such discussions have been a fairly private
issues for the VISA members.

However, if the goal is a global TTP trust network, I don't
believe that the VISA approach works, as identity is much more
complex (as well as potentially considerably more far-reaching)
than transferring money in a closed payment network.

I would personally like to participate in a development of the
kind you are mentioning, although I believe that the "in scope"
issues are extremely hard as well as politically sensitive.

Here is an non-exhaustive list of issues that have to be dealt with:
1. Who is the relying party?
  Some possible answers: FIs only. FIs + e-govs.  "All", All but FIs(!).
2. Without having a standard card/container, is this really feasible?
3. Business model?
  Some possible answers: Four corner model. 
  Subscriber-based cost model. 
  Mixed model?
4. How to express FI identities?
  Some possible answers: Credit-card-like ID (ffffnnnnnnnnnnnn). 
  National IDs.
  Other.
  multiple credentials (national + CC-like)

Although very interesting and potentially very lucrative, my 
experiences so far with the financial industry, is that they don't
want to work "in open" which IMO is a prerequisite for a
global high-value TTP looking for a billions of customers.
Nothing below that level is going to work as the "brand"
will not be able to survive otherwise.

best regards
Anders

----- Original Message -----
From: <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; "Al Arsenault" <[email-masked]>; <[email-masked]>; "Arshad Noor"
<[email-masked]>; "Terwilliger, Ann" <[email-masked]>; "Eric Norman" <[email-masked]>; "PKIX list"
<[email-masked]>; "Stephen Kent" <[email-masked]>; <[email-masked]>
Sent: Friday, April 09, 2004 23:30
Subject: Re: Single Identity. Was: PKI International Consortium

Hello everyone.

Though new to this group, within a short span I understand there are people
who favor single identity and who does not. I also understand that there is
an effort towards standardizing or centralizing PKI among the Financial
Institutions. One such effort is Identrus. Thanks to some of the members of
this group who helped me with good information. However, moving forward,
can I look forward for a single identity that I can use to identify myself
to any public system that require identification and authentication? If
there is an ongoing effort in this regard, please let me know so that I can
participate.

Regards,

Shaheen Nasirudheen

-----------------------------------
This message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for delivery of this message to the intended
recipient(s), you are hereby notified that any dissemination, distribution
or copying of this message is strictly prohibited.  If you have received
this message in error, please immediately notify the sender and delete this
e-mail message from your computer.

                    "Anders Rundgren"
                    <anders.rundgren@t       To:     "Al Arsenault" <[email-masked]>, "PKIX list"
                    elia.com>                 <[email-masked]>, Shaheen Nasirudheen/JPMCHASE@JPMCHASE
                    Sent by:                 cc:     "Stephen Kent" <[email-masked]>, "Arshad Noor"
                    owner-ietf-pkix@ma        <[email-masked]>, <[email-masked]>, "Terwilliger, Ann"
                    il.imc.org                <[email-masked]>, "Eric Norman" <[email-masked]>
                                             Subject:     Re: Single Identity. Was: PKI International Consortium

                    04/05/2004 09:01
                    AM

AWA:  Speaking from practical experience (having a physical wallet lifted
in Prague a few years back), it was easier NOT having a single credential.
Okay, the wallet with the cash, credit cards, US driver's license, pictures
of the kids, medical insurance card, etc. is gone.  But, NOT the passport,
and not the emergency credit card kept separate from the rest for exactly
this eventuality.  Survival was assured until recovery could be
accomplished.

AR: In my opinion you are describing something like a "credential backup"
scheme which is pretty unrelated to the single credential issue.  Valid
questions arise, like: Where do you keep the backups? Where would you keep
your electronic IDs when on the road (where you need them)?  It looks to me
that the "always connected" world creates new problems requiring more
robust and universal solutions.   The globally supported trust network is
my shot as this problem.

AWA:  Now, map this to the virtual world, where everything is stored in
your mobile phone.  Whoops - mobile phone is lost/stolen.  So I go to the
nearest branch of the "issuing agency".  The conversation goes something
like Me: "excuse me, my name is Al Arsenault, and my ID was stolen.  I need
a new one".   Agency:  "Prove that's who you are".  Me:  "How?  My one
single ID was stolen, I need a new one".  Agency: "Yes, but if we believed
you based on just what you're telling us, it could deny service to the REAL
Al Arsenault, who our records show is out blithely spending money right
now". (Somebody call John Cleese - there's a great Monty Python skit in
here somewhere.)

AR: This situation is indeed a tricky one.  However, it gets more
manageable when issuers have 24/7 helpdesks which allows the agency to
look-up records and ask you to answer a few questions that only the
original issuer and you have the answers to.  Since agencies have to
authenticate to access external records (or identify themselves to an
issuer helpdesk), a screw-up may lead to the agency's loss of their
license.

AWA:  Yes, there's likely a way to PROVE that I'm the real Al Arsenault,
but I hope it doesn't involve biometrics - don't get me started down that
road. :-(

AR: Biometrics is of indeed a very vital part of such verifications.  Today
this may just be your picture but tomorrow it will be DNA.  Since identity
theft is admittedly the weak spot of the described scheme there are really
no alternatives to biometrics except abandoning the whole thing.  AFAIK the
US immigration authorities require (or are about to require) an extensive
set of biometrics in passports so either we foreigners have to stay at home
or deal with it.

AR: Regarding the value of single identities it is also a matter of cost.
The majority of people work for small businesses and these may find that
using the already existing bank-issued IDs will be easier to use than
putting out user-IDs and passwords.  The identity does not have to be an
SSN, it may be your bank client number or some completely artificial
number.  That is, bank-IDs do not have to "emulate" passports to be useful.

AR: Regarding multiple banks, I agree with you, you should not (mostly for
commercial and political reasons) force a network of TTPs to be direct TTPs
for each other.  So here there will be a deviation from the single ID.
However, you typically only need one "primary ID" for all your TTP-based
ID-relations.

best
AR = Anders Rundgren

From: "Anders Rundgren" <[email-masked]>
To: "Arshad Noor" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "PKIX list" <[email-masked]>
Subject: Re:Identity Firewall. l PKI International Consortium
Date: Sun, 11 Apr 2004 10:47:10 +0200
Sender: [email-masked]

Arshad,

>Steve Kent wrote:
>I'll respond to just one of your examples, so show why I think this 
>is very unrealistic for most of the grouping you chose.

>> 2) Education - for schools, colleges, professional associations;

>there is no single source appropriate for all schools. elementary, 
>high school, undergraduate, graduate, professionlal associations. 
>each is potentially a valid issuer of a cert, just as each issues a 
>paper credential attesting to graduation, professional certification, 
>etc. thus, one would not acquire one cert associated with educational 
>institutions, but several. so, here, as in most of the examples you 
>cite, an individual would acquire several certs, not just one.

Although I hardly ever agree with Steve, he is correct.  I think
the same is even more valid for industrial segments where it
is likely to be impossible to raise money for running top CAs,
cross-certify, or even creating a common certificate policy.

What Steve did not mention, is that the authentication and
authorization schemes that are firmly in place since three
decades or so for bank-to-bank and supplier-to-manufacturer
networks, together with recent developmemts like SAML and
3D Secure, will likely forever change how PKI is applied, which
also will affect schemes like the Identity Firewall.

>The reality is that there is generally very little motivation for an 
>organization to issue a credential that identifies a person, unless 
>the issuer plans the use the resulting credential for some form of 
>authorization, at least with regard to the issuer. TTP CAs are 
>typically in the business of issuing identity credentials that don't 
>match this model, but then I tend to think of them as anomalous 
>anyway ;-)

Probably PKI deployment will follow two main directions,
relying-party-only and general purpose TTPs.  Which one
will be dominating depends IMHO not on technical
issues but on business models and costs.  There are to my
knowledge practically no limitations to what you can do
with an identity credential using indirect auth* schemes.

Indirect auth* schemes BTW offer huge cost, control, and
scalability advantages over the schemes currently being
deployed by many public sector PKI programs.

Anders

Subject: privacy, authentication, identification , authorization
To: "PKIX list" <[email-masked]>
From: [email-masked]
Date: Sat, 10 Apr 2004 17:34:40 -0600
Sender: [email-masked]

basically somebody provides some authentication information, in
public/private key scenario ... a digital signature is generated by a
private key as part of a "something you have" authentication paradigm.

there could be some certification process where a hardware token is
involved (certifies the operation of specific hardware token analogous to
FIPS or common criteria, not as in a public key certificate issuing
institition), the hardware token is certified as generating (on-chip) a key
pair where the private key never leaves the chip. the hardware token could
also be certified as generating specific kinds of digital signature when
correct PIN or biometric is presented. with such a certificate
infrastructure .... the relying party might then have grounds to believe
that in addition to "something you have", there may bave been "something
you know" and/or "something you are" authentication. This wouldn't be a
shared-secret based operation .... but the relying-party could infer
"something you know" and/or "something you are" if it trusted the
certification process for the hardware token operation.

the relying-party then obtains a public-key and validates the digital
signature. the infrastructure for the public-key could be a database
(conforming to most existing business processes for authentication
material) or a certificate (in the PKI model).

the infrastructure typically has bound the public-key to some
identification, index, and/or authorization information. In the case of
identification or index, that information is frequently then used to lookup
some authorization information (i.e. specific identity is allowed to do
specific stuff). A trivial example is a generic employee certificate ...
all it contains is some generic employer information and the public key, if
the digital signature authenticates ... then it is known that the person is
some employee and is entitled to do whatever generic employees are entitled
to do.

the issue here is that there aren't a lot of business processes that
perform identification (or authentication) just for the sake of it (having
absolutely no other purpose)  .... the business process is performing the
operation as part of some additional activity. For instance, there aren't a
lot of identification  stores in malls, where you walk in
authenticate/identify ... and then walk out (with no other operation
occuring).

The early x.509 identity certificates tended to contain a lot of arbitrary
information that ran afoul of various pricacy issues. The result was
retrenching to relying-party-only certificates that contain an indication
or domain-specific index ... which was then used to index a database entry
that then provided the actual information needed for executing a business
process.

Putting in generic identity information or possibly institutional specific
identity and/or authorization information (like clearance levels) in a
public certificate (targeted for uncontrolled distribution) tends to
violate various privacy and/or institutional rules/policies.

just because some item of information is encapsulated in a public
certificate doesn't magically mitigate all rules and policies regarding the
handling of that information

--
Anne & Lynn Wheeler - http://www.garlic.com/~lynn/

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Sat, 10 Apr 2004 15:24:18 -0700
Importance: Normal
Sender: [email-masked]

My opinion is that as long as DPD-only servers are capable of
signing responses, I don't see a problem with such servers not
shipping with active key material.  They may not be
operationally capable nor deployed so but would be functionally
capable of compliance. The distinction is that a local security
administrator is able to activate DPD signing in response to
emerging threats without recourse to a vendor's software update.

Mike

-----Original Message-----
From: David Engberg [mailto:[email-masked]]
Sent: Saturday, April 10, 2004 2:30 PM
To: Michael Myers
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

I could live with this (and so could my company), but my
personal
preference would be language changes which would also permit a
customer
to deploy SCVP servers which are only used for DPD and have no
keys at
all.  These servers would not be "capable of" signing responses,
and no
one would ever ask them to (or they would get an unsigned error
if they
did).  This would be the same as current PKIs that distributed
certs and
CRLs through LDAP directories that do not even have SSL keys.

I know there are dozens of options for implementing insecure
software
keys at every server, but by removing the keys entirely you
avoid giving
the incorrect impression that the servers should ever be
"trusted" in
the sense of DPV.  No client should be misconfigured to accept
the
signature of those servers as a replacement for its own local
PKI
validation.

Michael Myers wrote:
>
> Does anyone else agree or object?
>
> Mike
>
> From: Santosh Chokhani
> Sent: Thursday, April 08, 2004 4:40 AM
>
> I agree
>
> From: Michael Myers
> Sent: Wednesday, April 07, 2004 4:14 PM
>
> I think we should just change the relevant MUSTs to "MUST be
> capable of".
>
> Mike
>
>
>
>

Date: Sat, 10 Apr 2004 17:30:27 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: Signing Untrusted SCVP?
Sender: [email-masked]

I could live with this (and so could my company), but my personal 
preference would be language changes which would also permit a customer 
to deploy SCVP servers which are only used for DPD and have no keys at 
all.  These servers would not be "capable of" signing responses, and no 
one would ever ask them to (or they would get an unsigned error if they 
did).  This would be the same as current PKIs that distributed certs and 
CRLs through LDAP directories that do not even have SSL keys.

I know there are dozens of options for implementing insecure software 
keys at every server, but by removing the keys entirely you avoid giving 
the incorrect impression that the servers should ever be "trusted" in 
the sense of DPV.  No client should be misconfigured to accept the 
signature of those servers as a replacement for its own local PKI 
validation.

Michael Myers wrote:
> 
> Does anyone else agree or object?
> 
> Mike
> 
> From: Santosh Chokhani
> Sent: Thursday, April 08, 2004 4:40 AM
> 
> I agree
> 
> From: Michael Myers
> Sent: Wednesday, April 07, 2004 4:14 PM
> 
> I think we should just change the relevant MUSTs to "MUST be
> capable of".
> 
> Mike
> 
> 
> 
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Decoding Service Support
Date: Sun, 11 Apr 2004 03:02:32 +1200
Sender: [email-masked]

"Brian G. Holmes" <[email-masked]> writes:

>I support a free BER for ASN.1 decoding service known as the Berasno Decoding
>Service.

How is this different from something like dumpasn1?

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Sat, 10 Apr 2004 23:54:57 +1200
Sender: [email-masked]

Jean-Marc Desperrier <[email-masked]> writes:

>But I'm positive clients *never* check if the response cert is coherent with
>the name in the request they sent

Some do.  I know of client apps that reject the cert if the cert DN doesn't
match the request DN (by "match" I mean if memcmp() reports that they differ).

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Cc: [email-masked]
Date: Sat, 10 Apr 2004 23:33:33 +1200
Sender: [email-masked]

Santoni Adriano <[email-masked]> writes:

>As a CA, we do not handle DNs "encoded by the originator"; which "originator"
>at any rate?
>
>We register people, collecting their own true names, and then we build the
>DNs to be inserted into certificates.

In that case you're the originator, so you can encode them in whatever way you
want, and other apps will preserve the encoding.  So encoding as UTF-8 should
be fine, although some apps (particularly older ones) may not be able to
display it very well, and old (4.x) versions of Netscape will crash when they
encounter it.  You can probably ignore that though, although there are some
CAs that still use 4.x-compatibility as an excuse for doing weird things with
certs.

Peter.

Date: Fri, 09 Apr 2004 23:27:12 -0700
From: Arshad Noor <[email-masked]>
Subject: Re: Identity Firewalls - Was: PKI International Consortium
To: Stephen Kent <[email-masked]>
Cc: PKIX list <[email-masked]>
Organization: StrongAuth, Inc.
Sender: [email-masked]

It is unrealistic only if we accept status quo, Steve.  If we change
the operating conditions - based on reason - then reality changes.
I don't deny that it is an arduous task - but I do not accept that
it is impossible.

Please see other comments below.

Arshad Noor
StrongAuth, Inc.

Stephen Kent wrote:

> Arshad,
> 
> I'll respond to just one of your examples, [t]o show why I think this is 
> very unrealistic for most of the grouping you chose.
> 
>>     2) Education - for schools, colleges, professional associations;
> 
> 
> there is no single source appropriate for all schools. elementary, high 
> school, undergraduate, graduate, professionlal associations. 

	This is accurate.  However, there are a number of associations
	that represent such institutions - NEA, ITEA, AACSB, AMA, ABA,
	IEEE, IETF, etc. - that could have an influence amongst their
	members after they were convinced of the benefits.

	Once convinced, a small working group of representatives - one
	for the Elementary school, one for the Middle school, for High
	School, Undergraduate, Graduate school and a Professional
	Association - could create the technical and business standards
	necessary (with some support from members of this august forum).

	Much like individuals participate in the creation of IETF
	standards (as in this forum), so will these associations through
	their representatives.  Will it take time?  Definitely.  Will it
	please everybody?  Definitely not.  But will a standard come out
	of it?  Almost certainly, if the working group is dedicated.

each is
> potentially a valid issuer of a cert, just as each issues a paper 
> credential attesting to graduation, professional certification, etc. 
> thus, one would not acquire one cert associated with educational 
> institutions, but several. so, here, as in most of the examples you 
> cite, an individual would acquire several certs, not just one.
> 

	I would not recommend the issuance of a cert to attest to one's
	graduation or professional certification. The business objective
	is that someone needs to verify that you truly graduated from
	some school.  There are many simpler ways of accomplishing this:

	1) A secured website that would provide the unique cert DN, the
	   educational qualification and year of graduation to anyone
	   that wanted to view it; alumni that would rather not have
	   this information visible on the Internet could opt out of
	   this type of service, and go with #2;

	2) An asynchronous e-mail service that would send a signed
	   e-mail to the RP, from the alma mater, providing the above
	   information at the individual's request, AFTER having
	   authenticated him by his Education credential and having
	   duly determined his authorization to make such a request;

	3) A synchronous web-service available to anyone that requested
  	   the information; those alumni that would rather not have this
	   information sent out unless they authorized it, could opt out
	   of this type of service, and stay with #2;

	I am sure there are many other ways that members of this forum
	could solve this business problem, in addition to the above.

	In this manner, you end up issuing a single credential to serve
	an individual's needs in the Education industry from KG to Ph.D.
	and still attest to RP's about the individuals' educational
	qualifications without issuing additional certs.

	(Similar response for the travel and financial industry examples
	you provided.)

> A public key cert PKC) may attest to identity and be used as an input to 
> an ACL to determine authorization. Or, one may issue a PKC and include 
> authorization info. Or one may issue a PKC and issue one or more ACs to 
> provide authorization info. There is not one right way to achieve the 
> goal of authorization. However, in practice, essentially every identity 
> credential we issue that is of value, also happens to be an 
> authorization credential as well. A driver's license is an authorization 
> to drive a certain class of vehicle. An employee ID usually grants the 
> employee access to basic employ facilities, generic employee discounts, 
> etc.
> 
	I agree with you.  Even in my own example to Anders yesterday, a
	Financial Industry credential without any accounts associated
	with it, still has the implicit authorization to open a new
	account, if desired, at supporting institutions.

	To some extent, every industry group will probably associate
	some base level of authorization to the industry-specific
	identity; BUT since it serves just that industry, they reap the
	benefits, or pay for the consequences of their good or short-
	sighted	decisions, if any.

> The reality is that there is generally very little motivation for an 
> organization to issue a credential that identifies a person, unless the 
> issuer plans the use the resulting credential for some form of 
> authorization, at least with regard to the issuer. 

	If the issuer were a "super-association" for an industry, as
	opposed to a company within the industry or an association
	representing a segment of the industry, then there are huge
	cost savings to everyone in the industry - as well as the
	consumer they serve.  That will be the motivation; and I hope
	to document this in my treatise.

Date: Fri, 09 Apr 2004 21:48:45 -0700
From: Arshad Noor <[email-masked]>
Subject: Re: PKI International Consortium
To: Ed Gerck <[email-masked]>
Cc: PKIX list <[email-masked]>
Organization: StrongAuth, Inc.
Sender: [email-masked]

Ed Gerck wrote:
>  
> Empirical evidence supports the assertion
> that we all have a growing number of credentials with time,
> including all the expired ones. Yes, expired credentials are 
> useful. For example, as supporting evidence to issue a renewed 
> credential and/or as a credential with less privileges.
> 
	
	I have nothing against the number of expired credentials, Ed;
	just the number of active credentials.  Expired certs are
	invisible to me, even if they're still lying around in my
	authentication token.

Arshad Noor
StrongAuth, Inc.

Subject: Re: Single Identity. Was: PKI International Consortium
To: [email-masked]
Cc: "Al Arsenault" <[email-masked]>, [email-masked], "Anders Rundgren" <[email-masked]>, "Arshad Noor" <[email-masked]>, "Terwilliger, Ann" <[email-masked]>, "Eric Norman" <[email-masked]>, "PKIX list" <[email-masked]>, "Stephen Kent" <[email-masked]>, [email-masked]
From: [email-masked]
Date: Fri, 9 Apr 2004 20:03:06 -0600
Sender: [email-masked]

note that the financial examples aren't really identification ... they
really are authentication ... and that actually helps make it work. it is
somewhat a fabrication to call it identification.

if i my financial authentication device is lost/stolen/breaks/fails/etc, i
can call up and AUTHENICATE myself as the owner of the account and get a
new one. The various questions are all effectively some form of
shared-secret ... that they hope the person on the street can remember.
They ask things like transactions on previous statements ... but they also
ask address, social security number, and mothers-maiden-name.  For
mothers-maiden-name ... they've never actually ID you ... they've
effectively asked for a shared-secret that they hope you can
remember/answer. Because of some issue about mothers-maiden-name might not
be the best of secrets ... I know people that make up values to fill in
that field .... you just have to make sure you remember that when the
mothers-maiden-name tag shows up ... you remember what secret you actually
filled in. The use of SSN is something of a schizophrenic problem ... it is
dual-use both as a (mandatory) identification (by gov. requirements) and as
a shared-secret (something you can answer for authentication).  The problem
with the mandatory identification aspect of SSN is that it becomes
propogated to a large number of places, compromizing is use as a
shared-secret authentication mechanism.

the authentication taxonomy is

* something you have
* something you know
* someting you are

shared-secrets are part of "something you know". hardware tokens are
example of "something you have". Digital signatures for authentication
purposes tend to be of the "something you have" nature ... i.e. in theory
you and only you have a copy of your private key. Note in this context ...
whether or not certificates are part of the paradigm is orthogonal to the
authentication paradigm.

Financial cards have also been of the "something you have" paradigm. In the
past, there has been great deal of effort in making it hard to counterfeit
these cards .... majority of it based on assuming that the criminal
generates the counterfeit cards completely from scratch. The current
problem is one of skimming where all the information to make a duplicate
card is copied (as opposed to having to start from scratch creating a
counterfeit card).

"something you have" authentication paradigm breaks down when the object is
no longer unique. this can happen with private keys if wherever it is
stored becomes compromized. It has also happened in the case of the EMV
counterfeit "yes cards" .... i.e. effectively the same technology for
skimming to make duplicate (counterfeit) magstripe cards is also used to
make duplicate (counterfeit) EMV cards.

the issue regarding the contents or nature of a certificate is totally
orthogonal to the use of publib/private key system as a "something you
have" authentication mechanism. The advantages that the mechanism has over
existing shared-secret paradigms ... 1) resilent to insider attacks that
copy the master secret database (there is no shared secret that they can
get that allows them to impersonate you), 2) phishing attacks are slightly
more complicated since you don't actually "remember" your private key.

The downside of private keys in a file on your PC ... is that it is
relatively suseptable to phishing and virus attacks ... if they can get you
to click on something and give up your logon password ... they can get you
to click on something and give up the (private key) file encryption key
(transmitting the file at the same time).

Placing the private key in a hardware token where effectively nobody can
get it .... then requires change in tactics. They have to convince you to
mail off the hardware token along with any PIN ... or get you to use the
hardware token in transactions on their behalf.

Again ... nothing in the uses of private key and/or hardware tokens for
authentication is directly related to certificates.  The certificates
paradigm is part of a structure for validating the results of the
authentication .... but is not part of the generation of the authentication
or the authentication taxonomy.

shaheen nasirudheen wrote:

Hello everyone.

Though new to this group, within a short span I understand there are people
who favor single identity and who does not. I also understand that there is
an effort towards standardizing or centralizing PKI among the Financial
Institutions. One such effort is Identrus. Thanks to some of the members of
this group who helped me with good information. However, moving forward,
can I look forward for a single identity that I can use to identify myself
to any public system that require identification and authentication? If
there is an ongoing effort in this regard, please let me know so that I can
participate.

Regards,

Shaheen Nasirudheen

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Fri, 9 Apr 2004 17:42:33 -0700
Importance: Normal
Sender: [email-masked]

Does anyone else agree or object?

Mike

-----Original Message-----
From: Santosh Chokhani
Sent: Thursday, April 08, 2004 4:40 AM

I agree

-----Original Message-----
From: Michael Myers
Sent: Wednesday, April 07, 2004 4:14 PM

I think we should just change the relevant MUSTs to "MUST be
capable of".

Mike

Subject: Re: Single Identity. Was: PKI International Consortium
To: "Anders Rundgren" <[email-masked]>, "Al Arsenault" <[email-masked]>, [email-masked], "Arshad Noor" <[email-masked]>, "Terwilliger, Ann" <[email-masked]>, "Eric Norman" <[email-masked]>, "PKIX list" <[email-masked]>, "Stephen Kent" <[email-masked]>, [email-masked]
From: [email-masked]
Date: Fri, 9 Apr 2004 17:30:36 -0400
Sender: [email-masked]

Hello everyone.

Though new to this group, within a short span I understand there are people
who favor single identity and who does not. I also understand that there is
an effort towards standardizing or centralizing PKI among the Financial
Institutions. One such effort is Identrus. Thanks to some of the members of
this group who helped me with good information. However, moving forward,
can I look forward for a single identity that I can use to identify myself
to any public system that require identification and authentication? If
there is an ongoing effort in this regard, please let me know so that I can
participate.

Regards,

Shaheen Nasirudheen

-----------------------------------
This message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for delivery of this message to the intended
recipient(s), you are hereby notified that any dissemination, distribution
or copying of this message is strictly prohibited.  If you have received
this message in error, please immediately notify the sender and delete this
e-mail message from your computer.

                    "Anders Rundgren"                                                                                  
                    <anders.rundgren@t       To:     "Al Arsenault" <[email-masked]>, "PKIX list"                    
                    elia.com>                 <[email-masked]>, Shaheen Nasirudheen/JPMCHASE@JPMCHASE               
                    Sent by:                 cc:     "Stephen Kent" <[email-masked]>, "Arshad Noor"                      
                    owner-ietf-pkix@ma        <[email-masked]>, <[email-masked]>, "Terwilliger, Ann"       
                    il.imc.org                <[email-masked]>, "Eric Norman" <[email-masked]>               
                                             Subject:     Re: Single Identity. Was: PKI International Consortium       
                                                                                                                       
                    04/05/2004 09:01                                                                                   
                    AM                                                                                                 

AWA:  Speaking from practical experience (having a physical wallet lifted
in Prague a few years back), it was easier NOT having a single credential.
Okay, the wallet with the cash, credit cards, US driver's license, pictures
of the kids, medical insurance card, etc. is gone.  But, NOT the passport,
and not the emergency credit card kept separate from the rest for exactly
this eventuality.  Survival was assured until recovery could be
accomplished.

AR: In my opinion you are describing something like a "credential backup"
scheme which is pretty unrelated to the single credential issue.  Valid
questions arise, like: Where do you keep the backups? Where would you keep
your electronic IDs when on the road (where you need them)?  It looks to me
that the "always connected" world creates new problems requiring more
robust and universal solutions.   The globally supported trust network is
my shot as this problem.

AWA:  Now, map this to the virtual world, where everything is stored in
your mobile phone.  Whoops - mobile phone is lost/stolen.  So I go to the
nearest branch of the "issuing agency".  The conversation goes something
like Me: "excuse me, my name is Al Arsenault, and my ID was stolen.  I need
a new one".   Agency:  "Prove that's who you are".  Me:  "How?  My one
single ID was stolen, I need a new one".  Agency: "Yes, but if we believed
you based on just what you're telling us, it could deny service to the REAL
Al Arsenault, who our records show is out blithely spending money right
now". (Somebody call John Cleese - there's a great Monty Python skit in
here somewhere.)

AR: This situation is indeed a tricky one.  However, it gets more
manageable when issuers have 24/7 helpdesks which allows the agency to
look-up records and ask you to answer a few questions that only the
original issuer and you have the answers to.  Since agencies have to
authenticate to access external records (or identify themselves to an
issuer helpdesk), a screw-up may lead to the agency's loss of their
license.

AWA:  Yes, there's likely a way to PROVE that I'm the real Al Arsenault,
but I hope it doesn't involve biometrics - don't get me started down that
road. :-(

AR: Biometrics is of indeed a very vital part of such verifications.  Today
this may just be your picture but tomorrow it will be DNA.  Since identity
theft is admittedly the weak spot of the described scheme there are really
no alternatives to biometrics except abandoning the whole thing.  AFAIK the
US immigration authorities require (or are about to require) an extensive
set of biometrics in passports so either we foreigners have to stay at home
or deal with it.

AR: Regarding the value of single identities it is also a matter of cost.
The majority of people work for small businesses and these may find that
using the already existing bank-issued IDs will be easier to use than
putting out user-IDs and passwords.  The identity does not have to be an
SSN, it may be your bank client number or some completely artificial
number.  That is, bank-IDs do not have to "emulate" passports to be useful.

AR: Regarding multiple banks, I agree with you, you should not (mostly for
commercial and political reasons) force a network of TTPs to be direct TTPs
for each other.  So here there will be a deviation from the single ID.
However, you typically only need one "primary ID" for all your TTP-based
ID-relations.

best
AR = Anders Rundgren

Date: Fri, 9 Apr 2004 14:48:03 -0400
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Successor to RFC 3280?
Cc: "Denis Pinkas" <[email-masked]>, "PKIX List" <[email-masked]>
Sender: [email-masked]

At 10:22 AM -0700 4/9/04, todd glassey wrote:
>----- Original Message -----
>From: "Denis Pinkas" <[email-masked]>
>To: "Steve Hanna" <[email-masked]>
>Cc: "PKIX List" <[email-masked]>
>Sent: Friday, April 09, 2004 8:16 AM
>Subject: Re: Successor to RFC 3280?
>
>
>>
>>  Steve,
>>
>>  This is an additional change proposal to the successor to RFC 3280.
>>  We are currently deprecating the use of the private key usage period.
>>
>>  4.2.1.4  Private Key Usage Period
>>
>>      This extension SHOULD NOT be used within the Internet PKI.  CAs
>>      conforming to this profile MUST NOT generate certificates that
>>      include a critical private key usage period extension.
>
>yes I agree - and IMHO this use of time as part of the keying validation
>model clearly violates the Glassey-McNeil Patent's use claims.

Todd, you were warned by Russ to not bring this issue up on PKIX anymore.

One more time and I'll have to ask Paul Hoffman to revoke your 
posting privileges.

Steve

Date: Fri, 9 Apr 2004 14:45:46 -0400
To: Arshad Noor <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PKI International Consortium
Cc: PKIX list <[email-masked]>
Sender: [email-masked]

Arshad,

I'll respond to just one of your examples, so show why I think this 
is very unrealistic for most of the grouping you chose.

>	2) Education - for schools, colleges, professional associations;

there is no single source appropriate for all schools. elementary, 
high school, undergraduate, graduate, professionlal associations. 
each is potentially a valid issuer of a cert, just as each issues a 
paper credential attesting to graduation, professional certification, 
etc. thus, one would not acquire one cert associated with educational 
institutions, but several. so, here, as in most of the examples you 
cite, an individual would acquire several certs, not just one.

certainly any frequent traveller already knows how many distinct 
credentials he/she acquires. these are separate and each identifies 
you by an account number that is managed by the issuer, not by any 
travel-industry wide oversight organization.

in the financial sector, we also have separate credentials, each 
issued by a separate institution. there is no single organization 
that has oversight responsibility for all of these institutions, and 
smart people like to maintain separation to insulate themselves 
against bad behavior at any one of these institutions.

>	<SNIP>
>>
>>I too am in favor of the use of certs with private keys maintained 
>>in hardware tokens and a high assurance issuing process, when the 
>>resources being accessed warrant such measures. But, "optimal" is 
>>an inappropriate term when we have such a wide range of resources 
>>that people access.
>>
>	Therein lies the fallacy of PKI - or any other authentication
>	technology - today: implied authorization to use of resources
>	based on the authentication credential!
>
>	To me, the use of certs with private keys in hardware tokens and
>	a high assurance process is good enough only to IDENTIFY the
>	presenter of the credential.  I will still want to go through
>	whatever number of business rules I choose, to determine whether
>	the identified entity has the authorization to use the resource.

A public key cert PKC) may attest to identity and be used as an input 
to an ACL to determine authorization. Or, one may issue a PKC and 
include authorization info. Or one may issue a PKC and issue one or 
more ACs to provide authorization info. There is not one right way to 
achieve the goal of authorization. However, in practice, essentially 
every identity credential we issue that is of value, also happens to 
be an authorization credential as well. A driver's license is an 
authorization to drive a certain class of vehicle. An employee ID 
usually grants the employee access to basic employ facilities, 
generic employee discounts, etc.

The reality is that there is generally very little motivation for an 
organization to issue a credential that identifies a person, unless 
the issuer plans the use the resulting credential for some form of 
authorization, at least with regard to the issuer. TTP CAs are 
typically in the business of issuing identity credentials that don't 
match this model, but then I tend to think of them as anomalous 
anyway ;-)

Steve

Date: Fri, 9 Apr 2004 13:33:59 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SMIME Capabilities in X.509 certificates.
Cc: <[email-masked]>
Sender: [email-masked]

Stefan,

Steve

Date: Fri, 9 Apr 2004 13:24:44 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Successor to RFC 3280?
Cc: Steve Hanna <[email-masked]>, PKIX List <[email-masked]>
Sender: [email-masked]

Denis,

Good point. It might make sense to say that this extension is 
reasonable under such circumstances.

Steve

From: "todd glassey" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "PKIX List" <[email-masked]>
Subject: Re: Successor to RFC 3280?
Date: Fri, 9 Apr 2004 10:22:49 -0700
Sender: [email-masked]

----- Original Message ----- 
From: "Denis Pinkas" <[email-masked]>
To: "Steve Hanna" <[email-masked]>
Cc: "PKIX List" <[email-masked]>
Sent: Friday, April 09, 2004 8:16 AM
Subject: Re: Successor to RFC 3280?

>
> Steve,
>
> This is an additional change proposal to the successor to RFC 3280.
> We are currently deprecating the use of the private key usage period.
>
> 4.2.1.4  Private Key Usage Period
>
>     This extension SHOULD NOT be used within the Internet PKI.  CAs
>     conforming to this profile MUST NOT generate certificates that
>     include a critical private key usage period extension.

yes I agree - and IMHO this use of time as part of the keying validation
model clearly violates the Glassey-McNeil Patent's use claims.

>
> I have been advocating this in the past, while being (too much) focussed
on
> keys for human beings: it is not possible to prevent a human being to use
> his private key beyond that date.
>
> However, if this key is placed within a(n evaluated) security module that
> has a secure clock, it possible to make sure that the security module
> prevents the use of the private key beyond the expiration date (e.g. the
key
> can be zeroized). This is fully pertinent for time-stamping modules which
> must have a clock synchronised with UTC.

No Denis it is not. It is possible to say that "this use conforms to this
recommendation" but there in fact is no way with today's technologies to
stop anyone from doing anything that they want to with SW systems. So... the
issues for time stamping systems that must be synchronized with UTC services
are just a recommendation and we wont talk about this use's violation (in my
opinion) of my patent rights in the Datum Controlling Access to Stored
Information Patent.

>
> Thus I would propose to allow and even recommend the use of this extension
> for keys located in security modules that have a secure clock, in
particular
> time-stamping modules, where it is possible to enforce this control.
>
> Denis
>
> > I have heard some folks say that we should have
> > a successor to RFC 3280 (and 3279) and some folks
> > say that we shouldn't. I'd like to raise this topic
> > for discussion on the PKIX list to settle this matter.
> >
> > I believe that an update to RFC 3280 is necessary
> > for two reasons. First, some minor problems have
> > been found during implementation and deployment
> > (mostly typos and clarifications). These should
> > be fixed so that future implementors don't have
> > to suffer through them. Second, we are almost ready
> > for RFC 3280 to progress to Draft Standard status.
> > In order to do this, it must be revised. So I
> > believe that an update to RFC 3280 (and 3279)
> > should be undertaken.
> >
> > HOWEVER, I think it is essential for us to limit
> > the scope of this update. We should not add features
> > to the spec or make substantial changes, especially
> > changes that would break compatibility with RFC 3280.
> > The scope of the update should be limited to
> > "clarifying and correcting the document in light
> > of implementation experience".
> >
> > That's my perspective on this important matter.
> > I would like to hear other perspectives and
> > opinions so that we can arrive at a rough working
> > group consensus on this.
> >
> > Thanks,
> >
> > Steve
> >
> > P.S. I have a list of typos and clarifications
> > that need to be fixed in the next version of
> > RFC 3280. If we decide to proceed with a revision,
> > I'll forward it to the editor and cc the PKIX list.
>
>

From: "todd glassey" <[email-masked]>
To: <[email-masked]>
Cc: "Al Arsenault" <[email-masked]>, "Eric Norman" <[email-masked]>, "PKIX list" <[email-masked]>, <[email-masked]>
Subject: Re: Identity (was PKI International Consortium)
Date: Fri, 9 Apr 2004 09:45:13 -0700
Sender: [email-masked]

Here again Lynn we as technologists are telling the world what it needs
rather than looking at its existing processes, and figuring out how they
would work in a paperless model. But I do hear what you are saying and I do
realize the overhead of having a HGN fingerprint installed into a token and
BTW - I am in the process of filing a patent for a PKI adaptation for
signing the chromosomal matrix so that it generates a set of hashes and
simple signatures. This in fact is a DNS Signature. Filing should be done by
next week...

Todd Glassey

----- Original Message ----- 
From: <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Al Arsenault" <[email-masked]>; "Eric Norman"
<[email-masked]>; "PKIX list" <[email-masked]>;
<[email-masked]>
Sent: Friday, April 09, 2004 9:40 AM
Subject: Re: Identity (was PKI International Consortium)

>
>
>
>
> the down side is that DNA is one of those PIIs ... with high assurance
> requirements.
>
> private key values would likely be placed in a public certificates ...
long
> before DNA information
>
> todd glassey wrote:
>
> DNA is reasonably constant
>
> --
> Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
>

Subject: Re: Identity (was PKI International Consortium)
To: "todd glassey" <[email-masked]>
Cc: "Al Arsenault" <[email-masked]>, "Eric Norman" <[email-masked]>, "PKIX list" <[email-masked]>, [email-masked]
From: [email-masked]
Date: Fri, 9 Apr 2004 10:40:42 -0600
Sender: [email-masked]

the down side is that DNA is one of those PIIs ... with high assurance
requirements.

private key values would likely be placed in a public certificates ... long
before DNA information

todd glassey wrote:

DNA is reasonably constant

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Date: Fri, 09 Apr 2004 17:16:21 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Steve Hanna <[email-masked]>
CC: PKIX List <[email-masked]>
Subject: Re: Successor to RFC 3280?
Sender: [email-masked]

Steve,

This is an additional change proposal to the successor to RFC 3280.
We are currently deprecating the use of the private key usage period.

4.2.1.4  Private Key Usage Period

    This extension SHOULD NOT be used within the Internet PKI.  CAs
    conforming to this profile MUST NOT generate certificates that
    include a critical private key usage period extension.

I have been advocating this in the past, while being (too much) focussed on 
keys for human beings: it is not possible to prevent a human being to use 
his private key beyond that date.

However, if this key is placed within a(n evaluated) security module that 
has a secure clock, it possible to make sure that the security module 
prevents the use of the private key beyond the expiration date (e.g. the key 
can be zeroized). This is fully pertinent for time-stamping modules which 
must have a clock synchronised with UTC.

Thus I would propose to allow and even recommend the use of this extension 
for keys located in security modules that have a secure clock, in particular 
time-stamping modules, where it is possible to enforce this control.

Denis

> I have heard some folks say that we should have
> a successor to RFC 3280 (and 3279) and some folks
> say that we shouldn't. I'd like to raise this topic
> for discussion on the PKIX list to settle this matter.
> 
> I believe that an update to RFC 3280 is necessary
> for two reasons. First, some minor problems have
> been found during implementation and deployment
> (mostly typos and clarifications). These should
> be fixed so that future implementors don't have
> to suffer through them. Second, we are almost ready
> for RFC 3280 to progress to Draft Standard status.
> In order to do this, it must be revised. So I
> believe that an update to RFC 3280 (and 3279)
> should be undertaken.
> 
> HOWEVER, I think it is essential for us to limit
> the scope of this update. We should not add features
> to the spec or make substantial changes, especially
> changes that would break compatibility with RFC 3280.
> The scope of the update should be limited to
> "clarifying and correcting the document in light
> of implementation experience".
> 
> That's my perspective on this important matter.
> I would like to hear other perspectives and
> opinions so that we can arrive at a rough working
> group consensus on this.
> 
> Thanks,
> 
> Steve
> 
> P.S. I have a list of typos and clarifications
> that need to be fixed in the next version of
> RFC 3280. If we decide to proceed with a revision,
> I'll forward it to the editor and cc the PKIX list.

From: "todd glassey" <[email-masked]>
To: "Santoni Adriano" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Fri, 9 Apr 2004 06:31:46 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_003C_01C41DFC.5504D280
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

R: RFC3280: doubt on the use of UTF8String in encoding RDNsPeter - =
Santoni, the RFC is the RFC and it says MUST, and it addresses the =
NameRollover issues as well with commentary about=20

      (a)  CAs MAY issue "name rollover" certificates to support an
      orderly migration to UTF8String encoding.  Such certificates would
      include the CA's UTF8String encoded name as issuer and and the old
      name encoding as subject, or vice-versa.

... http://www.faqs.org/rfcs/rfc3280.html

So my reading is that UTF8 is not optional.

Todd Glassey

  ----- Original Message -----=20
  From: Santoni Adriano=20
  To: [email-masked]'=20
  Cc: [email-masked]=20
  Sent: Friday, April 09, 2004 3:35 AM
  Subject: R: RFC3280: doubt on the use of UTF8String in encoding RDNs

  Thanks for replying, although it seems a reply to another question (my =
fault, I presume).=20

  I was referring to new certificates, issued "from today on" (so to =
speak).=20

  As a CA, we do not handle DNs "encoded by the originator"; which =
"originator" at any rate?=20

  We register people, collecting their own true names, and then we build =
the DNs to be inserted into certificates. The names can be e.g. the =
ASCII-safe name "Peter Gutman", or the polish name "Anna =
Kr=C4=99glewska", or the greek =
"=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83 =
=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83"=
 or whatever else - can you read? :-). In the case of your name, a =
PrintableString would be "safe", as it would retain all the original =
information. In the latter cases, it would not and so it makes more =
sense to use Unicode encoded as UTF8String.

  Maybe I am just not getting what you mean...=20

  Adriano=20

  -----Messaggio originale-----=20
  Da: pgut001 [mailto:[email-masked]] Per conto di =
[email-masked]=20
  Inviato: mercoled=C3=AC 7 aprile 2004 15.55=20
  A: [email-masked]; [email-masked]=20
  Oggetto: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs=20

  Santoni Adriano <[email-masked]> writes:=20

  >I am probably asking an old question, so ... please be patient.=20
  >=20
  >Rfc3280 states (<A7>4.1.2.4): "...all certificates issued after=20
  >December 31, 2003 MUST use the UTF8String encoding of=20
  >DirectoryString...".=20
  >=20
  >Does that mean that it is mandatory to always encode all RDNs (having =
a=20
  >type of DirectoryString) of the issuer and subject (and still other)=20
  >certificate fields as UTF8Strings _even if they could be correctly=20
  >encoded as a PrintableStrings_ ?=20

  Hmm, see the previous thread on this a few months ago... in theory =
you're supposed to do this, but that violates the primary rule of DN =
encoding, which is "Never change the DN once it's been encoded by the =
originator".  If you break that rule, you get to discover all the apps =
that reject re-encoded DNs. If you're lucky, this will happen before =
your product ships and not after.

  Peter.=20

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

  SIA S.p.A. non si assume alcuna responsabilita' per eventuali =
intercettazioni, modifiche o danneggiamenti del presente messaggio =
e-mail.=20

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

  SIA S.p.A. does not accept liability for corruption, interception or =
amendment, if any, or the consequences thereof.=20

------=_NextPart_000_003C_01C41DFC.5504D280
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><TITLE>R: RFC3280: doubt on the use of UTF8String in =
encoding RDNs</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3DUTF-8">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Peter - Santoni, the RFC is the RFC and =
it says=20
MUST, and it addresses the NameRollover issues as well with commentary =
about=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; CAs MAY =
issue=20
"name rollover" certificates to support =
an<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
orderly migration to UTF8String encoding.&nbsp; Such certificates=20
would<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include the CA's UTF8String =
encoded name=20
as issuer and and the old<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; name =
encoding as=20
subject, or vice-versa.<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>... <A=20
href=3D"http://www.faqs.org/rfcs/rfc3280.html">http://www.faqs.org/rfcs/r=
fc3280.html</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>So my reading is that UTF8 is not=20
optional.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Todd Glassey</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Santoni Adriano</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  =
href=3D"mailto:[email-masked]'">[email-masked]'</=
A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, April 09, 2004 =
3:35=20
AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> R: RFC3280: doubt on =
the use of=20
  UTF8String in encoding RDNs</DIV>
  <DIV><BR></DIV>
  <P><FONT face=3DVerdana color=3D#0000ff>Thanks for replying, although =
it seems a=20
  reply to another question (my fault, I presume). </FONT></P>
  <P><FONT face=3DVerdana color=3D#0000ff>I was referring to new =
certificates,=20
  issued "from today on" (so to speak). </FONT></P>
  <P><FONT face=3DVerdana color=3D#0000ff>As a CA, we do not handle DNs =
"encoded by=20
  the originator"; which "originator" at any rate? </FONT></P>
  <P><FONT face=3DVerdana color=3D#0000ff>We register people, collecting =
their own=20
  true names, and then we build the DNs to be inserted into =
certificates. The=20
  names can be e.g. the ASCII-safe name "Peter Gutman", or the polish =
name "Anna=20
  Kr</FONT><FONT face=3DVerdana =
color=3D#0000ff>=C4=99glewska</FONT><FONT face=3DVerdana=20
  color=3D#0000ff>", or the greek "</FONT><FONT face=3DVerdana =
color=3D#0000ff>=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83=20
  =
=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83<=
/FONT><FONT face=3DVerdana color=3D#0000ff>" or whatever else - can=20
  you read? :-). In the case of your name, a PrintableString would be =
"safe", as=20
  it would retain all the original information. In the latter cases, it =
would=20
  not and so it makes more sense to use Unicode encoded as=20
UTF8String.</FONT></P>
  <P><FONT face=3DVerdana color=3D#0000ff>Maybe I am just not getting =
what you=20
  mean...</FONT> </P>
  <P><FONT face=3DVerdana color=3D#0000ff>Adriano</FONT> </P><BR>
  <P><FONT face=3DArial size=3D2>-----Messaggio originale-----</FONT> =
<BR><FONT=20
  face=3DArial size=3D2>Da: pgut001 [</FONT><A=20
  href=3D"mailto:[email-masked]"><U><FONT =
face=3DArial=20
  color=3D#0000ff=20
  size=3D2>mailto:[email-masked]</FONT></U></A><FONT =

  face=3DArial size=3D2>] Per conto di [email-masked]</FONT> =
<BR><FONT=20
  face=3DArial size=3D2>Inviato: mercoled=C3=AC 7 aprile 2004 =
15.55</FONT> <BR><FONT=20
  face=3DArial size=3D2>A: [email-masked]; =
[email-masked]</FONT>=20
  <BR><FONT face=3DArial size=3D2>Oggetto: Re: RFC3280: doubt on the use =
of=20
  UTF8String in encoding RDNs</FONT> </P><BR>
  <P><FONT face=3DArial size=3D2>Santoni Adriano =
&lt;[email-masked]&gt;=20
  writes:</FONT> </P>
  <P><FONT face=3DArial size=3D2>&gt;I am probably asking an old =
question, so ...=20
  please be patient.</FONT> <BR><FONT face=3DArial size=3D2>&gt;</FONT> =
<BR><FONT=20
  face=3DArial size=3D2>&gt;Rfc3280 states (&lt;A7&gt;4.1.2.4): "...all =
certificates=20
  issued after </FONT><BR><FONT face=3DArial size=3D2>&gt;December 31, =
2003 MUST use=20
  the UTF8String encoding of </FONT><BR><FONT face=3DArial=20
  size=3D2>&gt;DirectoryString...".</FONT> <BR><FONT face=3DArial =
size=3D2>&gt;</FONT>=20
  <BR><FONT face=3DArial size=3D2>&gt;Does that mean that it is =
mandatory to always=20
  encode all RDNs (having a </FONT><BR><FONT face=3DArial =
size=3D2>&gt;type of=20
  DirectoryString) of the issuer and subject (and still other) =
</FONT><BR><FONT=20
  face=3DArial size=3D2>&gt;certificate fields as UTF8Strings _even if =
they could be=20
  correctly </FONT><BR><FONT face=3DArial size=3D2>&gt;encoded as a=20
  PrintableStrings_ ?</FONT> </P>
  <P><FONT face=3DArial size=3D2>Hmm, see the previous thread on this a =
few months=20
  ago... in theory you're supposed to do this, but that violates the =
primary=20
  rule of DN encoding, which is "Never change the DN once it's been =
encoded by=20
  the originator".&nbsp; If you break that rule, you get to discover all =
the=20
  apps that reject re-encoded DNs. If you're lucky, this will happen =
before your=20
  product ships and not after.</FONT></P>
  <P><FONT face=3DArial size=3D2>Peter.</FONT> </P><BR>
  <P><FONT face=3DArial size=3D2>*******************Internet Email =
Confidentiality=20
  Footer******************* </FONT><BR><FONT face=3DArial =
size=3D2>Qualsiasi=20
  utilizzo non autorizzato del presente messaggio nonche' dei suoi =
allegati e'=20
  vietato e potrebbe costituire reato. Se lei ha ricevuto erroneamente =
il=20
  presente messaggio, Le saremmo grati se, via e-mail, ce ne comunicasse =
la=20
  ricezione e provvedesse alla distruzione del messaggio stesso e dei =
suoi=20
  eventuali allegati. Le dichiarazioni contenute nel presente messaggio =
nonche'=20
  nei suoi eventuali allegati devono essere attribuite esclusivamente al =

  mittente e non possono essere considerate come trasmesse o autorizzate =
da SIA=20
  S.p.A.; le medesime dichiarazioni non impegnano SIA S.p.A. nei =
confronti del=20
  destinatario o di terzi. </FONT></P>
  <P><FONT face=3DArial size=3D2>SIA S.p.A. non si assume alcuna =
responsabilita' per=20
  eventuali intercettazioni, modifiche o danneggiamenti del presente =
messaggio=20
  e-mail. </FONT></P>
  <P><FONT face=3DArial size=3D2>Any unauthorized use of this e-mail or =
any of its=20
  attachments is prohibited and could constitute an offence. If you are =
not the=20
  intended addressee please advise immediately the sender by using the =
reply=20
  facility in your e-mail software and destroy the message and its =
attachments.=20
  The statements and opinions expressed in this e-mail message are those =
of the=20
  author of the message and do not necessarily represent those of SIA. =
Besides,=20
  The contents of this message shall be understood as neither given nor =
endorsed=20
  by SIA S.p.A.. </FONT></P>
  <P><FONT face=3DArial size=3D2>SIA S.p.A. does not accept liability =
for=20
  corruption, interception or amendment, if any, or the consequences =
thereof.=20
  </FONT></P><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_003C_01C41DFC.5504D280--

Date: Fri, 09 Apr 2004 14:36:18 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Sender: [email-masked]

Santoni Adriano wrote:

> As a CA, we do not handle DNs "encoded by the originator"; which 
> "originator" at any rate?
>
_You_ are the originator, it's the CA that fixes what the name is when 
creating the X509 cert, and anybody using that name after that never 
should change it. (But if you generate a cross -certificate or find 
yourself  in a similar situation where another CA has already created 
the name, you shouldn't change it at all if you want to get good 
inter-operability).

Peter is not of that mind, I understood he thinks it's important to 
preserve the name that is created in the request where the client 
presented you his public key, and I had no time to argue about that the 
last time he raised it on the list.

But I'm positive clients *never* check if the response cert is coherent 
with the name in the request they sent, that anyway most CA just dump to 
the trash the name that whas included in the request and generate the 
name with a completely independant algorithm (they often use 
registration pages with a fixed name for the request), that in some case 
there is no request (pre-generated keys in tokens, the client just sends 
the token id, and the CA has OOB ways to know the corresponding public key).

So when you CA issue the very first cert for a user, you are free to fix 
the name, and it can be good to normalize it.
One this first cert is there, his "primary rule of DN encoding" actually 
applies, and application should better never touch the name and never 
use any transformation when doing comparisons to avoid problems, this 
including CA if renewing or cross-certificating.

From: Santoni Adriano <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Fri, 9 Apr 2004 12:35:08 +0200 
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_01C41E1E.53FF5D25
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for replying, although it seems a reply to another question (my
fault, I presume).=20

I was referring to new certificates, issued "from today on" (so to =
speak).=20

As a CA, we do not handle DNs "encoded by the originator"; which
"originator" at any rate?=20

We register people, collecting their own true names, and then we build =
the
DNs to be inserted into certificates. The names can be e.g. the =
ASCII-safe
name "Peter Gutman", or the polish name "Anna Kr=C4=99glewska", or the =
greek
"=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83 =
=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83=
" or whatever else - can you read? :-). In the case of
your name, a PrintableString would be "safe", as it would retain all =
the
original information. In the latter cases, it would not and so it makes =
more
sense to use Unicode encoded as UTF8String.

Maybe I am just not getting what you mean...

Adriano

-----Messaggio originale-----
Da: pgut001 [mailto:[email-masked]
<mailto:[email-masked]> ] Per conto di
[email-masked]
Inviato: mercoled=C3=AC 7 aprile 2004 15.55
A: [email-masked]; [email-masked]
Oggetto: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs

Santoni Adriano <[email-masked]> writes:

>I am probably asking an old question, so ... please be patient.
>
>Rfc3280 states (<A7>4.1.2.4): "...all certificates issued after=20
>December 31, 2003 MUST use the UTF8String encoding of=20
>DirectoryString...".
>
>Does that mean that it is mandatory to always encode all RDNs (having =
a=20
>type of DirectoryString) of the issuer and subject (and still other)=20
>certificate fields as UTF8Strings _even if they could be correctly=20
>encoded as a PrintableStrings_ ?

Hmm, see the previous thread on this a few months ago... in theory =
you're
supposed to do this, but that violates the primary rule of DN encoding,
which is "Never change the DN once it's been encoded by the =
originator".  If
you break that rule, you get to discover all the apps that reject =
re-encoded
DNs. If you're lucky, this will happen before your product ships and =
not
after.

Peter.

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

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

------_=_NextPart_001_01C41E1E.53FF5D25
Content-Type: text/html;
	charset="UTF-8"
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=3DUTF-8">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.88">
<TITLE>R: RFC3280: doubt on the use of UTF8String in encoding =
RDNs</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">Thanks for replying, =
although it seems a reply to another question (my fault, I presume). =
</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">I was referring to new =
certificates, issued &quot;from today on&quot; (so to speak). </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">As a CA, we do not handle =
DNs &quot;encoded by the originator&quot;; which &quot;originator&quot; =
at any rate? </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">We register people, =
collecting their own true names, and then we build the DNs to be =
inserted into certificates. The names can be e.g. the ASCII-safe name =
&quot;Peter Gutman&quot;, or the polish name &quot;Anna Kr</FONT><FONT =
COLOR=3D"#0000FF" FACE=3D"Verdana">=C4=99glewska</FONT><FONT =
COLOR=3D"#0000FF" FACE=3D"Verdana">&quot;, or the greek =
&quot;</FONT><FONT COLOR=3D"#0000FF" =
FACE=3D"Verdana">=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=B1=CF=83 =
=CE=91=CE=BD=CE=B4=CF=81=CE=B5=CE=BF=CF=80=CE=BF=CF=85=CE=BB=CE=BF=CF=83=
</FONT><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">&quot; or whatever else =
- can you read? :-). In the case of your name, a PrintableString would =
be &quot;safe&quot;, as it would retain all the original information. =
In the latter cases, it would not and so it makes more sense to use =
Unicode encoded as UTF8String.</FONT></P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">Maybe I am just not getting =
what you mean...</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Verdana">Adriano</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Messaggio originale-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Da: pgut001 [</FONT><A =
HREF=3D"mailto:[email-masked]"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">mailto:[email-masked]</FONT></U></A><=
FONT SIZE=3D2 FACE=3D"Arial">] Per conto di =
[email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Inviato: mercoled=C3=AC 7 aprile 2004 =
15.55</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">A: [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Oggetto: Re: RFC3280: doubt on the =
use of UTF8String in encoding RDNs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Santoni Adriano =
&lt;[email-masked]&gt; writes:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;I am probably asking an old =
question, so ... please be patient.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Rfc3280 states =
(&lt;A7&gt;4.1.2.4): &quot;...all certificates issued after </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;December 31, 2003 MUST use the =
UTF8String encoding of </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;DirectoryString...&quot;.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Does that mean that it is =
mandatory to always encode all RDNs (having a </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;type of DirectoryString) of the =
issuer and subject (and still other) </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;certificate fields as UTF8Strings =
_even if they could be correctly </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;encoded as a PrintableStrings_ =
?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hmm, see the previous thread on this a =
few months ago... in theory you're supposed to do this, but that =
violates the primary rule of DN encoding, which is &quot;Never change =
the DN once it's been encoded by the originator&quot;.&nbsp; If you =
break that rule, you get to discover all the apps that reject =
re-encoded DNs. If you're lucky, this will happen before your product =
ships and not after.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Peter.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">*******************Internet Email =
Confidentiality Footer******************* </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Qualsiasi utilizzo non autorizzato =
del presente messaggio nonche' dei suoi allegati e' vietato e potrebbe =
costituire reato. Se lei ha ricevuto erroneamente il presente =
messaggio, Le saremmo grati se, via e-mail, ce ne comunicasse la =
ricezione e provvedesse alla distruzione del messaggio stesso e dei =
suoi eventuali allegati. Le dichiarazioni contenute nel presente =
messaggio nonche' nei suoi eventuali allegati devono essere attribuite =
esclusivamente al mittente e non possono essere considerate come =
trasmesse o autorizzate da SIA S.p.A.; le medesime dichiarazioni non =
impegnano SIA S.p.A. nei confronti del destinatario o di terzi. =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">SIA S.p.A. non si assume alcuna =
responsabilita' per eventuali intercettazioni, modifiche o =
danneggiamenti del presente messaggio e-mail. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Any unauthorized use of this e-mail or =
any of its attachments is prohibited and could constitute an offence. =
If you are not the intended addressee please advise immediately the =
sender by using the reply facility in your e-mail software and destroy =
the message and its attachments. The statements and opinions expressed =
in this e-mail message are those of the author of the message and do =
not necessarily represent those of SIA. Besides, The contents of this =
message shall be understood as neither given nor endorsed by SIA =
S.p.A.. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">SIA S.p.A. does not accept liability =
for corruption, interception or amendment, if any, or the consequences =
thereof. </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C41E1E.53FF5D25--

From: "todd glassey" <[email-masked]>
To: "Al Arsenault" <[email-masked]>, "Eric Norman" <[email-masked]>, "PKIX list" <[email-masked]>
Subject: Re: Identity (was PKI International Consortium)
Date: Thu, 8 Apr 2004 19:02:08 -0700
Sender: [email-masked]

----- Original Message ----- 
From: "Al Arsenault" <[email-masked]>
To: "Eric Norman" <[email-masked]>; "PKIX list" <[email-masked]>
Sent: Sunday, April 04, 2004 6:19 PM
Subject: RE: Identity (was PKI International Consortium)

>
>
>
>
> >
> > On Sun, 4 Apr 2004 [email-masked] wrote:
> >
> > > So, again, in the design of Identity Certificates we should
> > concentrate on
> > > Identity issues, and on the needs of systems requiring
> > identification. Trying
> > > to use Identity Certificates for other uses is wrong.
> >
> > Well, my opinion is that you won't have much luck dealing with "Identity
> > issues" until you have a good definition of "identity".
> >
> > Here's my shot at it.  If you start from the premise that identity is
> > just a set of attributes, then your identity is those attributes that
> > are constant and last forever.
>
> AWA:  "reasonably forever". :-) There aren't any attributes guaranteed to
last forever.  People change their names, for reasons of marriage, divorce,
or because they just want to.  Affiliations - employers, university
attended, etc. - change when circumstances change.

DNA is reasonably constant

>
> >
> > So, my "Identity certificate" asserts an association between me and
> > the University of Wisconsin.  Is that part of my identity?  It depends
> > on how you interpret that assertion.  If you interpret it as "was at
> > one time affiliated with that university", then that lasts forever and
> > it is (Winston Smith to the contrary).  If you interpret it as "is
> > currently affiliated...", then it isn't.
> >
> > The only observation I can make right now is that with the former
> > interpretation, Lynn Wheeler doesn't get to use the adjectives "stale"
> > and "static".  Whether that's any more useful than counting angels
> > dancing on pinheads remains to be seen, I suppose.
> >
> >
>
> AWA:  I tend to agree with this.
>
> > Eric Norman
> >
> > "Congress shall make no law restricting the size of integers
> > that may be multiplied together, or the number of times that
> > an integer may be multiplied by itself, or the modulus by
> > which an integer may be reduced".
>
> Al Arsenault
> BBN Technologies
>
> (should I add "no longer a Verizon company"?  :-)
>
>

From: "Al Arsenault" <[email-masked]>
To: "Eric Norman" <[email-masked]>, "PKIX list" <[email-masked]>
Subject: RE: Identity (was PKI International Consortium)
Date: Sun, 4 Apr 2004 21:19:23 -0400
Importance: Normal
Sender: [email-masked]

> 
> On Sun, 4 Apr 2004 [email-masked] wrote:
> 
> > So, again, in the design of Identity Certificates we should 
> concentrate on
> > Identity issues, and on the needs of systems requiring 
> identification. Trying
> > to use Identity Certificates for other uses is wrong.
> 
> Well, my opinion is that you won't have much luck dealing with "Identity
> issues" until you have a good definition of "identity".
> 
> Here's my shot at it.  If you start from the premise that identity is
> just a set of attributes, then your identity is those attributes that
> are constant and last forever.

AWA:  "reasonably forever". :-) There aren't any attributes guaranteed to last forever.  People change their names, for reasons of marriage, divorce, or because they just want to.  Affiliations - employers, university attended, etc. - change when circumstances change. 

> 
> So, my "Identity certificate" asserts an association between me and
> the University of Wisconsin.  Is that part of my identity?  It depends
> on how you interpret that assertion.  If you interpret it as "was at
> one time affiliated with that university", then that lasts forever and
> it is (Winston Smith to the contrary).  If you interpret it as "is
> currently affiliated...", then it isn't.
> 
> The only observation I can make right now is that with the former
> interpretation, Lynn Wheeler doesn't get to use the adjectives "stale"
> and "static".  Whether that's any more useful than counting angels
> dancing on pinheads remains to be seen, I suppose.
> 
>

AWA:  I tend to agree with this.
 
> Eric Norman
> 
> 	"Congress shall make no law restricting the size of integers
> 	that may be multiplied together, or the number of times that
> 	an integer may be multiplied by itself, or the modulus by
> 	which an integer may be reduced".

		Al Arsenault
		BBN Technologies 

	(should I add "no longer a Verizon company"?  :-)

Content-class: urn:content-classes:message
Subject: draft-ietf-pkix-scvp-14.txt
Date: Thu, 8 Apr 2004 16:54:19 -0400
From: "Dave Engberg" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

It is not clear in this draft what the value of the response's
"RequestReference" should be if a non-unique (i.e. cached & signed) DPD
response is provided by the server.  I would recommend making this field
optional, or else clarify that clients should not perform a comparison
unless they have requested a unique response.

Subject: Privacy, personally identifiable information, identity theft
To: PKIX list <[email-masked]>
From: [email-masked]
Date: Thu, 8 Apr 2004 14:51:10 -0600
Sender: [email-masked]

minor references to eu data privacy directive related to those email
issues:
http//www.dmeurope.com/default.asp?ArticleID=1417
http//www.dmnews.com/cgi-bin/artprevbot.cgi?article_id=27045

lynn.wheeler wrote:

we were called in by one of the industry groups to do some work on the cal.
e-sign legistlation ... and then later on the federal bill. their interest
was focused on some of the implications between e-sign and privacy. one of
the things that they had studied was the driving factors behind privacy
legislation ... which they claimed to be 1) identity theft and 2) denial of
(institutional) service. Note that since then, there are issues with
exposure of email addresses ... for instance look at the postings in the
PKIX archive:
http://www.imc.org/ietf-pkix/mail-archive/maillist.html

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-14.txt
Date: Thu, 08 Apr 2004 16:20:57 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-14.txt
	Pages		: 53
	Date		: 2004-4-8
	
SCVP allows a client to offload certificate handling to a server.  
The server can provide the client with a variety of valuable 
information about the certificate, such as whether the certificate 
is valid, a certification path to a trust anchor, and revocation 
status.  SCVP has many purposes, including simplifying client 
implementations and allowing companies to centralize trust and 
policy management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-14.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-scvp-14.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-scvp-14.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-scvp-14.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 08 Apr 2004 16:03:48 -0400
From: "Brian G. Holmes" <[email-masked]>
Organization: Holmespun Solutions, LLC
To: [email-masked]
Subject: Decoding Service Support
Sender: [email-masked]

PKIX Discussion List Members...

I am writing to you in order to determine whether or not I should 
invest more of my time to support the PKIX family of protocols.

I support a free BER for ASN.1 decoding service known as the Berasno 
Decoding Service.  The service was originally established for decoding 
the GSM MAP and ITU TCAP protocols.  Now I am looking for other 
protocols to support.

I am new to the PKIX family of protocols.  In my investigation of RFC 
3280, I found that the protocol has a straight-forward ASN.1 
definition.  It appears that there would be a need to support 
Extensions based on OID; that functionality would be very similar to 
one used to identify GSM MAP information within TCAP.  I may also be 
able to support protocols like the one defined in 
draft-ietf-pkix-tap-00.txt (using RFCs 3280, 3281, 3161, 3369, and 2510).

I am looking for guidance.  I need your opinions, and some sample 
data.  I want the Berasno Decoding Service to be used, so I am looking 
for ways to make it useful.  What protocols would you like to see 
supported?  What information would you like to see presented?  Do you 
have a favorite decode report format?  Should the service support 
Base64 as an input data format?

Thank you for your time.

...Brian

NOTE:  If this is an inappropriate topic for discussion on this list 
then please let a list administrator say so ASAP.  Of course, you are 
welcome to send your responses directly to me.

-- 
Holmespun Solutions, LLC
http://www.holmespun.biz
919-844-7713

Subject: Privacy, personally identifiable information, identity theft
To: PKIX list <[email-masked]>
From: [email-masked]
Date: Thu, 8 Apr 2004 08:19:34 -0600
Sender: [email-masked]

<resend from 4/6, there appears to be some email tarpit>

we were called in by one of the industry groups to do some work on the cal.
e-sign legistlation ... and then later on the federal bill. their interest
was focused on some of the implications between e-sign and privacy. one of
the things that they had studied was the driving factors behind privacy
legislation ... which they claimed to be 1) identity theft and 2) denial of
(institutional) service. Note that since then, there are issues with
exposure of email addresses ... for instance look at the postings in the
PKIX archive:
http://www.imc.org/ietf-pkix/mail-archive/maillist.html

the issue with institutions in the mid-90s retrenching from the early x.509
identity certificates to relying-party-only certificates (basically a
public key and an account number ... or other database index ... where the
actual information might be located) .... wasn't directly an identity theft
issue .... it was the significant privacy issues. Some of the privacy
issues are related to identity theft ... but it isn't solely an identity
theft issue.

the various privacy legislative and regulatory aspects are related to
exposing personal identifiable information ... how and where that
information might be exposed ... regardless of whether or not that
information might be contained in a certificate or any other form. some of
the exposure issues may be related to identity theft.

GLB has a bunch of stuff about sharing of information within an
institutions and/or affiliated third parties. One could imagine a document
(certificate or otherwise) ... where it would be perfectly ok to transmit
and/or exchange between the individual and the primary institution ... but
there would be a requirement that no other entity be allowed to see it. If
some types of that information happened to be contained in a certificate
... then how that certificate was used, how it was transmitted, and who was
allowed to see it might be subject to various privacy legislation and/or
privacy regulations.

Recently issue was rasied that the proposed google email service may be in
violation of various privacy legislation and/or regulations.

In hypothetical scenario an entity digitally signs a perfectly acceptable
transaction. In a certificate-based authentication paradigm, the
certificate could contain personably identifiable information that has
absolutely nothing at all to do with the subject transaction. There could
be one or more relying-parties that had interest in authenticating the
digital signature. Under various legislative and/or regulatory constraints
it might be possible that some relying-parties would not be permitted
access to the certificate because of privacy constraints. Such privacy
constraints might also impose restrictions on how the certificate was
transmitted and/or handled.

Arshad Noor wrote:

I do not believe identity theft will ever be eradicated
regardless of the number of certs.  However, if we assume
that identity certs are useful, then there is some optimal
number that balances the risk against the inconvenience of
carrying too many credentials.  In the absence of objective
research recommending the precise number, or range, the
identity firewalls concept advances one figure.

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Thu, 8 Apr 2004 08:45:15 -0400
From: "Dave Engberg" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

If an SCVP client were implemented to use Microsoft's unpatched ASN.1
parsing library for all aspects of the protocol, then I think the attack
could also be used even if the responses are signed (e.g. I could encode
a bad 'version' for the SignedData or SignerInfo).  If a client were
written to use a different parsing library for all ASN.1, this would not
be a problem.

The only scenario where this would be relevant to the signed/unsigned
question is if requests were processed by a non-broken non-Microsoft
ASN.1 library, but then the raw certificate bytes were handed to the
unpatched Microsoft DLL for parsing.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Thursday, April 08, 2004 7:36 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

I do see some benefit to the signature in light of the current ASN.1
vulnerability.  This will help the clients that have not applied the
patch.

I have not done an analysis of the vulnerability to determine if the
attacker could manipulate the signed payload to exploit the ASN.1 bug in
the client.  I suspect so.

While LDAP is not PKIX, directory world will continue to be vulnerable
to that.

Date: Thu, 08 Apr 2004 08:04:32 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Trevor Freeman <[email-masked]>
CC: Santosh Chokhani <[email-masked]>, [email-masked]
Subject: Re: Signing Untrusted SCVP?
Sender: [email-masked]

There are a large number of protocols (S/MIME, SSL/TLS) that send 
clients an unsigned bag of certificates for path discovery.  The reason 
some of us feel that the "garbage path" client attack is of minor impact 
is because:

* Effort is medium

* Payoff is low:  a few (or even a few dozen) RSA-2048 verifies on the 
client.  I don't believe any client will launch a web browser during a 
path validation attempt, particularly for manufactured certs that don't 
chain to a client's trusted root (since validation goes from the root down).

* The attack is immediately detected by the client as a major problem to 
be remedied

I agree that no client should ever be forced to receive unsigned DPD 
responses, and no server should ever be forced to send unsigned DPD 
responses, but if both the client and the server are willing, I argue 
that unsigned should be possible.

Trevor Freeman wrote:
> I think it is that bad. An attacker is giving you a response which is of
> a content total their making which one would assume the client would
> pass to its own chaining engine who then acts upon it. The simple act of
> trying to validate the bag of carefully crafted certificates at the very
> minimal send some unsuspecting client to the attacker web page. With a
> signed response, if the client explicitly trust the signer, the attacker
> can invalidate the signature or insert an error, but that is about it.
> The client does not take the response at attempt some action upon it.

Date: Thu, 08 Apr 2004 07:46:14 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Trevor Freeman <[email-masked]>
CC: Michael Myers <[email-masked]>, [email-masked]
Subject: Re: SCVP Change Proposal (was: Signing Untrusted SCVP?)
Sender: [email-masked]

Mike's right that my proposal was to allow unsigned responses for pure 
DPD (see my proposed change to Section 3, below), and also to permit 
caching for responses by making the RequestReference optional (Section 4).

Trevor Freeman wrote:
> The proposal is allowing cached responses and the presence or absence of
> the nonce indicates to the server if cached signed responses are
> acceptable.
> Trevor
> 
> From: Michael Myers [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2004 4:09 PM
> To: Trevor Freeman; Dave Engberg; Santosh Chokhani; [email-masked]
> Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?)
> 
> Dave asked about signing DPD responses.  Why are we talking
> about nonces?
> 
> Mike
> 
> 
> On Behalf Of Dave Engberg
> Sent: Wednesday, April 07, 2004 9:11 AM
> To: Santosh Chokhani; [email-masked]
> Subject: SCVP Change Proposal (was: Signing Untrusted SCVP?)
> 
> 
> In Section 3, replace:
> 
>   If a
>   server is responding to an unsigned request or a signed
> request, it
>   MUST use a signed response or an unsigned error response.
> 
> With:
> 
>   If a server is responding to an unsigned request or a signed
> request,
>   it MUST use a signed response or an unsigned error response if
> either
>   of the following is true:
> 
>     - The request wantBack includes one or more of the
> following:
> 
>         * id-swb-pkc-public-key-info
>         * id-swb-pkc-cert-status
>         * id-swb-ac-cert-status
> 
>     - The request includes a requestNonce
> 
>   If neither is true, a server responding to an unsigned request
> or
>   signed request MAY use a signed response, an unsigned
> response, or
>   an unsigned error response.
> 
> 
> In Section 4, replace:
> 
>       requestRef            RequestReference,
> 
> With:
> 
>       requestRef        [0] RequestReference OPTIONAL,
> 
> In Section 4.5, replace:
> 
>   The requestRef allows the SCVP server to identify the request
> that
> 
> With:
> 
>   The OPTIONAL requestRef item allows the SCVP server to
> identify
>   the request that ...

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Thu, 8 Apr 2004 07:39:31 -0400
Importance: Normal
Sender: [email-masked]

I agree

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Myers
Sent: Wednesday, April 07, 2004 4:14 PM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

I think we should just change the relevant MUSTs to "MUST be capable of".

Mike

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Thu, 8 Apr 2004 07:38:22 -0400
Importance: Normal
Sender: [email-masked]

Trevor:

I would say more the server since the client can always ignore the signature
if it wishes and reject an unsigned response.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Trevor Freeman
Sent: Wednesday, April 07, 2004 5:52 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Santosh,

I don't view the benefit as minimal. I see it as blocking some exploits by
attackers. Given we are now allowing cached values to be returned, what is
the concern? Are we trying to help the server or client?

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 12:34 PM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor:

>From technical philosophy viewpoint, I do not have a problem.

But, from my understanding of how IETF works, given that the benefit is
minimal, we need to define the standard that accommodates products with
varying degree of functionality.  I think SCVP requirement to sign DPD
responses may be too much.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Santosh,
My argument cannot be construed as an argument to sign everything. It is an
argument to sign all positive responses. I am equally not convinced that no
singing achieves anything other than weaker security. The act of signing is
not a major burden, especially if this is no longer on a per request basis
and allows the client to be assured of positive. Not signing positive
responses allows an attacker to manipulate the client beyond inserting
errors which is very, very bad.

How the server protects the cache is an implementation decision. Assuming
untrusted transport is reasonable for the RFC.

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 9:00 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor:

This argument can be the basis for signing everything all the time, which we
do not do.

The attacker can still manipulate and inject data.  I am not persuaded by
the argument that checking the signature first will save lot of client
processing time.

If the product developer and consumers want to have the option for not
signing this data, they should.

I see a bigger problem with the DPD server maintaining a cache and some one
attacking that cache (if unsigned) since a stationary server may be easier
to hack at then data in transit.  Now, if the DPD server signed cached paths
on request or if the DPD, you have the same problem.

Also, my suggestion would be for the client to have the option of requesting
signed responses and having the option of rejecting responses that are not
signed.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 11:46 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

I think there is significant value in signing the response from the SCVP
server. Given the main issue seems to be SCVP operating in an environment
where an attacker has the ability to inject packets going between client and
server into the data stream. Signing the response relegates the attacker to
injecting error packets - which is a low grade DoS. Sending unsigned
responses allows the attacker to inject a packed as the server whatever they
want as a genuine response, with certificates  and content of there
choosing. So we just turned every SCVP client into a potential web beacon.
Where the client has direct trust in the server signing key this is a very
secure process with DPD. Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 5:32 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Given the limited value of signature, DPD response signature by the server
should be optional and signature verification by the client should be
optional.

The question we should answer is that is there any benefit to adding an
option for the client to request a signature and then should the DPD server
be forced to sign the response

(shades of OCSP nonce)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of David Engberg
Sent: Tuesday, April 06, 2004 11:32 PM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

Stephen -

You have provided interesting techniques that an attacker could use to 
make a DPD client waste an extra 500ms verifying signatures before 
displaying a "bad path returned from server" dialog (or the equivalent).

That same attacker with the same advantages (DNS spoofing, etc.) could 
achieve the same effective denial of path discovery even if an extra 
signature is thrown on responses.  The attacker could obviously make 
clients waste time & bandwidth in lots of sneaky ways, although the 
relying application would ultimately report different error messages 
("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route 
to host", "response signature verify failed", etc.).

I am curious whether the type of attack that you describe has ever been 
performed against a non-SSL LDAP directory in a manner that would not 
have been equally effective if SSL was in use.

While there is definitely a difference here, I think (hope?) that we 
agree that it may be useful for a PKI administrator to have the choice 
to deploy a path discovery mechanism which does not require a fresh 
signature from a protected server key for every request.  This would 
allow an administrator to balance the DoS risks for clients against the 
DoS risks for servers.

My guess is that virtually all real world DoS attacks exploit the 
centralized nature of secured servers, and the best cure for this is the

sort of distributed redundancy that a keyless or two-tier-caching DPD 
responder architecture would permit.  For example, Akamai has 16,000+ 
servers around the world with no SSL private keys.  They are subjected 
to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail 
not due to the magic of PKI, but rather due to the redundancy you can 
build when you don't have to secure keys at every server.

Thanks

Stephen Kent wrote:
...
> if an attacker can spoof a DNS response, he can cause the client to
> connect to him instead of the server, which would enable the bogus 
> server to receive the request as well as generate and send the 
> response, and in the absence of a signed response, the client cannot 
> know that he is not communicating with the intended server.
>
> a bogus server could then return bogus cert chains that fail to
> validate, but which waste client resources. just how effective this 
> may be will be a function of client implementation details, which are 
> outside the scope of our standards.
...

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Thu, 8 Apr 2004 07:36:23 -0400
Importance: Normal
Sender: [email-masked]

I do see some benefit to the signature in light of the current ASN.1
vulnerability.  This will help the clients that have not applied the patch.

I have not done an analysis of the vulnerability to determine if the
attacker could manipulate the signed payload to exploit the ASN.1 bug in the
client.  I suspect so.

While LDAP is not PKIX, directory world will continue to be vulnerable to
that.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 8:32 PM
To: Dave Engberg; Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Dave,
I think it is that bad. An attacker is giving you a response which is of a
content total their making which one would assume the client would pass to
its own chaining engine who then acts upon it. The simple act of trying to
validate the bag of carefully crafted certificates at the very minimal send
some unsuspecting client to the attacker web page. With a signed response,
if the client explicitly trust the signer, the attacker can invalidate the
signature or insert an error, but that is about it. The client does not take
the response at attempt some action upon it. Trevor -----Original
Message-----
From: Dave Engberg [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 1:23 PM
To: Trevor Freeman; Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

I think that "very, very bad" might be a bit strong.  Steve pointed out that
an attacker could use unsigned responses to waste client CPU resources
before the client rejects an unsigned DPD response, and possibly to lead a
smart client to "hot list" the bad server.  Even with signed responses, an
attacker could achieve the same end result (or
worse) through all of the normal bad-guy means.  For example, spoofed DNS
could send clients to bad IP addresses (30 second timeout while MS Outlook
hangs ...) or servers that faked flaky TCP packets for infinite exponential
backoff, etc.

Steve's right that a signature might allow a very clever client to mitigate
a very specific type of time-wasting client DoS, but obviously an attacker
who can seize your networking or DNS can cause a DoS regardless of whether
the responses are signed.

"Very, very bad" would apply if an attacker could trick a non-buggy client
into accepting a cert for which there is no valid path.  This is absolutly
not possible with unsigned DPD lookups (or non-SSL LDAP), although it
definitely is a risk for "Trusted SCVP" if any server is compromised.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Wednesday, April 07, 2004 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Santosh,
My argument cannot be construed as an argument to sign everything. It is an
argument to sign all positive responses. I am equally not convinced that no
singing achieves anything other than weaker security. The act of signing is
not a major burden, especially if this is no longer on a per request basis
and allows the client to be assured of positive. Not signing positive
responses allows an attacker to manipulate the client beyond inserting
errors which is very, very bad.

From: "Julien Stern" <[email-masked]>
Date: Thu, 8 Apr 2004 12:05:21 +0200
To: [email-masked]
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

On Wed, Apr 07, 2004 at 04:02:41PM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> (snip)
>
> It is also not clear what your thesis or agenda is.
> May be you are still trying understand it.  If you are challenging the
> rules we have proposed for CRL path, let me know.

I am quite honestly still trying to understand.

We have a validation algorithm with policy mappings and CRL/Indirect
CRL/OCSP support. The simple case (one cert -> one chain) is trivial.
We are interested in cases where one can potentially reconstructs many
chains for the certificate and for the CRL/OCSP response.

When I can actually build at least one chain to a TA to
verify the certificate, the revocation status of the certificate can be:
- UNREVOKED
- REVOKED (with reason)
- UNTERMINED

When there is only one revocation source, obviously, different
implementations cannot give UNREVOKED on one hand and REVOKED on the
other, but they could possibly give, say, either REVOKED or UNTERMINED
depending on how they implement verifications. That seems OK: a "smart"
verification algorithm will get the answer, a "simpler" one will just
indicate it did not find it. 

Now, my understanding of RFC3280 is that several entities could
potentially indicate that a given certificate is revoked,
using, say, Indirect CRLs. In this case, am I supposed to assume they
are all in sync ? That the first one checked is authoritative ?
That I have to check them all ?

My MAJOR problem in this case, is that our current algorithm
can give either REVOKED or UNREVOKED depending on:
- Initial Trust Anchors
- Policy mappings
- Even implementations details like path building order or Extension
  processing order

To be specific, I though one could want to have many "Local CAs" issuing
their own CRLs, plus a CRLDP to the CRL of a common "Revocation Center"
which is authorized to process revocations for all the Local CAs. So
maybe this case is just stupid, or even forbidden, but if not, I have a
serious soundness problem in my current verification algorithm ;)

Sincerely,

--
Julien

From: "Muriel Souville" <[email-masked]>
To: "'Ietf-Pkix@Imc. Org'" <[email-masked]>
Subject: ETSI Interoperability Event
Date: Thu, 8 Apr 2004 10:43:59 +0200
Sender: [email-masked]

Dear all,
 
As you probably know, The European Telecommunications Standards 
Institute (ETSI) is organising an interoperability event in the 
field of security. We already have many participants working on 
PKIs and XadES. But some of them are also interested in testing 
IKEv2, that's why we are searching new actors working on this field. 
 
I remind you that the deadline is the 5th of May. 
If you are interested in, please contact us at [email-masked] 
or just take a look at http://www.etsi.org/plugtests/security.htm  
 
Thanks for your attention.
 
Best regards,
 
Muriel SOUVILLE
ETSI Consultant
-----------------------------
+33 3 90 23 63 63

Date: Wed, 07 Apr 2004 21:34:46 -0700
From: Arshad Noor <[email-masked]>
Subject: Re: PKI International Consortium
To: Stephen Kent <[email-masked]>
Cc: PKIX list <[email-masked]>
Organization: StrongAuth, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_wkuYifgQq9RZoSdtOU7r/w)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Stephen Kent wrote:

> At 9:41 PM -0700 4/6/04, Arshad Noor wrote:
> 
>>     Taken to its logical conclusion, an infinite number of
>>     credentials per entity must lead to minimal impact of an
>>     identity theft incident.  However, humans cannot be expected to
>>     deal with such mathematical elegance without becoming blithering
>>     idiots.  (Some of us just need a few Internet accounts to reach
>>     that state :-)).
>>
>>     Therefore, there must be some optimal number between 1 and
>>     infinity that balances risk vs. the inconvenience of carrying
>>     mulitple credentials.  Once again, for lack of empirical
>>     evidence, the identity firewall concept advances seven as the
>>     optimal number.
> 
> this is silly, almost to the point of being absurd. "Seven" as the 
> optimal number sounds practically mystical.
> 
	Anything fantastic appears mystical and absurd if the logic
	behind it is not evident.  Here's the rationale:

	Most people in industrialized nations will deal with companies,
	or agencies, in one or more of the following industries, at some
	point in their lives:

	1) Healthcare - at birth, immunizations, medicines, etc.;
	2) Education - for schools, colleges, professional associations;
	3) Financial - for banks, brokerages, credit unions, etc.
	4) Government - for taxes, permits, licenses, passport;
	5) Employer
	6) Retail/E-commerce - buy books, air tickets, flowers, etc.
	7) Miscellaneous & personal uses - Sign e-mails to attorney,
		or receive encrypted e-mails from accountant, etc.

	By demarcating credential use strictly along industry lines, one
	allows each industry to come up with whatever issuance process
	that will serve their industry, for any legal purpose within
	that industry, without affecting any other industry.

	People may wind up with more or less credentials than seven.  An
	attorney, working for herself may choose never to have an
	Employer credential; and not liking the whole e-commerce
	experience she never buys anything on the Internet.  She may
	well have only 5 credentials.  As a parts supplier to a major
	auto manufacturer, I may be given access to their Supply-Chain
	portal through a Partner credential, perhaps taking my number
	of credentials to eight.  If I supply to 5 auto manufacturers
	and all of them issue me credentials, I will wind up with 12
	credentials.

	At a macro level, the average will wind up being around seven,
	based on the usage pattern enumerated above.

>>
>>> That is also why one ought not assume that use of
>>> certs, as a specific form of credential, will eradicate identity theft.
>>>
>>     To paraphrase you, Steve, "My comment said nothing about
>>     eradicating identity theft."  (I do not believe it can ever be
>>     eradicated - just made difficult enough to deter most people.)
> 
> 
> This paragraph makes no sense. Your previous message explicitly talked 
> about eradicating identity theft, yet you are backtracking here.
> 

	My first posting to the list (see attached) clearly stated that
	"I do not believe identity theft will ever be eradicated
	 regardless of the number of certs.".

> 
> I too am in favor of the use of certs with private keys maintained in 
> hardware tokens and a high assurance issuing process, when the resources 
> being accessed warrant such measures. But, "optimal" is an inappropriate 
> term when we have such a wide range of resources that people access.
> 
	Therein lies the fallacy of PKI - or any other authentication
	technology - today: implied authorization to use of resources
	based on the authentication credential!

	To me, the use of certs with private keys in hardware tokens and
	a high assurance process is good enough only to IDENTIFY the
	presenter of the credential.  I will still want to go through
	whatever number of business rules I choose, to determine whether
	the identified entity has the authorization to use the resource.

	I use the word "optimal" only to refer to the number of
	credentials needed to identify an entity across many industries;
	the term would be highly inappropriate when used in reference to
	authorizations.  I would expect an infinite number of rules to
	exist in the  business world, to accomodate for authorization
	policies that govern how a wide range of resources are used.

Arshad Noor
StrongAuth, Inc.

--Boundary_(ID_wkuYifgQq9RZoSdtOU7r/w)
Content-type: message/rfc822; name="Attached Message"

Date: Mon, 05 Apr 2004 23:27:56 -0700
From: Arshad Noor <[email-masked]>
Subject: Re: PKI International Consortium
In-reply-to: <p06020403bc97150f71da@[128.89.89.75]>
To: Stephen Kent <[email-masked]>
Cc: PKIX list <[email-masked]>
Message-id: <[email-masked]>
Organization: StrongAuth, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
 Gecko/20030624 Netscape/7.1 (ax)
References: <[email-masked]>
 <p06020403bc97150f71da@[128.89.89.75]>

Stephen Kent wrote:

  > two observations:
>     - the implicit ad for your company in the URL above is inappropriate 
> for the PKIX list

	If so, I apologize.  This is the only archived copy of the
	newsletter, and it seemed appropriate to provide the URL to the
	article rather than repeat the concept. However, I will be more
	cognizant of that in the future.

>     - although one might imagine such certs, there are significant 
> adverse privacy implications (see 
> http://www.nap.edu/books/0309088968/html/)

	I will address this after I have had an opportunity to read
	the book.
> 
> identity theft would likely be a bigger concern if we have fewer certs.
> 
	I do not believe identity theft will ever be eradicated
	regardless of the number of certs.  However, if we assume
	that identity certs are useful, then there is some optimal
	number that balances the risk against the inconvenience of
	carrying too many credentials.  In the absence of objective
	research recommending the precise number, or range, the
	identity firewalls concept advances one figure.

> finally, I am concerned that your message seems to be so closely aligned 
> with you company's products. if you want to continue this discussion, 
> please do so without making it seem like an ad for your company's 
> products and services.
> 
	The message expressed a concept for how digital certificates
	can be used to solve some problems in a different way, Steve.  	
	No more, no less.

Arshad Noor
StrongAuth, Inc.

--Boundary_(ID_wkuYifgQq9RZoSdtOU7r/w)--

Date: Wed, 07 Apr 2004 20:40:35 -0700
From: Arshad Noor <[email-masked]>
Subject: Re: Identity Firewall.  Was: PKI International Consortium
To: Anders Rundgren <[email-masked]>
Cc: PKIX list <[email-masked]>
Organization: StrongAuth, Inc.
Sender: [email-masked]

Anders Rundgren wrote:

> Arshad,
> 
> 
>>So, one could get oneself a Financial industry credential, for
>>instance, by going through the industry's issuance process, and
>>yet not have a single bank/brokerage account at all (not very
>>useful, I realize - nonetheless that is the premise).
> 
> 
> Absolutely, this is BTW already a reality in Scandinavia.
> 
	If there are any pointers to websites that describe how
	Scandinavia implements this, Anders, I'd appreciate it.
	Thank you.

> 
>>This individual, armed with the Financial credential, can now
>>approach any financial institution that honored the credential,
>>and open an account.  However, depending on the context of the
>>account & the transactions the individual may wish to carry out
>>against that account, the financial institution may want to
>>determine a number of attributes about that individual before
>>granting him/her that privilege.
> 
> 
> I would extend this to include *any* relying party that is prepared
> to trust FI-issued credentials.  e-governments are the first to make
> use of this.
> 
	I would specifically NOT, Anders.  Here's why.  One of the
	biggest reasons why identity theft is so prevalent today, is
	because of the inappropriate use of identity data for secondary
	uses.  If a specific industry credential were restricted by
	policy and contract, to only companies within that industry,
	the consequences of a compromised credential is restricted to
	only uses within that industry.  Thus, if a FI credential was
	compromised, only the holders banking, brokerage, insurance
	uses might get affected.  The credential that identifies them
	to hospitals, doctors, pharmacies would not.  Neither would the
	credential identifying them to schools, colleges & professional
	associations.  Thus the term "Identity Firewall".

	Even though it is technically, as well as contractually,
	possible for cross-industry uses, by deliberately putting up
	protection barriers between industries, we prevent the
	domino-effect of the compromise of a credential.

> The use of employment-style certificates outside of the company
> border is never going to happen on a wider scale because that idea
> is conceptually completely flawed.  Well, an IBM company badge
> may indeed give you 10% discount at Tony's Pizza, but that's about it.
> 
	In fact, it should not be allowed to happen.  If an airline, a
	hotel or a store wished to give specific company employees a
	discount, let them rely on the Retail Industry credential, or
	issue their own certificate to be stored on the RI smartcard
	or other crypto token.  The principle is the same - if we do
	not allow compromises to cross industry boundaries, then the
	damage is limited to only that industry.

Arshad Noor
StrongAuth, Inc.

Content-class: urn:content-classes:message
Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?)
Date: Wed, 7 Apr 2004 18:58:10 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, "Dave Engberg" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Mike
A specific response is not a cahed response but one made to a specific
request. I am not sold on the description so any suggestions may win a
prize.
Trevor

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 6:31 PM
To: Trevor Freeman; Dave Engberg; Santosh Chokhani; [email-masked]
Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?)

Trevor,

Please define "specific response" as used below in the proposed
amendment to section 3.5.  Nowhere does this term appear in -13
of SCVP.

Mike

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Wednesday, April 07, 2004 5:33 PM

The proposal is allowing cached responses and the presence or
absence of
the nonce indicates to the server if cached signed responses are
acceptable.
Trevor

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Wednesday, April 07, 2004 4:09 PM

Dave asked about signing DPD responses.  Why are we talking
about nonces?

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Wednesday, April 07, 2004 3:25 PM

Hi Dave,
That is almost the proposed change. The presence of the nonce
will
indicate the request for a unique response, and I have added a
wantBack.

3.5 requestNonce

The OPTIONAL requestNonce item contains a request identifier
generated by the SCVP client.  If the client includes a
requestNonce value in the request, it is expressing a
preference the SCVP server SHOULD return a specific response.
If the server returns a specific response it MUST include
the requestNonce from the request in the response, but MAY
return a cached success response which MUST NOT have a
requestNonce. If the client includes a requestNonce and
also sets a wantBack of id-swb-unique-resp-required, the
client is indicating that the SCVP server MUST return either
a specific response including the requestNonce or an error.
The client SHOULD include a requestNonce item in every request
to prevent an attacker from acting as a man-in-the-middle
by replaying old responses from the server.  The requestNonce
value
SHOULD change with every request sent by the client. The client
MUST
NOT include the wantBack of id-swb-unique-resp-required without
a
requestNonce, and a server receiving such a request SHOULD
return an invalidRequest error

Trevor

From: "Michael Myers" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Dave Engberg" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?)
Date: Wed, 7 Apr 2004 18:30:40 -0700
Importance: Normal
Sender: [email-masked]

Trevor,

Please define "specific response" as used below in the proposed
amendment to section 3.5.  Nowhere does this term appear in -13
of SCVP.

Mike

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Wednesday, April 07, 2004 5:33 PM

The proposal is allowing cached responses and the presence or
absence of
the nonce indicates to the server if cached signed responses are
acceptable.
Trevor

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Wednesday, April 07, 2004 4:09 PM

Dave asked about signing DPD responses.  Why are we talking
about nonces?

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Wednesday, April 07, 2004 3:25 PM

Hi Dave,
That is almost the proposed change. The presence of the nonce
will
indicate the request for a unique response, and I have added a
wantBack.

3.5 requestNonce

The OPTIONAL requestNonce item contains a request identifier
generated by the SCVP client.  If the client includes a
requestNonce value in the request, it is expressing a
preference the SCVP server SHOULD return a specific response.
If the server returns a specific response it MUST include
the requestNonce from the request in the response, but MAY
return a cached success response which MUST NOT have a
requestNonce. If the client includes a requestNonce and
also sets a wantBack of id-swb-unique-resp-required, the
client is indicating that the SCVP server MUST return either
a specific response including the requestNonce or an error.
The client SHOULD include a requestNonce item in every request
to prevent an attacker from acting as a man-in-the-middle
by replaying old responses from the server.  The requestNonce
value
SHOULD change with every request sent by the client. The client
MUST
NOT include the wantBack of id-swb-unique-resp-required without
a
requestNonce, and a server receiving such a request SHOULD
return an invalidRequest error

Trevor

Date: Wed, 7 Apr 2004 17:52:45 -0700
To: [email-masked]
From: Paul Hoffman / VPNC <[email-masked]>
Subject: New open-source freeware CA product for creating PKIX certs
Sender: [email-masked]

Greetings again. The VPN Consortium is happy to announce SimpleCA, an 
open-source freeware CA product based on Peter Gutmann's cryptlib 
engine. Full information, including source and pre-made binaries for 
Linux, FreeBSD, and Windows, can be found at 
<http://www.vpnc.org/SimpleCA/>.

This is just version 1. We look forward to hearing suggestions about 
how to make future versions more useful. And, of course, bug reports 
are also welcome.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 7 Apr 2004 17:42:50 -0700 (PDT)
From: "Bill Burns" <[email-masked]>
Subject: Re: key uniqueness in a PKI
To: "Stephen Kent" <[email-masked]>
cc: "Miguel Rodriguez" <[email-masked]>, [email-masked]
Organization: America Online
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
<font face="Tahoma,sans-serif"><font size="2"><span type="cite">Stephen
Kent wrote on 4/7/04, 1:39 PM:</span>
</font></font>
<p><font face="Tahoma,sans-serif" size="2"></font></p>
<blockquote type="cite"  style="border-left: thin solid blue; padding-left: 10px; margin-left: 0pt;"><font  face="Tahoma,sans-serif" size="2"></font>
  <div><font face="Tahoma,sans-serif" size="2">At 10:39 AM -0500
4/7/04, Miguel Rodriguez wrote:</font></div>
  <font face="Tahoma,sans-serif" size="2"></font>
  <blockquote type="cite" cite=""><font face="Arial" size="-1">Where
can I
find information on key pair uniqueness in a PKI? Is this issue
discussed in an RFC?</font></blockquote>
  <font face="Tahoma,sans-serif" size="2"></font>
  <blockquote type="cite" cite=""><font face="Arial" size="-1">I will
also
appreciate comments on this issue, particularly when considering a PKI
with several CAs.</font></blockquote>
  <font face="Tahoma,sans-serif" size="2"></font>
  <blockquote type="cite" cite=""><font face="Tahoma,sans-serif"  size="2">&nbsp;</font></blockquote>
  <font face="Tahoma,sans-serif" size="2"></font>
  <blockquote type="cite" cite=""><font face="Arial" size="-1">Thanks.</font></blockquote>
  <font face="Tahoma,sans-serif" size="2"></font>
  <blockquote type="cite" cite=""><font face="Tahoma,sans-serif"  size="2">&nbsp;</font></blockquote>
  <font face="Tahoma,sans-serif" size="2"></font>
  <blockquote type="cite" cite=""><font face="Arial" size="-1">Miguel A
Rodriguez</font></blockquote>
  <font face="Tahoma,sans-serif" size="2"></font>
  <blockquote type="cite" cite=""><font face="Arial" size="-1">SeguriData</font></blockquote>
  <font face="Tahoma,sans-serif" size="2"></font>
  <blockquote type="cite" cite=""><font face="Arial" size="-1">Mexico</font></blockquote>
  <font face="Tahoma,sans-serif" size="2"></font>
  <div><font face="Tahoma,sans-serif" size="2"><br>
  </font></div>
  <font face="Tahoma,sans-serif" size="2"></font>
  <div><font face="Tahoma,sans-serif" size="2">there is no
standards-based requirement that a CA verify that
each cert request contain a unique public key, neither globally nor
relative to the certs that the CA has perviously issued.&nbsp; A CA
might choose to try to make checks relative to the certs it has
issued, and for which it still has this info, but there is no
requirement to do so in X.509 nor PKIX standards.</font></div>
  <font face="Tahoma,sans-serif" size="2"></font>
  <div><font face="Tahoma,sans-serif" size="2"><br>
  </font></div>
  <font face="Tahoma,sans-serif" size="2"></font>
  <div><font face="Tahoma,sans-serif" size="2">Steve</font></div>
</blockquote>
<font size="2"><font face="Tahoma,sans-serif"><br>
</font></font><font face="Tahoma,sans-serif" size="2"><font size="2">FWIW,
there's also a
mention of this in the WebTrust for CA's documentation.&nbsp; It's not a
"requirement" per se, but they seem to suggest that it's a good idea.&nbsp;
Nevertheless, that's a pretty expensive operation to
perform...especially as the Member base grows.<br>
<br>
bill</font></font><br>
</body>
</html>

Content-class: urn:content-classes:message
Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?)
Date: Wed, 7 Apr 2004 17:33:25 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, "Dave Engberg" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The proposal is allowing cached responses and the presence or absence of
the nonce indicates to the server if cached signed responses are
acceptable.
Trevor

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 4:09 PM
To: Trevor Freeman; Dave Engberg; Santosh Chokhani; [email-masked]
Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?)

Dave asked about signing DPD responses.  Why are we talking
about nonces?

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Wednesday, April 07, 2004 3:25 PM
To: Dave Engberg; Santosh Chokhani; [email-masked]
Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?)

Hi Dave,
That is almost the proposed change. The presence of the nonce
will
indicate the request for a unique response, and I have added a
wantBack.

3.5 requestNonce

The OPTIONAL requestNonce item contains a request identifier
generated
by the SCVP client.  If the client includes a requestNonce value
in the
request, it is expressing a preference the SCVP server SHOULD
return a
specific response. If the server returns a specific response it
MUST
include the requestNonce from the request in the response, but
MAY
return a cached success response which MUST NOT have a
requestNonce. If
the client includes a requestNonce and also sets a wantBack of
id-swb-unique-resp-required, the client is indicating that the
SCVP
server MUST return either a specific response including the
requestNonce
or an error.  The client SHOULD include a requestNonce item in
every
request to prevent an attacker from acting as a
man-in-the-middle by
replaying old responses from the server.  The requestNonce value
SHOULD
change with every request sent by the client. The client MUST
NOT
include the wantBack of id-swb-unique-resp-required without a
requestNonce, and a server receiving such a request SHOULD
return an
invalidRequest error

Trevor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Wednesday, April 07, 2004 9:11 AM
To: Santosh Chokhani; [email-masked]
Subject: SCVP Change Proposal (was: Signing Untrusted SCVP?)

Thanks, Santosh.  Here's a specific list of changes to SCVP
Draft 13
that would allow the use of signatures to be optional on pure
DPD
lookups, and permit server caching of signed responses when
mutually
acceptable by server and client security policies.  Rather than
defining
a new request extension to signal a desire for a fresh
signature, this
proposal uses the request nonce.  I assume there would be
agreement that
any client who sends a nonce would not want an unsigned or
cached
response in return, but I wouldn't have any problem with
defining a
separate new extension if that makes the intent more clear.

The section 3 changes are separate from section 4, and either
could be
adopted independently.

In Section 3, replace:

  If a
  server is responding to an unsigned request or a signed
request, it
  MUST use a signed response or an unsigned error response.

With:

  If a server is responding to an unsigned request or a signed
request,
  it MUST use a signed response or an unsigned error response if
either
  of the following is true:

    - The request wantBack includes one or more of the
following:

        * id-swb-pkc-public-key-info
        * id-swb-pkc-cert-status
        * id-swb-ac-cert-status

    - The request includes a requestNonce

  If neither is true, a server responding to an unsigned request
or
  signed request MAY use a signed response, an unsigned
response, or
  an unsigned error response.

In Section 4, replace:

      requestRef            RequestReference,

With:

      requestRef        [0] RequestReference OPTIONAL,

In Section 4.5, replace:

  The requestRef allows the SCVP server to identify the request
that

With:

  The OPTIONAL requestRef item allows the SCVP server to
identify
  the request that ...

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 8:32 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Given the limited value of signature, DPD response signature by
the
server should be optional and signature verification by the
client
should be optional.

The question we should answer is that is there any benefit to
adding an
option for the client to request a signature and then should the
DPD
server be forced to sign the response

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Wed, 7 Apr 2004 17:31:33 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Dave Engberg" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Dave,
I think it is that bad. An attacker is giving you a response which is of
a content total their making which one would assume the client would
pass to its own chaining engine who then acts upon it. The simple act of
trying to validate the bag of carefully crafted certificates at the very
minimal send some unsuspecting client to the attacker web page. With a
signed response, if the client explicitly trust the signer, the attacker
can invalidate the signature or insert an error, but that is about it.
The client does not take the response at attempt some action upon it.
Trevor
-----Original Message-----
From: Dave Engberg [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 1:23 PM
To: Trevor Freeman; Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

I think that "very, very bad" might be a bit strong.  Steve pointed out
that an attacker could use unsigned responses to waste client CPU
resources before the client rejects an unsigned DPD response, and
possibly to lead a smart client to "hot list" the bad server.  Even with
signed responses, an attacker could achieve the same end result (or
worse) through all of the normal bad-guy means.  For example, spoofed
DNS could send clients to bad IP addresses (30 second timeout while MS
Outlook hangs ...) or servers that faked flaky TCP packets for infinite
exponential backoff, etc.

Steve's right that a signature might allow a very clever client to
mitigate a very specific type of time-wasting client DoS, but obviously
an attacker who can seize your networking or DNS can cause a DoS
regardless of whether the responses are signed.

"Very, very bad" would apply if an attacker could trick a non-buggy
client into accepting a cert for which there is no valid path.  This is
absolutly not possible with unsigned DPD lookups (or non-SSL LDAP),
although it definitely is a risk for "Trusted SCVP" if any server is
compromised.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Wednesday, April 07, 2004 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Santosh,
My argument cannot be construed as an argument to sign everything. It is
an argument to sign all positive responses. I am equally not convinced
that no singing achieves anything other than weaker security. The act of
signing is not a major burden, especially if this is no longer on a per
request basis and allows the client to be assured of positive. Not
signing positive responses allows an attacker to manipulate the client
beyond inserting errors which is very, very bad.

From: "Michael Myers" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Dave Engberg" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?)
Date: Wed, 7 Apr 2004 16:09:02 -0700
Importance: Normal
Sender: [email-masked]

Dave asked about signing DPD responses.  Why are we talking
about nonces?

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Wednesday, April 07, 2004 3:25 PM
To: Dave Engberg; Santosh Chokhani; [email-masked]
Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?)

Hi Dave,
That is almost the proposed change. The presence of the nonce
will
indicate the request for a unique response, and I have added a
wantBack.

3.5 requestNonce

The OPTIONAL requestNonce item contains a request identifier
generated
by the SCVP client.  If the client includes a requestNonce value
in the
request, it is expressing a preference the SCVP server SHOULD
return a
specific response. If the server returns a specific response it
MUST
include the requestNonce from the request in the response, but
MAY
return a cached success response which MUST NOT have a
requestNonce. If
the client includes a requestNonce and also sets a wantBack of
id-swb-unique-resp-required, the client is indicating that the
SCVP
server MUST return either a specific response including the
requestNonce
or an error.  The client SHOULD include a requestNonce item in
every
request to prevent an attacker from acting as a
man-in-the-middle by
replaying old responses from the server.  The requestNonce value
SHOULD
change with every request sent by the client. The client MUST
NOT
include the wantBack of id-swb-unique-resp-required without a
requestNonce, and a server receiving such a request SHOULD
return an
invalidRequest error

Trevor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Wednesday, April 07, 2004 9:11 AM
To: Santosh Chokhani; [email-masked]
Subject: SCVP Change Proposal (was: Signing Untrusted SCVP?)

Thanks, Santosh.  Here's a specific list of changes to SCVP
Draft 13
that would allow the use of signatures to be optional on pure
DPD
lookups, and permit server caching of signed responses when
mutually
acceptable by server and client security policies.  Rather than
defining
a new request extension to signal a desire for a fresh
signature, this
proposal uses the request nonce.  I assume there would be
agreement that
any client who sends a nonce would not want an unsigned or
cached
response in return, but I wouldn't have any problem with
defining a
separate new extension if that makes the intent more clear.

The section 3 changes are separate from section 4, and either
could be
adopted independently.

In Section 3, replace:

  If a
  server is responding to an unsigned request or a signed
request, it
  MUST use a signed response or an unsigned error response.

With:

  If a server is responding to an unsigned request or a signed
request,
  it MUST use a signed response or an unsigned error response if
either
  of the following is true:

    - The request wantBack includes one or more of the
following:

        * id-swb-pkc-public-key-info
        * id-swb-pkc-cert-status
        * id-swb-ac-cert-status

    - The request includes a requestNonce

  If neither is true, a server responding to an unsigned request
or
  signed request MAY use a signed response, an unsigned
response, or
  an unsigned error response.

In Section 4, replace:

      requestRef            RequestReference,

With:

      requestRef        [0] RequestReference OPTIONAL,

In Section 4.5, replace:

  The requestRef allows the SCVP server to identify the request
that

With:

  The OPTIONAL requestRef item allows the SCVP server to
identify
  the request that ...

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 8:32 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Given the limited value of signature, DPD response signature by
the
server should be optional and signature verification by the
client
should be optional.

The question we should answer is that is there any benefit to
adding an
option for the client to request a signature and then should the
DPD
server be forced to sign the response

Date: Wed, 07 Apr 2004 15:58:56 -0700
From: Ed Gerck <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: clarification proposal -- Re: Current status of CRL validation?
Sender: [email-masked]

Stefan Santesson wrote:
> 
> Or as RFC 3280 currently defines it in section 6, top of page 65:
> 
>   "A particular certification path may not, however, be appropriate for
>    all applications.  Therefore, an application MAY augment this
>    algorithm to further limit the set of valid paths. "

That text would be clearer if "RP software" replaces "application". 
Otherwise, I agree that it does seem equivalent to:

    Since there may be more than one path used to validate the same
    certificate, it is possible that some paths to that certificate
    are valid for some RPs while not valid to other RPs.

BTW, the purpose of the clarification Note (that includes the paragraph 
above) is not to reinvent or change X.509 or related RFCs. The purpose is 
to clarify and unify EXISTING references (including WG context interpretation)
in regard to certificate revocation. There should be lots of paragraphs 
in X.509 and related RFCs that are, with analysis, equivalent to the 
Note and vice versa. The only informative aspect of the Note should be 
in terms of ambiguity resolution.

Cheers,
Ed Gerck

Content-class: urn:content-classes:message
Subject: RE: SCVP Change Proposal (was: Signing Untrusted SCVP?)
Date: Wed, 7 Apr 2004 15:25:01 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Dave Engberg" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Dave,
That is almost the proposed change. The presence of the nonce will
indicate the request for a unique response, and I have added a wantBack.

3.5 requestNonce

The OPTIONAL requestNonce item contains a request identifier generated
by the SCVP client.  If the client includes a requestNonce value in the
request, it is expressing a preference the SCVP server SHOULD return a
specific response. If the server returns a specific response it MUST
include the requestNonce from the request in the response, but MAY
return a cached success response which MUST NOT have a requestNonce. If
the client includes a requestNonce and also sets a wantBack of
id-swb-unique-resp-required, the client is indicating that the SCVP
server MUST return either a specific response including the requestNonce
or an error.  The client SHOULD include a requestNonce item in every
request to prevent an attacker from acting as a man-in-the-middle by
replaying old responses from the server.  The requestNonce value SHOULD
change with every request sent by the client. The client MUST NOT
include the wantBack of id-swb-unique-resp-required without a
requestNonce, and a server receiving such a request SHOULD return an
invalidRequest error

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Wednesday, April 07, 2004 9:11 AM
To: Santosh Chokhani; [email-masked]
Subject: SCVP Change Proposal (was: Signing Untrusted SCVP?)

Thanks, Santosh.  Here's a specific list of changes to SCVP Draft 13
that would allow the use of signatures to be optional on pure DPD
lookups, and permit server caching of signed responses when mutually
acceptable by server and client security policies.  Rather than defining
a new request extension to signal a desire for a fresh signature, this
proposal uses the request nonce.  I assume there would be agreement that
any client who sends a nonce would not want an unsigned or cached
response in return, but I wouldn't have any problem with defining a
separate new extension if that makes the intent more clear.

The section 3 changes are separate from section 4, and either could be
adopted independently.

In Section 3, replace:

  If a 
  server is responding to an unsigned request or a signed request, it 
  MUST use a signed response or an unsigned error response.

With:

  If a server is responding to an unsigned request or a signed request,
  it MUST use a signed response or an unsigned error response if either
  of the following is true:

    - The request wantBack includes one or more of the following:

        * id-swb-pkc-public-key-info
        * id-swb-pkc-cert-status
        * id-swb-ac-cert-status

    - The request includes a requestNonce
        
  If neither is true, a server responding to an unsigned request or
  signed request MAY use a signed response, an unsigned response, or
  an unsigned error response.

In Section 4, replace:

      requestRef            RequestReference, 

With:

      requestRef        [0] RequestReference OPTIONAL,

In Section 4.5, replace:

  The requestRef allows the SCVP server to identify the request that 

With:

  The OPTIONAL requestRef item allows the SCVP server to identify
  the request that ...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 8:32 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Given the limited value of signature, DPD response signature by the
server should be optional and signature verification by the client
should be optional.

The question we should answer is that is there any benefit to adding an
option for the client to request a signature and then should the DPD
server be forced to sign the response

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Wed, 7 Apr 2004 14:51:37 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Santosh,

I don't view the benefit as minimal. I see it as blocking some exploits
by attackers. Given we are now allowing cached values to be returned,
what is the concern? Are we trying to help the server or client?

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 12:34 PM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor:

>From technical philosophy viewpoint, I do not have a problem.

But, from my understanding of how IETF works, given that the benefit is
minimal, we need to define the standard that accommodates products with
varying degree of functionality.  I think SCVP requirement to sign DPD
responses may be too much.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Santosh,
My argument cannot be construed as an argument to sign everything. It is
an
argument to sign all positive responses. I am equally not convinced that
no
singing achieves anything other than weaker security. The act of signing
is
not a major burden, especially if this is no longer on a per request
basis
and allows the client to be assured of positive. Not signing positive
responses allows an attacker to manipulate the client beyond inserting
errors which is very, very bad.

How the server protects the cache is an implementation decision.
Assuming
untrusted transport is reasonable for the RFC.

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 9:00 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor:

This argument can be the basis for signing everything all the time,
which we
do not do.

The attacker can still manipulate and inject data.  I am not persuaded
by
the argument that checking the signature first will save lot of client
processing time.

If the product developer and consumers want to have the option for not
signing this data, they should.

I see a bigger problem with the DPD server maintaining a cache and some
one
attacking that cache (if unsigned) since a stationary server may be
easier
to hack at then data in transit.  Now, if the DPD server signed cached
paths
on request or if the DPD, you have the same problem.

Also, my suggestion would be for the client to have the option of
requesting
signed responses and having the option of rejecting responses that are
not
signed.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 11:46 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

I think there is significant value in signing the response from the SCVP
server. Given the main issue seems to be SCVP operating in an
environment
where an attacker has the ability to inject packets going between client
and
server into the data stream. Signing the response relegates the attacker
to
injecting error packets - which is a low grade DoS. Sending unsigned
responses allows the attacker to inject a packed as the server whatever
they
want as a genuine response, with certificates  and content of there
choosing. So we just turned every SCVP client into a potential web
beacon.
Where the client has direct trust in the server signing key this is a
very
secure process with DPD. Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 5:32 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Given the limited value of signature, DPD response signature by the
server
should be optional and signature verification by the client should be
optional.

The question we should answer is that is there any benefit to adding an
option for the client to request a signature and then should the DPD
server
be forced to sign the response

(shades of OCSP nonce)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of David Engberg
Sent: Tuesday, April 06, 2004 11:32 PM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

Stephen -

You have provided interesting techniques that an attacker could use to 
make a DPD client waste an extra 500ms verifying signatures before 
displaying a "bad path returned from server" dialog (or the equivalent).

That same attacker with the same advantages (DNS spoofing, etc.) could 
achieve the same effective denial of path discovery even if an extra 
signature is thrown on responses.  The attacker could obviously make 
clients waste time & bandwidth in lots of sneaky ways, although the 
relying application would ultimately report different error messages 
("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route 
to host", "response signature verify failed", etc.).

I am curious whether the type of attack that you describe has ever been 
performed against a non-SSL LDAP directory in a manner that would not 
have been equally effective if SSL was in use.

While there is definitely a difference here, I think (hope?) that we 
agree that it may be useful for a PKI administrator to have the choice 
to deploy a path discovery mechanism which does not require a fresh 
signature from a protected server key for every request.  This would 
allow an administrator to balance the DoS risks for clients against the 
DoS risks for servers.

My guess is that virtually all real world DoS attacks exploit the 
centralized nature of secured servers, and the best cure for this is the

sort of distributed redundancy that a keyless or two-tier-caching DPD 
responder architecture would permit.  For example, Akamai has 16,000+ 
servers around the world with no SSL private keys.  They are subjected 
to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail 
not due to the magic of PKI, but rather due to the redundancy you can 
build when you don't have to secure keys at every server.

Thanks

Stephen Kent wrote:
...
> if an attacker can spoof a DNS response, he can cause the client to 
> connect to him instead of the server, which would enable the bogus 
> server to receive the request as well as generate and send the 
> response, and in the absence of a signed response, the client cannot 
> know that he is not communicating with the intended server.
>
> a bogus server could then return bogus cert chains that fail to 
> validate, but which waste client resources. just how effective this 
> may be will be a function of client implementation details, which are 
> outside the scope of our standards.
...

Content-class: urn:content-classes:message
Subject: RE: clarification proposal -- Re: Current status of CRL validation?
Date: Wed, 7 Apr 2004 22:51:00 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Ed Gerck" <[email-masked]>, "PKIX" <[email-masked]>
Sender: [email-masked]

Or as RFC 3280 currently defines it in section 6, top of page 65:

  "A particular certification path may not, however, be appropriate for
   all applications.  Therefore, an application MAY augment this
   algorithm to further limit the set of valid paths. "

/Stefan

> On Behalf Of Ed Gerck
> Sent: den 7 april 2004 11:47
> To: PKIX
> Subject: Re: clarification proposal -- Re: Current status of CRL
> validation?
> 
> 
> 
> 
> Stefan Santesson wrote:
> >
> > The basic assumption for the whole discussion seems to be very
confused:
> >
> > Snip:
> > >
> > >    "Since there may be more than one path used to validate the
> > >    same certificate, it is possible that some paths to that
> > >    certificate are valid while others are not."
> > >
> >
> > There is only 1 kind of path that can be used to validate a
certificate,
> > and that is a valid path.
> 
> Valid to a RP may not be valid to another RP. To clarify this,
> the text could say:
> 
>  Since there may be more than one path used to validate the same
>  certificate, it is possible that some paths to that certificate
>  are valid for some RPs while not valid to other RPs.
> 
> > Valid being defined as a path that pass the
> > RPs validation policy (defined at the discretion of the relying
party).
> 
> Exactly. It depends on what each RP may choose to rely upon. Different
> RPs may define "valid path" in a different way.
> 
> The RP may also receive different answers from valid paths.
> 
> > All other paths are invalid by definition. So among the valid paths
> > there is no ambiguity, since they are all valid.
> >
> > Why complicate things?
> 
> The RPs are complicated ;-)
> 
> Cheers,
> Ed Gerck

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Re-certification
Date: Wed, 7 Apr 2004 17:30:16 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

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

In that case, the following may work:

1.  The new CA reissues all the old CA issued certificates that are not
yet expired.  It can keep the same serial number if possible.

2.  Everyone has the new root using secure means.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Rodrigo Botafogo
Sent: Wednesday, April 07, 2004 4:05 PM
To: [email-masked]
Subject: RES: Re-certification

Santosh,

Sorry, I missed your reply.  But unfortunately, my product does not allow
me to have two CAs with the same DN active at the same time.  So, once I
create the new CA, I'll have to deactivate somehow the old CA.

But I agree, that probably would be a good solution.

Thanks

Rodrigo Botafogo

> As my answer said, there would not be a problem with CRL since each
serial
> number will be unique and both keys will be used to sign the CRL.
> 
> Please go back and read my response.
> 

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

------=_NextPart_000_01D2_01C41CC5.FDBF1530--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Wed, 7 Apr 2004 16:48:11 -0400
Importance: Normal
Sender: [email-masked]

Steve:

I agree.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 4:15 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

At 3:33 PM -0400 4/7/04, Santosh Chokhani wrote:
>Trevor:
>
>>From technical philosophy viewpoint, I do not have a problem.
>
>But, from my understanding of how IETF works, given that the benefit is 
>minimal, we need to define the standard that accommodates products with 
>varying degree of functionality.  I think SCVP requirement to sign DPD 
>responses may be too much.

This is a value judgement call. If one starts from the premise that 
the benefit is minimal, then the answer seems obvious. if one does 
not characterize the benefit that way, the answer is probably 
different.

Steve

Date: Wed, 7 Apr 2004 16:34:49 -0400
To: "Julien Stern" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Current status of CRL validation ?
Cc: [email-masked]
Sender: [email-masked]

At 6:35 PM +0200 4/7/04, Julien Stern wrote:
>On Wed, Apr 07, 2004 at 12:07:34PM -0400, Santosh Chokhani wrote:
>>
>>  Julien:
>>
>>  I am not sure that two distinct CAs with the same key (putting aside the
>>  same DN) should be the basis for analysis.  That situation will always lead
>>  to problems.  We are relying on randomness of large numbers to help us that
>>  this will not happen.
>>
>>  Consider providing an example where different CAs do not have the same key.
>
>You should view my "two" CAs as the same CA with two different keys.
>I might not have been totally clear about that, sorry.
>This can be "either due to multiple concurrent key pairs or
>due to changeover" (to quote RFC3280 :)).

Well, that would make this a very different example. it also means 
that the two CAs, with different keys, would not both point to the 
same cert, since that would yield different cert signatures.

So, let me suggest you recreate a valid example before we expend any 
more ffort on this.

Steve

Date: Wed, 7 Apr 2004 16:39:48 -0400
To: "Miguel Rodriguez" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key uniqueness in a PKI
Cc: <[email-masked]>
Sender: [email-masked]

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

At 10:39 AM -0500 4/7/04, Miguel Rodriguez wrote:
>Where can I find information on key pair uniqueness in a PKI? Is 
>this issue discussed in an RFC?
>I will also appreciate comments on this issue, particularly when 
>considering a PKI with several CAs.
>
>Thanks.
>
>Miguel A Rodriguez
>SeguriData
>Mexico

there is no standards-based requirement that a CA verify that each 
cert request contain a unique public key, neither globally nor 
relative to the certs that the CA has perviously issued.  A CA might 
choose to try to make checks relative to the certs it has issued, and 
for which it still has this info, but there is no requirement to do 
so in X.509 nor PKIX standards.

Steve
--============_-1130752094==_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: key uniqueness in a PKI</title></head><body>
<div>At 10:39 AM -0500 4/7/04, Miguel Rodriguez wrote:</div>
<blockquote type="cite" cite><font face="Arial" size="-1">Where can I
find information on key pair uniqueness in a PKI? Is this issue
discussed in an RFC?</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I will also
appreciate comments on this issue, particularly when considering a PKI
with several CAs.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">Thanks.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Miguel A
Rodriguez</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">SeguriData</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">Mexico</font></blockquote>
<div><br></div>
<div>there is no standards-based requirement that a CA verify that
each cert request contain a unique public key, neither globally nor
relative to the certs that the CA has perviously issued.&nbsp; A CA
might choose to try to make checks relative to the certs it has
issued, and for which it still has this info, but there is no
requirement to do so in X.509 nor PKIX standards.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1130752094==_ma============--

Date: Wed, 7 Apr 2004 16:15:25 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Cc: <[email-masked]>
Sender: [email-masked]

At 3:33 PM -0400 4/7/04, Santosh Chokhani wrote:
>Trevor:
>
>>From technical philosophy viewpoint, I do not have a problem.
>
>But, from my understanding of how IETF works, given that the benefit is
>minimal, we need to define the standard that accommodates products with
>varying degree of functionality.  I think SCVP requirement to sign DPD
>responses may be too much.

This is a value judgement call. If one starts from the premise that 
the benefit is minimal, then the answer seems obvious. if one does 
not characterize the benefit that way, the answer is probably 
different.

Steve

Date: Wed, 07 Apr 2004 13:32:53 -0700
From: Ed Gerck <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation?
Sender: [email-masked]

Santosh Chokhani wrote:
> 
> Ed:
> 
> I see no benefit of having this dialog.  Our understanding of security, PKI,
> X.509, 3280, and ASN.1 are so far apart, I better go and back to
> kindergarten and learn some stuff.

;-) we have not discussed ASN.1 yet, so how could you have guessed?

> Rest of the PKIXers:
> 
> My lack of response to Ed on this thread from now on should not be viewed as
> concurrence.

That's SOP. Anyway, I have benefited greatly by your responses
and I am always happy to see your comments as you usually bring 
a different POV.

Cheers,
Ed Gerck

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Wed, 7 Apr 2004 16:23:06 -0400
From: "Dave Engberg" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I think that "very, very bad" might be a bit strong.  Steve pointed out
that an attacker could use unsigned responses to waste client CPU
resources before the client rejects an unsigned DPD response, and
possibly to lead a smart client to "hot list" the bad server.  Even with
signed responses, an attacker could achieve the same end result (or
worse) through all of the normal bad-guy means.  For example, spoofed
DNS could send clients to bad IP addresses (30 second timeout while MS
Outlook hangs ...) or servers that faked flaky TCP packets for infinite
exponential backoff, etc.

Steve's right that a signature might allow a very clever client to
mitigate a very specific type of time-wasting client DoS, but obviously
an attacker who can seize your networking or DNS can cause a DoS
regardless of whether the responses are signed.

"Very, very bad" would apply if an attacker could trick a non-buggy
client into accepting a cert for which there is no valid path.  This is
absolutly not possible with unsigned DPD lookups (or non-SSL LDAP),
although it definitely is a risk for "Trusted SCVP" if any server is
compromised.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
Sent: Wednesday, April 07, 2004 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Santosh,
My argument cannot be construed as an argument to sign everything. It is
an argument to sign all positive responses. I am equally not convinced
that no singing achieves anything other than weaker security. The act of
signing is not a major burden, especially if this is no longer on a per
request basis and allows the client to be assured of positive. Not
signing positive responses allows an attacker to manipulate the client
beyond inserting errors which is very, very bad.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Wed, 7 Apr 2004 13:13:49 -0700
Importance: Normal
Sender: [email-masked]

I think we should just change the relevant MUSTs to "MUST be
capable of".

Mike

From: "Rodrigo Botafogo" <[email-masked]>
To: <[email-masked]>
Subject: RES: Re-certification
Date: Wed, 7 Apr 2004 17:05:03 -0300
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_03A2_01C41CC2.77081CB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Santosh,

Sorry, I missed your reply.  But unfortunately, my product does not
allow me to have two CAs with the same DN active at the same time.  So,
once I create the new CA, I'll have to deactivate somehow the old CA.

But I agree, that probably would be a good solution.

Thanks

Rodrigo Botafogo

> As my answer said, there would not be a problem with CRL since each
serial
> number will be unique and both keys will be used to sign the CRL.
> 
> Please go back and read my response.
> 

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

------=_NextPart_000_03A2_01C41CC2.77081CB0--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Current status of CRL validation ?
Date: Wed, 7 Apr 2004 16:02:41 -0400
Importance: Normal
Sender: [email-masked]

Julien:

There is still poor terminology being used.  Neither multiple concurrent key
pairs nor rekey will lead to the same CA to have the same key. Actually, it
is the other way around.  The DN will be the same and the keys will be
different.

Nonetheless, I will try to deal with your example assuming that it is the
same CA.

First of all, if you can not find a CRL that does not mean you conclude the
certificate to be valid.

Second, if the certification path you have for the CRL does not match, you
do not give up, you try other paths.

One of the basic tricks is: try to verify the signature on the CRL using the
same CA public key as you used to verify the signature on the certificate
whose status you want to check.

If that does not succeed, you can create variation of that path one link at
a time to account for re-key.

Your example has errors and lack of specificity to answer the question.

The simply answer is that you do not need a separate path for CRL since PK4
is used to sign both the certificate and CRL.

It is also not clear what your thesis or agenda is.

May be you are still trying understand it.  If you are challenging the rules
we have proposed for CRL path, let me know.

May be you are saying that certificate issuing CA may not be the only
authoritative source for revocation information.  If that is the case, I
agree with you, but your example does not illustrate that.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Wednesday, April 07, 2004 12:35 PM
To: [email-masked]
Subject: Re: Current status of CRL validation ?

On Wed, Apr 07, 2004 at 12:07:34PM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> I am not sure that two distinct CAs with the same key (putting aside 
> the same DN) should be the basis for analysis.  That situation will 
> always lead to problems.  We are relying on randomness of large 
> numbers to help us that this will not happen.
> 
> Consider providing an example where different CAs do not have the same 
> key.

You should view my "two" CAs as the same CA with two different keys. I might
not have been totally clear about that, sorry. This can be "either due to
multiple concurrent key pairs or due to changeover" (to quote RFC3280 :)).

--
Julien

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Wednesday, April 07, 2004 10:45 AM
> To: [email-masked]
> Subject: Re: Current status of CRL validation ?
> 
> 
> 
> On Tue, Mar 23, 2004 at 11:56:01AM -0500, Stephen Kent wrote:
> > 
> > Julien,
> > 
> > The confusion stems from somewhat sloppy use of terminology in these 
> > discussions.
> > 
> > Only the issuer of a cert can revoke it and in X.509 (unlike PGP) 
> > there is only one issuer for a given cert. So, the revocation 
> > question as you stated it was not well formed.
> 
> Stephen,
> 
> I do not believe that only the issuer of a cert can revoke it, notably 
> when indirect CRL are used.
> 
> > A cert is either revoked or not.
> 
> Well, I'm sincerely starting to believe this is not true :) and not 
> because of lack of available information. Please point me to the flaw 
> in the following setting:
> 
>        +-----+        +-----+    I have a certificate (Cert). Two
>        | CA1 |        |     |    Different CAs (CA4 and CA5) have
>        | DN1 |        | DN1 |    matching issuer DN and keys for it.
>        | PK1 |        |     |
>        +-----+        +-----+    These two CAs have two super CAs
>         /   \            |       signed by the same root.
>   +-----+   +-----+   +-----+
>   | CA2 |   | CA3 |   |     |    I also have a CRL which refers to
>   | DN2 |   | DN3 |   | DN3 |    the certificate but whose only
>   | PK2 |   | PK3 |   |     |    chain up to DN1 is going through
>   +-----+   +-----+   +-----+    DN4 and DN3 (but NOT DN2).
>      |         |         |
>   +-----+   +-----+   +-----+    Now assume that the left path
>   | CA4 |   | CA5 |   |     |    (CA1 -> CA2 -> CA4 -> Cert)
>   | DN4 |   | DN4 |   | DN4 |    is valid for SOME policies, and
>   | PK4 |   | PK4 |   |     |    the right path is valid for some
>   +-----+   +-----+   +-----+    OTHER policies.
>        \     /           |
>        +-----+        +-----+
>        |Cert |        | CRL |
>        +-----+        +-----+
>  
> If I try to validate the certificate with the "left" policy mappings, 
> only the "left" chain will be valid. Then, I will check the chain for 
> the CRL, which will be valid and will match the DN matching rule, so I 
> will conclude that the certificate is revoked.
> 
> If I try to validate the certificate with the "right" policy mappings, 
> onle the "right" chain will be valid. Then, I will check the chain for 
> the CRL, which will not match the DN matching rule, so I will not be 
> able to verify the validity of the CRL, and hence conclude that the 
> certificate is valid.
> 
> Sincerely,
> 
> --
> Julien
> 

From: "Santosh Chokhani" <[email-masked]>
To: "'Ed Gerck'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: clarification proposal -- Re: Current status of CRL validation?
Date: Wed, 7 Apr 2004 15:36:40 -0400
Importance: Normal
Sender: [email-masked]

Ed:

I see no benefit of having this dialog.  Our understanding of security, PKI,
X.509, 3280, and ASN.1 are so far apart, I better go and back to
kindergarten and learn some stuff.

Rest of the PKIXers:

My lack of response to Ed on this thread from now on should not be viewed as
concurrence.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ed Gerck
Sent: Wednesday, April 07, 2004 1:17 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation?

Santosh Chokhani wrote:
> Please read X.509 and 3280 carefully.  There is no mechanism to limit 
> the time of delegation.

I find this interpretation interesting. I wonder how many people would agree
with that. We now have eternal certs, that don't expire and cannot be
revoked. This would certainly solve the revocation problem ;-)

As an alternative reading to eternal delegation, X.509 should be 
interpreted in its entirety. Since there is nothing that mandates 
eternal delegation, the CA is  free to use its CPS to control delegation as
the CA so chooses --including expiration dates and 
revocation mechanisms-- both off-line and on-line.

>  See the syntax and semantics of CRL DP extension.

I see the semantics of the CPS. There is nothing stated there that would bar
a CA from limiting the time and scope of delegation.

> Also, there is no requirement for the certificate issuing CA to issue 
> a CRL

My point exactly -- the CA can control all aspects of its revocation 
management policy.

> and if the Indirect CRL is checked by the relying party, there is no 
> requirement to check any CRL issued by the issuing CA.

Yes, but that check was not done absolutely. It was done in reference to
what the issuer CA defines in its CPS, including its revocation 
management policy. For example, look for words such as "...MAKES NO 
REPRESENTATION ..." and "...MAKES NO ASSURANCES ...". The issuer CA 
can also change its CPS at any time, possibly excluding any delegation from
some time on.

> Actually, if the CRL DP extension is marked critical and it points to 
> an indirect CRL issuer, you MUST check that CRL.

My point exactly -- the issuer CA can control all aspects of its revocation 
management policy. Let's ask, who signed that critical CRL DP extension? 
Who controls whether the RP MUST check that CRL at that indirect CRL issuer
or not? Further, who can revoke such critical CRL DP extension?

Cheers,
Ed Gerck

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Wed, 7 Apr 2004 15:33:59 -0400
Importance: Normal
Sender: [email-masked]

Trevor:

>From technical philosophy viewpoint, I do not have a problem.

But, from my understanding of how IETF works, given that the benefit is
minimal, we need to define the standard that accommodates products with
varying degree of functionality.  I think SCVP requirement to sign DPD
responses may be too much.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Santosh,
My argument cannot be construed as an argument to sign everything. It is an
argument to sign all positive responses. I am equally not convinced that no
singing achieves anything other than weaker security. The act of signing is
not a major burden, especially if this is no longer on a per request basis
and allows the client to be assured of positive. Not signing positive
responses allows an attacker to manipulate the client beyond inserting
errors which is very, very bad.

How the server protects the cache is an implementation decision. Assuming
untrusted transport is reasonable for the RFC.

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 9:00 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor:

This argument can be the basis for signing everything all the time, which we
do not do.

The attacker can still manipulate and inject data.  I am not persuaded by
the argument that checking the signature first will save lot of client
processing time.

If the product developer and consumers want to have the option for not
signing this data, they should.

I see a bigger problem with the DPD server maintaining a cache and some one
attacking that cache (if unsigned) since a stationary server may be easier
to hack at then data in transit.  Now, if the DPD server signed cached paths
on request or if the DPD, you have the same problem.

Also, my suggestion would be for the client to have the option of requesting
signed responses and having the option of rejecting responses that are not
signed.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 11:46 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

I think there is significant value in signing the response from the SCVP
server. Given the main issue seems to be SCVP operating in an environment
where an attacker has the ability to inject packets going between client and
server into the data stream. Signing the response relegates the attacker to
injecting error packets - which is a low grade DoS. Sending unsigned
responses allows the attacker to inject a packed as the server whatever they
want as a genuine response, with certificates  and content of there
choosing. So we just turned every SCVP client into a potential web beacon.
Where the client has direct trust in the server signing key this is a very
secure process with DPD. Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 5:32 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Given the limited value of signature, DPD response signature by the server
should be optional and signature verification by the client should be
optional.

The question we should answer is that is there any benefit to adding an
option for the client to request a signature and then should the DPD server
be forced to sign the response

(shades of OCSP nonce)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of David Engberg
Sent: Tuesday, April 06, 2004 11:32 PM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

Stephen -

You have provided interesting techniques that an attacker could use to 
make a DPD client waste an extra 500ms verifying signatures before 
displaying a "bad path returned from server" dialog (or the equivalent).

That same attacker with the same advantages (DNS spoofing, etc.) could 
achieve the same effective denial of path discovery even if an extra 
signature is thrown on responses.  The attacker could obviously make 
clients waste time & bandwidth in lots of sneaky ways, although the 
relying application would ultimately report different error messages 
("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route 
to host", "response signature verify failed", etc.).

I am curious whether the type of attack that you describe has ever been 
performed against a non-SSL LDAP directory in a manner that would not 
have been equally effective if SSL was in use.

While there is definitely a difference here, I think (hope?) that we 
agree that it may be useful for a PKI administrator to have the choice 
to deploy a path discovery mechanism which does not require a fresh 
signature from a protected server key for every request.  This would 
allow an administrator to balance the DoS risks for clients against the 
DoS risks for servers.

My guess is that virtually all real world DoS attacks exploit the 
centralized nature of secured servers, and the best cure for this is the

sort of distributed redundancy that a keyless or two-tier-caching DPD 
responder architecture would permit.  For example, Akamai has 16,000+ 
servers around the world with no SSL private keys.  They are subjected 
to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail 
not due to the magic of PKI, but rather due to the redundancy you can 
build when you don't have to secure keys at every server.

Thanks

Stephen Kent wrote:
...
> if an attacker can spoof a DNS response, he can cause the client to 
> connect to him instead of the server, which would enable the bogus 
> server to receive the request as well as generate and send the 
> response, and in the absence of a signed response, the client cannot 
> know that he is not communicating with the intended server.
>
> a bogus server could then return bogus cert chains that fail to 
> validate, but which waste client resources. just how effective this 
> may be will be a function of client implementation details, which are 
> outside the scope of our standards.
...

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Re-certification
Date: Wed, 7 Apr 2004 15:29:54 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0167_01C41CB5.2CEC52C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

As my answer said, there would not be a problem with CRL since each serial
number will be unique and both keys will be used to sign the CRL.

Please go back and read my response.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Rodrigo Botafogo
Sent: Wednesday, April 07, 2004 11:48 AM
To: [email-masked]
Subject: RES: Re-certification

Thanks for the answers, but I haven't seen any comments about the CRL
issue that I've also asked about.  Anybody cares to comment.  I see that
there is a thread about CRL validation and it might somehow indicate how
the validation in this case should happen.

As I have stated previously, We've made some tests and when a new key is
generated for the same DN, some RP, Outlook for instance, sees the CRL
signed with the new key as another CA and not the same CA with a new key.
Certificates revoked before the new key generation are not seen as
revoked, the RP seems to tread the CRL as an "invalid" CRL for this
certificate.

I couldn't find anyway to configure Outlook so that it would recognize
that the cert was revoked.  Is there any application out there that does
the right thing?  Sorry if discussing real apps is not in the scope of the
group.  If so, let me know.

Thanks again,

Rodrigo

Jean-Marc Desperrier <[email-masked]> writes:

>AFAIK I have never seen Verisign *change* the key pair of an authority.
They
>always extend validity, while keeping the same key pair.

Ah, sorry, I was a bit too quick in my reply, what I meant was that they
kept the DN, key, and start date, and only changed the end date and serial
number. I was never quite sure why they kept the validFrom date, I can
understand wanting to leave a bit of overlap, but the new certs were
backdated many years through the direct copying of the validFrom.

Peter.

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

------=_NextPart_000_0167_01C41CB5.2CEC52C0--

Date: Wed, 07 Apr 2004 11:47:09 -0700
From: Ed Gerck <[email-masked]>
To: PKIX <[email-masked]>
Subject: Re: clarification proposal -- Re: Current status of CRL validation?
Sender: [email-masked]

Stefan Santesson wrote:
> 
> The basic assumption for the whole discussion seems to be very confused:
> 
> Snip:
> >
> >    "Since there may be more than one path used to validate the
> >    same certificate, it is possible that some paths to that
> >    certificate are valid while others are not."
> >
> 
> There is only 1 kind of path that can be used to validate a certificate,
> and that is a valid path. 

Valid to a RP may not be valid to another RP. To clarify this,
the text could say:

 Since there may be more than one path used to validate the same 
 certificate, it is possible that some paths to that certificate 
 are valid for some RPs while not valid to other RPs. 

> Valid being defined as a path that pass the
> RPs validation policy (defined at the discretion of the relying party).

Exactly. It depends on what each RP may choose to rely upon. Different
RPs may define "valid path" in a different way.

The RP may also receive different answers from valid paths.

> All other paths are invalid by definition. So among the valid paths
> there is no ambiguity, since they are all valid.
> 
> Why complicate things?

The RPs are complicated ;-)

Cheers,
Ed Gerck

Date: Wed, 07 Apr 2004 11:21:11 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: restated -- Re: clarification proposal -- Re: Current status of  CRLvalidation?
Sender: [email-masked]

Steve,

We agree. The purpose, after all is to clarify ;-) 

There are three meanings re that pesky phrase "...anything other than
their value as a representation of the issuer CA revocation management 
policy." The first two you list in your reply inlined below. The third
meaning has to do with limitations on the edge cases mentioned by 
Santoshi:
	- relying on revocation status mechanisms such as OCSP and 
indirect CRLs is subject to conditions defined the issuer CA.

Based on the input so far, I now restate the clarification NOTE.

NOTE:

 In X.509/PKIX only the issuer of a certificate is authoritative for 
 revocation and there is only one issuer for a given certificate. 
 Therefore, a certificate is either revoked or not from the issuer CA 
 point of view.

 From the RP point of view, the ability of a RP to establish the validity 
 of a certificate is a function of the certificate path that the RP uses 
 to validate the certificate, and of the access to revocation status 
 information available to the RP. Since there may be more than one path 
 used to validate the same certificate, it is possible that some paths to
 that certificate are valid while others are not. It is also possible to
 obtain different answers to the question whether a certificate is valid 
 or not. Also, two RPs may have access to different revocation status 
 data for the EE certificate or for a CA certificate along a path, so 
 that each RP may arrive at a different view of the validity of the EE 
 certificate at any given time.

 When a RP relies on revocation status mechanisms such as OCSP and 
 indirect CRLs, the data is subject to conditions defined by the issuer
 of the certificate. Such conditions may change from time to time. Also,
 the RP may not have direct evidence of the issuer CA's assertion of 
 a certificate's revocation status at that time.

 In terms of a RP software, resolution may be difficult in practical 
 terms. For example, it may need more time than what's available, 
 and/or need additional channels not included/reachable by that RP 
 software, and/or need human intervention.

 However, because a RP is always subject to conditions defined the 
 issuer CA, revocation status is ultimately definable by a RP.

Comments?

Cheers,
Ed Gerck

Stephen Kent wrote:
> 
> Ed,
> 
> We agree that there are some edge cases re revocation, as Santosh
> noted. My objection to your text is that it fails to clarify.
> 
> If you meant to say that
>         - only the issuer of a cert is authoritative for revocation, and
>         - relying on revocation status mechanisms such as OCSP and
> indirect CRLs  may not provide direct evidence of the issuer's
> assertion of a cert's revocation status
> 
> then say that. phrases like "...anything other than their value as a
> representation of the issuer CA revocation management policy" are
> just not helpful to most folks.
> 
> Steve

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Wed, 7 Apr 2004 11:06:54 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Santosh,
My argument cannot be construed as an argument to sign everything. It is
an argument to sign all positive responses. I am equally not convinced
that no singing achieves anything other than weaker security. The act of
signing is not a major burden, especially if this is no longer on a per
request basis and allows the client to be assured of positive. Not
signing positive responses allows an attacker to manipulate the client
beyond inserting errors which is very, very bad.

How the server protects the cache is an implementation decision.
Assuming untrusted transport is reasonable for the RFC.

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 9:00 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor:

This argument can be the basis for signing everything all the time,
which we
do not do.

The attacker can still manipulate and inject data.  I am not persuaded
by
the argument that checking the signature first will save lot of client
processing time.

If the product developer and consumers want to have the option for not
signing this data, they should.

I see a bigger problem with the DPD server maintaining a cache and some
one
attacking that cache (if unsigned) since a stationary server may be
easier
to hack at then data in transit.  Now, if the DPD server signed cached
paths
on request or if the DPD, you have the same problem.

Also, my suggestion would be for the client to have the option of
requesting
signed responses and having the option of rejecting responses that are
not
signed.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 11:46 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

I think there is significant value in signing the response from the SCVP
server. Given the main issue seems to be SCVP operating in an
environment
where an attacker has the ability to inject packets going between client
and
server into the data stream. Signing the response relegates the attacker
to
injecting error packets - which is a low grade DoS. Sending unsigned
responses allows the attacker to inject a packed as the server whatever
they
want as a genuine response, with certificates  and content of there
choosing. So we just turned every SCVP client into a potential web
beacon.
Where the client has direct trust in the server signing key this is a
very
secure process with DPD. Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 5:32 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Given the limited value of signature, DPD response signature by the
server
should be optional and signature verification by the client should be
optional.

The question we should answer is that is there any benefit to adding an
option for the client to request a signature and then should the DPD
server
be forced to sign the response

(shades of OCSP nonce)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of David Engberg
Sent: Tuesday, April 06, 2004 11:32 PM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

Stephen -

You have provided interesting techniques that an attacker could use to 
make a DPD client waste an extra 500ms verifying signatures before 
displaying a "bad path returned from server" dialog (or the equivalent).

That same attacker with the same advantages (DNS spoofing, etc.) could 
achieve the same effective denial of path discovery even if an extra 
signature is thrown on responses.  The attacker could obviously make 
clients waste time & bandwidth in lots of sneaky ways, although the 
relying application would ultimately report different error messages 
("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route 
to host", "response signature verify failed", etc.).

I am curious whether the type of attack that you describe has ever been 
performed against a non-SSL LDAP directory in a manner that would not 
have been equally effective if SSL was in use.

While there is definitely a difference here, I think (hope?) that we 
agree that it may be useful for a PKI administrator to have the choice 
to deploy a path discovery mechanism which does not require a fresh 
signature from a protected server key for every request.  This would 
allow an administrator to balance the DoS risks for clients against the 
DoS risks for servers.

My guess is that virtually all real world DoS attacks exploit the 
centralized nature of secured servers, and the best cure for this is the

sort of distributed redundancy that a keyless or two-tier-caching DPD 
responder architecture would permit.  For example, Akamai has 16,000+ 
servers around the world with no SSL private keys.  They are subjected 
to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail 
not due to the magic of PKI, but rather due to the redundancy you can 
build when you don't have to secure keys at every server.

Thanks

Stephen Kent wrote:
...
> if an attacker can spoof a DNS response, he can cause the client to
> connect to him instead of the server, which would enable the bogus 
> server to receive the request as well as generate and send the 
> response, and in the absence of a signed response, the client cannot 
> know that he is not communicating with the intended server.
>
> a bogus server could then return bogus cert chains that fail to
> validate, but which waste client resources. just how effective this 
> may be will be a function of client implementation details, which are 
> outside the scope of our standards.
...

Date: Wed, 07 Apr 2004 19:57:01 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: RES: Re-certification
Sender: [email-masked]

Rodrigo Botafogo wrote:

>[...] I haven't seen any comments about the CRL
>issue that I've also asked about. [...]
>
AFAIC what you did about the CRL seemed really special, and I wasn't 
sure I understood it fully.

>[...] We've made some tests and when a new key is
>generated for the same DN, some RP, Outlook for instance, sees the CRL
>signed with the new key as another CA and not the same CA with a new
>key.
>
Does it have both the old and the new CA certificate in it's store ?

You can't say "Outlook" and expect answers.
Depending on the exact version, the behavior (especially CRL) has major 
differences.

>[...]  Certificates revoked before the new key generation are not seen as
>revoked, the RP seems to tread the CRL as an "invalid" CRL for this
>certificate.
>  
>
Quite interesting. 
Whatever the RFC say about the subject, accepting as valid a CRL emitted 
by a CA that has the same DN as the CA that emitted the subject (but a 
different key) is very delicate thing to handle without dangerous 
security implications, and I think most implementors just safely refuse 
it all together, which is a better solution than to do it without being 
able to define adequate safegards.
 
But the thing you can rely on to get this working is AKI identifiers.
The Microsoft implementation places a lot of confidence in AKI, even 
accepting to follow a path based on the AKI when the DN don't match 
(which is invalid).

So you can hope to get some succesful results if you generate two CRL in 
parallel, one by the old CA one by the new CA, and use an AKI inside the 
CRL to link them strongly to the adequate CA. And always revoke certs in 
the CRL signed by the keypair that issued them.
If you're still concerned about being able to revoke certs emitted by 
the old CA, that mean that old CA is not yet expired and still can emit 
CRL, doesn't it ?

>I couldn't find anyway to configure Outlook so that it would recognize
>that the cert was revoked.  Is there any application out there that does
>the right thing? 
>
I'm surprised Outlook goes as far as you apparently describe.
Since years, people have reached the conclusion with the applications on 
the market, CA changeover with key renewal and the same DN doesn't work, 
and always either keeped the same key, or (even if only slightly) 
changed the DN.
AKI is theorically the key to getting it working correctly, but it's 
adventurous to really test it.

>Sorry if discussing real apps is not in the scope of
>the group.  If so, let me know.
>  
>
I too sometime wonder too why this lists spends astounding amount of 
time discussing very advanced points, and so little discussing the 
actual shortcomings of existing implementations on basic things.
But this said yes to some degree detailled discussion of how to get such 
specific implementation to do some thing might be out of the scope.

Date: Wed, 07 Apr 2004 10:17:11 -0700
From: Ed Gerck <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation?
Sender: [email-masked]

Santosh Chokhani wrote:
> Please read X.509 and 3280 carefully.  There is no mechanism to limit the
> time of delegation.

I find this interpretation interesting. I wonder how many people
would agree with that. We now have eternal certs, that don't
expire and cannot be revoked. This would certainly solve the
revocation problem ;-)

As an alternative reading to eternal delegation, X.509 should be 
interpreted in its entirety. Since there is nothing that mandates 
eternal delegation, the CA is  free to use its CPS to control
delegation as the CA so chooses --including expiration dates and 
revocation mechanisms-- both off-line and on-line.

>  See the syntax and semantics of CRL DP extension.

I see the semantics of the CPS. There is nothing stated there that
would bar a CA from limiting the time and scope of delegation.

> Also, there is no requirement for the certificate issuing CA to issue a CRL

My point exactly -- the CA can control all aspects of its revocation 
management policy.

> and if the Indirect CRL is checked by the relying party, there is no
> requirement to check any CRL issued by the issuing CA.

Yes, but that check was not done absolutely. It was done in reference
to what the issuer CA defines in its CPS, including its revocation 
management policy. For example, look for words such as "...MAKES NO 
REPRESENTATION ..." and "...MAKES NO ASSURANCES ...". The issuer CA 
can also change its CPS at any time, possibly excluding any delegation
from some time on.

> Actually, if the CRL DP extension is marked critical and it points to an
> indirect CRL issuer, you MUST check that CRL.

My point exactly -- the issuer CA can control all aspects of its revocation 
management policy. Let's ask, who signed that critical CRL DP extension? 
Who controls whether the RP MUST check that CRL at that indirect CRL issuer
or not? Further, who can revoke such critical CRL DP extension?

Cheers,
Ed Gerck

Date: Wed, 7 Apr 2004 11:47:28 -0400
To: "Julien Stern" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Current status of CRL validation ?
Cc: [email-masked]
Sender: [email-masked]

Julien,

I think you must be a bit behind on reading PKIX mail, since Santosh 
and I have been discussing the indirect CRL issue for two days now.

In your example, the first flaw I see is that the cert in question is 
supposedly signed by two CAs (CA4 and CA5), which have the same DN 
and public keys. if they have the same DN and the same public key, 
then they are the same CA, so the example is broken at that point, 
period.

Steve

From: "Julien Stern" <[email-masked]>
Date: Wed, 7 Apr 2004 18:35:12 +0200
To: [email-masked]
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

On Wed, Apr 07, 2004 at 12:07:34PM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> I am not sure that two distinct CAs with the same key (putting aside the
> same DN) should be the basis for analysis.  That situation will always lead
> to problems.  We are relying on randomness of large numbers to help us that
> this will not happen.
> 
> Consider providing an example where different CAs do not have the same key.

You should view my "two" CAs as the same CA with two different keys.
I might not have been totally clear about that, sorry.
This can be "either due to multiple concurrent key pairs or
due to changeover" (to quote RFC3280 :)).

--
Julien

> Behalf Of Julien Stern
> Sent: Wednesday, April 07, 2004 10:45 AM
> To: [email-masked]
> Subject: Re: Current status of CRL validation ?
> 
> 
> 
> On Tue, Mar 23, 2004 at 11:56:01AM -0500, Stephen Kent wrote:
> > 
> > Julien,
> > 
> > The confusion stems from somewhat sloppy use of terminology in these
> > discussions.
> > 
> > Only the issuer of a cert can revoke it and in X.509 (unlike PGP)
> > there is only one issuer for a given cert. So, the revocation 
> > question as you stated it was not well formed.
> 
> Stephen,
> 
> I do not believe that only the issuer of a cert can revoke it, notably when
> indirect CRL are used.
> 
> > A cert is either revoked or not.
> 
> Well, I'm sincerely starting to believe this is not true :)
> and not because of lack of available information.
> Please point me to the flaw in the following setting:
> 
>        +-----+        +-----+    I have a certificate (Cert). Two
>        | CA1 |        |     |    Different CAs (CA4 and CA5) have
>        | DN1 |        | DN1 |    matching issuer DN and keys for it.
>        | PK1 |        |     |
>        +-----+        +-----+    These two CAs have two super CAs
>         /   \            |       signed by the same root.
>   +-----+   +-----+   +-----+
>   | CA2 |   | CA3 |   |     |    I also have a CRL which refers to
>   | DN2 |   | DN3 |   | DN3 |    the certificate but whose only
>   | PK2 |   | PK3 |   |     |    chain up to DN1 is going through
>   +-----+   +-----+   +-----+    DN4 and DN3 (but NOT DN2).
>      |         |         |
>   +-----+   +-----+   +-----+    Now assume that the left path
>   | CA4 |   | CA5 |   |     |    (CA1 -> CA2 -> CA4 -> Cert)
>   | DN4 |   | DN4 |   | DN4 |    is valid for SOME policies, and
>   | PK4 |   | PK4 |   |     |    the right path is valid for some
>   +-----+   +-----+   +-----+    OTHER policies.
>        \     /           |
>        +-----+        +-----+
>        |Cert |        | CRL |
>        +-----+        +-----+
>  
> If I try to validate the certificate with the "left" policy mappings, only
> the "left" chain will be valid. Then, I will check the chain for the CRL,
> which will be valid and will match the DN matching rule, so I will conclude
> that the certificate is revoked.
> 
> If I try to validate the certificate with the "right" policy mappings, onle
> the "right" chain will be valid. Then, I will check the chain for the CRL,
> which will not match the DN matching rule, so I will not be able to verify
> the validity of the CRL, and hence conclude that the certificate is valid.
> 
> Sincerely,
> 
> --
> Julien
> 

Content-class: urn:content-classes:message
Subject: SCVP Change Proposal (was: Signing Untrusted SCVP?)
Date: Wed, 7 Apr 2004 12:11:15 -0400
From: "Dave Engberg" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Thanks, Santosh.  Here's a specific list of changes to SCVP Draft 13
that would allow the use of signatures to be optional on pure DPD
lookups, and permit server caching of signed responses when mutually
acceptable by server and client security policies.  Rather than defining
a new request extension to signal a desire for a fresh signature, this
proposal uses the request nonce.  I assume there would be agreement that
any client who sends a nonce would not want an unsigned or cached
response in return, but I wouldn't have any problem with defining a
separate new extension if that makes the intent more clear.

The section 3 changes are separate from section 4, and either could be
adopted independently.

In Section 3, replace:

  If a 
  server is responding to an unsigned request or a signed request, it 
  MUST use a signed response or an unsigned error response.

With:

  If a server is responding to an unsigned request or a signed request,
  it MUST use a signed response or an unsigned error response if either
  of the following is true:

    - The request wantBack includes one or more of the following:

        * id-swb-pkc-public-key-info
        * id-swb-pkc-cert-status
        * id-swb-ac-cert-status

    - The request includes a requestNonce
        
  If neither is true, a server responding to an unsigned request or
  signed request MAY use a signed response, an unsigned response, or
  an unsigned error response.

In Section 4, replace:

      requestRef            RequestReference, 

With:

      requestRef        [0] RequestReference OPTIONAL,

In Section 4.5, replace:

  The requestRef allows the SCVP server to identify the request that 

With:

  The OPTIONAL requestRef item allows the SCVP server to identify
  the request that ...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 8:32 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Given the limited value of signature, DPD response signature by the
server should be optional and signature verification by the client
should be optional.

The question we should answer is that is there any benefit to adding an
option for the client to request a signature and then should the DPD
server be forced to sign the response

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Current status of CRL validation ?
Date: Wed, 7 Apr 2004 12:07:34 -0400
Importance: Normal
Sender: [email-masked]

Julien:

I am not sure that two distinct CAs with the same key (putting aside the
same DN) should be the basis for analysis.  That situation will always lead
to problems.  We are relying on randomness of large numbers to help us that
this will not happen.

Consider providing an example where different CAs do not have the same key.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Wednesday, April 07, 2004 10:45 AM
To: [email-masked]
Subject: Re: Current status of CRL validation ?

On Tue, Mar 23, 2004 at 11:56:01AM -0500, Stephen Kent wrote:
> 
> Julien,
> 
> The confusion stems from somewhat sloppy use of terminology in these
> discussions.
> 
> Only the issuer of a cert can revoke it and in X.509 (unlike PGP)
> there is only one issuer for a given cert. So, the revocation 
> question as you stated it was not well formed.

Stephen,

I do not believe that only the issuer of a cert can revoke it, notably when
indirect CRL are used.

> A cert is either revoked or not.

Well, I'm sincerely starting to believe this is not true :)
and not because of lack of available information.
Please point me to the flaw in the following setting:

       +-----+        +-----+    I have a certificate (Cert). Two
       | CA1 |        |     |    Different CAs (CA4 and CA5) have
       | DN1 |        | DN1 |    matching issuer DN and keys for it.
       | PK1 |        |     |
       +-----+        +-----+    These two CAs have two super CAs
        /   \            |       signed by the same root.
  +-----+   +-----+   +-----+
  | CA2 |   | CA3 |   |     |    I also have a CRL which refers to
  | DN2 |   | DN3 |   | DN3 |    the certificate but whose only
  | PK2 |   | PK3 |   |     |    chain up to DN1 is going through
  +-----+   +-----+   +-----+    DN4 and DN3 (but NOT DN2).
     |         |         |
  +-----+   +-----+   +-----+    Now assume that the left path
  | CA4 |   | CA5 |   |     |    (CA1 -> CA2 -> CA4 -> Cert)
  | DN4 |   | DN4 |   | DN4 |    is valid for SOME policies, and
  | PK4 |   | PK4 |   |     |    the right path is valid for some
  +-----+   +-----+   +-----+    OTHER policies.
       \     /           |
       +-----+        +-----+
       |Cert |        | CRL |
       +-----+        +-----+
 
If I try to validate the certificate with the "left" policy mappings, only
the "left" chain will be valid. Then, I will check the chain for the CRL,
which will be valid and will match the DN matching rule, so I will conclude
that the certificate is revoked.

If I try to validate the certificate with the "right" policy mappings, onle
the "right" chain will be valid. Then, I will check the chain for the CRL,
which will not match the DN matching rule, so I will not be able to verify
the validity of the CRL, and hence conclude that the certificate is valid.

Sincerely,

--
Julien

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Wed, 7 Apr 2004 12:00:20 -0400
Importance: Normal
Sender: [email-masked]

Trevor:

This argument can be the basis for signing everything all the time, which we
do not do.

The attacker can still manipulate and inject data.  I am not persuaded by
the argument that checking the signature first will save lot of client
processing time.

If the product developer and consumers want to have the option for not
signing this data, they should.

I see a bigger problem with the DPD server maintaining a cache and some one
attacking that cache (if unsigned) since a stationary server may be easier
to hack at then data in transit.  Now, if the DPD server signed cached paths
on request or if the DPD, you have the same problem.

Also, my suggestion would be for the client to have the option of requesting
signed responses and having the option of rejecting responses that are not
signed.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 11:46 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

I think there is significant value in signing the response from the SCVP
server. Given the main issue seems to be SCVP operating in an environment
where an attacker has the ability to inject packets going between client and
server into the data stream. Signing the response relegates the attacker to
injecting error packets - which is a low grade DoS. Sending unsigned
responses allows the attacker to inject a packed as the server whatever they
want as a genuine response, with certificates  and content of there
choosing. So we just turned every SCVP client into a potential web beacon.
Where the client has direct trust in the server signing key this is a very
secure process with DPD. Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 5:32 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Given the limited value of signature, DPD response signature by the server
should be optional and signature verification by the client should be
optional.

The question we should answer is that is there any benefit to adding an
option for the client to request a signature and then should the DPD server
be forced to sign the response

(shades of OCSP nonce)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of David Engberg
Sent: Tuesday, April 06, 2004 11:32 PM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

Stephen -

You have provided interesting techniques that an attacker could use to 
make a DPD client waste an extra 500ms verifying signatures before 
displaying a "bad path returned from server" dialog (or the equivalent).

That same attacker with the same advantages (DNS spoofing, etc.) could 
achieve the same effective denial of path discovery even if an extra 
signature is thrown on responses.  The attacker could obviously make 
clients waste time & bandwidth in lots of sneaky ways, although the 
relying application would ultimately report different error messages 
("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route 
to host", "response signature verify failed", etc.).

I am curious whether the type of attack that you describe has ever been 
performed against a non-SSL LDAP directory in a manner that would not 
have been equally effective if SSL was in use.

While there is definitely a difference here, I think (hope?) that we 
agree that it may be useful for a PKI administrator to have the choice 
to deploy a path discovery mechanism which does not require a fresh 
signature from a protected server key for every request.  This would 
allow an administrator to balance the DoS risks for clients against the 
DoS risks for servers.

My guess is that virtually all real world DoS attacks exploit the 
centralized nature of secured servers, and the best cure for this is the

sort of distributed redundancy that a keyless or two-tier-caching DPD 
responder architecture would permit.  For example, Akamai has 16,000+ 
servers around the world with no SSL private keys.  They are subjected 
to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail 
not due to the magic of PKI, but rather due to the redundancy you can 
build when you don't have to secure keys at every server.

Thanks

Stephen Kent wrote:
...
> if an attacker can spoof a DNS response, he can cause the client to
> connect to him instead of the server, which would enable the bogus 
> server to receive the request as well as generate and send the 
> response, and in the absence of a signed response, the client cannot 
> know that he is not communicating with the intended server.
>
> a bogus server could then return bogus cert chains that fail to
> validate, but which waste client resources. just how effective this 
> may be will be a function of client implementation details, which are 
> outside the scope of our standards.
...

From: "Rodrigo Botafogo" <[email-masked]>
To: <[email-masked]>
Subject: RES: Re-certification
Date: Wed, 7 Apr 2004 12:47:57 -0300
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_01D2_01C41C9E.86C403E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks for the answers, but I haven't seen any comments about the CRL
issue that I've also asked about.  Anybody cares to comment.  I see that
there is a thread about CRL validation and it might somehow indicate how
the validation in this case should happen.  

As I have stated previously, We've made some tests and when a new key is
generated for the same DN, some RP, Outlook for instance, sees the CRL
signed with the new key as another CA and not the same CA with a new
key.  Certificates revoked before the new key generation are not seen as
revoked, the RP seems to tread the CRL as an "invalid" CRL for this
certificate.

I couldn't find anyway to configure Outlook so that it would recognize
that the cert was revoked.  Is there any application out there that does
the right thing?  Sorry if discussing real apps is not in the scope of
the group.  If so, let me know.

Thanks again,

Rodrigo

Jean-Marc Desperrier <[email-masked]> writes:

>AFAIK I have never seen Verisign *change* the key pair of an authority.
They
>always extend validity, while keeping the same key pair.

Ah, sorry, I was a bit too quick in my reply, what I meant was that they
kept
the DN, key, and start date, and only changed the end date and serial
number.
I was never quite sure why they kept the validFrom date, I can
understand
wanting to leave a bit of overlap, but the new certs were backdated many
years
through the direct copying of the validFrom.

Peter.

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

------=_NextPart_000_01D2_01C41C9E.86C403E0--

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Wed, 7 Apr 2004 08:46:13 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I think there is significant value in signing the response from the SCVP
server. Given the main issue seems to be SCVP operating in an
environment where an attacker has the ability to inject packets going
between client and server into the data stream. Signing the response
relegates the attacker to injecting error packets - which is a low grade
DoS. Sending unsigned responses allows the attacker to inject a packed
as the server whatever they want as a genuine response, with
certificates  and content of there choosing. So we just turned every
SCVP client into a potential web beacon. Where the client has direct
trust in the server signing key this is a very secure process with DPD.
Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 5:32 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Given the limited value of signature, DPD response signature by the
server
should be optional and signature verification by the client should be
optional.

The question we should answer is that is there any benefit to adding an
option for the client to request a signature and then should the DPD
server
be forced to sign the response

(shades of OCSP nonce)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of David Engberg
Sent: Tuesday, April 06, 2004 11:32 PM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

Stephen -

You have provided interesting techniques that an attacker could use to 
make a DPD client waste an extra 500ms verifying signatures before 
displaying a "bad path returned from server" dialog (or the equivalent).

That same attacker with the same advantages (DNS spoofing, etc.) could 
achieve the same effective denial of path discovery even if an extra 
signature is thrown on responses.  The attacker could obviously make 
clients waste time & bandwidth in lots of sneaky ways, although the 
relying application would ultimately report different error messages 
("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route 
to host", "response signature verify failed", etc.).

I am curious whether the type of attack that you describe has ever been 
performed against a non-SSL LDAP directory in a manner that would not 
have been equally effective if SSL was in use.

While there is definitely a difference here, I think (hope?) that we 
agree that it may be useful for a PKI administrator to have the choice 
to deploy a path discovery mechanism which does not require a fresh 
signature from a protected server key for every request.  This would 
allow an administrator to balance the DoS risks for clients against the 
DoS risks for servers.

My guess is that virtually all real world DoS attacks exploit the 
centralized nature of secured servers, and the best cure for this is the

sort of distributed redundancy that a keyless or two-tier-caching DPD 
responder architecture would permit.  For example, Akamai has 16,000+ 
servers around the world with no SSL private keys.  They are subjected 
to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail 
not due to the magic of PKI, but rather due to the redundancy you can 
build when you don't have to secure keys at every server.

Thanks

Stephen Kent wrote:
...
> if an attacker can spoof a DNS response, he can cause the client to 
> connect to him instead of the server, which would enable the bogus 
> server to receive the request as well as generate and send the 
> response, and in the absence of a signed response, the client cannot 
> know that he is not communicating with the intended server.
>
> a bogus server could then return bogus cert chains that fail to 
> validate, but which waste client resources. just how effective this 
> may be will be a function of client implementation details, which are 
> outside the scope of our standards.
...

Content-class: urn:content-classes:message
Subject: RE: clarification proposal -- Re: Current status of CRL validation?
Date: Wed, 7 Apr 2004 16:45:56 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

The basic assumption for the whole discussion seems to be very confused:

Snip:
> 
>    "Since there may be more than one path used to validate the
>    same certificate, it is possible that some paths to that
>    certificate are valid while others are not."
> 

There is only 1 kind of path that can be used to validate a certificate,
and that is a valid path. Valid being defined as a path that pass the
RPs validation policy (defined at the discretion of the relying party).

All other paths are invalid by definition. So among the valid paths
there is no ambiguity, since they are all valid.

Why complicate things?

/Stefan

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: key uniqueness in a PKI
Date: Wed, 7 Apr 2004 10:39:40 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Where can I find information on key pair uniqueness in a PKI? Is this
issue discussed in an RFC?
I will also appreciate comments on this issue, particularly when
considering a PKI with several CAs.
 
Thanks.
 
Miguel A Rodriguez
SeguriData
Mexico

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

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

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359323615-07042004>Where =
can I find=20
information on key pair uniqueness in a PKI? Is this issue discussed in =
an=20
RFC?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359323615-07042004>I will =
also=20
appreciate comments on this issue, particularly when considering a PKI =
with=20
several CAs.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D359323615-07042004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D359323615-07042004>Thanks.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D359323615-07042004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359323615-07042004>Miguel =
A=20
Rodriguez</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D359323615-07042004>SeguriData</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D359323615-07042004>Mexico</SPAN></FONT></DIV></BODY></HTML>

------=_NextPart_000_0017_01C41C8C.A19963C0--

Date: Wed, 7 Apr 2004 10:32:05 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Cc: <[email-masked]>
Sender: [email-masked]

At 8:32 AM -0400 4/7/04, Santosh Chokhani wrote:
>Given the limited value of signature, DPD response signature by the server
>should be optional and signature verification by the client should be
>optional.
>
>The question we should answer is that is there any benefit to adding an
>option for the client to request a signature and then should the DPD server
>be forced to sign the response
>
>(shades of OCSP nonce)
>

I disagree with your first assertion, and thus, not surprisingly, the 
conclusion. I think signature support for client and server should be 
mandated, but local amdins can choose to not invoke the feature.

Steve

Date: Wed, 7 Apr 2004 10:24:00 -0400
To: David Engberg <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Signing Untrusted SCVP?
Cc: [email-masked]
Sender: [email-masked]

At 11:31 PM -0400 4/6/04, David Engberg wrote:
>Stephen -
>
>You have provided interesting techniques that an attacker could use 
>to make a DPD client waste an extra 500ms verifying signatures 
>before displaying a "bad path returned from server" dialog (or the 
>equivalent).

Your next paragraph admits the problem is not the 500ms wasted in 
verifying signatures that lead to a dead end, but rather the errors 
that effectively kill the process and result in user error messages 
that deny service. So, I wonder why you chose to lead off with this 
red herring?

>That same attacker with the same advantages (DNS spoofing, etc.) 
>could achieve the same effective denial of path discovery even if an 
>extra signature is thrown on responses.  The attacker could 
>obviously make clients waste time & bandwidth in lots of sneaky 
>ways, although the relying application would ultimately report 
>different error messages ("unknown host: 'scvp.eubridge.org'", 
>"connection timed out", "no route to host", "response signature 
>verify failed", etc.).

If the attacker cannot forge signatures on DPD server responses, then 
the DPD software will not be so easily led into error states based on 
the assumption that it is talking with a valid server. Thus reduces 
the opportunities for attackers to steer the user into a state of 
confusion. If one believed the argument you cite above, then we ought 
to not bother with checksums on TCP packets (which is often the 
slowest part of TCP processing), because the users will eventually 
figure out if a transmission was corrupted, and there are so many 
other ways that an attacker could deny a user service.

>I am curious whether the type of attack that you describe has ever 
>been performed against a non-SSL LDAP directory in a manner that 
>would not have been equally effective if SSL was in use.

I don't know, and I don't care. It is a bad strategy to rely on past 
attack behavior as a primary predictor of future attacks.

>While there is definitely a difference here, I think (hope?) that we 
>agree that it may be useful for a PKI administrator to have the 
>choice to deploy a path discovery mechanism which does not require a 
>fresh signature from a protected server key for every request.  This 
>would allow an administrator to balance the DoS risks for clients 
>against the DoS risks for servers.

I think it could be reasonable to give local admins that option, 
which requires that products support signatures and allow local 
admins to decide whether to employ the signatures.

>My guess is that virtually all real world DoS attacks exploit the 
>centralized nature of secured servers, and the best cure for this is 
>the sort of distributed redundancy that a keyless or 
>two-tier-caching DPD responder architecture would permit.  For 
>example, Akamai has 16,000+ servers around the world with no SSL 
>private keys.  They are subjected to daily DoS attempts (e.g. they 
>host www.whitehouse.gov), which fail not due to the magic of PKI, 
>but rather due to the redundancy you can build when you don't have 
>to secure keys at every server.

Your Akamai example is a poor one; it says nothing about the need to 
secure keys at every server. And, by the way, every one of those 
severs does have a key in it, for use with Kerberos for managing the 
servers.

Steve

Date: Wed, 7 Apr 2004 09:54:12 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: clarification proposal -- Re: Current status of CRL validation ?
Cc: <[email-masked]>
Sender: [email-masked]

At 6:17 PM -0400 4/6/04, Santosh Chokhani wrote:
>Steve:
>
>Here is the quote from 3280, paragraph 3, Section 5.
>
>"CRL issuers issue CRLs.  In general, the CRL issuer is the CA.  CAs
>    publish CRLs to provide status information about the certificates
>    they issued.  However, a CA may delegate this responsibility to
>    another trusted authority.  Whenever the CRL issuer is not the CA
>    that issued the certificates, the CRL is referred to as an indirect
>    CRL."
>
>This may have been done to accommodate OCSP, but as the RFC is written, it
>should be interpreted to accommodate various situations, not just OCSP.
>

Agreed that the wording is not OVCS-specific. maybe we can add that 
to the list of fixes for 3280 as we go forward.

Steve

Date: Wed, 7 Apr 2004 10:02:09 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: clarification proposal -- Re: Current status of CRLvalidation?
Cc: [email-masked]
Sender: [email-masked]

Ed,

We agree that there are some edge cases re revocation, as Santosh 
noted. My objection to your text is that it fails to clarify.

If you meant to say that
	- only the issuer of a cert is authoritative for revocation, and
	- relying on revocation status mechanisms such as OCSP and 
indirect CRLs  may not provide direct evidence of the issuer's 
assertion of a cert's revocation status

then say that. phrases like "...anything other than their value as a 
representation of the issuer CA revocation management policy" are 
just not helpful to most folks.

Steve

Date: Wed, 7 Apr 2004 09:51:17 -0400
To: Arshad Noor <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PKI International Consortium
Cc: PKIX list <[email-masked]>
Sender: [email-masked]

At 9:41 PM -0700 4/6/04, Arshad Noor wrote:
>Stephen Kent wrote:
>
>>My suggestion is that the IMPACT of an identity theft incident 
>>would be worse if there are fewer credentials (e.g., certs) 
>>associated with an individual, rather than more. That notion is 
>>based on the assumption, stated elsewhere, that when we have more 
>>credentials, each has a narrower scope than if we have fewer, and 
>>thus the impact of a compromised credential is less severe.
>>
>	Taken to its logical conclusion, an infinite number of
>	credentials per entity must lead to minimal impact of an
>	identity theft incident.  However, humans cannot be expected to
>	deal with such mathematical elegance without becoming blithering
>	idiots.  (Some of us just need a few Internet accounts to reach
>	that state :-)).
>
>	Therefore, there must be some optimal number between 1 and
>	infinity that balances risk vs. the inconvenience of carrying
>	mulitple credentials.  Once again, for lack of empirical
>	evidence, the identity firewall concept advances seven as the
>	optimal number.

this is silly, almost to the point of being absurd. "Seven" as the 
optimal number sounds practically mystical.

>There is no reason to believe that there is an optimal number of 
>credentials for an individual, since other factors affecting the 
>ease of identity theft have to do with the procedures used to issue 
>the credentials, and the extent to which secondary [uses] for 
>selected credentials are condoned. In fact, secondary uses are a 
>major factor in identity theft, which is often more of a procedural 
>failure than a technical, credential failure.
>
>	My point exactly when I spoke of "inappropriate use of identity
>	data".  However, in order to correct procedural failures, one
>	must look at all elements of the process - including the
>	technology and the data itself - and determine if that needs to
>	be corrected with with the process.
>
>>That is also why one ought not assume that use of
>>certs, as a specific form of credential, will eradicate identity theft.
>>
>	To paraphrase you, Steve, "My comment said nothing about
>	eradicating identity theft."  (I do not believe it can ever be
>	eradicated - just made difficult enough to deter most people.)

This paragraph makes no sense. Your previous message explicitly 
talked about eradicating identity theft, yet you are backtracking 
here.

>	Given the range of options that are available to technologists
>	today, balancing usability, cost and security, digital
>	certificates coupled with external cryptographic tokens and a
>	high-assurance issuance process, are an optimal solution.  As
>	time goes by, it may very well not be so, but until I see
>	something better, that is the position I hold.

I too am in favor of the use of certs with private keys maintained in 
hardware tokens and a high assurance issuing process, when the 
resources being accessed warrant such measures. But, "optimal" is an 
inappropriate term when we have such a wide range of resources that 
people access.

Steve

From: "Julien Stern" <[email-masked]>
Date: Wed, 7 Apr 2004 16:44:50 +0200
To: [email-masked]
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

On Tue, Mar 23, 2004 at 11:56:01AM -0500, Stephen Kent wrote:
> 
> Julien,
> 
> The confusion stems from somewhat sloppy use of terminology in these 
> discussions.
> 
> Only the issuer of a cert can revoke it and in X.509 (unlike PGP) 
> there is only one issuer for a given cert. So, the revocation 
> question as you stated it was not well formed.

Stephen,

I do not believe that only the issuer of a cert can revoke it,
notably when indirect CRL are used.

> A cert is either revoked or not.

Well, I'm sincerely starting to believe this is not true :)
and not because of lack of available information.
Please point me to the flaw in the following setting:

       +-----+        +-----+    I have a certificate (Cert). Two
       | CA1 |        |     |    Different CAs (CA4 and CA5) have
       | DN1 |        | DN1 |    matching issuer DN and keys for it.
       | PK1 |        |     |
       +-----+        +-----+    These two CAs have two super CAs
        /   \            |       signed by the same root.
  +-----+   +-----+   +-----+
  | CA2 |   | CA3 |   |     |    I also have a CRL which refers to
  | DN2 |   | DN3 |   | DN3 |    the certificate but whose only
  | PK2 |   | PK3 |   |     |    chain up to DN1 is going through
  +-----+   +-----+   +-----+    DN4 and DN3 (but NOT DN2).
     |         |         |
  +-----+   +-----+   +-----+    Now assume that the left path
  | CA4 |   | CA5 |   |     |    (CA1 -> CA2 -> CA4 -> Cert)
  | DN4 |   | DN4 |   | DN4 |    is valid for SOME policies, and
  | PK4 |   | PK4 |   |     |    the right path is valid for some
  +-----+   +-----+   +-----+    OTHER policies.
       \     /           |
       +-----+        +-----+
       |Cert |        | CRL |
       +-----+        +-----+
 
If I try to validate the certificate with the "left" policy mappings,
only the "left" chain will be valid. Then, I will check the chain
for the CRL, which will be valid and will match the DN matching rule,
so I will conclude that the certificate is revoked.

If I try to validate the certificate with the "right" policy mappings,
onle the "right" chain will be valid. Then, I will check the chain
for the CRL, which will not match the DN matching rule, so I will not
be able to verify the validity of the CRL, and hence conclude that
the certificate is valid.

Sincerely,

--
Julien

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Thu, 08 Apr 2004 01:54:40 +1200
Sender: [email-masked]

Santoni Adriano <[email-masked]> writes:

>I am probably asking an old question, so ... please be patient.
>
>Rfc3280 states (<A7>4.1.2.4): "...all certificates issued after December 31,
>2003 MUST use the UTF8String encoding of DirectoryString...".
>
>Does that mean that it is mandatory to always encode all RDNs (having a type
>of DirectoryString) of the issuer and subject (and still other) certificate
>fields as UTF8Strings _even if they could be correctly encoded as a
>PrintableStrings_ ?

Hmm, see the previous thread on this a few months ago... in theory you're
supposed to do this, but that violates the primary rule of DN encoding, which
is "Never change the DN once it's been encoded by the originator".  If you
break that rule, you get to discover all the apps that reject re-encoded DNs.
If you're lucky, this will happen before your product ships and not after.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Re-certification
Date: Thu, 08 Apr 2004 01:50:43 +1200
Sender: [email-masked]

Jean-Marc Desperrier <[email-masked]> writes:

>AFAIK I have never seen Verisign *change* the key pair of an authority. They
>always extend validity, while keeping the same key pair.

Ah, sorry, I was a bit too quick in my reply, what I meant was that they kept
the DN, key, and start date, and only changed the end date and serial number.
I was never quite sure why they kept the validFrom date, I can understand
wanting to leave a bit of overlap, but the new certs were backdated many years
through the direct copying of the validFrom.

Peter.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: clarification proposal -- Re: Current status of CRL validation?
Date: Wed, 7 Apr 2004 08:49:46 -0400
Importance: Normal
Sender: [email-masked]

-----Original Message-----
From: Ed Gerck [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 4:30 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation?

Ed:

Please read X.509 and 3280 carefully.  There is no mechanism to limit the
time of delegation.  See the syntax and semantics of CRL DP extension.

Also, there is no requirement for the certificate issuing CA to issue a CRL
and if the Indirect CRL is checked by the relying party, there is no
requirement to check any CRL issued by the issuing CA.

Actually, if the CRL DP extension is marked critical and it points to an
indirect CRL issuer, you MUST check that CRL.

Santosh Chokhani wrote:
> 
> Any chnage of this nature is inconsistent with how X.509 and 3280 are.

Can you please point to the inconsistency in each case? I don't see it.

When X.509 says that a CA may delegate the responsibility of issuing CRLs 
to another trusted authority, X.509 does not bar the issuer CA from using 
its revocation management policy to govern all representations made to RPs,
whether they are delegated or not.  In fact, I understand that the issuer 
CA is authoritative to decide all aspects of such delegation.

What happens, for example, if the delegated CRL issuer oversteps the limits
of the issuer CA delegation when issuing a CRL (e.g., by issuing the CRL
after the delegation expires)?  As I understand it, X.509 says that the 
CRL is not valid in this case. The responsibility of issuing the CRL was 
not, in fact, delegated by the issuer CA when the CRL was issued.

Thus, with delegation or not, a RP cannot rely upon the confirmation 
procedures of any party that the RP chooses (e.g., a delegated CRL issuer,
or an indirect CRL issuer) for anything other than their value as a 
representation of the issuer CA revocation management policy. 

Comments?

Cheers,
Ed Gerck

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Wed, 7 Apr 2004 08:32:21 -0400
Importance: Normal
Sender: [email-masked]

Given the limited value of signature, DPD response signature by the server
should be optional and signature verification by the client should be
optional.

The question we should answer is that is there any benefit to adding an
option for the client to request a signature and then should the DPD server
be forced to sign the response

(shades of OCSP nonce)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Engberg
Sent: Tuesday, April 06, 2004 11:32 PM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

Stephen -

You have provided interesting techniques that an attacker could use to 
make a DPD client waste an extra 500ms verifying signatures before 
displaying a "bad path returned from server" dialog (or the equivalent).

That same attacker with the same advantages (DNS spoofing, etc.) could 
achieve the same effective denial of path discovery even if an extra 
signature is thrown on responses.  The attacker could obviously make 
clients waste time & bandwidth in lots of sneaky ways, although the 
relying application would ultimately report different error messages 
("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route 
to host", "response signature verify failed", etc.).

I am curious whether the type of attack that you describe has ever been 
performed against a non-SSL LDAP directory in a manner that would not 
have been equally effective if SSL was in use.

While there is definitely a difference here, I think (hope?) that we 
agree that it may be useful for a PKI administrator to have the choice 
to deploy a path discovery mechanism which does not require a fresh 
signature from a protected server key for every request.  This would 
allow an administrator to balance the DoS risks for clients against the 
DoS risks for servers.

My guess is that virtually all real world DoS attacks exploit the 
centralized nature of secured servers, and the best cure for this is the 
sort of distributed redundancy that a keyless or two-tier-caching DPD 
responder architecture would permit.  For example, Akamai has 16,000+ 
servers around the world with no SSL private keys.  They are subjected 
to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail 
not due to the magic of PKI, but rather due to the redundancy you can 
build when you don't have to secure keys at every server.

Thanks

Stephen Kent wrote:
...
> if an attacker can spoof a DNS response, he can cause the client to 
> connect to him instead of the server, which would enable the bogus 
> server to receive the request as well as generate and send the 
> response, and in the absence of a signed response, the client cannot 
> know that he is not communicating with the intended server.
>
> a bogus server could then return bogus cert chains that fail to 
> validate, but which waste client resources. just how effective this 
> may be will be a function of client implementation details, which are 
> outside the scope of our standards.
...

From: "Anders Rundgren" <[email-masked]>
To: "Arshad Noor" <[email-masked]>
Cc: "PKIX list" <[email-masked]>
Subject: IF-issued credentials.  Was: PKI International Consortium
Date: Wed, 7 Apr 2004 10:34:38 +0200
Sender: [email-masked]

Arshad,

>So, one could get oneself a Financial industry credential, for
>instance, by going through the industry's issuance process, and
>yet not have a single bank/brokerage account at all (not very
>useful, I realize - nonetheless that is the premise).

Absolutely, this is BTW already a reality in Scandinavia.

>This individual, armed with the Financial credential, can now
>approach any financial institution that honored the credential,
>and open an account.  However, depending on the context of the
>account & the transactions the individual may wish to carry out
>against that account, the financial institution may want to
>determine a number of attributes about that individual before
>granting him/her that privilege.

I would extend this to include *any* relying party that is prepared
to trust FI-issued credentials.  e-governments are the first to make
use of this.

Now, to the more general use of FI-issued identity credentials.
The need for certificates specifying employment or similar is
greatly exaggerated which is proven by the fact that the current
"authentication standard" (userid/password), does not force you
to specify "John Doe, Marketing, IBM, Armonk, US" but rather
"JohnDoe34" (and maybe a domain) as the various backend
systems already have all other information needed to authorize
access to the different internal systems.

The use of employment-style certificates outside of the company
border is never going to happen on a wider scale because that idea
is conceptually completely flawed.  Well, an IBM company badge
may indeed give you 10% discount at Tony's Pizza, but that's about it.

>I realize that there may be situations where AC's may be more
>effective, but I haven't seen a convincing business example that
>cannot be implemented more effectively - and just as securely -
>with LDAP-based Directories, at lower costs.

I agree 100%.

rgds
Anders R

Date: Wed, 07 Apr 2004 01:30:09 -0700
From: Ed Gerck <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation?
Sender: [email-masked]

Santosh Chokhani wrote:
> 
> Any chnage of this nature is inconsistent with how X.509 and 3280 are.

Can you please point to the inconsistency in each case? I don't see it.

When X.509 says that a CA may delegate the responsibility of issuing CRLs 
to another trusted authority, X.509 does not bar the issuer CA from using 
its revocation management policy to govern all representations made to RPs,
whether they are delegated or not.  In fact, I understand that the issuer 
CA is authoritative to decide all aspects of such delegation.

What happens, for example, if the delegated CRL issuer oversteps the limits
of the issuer CA delegation when issuing a CRL (e.g., by issuing the CRL
after the delegation expires)?  As I understand it, X.509 says that the 
CRL is not valid in this case. The responsibility of issuing the CRL was 
not, in fact, delegated by the issuer CA when the CRL was issued.

Thus, with delegation or not, a RP cannot rely upon the confirmation 
procedures of any party that the RP chooses (e.g., a delegated CRL issuer,
or an indirect CRL issuer) for anything other than their value as a 
representation of the issuer CA revocation management policy. 

Comments?

Cheers,
Ed Gerck

Date: Tue, 06 Apr 2004 23:59:45 -0700
From: Ed Gerck <[email-masked]>
To: PKIX list <[email-masked]>
Subject: Re: PKI International Consortium
Sender: [email-masked]

Arshad Noor wrote:
>         Therefore, there must be some optimal number between 1 and
>         infinity that balances risk vs. the inconvenience of carrying
>         mulitple credentials.  Once again, for lack of empirical
>         evidence, the identity firewall concept advances seven as the
>         optimal number.
 
There is no logic requiring a global optimum, or even the same
global optimum, for the number of credentials for all users and 
all uses at all times. Empirical evidence supports the assertion
that we all have a growing number of credentials with time,
including all the expired ones. Yes, expired credentials are 
useful. For example, as supporting evidence to issue a renewed 
credential and/or as a credential with less privileges.

In such context, the idea that "seven" might be a magical number
is already outdated ;-)

Cheers,
Ed Gerck

Date: Tue, 06 Apr 2004 23:43:53 -0700
From: Ed Gerck <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation?
Sender: [email-masked]

Dave,

I agree:

   "Since there may be more than one path used to validate the
   same certificate, it is possible that some paths to that
   certificate are valid while others are not." 

However:

(1) the valid paths may present the same answer but at least one
of the answers is stale and should have been different at that time
(e.g., due to delays before and after publication),

(2) the valid paths may present conflicting answers (e.g., due to 
race conditions), 

(3) even though in principle the answers are always resolvable to 
one conclusion (since an X.509/PKIX cert is either revoked or not), 
resolution may be impossible in practical terms by a RP software. 
For example, it may need more time than what's available, and/or 
need additional channels not included/reachable by that RP software, 
and/or need human intervention.

An ambiguous answer may exist by conditions (1), (2), (3) or their
combinations. In other words, it is possible for a RP to obtain 
two *conflicting* answers for the same cert. It is also possible for 
different RPs to obtain *conflicting* answers for the same cert. 
These possibilities, and you are correct, can be concluded from that 
first paragraph. Nonetheless, from the issuer CA viewpoint, the 
cert is either revoked or not. Unambiguously.

Is this a flaw? The rather surprising answer is that it isn't. An 
ambiguous answer is more informative than an unknown answer -- 
which is also possible. In other words, a RP would rather have an 
ambiguous answer than an unknown answer. For example, the issuer 
CA informs that the cert is not in the current CRL while an indirect 
CRL issuer informs that the cert is "revoked". This is informative 
and might be used by the RP software.

Moreover, even when a validation engine used by RP software does 
return answers that are all valid and look unambiguous there is always 
some degree of unreliability because the occurrence of (1), (2), (3) 
or their combinations cannot be ruled out.

When such things are considered, is revocation information useful? 
Surely, as it allows the RP software to have more information on the 
cert revocation status than without it. However, there are caveats and
even experts may disagree on their description. Presenting those caveats
in a clear and unified way, with some degree of consensus, was the 
purpose behind the proposed two paragraphs in the clarification Note 
(with their edits/improvements as further discussed in this thread).

Comments?

Cheers,
Ed Gerck

PS: In information theory terms, a RP software should need to use more
than one reporting channel in order to validate cert revocation status
with some degree of reliability. The improved results should compensate
the additional efforts. This may validate the use of indirect CRL issuers
and responders trusted by the RP, in addition to the issuer CA. As a 
counter example, if the RP has only one channel (e.g., the issuer CA CRL) 
presenting the information that the cert is not revoked, that information
is accurate (there is only one value) but is not reliable (the issuer 
CA CRL may be outdated). Conversely, if we have three or more channels (e.g.,
the issuer CA CRL, an indirect CRL issuer, a responder trusted by the RP) 
presenting the information that the cert is not revoked, that information
can be accurate (even if 2 out of 3 agree) and reliable. The use of two 
channels, even though it would lead to an ambiguity in case of a single 
failure, would still be an improvement over the single channel case
(that has a  single point of failure) of the issuer CA alone providing
the revocation information.

"David P. Kemp" wrote:
> 
> Ed,
> 
> While the first paragraph is factually correct, it nonetheless may
> lead the careless reader to an incorrect conclusion, namely that
> it is possible for an RP to obtain two *conflicting* answers, rather
> than merely two different answers.
> 
> If you ask whether an IP packet can reach its destination through
> a mesh of routers, the answer may well be that some paths are valid
> while others are not due to link failures.  But as long as at least
> one path is valid, the destination is reachable.  There is no
> conflict between paths that are up and those that are down.
> 
> There would be less chance of misinterpretation if your Note were
> to say:
>   "Since there may be more than one path used to validate the
>   same certificate, it is possible that some paths to that
>   certificate are valid while others are not."
> 
> As you say, there is an unambiguous validity status for each
> certificate in every potential path.  Validation engines used
> by RP software can always return an unambiguous answer:
>  * valid if at least one valid path exists,
>  * invalid if no path is valid and all CRLs are available, or
>  * unknown if no path is known valid and at least one CRL for
>     a potentially valid path is unavailable.
> 
> Dave
> 
> Ed Gerck wrote:
> 
> >
> >
> > Stephen Kent wrote:
> >
> >>Ed,
> >>
> >>PKIX is winding down now; we are not taking on any new work items. I
> >>suspect that anything as basic as what you allude to would be a
> >>significant departure from what we have done, and thus is not
> >>appropriate for PKIX to pursue.
> >
> >
> > Steve,
> >
> > How about a clarification to be added to the current PKIX documents
> > that deal with revocation and validation of certs? This would help
> > the weary reader, who must otherwise wade through this list's archives
> > in order to find the limitations we have been discussing. For example
> > (using some of your previous text):
> >
> > NOTE:
> >  In X.509/PKIX only the issuer of a certificate can revoke it and there
> >  is only one issuer for a given certificate. Therefore, a certificate
> >  is either revoked or not. However, the ability of a RP to establish
> >  the validity of a certificate is a function of the certificate path
> >  that the RP uses to validate the certificate, and of the access to
> >  revocation status information available to the RP. Since there may be
> >  more than one path used to validate the same certificate, it is possible
> >  to obtain different answers to the question whether a certificate is
> >  valid, depending on which path the RP uses. Also, two RPs may have
> >  access to different revocation status data for the EE certificate or for
> >  a CA certificate along a path, so that each RP may arrive at a different
> >  view of the validity of the EE certificate at any given time.
> >
> >  Moreover, in X.509/PKIX reliance terms, one may trust the confirmation
> >  procedures of the issuer CA, the issuer CA Designated Responder or any
> >  Trusted Responder during certificate reliance (i.e., whether the
> >  certificate has been revoked or not) under CRLs or OCSPs, but one cannot
> >  rely upon them for other than their value as a representation of the
> >  issuer CA revocation management as expressed in the issuer CA own terms
> >  and rules, usually contained in the CA CPS.
> >
> > Comments?
> >
> > Cheers,
> > Ed Gerck
> >

Date: Tue, 06 Apr 2004 22:33:08 -0700
From: Arshad Noor <[email-masked]>
Subject: Re: PKI International Consortium
To: [email-masked]
Cc: PKIX list <[email-masked]>
Organization: StrongAuth, Inc.
Sender: [email-masked]

Antonio, some comments inline.

[email-masked] wrote:

> Hi all,
> 
> In line with Arshad's comments, I think there's some kind of misunderstanding 
> in this discussion. It seems that we're confusing Identity and Attributes (or 
> privileges). It is reasonable to think that one entity (anything that can have 
> a certificate) should have only one Identity (and therefore, only one Identity 
> Certificate). There are reasons that may justify having more than one 
> Identity, and I will come to that later, but let's assume for now that only 
> one Identity is enough.
> 
> What has been mentioned in this thread is the need to have several (identity) 
> certificates for different purposes. Therefore, each of these "identity 
> certificates" will be "industry-specific" and will have different associated 
> semantics depending on the "industry" or purpose. In this way a "Financial 
> identity certificate" would mean "The cert holder has an associated account in 
> bank X and blah, blah". On the other hand my university certificate would 
> state that I am "professor of the Computer Science Department".  Well, in my 
> opinion these are not "identity certificates" but "attribute certificates". 
> 
	By proposing identity firewalls between industry-specific certs,
	I did not imply that any attributes would be associated with the
	identity (other than the basic DN, public key, key usages, etc).
	Although, each industry will almost certainly have some basic
	attributes implied, the advantage for the industry would come
	from having the minimum information in the identity cert to
	assure an RP of the identity, and leave the RP to address what
	information they needed to have to make authorization decisions.

	So, one could get oneself a Financial industry credential, for
	instance, by going through the industry's issuance process, and
	yet not have a single bank/brokerage account at all (not very
	useful, I realize - nonetheless that is the premise).

	This individual, armed with the Financial credential, can now
	approach any financial institution that honored the credential,
	and open an account.  However, depending on the context of the
	account & the transactions the individual may wish to carry out
	against that account, the financial institution may want to
	determine a number of attributes about that individual before
	granting him/her that privilege.

	But the authorization process - which, as you rightly point out,
	now depends on the attributes associated with that individual -
	should be completely distinct from the identification process,
	and must be in the control of the context owner.

> The newest version of X.509 provides a more suitable solution because it 
> clearly defines a framework where identity and attribute certificates, 
> although related, can be independently managed. That recommendation defines 
> new types of authorities, Attribute Authorities (AA), for the assignment of 
> privileges. It also defines the Source of Authority (SOA) as the ultimate 
> authority to assign a set of privileges. Additionally, it provides a 
> foundation to build a Privilege Management Infrastructure (PMI) that contain a 
> multiplicity of AAs, SOAs and final users.
> 
> So, summarizing, if the idea is to have "context-sensitive identities", 
> then "Attribute Certificates" linked to a single "Identity Certificate" are 
> the best solution.
> 
	While Attribute Certficates appear to have some appealing
	characteristics, there are a number of competing technologies
	that may appear less daunting to corporate developers currently.

	LDAP-based Directories, for instance, allow a rich set of ACI's
	that can be used to build authorization frameworks.  Since a
	vast majority of authorization decisions will occur within
	"closed" networks, it may turn out to be far more cost effective
	to build such frameworks out of LDAP-based Directories than AC
	based infrastructures.  It is difficult enough getting companies
	to deploy regular PKI's correctly - and use them appropriately -
	without adding the complexity of Attribute Cert infrastructures.

	I realize that there may be situations where AC's may be more
	effective, but I haven't seen a convincing business example that
	cannot be implemented more effectively - and just as securely -
	with LDAP-based Directories, at lower costs.

Arshad Noor
StrongAuth, Inc.

Date: Tue, 06 Apr 2004 21:41:17 -0700
From: Arshad Noor <[email-masked]>
Subject: Re: PKI International Consortium
To: Stephen Kent <[email-masked]>
Cc: PKIX list <[email-masked]>
Organization: StrongAuth, Inc.
Sender: [email-masked]

Stephen Kent wrote:

> My suggestion 
> is that the IMPACT of an identity theft incident would be worse if there 
> are fewer credentials (e.g., certs) associated with an individual, 
> rather than more. That notion is based on the assumption, stated 
> elsewhere, that when we have more credentials, each has a narrower scope 
> than if we have fewer, and thus the impact of a compromised credential 
> is less severe.
> 
	Taken to its logical conclusion, an infinite number of
	credentials per entity must lead to minimal impact of an
	identity theft incident.  However, humans cannot be expected to
	deal with such mathematical elegance without becoming blithering
	idiots.  (Some of us just need a few Internet accounts to reach
	that state :-)).

	Therefore, there must be some optimal number between 1 and
	infinity that balances risk vs. the inconvenience of carrying
	mulitple credentials.  Once again, for lack of empirical
	evidence, the identity firewall concept advances seven as the
	optimal number.
	
> There is no reason to believe that there is an optimal number of 
> credentials for an individual, since other factors affecting the ease of 
> identity theft have to do with the procedures used to issue the 
> credentials, and the extent to which secondary [uses] for selected credentials 
> are condoned. In fact, secondary uses are a major factor in identity 
> theft, which is often more of a procedural failure than a technical, 
> credential failure. 

	My point exactly when I spoke of "inappropriate use of identity
	data".  However, in order to correct procedural failures, one
	must look at all elements of the process - including the
	technology and the data itself - and determine if that needs to
	be corrected with with the process.

That is also why one ought not assume that use of
> certs, as a specific form of credential, will eradicate identity theft.
> 
	To paraphrase you, Steve, "My comment said nothing about
	eradicating identity theft."  (I do not believe it can ever be
	eradicated - just made difficult enough to deter most people.)

	Given the range of options that are available to technologists
	today, balancing usability, cost and security, digital
	certificates coupled with external cryptographic tokens and a
	high-assurance issuance process, are an optimal solution.  As
	time goes by, it may very well not be so, but until I see
	something better, that is the position I hold.

Arshad Noor
StrongAuth, Inc.

Date: Tue, 06 Apr 2004 23:31:31 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Signing Untrusted SCVP?
Sender: [email-masked]

Stephen -

You have provided interesting techniques that an attacker could use to 
make a DPD client waste an extra 500ms verifying signatures before 
displaying a "bad path returned from server" dialog (or the equivalent).

That same attacker with the same advantages (DNS spoofing, etc.) could 
achieve the same effective denial of path discovery even if an extra 
signature is thrown on responses.  The attacker could obviously make 
clients waste time & bandwidth in lots of sneaky ways, although the 
relying application would ultimately report different error messages 
("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route 
to host", "response signature verify failed", etc.).

I am curious whether the type of attack that you describe has ever been 
performed against a non-SSL LDAP directory in a manner that would not 
have been equally effective if SSL was in use.

While there is definitely a difference here, I think (hope?) that we 
agree that it may be useful for a PKI administrator to have the choice 
to deploy a path discovery mechanism which does not require a fresh 
signature from a protected server key for every request.  This would 
allow an administrator to balance the DoS risks for clients against the 
DoS risks for servers.

My guess is that virtually all real world DoS attacks exploit the 
centralized nature of secured servers, and the best cure for this is the 
sort of distributed redundancy that a keyless or two-tier-caching DPD 
responder architecture would permit.  For example, Akamai has 16,000+ 
servers around the world with no SSL private keys.  They are subjected 
to daily DoS attempts (e.g. they host www.whitehouse.gov), which fail 
not due to the magic of PKI, but rather due to the redundancy you can 
build when you don't have to secure keys at every server.

Thanks

Stephen Kent wrote:
...
> if an attacker can spoof a DNS response, he can cause the client to
> connect to him instead of the server, which would enable the bogus
> server to receive the request as well as generate and send the
> response, and in the absence of a signed response, the client cannot
> know that he is not communicating with the intended server.
>
> a bogus server could then return bogus cert chains that fail to
> validate, but which waste client resources. just how effective this
> may be will be a function of client implementation details, which are
> outside the scope of our standards.
...

From: "Admin" <[email-masked]>
To: [email-masked]
Subject: ADV:        Attention All  Nonprofit Orgs: (Members, Staff and  Associates):
Date: Wed, 07 Apr 04 03:02:19 GMT

This is a multi-part message in MIME format.

--A5.F.C.B__593.
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Nonprofit Organizations, Members, Staff and Associates:

You Must Respond By 5 P.M. Thursday, April 8, 2004.

Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Members, Staff and Associates
who respond to this message before 5 P.M., Thursday, April 8, 2004.

All desktop computers are brand-new packed in their original boxes,
and come with a full manufacturer's warranty plus
a 100% satisfaction guarantee.

These professional grade Desktops are fully equipped with 2004
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:

    1-800-884-9510 by 5 P.M. Thursday, April 8, 2004

The fast and powerful AT-2400 series Desktop features: 

      * Intel 2.0Ghz Processor for amazing speed and performance
      * 128MB DDR RAM,  --- Upgradeable to 1024
      * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB
      * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW 
      * 1.44 Floppy disk drive
      * Next Generation Technology
      * ATI Premium video and sound
      * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0
      * Soft Touch Keyboard and scroll mouse
      * Internet Ready
      * Network Ready
      * 1 Year parts and labor warranty
      * Priority customer service and tech support

MSRP $699 ........................................ Your Cost $297

How to qualify:

  1. You must be a Member, Staff or Associate of a Nonprofit:
  2. All desktop computers will be available on a
     first come first serve basis.
  3. You must call 1-800-884-9510 by 5 P.M. Thursday, April 8, 2004
     and we will hold the desktops you request on will call. 
  4. You are not obligated in any way.
  5. 100% Satisfaction Guaranteed.

Call Avtech Direct
1-800-884-9510 before 5 P.M. Thursday, April 8, 2004

If you wish to unsubscribe from this list, please go to:
http://www.computeradvice.org/unsubscribe.asp
--A5.F.C.B__593.--

From: "Santosh Chokhani" <[email-masked]>
To: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRLvalidation?
Date: Tue, 6 Apr 2004 21:10:16 -0400
Sender: [email-masked]

Any chnage of this nature is inconsistent with how X.509 and 3280 are.

On Tue, 06 Apr 2004 16:21:29 -0700, Ed Gerck wrote
> Stephen Kent wrote:
> > 
> > Ed Gerck wrote:
> > >
> > >  To decide whether a certificate has been revoked or not, a RP may
> > >  trust the confirmation procedures of the issuer CA, or a proxy
> > >  designated by the CA, or any third party that the RP so chooses.
> > >  However, the RP cannot rely upon them for other than their value
> > >  as a representation of the issuer CA revocation management policy.
> > 
> > Getting better. But the last sentence, as best I can make out, just
> > says that the CA or its designees can only tell an RP about the
> > revocation status of a cert as seen by the CA. This seems almost a
> > tautology, and does not shed light on whatever subtle issue is
> > lurking behind the words.
> 
> Steve,
> 
> I think your reply to Santoshi exemplifies why the second paragraph
> is needed in the proposed clarification. It is not about the 
> "revocation status of a cert as seen by the CA". It is about who has 
> authoritative management of that status in what context.
> 
> The second paragraph is needed to assert that the issuer CA is and 
> remains authoritative for the policy governing revocation management 
> of certs issued by that CA in *all* contexts. Even when such 
> revocation is delegated by the CA, or is designated to another 
> entity by the cert subscriber or by the RP. This goes beyond the 
> crypto math assurances underlying and linking the issuer CA 
> signature of the cert and its possible CRL.
> 
> BTW, as an alternative to that second paragraph, I suggest: 
> 
> When deciding whether a certificate has been revoked or not, a RP 
> cannot rely upon the confirmation procedures of any party that the 
> RP chooses (e.g., a delegated CRL issuer, or an indirect CRL issuer)
> for anything other than their value as a representation of the 
> issuer CA revocation management policy. The issuer CA is 
> authoritative for the revocation management of certificates issued 
> by that CA.
> 
> Cheers,
> Ed Gerck

Date: Tue, 06 Apr 2004 16:21:29 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRLvalidation?
Sender: [email-masked]

Stephen Kent wrote:
> 
> Ed Gerck wrote:
> >
> >  To decide whether a certificate has been revoked or not, a RP may
> >  trust the confirmation procedures of the issuer CA, or a proxy
> >  designated by the CA, or any third party that the RP so chooses.
> >  However, the RP cannot rely upon them for other than their value
> >  as a representation of the issuer CA revocation management policy.
> 
> Getting better. But the last sentence, as best I can make out, just
> says that the CA or its designees can only tell an RP about the
> revocation status of a cert as seen by the CA. This seems almost a
> tautology, and does not shed light on whatever subtle issue is
> lurking behind the words.

Steve,

I think your reply to Santoshi exemplifies why the second paragraph
is needed in the proposed clarification. It is not about the "revocation 
status of a cert as seen by the CA". It is about who has authoritative 
management of that status in what context.

The second paragraph is needed to assert that the issuer CA is and 
remains authoritative for the policy governing revocation management of 
certs issued by that CA in *all* contexts. Even when such revocation is 
delegated by the CA, or is designated to another entity by the cert 
subscriber or by the RP. This goes beyond the crypto math assurances 
underlying and linking the issuer CA signature of the cert and its 
possible CRL.

BTW, as an alternative to that second paragraph, I suggest: 

When deciding whether a certificate has been revoked or not, a RP 
cannot rely upon the confirmation procedures of any party that the 
RP chooses (e.g., a delegated CRL issuer, or an indirect CRL issuer)
for anything other than their value as a representation of the 
issuer CA revocation management policy. The issuer CA is authoritative 
for the revocation management of certificates issued by that CA.

Cheers,
Ed Gerck

Date: Tue, 06 Apr 2004 15:56:35 -0700
From: Ed Gerck <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation ?
Sender: [email-masked]

Santosh Chokhani wrote:
> 
> Steve:
> 
> I do not have objection to parts of the first paragraph.  But, the first two
> sentences of the paragraph are not accurate by most interpretations.  I
> quote:
> 
> "In X.509/PKIX only the issuer of a certificate can revoke it and there is
> only one issuer for a given certificate. Therefore, a certificate is either
> revoked or not."
> 
> Through indirect CRL issuer mechanism (as defined in X.509 and in 3280), an
> indirect CRL issuer can revoke a certificate with or without the knowledge
> of the certificate issuing CA.  Since neither standard provide operations
> related guidance (lack of this guidance is appropriate in the case of both
> the standards), a subscriber can directly contact indirect CRL issuer and
> have their certificate placed on the CRL.

Santosh,

Yes, semantically, an indirect CRL issuer can "revoke" a cert as
requested by the cert's subscriber. However, does this mean that 
the revocation signature is chained to the issuer CA of that cert? 
Not necessarily. Thus, a RP may have no way of knowing whether 
such "revocation" is bogus or not. The issuer CA is the only 
authoritative source, by virtue of crypto math, that can revoke 
a cert (or delegate such revocation by chaining). Anything else is 
not much more than hearsay.

That's exactly why I added the second paragraph to the proposed 
clarification note. It says that, when deciding whether a certificate 
has been revoked or not, a RP cannot rely upon the confirmation 
procedures of any party that the RP chooses (e.g., a delegated CRL
issuer, or an indirect CRL issuer) for anything other than their 
value as a representation of the issuer CA revocation management 
policy. 

Cheers,
Ed Gerck

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: clarification proposal -- Re: Current status of CRL validation ?
Date: Tue, 6 Apr 2004 18:17:06 -0400
Importance: Normal
Sender: [email-masked]

Steve:

Here is the quote from 3280, paragraph 3, Section 5.

"CRL issuers issue CRLs.  In general, the CRL issuer is the CA.  CAs
   publish CRLs to provide status information about the certificates
   they issued.  However, a CA may delegate this responsibility to
   another trusted authority.  Whenever the CRL issuer is not the CA
   that issued the certificates, the CRL is referred to as an indirect
   CRL."

This may have been done to accommodate OCSP, but as the RFC is written, it
should be interpreted to accommodate various situations, not just OCSP.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, April 06, 2004 6:08 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: clarification proposal -- Re: Current status of CRL validation
?

At 5:48 PM -0400 4/6/04, Santosh Chokhani wrote:
>Steve:
>
>Both X.509 and 3280 are very clear in this area.  The CA need not issue 
>CRL
>(ref: introduction in 3280 and paragraph 3 in introduction of Section 5 in
>3280 just as a start and there is more).

yes, but I thought that was an accommodation for OCSP, in the case of 3280.

>The relying party software can use the indirect CRL issuer information 
>and thus from software viewpoint, certificate issuer may not be 
>involved.

yes, but doing so is dangerous unless there are appropriate controls 
on the set of CAs for which the indicates CA can issue indirect CRLs. 
I bet such controls are rarely if ever available on clients.

>  >From operations, viewpoint, I gave a simple model where the 
>certificate issuer is not involved.
>
>Thus, adding those sentences creates conflict in the standard.
>
>Now, to the security issue, I agree that indirect CRL mechanism is not 
>a good idea.  It should be a matter of relying party policy.

well, at least we agree on that, which is the underlying issue here.

Steve

Date: Tue, 6 Apr 2004 18:08:10 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: clarification proposal -- Re: Current status of CRL validation ?
Cc: <[email-masked]>
Sender: [email-masked]

At 5:48 PM -0400 4/6/04, Santosh Chokhani wrote:
>Steve:
>
>Both X.509 and 3280 are very clear in this area.  The CA need not issue CRL
>(ref: introduction in 3280 and paragraph 3 in introduction of Section 5 in
>3280 just as a start and there is more).

yes, but I thought that was an accommodation for OCSP, in the case of 3280.

>The relying party software can use the indirect CRL issuer information and
>thus from software viewpoint, certificate issuer may not be involved.

yes, but doing so is dangerous unless there are appropriate controls 
on the set of CAs for which the indicates CA can issue indirect CRLs. 
I bet such controls are rarely if ever available on clients.

>  >From operations, viewpoint, I gave a simple model where the certificate
>issuer is not involved.
>
>Thus, adding those sentences creates conflict in the standard.
>
>Now, to the security issue, I agree that indirect CRL mechanism is not a
>good idea.  It should be a matter of relying party policy.

well, at least we agree on that, which is the underlying issue here.

Steve

Date: Tue, 06 Apr 2004 17:49:29 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation ?
Sender: [email-masked]

Ed,

While the first paragraph is factually correct, it nonetheless may
lead the careless reader to an incorrect conclusion, namely that
it is possible for an RP to obtain two *conflicting* answers, rather
than merely two different answers.

If you ask whether an IP packet can reach its destination through
a mesh of routers, the answer may well be that some paths are valid
while others are not due to link failures.  But as long as at least
one path is valid, the destination is reachable.  There is no
conflict between paths that are up and those that are down.

There would be less chance of misinterpretation if your Note were
to say:
  "Since there may be more than one path used to validate the
  same certificate, it is possible that some paths to that
  certificate are valid while others are not."

As you say, there is an unambiguous validity status for each
certificate in every potential path.  Validation engines used
by RP software can always return an unambiguous answer:
 * valid if at least one valid path exists,
 * invalid if no path is valid and all CRLs are available, or
 * unknown if no path is known valid and at least one CRL for
    a potentially valid path is unavailable.

Dave

Ed Gerck wrote:

> 
> 
> Stephen Kent wrote:
> 
>>Ed,
>>
>>PKIX is winding down now; we are not taking on any new work items. I
>>suspect that anything as basic as what you allude to would be a
>>significant departure from what we have done, and thus is not
>>appropriate for PKIX to pursue.
> 
> 
> Steve,
> 
> How about a clarification to be added to the current PKIX documents
> that deal with revocation and validation of certs? This would help 
> the weary reader, who must otherwise wade through this list's archives
> in order to find the limitations we have been discussing. For example 
> (using some of your previous text):
> 
> NOTE:
>  In X.509/PKIX only the issuer of a certificate can revoke it and there 
>  is only one issuer for a given certificate. Therefore, a certificate 
>  is either revoked or not. However, the ability of a RP to establish
>  the validity of a certificate is a function of the certificate path 
>  that the RP uses to validate the certificate, and of the access to 
>  revocation status information available to the RP. Since there may be 
>  more than one path used to validate the same certificate, it is possible 
>  to obtain different answers to the question whether a certificate is 
>  valid, depending on which path the RP uses. Also, two RPs may have 
>  access to different revocation status data for the EE certificate or for
>  a CA certificate along a path, so that each RP may arrive at a different
>  view of the validity of the EE certificate at any given time.
> 
>  Moreover, in X.509/PKIX reliance terms, one may trust the confirmation 
>  procedures of the issuer CA, the issuer CA Designated Responder or any 
>  Trusted Responder during certificate reliance (i.e., whether the 
>  certificate has been revoked or not) under CRLs or OCSPs, but one cannot
>  rely upon them for other than their value as a representation of the 
>  issuer CA revocation management as expressed in the issuer CA own terms 
>  and rules, usually contained in the CA CPS.
> 
> Comments?
> 
> Cheers,
> Ed Gerck
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: clarification proposal -- Re: Current status of CRL validation ?
Date: Tue, 6 Apr 2004 17:48:35 -0400
Importance: Normal
Sender: [email-masked]

Steve:

Both X.509 and 3280 are very clear in this area.  The CA need not issue CRL
(ref: introduction in 3280 and paragraph 3 in introduction of Section 5 in
3280 just as a start and there is more).

The relying party software can use the indirect CRL issuer information and
thus from software viewpoint, certificate issuer may not be involved.

>From operations, viewpoint, I gave a simple model where the certificate
issuer is not involved.

Thus, adding those sentences creates conflict in the standard.

Now, to the security issue, I agree that indirect CRL mechanism is not a
good idea.  It should be a matter of relying party policy.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, April 06, 2004 3:09 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: clarification proposal -- Re: Current status of CRL validation
?

At 1:56 PM -0400 4/6/04, Santosh Chokhani wrote:
>Steve:
>
>I do not have objection to parts of the first paragraph.  But, the 
>first two sentences of the paragraph are not accurate by most 
>interpretations.  I
>quote:
>
>"In X.509/PKIX only the issuer of a certificate can revoke it and there 
>is only one issuer for a given certificate. Therefore, a certificate is 
>either revoked or not."
>
>Through indirect CRL issuer mechanism (as defined in X.509 and in 
>3280), an indirect CRL issuer can revoke a certificate with or without 
>the knowledge of the certificate issuing CA.  Since neither standard 
>provide operations related guidance (lack of this guidance is 
>appropriate in the case of both the standards), a subscriber can 
>directly contact indirect CRL issuer and have their certificate placed 
>on the CRL.

Good point. I overlooked that "feature" of the newer CRLs. Of course, 
I always thought it was a very questionable feature, so maybe I was 
pre-disposed to overlook it ;-)

The problem is not so much that a subscriber could ask someone other 
than the issuer of his cert to list it on an indirect CRL, but rather 
that we have no way for an RP to know whether certs listed in this 
way are appropriately revoked, in the general case. An indirect CRL 
is not authoritative for the entries that refer to certs issued by 
other CAs. In that sense I would still argue that only the issuer can 
revoke the certs that it issues. The use of indirect CRLs is much 
like using OCSP, in that an RP that is configured to accept 
revocation status data from a CA issuing an indirect CRL implicitly 
assumes that the CA is authorized to revoke whatever certs it chooses 
to list in this fashion. i don't think we would say that any OCSP 
server can revoke any cert, even though any server can issue a 
respnse that asserts that any cert is revoked. It's an issue of 
whether a RP is configured to accept status info from an OCSP server, 
or in the case of an indirect CRL, to accept indirect 
(non-authoritative) CRL entries.

Steve

Date: Tue, 6 Apr 2004 17:11:09 -0400
To: David Engberg <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Signing Untrusted SCVP?
Cc: Ambarish Malpani <[email-masked]>, [email-masked]
Sender: [email-masked]

David,

	<SNIP>
>Am I correct that this is the only reason to require mandatory 
>signatures on DPD responses?

no, you are not.

You described a class of attacks, but not at all what I hand in mind.

an attacker can create a response without intercepting the query. the 
question is what the client with do with such a response, e.g., how 
much effort will the client expend before it determines that the 
response is not appropriate. there are options in SCVP that would 
make it harder for an attacker to do this, but since these are 
options, we can't be sure that they would be used. the difficulty in 
sending a bogus response is also dependent on the transport mechanism 
employed. HTTP is suggested as the like method, but e-mail is cited 
as well, and other transports might be used in the future.

if an attacker can spoof a DNS response, he can cause the client to 
connect to him instead of the server, which would enable the bogus 
server to receive the request as well as generate and send the 
response, and in the absence of a signed response, the client cannot 
know that he is not communicating with the intended server.

a bogus server could then return bogus cert chains that fail to 
validate, but which waste client resources. just how effective this 
may be will be a function of client implementation details, which are 
outside the scope of our standards.

when the client decides (via some unspecified means) that the server 
is "bad" the client is left not knowing whether the bad response was 
from the indicated server, or from some bogus server, if we have no 
signature. what is the client supposed to do? if he elects to locally 
"hot list" the server, then in a few attempts, the attacker may be 
able to cause the client to decide that there are no viable servers 
available to him, i.e., he may give up. he may back off for an 
unspecified period.  (remember the chaos that resulted when 
VeriSign's CRL services were overwhelmed not long ago? many clients 
hung for a while, I was told.)

The hallmark of a good DoS attack is one in which the attacker emits 
as few bad packets as possible, and inflicts the greatest denial or 
degradation of service. use of signatures in responses (and 
preferably on requests) minimizes opportunities for such attacks.

Steve

Date: Tue, 6 Apr 2004 15:08:32 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: clarification proposal -- Re: Current status of CRL validation ?
Cc: <[email-masked]>
Sender: [email-masked]

At 1:56 PM -0400 4/6/04, Santosh Chokhani wrote:
>Steve:
>
>I do not have objection to parts of the first paragraph.  But, the first two
>sentences of the paragraph are not accurate by most interpretations.  I
>quote:
>
>"In X.509/PKIX only the issuer of a certificate can revoke it and there is
>only one issuer for a given certificate. Therefore, a certificate is either
>revoked or not."
>
>Through indirect CRL issuer mechanism (as defined in X.509 and in 3280), an
>indirect CRL issuer can revoke a certificate with or without the knowledge
>of the certificate issuing CA.  Since neither standard provide operations
>related guidance (lack of this guidance is appropriate in the case of both
>the standards), a subscriber can directly contact indirect CRL issuer and
>have their certificate placed on the CRL.

Good point. I overlooked that "feature" of the newer CRLs. Of course, 
I always thought it was a very questionable feature, so maybe I was 
pre-disposed to overlook it ;-)

The problem is not so much that a subscriber could ask someone other 
than the issuer of his cert to list it on an indirect CRL, but rather 
that we have no way for an RP to know whether certs listed in this 
way are appropriately revoked, in the general case. An indirect CRL 
is not authoritative for the entries that refer to certs issued by 
other CAs. In that sense I would still argue that only the issuer can 
revoke the certs that it issues. The use of indirect CRLs is much 
like using OCSP, in that an RP that is configured to accept 
revocation status data from a CA issuing an indirect CRL implicitly 
assumes that the CA is authorized to revoke whatever certs it chooses 
to list in this fashion. i don't think we would say that any OCSP 
server can revoke any cert, even though any server can issue a 
respnse that asserts that any cert is revoked. It's an issue of 
whether a RP is configured to accept status info from an OCSP server, 
or in the case of an indirect CRL, to accept indirect 
(non-authoritative) CRL entries.

Steve

Date: Tue, 6 Apr 2004 14:24:30 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: clarification proposal -- Re: Current status of CRLvalidation ?
Cc: [email-masked]
Sender: [email-masked]

Ed,

>
>
>Agree. I reworded it as:
>
>  To decide whether a certificate has been revoked or not, a RP may
>  trust the confirmation procedures of the issuer CA, or a proxy
>  designated by the CA, or any third party that the RP so chooses.
>  However, the RP cannot rely upon them for other than their value
>  as a representation of the issuer CA revocation management policy.

Getting better. But the last sentence, as best I can make out, just 
says that the CA or its designees can only tell an RP about the 
revocation status of a cert as seen by the CA. This seems almost a 
tautology, and does not shed light on whatever subtle issue is 
lurking behind the words.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: clarification proposal -- Re: Current status of CRL validation ?
Date: Tue, 6 Apr 2004 13:56:34 -0400
Importance: Normal
Sender: [email-masked]

Steve:

I do not have objection to parts of the first paragraph.  But, the first two
sentences of the paragraph are not accurate by most interpretations.  I
quote:

"In X.509/PKIX only the issuer of a certificate can revoke it and there is
only one issuer for a given certificate. Therefore, a certificate is either
revoked or not."

Through indirect CRL issuer mechanism (as defined in X.509 and in 3280), an
indirect CRL issuer can revoke a certificate with or without the knowledge
of the certificate issuing CA.  Since neither standard provide operations
related guidance (lack of this guidance is appropriate in the case of both
the standards), a subscriber can directly contact indirect CRL issuer and
have their certificate placed on the CRL.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, April 06, 2004 9:31 AM
To: Ed Gerck
Cc: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation
?

At 3:31 PM -0700 4/5/04, Ed Gerck wrote:
>Stephen Kent wrote:
>>  Ed,
>>
>>  PKIX is winding down now; we are not taking on any new work items. I  
>> suspect that anything as basic as what you allude to would be a  
>> significant departure from what we have done, and thus is not  
>> appropriate for PKIX to pursue.
>
>Steve,
>
>How about a clarification to be added to the current PKIX documents 
>that deal with revocation and validation of certs? This would help the 
>weary reader, who must otherwise wade through this list's archives in 
>order to find the limitations we have been discussing. For example 
>(using some of your previous text):
>
>NOTE:
>  In X.509/PKIX only the issuer of a certificate can revoke it and 
>there
>  is only one issuer for a given certificate. Therefore, a certificate
>  is either revoked or not. However, the ability of a RP to establish
>  the validity of a certificate is a function of the certificate path
>  that the RP uses to validate the certificate, and of the access to
>  revocation status information available to the RP. Since there may be
>  more than one path used to validate the same certificate, it is possible
>  to obtain different answers to the question whether a certificate is
>  valid, depending on which path the RP uses. Also, two RPs may have
>  access to different revocation status data for the EE certificate or for
>  a CA certificate along a path, so that each RP may arrive at a different
>  view of the validity of the EE certificate at any given time.
>
>  Moreover, in X.509/PKIX reliance terms, one may trust the 
> confirmation  procedures of the issuer CA, the issuer CA Designated 
> Responder or any  Trusted Responder during certificate reliance (i.e., 
> whether the  certificate has been revoked or not) under CRLs or OCSPs, 
> but one cannot  rely upon them for other than their value as a 
> representation of the  issuer CA revocation management as expressed in 
> the issuer CA own terms  and rules, usually contained in the CA CPS.
>
>Comments?
>
>Cheers,
>Ed Gerck

We have a suggestion before the WG to issue an update to 3280, so the 
WG can decide if text of the sort noted above should be part of the 
update, if we proceed on that work item.

With regard to the text above, I like the first paragraph :-), but 
the second one becomes murky very quickly. The paragraph doesn't 
convey any meaning to me.
It probably doesn't help that the paragraph is one, 6 line sentence, 
or that it introduces terms such as "CA Designated Responder," 
"Trusted Responder," ...

Steve

Date: Tue, 06 Apr 2004 10:36:59 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRLvalidation ?
Sender: [email-masked]

Stephen Kent wrote:
> 
> At 3:31 PM -0700 4/5/04, Ed Gerck wrote:
> >NOTE:
> >  In X.509/PKIX only the issuer of a certificate can revoke it and there
> >  is only one issuer for a given certificate. Therefore, a certificate
> >  is either revoked or not. However, the ability of a RP to establish
> >  the validity of a certificate is a function of the certificate path
> >  that the RP uses to validate the certificate, and of the access to
> >  revocation status information available to the RP. Since there may be
> >  more than one path used to validate the same certificate, it is possible
> >  to obtain different answers to the question whether a certificate is
> >  valid, depending on which path the RP uses. Also, two RPs may have
> >  access to different revocation status data for the EE certificate or for
> >  a CA certificate along a path, so that each RP may arrive at a different
> >  view of the validity of the EE certificate at any given time.
> >
> >  Moreover, in X.509/PKIX reliance terms, one may trust the confirmation
> >  procedures of the issuer CA, the issuer CA Designated Responder or any
> >  Trusted Responder during certificate reliance (i.e., whether the
> >  certificate has been revoked or not) under CRLs or OCSPs, but one cannot
> >  rely upon them for other than their value as a representation of the
> >  issuer CA revocation management as expressed in the issuer CA own terms
> >  and rules, usually contained in the CA CPS.
> >
> >Comments?
> >
> >Cheers,
> >Ed Gerck
> 
> We have a suggestion before the WG to issue an update to 3280, so the
> WG can decide if text of the sort noted above should be part of the
> update, if we proceed on that work item.

Sounds like good timing. 

> With regard to the text above, I like the first paragraph :-), 

;-) I improved it a bit.

> but
> the second one becomes murky very quickly. The paragraph doesn't
> convey any meaning to me.
> It probably doesn't help that the paragraph is one, 6 line sentence,
> or that it introduces terms such as "CA Designated Responder,"
> "Trusted Responder," ...

Agree. I reworded it as:

 To decide whether a certificate has been revoked or not, a RP may 
 trust the confirmation procedures of the issuer CA, or a proxy 
 designated by the CA, or any third party that the RP so chooses. 
 However, the RP cannot rely upon them for other than their value 
 as a representation of the issuer CA revocation management policy.

Cheers,
Ed Gerck

From: "Julien Stern" <[email-masked]>
Date: Tue, 6 Apr 2004 17:15:30 +0200
To: [email-masked]
Subject: Problem with Indirect CRL with DPV/DPD
Sender: [email-masked]

Greetings,

I keep on having a major problem with indirect CRLs, and I do not see
how they can be used with DPV/DPD (or RFC3126 actually, but this might
be out of scope).

As a matter of fact, my understanding of RFC3379 (requirements for DPV/DPD)
and the draft DPV and DPD over OCSP is that in DPD the client should
receive enough information to perform all the validity checks by
himself.

I can see that this works very well when no indirect CRL is used.
However, when an indirect CRL is used, an EXTRA certificate path
that should be used to validate the CRL issuer certificate should be
provided to the client. And if there is any other indirect CRL in
this new path, yet another extra CRL and another extra certificate path
should be sent, and so on (recursively).

I do not see how this information can be provided through DPD.

As a side note, the same problem occurs in RFC3126 where it seems the
validation information provided is not enough when indirect CRL are
used.

All these protocols seem to imply that the same path can be used to
validate a certificate and the corresponding CRL, which is not the case.
How am I supposed to verify an (indirect) CRL when the only information
provided to me is the X500Name of the CRL issuer ?

Any clarification would be appreciated.

--
Julien

Date: Tue, 6 Apr 2004 09:21:28 -0400
To: Arshad Noor <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PKI International Consortium
Cc: PKIX list <[email-masked]>
Sender: [email-masked]

At 11:27 PM -0700 4/5/04, Arshad Noor wrote:

	<SNIP>
>>identity theft would likely be a bigger concern if we have fewer certs.
>>
>	I do not believe identity theft will ever be eradicated
>	regardless of the number of certs.  However, if we assume
>	that identity certs are useful, then there is some optimal
>	number that balances the risk against the inconvenience of
>	carrying too many credentials.  In the absence of objective
>	research recommending the precise number, or range, the
>	identity firewalls concept advances one figure.

My comment said nothing about eradicating identity theft. My 
suggestion is that the IMPACT of an identity theft incident would be 
worse if there are fewer credentials (e.g., certs) associated with an 
individual, rather than more. That notion is based on the assumption, 
stated elsewhere, that when we have more credentials, each has a 
narrower scope than if we have fewer, and thus the impact of a 
compromised credential is less severe.

There is no reason to believe that there is an optimal number of 
credentials for an individual, since other factors affecting the ease 
of identity theft have to do with the procedures used to issue the 
credentials, and the extent to which secondary for selected 
credentials are condoned. In fact, secondary uses are a major factor 
in identity theft, which is often more of a procedural failure than a 
technical, credential failure. That is also why one ought not assume 
that use of certs, as a specific form of credential, will eradicate 
identity theft.

Steve

Date: Tue, 6 Apr 2004 09:31:12 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: clarification proposal -- Re: Current status of CRL validation ?
Cc: [email-masked]
Sender: [email-masked]

At 3:31 PM -0700 4/5/04, Ed Gerck wrote:
>Stephen Kent wrote:
>>  Ed,
>>
>>  PKIX is winding down now; we are not taking on any new work items. I
>>  suspect that anything as basic as what you allude to would be a
>>  significant departure from what we have done, and thus is not
>>  appropriate for PKIX to pursue.
>
>Steve,
>
>How about a clarification to be added to the current PKIX documents
>that deal with revocation and validation of certs? This would help
>the weary reader, who must otherwise wade through this list's archives
>in order to find the limitations we have been discussing. For example
>(using some of your previous text):
>
>NOTE:
>  In X.509/PKIX only the issuer of a certificate can revoke it and there
>  is only one issuer for a given certificate. Therefore, a certificate
>  is either revoked or not. However, the ability of a RP to establish
>  the validity of a certificate is a function of the certificate path
>  that the RP uses to validate the certificate, and of the access to
>  revocation status information available to the RP. Since there may be
>  more than one path used to validate the same certificate, it is possible
>  to obtain different answers to the question whether a certificate is
>  valid, depending on which path the RP uses. Also, two RPs may have
>  access to different revocation status data for the EE certificate or for
>  a CA certificate along a path, so that each RP may arrive at a different
>  view of the validity of the EE certificate at any given time.
>
>  Moreover, in X.509/PKIX reliance terms, one may trust the confirmation
>  procedures of the issuer CA, the issuer CA Designated Responder or any
>  Trusted Responder during certificate reliance (i.e., whether the
>  certificate has been revoked or not) under CRLs or OCSPs, but one cannot
>  rely upon them for other than their value as a representation of the
>  issuer CA revocation management as expressed in the issuer CA own terms
>  and rules, usually contained in the CA CPS.
>
>Comments?
>
>Cheers,
>Ed Gerck

We have a suggestion before the WG to issue an update to 3280, so the 
WG can decide if text of the sort noted above should be part of the 
update, if we proceed on that work item.

With regard to the text above, I like the first paragraph :-), but 
the second one becomes murky very quickly. The paragraph doesn't 
convey any meaning to me.
It probably doesn't help that the paragraph is one, 6 line sentence, 
or that it introduces terms such as "CA Designated Responder," 
"Trusted Responder," ...

Steve

Date: Mon, 05 Apr 2004 23:27:56 -0700
From: Arshad Noor <[email-masked]>
Subject: Re: PKI International Consortium
To: Stephen Kent <[email-masked]>
Cc: PKIX list <[email-masked]>
Organization: StrongAuth, Inc.
Sender: [email-masked]

Stephen Kent wrote:

  > two observations:
>     - the implicit ad for your company in the URL above is inappropriate 
> for the PKIX list

	If so, I apologize.  This is the only archived copy of the
	newsletter, and it seemed appropriate to provide the URL to the
	article rather than repeat the concept. However, I will be more
	cognizant of that in the future.

>     - although one might imagine such certs, there are significant 
> adverse privacy implications (see 
> http://www.nap.edu/books/0309088968/html/)

	I will address this after I have had an opportunity to read
	the book.
> 
> identity theft would likely be a bigger concern if we have fewer certs.
> 
	I do not believe identity theft will ever be eradicated
	regardless of the number of certs.  However, if we assume
	that identity certs are useful, then there is some optimal
	number that balances the risk against the inconvenience of
	carrying too many credentials.  In the absence of objective
	research recommending the precise number, or range, the
	identity firewalls concept advances one figure.

> finally, I am concerned that your message seems to be so closely aligned 
> with you company's products. if you want to continue this discussion, 
> please do so without making it seem like an ad for your company's 
> products and services.
> 
	The message expressed a concept for how digital certificates
	can be used to solve some problems in a different way, Steve.  	
	No more, no less.

Arshad Noor
StrongAuth, Inc.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 5 Apr 2004 21:26:31 -0700
Importance: Normal
Sender: [email-masked]

Trevor,

That's not how I read the genesis of this thread.  As excerpted
below, I read Dave asking why in an SCVP context DPD responses
MUST be signed.

Mike

-----Original Message-----
From: Trevor Freeman
Sent: Monday, April 05, 2004 5:43 PM

Hi Michael,

I thought the question was scaling given Dave's comments on
pre-generation of responses. I seem to remember somewhere else a
discussion on pre-canned vs. non-pre-canned responses.

Trevor

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Monday, April 05, 2004 3:34 PM

Trevor,

Is not the issue at hand whether or not DPD responses
MUST be signed?

Mike

-----Original Message-----
From: Dave Engberg
Sent: Thursday, April 01, 2004 3:43 PM

. . . Given that the spec goes to some lengths to
support pure DPD by clients, why is there a requirement
(section 3) that every SCVP response be digitally signed?

. . . The extra dynamic signature around the entire package
is gratuitously expensive overhead . . . .

Date: Mon, 05 Apr 2004 20:34:28 -0700
From: Ed Gerck <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: clarification proposal -- Re: Current status of CRL validation ?
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 3:31 PM -0700 4/5/04, Ed Gerck wrote:
> >
> >How about a clarification to be added to the current PKIX documents
> >that deal with revocation and validation of certs? This would help
> >the weary reader, who must otherwise wade through this list's archives
> >in order to find the limitations we have been discussing. For example
> >(using some of your previous text):
> 
> New work items are decided by the WG, not just one co-chair. You are
> asking the WG whether or not we should take up a clarification
> document based on just two paragraphs of text. 

No, I'm based on the recent list traffic Re this subject line.

> As Steve said, we're
> trying to wind down, so such a generic request is really hard to
> support.

What is generic about it? It's two paragraphs of text that address
head on the question whether a cert is revoked or not, both from the
issuer CA point of view as well as from the RP's.

> If you are serious about this work item (and I'm not suggesting that
> you are), please put together an abstract and a reasonably complete
> outline so the WG can see if we want to do it. Thanks!

My abstract is my previous posting; the reasonably complete outline
is this list's archive with all ~20 messages re "Current status of CRL
validation ?" 

If you are serious about your comment (and I see no reason to suggest
you are not), please note that the WG already has in the recent list
archive all ~20 messages it needs in order to consider my proposal, 
including my very succinct suggestion for the clarification.

I think that the WG can reasonably expand or rework what I have
already presented as my input. I am of course available for a 
second, third or n-pass.

Cheers,
Ed Gerck

Date: Mon, 05 Apr 2004 22:07:17 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Ambarish Malpani <[email-masked]>
CC: [email-masked]
Subject: Re: Signing Untrusted SCVP?
Sender: [email-masked]

Rather than assuming that SCVP DPD signatures must be mandatory and 
discussing low security ways of implementing them (no HSM, etc.), 
perhaps it would be useful to discuss what those signatures give you in 
a pure DPD response.

Unless I'm missing something, here's a full description of the only 
attack that is possible with unsigned pure DPD that is not possible with 
signed pure DPD:

In an environment with multiple SCVP servers in separate network 
locations, an attacker who can take complete control of the network link 
close to one of the servers could intercept SCVP requests and then 
provide syntactically correct (but unsigned) SCVP responses to clients 
to indicate that the server is unable to find a usable path that meets 
the client requirements.  A client with alternate SCVP server URLs 
explicitly configured would have to try the other URLs in an unsigned 
environment to be sure that none of them have a path, whereas in a 
signed environment, the client could assume from the signature that no 
path is available without trying the alternate URLs.  This would 
potentially save a few extra HTTP requests for every "no path" response 
for this hypothetical multi-URL client.

Any variation on this scenario renders the signed vs. unsigned 
equivalent.  E.g.:

* If the attacker has control of the network closer to the client, or 
control in front of multiple servers, s/he could DoS all requests to any 
of the SCVP servers (HTTP 404 errors, etc.).

* If the attacker has control of the SCVP server, s/he could issue a 
signed response with the same "no path" content.

* If clients only have one server URL (i.e. only one local server, or 
all servers are balanced from one host name), then the result is 
equivalent (unsigned error from attacker, client is stuck).

This attack sounds so awkward, and the payoff is so minor, that I really 
don't see the point of managing and protecting keys at every DPD server 
just to prevent it.  If I were an attacker who wanted to DoS a cert 
discovery mechanism like Untrusted SCVP or non-SSL LDAP, I could come up 
with about 20 easier and more fruitful attacks.

Am I correct that this is the only reason to require mandatory 
signatures on DPD responses?

Ambarish Malpani wrote:
> 
> Hi Dave,
>     I don't thing speed of signing is a legitimate concern these
> days. If folks want to deploy a DPD server without needing to
> worry about key security, they can always use 512 bit software
> keys for their RSA operations.
> 
> I can generate over 1000 512 bit RSA signatures on my laptop. I am
> sure the other work that the SCVP server will do in path creation
> will overwhelm the work done for the signing.

From: "Ambarish Malpani" <[email-masked]>
To: "'Dave Engberg'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 5 Apr 2004 18:17:20 -0700
Importance: Normal
Sender: [email-masked]

Hi Dave,
    I don't thing speed of signing is a legitimate concern these
days. If folks want to deploy a DPD server without needing to
worry about key security, they can always use 512 bit software
keys for their RSA operations.

I can generate over 1000 512 bit RSA signatures on my laptop. I am
sure the other work that the SCVP server will do in path creation
will overwhelm the work done for the signing.

A

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Engberg
> Sent: Monday, April 05, 2004 1:18 PM
> To: Stephen Kent
> Cc: [email-masked]
> Subject: RE: Signing Untrusted SCVP?
> 
> 
> 
> 
> Stephen -
> 
> Sorry, I wasn't clear enough on pregeneration.  In the 
> current draft, the combination of a mandatory signature (or 
> MAC) plus the mandatory RequestReference inclusion in every 
> response means that you can never provide SCVP DPD without 
> using a protected online key for each transaction.  No caching (e.g.
> http://www.rfc-editor.org/internet-drafts/draft-deacon-lightwe
> ight-ocsp-
> profile-00.txt, section 4.2), no pregeneration, no keyless 
> DPD servers.
> 
> 
> My preference would be support for keyless DPD through 
> optional signatures, but pregeneration with a keyless HTTP 
> caching tier would be an unpleasant second option that would 
> require that the RequestReference be made optional.  Without 
> at least one of these options, I'm pessimistic about SCVP's 
> usability for the sort of big (e.g. governmental, 
> inter-banking) PKIs that my company works with.
> 
> My reference to DPV security is well summarized in section 10 
> of the SCVP spec:
> 
>    A client that trusts a server's response for validation of a 
>    certificate inherently trusts that server as much as it 
> would trust 
>    its own validation software.  This means that if an attacker 
>    compromises a trusted SCVP server, the attacker can change the 
>    validation processing for every client that relies on that 
> server.  
>    Thus, an SCVP server must be protected at least as well as the 
>    trust anchors that the SCVP server trusts.
> 
> In a serious PKI, most trust anchors are highly secured 
> offline roots with armed guards and missile launchers and 
> whatnot.  I'm nervous about trying to secure online DPV 
> servers "at least as well as" PKI trust anchors, and then 
> service millions of requests a day from them over public 
> networks.  Server compromise (network or physical) of an 
> explicitly-trusted DPV server would be a very bad thing until 
> you catch it and reconfigure every relying client.
> 
> 
> 
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Monday, April 05, 2004 1:58 PM
> To: Dave Engberg
> Cc: [email-masked]
> Subject: RE: Signing Untrusted SCVP?
> 
> At 12:17 PM -0400 4/5/04, Dave Engberg wrote:
> 
> ...
> 
> >I actually have a strong preference
> >AGAINST pre-signing (or any kind of signing) for DPD responses, which
> >is the opposite of CoreStreet's preferred approach to OCSP.
> 
> I'm surprised by that assertion, given your comment in the 
> previous message that pre-signed responses were a problem if 
> we require signed, nonced (pardon the neologism) responses 
> for DVD. if you are not a fan of pre-signed responses, I 
> would not have expected you to cite that concern, nor raise 
> the related issue of the cost of an expensive crypto module. 
> But, I'll take your word that these arguments, which seem to 
> be motivated by a preference for pre-signing, are not really 
> representative of your personal views.
> 
> ...
> 
> >To be less
> >circumspect about my motives:  I am interested in DPD and DPV, but
> >believe that SCVP DPV is a gigantic step backward for PKI security,
> 
> What parts of the rationale in 3379 for DPV do you not 
> believe are true?
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 5 Apr 2004 17:43:13 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, "Dave Engberg" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Michael,
I thought the question was scaling given Dave's comments on
pre-generation of responses. I seem to remember somewhere else a
discussion on pre-canned vs. non-pre-canned responses.

Trevor

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Monday, April 05, 2004 3:34 PM
To: Trevor Freeman; Dave Engberg; Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor,

Is not the issue at hand whether not DPD responses MUST be
signed?

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Monday, April 05, 2004 2:44 PM
To: Dave Engberg; Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

So Dave, if we supported the ability for the client to specify
if it
wanted a fresh response vs. would accept a pre caned response -
would
that address you concern?
Trevor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Monday, April 05, 2004 1:18 PM
To: Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Stephen -

Sorry, I wasn't clear enough on pregeneration.  In the current
draft,
the combination of a mandatory signature (or MAC) plus the
mandatory
RequestReference inclusion in every response means that you can
never
provide SCVP DPD without using a protected online key for each
transaction.  No caching (e.g.
http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweig
ht-ocsp-
profile-00.txt, section 4.2), no pregeneration, no keyless DPD
servers.

My preference would be support for keyless DPD through optional
signatures, but pregeneration with a keyless HTTP caching tier
would be
an unpleasant second option that would require that the
RequestReference
be made optional.  Without at least one of these options, I'm
pessimistic about SCVP's usability for the sort of big (e.g.
governmental, inter-banking) PKIs that my company works with.

My reference to DPV security is well summarized in section 10 of
the
SCVP spec:

   A client that trusts a server's response for validation of a
   certificate inherently trusts that server as much as it would
trust
   its own validation software.  This means that if an attacker
   compromises a trusted SCVP server, the attacker can change
the
   validation processing for every client that relies on that
server.
   Thus, an SCVP server must be protected at least as well as
the
   trust anchors that the SCVP server trusts.

In a serious PKI, most trust anchors are highly secured offline
roots
with armed guards and missile launchers and whatnot.  I'm
nervous about
trying to secure online DPV servers "at least as well as" PKI
trust
anchors, and then service millions of requests a day from them
over
public networks.  Server compromise (network or physical) of an
explicitly-trusted DPV server would be a very bad thing until
you catch
it and reconfigure every relying client.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, April 05, 2004 1:58 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

At 12:17 PM -0400 4/5/04, Dave Engberg wrote:

...

>I actually have a strong preference
>AGAINST pre-signing (or any kind of signing) for DPD responses,
which
>is the opposite of CoreStreet's preferred approach to OCSP.

I'm surprised by that assertion, given your comment in the
previous
message that pre-signed responses were a problem if we require
signed,
nonced (pardon the neologism) responses for DVD. if you are not
a fan of
pre-signed responses, I would not have expected you to cite that
concern, nor raise the related issue of the cost of an expensive
crypto
module. But, I'll take your word that these arguments, which
seem to be
motivated by a preference for pre-signing, are not really
representative
of your personal views.

...

>To be less
>circumspect about my motives:  I am interested in DPD and DPV,
but
>believe that SCVP DPV is a gigantic step backward for PKI
security,

What parts of the rationale in 3379 for DPV do you not believe
are true?

Date: Mon, 5 Apr 2004 19:30:10 -0500
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: clarification proposal -- Re: Current status of CRL validation ?
Sender: [email-masked]

At 3:31 PM -0700 4/5/04, Ed Gerck wrote:
>
>How about a clarification to be added to the current PKIX documents
>that deal with revocation and validation of certs? This would help
>the weary reader, who must otherwise wade through this list's archives
>in order to find the limitations we have been discussing. For example
>(using some of your previous text):

New work items are decided by the WG, not just one co-chair. You are 
asking the WG whether or not we should take up a clarification 
document based on just two paragraphs of text. As Steve said, we're 
trying to wind down, so such a generic request is really hard to 
support.

If you are serious about this work item (and I'm not suggesting that 
you are), please put together an abstract and a reasonably complete 
outline so the WG can see if we want to do it. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 05 Apr 2004 18:48:14 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
Subject: Re: Signing Untrusted SCVP?
Sender: [email-masked]

Trevor Freeman wrote:
> So Dave, if we supported the ability for the client to specify if it
> wanted a fresh response vs. would accept a pre caned response - would
> that address you concern?

That would be my second choice.

When a client asks an untrusted SCVP DPD server, "Please give me a path 
between certs A and E that satisfy constraints X," my first choice would 
be that the client could say "I don't need a signed response because I 
don't explicitly trust you."  The untrusted server would be able to 
provide a response ("B, C, and D") with an empty Set of SignerInfo.  The 
DPD server would not need to have any protected keys, in the same way 
that an LDAP directory fulfilling the same task would not be required to 
support SSL.  It lets a mature PKI use DPD without having to add yet 
another set of protected keys or new certificate profiles, etc.

My second choice would be what you describe.  I wouldn't continue to 
call this "untrusted" SCVP ... it's more like "semi-trusted."  In this 
mode, a client would indicate that it doesn't require a RequestReference 
(or a nonce), and a local keyless cache server could provide a cached or 
pregenerated response ("B, C, and D") which was previously signed.

Thanks

From: "Michael Myers" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Dave Engberg" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 5 Apr 2004 15:33:42 -0700
Importance: Normal
Sender: [email-masked]

Trevor,

Is not the issue at hand whether not DPD responses MUST be
signed?

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Monday, April 05, 2004 2:44 PM
To: Dave Engberg; Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

So Dave, if we supported the ability for the client to specify
if it
wanted a fresh response vs. would accept a pre caned response -
would
that address you concern?
Trevor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Monday, April 05, 2004 1:18 PM
To: Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Stephen -

Sorry, I wasn't clear enough on pregeneration.  In the current
draft,
the combination of a mandatory signature (or MAC) plus the
mandatory
RequestReference inclusion in every response means that you can
never
provide SCVP DPD without using a protected online key for each
transaction.  No caching (e.g.
http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweig
ht-ocsp-
profile-00.txt, section 4.2), no pregeneration, no keyless DPD
servers.

My preference would be support for keyless DPD through optional
signatures, but pregeneration with a keyless HTTP caching tier
would be
an unpleasant second option that would require that the
RequestReference
be made optional.  Without at least one of these options, I'm
pessimistic about SCVP's usability for the sort of big (e.g.
governmental, inter-banking) PKIs that my company works with.

My reference to DPV security is well summarized in section 10 of
the
SCVP spec:

   A client that trusts a server's response for validation of a
   certificate inherently trusts that server as much as it would
trust
   its own validation software.  This means that if an attacker
   compromises a trusted SCVP server, the attacker can change
the
   validation processing for every client that relies on that
server.
   Thus, an SCVP server must be protected at least as well as
the
   trust anchors that the SCVP server trusts.

In a serious PKI, most trust anchors are highly secured offline
roots
with armed guards and missile launchers and whatnot.  I'm
nervous about
trying to secure online DPV servers "at least as well as" PKI
trust
anchors, and then service millions of requests a day from them
over
public networks.  Server compromise (network or physical) of an
explicitly-trusted DPV server would be a very bad thing until
you catch
it and reconfigure every relying client.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, April 05, 2004 1:58 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

At 12:17 PM -0400 4/5/04, Dave Engberg wrote:

...

>I actually have a strong preference
>AGAINST pre-signing (or any kind of signing) for DPD responses,
which
>is the opposite of CoreStreet's preferred approach to OCSP.

I'm surprised by that assertion, given your comment in the
previous
message that pre-signed responses were a problem if we require
signed,
nonced (pardon the neologism) responses for DVD. if you are not
a fan of
pre-signed responses, I would not have expected you to cite that
concern, nor raise the related issue of the cost of an expensive
crypto
module. But, I'll take your word that these arguments, which
seem to be
motivated by a preference for pre-signing, are not really
representative
of your personal views.

...

>To be less
>circumspect about my motives:  I am interested in DPD and DPV,
but
>believe that SCVP DPV is a gigantic step backward for PKI
security,

What parts of the rationale in 3379 for DPV do you not believe
are true?

Date: Mon, 05 Apr 2004 15:31:10 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: clarification proposal -- Re: Current status of CRL validation ?
Sender: [email-masked]

Stephen Kent wrote:
> Ed,
> 
> PKIX is winding down now; we are not taking on any new work items. I
> suspect that anything as basic as what you allude to would be a
> significant departure from what we have done, and thus is not
> appropriate for PKIX to pursue.

Steve,

How about a clarification to be added to the current PKIX documents
that deal with revocation and validation of certs? This would help 
the weary reader, who must otherwise wade through this list's archives
in order to find the limitations we have been discussing. For example 
(using some of your previous text):

NOTE:
 In X.509/PKIX only the issuer of a certificate can revoke it and there 
 is only one issuer for a given certificate. Therefore, a certificate 
 is either revoked or not. However, the ability of a RP to establish
 the validity of a certificate is a function of the certificate path 
 that the RP uses to validate the certificate, and of the access to 
 revocation status information available to the RP. Since there may be 
 more than one path used to validate the same certificate, it is possible 
 to obtain different answers to the question whether a certificate is 
 valid, depending on which path the RP uses. Also, two RPs may have 
 access to different revocation status data for the EE certificate or for
 a CA certificate along a path, so that each RP may arrive at a different
 view of the validity of the EE certificate at any given time.

 Moreover, in X.509/PKIX reliance terms, one may trust the confirmation 
 procedures of the issuer CA, the issuer CA Designated Responder or any 
 Trusted Responder during certificate reliance (i.e., whether the 
 certificate has been revoked or not) under CRLs or OCSPs, but one cannot
 rely upon them for other than their value as a representation of the 
 issuer CA revocation management as expressed in the issuer CA own terms 
 and rules, usually contained in the CA CPS.

Comments?

Cheers,
Ed Gerck

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 5 Apr 2004 14:43:30 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Dave Engberg" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

So Dave, if we supported the ability for the client to specify if it
wanted a fresh response vs. would accept a pre caned response - would
that address you concern?
Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Monday, April 05, 2004 1:18 PM
To: Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Stephen -

Sorry, I wasn't clear enough on pregeneration.  In the current draft,
the combination of a mandatory signature (or MAC) plus the mandatory
RequestReference inclusion in every response means that you can never
provide SCVP DPD without using a protected online key for each
transaction.  No caching (e.g.
http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweight-ocsp-
profile-00.txt, section 4.2), no pregeneration, no keyless DPD servers.

My preference would be support for keyless DPD through optional
signatures, but pregeneration with a keyless HTTP caching tier would be
an unpleasant second option that would require that the RequestReference
be made optional.  Without at least one of these options, I'm
pessimistic about SCVP's usability for the sort of big (e.g.
governmental, inter-banking) PKIs that my company works with.

My reference to DPV security is well summarized in section 10 of the
SCVP spec:

   A client that trusts a server's response for validation of a 
   certificate inherently trusts that server as much as it would trust 
   its own validation software.  This means that if an attacker 
   compromises a trusted SCVP server, the attacker can change the 
   validation processing for every client that relies on that server.  
   Thus, an SCVP server must be protected at least as well as the 
   trust anchors that the SCVP server trusts.

In a serious PKI, most trust anchors are highly secured offline roots
with armed guards and missile launchers and whatnot.  I'm nervous about
trying to secure online DPV servers "at least as well as" PKI trust
anchors, and then service millions of requests a day from them over
public networks.  Server compromise (network or physical) of an
explicitly-trusted DPV server would be a very bad thing until you catch
it and reconfigure every relying client.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, April 05, 2004 1:58 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

At 12:17 PM -0400 4/5/04, Dave Engberg wrote:

...

>I actually have a strong preference
>AGAINST pre-signing (or any kind of signing) for DPD responses, which 
>is the opposite of CoreStreet's preferred approach to OCSP.

I'm surprised by that assertion, given your comment in the previous
message that pre-signed responses were a problem if we require signed,
nonced (pardon the neologism) responses for DVD. if you are not a fan of
pre-signed responses, I would not have expected you to cite that
concern, nor raise the related issue of the cost of an expensive crypto
module. But, I'll take your word that these arguments, which seem to be
motivated by a preference for pre-signing, are not really representative
of your personal views.

...

>To be less
>circumspect about my motives:  I am interested in DPD and DPV, but 
>believe that SCVP DPV is a gigantic step backward for PKI security,

What parts of the rationale in 3379 for DPV do you not believe are true?

Date: Mon, 5 Apr 2004 17:14:07 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Current status of CRL validation ?
Cc: [email-masked]
Sender: [email-masked]

>Stephen Kent wrote:
>>
>>  Ed,
>>
>>  I'd like to respond to each of your points, but experience has shown
>>  that we never manage to get closure in these exchanges.
>>
>>  Since you are convinced that X.509 and PKIX standards do not address
>>  the real problems that a certification system should address, and
>>  since this list is devoted to PKIX standards development, let's just
>>  stop now and save everyone's time.
>
>Steve,
>
>Let me clarify. Nothing that I wrote is a critique of X.509 or
>PKIX. I use X.509/PKIX everyday. I'm simply stating that there is
>a problem with certificate validation in X.509/PKIX. The problem
>is very basic, as I outlined. I think it's incumbent upon the PKIX
>WG, sooner or later, to address the need for a better revocation
>mechanism.
>
>BTW, there is no closure possible ;-) I'd like keep this old
>grudge until it's solved.
>
>Cheers,
>Ed Gerck
>
>PS: Private mail is also fine if you want to exchange tentative ideas
>on this.

Ed,

PKIX is winding down now; we are not taking on any new work items. I 
suspect that anything as basic as what you allude to would be a 
significant departure from what we have done, and thus is not 
appropriate for PKIX to pursue.

Stev

Date: Mon, 5 Apr 2004 17:00:50 -0400
To: "Dave Engberg" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Cc: <[email-masked]>
Sender: [email-masked]

At 4:18 PM -0400 4/5/04, Dave Engberg wrote:
>Stephen -
>
>Sorry, I wasn't clear enough on pregeneration.  In the current draft,
>the combination of a mandatory signature (or MAC) plus the mandatory
>RequestReference inclusion in every response means that you can never
>provide SCVP DPD without using a protected online key for each
>transaction.  No caching (e.g.
>http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweight-ocsp-
>profile-00.txt, section 4.2), no pregeneration, no keyless DPD servers.

There is a difference between pre-generated OCSP responses and 
reliance on a lower level security protocol to provide integrity for 
queries and responses. But, you are right that the latter still 
requires a key in the server to authenticate it to clients.

>My preference would be support for keyless DPD through optional
>signatures, but pregeneration with a keyless HTTP caching tier would be
>an unpleasant second option that would require that the RequestReference
>be made optional.  Without at least one of these options, I'm
>pessimistic about SCVP's usability for the sort of big (e.g.
>governmental, inter-banking) PKIs that my company works with.

I'm not sure I have a preference, not having though about it in as much detail.

>My reference to DPV security is well summarized in section 10 of the
>SCVP spec:
>
>    A client that trusts a server's response for validation of a
>    certificate inherently trusts that server as much as it would trust
>    its own validation software.  This means that if an attacker
>    compromises a trusted SCVP server, the attacker can change the
>    validation processing for every client that relies on that server. 
>    Thus, an SCVP server must be protected at least as well as the
>    trust anchors that the SCVP server trusts.
>
>In a serious PKI, most trust anchors are highly secured offline roots
>with armed guards and missile launchers and whatnot.  I'm nervous about
>trying to secure online DPV servers "at least as well as" PKI trust
>anchors, and then service millions of requests a day from them over
>public networks.  Server compromise (network or physical) of an
>explicitly-trusted DPV server would be a very bad thing until you catch
>it and reconfigure every relying client.
>

first, the argument about well protected trust anchors is not only a 
bit hyperbolic, but it is also backwards, since a TA is defined as a 
public key and associated parameters, not a private key.

Anyway, we should be more precise in analyzing the two approaches. 
for example, the private keys that are maintained offline and are 
very well protected, are not used except as a compromise recovery 
mechanism. the keys can't be both offline and used for day to day 
issuance of certs and CRLs. rather the common mode of use entails a 
second tier of CAs that are used daily, and thus are not offline. 
these keys should be well protected and that's where the expensive 
FIPS-evaluated (gee, I hope you get better than level 2 for $20K, we 
used to sell our level 3 device for less than that!) crypto module 
comes into play. for cert & CRL signing the centralization of the CA 
function does not pose a problem, so one need not spend a lot on high 
quality crypto modules, since they are not being widely distributed.

the problem arose when we adopted OCSP, because now there was a 
notion of an online server that had a much higher transaction rate, 
and the compromise of the private key was almost as bad as compromise 
of the key used to sign CRLs (not certs). it is not literally as bad, 
because if one has a small population of users that access a given 
OCSP server, then the number of folks affected by a compromise of 
that one sever is correspondingly small. On the other hand, that 
local server is the authoritative revocation status source for ALL 
CAs, for its client population, so the impact of a local compromise 
is different.

But how bnad is it to deal with a compromise of an OCSP server's key? 
One might   have a set of OCSP servers whose certs are issued by an 
offline CA, and the CRL for this set is issued by the same CA. then 
if there is a compromise of a server's key, one can revoke the 
server's cert, issue a new one, and notify clients via a CRL. that 
CRL, if limited to just OCSP servers, should not grow too big and 
thus its distribution and caching is not onerous. this hybrid scheme 
would help mitigate the risks associated with having keys in OCSP 
servers. The residual problem for live responses is performance, not 
security.

Still, I think we agree that DPV, like OCSP, is most appropriate for 
enterprise customers, not as a public service. the impact of 
compromise is less severe and ability to recover from compromise is 
better when the scope is limited. one has to balance the ability of 
an enterprise security admin to configuration manage lots of 
workstations and servers, vs. the ability to secure a few DPV 
servers. we have a lot of experience that suggests the configuration 
management task is hard and that admins usually fail. firewalls are 
attractive because they allow admins to focus efforts on a few, 
centrally managed resources that the admins control.

there is a lesson here.

Steve

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 5 Apr 2004 13:22:34 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Dave Engberg" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Dave,
The private key protection is a question of assurance which is an
implementation and deployment issue. A large % of the world continues to
function with FIPS- level 1 crypto since that level of assurance meets
their needs.
Trevor

-----Original Message-----
From: Dave Engberg [mailto:[email-masked]] 
Sent: Monday, April 05, 2004 10:08 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

The issue isn't performance, it's security.  If the private/secret keys
that you are using matter, then a real-world PKI will need to protect
them with an appropriate FIPS Level 2+ token.  This limits where you can
deploy the servers, who can manage it, per-server cost, and overall
solution scalability.

If the keys don't matter, than the signature/MAC shouldn't be mandatory.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Monday, April 05, 2004 12:56 PM
To: Dave Engberg; Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Dave,
I don't see the need for the option you suggest. Give today system
performance there is no need to add HSMs to do PK signatures. We also
don't mandate that the response be PK signed since we also support HMAC
reposes which are very trivial to generate. 
Trevor

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 5 Apr 2004 16:18:18 -0400
From: "Dave Engberg" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Stephen -

Sorry, I wasn't clear enough on pregeneration.  In the current draft,
the combination of a mandatory signature (or MAC) plus the mandatory
RequestReference inclusion in every response means that you can never
provide SCVP DPD without using a protected online key for each
transaction.  No caching (e.g.
http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweight-ocsp-
profile-00.txt, section 4.2), no pregeneration, no keyless DPD servers.

My preference would be support for keyless DPD through optional
signatures, but pregeneration with a keyless HTTP caching tier would be
an unpleasant second option that would require that the RequestReference
be made optional.  Without at least one of these options, I'm
pessimistic about SCVP's usability for the sort of big (e.g.
governmental, inter-banking) PKIs that my company works with.

My reference to DPV security is well summarized in section 10 of the
SCVP spec:

   A client that trusts a server's response for validation of a 
   certificate inherently trusts that server as much as it would trust 
   its own validation software.  This means that if an attacker 
   compromises a trusted SCVP server, the attacker can change the 
   validation processing for every client that relies on that server.  
   Thus, an SCVP server must be protected at least as well as the 
   trust anchors that the SCVP server trusts.

In a serious PKI, most trust anchors are highly secured offline roots
with armed guards and missile launchers and whatnot.  I'm nervous about
trying to secure online DPV servers "at least as well as" PKI trust
anchors, and then service millions of requests a day from them over
public networks.  Server compromise (network or physical) of an
explicitly-trusted DPV server would be a very bad thing until you catch
it and reconfigure every relying client.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, April 05, 2004 1:58 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

At 12:17 PM -0400 4/5/04, Dave Engberg wrote:

...

>I actually have a strong preference
>AGAINST pre-signing (or any kind of signing) for DPD responses, which 
>is the opposite of CoreStreet's preferred approach to OCSP.

I'm surprised by that assertion, given your comment in the previous
message that pre-signed responses were a problem if we require signed,
nonced (pardon the neologism) responses for DVD. if you are not a fan of
pre-signed responses, I would not have expected you to cite that
concern, nor raise the related issue of the cost of an expensive crypto
module. But, I'll take your word that these arguments, which seem to be
motivated by a preference for pre-signing, are not really representative
of your personal views.

...

>To be less
>circumspect about my motives:  I am interested in DPD and DPV, but 
>believe that SCVP DPV is a gigantic step backward for PKI security,

What parts of the rationale in 3379 for DPV do you not believe are true?

Date: Mon, 05 Apr 2004 11:55:00 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

Stephen Kent wrote:
> 
> Ed,
> 
> I'd like to respond to each of your points, but experience has shown
> that we never manage to get closure in these exchanges.
> 
> Since you are convinced that X.509 and PKIX standards do not address
> the real problems that a certification system should address, and
> since this list is devoted to PKIX standards development, let's just
> stop now and save everyone's time.

Steve,

Let me clarify. Nothing that I wrote is a critique of X.509 or
PKIX. I use X.509/PKIX everyday. I'm simply stating that there is 
a problem with certificate validation in X.509/PKIX. The problem
is very basic, as I outlined. I think it's incumbent upon the PKIX
WG, sooner or later, to address the need for a better revocation
mechanism.

BTW, there is no closure possible ;-) I'd like keep this old
grudge until it's solved.

Cheers,
Ed Gerck

PS: Private mail is also fine if you want to exchange tentative ideas
on this.

Date: Mon, 5 Apr 2004 13:57:46 -0400
To: "Dave Engberg" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Cc: <[email-masked]>
Sender: [email-masked]

At 12:17 PM -0400 4/5/04, Dave Engberg wrote:
>Stephen -
>
>I assume that the "From" address in my email message makes it pretty
>up-front what company I work for.

yes, but I don't assume an employee necessarily agrees with all of 
his/her employer's technical positions, and IETF policy argues that 
one ought not make such assumptions.

>I actually have a strong preference
>AGAINST pre-signing (or any kind of signing) for DPD responses, which is
>the opposite of CoreStreet's preferred approach to OCSP.

I'm surprised by that assertion, given your comment in the previous 
message that pre-signed responses were a problem if we require 
signed, nonced (pardon the neologism) responses for DVD. if you are 
not a fan of pre-signed responses, I would not have expected you to 
cite that concern, nor raise the related issue of the cost of an 
expensive crypto module. But, I'll take your word that these 
arguments, which seem to be motivated by a preference for 
pre-signing, are not really representative of your personal views.

>To be less
>circumspect about my motives:  I am interested in DPD and DPV, but
>believe that SCVP DPV is a gigantic step backward for PKI security,

What parts of the rationale in 3379 for DPV do you not believe are true?

>and
>want to figure out whether SCVP DPD can be tweaked to support large
>(multi-million-user) environments with hundreds of DPD servers around
>the world on public networks.  If so, CoreStreet may consider product
>development in this area, probably without a pregeneration approach.
>
>Anyhoo ... my preference is your second option.  Allow SCVP servers to
>be deployed by environments that only use DPD, without requiring that
>those servers protect any private keys "just in case".  This is the same
>as allowing some CAs to distribute CRLs only via LDAP or HTTP
>directories that don't implement SSL.  This avoids "over PKIing" the
>SCVP DPD protocol just to slightly mitigate one minor and baroque type
>of DoS.

Well, at least we agree on a resolution to the issue.

Steve

Date: Mon, 5 Apr 2004 14:08:05 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Current status of CRL validation ?
Cc: [email-masked]
Sender: [email-masked]

Ed,

I'd like to respond to each of your points, but experience has shown 
that we never manage to get closure in these exchanges.

Since you are convinced that X.509 and PKIX standards do not address 
the real problems that a certification system should address, and 
since this list is devoted to PKIX standards development, let's just 
stop now and save everyone's time.

Steve

Date: Mon, 5 Apr 2004 14:04:21 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Cc: <[email-masked]>
Sender: [email-masked]

At 12:03 AM -0400 4/3/04, Santosh Chokhani wrote:
>Steve:
>
>I do not see a particular reason to require a DPD Server to be held to a
>higher standard then a Directory Server.  We do not require signed responses
>from Directories.  Both being stationary servers, are equally prone to
>hacking.  Also, in order to verify the DPD Server signature, the client may
>get into another problem of obtaining a path for the DPD Server itself, which
>may not be a circular problem, but will degrade performance

We are not the LDAP WG, so we don't make requirements for directory 
access, as I noted in my previous message.  (Our last foray into that 
area is a superceded RFC that had mixed feelings about DoS issues.)

I thought there was a clear need to configure clients with an ability 
to directly verify signatures for DPD and DPV servers. Otherwsie, as 
you note, a circular dependency can arise.

Steve

Date: Mon, 5 Apr 2004 19:43:04 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?
Sender: [email-masked]

> 
> Hi Dave,
> I don't see the need for the option you suggest. Give today system
> performance there is no need to add HSMs to do PK signatures. We also
> don't mandate that the response be PK signed since we also support HMAC
> reposes which are very trivial to generate. 
> Trevor

The current text seems unclear to me concerning the interoperability
between clients and servers. What if a client can only support 
authenticated data and the server can only support signeddata.

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 5 Apr 2004 13:07:51 -0400
From: "Dave Engberg" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

The issue isn't performance, it's security.  If the private/secret keys
that you are using matter, then a real-world PKI will need to protect
them with an appropriate FIPS Level 2+ token.  This limits where you can
deploy the servers, who can manage it, per-server cost, and overall
solution scalability.

If the keys don't matter, than the signature/MAC shouldn't be mandatory.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Monday, April 05, 2004 12:56 PM
To: Dave Engberg; Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Dave,
I don't see the need for the option you suggest. Give today system
performance there is no need to add HSMs to do PK signatures. We also
don't mandate that the response be PK signed since we also support HMAC
reposes which are very trivial to generate. 
Trevor

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 5 Apr 2004 09:55:55 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Dave Engberg" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Dave,
I don't see the need for the option you suggest. Give today system
performance there is no need to add HSMs to do PK signatures. We also
don't mandate that the response be PK signed since we also support HMAC
reposes which are very trivial to generate. 
Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Friday, April 02, 2004 2:33 PM
To: Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

An attacker with the ability to intercept your SCVP calls and send back
spoofed responses has a more obvious way to deny service ...

More seriously, I think we agree that there should absolutely be an
option in the protocol to allow a client to request a signed response,
and for the server to provide it.  But by making this an absolute hard
requirement for every client-server pair, you are permanently preventing
the SCVP protocol from being used with any caching or pregeneration at
the server level when used for pure DPD, and you're adding 150 bytes and
50 ms onto every response (plus $20k for a FIPS HSM, if you're serious).

Think of pure DPD as an optimized mechanism for doing certificate
lookups, as an alternative to LDAP.  Previously, PKI standards have not
forced every LDAP lookup to use authenticated SSL tunnels, because most
clients derive their security from the signatures on the retrieved
objects rather than the transport mechanism.  The gratuitous requirement
for SSL on every LDAP query would just further reduce performance and
increase costs for PKI deployments.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, April 02, 2004 4:45 PM
To: Dave Engberg
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

Dave,

I agree that one might not want to invest as much effort and money in
securing a DPD server as a DPV server. But that does not necessarily
translate into removing the need for signatures on responses from such
servers. If responses from a DPD server are spoofed, a client may be
subject to a form of DoS attack, as it tries to make use of bogus certs
formed chains intended to maximize the amount of crypto processing the
client does, before realizing that the chain is bad. 
Or certs might be returned that conflict with certs from some other DPD
server.  Without signed responses it could be very hard to determine
what went wrong and what servers ought to be avoided, based on bad
behavior.

Steve

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Mon, 5 Apr 2004 12:17:18 -0400
From: "Dave Engberg" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Stephen -

I assume that the "From" address in my email message makes it pretty
up-front what company I work for.  I actually have a strong preference
AGAINST pre-signing (or any kind of signing) for DPD responses, which is
the opposite of CoreStreet's preferred approach to OCSP.  To be less
circumspect about my motives:  I am interested in DPD and DPV, but
believe that SCVP DPV is a gigantic step backward for PKI security, and
want to figure out whether SCVP DPD can be tweaked to support large
(multi-million-user) environments with hundreds of DPD servers around
the world on public networks.  If so, CoreStreet may consider product
development in this area, probably without a pregeneration approach.

Anyhoo ... my preference is your second option.  Allow SCVP servers to
be deployed by environments that only use DPD, without requiring that
those servers protect any private keys "just in case".  This is the same
as allowing some CAs to distribute CRLs only via LDAP or HTTP
directories that don't implement SSL.  This avoids "over PKIing" the
SCVP DPD protocol just to slightly mitigate one minor and baroque type
of DoS.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, April 05, 2004 11:41 AM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

...

	- the pre-generation issue is what I bet is your major concern,
consistent with you company's model for OCSP, and your should have been
more up front about that in your first message

...

RFC 3379 (2002) established requirements for DPD and said that
authenticated  requests and responses MAY be required. So, that RFC does
not mandate integrity and authenticity for these exchanges, and it
explicitly allows for use of lower layer mechanisms to provide these
services.

So, we could mandate that DPD servers support signed requests and
responses, and allow local users and admins to choose whether to invoke
the feature, or we make it an optional aspect of implementations.  I do
worry that the latter approach will result in depriving clients of the
option, due to the sort of marketplace pressures that became evident in
our discussion of pre-generated OCSP responses.

Steve

Date: Mon, 5 Apr 2004 11:15:43 -0400
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Single Identity. Was: PKI International Consortium
Cc: "PKIX list" <[email-masked]>, <[email-masked]>, "Arshad Noor" <[email-masked]>, <[email-masked]>, "Terwilliger, Ann" <[email-masked]>, "Eric Norman" <[email-masked]>
Sender: [email-masked]

At 4:37 PM +0200 4/4/04, Anders Rundgren wrote:
>Dear PKIers,
>I could not resist this one as I have worked with this idea since
>1997....
>
>The quest for a single identity
>---------------------------------
>Assume that an international consortium of banks indeed agreed
>on a common certificate issuance policy of a relatively high level
>(as well as shelving the four-corner model), I believe you would
>have a very good foundation for a universal single-identity scheme.
>It is worth noting that a single identity is a reality in Sweden since
>around 1960 so this is a time-proven scheme as well.

As Al notes, different cultures have different operating models. What 
may work for Sweden may not work elsewhere.

>A tricky real-life use-case
>-----------------------------
>Now assume that you one day lose your wallet [1] with ID-
>certificates when you are on an oversea trip.  Who will have
>the swift and secure way back?  The individual with a handful
>of locally issued credentials, or the individual who have a
>single credential issued by a member of a trusted network of
>international issuers having branch offices in every town of
>any size worth mentioning?

As Al pointed out, reality is much different from your model. A real 
advantage to having multiple credentials for different purposes is 
that you can use the alternatives that were not lost/stolen. Also, in 
the U.S. some folks subscribe to a service that will notify affected 
credential issuers when you lose credentials, and that eases the 
burden if multiple credentials are lost at the same time.

>Most security folks only look to revocation issues but it is
>really at least as critical to get replacement credentials as you
>in an anticipated "e-society" will be completely handicapped
>without getting access to your work, bank, e-government etc.

When I needed to have my wife's Amex card replaced a few years ago, 
not because we lost it but because of fraudulent use, we had a new 
one in less than 48 hours. That is not the sort of service I would 
expect from my government ;-) BTW, given your notion of a "trusted 
network of International issuers" I guess Amex would qualify, but I 
doubt that my Amex card will be accepted by immigration folks at 
either end of my return trip. I'll need to contact my embassy or 
consulate for that sort of assistance.

>
>TTPs rule - Like it or not
>-----------------------------
>Some people object to the TTP idea but the reality is that
>all issuances not based on DNA or similar "body-based-
>authentication", already fully depend on TTP-issued
>passports, driver licenses, gas bills (!) etc.

nonsense. an organization that is authoritative for the credentials 
it issues is NOT like the TTPs you cite, which are authoritative for 
nothing, but which are good at collecting fees.

I won't bother addressing the rest of your message; Al did a good job 
of noting the issues I would have commented upon.

Steve

Date: Mon, 5 Apr 2004 10:22:31 -0400
To: Eric Norman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PKI International Consortium
Cc: PKIX list <[email-masked]>
Sender: [email-masked]

At 2:35 PM -0600 4/3/04, Eric Norman wrote:
>On Sat, 3 Apr 2004 [email-masked] wrote:
>
>>  The newest version of X.509 provides a more suitable solution because it
>>  clearly defines a framework where identity and attribute certificates,
>>  although related, can be independently managed. That recommendation defines
>>  new types of authorities, Attribute Authorities (AA), for the assignment of
>>  privileges. It also defines the Source of Authority (SOA) as the ultimate
>>  authority to assign a set of privileges. Additionally, it provides a
>>  foundation to build a Privilege Management Infrastructure (PMI) 
>>that contain a
>>  multiplicity of AAs, SOAs and final users.
>>
>>  So, summarizing, if the idea is to have "context-sensitive identities",
>>  then "Attribute Certificates" linked to a single "Identity Certificate" are
>>  the best solution.
>
>If a relying party needs to know that I possess certain attributes, and
>if I can present an "Attribute Certificate" that convinces them that I
>do indeed possess those attributes, then what purpose is served by also
>having me present an "Identity Certificate"?

Eric, recall that an attribute cert does not contain a public key, so 
presentation of an attribute cert does not provide a secure 
association between the presenter and the cert.

Steve

Date: Mon, 5 Apr 2004 11:40:44 -0400
To: "Dave Engberg" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Cc: <[email-masked]>
Sender: [email-masked]

At 5:32 PM -0500 4/2/04, Dave Engberg wrote:
>An attacker with the ability to intercept your SCVP calls and send back
>spoofed responses has a more obvious way to deny service ...

	remember, the example I gave has the property that it burns 
cycles on the client computer, irrespective of consuming network 
bandwidth. also, since you mention pre-generated responses below (a 
favorite technical strategy for your company, if I recall), then 
there would be no basis for a challenge response scheme. thus whether 
the adversary has to intercept you request or not is not at all clear.

>More seriously, I think we agree that there should absolutely be an
>option in the protocol to allow a client to request a signed response,
>and for the server to provide it.  But by making this an absolute hard
>requirement for every client-server pair, you are permanently preventing
>the SCVP protocol from being used with any caching or pregeneration at
>the server level when used for pure DPD, and you're adding 150 bytes and
>50 ms onto every response (plus $20k for a FIPS HSM, if you're serious).

	- the pre-generation issue is what I bet is your major 
concern, consistent with you company's model for OCSP, and your 
should have been more up front about that in your first message

	- given the size of the certs being returned, often multiple 
certs, it is hard to get excited about the bandwidth devoted to 
carrying a signature

	- you keep mentioning the costs of a FIPS evaluated HSM, 
which is a red herring, since PKIX makes NO statements about the 
level of assurance for the crypto implementations required for any of 
our standards.

>Think of pure DPD as an optimized mechanism for doing certificate
>lookups, as an alternative to LDAP.  Previously, PKI standards have not
>forced every LDAP lookup to use authenticated SSL tunnels, because most
>clients derive their security from the signatures on the retrieved
>objects rather than the transport mechanism.  The gratuitous requirement
>for SSL on every LDAP query would just further reduce performance and
>increase costs for PKI deployments.

this is a better line of argument.

The old PKIX document on this topic was RFC 2559 (from 1999). It was 
replaced by an RFC that is NOT a PKIX document, and thus does not 
necessarily represent a PKIX view of what is or is not appropriate in 
this context.  2559 said that additional integrity services were not 
required for LDAP responses, although it did call for SSL use for CA 
access to an LDAP server, to prevent denial of service attacks that 
could result if CRLs or certs were replaced with bogus replicas.  So, 
that RFC acknowledges that if a client gets only bogus certs (because 
the LDAP entries are corrupted) we have a DoS problem, yet if did not 
require integrity on retrieval of certs and CRLs from the LDAP 
server.  We seemed to have been of two minds here :-)

RFC 3379 (2002) established requirements for DPD and said that 
authenticated  requests and responses MAY be required. So, that RFC 
does not mandate integrity and authenticity for these exchanges, and 
it explicitly allows for use of lower layer mechanisms to provide 
these services.

So, we could mandate that DPD servers support signed requests and 
responses, and allow local users and admins to choose whether to 
invoke the feature, or we make it an optional aspect of 
implementations.  I do worry that the latter approach will result in 
depriving clients of the option, due to the sort of marketplace 
pressures that became evident in our discussion of pre-generated OCSP 
responses.

Steve

Date: Mon, 5 Apr 2004 11:15:59 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: PKI International Consortium
Cc: Arshad Noor <[email-masked]>, PKIX list <[email-masked]>
Sender: [email-masked]

At 12:57 PM +0100 4/3/04, [email-masked] wrote:
>Hi all,
>
>In line with Arshad's comments, I think there's some kind of misunderstanding
>in this discussion. It seems that we're confusing Identity and Attributes (or
>privileges). It is reasonable to think that one entity (anything that can have
>a certificate) should have only one Identity (and therefore, only one Identity
>Certificate). There are reasons that may justify having more than one
>Identity, and I will come to that later, but let's assume for now that only
>one Identity is enough.

See the recent National Research Council report: "Who Goes there? 
Authentication Through the Lens of Privacy" for a detailed discussion 
of why there is not really ONE identity for an individual, in the 
sense that we're discussing here.

Steve

Date: Mon, 5 Apr 2004 11:12:32 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: PKI International Consortium
Cc: PKIX list <[email-masked]>, Arshad Noor <[email-masked]>, "Anders Rundgren" <[email-masked]>
Sender: [email-masked]

At 5:37 PM -0500 4/2/04, [email-masked] wrote:
>Hello everyone,
>
>Quote from bbn.com : "In 1968, the Advanced Research Projects Agency (ARPA)
>sent out a Request for Quotation (RFQ) to build a network of four Interface
>Message Processors (IMPs). Many of the large computer and
>telecommunications organizations didn't even respond--they thought it was
>impossible. " - http://bbn.com/arpanet/index.html.
>
>If the pioneers believed that "Internet" is impossible, then I dont think
>we would enjoy sending these emails today.

As the Chief Scientist for Information Security here at BBN, I don't 
think the analogy is at all relevant to our current discussion.

>Anyway, consider the following:
>
>1. A central authority issues and maintains certificates for the customers
>of FI. The central authority prescribes a set of standards and regulations
>on creation, issuance and maintenance of the certificate.
>2. The FI or independent agents may issue the certificate on behalf of the
>central authority. However, the certificate issued to the customer should
>not have any direct relation to the FI (Financial Institution).
>3. The customer may subscribe for the services of an FI, identifying
>himself producing the certificate issued by the central authority.
>4. All verification of the certificate should be verified referring to the
>central authority.
>5. The customer has to produce the certificate to the FI whenever he/she
>would like to do a transaction. The FI may check for subscription of the
>customer and verify the credentials referring to the central authority.
>
>Of course, the availability, integrity and confidentiality of the system
>has to be considered for an ideal process such as above. However, with
>right technology and prevention mechanism in place, I believe such a system
>may be possible. Think about an "International Passport" with which you can
>travel to any country. However, your passport require an entry visa
>(subscription)  to the destination country. This way I avoid travelling
>with multiple passport (for person with multiple citizenship).

You miss the point, and your analogy is seriously flawed. Most folks 
have only one passport; unless you hold dual citizenship you 
generally don't get another passport. Visas are sometime required to 
admission to a country, in conjunction with a passport. In that 
sense, they are a lot like attribute certs used with identity certs.

A passport is the appropriate credential for identifying you as a 
citizen  of a specified country, but that's all it does. The name 
info on it is not unique, and the unique ID (the passport number) is 
not of use to most relying parties.  Try using your passport to make 
a purchase, instead of using a credit card and see how well this 
universal ID works. Conversely, try giving your credit card to the 
immigration officials and see what happens :-)

Steve

Date: Mon, 5 Apr 2004 11:16:29 -0400
To: Arshad Noor <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PKI International Consortium
Cc: [email-masked], PKIX list <[email-masked]>
Sender: [email-masked]

At 1:39 PM -0800 4/2/04, Arshad Noor wrote:
>I would concur with you, Steve, that a single certificate that serves all
>purposes, is neither practical nor desirable.  (Although I must confess
>to occassionally dreaming of such a utopian environment, sometimes).
>
>However, I believe, it is reasonable - assuming appropriate policy,
>process, implementation and most importantly, cooperation - to have
>industry-specific identities that may serve us all better.  ("Identity
>Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html).

two observations:
	- the implicit ad for your company in the URL above is 
inappropriate for the PKIX list

	- although one might imagine such certs, there are 
significant adverse privacy implications (see 
http://www.nap.edu/books/0309088968/html/)

>Companies waste far too much time and money today, building
>duplicate identity infrastructures - and consequently tying their own
>hands with context-sensitive identities - because it appears to be the
>path of least resistance to them.  But as the cost of identity theft &
>of managing those numerous identity infrastructures surpasses the
>perceived savings from using this path of least resistance, companies
>will be forced to rethink that strategy.

identity theft would likely be a bigger concern if we have fewer certs.

finally, I am concerned that your message seems to be so closely 
aligned with you company's products. if you want to continue this 
discussion, please do so without making it seem like an ad for your 
company's products and services.

Steve

From: Santoni Adriano <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Mon, 5 Apr 2004 17:28:58 +0200 
Sender: [email-masked]

Dear all,

I am probably asking an old question, so ... please be patient.

Rfc3280 states (�4.1.2.4): "...all certificates issued after December 31,
2003 MUST use the UTF8String encoding of DirectoryString...".

Does that mean that it is mandatory to always encode all RDNs (having a type
of DirectoryString) of the issuer and subject (and still other) certificate
fields as UTF8Strings _even if they could be correctly encoded as a
PrintableStrings_ ? 

TIA to all volunteers,
  Adriano

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

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

From: "Anders Rundgren" <[email-masked]>
To: "Al Arsenault" <[email-masked]>, "PKIX list" <[email-masked]>, <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Arshad Noor" <[email-masked]>, <[email-masked]>, "Terwilliger, Ann" <[email-masked]>, "Eric Norman" <[email-masked]>
Subject: Re: Single Identity. Was: PKI International Consortium
Date: Mon, 5 Apr 2004 15:01:13 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

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

AWA:  Speaking from practical experience (having a physical wallet =
lifted in Prague a few years back), it was easier NOT having a single =
credential.  Okay, the wallet with the cash, credit cards, US driver's =
license, pictures of the kids, medical insurance card, etc. is gone.  =
But, NOT the passport, and not the emergency credit card kept separate =
from the rest for exactly this eventuality.  Survival was assured until =
recovery could be accomplished.

AR: In my opinion you are describing something like a "credential =
backup" scheme which is pretty unrelated to the single credential issue. =
 Valid questions arise, like: Where do you keep the backups? Where would =
you keep your electronic IDs when on the road (where you need them)?  It =
looks to me that the "always connected" world creates new problems =
requiring more robust and universal solutions.   The globally supported =
trust network is my shot as this problem.

AWA:  Now, map this to the virtual world, where everything is stored in =
your mobile phone.  Whoops - mobile phone is lost/stolen.  So I go to =
the nearest branch of the "issuing agency".  The conversation goes =
something like Me: "excuse me, my name is Al Arsenault, and my ID was =
stolen.  I need a new one".   Agency:  "Prove that's who you are".  Me:  =
"How?  My one single ID was stolen, I need a new one".  Agency: "Yes, =
but if we believed you based on just what you're telling us, it could =
deny service to the REAL Al Arsenault, who our records show is out =
blithely spending money right now". (Somebody call John Cleese - there's =
a great Monty Python skit in here somewhere.)

AR: This situation is indeed a tricky one.  However, it gets more =
manageable when issuers have 24/7 helpdesks which allows the agency to =
look-up records and ask you to answer a few questions that only the =
original issuer and you have the answers to.  Since agencies have to =
authenticate to access external records (or identify themselves to an =
issuer helpdesk), a screw-up may lead to the agency's loss of their =
license.

AWA:  Yes, there's likely a way to PROVE that I'm the real Al Arsenault, =
but I hope it doesn't involve biometrics - don't get me started down =
that road. :-(

AR: Biometrics is of indeed a very vital part of such verifications.  =
Today this may just be your picture but tomorrow it will be DNA.  Since =
identity theft is admittedly the weak spot of the described scheme there =
are really no alternatives to biometrics except abandoning the whole =
thing.  AFAIK the US immigration authorities require (or are about to =
require) an extensive set of biometrics in passports so either we =
foreigners have to stay at home or deal with it.

AR: Regarding the value of single identities it is also a matter of =
cost.  The majority of people work for small businesses and these may =
find that using the already existing bank-issued IDs will be easier to =
use than putting out user-IDs and passwords.  The identity does not have =
to be an SSN, it may be your bank client number or some completely =
artificial number.  That is, bank-IDs do not have to "emulate" passports =
to be useful.

AR: Regarding multiple banks, I agree with you, you should not (mostly =
for commercial and political reasons) force a network of TTPs to be =
direct TTPs for each other.  So here there will be a deviation from the =
single ID.  However, you typically only need one "primary ID" for all =
your TTP-based ID-relations.

best
AR =3D Anders Rundgren

------=_NextPart_000_0075_01C41B1E.D68DE9D0
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>AWA:&nbsp; Speaking from practical =
experience=20
(having a physical wallet lifted in Prague a few years back), it was =
easier NOT=20
having a single credential.&nbsp; Okay, the wallet with the cash, credit =
cards,=20
US driver's license, pictures of the kids, medical insurance card, etc. =
is=20
gone.&nbsp; But, NOT the passport, and not the emergency credit card =
kept=20
separate from the rest for exactly this eventuality.&nbsp; Survival was =
assured=20
until recovery could be accomplished.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>AR: In my opinion you are describing =
something like=20
a "credential&nbsp;backup" scheme which is pretty unrelated to the =
single=20
credential issue.&nbsp; Valid questions&nbsp;arise, like: Where do you =
keep the=20
backups? Where would you keep your electronic IDs when on the road =
(where you=20
need them)?&nbsp; It looks to me that the "always connected" world =
creates=20
new&nbsp;problems&nbsp;requiring&nbsp;more robust and universal=20
solutions.&nbsp;&nbsp; The globally supported trust network is my shot =
as this=20
problem.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
size=3D3></FONT><BR>AWA:&nbsp; Now, map this to the virtual world, where =

everything is stored in your mobile phone.&nbsp; Whoops - mobile phone =
is=20
lost/stolen.&nbsp; So I go to the nearest branch of the "issuing =
agency".&nbsp;=20
The conversation goes something like Me: "excuse me, my name is Al =
Arsenault,=20
and my ID was stolen.&nbsp; I need a new one".&nbsp;&nbsp; Agency:&nbsp; =
"Prove=20
that's who you are".&nbsp; Me:&nbsp; "How?&nbsp; My one single ID was =
stolen, I=20
need a new one".&nbsp; Agency: "Yes, but if we believed you based on =
just what=20
you're telling us, it could deny service to the REAL Al Arsenault, who =
our=20
records show is out blithely spending money right now". (Somebody call =
John=20
Cleese - there's a great Monty Python skit in here =
somewhere.)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>AR: This situation is indeed a tricky =
one.&nbsp;=20
However, it gets more manageable when issuers have 24/7 helpdesks which =
allows=20
the agency to look-up records and ask you to answer a few questions that =
only=20
the original issuer and you have&nbsp;the answers to.&nbsp; Since =
agencies have=20
to authenticate to access external records (or identify themselves to an =

issuer&nbsp;helpdesk), a screw-up may lead to the agency's loss of their =

license.<BR><BR>AWA:&nbsp; Yes, there's likely a way to PROVE that I'm =
the real=20
Al Arsenault, but I hope it doesn't involve biometrics - don't get me =
started=20
down that road. :-(</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>AR: Biometrics is of indeed a very =
vital part of=20
such verifications.&nbsp; Today this may just be your picture but =
tomorrow it=20
will be DNA.&nbsp; Since identity theft is admittedly the weak spot of =
the=20
described scheme there are really no alternatives to biometrics except=20
abandoning the whole thing.&nbsp; AFAIK the US immigration authorities =
require=20
(or are about to require) an extensive set of biometrics in passports so =
either=20
we foreigners have to stay at home or deal with it.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>AR: Regarding the value of single =
identities it is=20
also a matter of cost.&nbsp; The majority of people work for small =
businesses=20
and these may find that using the <EM>already existing</EM> bank-issued =
IDs will=20
be easier to use than putting out user-IDs and passwords.&nbsp;=20
The&nbsp;identity does not have to be an SSN, it may be your bank client =
number=20
or some completely artificial number.&nbsp; That is, bank-IDs do not =
have to=20
"emulate" passports to be useful.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>AR: Regarding multiple banks, I agree =
with you, you=20
should not (mostly for commercial and political reasons) force&nbsp;a =
network=20
of&nbsp;TTPs to be direct TTPs for each other.&nbsp; So here there will =
be a=20
deviation from the single ID.&nbsp; However, you typically only need one =

"primary ID" for all your TTP-based ID-relations.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>best</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>AR =3D Anders Rundgren</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></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0075_01C41B1E.D68DE9D0--

Date: Sun, 04 Apr 2004 20:13:22 -0700
From: Ed Gerck <[email-masked]>
To: Eric Norman <[email-masked]>
CC: PKIX list <[email-masked]>
Subject: Re: Identity (was PKI International Consortium)
Sender: [email-masked]

Eric Norman wrote:
> 
> On Sun, 4 Apr 2004 [email-masked] wrote:
> 
> > So, again, in the design of Identity Certificates we should concentrate on
> > Identity issues, and on the needs of systems requiring identification. Trying
> > to use Identity Certificates for other uses is wrong.
> 
> Well, my opinion is that you won't have much luck dealing with "Identity
> issues" until you have a good definition of "identity".
> 
> Here's my shot at it.  If you start from the premise that identity is
> just a set of attributes, then your identity is those attributes that
> are constant and last forever.

Not even your fingerprints are constant and last forever (or, for your 
lifetime).

Identity is not a thing or a set of things. Identity is the connection
-- to identify is to seek connections [1]. In identification we look for 
logical or natural connections, where absence of connections also counts. 
For example:

- between a fingerprint and the person that has it,
- between a PK certificate and its private key,
- between a name and the person that answers by that name,
- between an Internet host and a URL that connects to it,
- between an idea and the way we can represent it in words,
- conversely, between words and the ideas they represent,
- etc.

Identification can thus be understood not only in the sense of an
"identity" connection, but in the wider sense of any connection.

That's why it does not make much sense to have *one* identity certificate
-- we do have many identities (connections) and we may need to use them 
in separate. Which one to use is just a matter of protocol expression, 
need, cost and (very importantly) privacy concerns [1]. 

Cheers,
Ed Gerck

[1] For my '98 draft on this concept, please see 
http://nma.com/mcg-mirror/coherence.txt
This work shows that not identity but coherence (as natural or logical
connections) is the general metric for identification. More coherence 
and more coherence modes mean stronger identification, even if anonymous.

Subject: Re: Identity (was PKI International Consortium)
To: Eric Norman <[email-masked]>
Cc: PKIX list <[email-masked]>, [email-masked]
From: [email-masked]
Date: Sun, 4 Apr 2004 20:57:59 -0600
Sender: [email-masked]

I've lately been busy working on X9.99 financial industry financial
standard for privacy, learning more than i want to do about EU-DPD, GLB and
HiPPA, etc. Somewhat to complement the merged security taxonomy & glossary
work
http://www.garlic.com/~lynn/index.html#glosnote

I've started a merged privacy taxonomy & glossary ... pulling from EU data
privacy directive, GLB, HiPPA, OMB, FTC and a couple others.

My earlier statement was that there was significant retrenchment from the
X.509 Identity certificates of the early '90s because of the serious
privacy issues that the information represented. The issue wasn't so much
what features in X.509 Identity certificates were related to identity ...
but what features in X.509 identity certificates that raised serious
privacy issues. EU-DPD, HiPPA, and GLB have issues about PHI (protected
health information) and PII (personally identifiable information) and
sensitive perosnally identifiable information.

>From their standpoint, it isn't so much identity information per se ... it
is any kind of personal information that adversely affect a person's
quality of living (like fraud, phishing, identity theft, etc).

In the past i've defined a taxonomy for authentication information and
certificates. In effect, there is some entity information that is
registered someplace ... likely at a certificate issuer ... but possibly
someplace else. The certificate issuer packages up a R/O copy of that
information and creates a static certificate containing that information
and distributes it (or at least returns the r/o copy of the information,
i.e. the certificate to the entity requesting the certificate). The
certificate by its very nature is static ... the digital signature of the
certificate issuer goes to a great deal of trouble to establish it as
static (and if it ever does change ... the certificate becomes invalid).

The certificate is, in a way, a high-integrity, static, r/o cached copy of
some information stored some place else. This allows it to be used in an
offline process when the relying-party doesn't otherwise have recourse to
the original information.

In that sense, it is directly analogous to CPU r/o cached entries, or
filesystem r/o cached records, or database r/o cached entriess.

Once the cached copy (certificate) is distributed, it by definition is
stale ... representing the state of some record at some time in the past.
The information contained in the cached certificate/copy may or may not be
stale, but by definition the certificate itself is stale.

So therefor, I assert that it is perfectly reasonable to refer to
certificates as static and stale (regardless of whether or not the
information contained within the certificate has yet become stale).

One point in using the characteristics static and stale to describe the
certificate paradigm .... is to highlight that certificates are in effect,
r/o cached entries of some other information. It makes a distinction
between the information that might be contained in a certificate from the
certificate paradigm itself. There has been a lot of work on the basic
nature of cached information ... which i believe is applicable to the
certificate paradigm. That work is totally orthogonal to the nature of the
information itself (that might be contained in a certificate).

[email-masked] wrote:

Well, my opinion is that you won't have much luck dealing with "Identity
issues" until you have a good definition of "identity".

Here's my shot at it.  If you start from the premise that identity is
just a set of attributes, then your identity is those attributes that
are constant and last forever.

So, my "Identity certificate" asserts an association between me and
the University of Wisconsin.  Is that part of my identity?  It depends
on how you interpret that assertion.  If you interpret it as "was at
one time affiliated with that university", then that lasts forever and
it is (Winston Smith to the contrary).  If you interpret it as "is
currently affiliated...", then it isn't.

The only observation I can make right now is that with the former
interpretation, Lynn Wheeler doesn't get to use the adjectives "stale"
and "static".  Whether that's any more useful than counting angels
dancing on pinheads remains to be seen, I suppose.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Subject: Re: PKI International Consortium
To: "todd glassey" <[email-masked]>
Cc: "Arshad Noor" <[email-masked]>, "PKIX list" <[email-masked]>, [email-masked]
From: [email-masked]
Date: Sun, 4 Apr 2004 20:28:38 -0600
Sender: [email-masked]

the EU directive just said something about being as anonymous as cash ....
in general the privacy mandates signficantly reduce the run of the mill
phishing .... it is somewhat like cryptography .... some cryptography is
secure for all but the most determined government operations.

it is possible to make account number electronic financial transactions
like x9.59
http://www.garlic.com/~lynn/index.html#x959
 .... authenticated but not identified.

In that sense they become pretty agnostic with respect to identification.
Governments are able to mandate "know your customer" rules for the accounts
... which given the appropriate government action can extract all sorts of
details. However, it doesn't preclude other governments allowing purely
anonymous accounts.

[email-masked] wrote:

Lynn - good commentary - but I also want to add that cash transactions are
not anonymous in that they leave finger prints and they survived this
"reduction in their anonymity" after the adoption of fingerprinting by law
enforcement... i.e.  Someone handles the money and there is all kind of
tangible evidence left, the issue is the cost of collecting and maintaining
it.

Todd

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

From: "Al Arsenault" <[email-masked]>
To: "Eric Norman" <[email-masked]>, "PKIX list" <[email-masked]>
Subject: RE: Identity (was PKI International Consortium)
Date: Sun, 4 Apr 2004 21:19:23 -0400
Importance: Normal
Sender: [email-masked]

> 
> On Sun, 4 Apr 2004 [email-masked] wrote:
> 
> > So, again, in the design of Identity Certificates we should 
> concentrate on
> > Identity issues, and on the needs of systems requiring 
> identification. Trying
> > to use Identity Certificates for other uses is wrong.
> 
> Well, my opinion is that you won't have much luck dealing with "Identity
> issues" until you have a good definition of "identity".
> 
> Here's my shot at it.  If you start from the premise that identity is
> just a set of attributes, then your identity is those attributes that
> are constant and last forever.

AWA:  "reasonably forever". :-) There aren't any attributes guaranteed to last forever.  People change their names, for reasons of marriage, divorce, or because they just want to.  Affiliations - employers, university attended, etc. - change when circumstances change. 

> 
> So, my "Identity certificate" asserts an association between me and
> the University of Wisconsin.  Is that part of my identity?  It depends
> on how you interpret that assertion.  If you interpret it as "was at
> one time affiliated with that university", then that lasts forever and
> it is (Winston Smith to the contrary).  If you interpret it as "is
> currently affiliated...", then it isn't.
> 
> The only observation I can make right now is that with the former
> interpretation, Lynn Wheeler doesn't get to use the adjectives "stale"
> and "static".  Whether that's any more useful than counting angels
> dancing on pinheads remains to be seen, I suppose.
> 
>

AWA:  I tend to agree with this.
 
> Eric Norman
> 
> 	"Congress shall make no law restricting the size of integers
> 	that may be multiplied together, or the number of times that
> 	an integer may be multiplied by itself, or the modulus by
> 	which an integer may be reduced".

		Al Arsenault
		BBN Technologies 

	(should I add "no longer a Verizon company"?  :-)

From: "Al Arsenault" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, "PKIX list" <[email-masked]>, <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Arshad Noor" <[email-masked]>, <[email-masked]>, "Terwilliger, Ann" <[email-masked]>, "Eric Norman" <[email-masked]>
Subject: RE: Single Identity. Was: PKI International Consortium
Date: Sun, 4 Apr 2004 21:15:18 -0400
Importance: Normal
Sender: [email-masked]

A few comments in-line, prefaced by my initials, "AWA".

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Anders Rundgren
> Sent: Sunday, April 04, 2004 10:38 AM
> To: PKIX list; [email-masked]
> Cc: Stephen Kent; Arshad Noor; [email-masked]; Terwilliger, Ann; Eric
> Norman
> Subject: Single Identity. Was: PKI International Consortium
> 
> 
> 
> Dear PKIers,
> I could not resist this one as I have worked with this idea since
> 1997....
> 
> The quest for a single identity
> ---------------------------------
> Assume that an international consortium of banks indeed agreed
> on a common certificate issuance policy of a relatively high level
> (as well as shelving the four-corner model), I believe you would
> have a very good foundation for a universal single-identity scheme.
> It is worth noting that a single identity is a reality in Sweden since
> around 1960 so this is a time-proven scheme as well.

AWA:  This really seems to be a function of national culture.  In some places - Sweden and other countries among them - a "single identity" is accepted as part of life.  In other cultures, it's not only not accepted, but the entire idea is abhorrent.  This is actually a good thing, to me:  the world is different; let different people/cultures live by their own rules rather than trying to force them all into one thing.

> 
> A tricky real-life use-case
> -----------------------------
> Now assume that you one day lose your wallet [1] with ID-
> certificates when you are on an oversea trip.  Who will have
> the swift and secure way back?  The individual with a handful
> of locally issued credentials, or the individual who have a
> single credential issued by a member of a trusted network of
> international issuers having branch offices in every town of
> any size worth mentioning?
>

AWA:  Speaking from practical experience (having a physical wallet lifted in Prague a few years back), it was easier NOT having a single credential.  Okay, the wallet with the cash, credit cards, US driver's license, pictures of the kids, medical insurance card, etc. is gone.  But, NOT the passport, and not the emergency credit card kept separate from the rest for exactly this eventuality.  Survival was assured until recovery could be accomplished.

AWA:  Now, map this to the virtual world, where everything is stored in your mobile phone.  Whoops - mobile phone is lost/stolen.  So I go to the nearest branch of the "issuing agency".  The conversation goes something like Me: "excuse me, my name is Al Arsenault, and my ID was stolen.  I need a new one".   Agency:  "Prove that's who you are".  Me:  "How?  My one single ID was stolen, I need a new one".  Agency: "Yes, but if we believed you based on just what you're telling us, it could deny service to the REAL Al Arsenault, who our records show is out blithely spending money right now". (Somebody call John Cleese - there's a great Monty Python skit in here somewhere.)

AWA:  Yes, there's likely a way to PROVE that I'm the real Al Arsenault, but I hope it doesn't involve biometrics - don't get me started down that road. :-(

> Most security folks only look to revocation issues but it is
> really at least as critical to get replacement credentials as you 
> in an anticipated "e-society" will be completely handicapped
> without getting access to your work, bank, e-government etc.

AWA:  Yes, absolutely.  

> 
> TTPs rule - Like it or not
> -----------------------------
> Some people object to the TTP idea but the reality is that
> all issuances not based on DNA or similar "body-based-
> authentication", already fully depend on TTP-issued
> passports, driver licenses, gas bills (!) etc.
>

AWA:  I disagree.  These are generally Second-Party (not third) for their primary purposes. Examples:

	- Governments issue passports.  They're used to identify you to other Governments (and your own). Second party issuance.  Yes, it's true that passports are sometimes used in other circumstances, but that's not their primary reason for being.
	- Driver's licenses are issued, in the US, by state Motor Vehicle Agencies (the names vary, but the principle's the same).  They're meant to show that you are allowed to drive under some conditions (e.g., must wear glasses/contact lenses; under-age so cannot drive alone at night; can operate a motorcycle; can operate a commercial truck/bus; etc.)  Second party issuance.  Yes, these get used a lot for purposes other than showing that you can legally operate a motor vehicle just because it's so darned easy, but that's not the purpose for which they were created.
	- Gas bills are generated and managed by the utility company.  They don't want to know or care about my driver's license or whether I have a passport; they care about my address and payment history.  

Yes, it's true that in many cases, the second parties who issue these IDs outsource some of their IT infrastructure, so there are some "third parties" involved. But the bottom line is that the US Department of State doesn't go to VeriSign or anybody else to issue you a passport.  They do it by themselves or with the aid of selected Registration Agents like the US Postal Sservice.

> So you really need multiple identities?
> -------------------------------------------
> The need for multiple identity when you interact with your own
> trusted providers including your employers, banks, or emerging
> e-government services seems hard to justify (unless for potential
> cost issues with respect to the issuer).
> 

AWA: The issue is part cultural, part cost.  

	My employer knows me as an employee.  I have an employee number,  which is NOT the same as my tax id, my social security number, my passport number, or any of my credit card or bank account numbers.  BBN uses to reference all of my employment records since I started working here.  That's it.  There's no reason for them to know or care about any other number (except the tax/social security stuff, since they have to get the taxes right.  But that's handled with a mapping.)
	Suppose I have relationships with several banks (not uncommon in the US).  Bank 1 knows me as its account_1.  Bank_2 knows me as its account_2.  There's no reason these have to be synchronized; why force the two banks to combine/merge/whatever their account records? It would be a cost, with no benefit. And, it's just not necessary.  There's no real reason why Bank 1 and Bank 2 need to know me by a common identifier.  If I want them to be able to do things for me, like electronically transfer funds from one to the other, I'll provide them with the mapping.  If I don't, I won't and they're happier not knowing about each other. 
	Now, of course, it's likely that many places with whom I interact financially do know me by a common identifier - the US Social Security Number.  (Not all of them know it, but the employers and banks certainly do.)  They COULD if they want combine around that as a common identifier, but culturally, at least in the US, that's seen as a really bad idea. It lets too much information about you be aggregated, and is considered to be a major privacy problem.  Other societies have similar views; e.g., the Hong Kong ID used by all legal residents of the HKSAR is considered to be private information and its unauthorized disclosure is generally a violation of laws.
	In societies where this cultural view is not held - e.g., in Sweden according to Anders - then it's quite likely that many of my arguments do not hold. Fine - different places are different.
	
> When you OTOH interact with non-trusted providers or
> providers where your identity as an individual is of secondary
> importance or even is important to protect, SAML, 3D Secure,
> etc. offer a great way of leveraging a single identity.  That is,
> these schemes allow you to be a VISA card, B2B purchaser,
> etc. without having to have such resources issued to you to
> be carried around, as they exploit the on-line paradigm [2].
> 
> The only real problem
> -------------------------
> The only real problem stopping this vision is that banks are
> slove movers, cooperate poorly, and do not participate in
> the development of open standards, and may therefore miss
> this golden opportunity.  It is really about acknowledging
> that an identity business potentially targeting the entire
> "e-society" is very different to running payment networks,
> as only e-the former reach into the hart of relying parties'
> IT-systems. 
> 

AWA:  No,  the real "problem" is that many cultures in the world think having a single identifier for all purposes is a really bad idea.  That's certainly what my opinion is.  I recognize that others disagree, but.. 

> Regards
> Anders Rundgren
> Consultant, e-infrastructure
> + 46 70 - 627 74 37
> 
> 1] The "wallet" is likely to be our mobile phones as this
> device is developing at record speed, is replaced every 18
> months (ave.), and is already most people's favorite IT-toy.
> The local wireless connectivity today shipping in about 25%
> of all PCs is an excellent replacement for card readers.
> 
> 2] A couple of papers showing how on-line changes everything:
> http://www.x-obi.com/OBI400/pki4org.pdf
> http://w1.181.telia.com/~u18116613/CAeXtraInfo.pdf
> 
>
>

		Al Arsenault
		BBN Technologies 

Date: Sun, 4 Apr 2004 19:50:34 -0500 (CDT)
From: Eric Norman <[email-masked]>
To: PKIX list <[email-masked]>
Subject: Identity (was PKI International Consortium)
Sender: [email-masked]

On Sun, 4 Apr 2004 [email-masked] wrote:

> So, again, in the design of Identity Certificates we should concentrate on
> Identity issues, and on the needs of systems requiring identification. Trying
> to use Identity Certificates for other uses is wrong.

Well, my opinion is that you won't have much luck dealing with "Identity
issues" until you have a good definition of "identity".

Here's my shot at it.  If you start from the premise that identity is
just a set of attributes, then your identity is those attributes that
are constant and last forever.

So, my "Identity certificate" asserts an association between me and
the University of Wisconsin.  Is that part of my identity?  It depends
on how you interpret that assertion.  If you interpret it as "was at
one time affiliated with that university", then that lasts forever and
it is (Winston Smith to the contrary).  If you interpret it as "is
currently affiliated...", then it isn't.

The only observation I can make right now is that with the former
interpretation, Lynn Wheeler doesn't get to use the adjectives "stale"
and "static".  Whether that's any more useful than counting angels
dancing on pinheads remains to be seen, I suppose.

Eric Norman

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

From: "todd glassey" <[email-masked]>
To: "Arshad Noor" <[email-masked]>, <[email-masked]>
Cc: "PKIX list" <[email-masked]>, <[email-masked]>
Subject: Re: PKI International Consortium
Date: Sun, 4 Apr 2004 15:02:28 -0700
Sender: [email-masked]

Lynn - good commentary - but I also want to add that cash transactions are
not anonymous in that they leave finger prints and they survived this
"reduction in their anonymity" after the adoption of fingerprinting by law
enforcement... i.e.  Someone handles the money and there is all kind of
tangible evidence left, the issue is the cost of collecting and maintaining
it.

Todd

----- Original Message ----- 
From: <[email-masked]>
To: "Arshad Noor" <[email-masked]>
Cc: "PKIX list" <[email-masked]>; <[email-masked]>
Sent: Saturday, April 03, 2004 8:21 AM
Subject: Re: PKI International Consortium

>
>
>
>
>
> An example with slight variation on this was some EU directive that
> electronic payments at point-of-sale should be as anonymous as cash, aka
it
> should be possible to authenticate a transaction for authorization w/o
> requiring any identification what-so-ever.
>
> The issue is that if you have some sort of authentication, aka "something
> you have", "something you know", "something you are" .... and possibly
> non-shared-secret based ... it is possible to have an authorization
context
> that just does authentication and no identification is involved.
>
> it that case, if there is an authorization context ... with some recorded
> authentication mechanism ... then the authentication is bound to the
> authorization context and there is no identification at all.
>
> in such a taxonomy .... a certificate represents a static, stale,
> authorization context for offline environments ... where the public key is
> the authentication mechanism bound to the authorization context. The
> authentication mechanism is some form of "something you have" .... based
on
> uniquely having a private key that generates a digital signature that can
> authenticated with the public key. This is basically the scenario for the
> relying-party-only certificates from the mid-90s (somewhat resulting from
> retrentching from the horrible privacy issues of full blown x.509 identity
> certificates). Note, however, it isn't the certificate that creates the
> "something you have" associated with the private key, the certificate
> provides the portable, stale, static authorization context for offline
> environments. It is equally possible to have an online environment where
> the public key is bound to an online authorization mechanism and no
> certificates are involved at all.  The online payment point-of-sale
> transactions with relying-party-only certificates exemplified redundant
and
> superfluous. The transaction was valuable enough that timely and
aggregated
> online information was deemed justified (the benefit of having an online,
> timely transaction more than offset the incremental cost of having an
> online transaction)  .... but a relying-party-only certificate was
provided
> such that their could be an offline authorization context .... but that
was
> then made redundant and superfluous by having the transaction executed
> online with an online authorization context.
>
> The example I've used for identity is the problems with issuing SSL server
> domain certificates. The authoritative agency for domain names is the
> domain name infrastructure. The typical process for obtaining an SSL
server
> domain certificate is to provide very strong identification information to
> the SSL certificate issuer. The issue is that the domain name
> infrastructure has some identification information registered for the
owner
> of the domain name. The challenge for the SSL certificate issuer is to be
> able to perform some level of identification matching from what is
provided
> by the certificate applicant with the identification that is on file for
> the domain name owner. The reason for the identification operation is that
> there is no industry-specific authentication.  This turns out to be
> expensive and somewhat error prone.  A suggestion, somewhat from the
> certificate industry is that a public key is registered with the domain
> name infrastructure when the domain name is registered. Then when somebody
> applies for a certificate, they digitally sign the operation. The
> certificate issuer then just needs an online authentication of the digital
> signature with what is on file with the domain name infrastructure and a
> very expensive and error-prone identification process is turned into a
much
> simpler industry-specific authentication operation. There is an implied
> authorization that the owner of the domain name is allowed to obtain an
SSL
> domain certificate for that domain name. Of course, there is possibly a
> slight Catch-22 for the SSL certificate industry ... that if the
> certificate industry can make use of online public keys from the domain
> name infrastructure .... that possibly the rest of the world could also
...
> leading to possibly eliminating the need for SSL domain name certificates
> with stale, static certificates binding public keys to domain names.
>
>
> [email-masked] on 4/2/2004 8:49 pm wrote:
>
> I am in complete agreement with you, Lynn.  An industry-specifc
> identity should be designed to perform only a single function -
> authenticate the holder of the credential.  Authorization must
> ALWAYS be determined by the context that has successfully
> authenticated the entity - and those authorization rules must
> always be owned and controlled by the context owner.
>
> --
> Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
>
>

Date: Sun, 04 Apr 2004 21:56:03 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Re-certification
Sender: [email-masked]

Peter Gutmann wrote:

>"Rodrigo Botafogo" <[email-masked]> writes:
>  
>
>>What the Certificate Authority did was:
>>-          Generated a new key pair;
>>-          Created a new certificate with: i) the same DN as the
>>expiring CA, ii) the new key and iii) an extended expiration date
>>    
>>
>That's exactly what Verisign did when their root certs expired,
>
AFAIK I have never seen Verisign *change* the key pair of an authority.
They always extend validity, while keeping the same key pair.

About  Rorigo's question :
It's perfectly legal  to do that, if you don't reuse the same serial 
number for the old CA and the new CA cert.

The RFC proper way to do it is described in paragraph  2.4 of rfc2510.

You might find interesting to read the following document :
http://www.wide.ad.jp/wg/moca/CAkeychangeover.txt
that describes that the rfc recommended way of doing it doesn't work 
very well in real life.

Subject: Re: PKI International Consortium
To: [email-masked]
Cc: [email-masked], PKIX list <[email-masked]>, [email-masked]
From: [email-masked]
Date: Sun, 4 Apr 2004 10:24:08 -0600
Sender: [email-masked]

The use of relying-party-only certificates were done in large part because
of privacy issues ... which could be

* personal privacy issues with identity information
* personal privacy issues with personal attributes
* institutional sensitivity/privacy issues with institutional attributes

However, for a  relying party that used an index/account number from a
relying-party-only certificate to index an entity entry in a repository or
access an online service, it can be shown that the stale, static
replying-party-only certificate is redundant and superfluous. The issue is
that the relying party is retrieving attributes and/or authorization from
the online service and or an entity entry from their own respository ...
and, in effect, a public key bound to an entity is then just another
personal attribute. A public key personal attribute is safely stored in an
entities entry in a repository just like any other personal attribute, no
matter how many PKI infrastructures wish to infuse public keys with some
sort of mystical properties (alhtough public key can be a non-shared-secret
where so many other attributes take on shared-secret properties).

One scenario is FAST project that was being done by FSTC
http://www.fstc.org/
this basically attempted to leverage the 8583 real-time infrastructures to
provide real-time yes/no answers about things other than authorizing
financial transaction.

For instance, rather than having an attribute certificate with
date-of-birth (which currently represents a identity theft vulnerability)
to establish whether a person is younger/older than 18 .... an entity would
sign a age level question, much in the same way they might sign a x9.59
financial transaction. This is then sent off to the financial institution,
which decodes it and replies yes/no to the relying party. The FI maintains
a repository entry for the entity ... including things like timely,
sensitive and/or aggregated information. The FI can answerr questions about
younger/older than 18 (w/o having to reveal date-of-birth) or answer yes/no
to a financial transaction w/o having to reveal credit limit or current
balance.

The current issue is that things like identity theft vulnerabilities aren't
limited to just identity, but can include other personal attributes as
well; in fact probably includes attribute that may potentially be used in
part of a shared-secret paradigm. Also sensitivity of attributes may not be
just be limited to personal attributes, but may also include institutional
sensitivity regarding institutional attributes.

[email-masked] wrote:

Hi,

> If a relying party needs to know that I possess certain attributes, and
> if I can present an "Attribute Certificate" that convinces them that I
> do indeed possess those attributes, then what purpose is served by also
> having me present an "Identity Certificate"?

You are completely right, Eric. There are many situations that require
the knowledge of certain attributes but do not require knowledge of
identity.
For instance, accesing the Playboy should require knowledge of the user
being
over 18, but no identity information should be revealed.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

From: "Anders Rundgren" <[email-masked]>
To: "PKIX list" <[email-masked]>, <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Arshad Noor" <[email-masked]>, <[email-masked]>, "Terwilliger, Ann" <[email-masked]>, "Eric Norman" <[email-masked]>
Subject: Single Identity. Was: PKI International Consortium
Date: Sun, 4 Apr 2004 16:37:51 +0200
Sender: [email-masked]

Dear PKIers,
I could not resist this one as I have worked with this idea since
1997....

The quest for a single identity
---------------------------------
Assume that an international consortium of banks indeed agreed
on a common certificate issuance policy of a relatively high level
(as well as shelving the four-corner model), I believe you would
have a very good foundation for a universal single-identity scheme.
It is worth noting that a single identity is a reality in Sweden since
around 1960 so this is a time-proven scheme as well.

A tricky real-life use-case
-----------------------------
Now assume that you one day lose your wallet [1] with ID-
certificates when you are on an oversea trip.  Who will have
the swift and secure way back?  The individual with a handful
of locally issued credentials, or the individual who have a
single credential issued by a member of a trusted network of
international issuers having branch offices in every town of
any size worth mentioning?

Most security folks only look to revocation issues but it is
really at least as critical to get replacement credentials as you 
in an anticipated "e-society" will be completely handicapped
without getting access to your work, bank, e-government etc.

TTPs rule - Like it or not
-----------------------------
Some people object to the TTP idea but the reality is that
all issuances not based on DNA or similar "body-based-
authentication", already fully depend on TTP-issued
passports, driver licenses, gas bills (!) etc.

So you really need multiple identities?
-------------------------------------------
The need for multiple identity when you interact with your own
trusted providers including your employers, banks, or emerging
e-government services seems hard to justify (unless for potential
cost issues with respect to the issuer).

When you OTOH interact with non-trusted providers or
providers where your identity as an individual is of secondary
importance or even is important to protect, SAML, 3D Secure,
etc. offer a great way of leveraging a single identity.  That is,
these schemes allow you to be a VISA card, B2B purchaser,
etc. without having to have such resources issued to you to
be carried around, as they exploit the on-line paradigm [2].

The only real problem
-------------------------
The only real problem stopping this vision is that banks are
slove movers, cooperate poorly, and do not participate in
the development of open standards, and may therefore miss
this golden opportunity.  It is really about acknowledging
that an identity business potentially targeting the entire
"e-society" is very different to running payment networks,
as only e-the former reach into the hart of relying parties'
IT-systems. 

Regards
Anders Rundgren
Consultant, e-infrastructure
+ 46 70 - 627 74 37

1] The "wallet" is likely to be our mobile phones as this
device is developing at record speed, is replaced every 18
months (ave.), and is already most people's favorite IT-toy.
The local wireless connectivity today shipping in about 25%
of all PCs is an excellent replacement for card readers.

2] A couple of papers showing how on-line changes everything:
http://www.x-obi.com/OBI400/pki4org.pdf
http://w1.181.telia.com/~u18116613/CAeXtraInfo.pdf

---------------------------------------------------------
---------------------------------------------------------

----- Original Message ----- 
From: <[email-masked]>
To: "PKIX list" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>; "Arshad Noor" <[email-masked]>; "Anders Rundgren" <[email-masked]>
Sent: Saturday, April 03, 2004 00:37
Subject: Re: PKI International Consortium

Hello everyone,

Quote from bbn.com : "In 1968, the Advanced Research Projects Agency (ARPA)
sent out a Request for Quotation (RFQ) to build a network of four Interface
Message Processors (IMPs). Many of the large computer and
telecommunications organizations didn't even respond--they thought it was
impossible. " - http://bbn.com/arpanet/index.html.

If the pioneers believed that "Internet" is impossible, then I dont think
we would enjoy sending these emails today.

Anyway, consider the following:

1. A central authority issues and maintains certificates for the customers
of FI. The central authority prescribes a set of standards and regulations
on creation, issuance and maintenance of the certificate.
2. The FI or independent agents may issue the certificate on behalf of the
central authority. However, the certificate issued to the customer should
not have any direct relation to the FI (Financial Institution).
3. The customer may subscribe for the services of an FI, identifying
himself producing the certificate issued by the central authority.
4. All verification of the certificate should be verified referring to the
central authority.
5. The customer has to produce the certificate to the FI whenever he/she
would like to do a transaction. The FI may check for subscription of the
customer and verify the credentials referring to the central authority.

Of course, the availability, integrity and confidentiality of the system
has to be considered for an ideal process such as above. However, with
right technology and prevention mechanism in place, I believe such a system
may be possible. Think about an "International Passport" with which you can
travel to any country. However, your passport require an entry visa
(subscription)  to the destination country. This way I avoid travelling
with multiple passport (for person with multiple citizenship).

Regards,

Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security

-----------------------------------
This message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for delivery of this message to the intended
recipient(s), you are hereby notified that any dissemination, distribution
or copying of this message is strictly prohibited.  If you have received
this message in error, please immediately notify the sender and delete this
e-mail message from your computer.

                    Arshad Noor                                                                                        
                    <arshad.noor@stron       To:     Stephen Kent <[email-masked]>                                       
                    gauth.com>               cc:     Shaheen Nasirudheen/JPMCHASE@JPMCHASE, PKIX list                  
                                              <[email-masked]>                                                      
                    04/02/2004 04:39         Subject:     Re: PKI International Consortium                             
                    PM                                                                                                 

I would concur with you, Steve, that a single certificate that serves all
purposes, is neither practical nor desirable.  (Although I must confess
to occassionally dreaming of such a utopian environment, sometimes).

However, I believe, it is reasonable - assuming appropriate policy,
process, implementation and most importantly, cooperation - to have
industry-specific identities that may serve us all better.  ("Identity
Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html).

Companies waste far too much time and money today, building
duplicate identity infrastructures - and consequently tying their own
hands with context-sensitive identities - because it appears to be the
path of least resistance to them.  But as the cost of identity theft &
of managing those numerous identity infrastructures surpasses the
perceived savings from using this path of least resistance, companies
will be forced to rethink that strategy.

Arshad Noor
StrongAuth, Inc.

----- Original Message -----
From: Stephen Kent <[email-masked]>
Date: Friday, April 2, 2004 8:47 am
Subject: Re: PKI International Consortium

>
> At 10:57 AM -0500 4/2/04, [email-masked] wrote:
> >Hello everyone,
> >
> >I appreciate your feedback and most of the replies were referring to
> >identrus.com . My basic concern is from a customer's point of
> view. If I
> >have a digital certificate issued by a single authority that is
> considered>trusted internationally by all financial as well as
> other commercial
> >institutions, then I do not require to have a certificate for
> Institution>-1 and another for Institution -2. Do we have
> something in place that takes
> >of this issue. I would be happy to carry and protect that one
> certificate>which is trusted by everyone.
> >
> >Thank you,
> >
> >Shaheen Nasirudheen
> >JPMorgan ACCESS, Portal Security
> >978 805 1815
> >
>
> The notion of the one cert that is good for everything is probably
> never going to be a reality, fortunately. Note there there are no
> physical credentials that have this property. Why would you
> believe
> that digital credentials could overcome the organizational
> obstacles
> that contribute to the existence of context-limited credentials?
> Moreover, consider the awful consequences associated with a
> compromise of the private key associated with such a cert, if it
> existed.
>
> Steve
>
>

To: PKIX list <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Subject: Re: PKI International Consortium
Date: Sun, 4 Apr 2004 13:02:47 MET
Sender: [email-masked]

Hi,

> If a relying party needs to know that I possess certain attributes, and
> if I can present an "Attribute Certificate" that convinces them that I
> do indeed possess those attributes, then what purpose is served by also
> having me present an "Identity Certificate"?

You are completely right, Eric. There are many situations that require
the knowledge of certain attributes but do not require knowledge of identity.
For instance, accesing the Playboy should require knowledge of the user being 
over 18, but no identity information should be revealed. The paragraph about 
X.509 was extracted from a paper on interoperable access control for digital 
libraries [1]. In that paper we defend the idea of using no identity, or at 
least making the authorization usable without identity. This paragraph is also 
extracted from [1]:

"Most of current access control schemes base their authorization approaches on 
locally-issued credentials that are linked to user identities. This type of 
credentials present many drawbacks. Among them we highlight: (a) they are not 
interoperable; (b) credentials for the same attribute are issued many times 
for each user, what introduces management and inconsistency problems; (c) 
credentials are issued by the Digital Library administrator, however, in most 
cases, the administrator does not have enough information or resources to 
establish trustworthy credentials; and (d) they are dependent on user 
identity. In practice, it is frequent that the identity of the user is not 
relevant for the access decision. Sometimes it is even desirable that the 
identity is not considered or revealed. Furthermore, in systems based on 
identity, the lack of a global authentication infrastructure (a global Public 
Key Infrastructure, PKI) forces the use of local authentication schemes. "

So, again, in the design of Identity Certificates we should concentrate on 
Identity issues, and on the needs of systems requiring identification. Trying 
to use Identity Certificates for other uses is wrong.

Antonio Ma�a.

-------
[1] Yag�e, M.I., Ma�a, A., L�pez, J., Pimentel, E., Troya, J.M. A Secure 
Solution for Commercial Digital Libraries. Online Information Review Journal, 
Vol. 27 Issue 3, pp. 147-159, Emerald, June 2003.

> > There are, however, reasons to have more than one identity certificate, but
> > these are related to privacy, anonymity and sometimes legal reasons.
> 
> And I'm considering the possibility that there might be reasons to have
> fewer than one identity certificate.
> 
> 
> Eric Norman
> 
> 	"Congress shall make no law restricting the size of integers
> 	that may be multiplied together, or the number of times that
> 	an integer may be multiplied by itself, or the modulus by
> 	which an integer may be reduced".
> 
> 

------------------------------------------------------
Mensaje enviado desde el Servidor de Correo del
Departamento de Lenguajes y Ciencias de la Computacion
de la Universidad de Malaga
------------------------------------------------------

Date: Sat, 3 Apr 2004 14:35:50 -0600 (CST)
From: Eric Norman <[email-masked]>
To: PKIX list <[email-masked]>
Subject: Re: PKI International Consortium
Sender: [email-masked]

On Sat, 3 Apr 2004 [email-masked] wrote:

> The newest version of X.509 provides a more suitable solution because it
> clearly defines a framework where identity and attribute certificates,
> although related, can be independently managed. That recommendation defines
> new types of authorities, Attribute Authorities (AA), for the assignment of
> privileges. It also defines the Source of Authority (SOA) as the ultimate
> authority to assign a set of privileges. Additionally, it provides a
> foundation to build a Privilege Management Infrastructure (PMI) that contain a
> multiplicity of AAs, SOAs and final users.
>
> So, summarizing, if the idea is to have "context-sensitive identities",
> then "Attribute Certificates" linked to a single "Identity Certificate" are
> the best solution.

If a relying party needs to know that I possess certain attributes, and
if I can present an "Attribute Certificate" that convinces them that I
do indeed possess those attributes, then what purpose is served by also
having me present an "Identity Certificate"?

> There are, however, reasons to have more than one identity certificate, but
> these are related to privacy, anonymity and sometimes legal reasons.

And I'm considering the possibility that there might be reasons to have
fewer than one identity certificate.

Eric Norman

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

Subject: Re: PKI International Consortium
To: Arshad Noor <[email-masked]>
Cc: PKIX list <[email-masked]>, [email-masked]
From: [email-masked]
Date: Sat, 3 Apr 2004 08:21:17 -0700
Sender: [email-masked]

An example with slight variation on this was some EU directive that
electronic payments at point-of-sale should be as anonymous as cash, aka it
should be possible to authenticate a transaction for authorization w/o
requiring any identification what-so-ever.

The issue is that if you have some sort of authentication, aka "something
you have", "something you know", "something you are" .... and possibly
non-shared-secret based ... it is possible to have an authorization context
that just does authentication and no identification is involved.

it that case, if there is an authorization context ... with some recorded
authentication mechanism ... then the authentication is bound to the
authorization context and there is no identification at all.

in such a taxonomy .... a certificate represents a static, stale,
authorization context for offline environments ... where the public key is
the authentication mechanism bound to the authorization context. The
authentication mechanism is some form of "something you have" .... based on
uniquely having a private key that generates a digital signature that can
authenticated with the public key. This is basically the scenario for the
relying-party-only certificates from the mid-90s (somewhat resulting from
retrentching from the horrible privacy issues of full blown x.509 identity
certificates). Note, however, it isn't the certificate that creates the
"something you have" associated with the private key, the certificate
provides the portable, stale, static authorization context for offline
environments. It is equally possible to have an online environment where
the public key is bound to an online authorization mechanism and no
certificates are involved at all.  The online payment point-of-sale
transactions with relying-party-only certificates exemplified redundant and
superfluous. The transaction was valuable enough that timely and aggregated
online information was deemed justified (the benefit of having an online,
timely transaction more than offset the incremental cost of having an
online transaction)  .... but a relying-party-only certificate was provided
such that their could be an offline authorization context .... but that was
then made redundant and superfluous by having the transaction executed
online with an online authorization context.

The example I've used for identity is the problems with issuing SSL server
domain certificates. The authoritative agency for domain names is the
domain name infrastructure. The typical process for obtaining an SSL server
domain certificate is to provide very strong identification information to
the SSL certificate issuer. The issue is that the domain name
infrastructure has some identification information registered for the owner
of the domain name. The challenge for the SSL certificate issuer is to be
able to perform some level of identification matching from what is provided
by the certificate applicant with the identification that is on file for
the domain name owner. The reason for the identification operation is that
there is no industry-specific authentication.  This turns out to be
expensive and somewhat error prone.  A suggestion, somewhat from the
certificate industry is that a public key is registered with the domain
name infrastructure when the domain name is registered. Then when somebody
applies for a certificate, they digitally sign the operation. The
certificate issuer then just needs an online authentication of the digital
signature with what is on file with the domain name infrastructure and a
very expensive and error-prone identification process is turned into a much
simpler industry-specific authentication operation. There is an implied
authorization that the owner of the domain name is allowed to obtain an SSL
domain certificate for that domain name. Of course, there is possibly a
slight Catch-22 for the SSL certificate industry ... that if the
certificate industry can make use of online public keys from the domain
name infrastructure .... that possibly the rest of the world could also ...
leading to possibly eliminating the need for SSL domain name certificates
with stale, static certificates binding public keys to domain names.

[email-masked] on 4/2/2004 8:49 pm wrote:

I am in complete agreement with you, Lynn.  An industry-specifc
identity should be designed to perform only a single function -
authenticate the holder of the credential.  Authorization must
ALWAYS be determined by the context that has successfully
authenticated the entity - and those authorization rules must
always be owned and controlled by the context owner.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

To: Arshad Noor <[email-masked]>, PKIX list <[email-masked]>
From: [email-masked]
Subject: Re: PKI International Consortium
Date: Sat, 3 Apr 2004 12:57:02 MET
Sender: [email-masked]

Hi all,

In line with Arshad's comments, I think there's some kind of misunderstanding 
in this discussion. It seems that we're confusing Identity and Attributes (or 
privileges). It is reasonable to think that one entity (anything that can have 
a certificate) should have only one Identity (and therefore, only one Identity 
Certificate). There are reasons that may justify having more than one 
Identity, and I will come to that later, but let's assume for now that only 
one Identity is enough.

What has been mentioned in this thread is the need to have several (identity) 
certificates for different purposes. Therefore, each of these "identity 
certificates" will be "industry-specific" and will have different associated 
semantics depending on the "industry" or purpose. In this way a "Financial 
identity certificate" would mean "The cert holder has an associated account in 
bank X and blah, blah". On the other hand my university certificate would 
state that I am "professor of the Computer Science Department".  Well, in my 
opinion these are not "identity certificates" but "attribute certificates". 

The newest version of X.509 provides a more suitable solution because it 
clearly defines a framework where identity and attribute certificates, 
although related, can be independently managed. That recommendation defines 
new types of authorities, Attribute Authorities (AA), for the assignment of 
privileges. It also defines the Source of Authority (SOA) as the ultimate 
authority to assign a set of privileges. Additionally, it provides a 
foundation to build a Privilege Management Infrastructure (PMI) that contain a 
multiplicity of AAs, SOAs and final users.

So, summarizing, if the idea is to have "context-sensitive identities", 
then "Attribute Certificates" linked to a single "Identity Certificate" are 
the best solution.

There are, however, reasons to have more than one identity certificate, but 
these are related to privacy, anonymity and sometimes legal reasons.

cheers,
Antonio Ma�a.

-- 
                                                           ___
      /---------------------------------------------------/   |
     /            _   ,                                  / /| |
    /   Dr. Antonio Mana Gomez  eMail: [email-masked]   / / | |
   /                                   [email-masked]   / /  | |
  /             http://www.lcc.uma.es/~amg            / /__ | | __
 /---------------------------------------------------/_//  ||_|/  |
     /  University of Malaga.  Computer Science Dept.  /   |  /   |
    /    E.T.S.I.Informatica.        Desp. 3.2.7      / /| | / /| |
   /               Campus de Teatinos.               / / | |/ / | |
  /               29071 MALAGA (SPAIN)              / /__|   /  | |
 /-------------------------------------------------/_// /|__/   |_|
    /           Phone: (+34) 95 213 71 42            / /  _
   /            Fax: (+34) 95 213 13 97             / /  | |
  /      Alternative  Phone: (+34) 95 213 41 86    / /___| |
 /------------------------------------------------/________|

> 
> I am in complete agreement with you, Lynn.  An industry-specifc
> identity should be designed to perform only a single function -
> authenticate the holder of the credential.  Authorization must
> ALWAYS be determined by the context that has successfully
> authenticated the entity - and those authorization rules must
> always be owned and controlled by the context owner.
> 
> There are some assumptions I make wrt industry-specific identities
> (not exhaustive):
> 
> a) They are used only in an online context; while certificates
>     can be used perfectly well offline too, the RP has greater
>     assurances when used only within online contexts.  Given the
>     nature of the always-online Internet and the services that are
>     being built on top of it, this is not an unreasanable assumption
>     anymore;
> 
> b) The single credential for the individual will suffice regardless
>     of the value of the transaction; this implies that the level of
>     assurance that needs to be built into that credential is high,
>     thereby increasing the initial cost of issuance.  However, since
>     that cost is spread out across an entire industry (hopefully, for
>     a very long duration) the actual cost borne by the industry per
>     credential will be lower than for any individual company within
>     that industry. The advantage for any given company to sign up to
>     this model?  All companies within that industry have the same level
>     of assurance in the credential for any level transaction.  (There
>     are other advantages too).
> 
> c) Since the credential is industry-specific, each industry will come
>     up with its own identifier per entity (besides the unique certificate
>     DN in the credential) that will be completely unrelated to other
>     identifiers in other industries.  This, coupled with more secure
>     practices in systems management, data-management & software
>     development will eliminate the privacy issues.  It will make no
>     difference whether you know my Social Security Number, birthdate
>     or my mother's maiden name, because modified business practices
>     (based on these new credentials) will eliminate the value of this
>     data to identity thieves.  Will other data become just as valuable
>     to the thieves?  Almost certainly, but they're also going to have
>     to steal the physical device that stores my industry-credential
>     along with the PIN that I carry in my head to unlock the device.
>     The risk is never eliminated, but the probability of damage is
>     reduced.
> 
> I do not deny that there are lots of other issues that need to be
> addressed (I'm in the middle of writing a much more comprehensive
> treatise to discuss these), however, given the losses borne by
> consumers (ultimately) - $53B in 2003 according to the FTC
> http://www.ftc.gov/opa/2003/09/idtheft.htm, I believe the issue
> has become costly enough to consider a radical overhaul of America's
> identity infrastructure.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> 
> 
> [email-masked] wrote:
> > 
> > 
> > 
> > it isn't necessarily just authentication that a relying party may have to
> > worry about with regard to the operation that they might be trusting the
> > certificate for .... but also things like authorization. the concept of a
> > certificate is that the relying party can trust the certificate in an
> > offline environment w/o necessarily any recourse to any additional
> > information.
> > 
> > the issue of recourse to additional information may because of things like
> > 
> > 1) privacy .... the early x.509 "identity" certificates were found to
> > represent signficiant privacy compromise, especially when broadcasting all
> > of the place. as a result, there was retrencement to relying-party-only
> > certificates .... where it was sufficient to authenticate the entity as
> > being authorized to perform some set of operations against some account
> > record.
> > 
> > 2) value ... the transaction is of sufficient value and/or complexity that
> > it is worthwhile to perform a online transaction (as opposed to an offline
> > operation purely relying on the contents of a certificate).
> > 
> > Note, however, that majority of relying-party-only certificates were used
> > in operations involving some value and therefor justified an online
> > operation with access to timely and/or aggregated information (aka
> > sufficient funds to actually cover a financial transaction).
> > 
> > 3) authorization ... the issue may not have anything at all to do with your
> > identity, but whether or not you can be authenticated (not identified) as
> > being an authorized employee or an authorized individual to perform
> > transactions against a specific bank account. Just because I can proov I'm
> > John Smith ... isn't sufficient to establish that I'm an authorized
> > employee of any specific corporation and therefor entitled to enter an
> > employee only area.
> > 
> > It isn't context-sensitive identity infrastructure ... they require
> > context-sensitive authorization (although sometimes there is significant
> > confusion and institutions build identity infrastructures that are totally
> > orthogonal to their need for authenticationa nnd authorization
> > infrastructures).
> > 
> > In many of these situations, then stale, static certificates can be totally
> > redundant and superfluous ... either because they are providing information
> > that has no direct bearing on the operation being performed by the relying
> > party and/or because the relying party will be doing an online operation
> > with the authoritative agency providing real-time and/or aggregated
> > information (not possible with a stale, static, offline certificate).
> > 
> > 
> > [email-masked] on 4/2/2004 2:39 pm wrote:
> > 
> > I would concur with you, Steve, that a single certificate that serves all
> > purposes, is neither practical nor desirable.  (Although I must confess
> > to occassionally dreaming of such a utopian environment, sometimes).
> > 
> > However, I believe, it is reasonable - assuming appropriate policy,
> > process, implementation and most importantly, cooperation - to have
> > industry-specific identities that may serve us all better.  ("Identity
> > Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html).
> > 
> > Companies waste far too much time and money today, building
> > duplicate identity infrastructures - and consequently tying their own
> > hands with context-sensitive identities - because it appears to be the
> > path of least resistance to them.  But as the cost of identity theft &
> > of managing those numerous identity infrastructures surpasses the
> > perceived savings from using this path of least resistance, companies
> > will be forced to rethink that strategy.
> > 
> > Arshad Noor
> > StrongAuth, Inc.
> > 
> 
> 

------------------------------------------------------
Mensaje enviado desde el Servidor de Correo del
Departamento de Lenguajes y Ciencias de la Computacion
de la Universidad de Malaga
------------------------------------------------------

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Re-certification
Date: Sat, 03 Apr 2004 16:22:19 +1200
Sender: [email-masked]

"Rodrigo Botafogo" <[email-masked]> writes:

>What the Certificate Authority did was:
>
>-          Generated a new key pair;
>-          Created a new certificate with: i) the same DN as the
>expiring CA, ii) the new key and iii) an extended expiration date

That's exactly what Verisign did when their root certs expired, AFAIK there
were no problems with apps using the certs (provided they got the new certs in
time).  Most CAs that started operating more recently (the Verisign roots are
from 1996) have got around this problem with 10-20 year validity periods, so
that whoever authorised this behaviour will have safely retired or moved on to
another job by the time it becomes a problem.

Peter.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Sat, 3 Apr 2004 00:03:23 -0400
Sender: [email-masked]

Steve:

I do not see a particular reason to require a DPD Server to be held to a 
higher standard then a Directory Server.  We do not require signed responses 
from Directories.  Both being stationary servers, are equally prone to 
hacking.  Also, in order to verify the DPD Server signature, the client may 
get into another problem of obtaining a path for the DPD Server itself, which 
may not be a circular problem, but will degrade performance

> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Friday, April 02, 2004 4:45 PM
> To: Dave Engberg
> Cc: [email-masked]
> Subject: Re: Signing Untrusted SCVP?
> 
> Dave,
> 
> I agree that one might not want to invest as much effort and money in
> securing a DPD server as a DPV server. But that does not necessarily
> translate into removing the need for signatures on responses from 
> such servers. If responses from a DPD server are spoofed, a client 
> may be subject to a form of DoS attack, as it tries to make use of 
> bogus certs formed chains intended to maximize the amount of crypto 
> processing the client does, before realizing that the chain is bad. 
> Or certs might be returned that conflict with certs from some other DPD
> server.  Without signed responses it could be very hard to determine
> what went wrong and what servers ought to be avoided, based on bad
> behavior.
> 
> Steve

Date: Fri, 02 Apr 2004 19:49:49 -0800
From: Arshad Noor <[email-masked]>
Subject: Re: PKI International Consortium
To: PKIX list <[email-masked]>
Organization: StrongAuth, Inc.
Sender: [email-masked]

I am in complete agreement with you, Lynn.  An industry-specifc
identity should be designed to perform only a single function -
authenticate the holder of the credential.  Authorization must
ALWAYS be determined by the context that has successfully
authenticated the entity - and those authorization rules must
always be owned and controlled by the context owner.

There are some assumptions I make wrt industry-specific identities
(not exhaustive):

a) They are used only in an online context; while certificates
    can be used perfectly well offline too, the RP has greater
    assurances when used only within online contexts.  Given the
    nature of the always-online Internet and the services that are
    being built on top of it, this is not an unreasanable assumption
    anymore;

b) The single credential for the individual will suffice regardless
    of the value of the transaction; this implies that the level of
    assurance that needs to be built into that credential is high,
    thereby increasing the initial cost of issuance.  However, since
    that cost is spread out across an entire industry (hopefully, for
    a very long duration) the actual cost borne by the industry per
    credential will be lower than for any individual company within
    that industry. The advantage for any given company to sign up to
    this model?  All companies within that industry have the same level
    of assurance in the credential for any level transaction.  (There
    are other advantages too).

c) Since the credential is industry-specific, each industry will come
    up with its own identifier per entity (besides the unique certificate
    DN in the credential) that will be completely unrelated to other
    identifiers in other industries.  This, coupled with more secure
    practices in systems management, data-management & software
    development will eliminate the privacy issues.  It will make no
    difference whether you know my Social Security Number, birthdate
    or my mother's maiden name, because modified business practices
    (based on these new credentials) will eliminate the value of this
    data to identity thieves.  Will other data become just as valuable
    to the thieves?  Almost certainly, but they're also going to have
    to steal the physical device that stores my industry-credential
    along with the PIN that I carry in my head to unlock the device.
    The risk is never eliminated, but the probability of damage is
    reduced.

I do not deny that there are lots of other issues that need to be
addressed (I'm in the middle of writing a much more comprehensive
treatise to discuss these), however, given the losses borne by
consumers (ultimately) - $53B in 2003 according to the FTC
http://www.ftc.gov/opa/2003/09/idtheft.htm, I believe the issue
has become costly enough to consider a radical overhaul of America's
identity infrastructure.

Arshad Noor
StrongAuth, Inc.

[email-masked] wrote:
> 
> 
> 
> it isn't necessarily just authentication that a relying party may have to
> worry about with regard to the operation that they might be trusting the
> certificate for .... but also things like authorization. the concept of a
> certificate is that the relying party can trust the certificate in an
> offline environment w/o necessarily any recourse to any additional
> information.
> 
> the issue of recourse to additional information may because of things like
> 
> 1) privacy .... the early x.509 "identity" certificates were found to
> represent signficiant privacy compromise, especially when broadcasting all
> of the place. as a result, there was retrencement to relying-party-only
> certificates .... where it was sufficient to authenticate the entity as
> being authorized to perform some set of operations against some account
> record.
> 
> 2) value ... the transaction is of sufficient value and/or complexity that
> it is worthwhile to perform a online transaction (as opposed to an offline
> operation purely relying on the contents of a certificate).
> 
> Note, however, that majority of relying-party-only certificates were used
> in operations involving some value and therefor justified an online
> operation with access to timely and/or aggregated information (aka
> sufficient funds to actually cover a financial transaction).
> 
> 3) authorization ... the issue may not have anything at all to do with your
> identity, but whether or not you can be authenticated (not identified) as
> being an authorized employee or an authorized individual to perform
> transactions against a specific bank account. Just because I can proov I'm
> John Smith ... isn't sufficient to establish that I'm an authorized
> employee of any specific corporation and therefor entitled to enter an
> employee only area.
> 
> It isn't context-sensitive identity infrastructure ... they require
> context-sensitive authorization (although sometimes there is significant
> confusion and institutions build identity infrastructures that are totally
> orthogonal to their need for authenticationa nnd authorization
> infrastructures).
> 
> In many of these situations, then stale, static certificates can be totally
> redundant and superfluous ... either because they are providing information
> that has no direct bearing on the operation being performed by the relying
> party and/or because the relying party will be doing an online operation
> with the authoritative agency providing real-time and/or aggregated
> information (not possible with a stale, static, offline certificate).
> 
> 
> [email-masked] on 4/2/2004 2:39 pm wrote:
> 
> I would concur with you, Steve, that a single certificate that serves all
> purposes, is neither practical nor desirable.  (Although I must confess
> to occassionally dreaming of such a utopian environment, sometimes).
> 
> However, I believe, it is reasonable - assuming appropriate policy,
> process, implementation and most importantly, cooperation - to have
> industry-specific identities that may serve us all better.  ("Identity
> Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html).
> 
> Companies waste far too much time and money today, building
> duplicate identity infrastructures - and consequently tying their own
> hands with context-sensitive identities - because it appears to be the
> path of least resistance to them.  But as the cost of identity theft &
> of managing those numerous identity infrastructures surpasses the
> perceived savings from using this path of least resistance, companies
> will be forced to rethink that strategy.
> 
> Arshad Noor
> StrongAuth, Inc.
> 

Subject: Re: PKI International Consortium
To: [email-masked]
Cc: "Anders Rundgren" <[email-masked]>, Arshad Noor <[email-masked]>, PKIX list <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked]
From: [email-masked]
Date: Fri, 2 Apr 2004 17:11:46 -0700
Sender: [email-masked]

The arpanet was a traditional, homogeneous network ... that happen to be a
packet-switch implementation rather than circuit-switch implementation.
Note however, it was NOT an internet. It corresponded much closer to the
standard OSI model of homogeneous infrastructure (but having a packet
orientation rather than a circuit orientation).

I've claimed that one of the reasons that the internal network was larger
than the arpaent for all of that period ... was that the internal network
had effectively the equivalent of a gateway built into every node ...
allowing support for heterogenous networking. The great switch-over from
arpanet to internet occured on 1/1/83 ... with the introduction of
internetworking .... a "layer" that doesn't even exist in the OSI model
(sitting somewhere between layer3/networking and layer4/transport). At that
time of the switchover the arpanet was around 250 nodes and the internal
network was nearly 1000 nodes. The combination of internetworking,
heterogeneous networking support, gateways, and the appearance of PCs and
workstations as internet network nodes resulted in the internet eventually
exceeding the number of nodes on the internal network sometime around
mid-85.

misc. past posts related to arpanet, csnet, nsfnet, internet, internet
switch-over and the internal network:
http://www.garlic.com/~lynn/internet.net

a story not related in the above was some corporate type doing technology
audit in the late 70s and being told about the size of the internal
network. the person supposedly wrote a report stating that it was
impossible ... because to build a network of that size using traditional
homogeneous networking technology (common at the time) would have required
more people total than had been working for the corporation over the
previous ten years.

misc. past posts related to OSI, arpanet, iso, etc:
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
the above mentions another issue w/OSI. attempting to get HSP (high-speed
protocol) work item in X3S3.3 (iso chartered us standards organization
responsible for networking and transport layer standards). The problem was
that ISO had a rule that there couldn't be standards work on protocols in
this area that violated OSI. HSP was going to go directly from
level4/transport to the MAC interface. This violated OSI in two respects 1)
it bypassed the level3/level4 interface and 2) it interfaced to MAC layer.
LANs/WANs/MAC are a violation of OSI with the MAC layer sitting somewhere
in the middle of layer3/networking. Because of the OSI violation rule,
X3S3.3 rejected the work item.

in late '69, i did get involved in a project as an undergraduate building a
telecommunication controller using an Interdata/3. this resulted in later
getting blaimed for helping create the plug-compatible manufactoring (PCM)
controller business:
http://www.garlic.com/~lynn/subtopic.html#360pcm

[email-masked] on 4/2/2004 3:37 pm wrote:

Hello everyone,

Quote from bbn.com : "In 1968, the Advanced Research Projects Agency (ARPA)
sent out a Request for Quotation (RFQ) to build a network of four Interface
Message Processors (IMPs). Many of the large computer and
telecommunications organizations didn't even respond--they thought it was
impossible. " - http://bbn.com/arpanet/index.html.

If the pioneers believed that "Internet" is impossible, then I dont think
we would enjoy sending these emails today.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Subject: Re: PKI International Consortium
To: Arshad Noor <[email-masked]>
Cc: PKIX list <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked], [email-masked]
From: [email-masked]
Date: Fri, 2 Apr 2004 16:46:04 -0700
Sender: [email-masked]

it isn't necessarily just authentication that a relying party may have to
worry about with regard to the operation that they might be trusting the
certificate for .... but also things like authorization. the concept of a
certificate is that the relying party can trust the certificate in an
offline environment w/o necessarily any recourse to any additional
information.

the issue of recourse to additional information may because of things like

1) privacy .... the early x.509 "identity" certificates were found to
represent signficiant privacy compromise, especially when broadcasting all
of the place. as a result, there was retrencement to relying-party-only
certificates .... where it was sufficient to authenticate the entity as
being authorized to perform some set of operations against some account
record.

2) value ... the transaction is of sufficient value and/or complexity that
it is worthwhile to perform a online transaction (as opposed to an offline
operation purely relying on the contents of a certificate).

Note, however, that majority of relying-party-only certificates were used
in operations involving some value and therefor justified an online
operation with access to timely and/or aggregated information (aka
sufficient funds to actually cover a financial transaction).

3) authorization ... the issue may not have anything at all to do with your
identity, but whether or not you can be authenticated (not identified) as
being an authorized employee or an authorized individual to perform
transactions against a specific bank account. Just because I can proov I'm
John Smith ... isn't sufficient to establish that I'm an authorized
employee of any specific corporation and therefor entitled to enter an
employee only area.

It isn't context-sensitive identity infrastructure ... they require
context-sensitive authorization (although sometimes there is significant
confusion and institutions build identity infrastructures that are totally
orthogonal to their need for authenticationa nnd authorization
infrastructures).

In many of these situations, then stale, static certificates can be totally
redundant and superfluous ... either because they are providing information
that has no direct bearing on the operation being performed by the relying
party and/or because the relying party will be doing an online operation
with the authoritative agency providing real-time and/or aggregated
information (not possible with a stale, static, offline certificate).

[email-masked] on 4/2/2004 2:39 pm wrote:

I would concur with you, Steve, that a single certificate that serves all
purposes, is neither practical nor desirable.  (Although I must confess
to occassionally dreaming of such a utopian environment, sometimes).

However, I believe, it is reasonable - assuming appropriate policy,
process, implementation and most importantly, cooperation - to have
industry-specific identities that may serve us all better.  ("Identity
Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html).

Companies waste far too much time and money today, building
duplicate identity infrastructures - and consequently tying their own
hands with context-sensitive identities - because it appears to be the
path of least resistance to them.  But as the cost of identity theft &
of managing those numerous identity infrastructures surpasses the
perceived savings from using this path of least resistance, companies
will be forced to rethink that strategy.

Arshad Noor
StrongAuth, Inc.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: Re: Re-certification
Date: Fri, 2 Apr 2004 19:29:22 -0400
Sender: [email-masked]

The best thing to do is for the new CA to pick up with the serial number wher 
the old CA left off and for both CAs ti produce the CRL for all certificates 
issued by both.

I do not know if your product will support the capabilities required to do 
that.

On Fri, 2 Apr 2004 18:44:00 -0300, Rodrigo Botafogo wrote
> I'm new to this group, so sorry if I do not follow the groups culture
> somehow.  I have a question regarding re-certification:
>  
> In Brazil, a Certificate Authority had one of its CA expiring.
> According to the Brazilian legislation, a CA cannot re-certify its 
> key, that is, it cannot extend the certificates expiration date for 
> the same key.
>  
> What the Certificate Authority did was:
>  
> -          Generated a new key pair;
> -          Created a new certificate with: i) the same DN as the
> expiring CA, ii) the new key and iii) an extended expiration date
>  
> First of all, is this legal according to X.509? If not, where do we find
> that on the norm?
>  
> If this is legal, how are the CRLs supposed to work in this case.  Note
> what happens:
>  
> 1)       There are two CA with certificates with the same DN.  Lets call
> them OLD and NEW.
> 2)       Lets call the CRLs generated CRLOld and CRLNew
> 3)       When CRLNew is issued, since the DN of OLD and NEW are the
> same, all revoked certificates from OLD and NEW are stored in CRLNew.
> This is the software's behavior.  Question: is this ok according to
> X.509?
> 4)       Lets suppose that CRLOld had the following certificates {1, 
> 3, 5} 5)       Lets suppose that a new cert 8 is revoked.  CRLNew 
> will have {1, 3, 5, 8} 6)       When a third party receives an email 
> signed with Cert 1 what should it do?  It will look at CRLNew, but 
> CRLNew is not signed with the same private key than Cert 1?  
> Question: Should the third party still say that the cert is invalid 
> or should it say that it could not verify the status of the 
> certificate? We made some tests and IE reported that it could not 
> verify the status of the certificate and did not show any warnings,
>  even though the certificate was expired.
>  
> I'd appreciate any help on this.  It seems to me that all that was
> described should not be legal according to X.509, but this is an actual
> case that is happening with the CA in Brazil and I couldn't find in the
> norms where it is said that this is illegal.
>  
> Thanks,
>  
>  
>  
> Rodrigo Botafogo

Subject: Re: PKI International Consortium
To: PKIX list <[email-masked]>
Cc: Stephen Kent <[email-masked]>, Arshad Noor <[email-masked]>, "Anders Rundgren" <[email-masked]>
From: [email-masked]
Date: Fri, 2 Apr 2004 17:37:04 -0500
Sender: [email-masked]

Hello everyone,

Quote from bbn.com : "In 1968, the Advanced Research Projects Agency (ARPA)
sent out a Request for Quotation (RFQ) to build a network of four Interface
Message Processors (IMPs). Many of the large computer and
telecommunications organizations didn't even respond--they thought it was
impossible. " - http://bbn.com/arpanet/index.html.

If the pioneers believed that "Internet" is impossible, then I dont think
we would enjoy sending these emails today.

Anyway, consider the following:

1. A central authority issues and maintains certificates for the customers
of FI. The central authority prescribes a set of standards and regulations
on creation, issuance and maintenance of the certificate.
2. The FI or independent agents may issue the certificate on behalf of the
central authority. However, the certificate issued to the customer should
not have any direct relation to the FI (Financial Institution).
3. The customer may subscribe for the services of an FI, identifying
himself producing the certificate issued by the central authority.
4. All verification of the certificate should be verified referring to the
central authority.
5. The customer has to produce the certificate to the FI whenever he/she
would like to do a transaction. The FI may check for subscription of the
customer and verify the credentials referring to the central authority.

Of course, the availability, integrity and confidentiality of the system
has to be considered for an ideal process such as above. However, with
right technology and prevention mechanism in place, I believe such a system
may be possible. Think about an "International Passport" with which you can
travel to any country. However, your passport require an entry visa
(subscription)  to the destination country. This way I avoid travelling
with multiple passport (for person with multiple citizenship).

Regards,

Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security

-----------------------------------
This message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for delivery of this message to the intended
recipient(s), you are hereby notified that any dissemination, distribution
or copying of this message is strictly prohibited.  If you have received
this message in error, please immediately notify the sender and delete this
e-mail message from your computer.

                    Arshad Noor                                                                                        
                    <arshad.noor@stron       To:     Stephen Kent <[email-masked]>                                       
                    gauth.com>               cc:     Shaheen Nasirudheen/JPMCHASE@JPMCHASE, PKIX list                  
                                              <[email-masked]>                                                      
                    04/02/2004 04:39         Subject:     Re: PKI International Consortium                             
                    PM                                                                                                 

I would concur with you, Steve, that a single certificate that serves all
purposes, is neither practical nor desirable.  (Although I must confess
to occassionally dreaming of such a utopian environment, sometimes).

However, I believe, it is reasonable - assuming appropriate policy,
process, implementation and most importantly, cooperation - to have
industry-specific identities that may serve us all better.  ("Identity
Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html).

Companies waste far too much time and money today, building
duplicate identity infrastructures - and consequently tying their own
hands with context-sensitive identities - because it appears to be the
path of least resistance to them.  But as the cost of identity theft &
of managing those numerous identity infrastructures surpasses the
perceived savings from using this path of least resistance, companies
will be forced to rethink that strategy.

Arshad Noor
StrongAuth, Inc.

----- Original Message -----
From: Stephen Kent <[email-masked]>
Date: Friday, April 2, 2004 8:47 am
Subject: Re: PKI International Consortium

>
> At 10:57 AM -0500 4/2/04, [email-masked] wrote:
> >Hello everyone,
> >
> >I appreciate your feedback and most of the replies were referring to
> >identrus.com . My basic concern is from a customer's point of
> view. If I
> >have a digital certificate issued by a single authority that is
> considered>trusted internationally by all financial as well as
> other commercial
> >institutions, then I do not require to have a certificate for
> Institution>-1 and another for Institution -2. Do we have
> something in place that takes
> >of this issue. I would be happy to carry and protect that one
> certificate>which is trusted by everyone.
> >
> >Thank you,
> >
> >Shaheen Nasirudheen
> >JPMorgan ACCESS, Portal Security
> >978 805 1815
> >
>
> The notion of the one cert that is good for everything is probably
> never going to be a reality, fortunately. Note there there are no
> physical credentials that have this property. Why would you
> believe
> that digital credentials could overcome the organizational
> obstacles
> that contribute to the existence of context-limited credentials?
> Moreover, consider the awful consequences associated with a
> compromise of the private key associated with such a cert, if it
> existed.
>
> Steve
>
>

Date: Fri, 02 Apr 2004 14:26:53 -0800
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

Stephen Kent wrote:
> 
> Ed,
> 
> I really should have asked the context in which you were referring to
> an RP's reliance on revocation status info. 

I welcome this clarification. Saying that the RP "relies" is not enough.
The context of an RP's reliance is what provides the RP's justification 
for reliance. 

It's easy to say that an RP's justification of reliance is a matter of 
need. But this is not quantitative. If we are to make some progress in 
this, we need to define those needs as degrees or levels -- i.e., in terms 
that we can identify their differences and their required revocation models.

For starters, I'd suggest the following reliance levels (from weaker to stronger):

(0) What the RP relies upon without any consideration of "why" and without 
any recourse (open reliance).

(1) What the RP relies upon without any consideration of "why" (actual reliance).

(2) What the RP relies upon because it is presented by a party accepted by the 
truster for that purpose (authorization reliance).

(3) What the RP as a reasonable man might do, with all prudence that might be
reasonable to use (reasonable reliance). In other words, "what would be reasonable
for a prudent man to do under the circumstances".

(4) What can be justified by the RP after an examination of the facts presented
(justified reliance).

As usually defined by a CA's CPS, revocation information provided by a CA is 
level (0). The RP has no contract relationship with the CA and is denied any 
warranties and rights to recourse. The revocation information is provided by 
the CA to an RP "as is". 

Therefore, it does not help much to talk about CRL issue dates and RP reliance
if the RP is stuck in level (0). No matter how frequent we make those CRL
updates (and how much excess traffic we impose on the RP), that's why I
said that the RP is unable to measure with any desired confidence (i.e., 
desired by the RP) whether a cert is revoked or not.

The RP can hope to move to levels (1) and (2) when using a Trusted Responder 
during certificate reliance (i.e., whether the cert has been revoked or not) 
under CRLs or OCSPs. However, as I said before, one cannot rely upon them for 
other than their value as a representation of the issuer CA revocation 
management as expressed in the issuer CA own terms and rules -- which are
in level (0).

Thus, even though a X.509/PKIX cert is either revoked or not (and, yes, 
this is strictly enforceable in X.509/PKIX),  X.509/PKIX is unable to
allow a RP to measure with any desired confidence whether the cert is
in fact revoked or not.

The real problem is to make the cert unusable when revoked.

> If the RP is validating a
> signature for NR purposes, then the RP is nominally protected if he
> waits until the "next" CRL is issued before he acts on the signed
> object. 

The "next" CRL is usually one or two weeks away. Hardly worth waiting
for in an e-commerce transaction -- may as well fly there. And if the 
cycle is shorter, traffic shoots up.

> The CRL issuer is the only game in town re authoritative info
> on the revocation status of a cert. AN RP is, by definition, a
> "relying" party and he relies on the cert and CRL issuer(s) to
> provide this status data when they have said it becomes available. 

A relying party to whom? If in level (0), to himself.

> if
> the RP cannot tolerate the wait, tough luck. 

The wait would be one to two weeks today. And for an information without
any reliance except as an open statement. Tough luck indeed ;-)

> If the RP is using a signature in an access control context, then the
> problem is often different. For access control purposes, one usually
> will not have the luxury of waiting for the next CRL to determine
> revocation status, and even use of OCSP may not help, as many OCSP
> servers are driven by CRLs. But, this is not an X.509 problem per se.
> If the operator of an access control systems wants to ensure that a
> user's privileges are revoked quickly, then the best way to do that
> is to change the ACLs associated with the resources being protected,
> or to push a hot list to each resource access manager. When certs are
> used to verify identity in support of access control, these general
> rules apply, and they are not fundamentally different than if one had
> chosen to use passwords for user authentication.

If X.509 revocation information could be trusted in this context,
access control would not have that security gap.

> >We have struggled with this passage before. Thanks for helping me
> >clarify it now. In short, I mean that revocation by reference (i.e., a
> >X.509 reference that X is revoked) does not revoke anything. Actual
> >revocation, OTOH, would make it impossible to use the cert -- even if
> >a reference about its revocation is not available.
> 
> One cannot, in general, make "it impossible to use the cert" but one
> can make a cert unusable in a given context. But that is not
> surprising. In many systems with capability-like properties,
> revocation effected by seizing an access token is often infeasible.

Seizing the token is not the only way to make the token unusable.

> If I have a keyed padlock on a locker, I can change the lock to
> effect revocation of access privileges for the holders of keys, and
> reissue new keys for the new lock to the folks I want to authorize.
> Do I know that the keys that are out there will not be able to open
> any other padlocks? Not really/ There may have been another padlock
> that would accept the same keys and I don't now, nor can I prevent
> the use of the keys in that padlock.

Even though I usually dislike physical metaphors for crypto locks/keys,
I think that you surely can prevent the keys that are out there to open 
any other padlocks.  It's called key management and is the same with
crypto locks/keys.

> So, I'm afraid I don't find your clarification helpful. Maybe we're
> still just missing a concisely stated context for the comment.

Revoking by reference (the current method with CRLs and OCSPs) has some 
unsolved and unsolvable problems, and does not solve the real problem. 
The real problem is to make the cert unusable when revoked. For that, 
one should also not need to trust user intervention (even to update 
software, as some certs have been revoked).

Cheers,
Ed Gerck

Content-class: urn:content-classes:message
Subject: RE: Signing Untrusted SCVP?
Date: Fri, 2 Apr 2004 17:32:30 -0500
From: "Dave Engberg" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

An attacker with the ability to intercept your SCVP calls and send back
spoofed responses has a more obvious way to deny service ...

More seriously, I think we agree that there should absolutely be an
option in the protocol to allow a client to request a signed response,
and for the server to provide it.  But by making this an absolute hard
requirement for every client-server pair, you are permanently preventing
the SCVP protocol from being used with any caching or pregeneration at
the server level when used for pure DPD, and you're adding 150 bytes and
50 ms onto every response (plus $20k for a FIPS HSM, if you're serious).

Think of pure DPD as an optimized mechanism for doing certificate
lookups, as an alternative to LDAP.  Previously, PKI standards have not
forced every LDAP lookup to use authenticated SSL tunnels, because most
clients derive their security from the signatures on the retrieved
objects rather than the transport mechanism.  The gratuitous requirement
for SSL on every LDAP query would just further reduce performance and
increase costs for PKI deployments.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, April 02, 2004 4:45 PM
To: Dave Engberg
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

Dave,

I agree that one might not want to invest as much effort and money in
securing a DPD server as a DPV server. But that does not necessarily
translate into removing the need for signatures on responses from such
servers. If responses from a DPD server are spoofed, a client may be
subject to a form of DoS attack, as it tries to make use of bogus certs
formed chains intended to maximize the amount of crypto processing the
client does, before realizing that the chain is bad. 
Or certs might be returned that conflict with certs from some other DPD
server.  Without signed responses it could be very hard to determine
what went wrong and what servers ought to be avoided, based on bad
behavior.

Steve

Date: Fri, 02 Apr 2004 14:31:52 -0800
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

Stephen Kent wrote:
> 
> Ed,
> 
> I really should have asked the context in which you were referring to
> an RP's reliance on revocation status info. 

I welcome this clarification. Saying that the RP "relies" is not enough.
The context of an RP's reliance is what provides the RP's justification 
for reliance. 

It's easy to say that an RP's justification of reliance is a matter of 
need. But this is not quantitative. If we are to make some progress in 
this, we need to define those needs as degrees or levels -- i.e., in terms 
that we can identify their differences and their required revocation models.

For starters, I'd suggest the following reliance levels (from weaker to stronger):

(0) What the RP relies upon without any consideration of "why" and without 
any recourse (open reliance).

(1) What the RP relies upon without any consideration of "why" (actual reliance).

(2) What the RP relies upon because it is presented by a party accepted by the 
RP for that purpose (authorization reliance).

(3) What the RP as a reasonable man might do, with all prudence that might be
reasonable to use (reasonable reliance). In other words, "what would be reasonable
for a prudent man to do under the circumstances".

(4) What can be justified by the RP after an examination of the facts presented
(justified reliance).

As usually defined by a CA's CPS, revocation information provided by a CA is 
level (0). The RP has no contract relationship with the CA and is denied any 
warranties and rights to recourse. The revocation information is provided by 
the CA to an RP "as is". 

Therefore, it does not help much to talk about CRL issue dates and RP reliance
if the RP is stuck in level (0). No matter how frequent we make those CRL
updates (and how much excess traffic we impose on the RP), that's why I
said that the RP is unable to measure with any desired confidence (i.e., 
desired by the RP) whether a cert is revoked or not.

The RP can hope to move to levels (1) and (2) when using a Trusted Responder 
during certificate reliance (i.e., whether the cert has been revoked or not) 
under CRLs or OCSPs. However, as I said before, one cannot rely upon them for 
other than their value as a representation of the issuer CA revocation 
management as expressed in the issuer CA own terms and rules -- which are
in level (0).

Thus, even though a X.509/PKIX cert is either revoked or not (and, yes, 
this is strictly enforceable in X.509/PKIX),  X.509/PKIX is unable to
allow a RP to measure with any desired confidence whether the cert is
in fact revoked or not.

> If the RP is validating a
> signature for NR purposes, then the RP is nominally protected if he
> waits until the "next" CRL is issued before he acts on the signed
> object. 

The "next" CRL is usually one or two weeks away. Hardly worth waiting
for in an e-commerce transaction -- may as well fly there. And if the 
cycle is shorter, traffic shoots up.

> The CRL issuer is the only game in town re authoritative info
> on the revocation status of a cert. AN RP is, by definition, a
> "relying" party and he relies on the cert and CRL issuer(s) to
> provide this status data when they have said it becomes available. 

A relying party to whom? If in level (0), to himself.

> if
> the RP cannot tolerate the wait, tough luck. 

The wait would be one to two weeks today. And for an information without
any reliance except as an open statement. Tough luck indeed ;-)

> If the RP is using a signature in an access control context, then the
> problem is often different. For access control purposes, one usually
> will not have the luxury of waiting for the next CRL to determine
> revocation status, and even use of OCSP may not help, as many OCSP
> servers are driven by CRLs. But, this is not an X.509 problem per se.
> If the operator of an access control systems wants to ensure that a
> user's privileges are revoked quickly, then the best way to do that
> is to change the ACLs associated with the resources being protected,
> or to push a hot list to each resource access manager. When certs are
> used to verify identity in support of access control, these general
> rules apply, and they are not fundamentally different than if one had
> chosen to use passwords for user authentication.

If X.509 revocation information could be trusted in this context,
access control would not have that security gap.

> >We have struggled with this passage before. Thanks for helping me
> >clarify it now. In short, I mean that revocation by reference (i.e., a
> >X.509 reference that X is revoked) does not revoke anything. Actual
> >revocation, OTOH, would make it impossible to use the cert -- even if
> >a reference about its revocation is not available.
> 
> One cannot, in general, make "it impossible to use the cert" but one
> can make a cert unusable in a given context. But that is not
> surprising. In many systems with capability-like properties,
> revocation effected by seizing an access token is often infeasible.

Seizing the token is not the only way to make the token unusable.

> If I have a keyed padlock on a locker, I can change the lock to
> effect revocation of access privileges for the holders of keys, and
> reissue new keys for the new lock to the folks I want to authorize.
> Do I know that the keys that are out there will not be able to open
> any other padlocks? Not really/ There may have been another padlock
> that would accept the same keys and I don't now, nor can I prevent
> the use of the keys in that padlock.

Even though I usually dislike physical metaphors for crypto locks/keys,
I think that you surely can prevent the keys that are out there to open 
any other padlocks.  It's called key management and is the same with
crypto locks/keys.

> So, I'm afraid I don't find your clarification helpful. Maybe we're
> still just missing a concisely stated context for the comment.

Revoking by reference (the current method with CRLs and OCSPs) has some 
unsolved and unsolvable problems, and does not solve the real problem. 
The real problem is to make the cert unusable when revoked. For that, 
one should also not need to trust user intervention (even to update 
software, as some certs have been revoked).

Cheers,
Ed Gerck

Date: Fri, 02 Apr 2004 13:39:44 -0800
From: Arshad Noor <[email-masked]>
Subject: Re: PKI International Consortium
To: Stephen Kent <[email-masked]>
Cc: [email-masked], PKIX list <[email-masked]>
Sender: [email-masked]

I would concur with you, Steve, that a single certificate that serves all 
purposes, is neither practical nor desirable.  (Although I must confess
to occassionally dreaming of such a utopian environment, sometimes).

However, I believe, it is reasonable - assuming appropriate policy, 
process, implementation and most importantly, cooperation - to have 
industry-specific identities that may serve us all better.  ("Identity
Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html).

Companies waste far too much time and money today, building 
duplicate identity infrastructures - and consequently tying their own
hands with context-sensitive identities - because it appears to be the
path of least resistance to them.  But as the cost of identity theft &
of managing those numerous identity infrastructures surpasses the 
perceived savings from using this path of least resistance, companies 
will be forced to rethink that strategy.

Arshad Noor
StrongAuth, Inc.

----- Original Message -----
From: Stephen Kent <[email-masked]>
Date: Friday, April 2, 2004 8:47 am
Subject: Re: PKI International Consortium

> 
> At 10:57 AM -0500 4/2/04, [email-masked] wrote:
> >Hello everyone,
> >
> >I appreciate your feedback and most of the replies were referring to
> >identrus.com . My basic concern is from a customer's point of 
> view. If I
> >have a digital certificate issued by a single authority that is 
> considered>trusted internationally by all financial as well as 
> other commercial
> >institutions, then I do not require to have a certificate for 
> Institution>-1 and another for Institution -2. Do we have 
> something in place that takes
> >of this issue. I would be happy to carry and protect that one 
> certificate>which is trusted by everyone.
> >
> >Thank you,
> >
> >Shaheen Nasirudheen
> >JPMorgan ACCESS, Portal Security
> >978 805 1815
> >
> 
> The notion of the one cert that is good for everything is probably 
> never going to be a reality, fortunately. Note there there are no 
> physical credentials that have this property. Why would you 
> believe 
> that digital credentials could overcome the organizational 
> obstacles 
> that contribute to the existence of context-limited credentials? 
> Moreover, consider the awful consequences associated with a 
> compromise of the private key associated with such a cert, if it 
> existed.
> 
> Steve
> 
> 

From: "Rodrigo Botafogo" <[email-masked]>
To: <[email-masked]>
Subject: Re-certification
Date: Fri, 2 Apr 2004 18:44:00 -0300
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_03AD_01C418E2.746F8E40
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_03AE_01C418E2.74729B80"

------=_NextPart_001_03AE_01C418E2.74729B80
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I'm new to this group, so sorry if I do not follow the groups culture
somehow.  I have a question regarding re-certification:
 
In Brazil, a Certificate Authority had one of its CA expiring.
According to the Brazilian legislation, a CA cannot re-certify its key,
that is, it cannot extend the certificates expiration date for the same
key.
 
What the Certificate Authority did was:
 
-          Generated a new key pair;
-          Created a new certificate with: i) the same DN as the
expiring CA, ii) the new key and iii) an extended expiration date
 
First of all, is this legal according to X.509? If not, where do we find
that on the norm?
 
If this is legal, how are the CRLs supposed to work in this case.  Note
what happens:
 
1)       There are two CA with certificates with the same DN.  Lets call
them OLD and NEW.
2)       Lets call the CRLs generated CRLOld and CRLNew
3)       When CRLNew is issued, since the DN of OLD and NEW are the
same, all revoked certificates from OLD and NEW are stored in CRLNew.
This is the software's behavior.  Question: is this ok according to
X.509?
4)       Lets suppose that CRLOld had the following certificates {1, 3,
5}
5)       Lets suppose that a new cert 8 is revoked.  CRLNew will have
{1, 3, 5, 8}
6)       When a third party receives an email signed with Cert 1 what
should it do?  It will look at CRLNew, but CRLNew is not signed with the
same private key than Cert 1?  Question: Should the third party still
say that the cert is invalid or should it say that it could not verify
the status of the certificate? We made some tests and IE reported that
it could not verify the status of the certificate and did not show any
warnings, even though the certificate was expired.
 
I'd appreciate any help on this.  It seems to me that all that was
described should not be legal according to X.509, but this is an actual
case that is happening with the CA in Brazil and I couldn't find in the
norms where it is said that this is illegal.
 
Thanks,

Rodrigo Botafogo

------=_NextPart_001_03AE_01C418E2.74729B80
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:HyphenationZone>21</w:HyphenationZone>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;
	mso-font-charset:2;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:0 268435456 0 0 -2147483648 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EstiloDeEmail17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 3.0cm 70.85pt 3.0cm;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1990010115;
	mso-list-type:hybrid;
	mso-list-template-ids:-2127900860 558148752 68550659 68550661 68550657 =
68550659 68550661 68550657 68550659 68550661;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";}
@list l1
	{mso-list-id:1990404705;
	mso-list-type:hybrid;
	mso-list-template-ids:662842690 68550673 68550681 68550683 68550671 =
68550681 68550683 68550671 68550681 68550683;}
@list l1:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Tabela normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DPT-BR link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:35.4pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial;mso-ansi-language:EN-US'>I&#8217;m new to this =
group,
so sorry if I do not follow the groups culture somehow. <span
style=3D'mso-spacerun:yes'>&nbsp;</span>I have a question regarding =
re-certification:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial;mso-ansi-language:EN-US'>In =
</span></font><st1:country-region><st1:place><font
  size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;
  =
mso-ansi-language:EN-US'>Brazil</span></font></st1:place></st1:country-re=
gion><font
size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;
mso-ansi-language:EN-US'>, a Certificate Authority had one of its CA =
expiring. <span
style=3D'mso-spacerun:yes'>&nbsp;</span>According to the Brazilian =
legislation, a CA
cannot re-certify its key, that is, it cannot extend the certificates
expiration date for the same key.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial;mso-ansi-language:EN-US'>What the Certificate
Authority did was:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1;
tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family:
Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>-<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Gene=
rated
a new key pair;<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1;
tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family:
Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>-<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Crea=
ted
a new certificate with: <span class=3DSpellE>i</span>) the same DN as =
the
expiring CA, ii) the new key and iii) an extended expiration =
date<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial;mso-ansi-language:EN-US'>First of all, is this =
legal
according to X.509? If not, where do we find that on the =
norm?<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial;mso-ansi-language:EN-US'>If this is legal, how =
are the
<span class=3DSpellE>CRLs</span> supposed to work in this case.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Note what =
happens:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2;
tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family:
Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>1)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Ther=
e
are two CA with certificates with the same DN.<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span><span class=3DGramE>Lets</span> call them OLD and =
NEW.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2;
tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family:
Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>2)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Lets=

call the <span class=3DSpellE>CRLs</span> generated <span =
class=3DSpellE>CRLOld</span>
and <span class=3DSpellE>CRLNew</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2;
tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family:
Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>3)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>When=

<span class=3DSpellE>CRLNew</span> is issued, since the DN of OLD and =
NEW are the
same, all revoked certificates from OLD and NEW are stored in <span
class=3DSpellE>CRLNew</span>.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>This is the
software&#8217;s behavior.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>Question: is
this ok according to X.509?<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2;
tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family:
Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>4)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Lets=

suppose that <span class=3DSpellE>CRLOld</span> had the following =
certificates
{1, 3, 5}<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2;
tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family:
Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>5)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><span class=3DGramE><font =
size=3D2
face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;
mso-ansi-language:EN-US'>Lets</span></font></span><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>
suppose that a new cert 8 is revoked.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span><span
class=3DSpellE>CRLNew</span> will have {1, 3, 5, =
8}<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo2;
tab-stops:list 36.0pt'><![if !supportLists]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-fareast-font-family:
Arial;mso-ansi-language:EN-US'><span style=3D'mso-list:Ignore'>6)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;mso-ansi-language:EN-US'>When=

a third party receives an email signed with Cert 1 what should it =
do?<span
style=3D'mso-spacerun:yes'>&nbsp; </span>It will look at <span =
class=3DSpellE>CRLNew</span>,
but <span class=3DSpellE>CRLNew</span> is not signed with the same =
private key
than Cert 1?<span style=3D'mso-spacerun:yes'>&nbsp; </span>Question: =
Should the third party
still say that the cert is invalid or should it say that it could not =
verify
the status of the certificate? We made some tests and IE reported that =
it could
not verify the status of the certificate and did not show any warnings, =
even
though the certificate was expired.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial;mso-ansi-language:EN-US'>I&#8217;d appreciate =
any help
on this. <span style=3D'mso-spacerun:yes'>&nbsp;</span>It seems to me =
that all that
was described should not be legal according to X.509, but this is an =
actual
case that is happening with the CA in =
</span></font><st1:country-region><st1:place><font
  size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;
  =
mso-ansi-language:EN-US'>Brazil</span></font></st1:place></st1:country-re=
gion><font
size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;
mso-ansi-language:EN-US'> and I couldn&#8217;t find in the norms where =
it is
said that this is illegal.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial;mso-ansi-language:EN-US'>Thanks,<o:p></o:p></spa=
n></font></p>

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

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

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

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:10.0pt;mso-ansi-language:EN-US;mso-no-proof:yes'>Rodri=
go
Botafogo<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt;mso-ansi-language:EN-US'><o:p>&nbsp;</o:p></spa=
n></font></p>

</div>

</body>

</html>

------=_NextPart_001_03AE_01C418E2.74729B80--

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

------=_NextPart_000_03AD_01C418E2.746F8E40--

Date: Fri, 2 Apr 2004 16:45:29 -0500
To: "Dave Engberg" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Signing Untrusted SCVP?
Cc: <[email-masked]>
Sender: [email-masked]

Dave,

I agree that one might not want to invest as much effort and money in 
securing a DPD server as a DPV server. But that does not necessarily 
translate into removing the need for signatures on responses from 
such servers. If responses from a DPD server are spoofed, a client 
may be subject to a form of DoS attack, as it tries to make use of 
bogus certs formed chains intended to maximize the amount of crypto 
processing the client does, before realizing that the chain is bad. 
Or certs might be returned that conflict with certs from some other 
DPD server.  Without signed responses it could be very hard to 
determine what went wrong and what servers ought to be avoided, based 
on bad behavior.

Steve

Subject: Re: PKI International Consortium
To: [email-masked]
Cc: "Anders Rundgren" <[email-masked]>, "PKIX list" <[email-masked]>, [email-masked]
From: [email-masked]
Date: Fri, 2 Apr 2004 11:49:36 -0700
Sender: [email-masked]

sort of the fundamental issue is that the certificate design point is for
offline processing .... it contains sufficient information that it is
possible for the relying party to perform some operation based on relying
on the certificate w/o needing recourse to any additional information.

the problem is also sort of analogous to the issue of needing different
shared-secrets for different security domains ... recent topic drift in
sci.scrypt ...
http://www.garlic.com/~lynn/2004d.html#40 RFC-2898 Appendix B

lets say i have a passport certificate and i wish to do a financial
transaction on a chase bank account. the passport certificate probably
doesn't provide any information with regard to whether i even have a
financial account with chase bank .... aka the passport certificate
contains insufficient information for a relying party expecting a valid
financial transaction.

so for an offline certificate paradigm to work .... it just about means a
unique certificate for every operational domain ... containing sufficient
information that a relying party will go ahead and do whatever operation
based on the contents of the certificate.

now, if the relying party really wants a financial transaction executed
with chase .... then there is not only the issue of the contents of a
stale, static certificate designed as a solution for offline environments
... but there is the possibility that the relying party might be interested
in online, timely, and possibly aggregated information (not conducive for
incorporation in a stale, static certificate designed for solving problems
associated with offline environments) ... in which case, the relying party
might be inclined to perform a online operation with the authoritative
institution for that particular
kind of operation. In the case of a customer financial transaction, the
relying party might be interested in performing a financial transaction
with the customer's financial institution (as the authoritative agency for
that kind of operation).

For this type of scenario, it is then possible to claim for valuable and/or
important operations (where relying parties may be interested in timely
information, as opposed to stale, static information possibly contained in
a certificate), that direclty contacting the authoritative agency makes the
use of stale, static certificates redundant and superfluous. If the
authoritative agency has registered a public key and issued a stale, static
certificate .... then if the relying party is directly contacting the
authoritative agency ... the substitute stale static certificate (issued
for addressing the needs of offline operations) is redundant and
superfluous.

[email-masked] on 4/2/2004 8:57 am wrote:

Hello everyone,

I appreciate your feedback and most of the replies were referring to
identrus.com . My basic concern is from a customer's point of view. If I
have a digital certificate issued by a single authority that is considered
trusted internationally by all financial as well as other commercial
institutions, then I do not require to have a certificate for Institution
-1 and another for Institution -2. Do we have something in place that takes
of this issue. I would be happy to carry and protect that one certificate
which is trusted by everyone.

Thank you,

Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security
978 805 1815

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

content-class: urn:content-classes:message
Subject: RE: PKI International Consortium
Date: Fri, 2 Apr 2004 09:54:28 -0800
From: "Terwilliger, Ann" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, "PKIX list" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The Visa International PKI does issue certificates to Visa Members and their agents internationally.  However, we are a closed system and these certificates are only to be used in conjunction with Visa products and services.

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Friday, April 02, 2004 8:28 AM
To: PKIX list; [email-masked]
Subject: Re: PKI International Consortium

Hi Shaheen,
There are several PKIs run by FIs, even on an international level.
However, I have some difficulties with the phrase
"certificates for the members"? 

Is a "member" an FI organization, FI employee or an FI customer?

For the premier category I believe VISA does that for the 3D Secure
network.   For FI employees I don't know if there really is any
big need for such as these certificates have little use except internally.
Well, Identrus have indeed sold such services to a few banks.

Regarding the third category, it is interesting to note that banks
seem to take the lead in issuing "citizen-certificates" as a
citizen=bank customer.  These FA CAs are though not really
international due to some basic problems like the lack of
standards for expressing citizen identities in various regimes.
Here the customer is really e-governments although the certificates
can often be used for on-line banking as well.

www.identrus.com
www.bankid.com
www.bankid.no

Anders

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

From: <[email-masked]>
To: "PKIX list" <[email-masked]>
Sent: Thursday, April 01, 2004 16:30
Subject: PKI International Consortium

Hello,

I would like to know if there is any international consortium of financial
institutions that maintain a PKI and issues certificates for the members.
If so, what are the standards followed? Any information would be helpful.

Regards.

Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security

-----------------------------------
This message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for delivery of this message to the intended
recipient(s), you are hereby notified that any dissemination, distribution
or copying of this message is strictly prohibited.  If you have received
this message in error, please immediately notify the sender and delete this
e-mail message from your computer.

Content-class: urn:content-classes:message
Subject: SMIME Capabilities in X.509 certificates.
Date: Fri, 2 Apr 2004 18:47:55 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPartTM-000-9219e7d0-b3e1-43af-bb98-272ff38359b6
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C418DA.93B68833"

------_=_NextPart_001_01C418DA.93B68833
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

=20

=20

=20

=20

=20

=20

Stefan Santesson

=20

------_=_NextPart_001_01C418DA.93B68833
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>I would like to revisit a subject that has =
been
discussed in the passed as consideration for future =
work.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>The SMIME Capabilities attribute, defined in =
PKCS#9
is used in CMS as a signedAttribute (RFC 2633, </span></font><span =
lang=3DEN-US>2.5.2
SMIMECapabilities Attribute</span><font size=3D2 face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial'>) to carry information =
about the
cryptographic capabilities of an entity.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>However the use of this extension can also be =
useful
to carry inside a certificate to communicate primary capabilities in =
situation
where no other prior knowledge of the other party =
exist.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>There are of course cases where it is =
unsuitable to
include such information in certificates, e.g. where the capabilities =
changes
over time within the validity period of the certificate, but there are =
without
doubt situations where it is useful.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Microsoft has since long successfully used the =
PKCS#9
attribute OID to also identify a certificate extension with the same =
syntax of
this attribute, to include this information in certificates. I would =
therefore suggest
that PKIX consider standardizing this =
practice.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>This may also be an issue for the update of =
RFC 2632 dependent
on this work group&#8217;s opinion.<o:p></o:p></span></font></p>

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

<div>

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dolive =
face=3D"Times New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;color:olive'>Stefan =
Santesson</span></font></b></strong><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dolive face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Program =
Manager, Windows
Security</span></font><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:black'><o:p></o:p></spa=
n></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dolive face=3DArial><span =
lang=3DEN-US
style=3D'font-size:7.5pt;font-family:Arial;color:olive'>Principal =
Consultant,
Microsoft <st1:country-region w:st=3D"on"><st1:place =
w:st=3D"on">Denmark</st1:place></st1:country-region></span></font><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'><o:p></o:p></span></font></p>

</div>

</div>

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

</div>

</body>

</html>

------_=_NextPart_001_01C418DA.93B68833--

------=_NextPartTM-000-9219e7d0-b3e1-43af-bb98-272ff38359b6--

Date: Fri, 2 Apr 2004 11:47:32 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: PKI International Consortium
Cc: "PKIX list" <[email-masked]>
Sender: [email-masked]

At 10:57 AM -0500 4/2/04, [email-masked] wrote:
>Hello everyone,
>
>I appreciate your feedback and most of the replies were referring to
>identrus.com . My basic concern is from a customer's point of view. If I
>have a digital certificate issued by a single authority that is considered
>trusted internationally by all financial as well as other commercial
>institutions, then I do not require to have a certificate for Institution
>-1 and another for Institution -2. Do we have something in place that takes
>of this issue. I would be happy to carry and protect that one certificate
>which is trusted by everyone.
>
>Thank you,
>
>Shaheen Nasirudheen
>JPMorgan ACCESS, Portal Security
>978 805 1815
>

The notion of the one cert that is good for everything is probably 
never going to be a reality, fortunately. Note there there are no 
physical credentials that have this property. Why would you believe 
that digital credentials could overcome the organizational obstacles 
that contribute to the existence of context-limited credentials? 
Moreover, consider the awful consequences associated with a 
compromise of the private key associated with such a cert, if it 
existed.

Steve

From: "Anders Rundgren" <[email-masked]>
To: "PKIX list" <[email-masked]>, <[email-masked]>
Subject: Re: PKI International Consortium
Date: Fri, 2 Apr 2004 19:13:00 +0200
Sender: [email-masked]

Shaheen,
I believe this is a *very* good idea which I have touted myself.

The problem I see, is that FIs do not accept the open PKI
approach which makes their offers less tasteful.

That is, FIs (unlike practically all other CAs) force each
relying party to:
- Have a contract with each FI trust network
- Install the trust network's proprietary (often licensed) verification software
- Get and install a unique ID from the relying party's FI

http://w1.181.telia.com/~u18116613/e-government-ID-A.Rundgren.pdf

Due to this, I believe we will not get this wonderful PKI that
you and I dream of but rather stay with an ocean of highly
variant and incompatible "security solutions".

Anders

----- Original Message ----- 
From: <[email-masked]>
To: "PKIX list" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>
Sent: Friday, April 02, 2004 17:57
Subject: Re: PKI International Consortium

Hello everyone,

I appreciate your feedback and most of the replies were referring to
identrus.com . My basic concern is from a customer's point of view. If I
have a digital certificate issued by a single authority that is considered
trusted internationally by all financial as well as other commercial
institutions, then I do not require to have a certificate for Institution
-1 and another for Institution -2. Do we have something in place that takes
of this issue. I would be happy to carry and protect that one certificate
which is trusted by everyone.

Thank you,

Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security
978 805 1815

Subject: Re: PKI International Consortium
To: "PKIX list" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>
From: [email-masked]
Date: Fri, 2 Apr 2004 10:57:19 -0500
Sender: [email-masked]

Hello everyone,

I appreciate your feedback and most of the replies were referring to
identrus.com . My basic concern is from a customer's point of view. If I
have a digital certificate issued by a single authority that is considered
trusted internationally by all financial as well as other commercial
institutions, then I do not require to have a certificate for Institution
-1 and another for Institution -2. Do we have something in place that takes
of this issue. I would be happy to carry and protect that one certificate
which is trusted by everyone.

Thank you,

Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security
978 805 1815

-----------------------------------
This message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for delivery of this message to the intended
recipient(s), you are hereby notified that any dissemination, distribution
or copying of this message is strictly prohibited.  If you have received
this message in error, please immediately notify the sender and delete this
e-mail message from your computer.

                    "Anders Rundgren"                                                                                 
                    <anders.rundgren@       To:     "PKIX list" <[email-masked]>, Shaheen                          
                    telia.com>               Nasirudheen/JPMCHASE@JPMCHASE                                            
                                            cc:                                                                       
                    04/02/2004 11:28        Subject:     Re: PKI International Consortium                             
                    AM                                                                                                

Hi Shaheen,
There are several PKIs run by FIs, even on an international level.
However, I have some difficulties with the phrase
"certificates for the members"?

Is a "member" an FI organization, FI employee or an FI customer?

For the premier category I believe VISA does that for the 3D Secure
network.   For FI employees I don't know if there really is any
big need for such as these certificates have little use except internally.
Well, Identrus have indeed sold such services to a few banks.

Regarding the third category, it is interesting to note that banks
seem to take the lead in issuing "citizen-certificates" as a
citizen=bank customer.  These FA CAs are though not really
international due to some basic problems like the lack of
standards for expressing citizen identities in various regimes.
Here the customer is really e-governments although the certificates
can often be used for on-line banking as well.

www.identrus.com
www.bankid.com
www.bankid.no

Anders

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

From: <[email-masked]>
To: "PKIX list" <[email-masked]>
Sent: Thursday, April 01, 2004 16:30
Subject: PKI International Consortium

Hello,

I would like to know if there is any international consortium of financial
institutions that maintain a PKI and issues certificates for the members.
If so, what are the standards followed? Any information would be helpful.

Regards.

Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security

-----------------------------------
This message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for delivery of this message to the intended
recipient(s), you are hereby notified that any dissemination, distribution
or copying of this message is strictly prohibited.  If you have received
this message in error, please immediately notify the sender and delete this
e-mail message from your computer.

From: "Anders Rundgren" <[email-masked]>
To: "PKIX list" <[email-masked]>, <[email-masked]>
Subject: Re: PKI International Consortium
Date: Fri, 2 Apr 2004 18:28:12 +0200
Sender: [email-masked]

Hi Shaheen,
There are several PKIs run by FIs, even on an international level.
However, I have some difficulties with the phrase
"certificates for the members"? 

Is a "member" an FI organization, FI employee or an FI customer?

For the premier category I believe VISA does that for the 3D Secure
network.   For FI employees I don't know if there really is any
big need for such as these certificates have little use except internally.
Well, Identrus have indeed sold such services to a few banks.

Regarding the third category, it is interesting to note that banks
seem to take the lead in issuing "citizen-certificates" as a
citizen=bank customer.  These FA CAs are though not really
international due to some basic problems like the lack of
standards for expressing citizen identities in various regimes.
Here the customer is really e-governments although the certificates
can often be used for on-line banking as well.

www.identrus.com
www.bankid.com
www.bankid.no

Anders

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

From: <[email-masked]>
To: "PKIX list" <[email-masked]>
Sent: Thursday, April 01, 2004 16:30
Subject: PKI International Consortium

Hello,

I would like to know if there is any international consortium of financial
institutions that maintain a PKI and issues certificates for the members.
If so, what are the standards followed? Any information would be helpful.

Regards.

Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security

-----------------------------------
This message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for delivery of this message to the intended
recipient(s), you are hereby notified that any dissemination, distribution
or copying of this message is strictly prohibited.  If you have received
this message in error, please immediately notify the sender and delete this
e-mail message from your computer.

Date: Fri, 02 Apr 2004 12:46:12 +0100
From: "D.W.Chadwick" <[email-masked]>
Organization: University of Salford
To: PKIX <[email-masked]>
Subject: CMS 2004
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------ACE07760760F823563D789A0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dear All

The CMS 2004 call for papers closes in just under a fortnight.

CMS 2004 is the eighth working conference in Communications and
Multimedia Security since 1995. This year it will take place in the Lake
District, England.

CMS 2004 is a joint working conference of IFIP TC6 and TC11.

All papers will be blind reviewed by a set of distinguished referees
(see below) and accepted papers will be published in the conference
proceedings by Kluwer Academic Publishers.

The call for papers can be downloaded from

http://sec.isi.salford.ac.uk/cms2004/CallForPapers/index.html

The Programme Committee comprises

David Chadwick, Program Chair, University of Salford, UK 
Jean Bacon, University of Cambridge, UK 
Steve Bellovin, AT&T Research, USA 
Elisa Bertino, CERIAS, Purdue University, USA 
Howard Chivers, University of York, UK 
Stephen Farrell, Trinity College Dublin, Ireland 
Russ Housley, Vigil Security, USA 
Stephen Kent, BBN Technologies, USA 
Herbert Leitold, TU Gratz, Austria 
Javier Lopez, University of Malaga, Spain 
Chris Mitchell, Royal Holloway College, UK 
Ken Moody, University of Cambridge, UK 
Sead Muftic, Stockholm University, Sweden 
Sassa Otenko, University of Salford, UK 
G�nther Pernul, University of Regensburg. Germany 
Bart Preneel, Katholieke Universiteit Leuven, Belgium 
Pierangela Samarati, University of Milan, Italy 
Wolfgang Schneider, Fraunhofer SIT, Germany 
Frank Siebenlist, Argonne National Laboratory, USA 
Otto Spaniol, Chairman of TC6, Aachen University, Germany 
Leon Strous, Chairman of TC11, De Nederlandsche Bank, Netherlands 
Mary Thompson, Lawrence Berkeley Laboratory, USA   

regards

David 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 1484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------ACE07760760F823563D789A0
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://sec.isi.salford.ac.uk
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-18752
fn:David Chadwick
end:vcard

--------------ACE07760760F823563D789A0--

From: "Michael Myers" <[email-masked]>
To: "Dave Engberg" <[email-masked]>, <[email-masked]>
Subject: RE: Signing Untrusted SCVP?
Date: Thu, 1 Apr 2004 17:18:56 -0700
Importance: Normal
Sender: [email-masked]

Dave,

Your analysis is consistent with original intent.  We may have
some work in front of us.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Dave Engberg
Sent: Thursday, April 01, 2004 3:43 PM
To: [email-masked]
Subject: Signing Untrusted SCVP?

Section 1.1 of the SCVP draft specification has a nice
justification for
supporting pure DPD to avoid the security and scalability
problems of
DPV:

   SCVP can be used by clients that do much of the certificate
   processing themselves but simply want an untrusted server to
   collect information for them. ...

   Untrusted SCVP servers can provide clients the certification
paths.
   They can also provide clients revocation information, such as
CRLs
   and OCSP responses, and the client needs to validate the
   certification path constructed by the SCVP server.

Validating the received path on the client requires a competent
local
validation engine, but avoids the first security concern listed
in
section 10:

   A client that trusts a server's response for validation of a
   certificate inherently trusts that server as much as it would
trust
   its own validation software.  This means that if an attacker
   compromises a trusted SCVP server, the attacker can change
the
   validation processing for every client that relies on that
server.
   Thus, an SCVP server must be protected at least as well as
the
   trust anchors that the SCVP server trusts.

Rather than trying to protect _every_ SCVP server to the same
level as a
root CA, DPD through "Untrusted SCVP" maintains end-to-end PKI
security
integrity between clients.

Given that the spec goes to some lengths to support pure DPD by
clients,
why is there a requirement (section 3) that every SCVP response
be
digitally signed?  In Untrusted mode, clients MUST ignore any
signature
from the SCVP server and independently verify the certificate
chain and
any extra CRLs, OCSP responses, etc.  The extra dynamic
signature around
the entire package is gratuitously expensive overhead (latency,
bandwidth, $20k HSM).

It would make sense (to me, obviously) to make the signature
optional,
and possibly add a request flag indicating Untrusted mode.

Content-class: urn:content-classes:message
Subject: Signing Untrusted SCVP?
Date: Thu, 1 Apr 2004 17:43:26 -0500
From: "Dave Engberg" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Section 1.1 of the SCVP draft specification has a nice justification for
supporting pure DPD to avoid the security and scalability problems of
DPV:

   SCVP can be used by clients that do much of the certificate 
   processing themselves but simply want an untrusted server to
   collect information for them. ...

   Untrusted SCVP servers can provide clients the certification paths.  
   They can also provide clients revocation information, such as CRLs 
   and OCSP responses, and the client needs to validate the 
   certification path constructed by the SCVP server.

Validating the received path on the client requires a competent local
validation engine, but avoids the first security concern listed in
section 10:

   A client that trusts a server's response for validation of a 
   certificate inherently trusts that server as much as it would trust 
   its own validation software.  This means that if an attacker 
   compromises a trusted SCVP server, the attacker can change the 
   validation processing for every client that relies on that server.  
   Thus, an SCVP server must be protected at least as well as the 
   trust anchors that the SCVP server trusts.

Rather than trying to protect _every_ SCVP server to the same level as a
root CA, DPD through "Untrusted SCVP" maintains end-to-end PKI security
integrity between clients.

Given that the spec goes to some lengths to support pure DPD by clients,
why is there a requirement (section 3) that every SCVP response be
digitally signed?  In Untrusted mode, clients MUST ignore any signature
from the SCVP server and independently verify the certificate chain and
any extra CRLs, OCSP responses, etc.  The extra dynamic signature around
the entire package is gratuitously expensive overhead (latency,
bandwidth, $20k HSM).

It would make sense (to me, obviously) to make the signature optional,
and possibly add a request flag indicating Untrusted mode.

From: "todd glassey" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
Subject: Re: WG Last Call: SHA-224
Date: Thu, 1 Apr 2004 08:56:44 -0800
Sender: [email-masked]

So then why complicate the world with another standard... why not just add
to the SHA256 spec a subsection on 224 usage? and then its not a separate
document at all...

Todd

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
To: "Russ Housley" <[email-masked]>; "Tim Polk" <[email-masked]>;
<[email-masked]>
Sent: Monday, March 29, 2004 7:41 AM
Subject: Re: WG Last Call: SHA-224

>
> At 10:25 AM -0500 3/29/04, Russ Housley wrote:
> >Paul:
> >
> >>At 8:21 AM -0500 3/29/04, Russ Housley wrote:
> >>>I understand that the computation expense is the same as SHA-256.
> >>>However, as you point out, there are times that a shorter hash
> >>>value is desirable.
> >>
> >>Do we agree that the only times where it is desirable is in
> >>severely bandwidth-restricted environments? Or am I missing some
> >>other scenario?
> >
> >It is also useful is you want all of the algorithms in a cipher
> >suite to offer the same strength.  I remember a SAAG discussion that
> >this was called "impedance match," but I do not particularly like
> >that term.
>
> This is all the more reason to put material in the document that
> tells protocol designers what the design goals for SHA-224 are. Such
> wording should explicitly say that SHA-224 SHOULD NOT be used with
> AES-128 or other asymmetric ciphers that have greater than 112 bits
> of strength.
>
> The reason I am hammering on this is that it is somewhat absurd to
> purposely reduce the strength of one of the algorithms in a cipher
> suite just so it "matches". For example, assume that someone this
> year discovers a trivial method for reducing the effective strength
> of TripleDES from 112 to 108 bits. Clearly, no one is going to stop
> using TripleDES or a suite that uses TripleDES. But, using the logic
> that prompted the creation of SHA-224, we will need a new RFC that
> specifies SHA-216 by shaving off eight more bits from the SHA-256
> result.
>
> Instead of this progression, we should be giving protocol designers
> advice that says "it is fine to use a hash algorithm that produces
> more bits than are needed to 'match' the symmetric key strength".
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

Subject: PKI International Consortium
To: PKIX list <[email-masked]>
From: [email-masked]
Date: Thu, 1 Apr 2004 09:30:16 -0500
Sender: [email-masked]

Hello,

I would like to know if there is any international consortium of financial
institutions that maintain a PKI and issues certificates for the members.
If so, what are the standards followed? Any information would be helpful.

Regards.

Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security

-----------------------------------
This message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for delivery of this message to the intended
recipient(s), you are hereby notified that any dissemination, distribution
or copying of this message is strictly prohibited.  If you have received
this message in error, please immediately notify the sender and delete this
e-mail message from your computer.