Subject: [[869272482]] Subscription to ietf-pkix for [email-masked]

From: [email-masked]
Date: Sat, 31 Aug 2002 15:41:35 -0700 (PDT)

Greetings. This message is a periodic reminder that
     [email-masked]
is subscribed to the
     ietf-pkix
mailing list.

There are two purposes for this message:
- If this message is bounced by your mail server, I can remove you from
  the mailing list and reduce waste of bandwidth and resources. (If you
  are reading this message, it clearly didn't get bounced!)
- Some people stay subscribed to mailing lists even though they do not
  want to because they do not know how to unsubscribe. 

If you want to stay subscribed to the ietf-pkix mailing list,
you do not need to do anything. Feel free to delete this message.

On the other hand, if you want to unsubscribe from this list, simply go
to the following link:
     <http://www.imc.org/Unsubs/869272482>

If for some reason you cannot go to that web site, you can also
unsubscribe by email; however, doing so is not as likely to get you
unsubscribed as the web site is. To unsubscribe using email, you can
respond to this message and I will unsubscribe you by hand in the next
few days. Again, this is not assured to work because your mail system
may make it impossible for me to determine who you are or what you want
to unsubscribe to.

Alternatively, you can send a plain-text message to:
     [email-masked]
with the single word
     unsubscribe
in the body of the message. This last method assumes that the "From:"
address in your mail is "[email-masked]". Again, using the
web site above is more likely to work than this method (due to limitations
in Majordomo, the mailing list software we currently use).

If you have any questions, feel free to contact me.

--Paul Hoffman, list administrator

Date: Sat, 31 Aug 2002 23:52:12 -0700
To: [email-masked], [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Wildcard certificates
Cc: [email-masked]
Sender: [email-masked]

"William I. Bormann" <[email-masked]> wrote:
> 1. Using dc in place of cn is probably the more correct
> approach to naming the subject of a server certificate,
> viz., for *.foo.bar.com, use dc=*,dc=foo,dc=bar,dc=com
> instead of cn=*.foo.bar.com. 

I note that RFC 2247 (as well as RFC 1274), which defines DC,
constrains it value to a domain component.  "*" is not a domain
component.  Even if "*" were allowed, it wouldn't have any
wildcard semantics.  That is, the DN "DC=*,DC=foo,DC=BAR,DC=COM"
is the (purported) name of one entry, not many.

In my opinion, the dNSname wildcard (ab)use is a far better,
and more widely supported, than DC (ab)use.  I would prefer
revising the applicable technical specifications to allow
dNSName=*.foo.bar.com wildcarding.   Most LDAP/TLS implementations
support dNSName wildcarding (as RECOMMENDED in RFC 2830).

Kurt

Date: Fri, 30 Aug 2002 14:19:06 -0400 (EDT)
From: Anne Anderson <[email-masked]>
To: [email-masked]
Subject: rfc822name Name Constraints question
Reply-To: [email-masked]
Sender: [email-masked]

RFC3280 describes how name constraints for "Internet mail
addresses" may be specified, but is unclear on a few points:

1. If the NameConstraint is "[email-masked]", does that include
   "[email-masked]"?
2. Can "@xyz.com" be used to match all mail addresses at
   "xyz.com" but not addresses at "abc.xyz.com?
3. The paragraph says the constraint "xyz.com" is satisfied by
   "any mail address at the host "xyz.com", and ".xyz.com" is
   satisfied by an address within the domain xyz.com, but not
   xyz.com itself.  How then do I specify all addresses in the
   domain xyz.com AND xyz.com itself?

Anne Anderson
-- 
Anne H. Anderson             Email: [email-masked]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Date: Fri, 30 Aug 2002 14:12:34 -0400 (EDT)
From: Anne Anderson <[email-masked]>
To: <[email-masked]>
Subject: Standard for Name Constraints for X500Names
Reply-To: [email-masked]
Sender: [email-masked]

In RFC3280, I do not find an algorithm or reference for how
X500Name NameConstraints are compared.  I know that the empty
string is the root of the X500 name space, but..

If A is constrained by B,
- must A include all RDNs in B as its most general RDNs?
- is there any sub-matching within a given RDN?  e.g.
   CN="* Anderson" matching "CN="Anne Anderson", or some other
   syntax for such partial matches?

Is there a standard for such comparisons?  An X500 ordering-rule
or something?

Anne Anderson
-- 
Anne H. Anderson             Email: [email-masked]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Content-return: allowed
Date: Fri, 30 Aug 2002 09:15:43 -0700
From: Ambarish Malpani <[email-masked]>
Subject: AIA for OCSP
To: "'carol'" <[email-masked]>, [email-masked]
Sender: [email-masked]

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

--Boundary_(ID_UBJaFM1u6/MxUY6XL0875w)
Content-type: text/plain; charset="GB2312"

Hi Carol,
    We support both mechanisms (in our toolkit). The other option
is to have a single fully qualified domain name map to multiple
IP addresses (if this is a mechanism being used by the responder
to provide redundancy).

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: carol [mailto:[email-masked]]
> Sent: Wednesday, August 28, 2002 6:15 PM
> To: [email-masked]
> Subject: 
> 
> 
> 
> ietf-pkix Hello everybody,
> 
>    In our CA system, their are several ocsp responders. One 
> can ask two ocsp responders
>    for the status of a certficate, for example http://global 
> and http://local . 
>    In such situation, what should be the AuthorityInfoAccess 
> extension like?
> 
>    case 1: only one AccessDescription node in 
> AuthorityInfoAccessSyntax
> 
>      AccessMethod  : id-at-ocsp
>      AccessLocation(URI): http://global;http://local
>    
>    case 2: set two  AccessDescription nodes in 
> AuthorityInfoAccessSyntax
>      AccessMethod  : id-at-ocsp
>      AccessLocation(URI): http://global
> 
>      AccessMethod  : id-at-ocsp
>      AccessLocation(URI): http://local
> 
>    Which of the above is more preferable? Or is there any 
> standard/suggestion
>    for such situation?
> 
>    Thanks a lot for any answer.
> 
>  wcarol
> 

--Boundary_(ID_UBJaFM1u6/MxUY6XL0875w)
Content-type: text/html; charset="GB2312"
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=3DGB2312">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>AIA for OCSP</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Hi Carol,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; We support both mechanisms (in =
our toolkit). The other option</FONT>
<BR><FONT SIZE=3D2>is to have a single fully qualified domain name map =
to multiple</FONT>
<BR><FONT SIZE=3D2>IP addresses (if this is a mechanism being used by =
the responder</FONT>
<BR><FONT SIZE=3D2>to provide redundancy).</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Ambarish</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
------</FONT>
<BR><FONT SIZE=3D2>Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>Chief =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>ValiCert, =
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; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>1215 Terra Bella =
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; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>Mountain View, CA 94043</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: carol [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, August 28, 2002 6:15 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ietf-pkix Hello everybody,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; In our CA system, their are =
several ocsp responders. One </FONT>
<BR><FONT SIZE=3D2>&gt; can ask two ocsp responders</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; for the status of a =
certficate, for example <A HREF=3D"http://global" =
TARGET=3D"_blank">http://global</A> </FONT>
<BR><FONT SIZE=3D2>&gt; and <A HREF=3D"http://local" =
TARGET=3D"_blank">http://local</A> . </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; In such situation, what =
should be the AuthorityInfoAccess </FONT>
<BR><FONT SIZE=3D2>&gt; extension like?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; case 1: only one =
AccessDescription node in </FONT>
<BR><FONT SIZE=3D2>&gt; AuthorityInfoAccessSyntax</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
AccessMethod&nbsp; : id-at-ocsp</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
AccessLocation(URI): <A HREF=3D"http://global;http://local" =
TARGET=3D"_blank">http://global;http://local</A></FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; case 2: set two&nbsp; =
AccessDescription nodes in </FONT>
<BR><FONT SIZE=3D2>&gt; AuthorityInfoAccessSyntax</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
AccessMethod&nbsp; : id-at-ocsp</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
AccessLocation(URI): <A HREF=3D"http://global" =
TARGET=3D"_blank">http://global</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
AccessMethod&nbsp; : id-at-ocsp</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
AccessLocation(URI): <A HREF=3D"http://local" =
TARGET=3D"_blank">http://local</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Which of the above is more =
preferable? Or is there any </FONT>
<BR><FONT SIZE=3D2>&gt; standard/suggestion</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; for such situation?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Thanks a lot for any =
answer.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; wcarol</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_UBJaFM1u6/MxUY6XL0875w)--

Content-return: allowed
Date: Fri, 30 Aug 2002 04:51:44 -0700
From: Peter Williams <[email-masked]>
Subject: RE: Wildcard certificates
To: "'Kefeng Chen '" <[email-masked]>, "''Stefan Santesson' '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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

--Boundary_(ID_jbPQS+Azs0DFjU2cg1KWTg)
Content-type: text/plain

Folks,

2 issues: (a) wildcards, and (b) using a nominated Root CA 
to issue wildcard certs based on reliance on another certificate.

(a) wildcards

There is nothing in any known standard that constrains 
binding any complying common-name to a PKIX
certificate. It would be improper for any PKI standard to 
contrain applications in their use of names. I&A and access control
functions of OSs (or their apps) are not in the scope 
of PKIX, ISO, etc.

All PKIX applications are allowed, explictely, to
impose applicaiton-specific rules on the handling
of cert paths, once they pass PKIX cert path
processing rules. Cert path processing rules
DO NOT address application-specific matching rules
or processing rules for common-names - which ISO definees
to have local identification-semantics.

In the case of https, the rules of de facto standards
for over 5 years now include handling the binding between 
transport-addresses signalled by the socket (which may be a VPN, 
as known to the local application) and the common-name value.
The facility was introduced in the earliest days of
the secure server tradition - to support MCI's and AT&T's
e-mall concepts.

(2) Root key use/sale

Ive proposed to Valicert that we begin to use (or sell) one of our
Root keys for the following purposes related to wildcards:

An enterprise procures 1 class 3 certificate from verisign, for $300,
each year.

An enterprise procures a couple of additional wildcard certs from  
valicert or A.N.OTHER,  for ALL other server certs required by 
that enterprise. The wildcard cert can support an entire class of "secure
servers" which do not need to be independently keyed, and 
are managed as server group from a single console.

Valicert would use the verisign certificate as an proxy LRA, 
essentially. The wild card cert status could generally track the 
status of the certificate issued by verisign, performing the normal
actions of relying party when deciding whether to not
to rely on the verisign certificate. ValiCerg can properly publish
its decision to no longer rely on any given certificate to all users, 
of course.

If we need to write an ID on this issuing practice, Id be happy
to volunteer. I could also see how the ValiCert WebTrust disclosures 
and controls would have to change to authorize this issuing and 
business practice; this guidance would conform part of the
ID, perhaps.

Mail me here or privately, if you want to discuss this. Making
the WebTrust policy changes would be an interesting project,
that can benefit PKIX more generally than just specifying
the wildcard matters. Id like to transfer some of the
ValiCert exerience in satisfying the webtrust criteria to IETF,
as the way I satisifed the audit requiremnets was really quite 
novel; the  approach could be reused widely by others, in my opinion,
to bring the cost of audit down to <$50,000.

Peter.

-----Original Message-----
From: Kefeng Chen
To: 'Stefan Santesson'; [email-masked]
Sent: 8/28/02 10:20 AM
Subject: RE: Wildcard certificates

Both Microsoft IE browser and Netscape browser
accept wild card SSL server certificate.
Microsoft IE has more strict rules on accepting wild card
cert than Netscape browser.

-Kefeng

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Wednesday, August 28, 2002 8:49 AM
To: [email-masked]
Subject: Wildcard certificates

I wander if anyone on this list have experience/opinions on using
wildcard
names in SSL server certificates.

E.g. having the name *.domain.com  in one certificate instead of having
xxx.domain.com and secure.domain.com as common name in 2 separate
certificates.

Several CA service providers offer wildcard certificates on the market
today.

Talking to Steve Kent in Yokohama, he implied that this practice is
against
current standards (but I can't recall how) and that it is known to
create
problems in certain environments.

Are there any opinions on the list?

1) Is this braking any standards?
2) What environments have problems with wildcard certificates?
3) What are the problems?

/Stefan

--Boundary_(ID_jbPQS+Azs0DFjU2cg1KWTg)
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.2653.12">
<TITLE>RE: Wildcard certificates</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>2 issues: (a) wildcards, and (b) using a nominated =
Root CA </FONT>
<BR><FONT SIZE=3D2>to issue wildcard certs based on reliance on another =
certificate.</FONT>
</P>

<P><FONT SIZE=3D2>(a) wildcards</FONT>
</P>

<P><FONT SIZE=3D2>There is nothing in any known standard that =
constrains </FONT>
<BR><FONT SIZE=3D2>binding any complying common-name to a PKIX</FONT>
<BR><FONT SIZE=3D2>certificate. It would be improper for any PKI =
standard to </FONT>
<BR><FONT SIZE=3D2>contrain applications in their use of names. I&amp;A =
and access control</FONT>
<BR><FONT SIZE=3D2>functions of OSs (or their apps) are not in the =
scope </FONT>
<BR><FONT SIZE=3D2>of PKIX, ISO, etc.</FONT>
</P>

<P><FONT SIZE=3D2>All PKIX applications are allowed, explictely, =
to</FONT>
<BR><FONT SIZE=3D2>impose applicaiton-specific rules on the =
handling</FONT>
<BR><FONT SIZE=3D2>of cert paths, once they pass PKIX cert path</FONT>
<BR><FONT SIZE=3D2>processing rules. Cert path processing rules</FONT>
<BR><FONT SIZE=3D2>DO NOT address application-specific matching =
rules</FONT>
<BR><FONT SIZE=3D2>or processing rules for common-names - which ISO =
definees</FONT>
<BR><FONT SIZE=3D2>to have local identification-semantics.</FONT>
</P>

<P><FONT SIZE=3D2>In the case of https, the rules of de facto =
standards</FONT>
<BR><FONT SIZE=3D2>for over 5 years now include handling the binding =
between </FONT>
<BR><FONT SIZE=3D2>transport-addresses signalled by the socket (which =
may be a VPN, </FONT>
<BR><FONT SIZE=3D2>as known to the local application) and the =
common-name value.</FONT>
<BR><FONT SIZE=3D2>The facility was introduced in the earliest days =
of</FONT>
<BR><FONT SIZE=3D2>the secure server tradition - to support MCI's and =
AT&amp;T's</FONT>
<BR><FONT SIZE=3D2>e-mall concepts.</FONT>
</P>

<P><FONT SIZE=3D2>(2) Root key use/sale</FONT>
</P>

<P><FONT SIZE=3D2>Ive proposed to Valicert that we begin to use (or =
sell) one of our</FONT>
<BR><FONT SIZE=3D2>Root keys for the following purposes related to =
wildcards:</FONT>
</P>

<P><FONT SIZE=3D2>An enterprise procures 1 class 3 certificate from =
verisign, for $300,</FONT>
<BR><FONT SIZE=3D2>each year.</FONT>
</P>

<P><FONT SIZE=3D2>An enterprise procures a couple of additional =
wildcard certs from&nbsp; </FONT>
<BR><FONT SIZE=3D2>valicert or A.N.OTHER,&nbsp; for ALL other server =
certs required by </FONT>
<BR><FONT SIZE=3D2>that enterprise. The wildcard cert can support an =
entire class of &quot;secure servers&quot; which do not need to be =
independently keyed, and </FONT></P>

<P><FONT SIZE=3D2>are managed as server group from a single =
console.</FONT>
</P>

<P><FONT SIZE=3D2>Valicert would use the verisign certificate as an =
proxy LRA, </FONT>
<BR><FONT SIZE=3D2>essentially. The wild card cert status could =
generally track the </FONT>
<BR><FONT SIZE=3D2>status of the certificate issued by verisign, =
performing the normal</FONT>
<BR><FONT SIZE=3D2>actions of relying party when deciding whether to =
not</FONT>
<BR><FONT SIZE=3D2>to rely on the verisign certificate. ValiCerg can =
properly publish</FONT>
<BR><FONT SIZE=3D2>its decision to no longer rely on any given =
certificate to all users, </FONT>
<BR><FONT SIZE=3D2>of course.</FONT>
</P>

<P><FONT SIZE=3D2>If we need to write an ID on this issuing practice, =
Id be happy</FONT>
<BR><FONT SIZE=3D2>to volunteer. I could also see how the ValiCert =
WebTrust disclosures </FONT>
<BR><FONT SIZE=3D2>and controls would have to change to authorize this =
issuing and </FONT>
<BR><FONT SIZE=3D2>business practice; this guidance would conform part =
of the</FONT>
<BR><FONT SIZE=3D2>ID, perhaps.</FONT>
</P>

<P><FONT SIZE=3D2>Mail me here or privately, if you want to discuss =
this. Making</FONT>
<BR><FONT SIZE=3D2>the WebTrust policy changes would be an interesting =
project,</FONT>
<BR><FONT SIZE=3D2>that can benefit PKIX more generally than just =
specifying</FONT>
<BR><FONT SIZE=3D2>the wildcard matters. Id like to transfer some of =
the</FONT>
<BR><FONT SIZE=3D2>ValiCert exerience in satisfying the webtrust =
criteria to IETF,</FONT>
<BR><FONT SIZE=3D2>as the way I satisifed the audit requiremnets was =
really quite </FONT>
<BR><FONT SIZE=3D2>novel; the&nbsp; approach could be reused widely by =
others, in my opinion,</FONT>
<BR><FONT SIZE=3D2>to bring the cost of audit down to =
&lt;$50,000.</FONT>
</P>

<P><FONT SIZE=3D2>Peter.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kefeng Chen</FONT>
<BR><FONT SIZE=3D2>To: 'Stefan Santesson'; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Sent: 8/28/02 10:20 AM</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Wildcard certificates</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Both Microsoft IE browser and Netscape browser</FONT>
<BR><FONT SIZE=3D2>accept wild card SSL server certificate.</FONT>
<BR><FONT SIZE=3D2>Microsoft IE has more strict rules on accepting wild =
card</FONT>
<BR><FONT SIZE=3D2>cert than Netscape browser.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-Kefeng</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stefan Santesson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 28, 2002 8:49 AM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Wildcard certificates</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>I wander if anyone on this list have =
experience/opinions on using</FONT>
<BR><FONT SIZE=3D2>wildcard</FONT>
<BR><FONT SIZE=3D2>names in SSL server certificates.</FONT>
</P>

<P><FONT SIZE=3D2>E.g. having the name *.domain.com&nbsp; in one =
certificate instead of having</FONT>
<BR><FONT SIZE=3D2>xxx.domain.com and secure.domain.com as common name =
in 2 separate</FONT>
<BR><FONT SIZE=3D2>certificates.</FONT>
</P>

<P><FONT SIZE=3D2>Several CA service providers offer wildcard =
certificates on the market</FONT>
<BR><FONT SIZE=3D2>today.</FONT>
</P>

<P><FONT SIZE=3D2>Talking to Steve Kent in Yokohama, he implied that =
this practice is</FONT>
<BR><FONT SIZE=3D2>against</FONT>
<BR><FONT SIZE=3D2>current standards (but I can't recall how) and that =
it is known to</FONT>
<BR><FONT SIZE=3D2>create</FONT>
<BR><FONT SIZE=3D2>problems in certain environments.</FONT>
</P>

<P><FONT SIZE=3D2>Are there any opinions on the list?</FONT>
</P>

<P><FONT SIZE=3D2>1) Is this braking any standards?</FONT>
<BR><FONT SIZE=3D2>2) What environments have problems with wildcard =
certificates?</FONT>
<BR><FONT SIZE=3D2>3) What are the problems?</FONT>
</P>

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

</BODY>
</HTML>

--Boundary_(ID_jbPQS+Azs0DFjU2cg1KWTg)--

Date: Fri, 30 Aug 2002 09:58:28 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Housley, Russ" <[email-masked]>
CC: Steve Tuecke <[email-masked]>, [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Russ,

> Steve:
> 
> I think that a straw poll is in order.  If the consensus of the group is
> that this work should proceed, then we simply follow the usual process.  If
> the consensus of the group is that this work should not proceed, then
> withdrawal is the appropriate course of action.
> 
> Would the PKIX WG Chairs please conduct the poll...

Hold on a second.

Is this document going to follow the Standards Track or the Informational
Track ?

I understood that the document is being progressed in the Grid Forum
Document and is well advanced. I wonder if the PKIX WG will have the real
possiblity to influence the content of the document. When a document is
going on the Standards Track, it has to reflect the consensus of the PKIX
WG and we all know by experience that it takes much more than a couple of
months to reach a consensus. I wonder if that time frame is compatible with
the goals of the people supporting that document.

Now, if the document is going to follow the Informational Track, it can do
it within or outside the PKIX WG.

Before any strow poll is conducted, it first needs to be clarified whether
the proposal would be to carry on the work on the Standards Track or the
Informational Track.

Denis 
 
> Russ
> 
> At 12:24 AM 8/28/2002 -0500, Steve Tuecke wrote:
> >Russ,
> >
> >So how do we get there from here?
> >
> >One fundamental obstacle may be that there are some PKIX participants who
> >seem to be fundamentally opposed to the approach taken in the proxy cert
> >profile.  Having had a number of conversations with such people, my belief
> >is that it is likely an irreconcilable difference.  It seems to be more of
> >a difference in world-view than in any specific technical detail -- they
> >believe that using an end-entity certificate to sign proxy certificates is
> >at fundamental odds with X.509 and PKIX philosophies.
> >
> >But even if we are able to resolve this difference (e.g. either through
> >finding an approach that we all agree on, or by agreeing to disagree but
> >moving forward anyway), I guess its not clear to me how we overcome the
> >energy barrier to advance it to an RFC.  There seems to be a general
> >apathy within PKIX participants toward advancing this draft.  (And please
> >realize that I am not faulting anybody by making this statement.  We all
> >have our own agendas within PKIX, and it may just be that mine is too far
> >off the radar for most.)
> >
> >I'm completely comfortable with PKIX making a consensus decision that the
> >Proxy Cert Profile should not be considered further in PKIX.  I'm also
> >happy to push forward with it if there is support for doing so.  But given
> >that it is currently languishing in PKIX, and that I don't see an obvious
> >path toward reaching consensus in PKIX on this profile, I felt the most
> >reasonable route was to suggest the withdrawal of the draft from PKIX.
> >
> >-Steve
> >
> >At 02:57 PM 8/27/2002, Housley, Russ wrote:
> >>Steve:
> >>
> >>I would like to see certificate handling libraries support the delegation
> >>environment, and the people that write such libraries are currently
> >>paying attention to the PKIX WG.  So, that is my preferred route.
> >>
> >>Russ
> >>
> >>At 02:05 PM 8/27/2002 -0500, Steve Tuecke wrote:
> >>>Russ,
> >>>
> >>>There are, of course, two avenues to RFC -- one through a working group,
> >>>and the other as an individual submission.  I am curious what you think
> >>>of each of these avenues, and more generally why you would prefer to see
> >>>it published as an RFC.  For broad acceptability of the profile, the
> >>>best route is obviously PKIX.  But if that doesn't happen, is there any
> >>>value to it being an individually submitted informational RFC, in
> >>>addition to a GGF (RFC-like) GFD?  (The GGF document process is pretty
> >>>similar to IETF.)
> >>>
> >>>-Steve
> >>>
> >>>At 01:01 PM 8/27/2002, Housley, Russ wrote:
> >>>>Steve:
> >>>>
> >>>>I understand the need for you to make progress.  And, I will support
> >>>>any pragmatic decision that you make.  However, I would prefer to see
> >>>>this profile published as an RFC.
> >>>>
> >>>>Russ
> >>>>
> >>>>At 11:47 AM 8/27/2002 -0500, Steve Tuecke wrote:
> >>>>
> >>>>>All,
> >>>>>
> >>>>>In February 2001 we wrote a first draft of "Internet X.509 Public Key
> >>>>>Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02)
> >>>>>and introduced it into the Global Grid Forum (GGF, www.gridforum.org).
> >>>>>Shortly after that, because it seemed to relate to the work in PKIX,
> >>>>>we also introduced it into the PKIX working group.  Tim and Steve
> >>>>>accepted this draft into PKIX and gave me time at several IETFs to
> >>>>>present progress on this draft (for which we are most grateful!),
> >>>>>which led to many useful discussions with IETF folks.  Over the past
> >>>>>year and a half, we have continued to refine the draft as a result of
> >>>>>this input and our own continuing work in this area.
> >>>>>
> >>>>>We are now trying to reach closure on this draft, so that various
> >>>>>groups, including our Globus Project, can implement and deploy to a
> >>>>>non-moving target.  There is strong support in the GGF Grid Security
> >>>>>Infrastructure (GSI) working group to finalize the draft, and push it
> >>>>>on to become a Grid Forum Document (GFD), which is GGF's equivalent of
> >>>>>an RFC. However, within the PKIX community I think its fair to say
> >>>>>that it has received little attention, and the reactions that have
> >>>>>been expressed have been mixed -- everywhere from strong disagreement
> >>>>>to strong support of the approach.
> >>>>>
> >>>>>We have a new, significantly cleaned up draft available at
> >>>>>http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet
> >>>>>submitted it to IETF, pending the outcome of this discussion.
> >>>>>
> >>>>>Our current intention is to withdraw this document from PKIX
> >>>>>consideration, and finish it up within GGF.  (The previous
> >>>>>draft-ietf-pkix-proxy-02 expires this month.)  However, if there is a
> >>>>>public ground swell to complete it within PKIX, we are happy to reconsider.
> >>>>>
> >>>>>Meanwhile, this draft is currently in last-call in the GGF GSI working
> >>>>>group, prior to submitting it for consideration to become a GFD.  We
> >>>>>would be happy to receive and incorporate feedback to the latest GGF
> >>>>>draft (see above URL), prior to the final submission (hopefully within
> >>>>>in a couple weeks).
> >>>>>
> >>>>>Thanks,
> >>>>>-Steve
> >>>>>------------------------------------------------------------------------
> >>>>>Steve Tuecke           MCS, Bldg 221, Office B-159  work: (630) 252-8711
> >>>>>[email-masked]     Argonne National Laboratory  cell: (630) 842-6917
> >>>>>http://www.mcs.anl.gov/~tuecke  Argonne, IL 60439   fax: (630) 252-5986

Date: Thu, 29 Aug 2002 19:02:01 -0500
To: "Housley, Russ" <[email-masked]>
From: Steve Tuecke <[email-masked]>
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Cc: [email-masked]
Sender: [email-masked]

I agree.
-Steve

At 08:54 AM 8/29/2002, Housley, Russ wrote:
>Steve:
>
>I think that a straw poll is in order.  If the consensus of the group is 
>that this work should proceed, then we simply follow the usual 
>process.  If the consensus of the group is that this work should not 
>proceed, then withdrawal is the appropriate course of action.
>
>Would the PKIX WG Chairs please conduct the poll...
>
>Russ
>
>
>At 12:24 AM 8/28/2002 -0500, Steve Tuecke wrote:
>>Russ,
>>
>>So how do we get there from here?
>>
>>One fundamental obstacle may be that there are some PKIX participants who 
>>seem to be fundamentally opposed to the approach taken in the proxy cert 
>>profile.  Having had a number of conversations with such people, my 
>>belief is that it is likely an irreconcilable difference.  It seems to be 
>>more of a difference in world-view than in any specific technical detail 
>>-- they believe that using an end-entity certificate to sign proxy 
>>certificates is at fundamental odds with X.509 and PKIX philosophies.
>>
>>But even if we are able to resolve this difference (e.g. either through 
>>finding an approach that we all agree on, or by agreeing to disagree but 
>>moving forward anyway), I guess its not clear to me how we overcome the 
>>energy barrier to advance it to an RFC.  There seems to be a general 
>>apathy within PKIX participants toward advancing this draft.  (And please 
>>realize that I am not faulting anybody by making this statement.  We all 
>>have our own agendas within PKIX, and it may just be that mine is too far 
>>off the radar for most.)
>>
>>I'm completely comfortable with PKIX making a consensus decision that the 
>>Proxy Cert Profile should not be considered further in PKIX.  I'm also 
>>happy to push forward with it if there is support for doing so.  But 
>>given that it is currently languishing in PKIX, and that I don't see an 
>>obvious path toward reaching consensus in PKIX on this profile, I felt 
>>the most reasonable route was to suggest the withdrawal of the draft from PKIX.
>>
>>-Steve
>>
>>At 02:57 PM 8/27/2002, Housley, Russ wrote:
>>>Steve:
>>>
>>>I would like to see certificate handling libraries support the 
>>>delegation environment, and the people that write such libraries are 
>>>currently paying attention to the PKIX WG.  So, that is my preferred route.
>>>
>>>Russ
>>>
>>>At 02:05 PM 8/27/2002 -0500, Steve Tuecke wrote:
>>>>Russ,
>>>>
>>>>There are, of course, two avenues to RFC -- one through a working 
>>>>group, and the other as an individual submission.  I am curious what 
>>>>you think of each of these avenues, and more generally why you would 
>>>>prefer to see it published as an RFC.  For broad acceptability of the 
>>>>profile, the best route is obviously PKIX.  But if that doesn't happen, 
>>>>is there any value to it being an individually submitted informational 
>>>>RFC, in addition to a GGF (RFC-like) GFD?  (The GGF document process is 
>>>>pretty similar to IETF.)
>>>>
>>>>-Steve
>>>>
>>>>At 01:01 PM 8/27/2002, Housley, Russ wrote:
>>>>>Steve:
>>>>>
>>>>>I understand the need for you to make progress.  And, I will support 
>>>>>any pragmatic decision that you make.  However, I would prefer to see 
>>>>>this profile published as an RFC.
>>>>>
>>>>>Russ
>>>>>
>>>>>At 11:47 AM 8/27/2002 -0500, Steve Tuecke wrote:
>>>>>
>>>>>>All,
>>>>>>
>>>>>>In February 2001 we wrote a first draft of "Internet X.509 Public Key 
>>>>>>Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02) 
>>>>>>and introduced it into the Global Grid Forum (GGF, 
>>>>>>www.gridforum.org). Shortly after that, because it seemed to relate 
>>>>>>to the work in PKIX, we also introduced it into the PKIX working 
>>>>>>group.  Tim and Steve accepted this draft into PKIX and gave me time 
>>>>>>at several IETFs to present progress on this draft (for which we are 
>>>>>>most grateful!), which led to many useful discussions with IETF 
>>>>>>folks.  Over the past year and a half, we have continued to refine 
>>>>>>the draft as a result of this input and our own continuing work in this area.
>>>>>>
>>>>>>We are now trying to reach closure on this draft, so that various 
>>>>>>groups, including our Globus Project, can implement and deploy to a 
>>>>>>non-moving target.  There is strong support in the GGF Grid Security 
>>>>>>Infrastructure (GSI) working group to finalize the draft, and push it 
>>>>>>on to become a Grid Forum Document (GFD), which is GGF's equivalent 
>>>>>>of an RFC. However, within the PKIX community I think its fair to say 
>>>>>>that it has received little attention, and the reactions that have 
>>>>>>been expressed have been mixed -- everywhere from strong disagreement 
>>>>>>to strong support of the approach.
>>>>>>
>>>>>>We have a new, significantly cleaned up draft available at 
>>>>>>http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet 
>>>>>>submitted it to IETF, pending the outcome of this discussion.
>>>>>>
>>>>>>Our current intention is to withdraw this document from PKIX 
>>>>>>consideration, and finish it up within GGF.  (The previous 
>>>>>>draft-ietf-pkix-proxy-02 expires this month.)  However, if there is a 
>>>>>>public ground swell to complete it within PKIX, we are happy to reconsider.
>>>>>>
>>>>>>Meanwhile, this draft is currently in last-call in the GGF GSI 
>>>>>>working group, prior to submitting it for consideration to become a 
>>>>>>GFD.  We would be happy to receive and incorporate feedback to the 
>>>>>>latest GGF draft (see above URL), prior to the final submission 
>>>>>>(hopefully within in a couple weeks).
>>>>>>
>>>>>>Thanks,
>>>>>>-Steve
>>>>>>------------------------------------------------------------------------
>>>>>>Steve Tuecke           MCS, Bldg 221, Office B-159  work: (630) 252-8711
>>>>>>[email-masked]     Argonne National Laboratory  cell: (630) 842-6917
>>>>>>http://www.mcs.anl.gov/~tuecke  Argonne, IL 60439   fax: (630) 252-5986

From: "Housley, Russ" <[email-masked]>
To: Steve Tuecke <[email-masked]>
Cc: [email-masked]
Date: Thu, 29 Aug 2002 09:54:21 -0400
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Steve:

I think that a straw poll is in order.  If the consensus of the group is 
that this work should proceed, then we simply follow the usual process.  If 
the consensus of the group is that this work should not proceed, then 
withdrawal is the appropriate course of action.

Would the PKIX WG Chairs please conduct the poll...

Russ

At 12:24 AM 8/28/2002 -0500, Steve Tuecke wrote:
>Russ,
>
>So how do we get there from here?
>
>One fundamental obstacle may be that there are some PKIX participants who 
>seem to be fundamentally opposed to the approach taken in the proxy cert 
>profile.  Having had a number of conversations with such people, my belief 
>is that it is likely an irreconcilable difference.  It seems to be more of 
>a difference in world-view than in any specific technical detail -- they 
>believe that using an end-entity certificate to sign proxy certificates is 
>at fundamental odds with X.509 and PKIX philosophies.
>
>But even if we are able to resolve this difference (e.g. either through 
>finding an approach that we all agree on, or by agreeing to disagree but 
>moving forward anyway), I guess its not clear to me how we overcome the 
>energy barrier to advance it to an RFC.  There seems to be a general 
>apathy within PKIX participants toward advancing this draft.  (And please 
>realize that I am not faulting anybody by making this statement.  We all 
>have our own agendas within PKIX, and it may just be that mine is too far 
>off the radar for most.)
>
>I'm completely comfortable with PKIX making a consensus decision that the 
>Proxy Cert Profile should not be considered further in PKIX.  I'm also 
>happy to push forward with it if there is support for doing so.  But given 
>that it is currently languishing in PKIX, and that I don't see an obvious 
>path toward reaching consensus in PKIX on this profile, I felt the most 
>reasonable route was to suggest the withdrawal of the draft from PKIX.
>
>-Steve
>
>At 02:57 PM 8/27/2002, Housley, Russ wrote:
>>Steve:
>>
>>I would like to see certificate handling libraries support the delegation 
>>environment, and the people that write such libraries are currently 
>>paying attention to the PKIX WG.  So, that is my preferred route.
>>
>>Russ
>>
>>At 02:05 PM 8/27/2002 -0500, Steve Tuecke wrote:
>>>Russ,
>>>
>>>There are, of course, two avenues to RFC -- one through a working group, 
>>>and the other as an individual submission.  I am curious what you think 
>>>of each of these avenues, and more generally why you would prefer to see 
>>>it published as an RFC.  For broad acceptability of the profile, the 
>>>best route is obviously PKIX.  But if that doesn't happen, is there any 
>>>value to it being an individually submitted informational RFC, in 
>>>addition to a GGF (RFC-like) GFD?  (The GGF document process is pretty 
>>>similar to IETF.)
>>>
>>>-Steve
>>>
>>>At 01:01 PM 8/27/2002, Housley, Russ wrote:
>>>>Steve:
>>>>
>>>>I understand the need for you to make progress.  And, I will support 
>>>>any pragmatic decision that you make.  However, I would prefer to see 
>>>>this profile published as an RFC.
>>>>
>>>>Russ
>>>>
>>>>At 11:47 AM 8/27/2002 -0500, Steve Tuecke wrote:
>>>>
>>>>>All,
>>>>>
>>>>>In February 2001 we wrote a first draft of "Internet X.509 Public Key 
>>>>>Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02) 
>>>>>and introduced it into the Global Grid Forum (GGF, www.gridforum.org). 
>>>>>Shortly after that, because it seemed to relate to the work in PKIX, 
>>>>>we also introduced it into the PKIX working group.  Tim and Steve 
>>>>>accepted this draft into PKIX and gave me time at several IETFs to 
>>>>>present progress on this draft (for which we are most grateful!), 
>>>>>which led to many useful discussions with IETF folks.  Over the past 
>>>>>year and a half, we have continued to refine the draft as a result of 
>>>>>this input and our own continuing work in this area.
>>>>>
>>>>>We are now trying to reach closure on this draft, so that various 
>>>>>groups, including our Globus Project, can implement and deploy to a 
>>>>>non-moving target.  There is strong support in the GGF Grid Security 
>>>>>Infrastructure (GSI) working group to finalize the draft, and push it 
>>>>>on to become a Grid Forum Document (GFD), which is GGF's equivalent of 
>>>>>an RFC. However, within the PKIX community I think its fair to say 
>>>>>that it has received little attention, and the reactions that have 
>>>>>been expressed have been mixed -- everywhere from strong disagreement 
>>>>>to strong support of the approach.
>>>>>
>>>>>We have a new, significantly cleaned up draft available at 
>>>>>http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet 
>>>>>submitted it to IETF, pending the outcome of this discussion.
>>>>>
>>>>>Our current intention is to withdraw this document from PKIX 
>>>>>consideration, and finish it up within GGF.  (The previous 
>>>>>draft-ietf-pkix-proxy-02 expires this month.)  However, if there is a 
>>>>>public ground swell to complete it within PKIX, we are happy to reconsider.
>>>>>
>>>>>Meanwhile, this draft is currently in last-call in the GGF GSI working 
>>>>>group, prior to submitting it for consideration to become a GFD.  We 
>>>>>would be happy to receive and incorporate feedback to the latest GGF 
>>>>>draft (see above URL), prior to the final submission (hopefully within 
>>>>>in a couple weeks).
>>>>>
>>>>>Thanks,
>>>>>-Steve
>>>>>------------------------------------------------------------------------
>>>>>Steve Tuecke           MCS, Bldg 221, Office B-159  work: (630) 252-8711
>>>>>[email-masked]     Argonne National Laboratory  cell: (630) 842-6917
>>>>>http://www.mcs.anl.gov/~tuecke  Argonne, IL 60439   fax: (630) 252-5986

Date: Thu, 29 Aug 2002 15:15:39 -0500 (CDT)
From: Eric Norman <[email-masked]>
To: PKIX list <[email-masked]>
Subject: Re: subject DN vs. directory DN
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---2140662931-1560634988-1030652140=:16382
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 29 Aug 2002, Jari Pirhonen wrote:

> What do the standards say about certificate subject DN matching the
> directory object DN?

There are more than standards involved.  For educational institutions
here in the US, FERPA regulations apply too.  This means that if a
student exercises her FERPA "opt out" rights, then there is information
that you can't have in the DN in a publically available directory.

The way we do this here at Wisconsin is to only include a bunch of
random gibberish in the directory DN as an identifier.  If you're
authorized, then you can use that gibberish to get attributes that
wouldn't normally be available to the whole world.  Furthermore,
it changes daily; that has interesting ramifications as far as
X.509 certificates and their DNs are concerned.

Eric Norman

		"I may be just a butterfly,
		 but watch out if I flap my wings".

---2140662931-1560634988-1030652140=:16382
Content-Type: APPLICATION/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: BASE64
Content-Description: S/MIME Cryptographic Signature
Content-Disposition: attachment; filename="smime.p7s"

---2140662931-1560634988-1030652140=:16382--

Date: Thu, 29 Aug 2002 21:20:37 +0300
From: Jari Pirhonen <[email-masked]>
Reply-To: [email-masked]
Organization: AtBusiness
To: [email-masked]
Subject: subject DN vs. directory DN
Sender: [email-masked]

Hi,

What do the standards say about certificate subject DN matching the
directory object DN?

I have seen some applications, which seem to use certificate subject as
a *searchbase* to the directory, when fetching additional info. I have
heard comments that subject and directory DN *must* match. To me it
seems to be quite a tough requirement. Especially when the organization
has built the corporate directory before implementing the PKI. This
requirement could mean that  either current directory DN must be used as
a certificate subject, which may lead to quite weird subjects or DIT
must be changed according to planned certificate subject, and this may
break some directory applications. One choice of course would be to
separate PKI and corporate directories and sync data as needed.

Example.

Let's say that for some good the company has decided to use the
following DN to store directory objects: "employeeNumber=123, ou=us,
ou=people,o=company" (has attribute "cn=John Smith 123" among others).
Now, when PKI is implemented, certificate subject like "cn=John Smith
123, o=Company"  is wanted.

Are the vendors, who say that this "breaks" the standard, correct?

I have also seen applications, which are sophisticated enough to search
"cn=John Smith 123" using "ou=people,o=company"  as a searchbase, to
fetch an "uid", for example.

regards,
Jari Pirhonen

Date: Thu, 29 Aug 2002 11:03:42 -0500
From: "William I. Bormann" <[email-masked]>
Reply-To: [email-masked]
To: EKR <[email-masked]>
CC: David Hopwood <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Wildcard certificates
Sender: [email-masked]

Eric Rescorla wrote:

>David Hopwood <[email-masked]> writes:
>  
>
>>RFC 2818 is very clear about this:
>>
>>   Matching is performed using the matching rules specified by
>>   [RFC2459].  If more than one identity of a given type is present in
>>   the certificate (e.g., more than one dNSName name, a match in any one
>>   of the set is considered acceptable.) Names may contain the wildcard
>>   character * which is considered to match any single domain name
>>   component or component fragment. E.g., *.a.com matches foo.a.com but
>>   not bar.foo.a.com. f*.com matches foo.com but not bar.com.
>>    
>>
>Note that RFC 2818 is Informational.
>
>As Steve Kent points out, dNSNames cannot contain *s. However, since
>CN is the standard place to put the DNS name (much to everyone's
>unhappiness) they often contain *s. Don't know if anyone actually
>uses dNSName for this.
>
>  
>
>>Arguably this is specified in the wrong place, though, since it should
>>apply to any TLS profile that uses PKIX certificates and where the server
>>is likely to have a DNS name. That includes at least RFCs 2487, 2595, 2716
>>and 2817, so it would probably be better just to specify it once and for
>>all in 2246bis.
>>    
>>
>Oh boy. ISTR that there was a lot of argument about even using
>opaque DNS names as extensions. I suspect that defining semantics
>for DNS names in TLS would be contentious.
>
>-Ekr
>
>  
>
A couple of things I think are clear from 3280 (pkix certificate and crl 
profile):

1.   Using dc in place of cn is probably the more correct approach to 
naming the subject of a server certificate, viz., for *.foo.bar.com, use 
dc=*,dc=foo,dc=bar,dc=com instead of cn=*.foo.bar.com.
2.  In the SubjectAltName field you can stick multiple DNS components as 
alternative names for the server.  In my mind, this is the more sensible 
approach, as I'm not too comfortable with using the wildcard approach 
when it comes to more than one system sharing the same certificate.

A question:  has any thought been given to allowing DNS names of the format:

.foo.bar.com

in SubjectAltName?  The matching rules would be analogous to that 
specified for NameConstraints URI?  Does this make any sense?

Bill Bormann
Technical Consultant
Purdue University

Date: Wed, 28 Aug 2002 21:53:34 -0400
From: Sam Schaen <[email-masked]>
Organization: The MITRE Corporation
To: carol <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Ocsp Responder and AuthorityInfoAccessSyntax Question
Sender: [email-masked]

We've been wrestling with this same problem for the large U.S. DOD PKI, where the number of
responders could number in the hundreds.  Our current planned approach is to not use AIA,
but instead use the option of local configuration in the client to point to an optimal
responder.

I believe in your case 2, http://local would be used only when http://global was
unavailable.  I'm not sure your case 1 is a legal syntax.

It might also be possible to use a load balancer solution where the URI in the AIA is a
virtual name translated by the load balancer to your http://global and http://local URIs.

Sam Schaen

carol wrote:

> Hello everybody,
>
>    In our CA system, their are several ocsp responders. One can ask two ocsp responders
>    for the status of a certficate, for example http://global and http://local .
>    In such situation, what should be the AuthorityInfoAccess extension like?
>
>    case 1: only one AccessDescription node in AuthorityInfoAccessSyntax
>
>      AccessMethod  : id-at-ocsp
>      AccessLocation(URI): http://global;http://local
>
>    case 2: set two  AccessDescription nodes in AuthorityInfoAccessSyntax
>      AccessMethod  : id-at-ocsp
>      AccessLocation(URI): http://global
>
>      AccessMethod  : id-at-ocsp
>      AccessLocation(URI): http://local
>
>    Which of the above is more preferable? Or is there any standard/suggestion
>    for such situation?
>
>    Thanks a lot for any answer.
>
>  wcarol

Date: Thu, 29 Aug 2002 9:16:26 +0800
From: carol <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Ocsp Responder and AuthorityInfoAccessSyntax Question
Sender: [email-masked]

Hello everybody,

   In our CA system, their are several ocsp responders. One can ask two ocsp responders
   for the status of a certficate, for example http://global and http://local . 
   In such situation, what should be the AuthorityInfoAccess extension like?

   case 1: only one AccessDescription node in AuthorityInfoAccessSyntax

     AccessMethod  : id-at-ocsp
     AccessLocation(URI): http://global;http://local
   
   case 2: set two  AccessDescription nodes in AuthorityInfoAccessSyntax
     AccessMethod  : id-at-ocsp
     AccessLocation(URI): http://global

     AccessMethod  : id-at-ocsp
     AccessLocation(URI): http://local

   Which of the above is more preferable? Or is there any standard/suggestion
   for such situation?

   Thanks a lot for any answer.

 wcarol

Date: Thu, 29 Aug 2002 9:14:35 +0800
From: carol <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: 
Sender: [email-masked]

ietf-pkix Hello everybody,

   In our CA system, their are several ocsp responders. One can ask two ocsp responders
   for the status of a certficate, for example http://global and http://local . 
   In such situation, what should be the AuthorityInfoAccess extension like?

   case 1: only one AccessDescription node in AuthorityInfoAccessSyntax

     AccessMethod  : id-at-ocsp
     AccessLocation(URI): http://global;http://local
   
   case 2: set two  AccessDescription nodes in AuthorityInfoAccessSyntax
     AccessMethod  : id-at-ocsp
     AccessLocation(URI): http://global

     AccessMethod  : id-at-ocsp
     AccessLocation(URI): http://local

   Which of the above is more preferable? Or is there any standard/suggestion
   for such situation?

   Thanks a lot for any answer.

 wcarol

To: David Hopwood <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Wildcard certificates
Reply-to: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: 28 Aug 2002 17:56:08 -0700
Lines: 31
Sender: [email-masked]

David Hopwood <[email-masked]> writes:
> RFC 2818 is very clear about this:
> 
>    Matching is performed using the matching rules specified by
>    [RFC2459].  If more than one identity of a given type is present in
>    the certificate (e.g., more than one dNSName name, a match in any one
>    of the set is considered acceptable.) Names may contain the wildcard
>    character * which is considered to match any single domain name
>    component or component fragment. E.g., *.a.com matches foo.a.com but
>    not bar.foo.a.com. f*.com matches foo.com but not bar.com.
Note that RFC 2818 is Informational.

As Steve Kent points out, dNSNames cannot contain *s. However, since
CN is the standard place to put the DNS name (much to everyone's
unhappiness) they often contain *s. Don't know if anyone actually
uses dNSName for this.

> Arguably this is specified in the wrong place, though, since it should
> apply to any TLS profile that uses PKIX certificates and where the server
> is likely to have a DNS name. That includes at least RFCs 2487, 2595, 2716
> and 2817, so it would probably be better just to specify it once and for
> all in 2246bis.
Oh boy. ISTR that there was a lot of argument about even using
opaque DNS names as extensions. I suspect that defining semantics
for DNS names in TLS would be contentious.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

Date: Wed, 28 Aug 2002 22:01:25 +0000
From: David Hopwood <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Wildcard certificates
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

[[email-masked] added]

Eric Norman <[email-masked]> wrote on ietf-pkix:
> On Wed, 28 Aug 2002, Stefan Santesson wrote:
> > I wonder if anyone on this list have experience/opinions on using wildcard
> > names in SSL server certificates.
[...]
>
> We did some experimentation a few years ago with a mail server that needs
> to support lots of different domains.  We found that wildcards work with
> both Netscape and IE browsers.  However, there is a difference in whether
> a wildcard can span a dot or not.  That is, in one browser (I think it's
> Netscape-Mozilla) *.wisc.edu will match a.b.wisc.edu; in the other,
> you need *.*.wisc.edu to match.  We got around this minor inconvenience
> by using two different IP numbers.

RFC 2818 is very clear about this:

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Arguably this is specified in the wrong place, though, since it should
apply to any TLS profile that uses PKIX certificates and where the server
is likely to have a DNS name. That includes at least RFCs 2487, 2595, 2716
and 2817, so it would probably be better just to specify it once and for
all in 2246bis.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

Date: Wed, 28 Aug 2002 19:33:19 -0400
To: Laurence Lundblade <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Wildcard certificates
Cc: <[email-masked]>
Sender: [email-masked]

At 9:49 AM -0700 8/28/02, Laurence Lundblade wrote:
>	<SNIP>
>
>>Talking to Steve Kent in Yokohama, he implied that this practice is against
>>current standards (but I can't recall how) and that it is known to create
>>problems in certain environments.
>
>Not sure what standard that would be. My understanding is that PKIX 
>doesn't necessarily apply to SSL, or at least no one has written 
>down how it applies. Also don't recall running into standard, PKIX 
>or other, that says how the CN should be matched to the hostname.
>
>LL

RFC 3280 defines what characters can appear in a DNS name appearing 
in the subject alternative name (by reference to RFC 1034), which is 
one of the two places that the server name might appear. The "*" 
character is not allowed there, and this is the preferred location in 
a cert for a DNS name.

The other alternative for DNS name representation defined by 3280 is 
to put the server DNS name into a DN as a series of domain 
components, and that too would preclude use of a "*" in the name.

What is often done by our beloved TTPs, is to represent a server DNS 
name as a common name, in what is clearly a bastardized use of a DN. 
This is not consistent with PKIX standards. I'm not familiar with any 
limitations on the use of "*" in a common name, but I think it fair 
to say that it is not within the realm of what X.500 envisioned for 
CNs.

This is the basis for my comment to Stefan.

Steve

From: "roy applebuim" <[email-masked]>
To: [email-masked]
Subject: Encryption Question
Date: Wed, 28 Aug 2002 22:26:05 +0000
Sender: [email-masked]

Hello everybody,

This might be a bit off topic, but I would be happy if you can answer my 
questions:

If I have a 1k bit string that I need to encrypt with a 128 bit key and then 
place it on a smart card,

1. How is it being done (public and private keys) ?
2. What would be the size of the encrypted string (1k not encrypted) ?
3. What key does my reader (Local or remote) must have, in order to decrypt 
the original 1k string ?

Thanks a lot for,

Roy Applebuim

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Date: Wed, 28 Aug 2002 13:36:15 -0400
From: "David A. Cooper" <[email-masked]>
Reply-To: [email-masked]
Organization: NIST
To: Laurence Lundblade <[email-masked]>
CC: Stefan Santesson <[email-masked]>, [email-masked]
Subject: Re: Wildcard certificates
Sender: [email-masked]

Laurence Lundblade wrote:

>> Talking to Steve Kent in Yokohama, he implied that this practice is 
>> against
>> current standards (but I can't recall how) and that it is known to 
>> create
>> problems in certain environments.
>
> Not sure what standard that would be. My understanding is that PKIX 
> doesn't necessarily apply to SSL, or at least no one has written down 
> how it applies. Also don't recall running into standard, PKIX or 
> other, that says how the CN should be matched to the hostname.

I don't know how products handle wildcards, but I did take a quick look 
to try to determine what the relevant standards might be:

1) Section 3.1 of RFC 2818 (HTTP Over TLS) specifies how to match the 
identity of a server to the information in a certificate. It specifies 
that the identity may either be in the dNSName component of 
subjectAltName or a common name component of the subject name (CAs are 
encouraged to put the DNS information in the dNSName component of 
subjectAltName). The specification includes a description of wildcard 
matching.

2) Section 4.2.1.7 of RFC 3280 specifies that the dNSName component of 
subjectAltName MUST be in the "preferred name syntax," as specified by 
RFC 1034.

3) RFC 1034 states that in the preferred name syntax, the "*" character 
is not allowed. Combining this with RFC 3280 means that names with a 
wildcard should only be placed in the common name component of the 
subject field.

Dave

From: Kefeng Chen <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, [email-masked]
Subject: RE: Wildcard certificates
Date: Wed, 28 Aug 2002 13:20:48 -0400
Sender: [email-masked]

Both Microsoft IE browser and Netscape browser
accept wild card SSL server certificate.
Microsoft IE has more strict rules on accepting wild card
cert than Netscape browser.

-Kefeng

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Wednesday, August 28, 2002 8:49 AM
To: [email-masked]
Subject: Wildcard certificates

I wander if anyone on this list have experience/opinions on using wildcard
names in SSL server certificates.

E.g. having the name *.domain.com  in one certificate instead of having
xxx.domain.com and secure.domain.com as common name in 2 separate
certificates.

Several CA service providers offer wildcard certificates on the market
today.

Talking to Steve Kent in Yokohama, he implied that this practice is against
current standards (but I can't recall how) and that it is known to create
problems in certain environments.

Are there any opinions on the list?

1) Is this braking any standards?
2) What environments have problems with wildcard certificates?
3) What are the problems?

/Stefan

Date: Wed, 28 Aug 2002 09:49:38 -0700
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: Wildcard certificates
Sender: [email-masked]

At 02:48 PM 8/28/2002 +0200, Stefan Santesson wrote:

>I wander if anyone on this list have experience/opinions on using wildcard
>names in SSL server certificates.
>
>E.g. having the name *.domain.com  in one certificate instead of having
>xxx.domain.com and secure.domain.com as common name in 2 separate
>certificates.

I've only ever seen "*" in a cert, but Netscape implements a fairly full 
form of regular expressions. The source is available in Mozilla, though I 
think it has a few bugs in the more esoteric nested expressions.

>Several CA service providers offer wildcard certificates on the market
>today.

I think an SSL implementation that didn't handle the wild cards, at least 
*, would have problems operating against many SSL sites. I haven't checked 
the IE, but I expect it does it or Thawte wouldn't be able to issue the 
certs it does.

>Talking to Steve Kent in Yokohama, he implied that this practice is against
>current standards (but I can't recall how) and that it is known to create
>problems in certain environments.

Not sure what standard that would be. My understanding is that PKIX doesn't 
necessarily apply to SSL, or at least no one has written down how it 
applies. Also don't recall running into standard, PKIX or other, that says 
how the CN should be matched to the hostname.

LL

Date: Wed, 28 Aug 2002 11:41:58 -0500 (CDT)
From: Eric Norman <[email-masked]>
To: [email-masked]
Subject: Re: Wildcard certificates
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---2140662931-503597828-1030552924=:16382
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 28 Aug 2002, Stefan Santesson wrote:

> I wander if anyone on this list have experience/opinions on using wildcard
> names in SSL server certificates.
>
> E.g. having the name *.domain.com  in one certificate instead of having
> xxx.domain.com and secure.domain.com as common name in 2 separate
> certificates.
>
> Several CA service providers offer wildcard certificates on the market
> today.
>
> Talking to Steve Kent in Yokohama, he implied that this practice is against
> current standards (but I can't recall how) and that it is known to create
> problems in certain environments.
>
> Are there any opinions on the list?
>
> 1) Is this braking any standards?
> 2) What environments have problems with wildcard certificates?
> 3) What are the problems?

We did some experimentation a few years ago with a mail server that needs
to support lots of different domains.  We found that wildcards work with
both Netscape and IE browsers.  However, there is a difference in whether
a wildcard can span a dot or not.  That is, in one browser (I think it's
Netscape-Mozilla) *.wisc.edu will match a.b.wisc.edu; in the other,
you need *.*.wisc.edu to match.  We got around this minor inconvenience
by using two different IP numbers.

Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".

---2140662931-503597828-1030552924=:16382
Content-Type: APPLICATION/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: BASE64
Content-Description: S/MIME Cryptographic Signature
Content-Disposition: attachment; filename="smime.p7s"

---2140662931-503597828-1030552924=:16382--

From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Subject: Wildcard certificates
Date: Wed, 28 Aug 2002 14:48:31 +0200
Importance: Normal
Sender: [email-masked]

I wander if anyone on this list have experience/opinions on using wildcard
names in SSL server certificates.

E.g. having the name *.domain.com  in one certificate instead of having
xxx.domain.com and secure.domain.com as common name in 2 separate
certificates.

Several CA service providers offer wildcard certificates on the market
today.

Talking to Steve Kent in Yokohama, he implied that this practice is against
current standards (but I can't recall how) and that it is known to create
problems in certain environments.

Are there any opinions on the list?

1) Is this braking any standards?
2) What environments have problems with wildcard certificates?
3) What are the problems?

/Stefan

Date: Wed, 28 Aug 2002 00:24:27 -0500
To: "Housley, Russ" <[email-masked]>
From: Steve Tuecke <[email-masked]>
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Cc: [email-masked]
Sender: [email-masked]

Russ,

So how do we get there from here?

One fundamental obstacle may be that there are some PKIX participants who 
seem to be fundamentally opposed to the approach taken in the proxy cert 
profile.  Having had a number of conversations with such people, my belief 
is that it is likely an irreconcilable difference.  It seems to be more of 
a difference in world-view than in any specific technical detail -- they 
believe that using an end-entity certificate to sign proxy certificates is 
at fundamental odds with X.509 and PKIX philosophies.

But even if we are able to resolve this difference (e.g. either through 
finding an approach that we all agree on, or by agreeing to disagree but 
moving forward anyway), I guess its not clear to me how we overcome the 
energy barrier to advance it to an RFC.  There seems to be a general apathy 
within PKIX participants toward advancing this draft.  (And please realize 
that I am not faulting anybody by making this statement.  We all have our 
own agendas within PKIX, and it may just be that mine is too far off the 
radar for most.)

I'm completely comfortable with PKIX making a consensus decision that the 
Proxy Cert Profile should not be considered further in PKIX.  I'm also 
happy to push forward with it if there is support for doing so.  But given 
that it is currently languishing in PKIX, and that I don't see an obvious 
path toward reaching consensus in PKIX on this profile, I felt the most 
reasonable route was to suggest the withdrawal of the draft from PKIX.

-Steve

At 02:57 PM 8/27/2002, Housley, Russ wrote:
>Steve:
>
>I would like to see certificate handling libraries support the delegation 
>environment, and the people that write such libraries are currently paying 
>attention to the PKIX WG.  So, that is my preferred route.
>
>Russ
>
>At 02:05 PM 8/27/2002 -0500, Steve Tuecke wrote:
>>Russ,
>>
>>There are, of course, two avenues to RFC -- one through a working group, 
>>and the other as an individual submission.  I am curious what you think 
>>of each of these avenues, and more generally why you would prefer to see 
>>it published as an RFC.  For broad acceptability of the profile, the best 
>>route is obviously PKIX.  But if that doesn't happen, is there any value 
>>to it being an individually submitted informational RFC, in addition to a 
>>GGF (RFC-like) GFD?  (The GGF document process is pretty similar to IETF.)
>>
>>-Steve
>>
>>At 01:01 PM 8/27/2002, Housley, Russ wrote:
>>>Steve:
>>>
>>>I understand the need for you to make progress.  And, I will support any 
>>>pragmatic decision that you make.  However, I would prefer to see this 
>>>profile published as an RFC.
>>>
>>>Russ
>>>
>>>At 11:47 AM 8/27/2002 -0500, Steve Tuecke wrote:
>>>
>>>>All,
>>>>
>>>>In February 2001 we wrote a first draft of "Internet X.509 Public Key 
>>>>Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02) 
>>>>and introduced it into the Global Grid Forum (GGF, www.gridforum.org). 
>>>>Shortly after that, because it seemed to relate to the work in PKIX, we 
>>>>also introduced it into the PKIX working group.  Tim and Steve accepted 
>>>>this draft into PKIX and gave me time at several IETFs to present 
>>>>progress on this draft (for which we are most grateful!), which led to 
>>>>many useful discussions with IETF folks.  Over the past year and a 
>>>>half, we have continued to refine the draft as a result of this input 
>>>>and our own continuing work in this area.
>>>>
>>>>We are now trying to reach closure on this draft, so that various 
>>>>groups, including our Globus Project, can implement and deploy to a 
>>>>non-moving target.  There is strong support in the GGF Grid Security 
>>>>Infrastructure (GSI) working group to finalize the draft, and push it 
>>>>on to become a Grid Forum Document (GFD), which is GGF's equivalent of 
>>>>an RFC. However, within the PKIX community I think its fair to say that 
>>>>it has received little attention, and the reactions that have been 
>>>>expressed have been mixed -- everywhere from strong disagreement to 
>>>>strong support of the approach.
>>>>
>>>>We have a new, significantly cleaned up draft available at 
>>>>http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet 
>>>>submitted it to IETF, pending the outcome of this discussion.
>>>>
>>>>Our current intention is to withdraw this document from PKIX 
>>>>consideration, and finish it up within GGF.  (The previous 
>>>>draft-ietf-pkix-proxy-02 expires this month.)  However, if there is a 
>>>>public ground swell to complete it within PKIX, we are happy to reconsider.
>>>>
>>>>Meanwhile, this draft is currently in last-call in the GGF GSI working 
>>>>group, prior to submitting it for consideration to become a GFD.  We 
>>>>would be happy to receive and incorporate feedback to the latest GGF 
>>>>draft (see above URL), prior to the final submission (hopefully within 
>>>>in a couple weeks).
>>>>
>>>>Thanks,
>>>>-Steve
>>>>------------------------------------------------------------------------
>>>>Steve Tuecke           MCS, Bldg 221, Office B-159  work: (630) 252-8711
>>>>[email-masked]     Argonne National Laboratory  cell: (630) 842-6917
>>>>http://www.mcs.anl.gov/~tuecke  Argonne, IL 60439   fax: (630) 252-5986

Date: Tue, 27 Aug 2002 16:38:17 -0700
To: (many IETF mailing lists)
From: Paul Hoffman / IMC <[email-masked]>
Subject: Nomcom call for volunteers
Sender: [email-masked]

Forwarded for Phil Roberts <[email-masked]>:

The members of the IESG and IAB and the IETF chair are selected
by a nominations committee made up of volunteers from the
IETF community.  The nominations committee is now in the process
of being formed and volunteers are being accepted until Sep 6.
Please see (http://www.ietf.org/nomcom/msg19765.html)
for information if you are interested in volunteering
to be on the nominations committee.

From: "Housley, Russ" <[email-masked]>
To: Steve Tuecke <[email-masked]>
Cc: Steve Tuecke <[email-masked]>, [email-masked]
Date: Tue, 27 Aug 2002 15:57:22 -0400
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Steve:

I would like to see certificate handling libraries support the delegation 
environment, and the people that write such libraries are currently paying 
attention to the PKIX WG.  So, that is my preferred route.

Russ

At 02:05 PM 8/27/2002 -0500, Steve Tuecke wrote:
>Russ,
>
>There are, of course, two avenues to RFC -- one through a working group, 
>and the other as an individual submission.  I am curious what you think of 
>each of these avenues, and more generally why you would prefer to see it 
>published as an RFC.  For broad acceptability of the profile, the best 
>route is obviously PKIX.  But if that doesn't happen, is there any value 
>to it being an individually submitted informational RFC, in addition to a 
>GGF (RFC-like) GFD?  (The GGF document process is pretty similar to IETF.)
>
>-Steve
>
>At 01:01 PM 8/27/2002, Housley, Russ wrote:
>>Steve:
>>
>>I understand the need for you to make progress.  And, I will support any 
>>pragmatic decision that you make.  However, I would prefer to see this 
>>profile published as an RFC.
>>
>>Russ
>>
>>At 11:47 AM 8/27/2002 -0500, Steve Tuecke wrote:
>>
>>>All,
>>>
>>>In February 2001 we wrote a first draft of "Internet X.509 Public Key 
>>>Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02) and 
>>>introduced it into the Global Grid Forum (GGF, 
>>>www.gridforum.org).  Shortly after that, because it seemed to relate to 
>>>the work in PKIX, we also introduced it into the PKIX working 
>>>group.  Tim and Steve accepted this draft into PKIX and gave me time at 
>>>several IETFs to present progress on this draft (for which we are most 
>>>grateful!), which led to many useful discussions with IETF folks.  Over 
>>>the past year and a half, we have continued to refine the draft as a 
>>>result of this input and our own continuing work in this area.
>>>
>>>We are now trying to reach closure on this draft, so that various 
>>>groups, including our Globus Project, can implement and deploy to a 
>>>non-moving target.  There is strong support in the GGF Grid Security 
>>>Infrastructure (GSI) working group to finalize the draft, and push it on 
>>>to become a Grid Forum Document (GFD), which is GGF's equivalent of an 
>>>RFC. However, within the PKIX community I think its fair to say that it 
>>>has received little attention, and the reactions that have been 
>>>expressed have been mixed -- everywhere from strong disagreement to 
>>>strong support of the approach.
>>>
>>>We have a new, significantly cleaned up draft available at 
>>>http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet submitted 
>>>it to IETF, pending the outcome of this discussion.
>>>
>>>Our current intention is to withdraw this document from PKIX 
>>>consideration, and finish it up within GGF.  (The previous 
>>>draft-ietf-pkix-proxy-02 expires this month.)  However, if there is a 
>>>public ground swell to complete it within PKIX, we are happy to reconsider.
>>>
>>>Meanwhile, this draft is currently in last-call in the GGF GSI working 
>>>group, prior to submitting it for consideration to become a GFD.  We 
>>>would be happy to receive and incorporate feedback to the latest GGF 
>>>draft (see above URL), prior to the final submission (hopefully within 
>>>in a couple weeks).
>>>
>>>Thanks,
>>>-Steve
>>>------------------------------------------------------------------------
>>>Steve Tuecke           MCS, Bldg 221, Office B-159  work: (630) 252-8711
>>>[email-masked]     Argonne National Laboratory  cell: (630) 842-6917
>>>http://www.mcs.anl.gov/~tuecke   Argonne, IL 60439   fax: (630) 252-5986

Date: Tue, 27 Aug 2002 14:05:11 -0500
To: "Housley, Russ" <[email-masked]>
From: Steve Tuecke <[email-masked]>
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Cc: Steve Tuecke <[email-masked]>, [email-masked]
Sender: [email-masked]

Russ,

There are, of course, two avenues to RFC -- one through a working group, 
and the other as an individual submission.  I am curious what you think of 
each of these avenues, and more generally why you would prefer to see it 
published as an RFC.  For broad acceptability of the profile, the best 
route is obviously PKIX.  But if that doesn't happen, is there any value to 
it being an individually submitted informational RFC, in addition to a GGF 
(RFC-like) GFD?  (The GGF document process is pretty similar to IETF.)

-Steve

At 01:01 PM 8/27/2002, Housley, Russ wrote:
>Steve:
>
>I understand the need for you to make progress.  And, I will support any 
>pragmatic decision that you make.  However, I would prefer to see this 
>profile published as an RFC.
>
>Russ
>
>At 11:47 AM 8/27/2002 -0500, Steve Tuecke wrote:
>
>>All,
>>
>>In February 2001 we wrote a first draft of "Internet X.509 Public Key 
>>Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02) and 
>>introduced it into the Global Grid Forum (GGF, 
>>www.gridforum.org).  Shortly after that, because it seemed to relate to 
>>the work in PKIX, we also introduced it into the PKIX working group.  Tim 
>>and Steve accepted this draft into PKIX and gave me time at several IETFs 
>>to present progress on this draft (for which we are most grateful!), 
>>which led to many useful discussions with IETF folks.  Over the past year 
>>and a half, we have continued to refine the draft as a result of this 
>>input and our own continuing work in this area.
>>
>>We are now trying to reach closure on this draft, so that various groups, 
>>including our Globus Project, can implement and deploy to a non-moving 
>>target.  There is strong support in the GGF Grid Security Infrastructure 
>>(GSI) working group to finalize the draft, and push it on to become a 
>>Grid Forum Document (GFD), which is GGF's equivalent of an RFC. However, 
>>within the PKIX community I think its fair to say that it has received 
>>little attention, and the reactions that have been expressed have been 
>>mixed -- everywhere from strong disagreement to strong support of the approach.
>>
>>We have a new, significantly cleaned up draft available at 
>>http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet submitted 
>>it to IETF, pending the outcome of this discussion.
>>
>>Our current intention is to withdraw this document from PKIX 
>>consideration, and finish it up within GGF.  (The previous 
>>draft-ietf-pkix-proxy-02 expires this month.)  However, if there is a 
>>public ground swell to complete it within PKIX, we are happy to reconsider.
>>
>>Meanwhile, this draft is currently in last-call in the GGF GSI working 
>>group, prior to submitting it for consideration to become a GFD.  We 
>>would be happy to receive and incorporate feedback to the latest GGF 
>>draft (see above URL), prior to the final submission (hopefully within in 
>>a couple weeks).
>>
>>Thanks,
>>-Steve
>>------------------------------------------------------------------------
>>Steve Tuecke           MCS, Bldg 221, Office B-159  work: (630) 252-8711
>>[email-masked]     Argonne National Laboratory  cell: (630) 842-6917
>>http://www.mcs.anl.gov/~tuecke   Argonne, IL 60439   fax: (630) 252-5986

From: "Housley, Russ" <[email-masked]>
To: Steve Tuecke <[email-masked]>
Cc: [email-masked]
Date: Tue, 27 Aug 2002 14:01:56 -0400
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Steve:

I understand the need for you to make progress.  And, I will support any 
pragmatic decision that you make.  However, I would prefer to see this 
profile published as an RFC.

Russ

At 11:47 AM 8/27/2002 -0500, Steve Tuecke wrote:

>All,
>
>In February 2001 we wrote a first draft of "Internet X.509 Public Key 
>Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02) and 
>introduced it into the Global Grid Forum (GGF, 
>www.gridforum.org).  Shortly after that, because it seemed to relate to 
>the work in PKIX, we also introduced it into the PKIX working group.  Tim 
>and Steve accepted this draft into PKIX and gave me time at several IETFs 
>to present progress on this draft (for which we are most grateful!), which 
>led to many useful discussions with IETF folks.  Over the past year and a 
>half, we have continued to refine the draft as a result of this input and 
>our own continuing work in this area.
>
>We are now trying to reach closure on this draft, so that various groups, 
>including our Globus Project, can implement and deploy to a non-moving 
>target.  There is strong support in the GGF Grid Security Infrastructure 
>(GSI) working group to finalize the draft, and push it on to become a Grid 
>Forum Document (GFD), which is GGF's equivalent of an RFC. However, within 
>the PKIX community I think its fair to say that it has received little 
>attention, and the reactions that have been expressed have been mixed -- 
>everywhere from strong disagreement to strong support of the approach.
>
>We have a new, significantly cleaned up draft available at 
>http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet submitted 
>it to IETF, pending the outcome of this discussion.
>
>Our current intention is to withdraw this document from PKIX 
>consideration, and finish it up within GGF.  (The previous 
>draft-ietf-pkix-proxy-02 expires this month.)  However, if there is a 
>public ground swell to complete it within PKIX, we are happy to reconsider.
>
>Meanwhile, this draft is currently in last-call in the GGF GSI working 
>group, prior to submitting it for consideration to become a GFD.  We would 
>be happy to receive and incorporate feedback to the latest GGF draft (see 
>above URL), prior to the final submission (hopefully within in a couple weeks).
>
>Thanks,
>-Steve
>------------------------------------------------------------------------
>Steve Tuecke           MCS, Bldg 221, Office B-159  work: (630) 252-8711
>[email-masked]     Argonne National Laboratory  cell: (630) 842-6917
>http://www.mcs.anl.gov/~tuecke   Argonne, IL 60439   fax: (630) 252-5986

Date: Tue, 27 Aug 2002 11:47:39 -0500
To: [email-masked]
From: Steve Tuecke <[email-masked]>
Subject: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

All,

In February 2001 we wrote a first draft of "Internet X.509 Public Key 
Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02) and 
introduced it into the Global Grid Forum (GGF, www.gridforum.org).  Shortly 
after that, because it seemed to relate to the work in PKIX, we also 
introduced it into the PKIX working group.  Tim and Steve accepted this 
draft into PKIX and gave me time at several IETFs to present progress on 
this draft (for which we are most grateful!), which led to many useful 
discussions with IETF folks.  Over the past year and a half, we have 
continued to refine the draft as a result of this input and our own 
continuing work in this area.

We are now trying to reach closure on this draft, so that various groups, 
including our Globus Project, can implement and deploy to a non-moving 
target.  There is strong support in the GGF Grid Security Infrastructure 
(GSI) working group to finalize the draft, and push it on to become a Grid 
Forum Document (GFD), which is GGF's equivalent of an RFC. However, within 
the PKIX community I think its fair to say that it has received little 
attention, and the reactions that have been expressed have been mixed -- 
everywhere from strong disagreement to strong support of the approach.

We have a new, significantly cleaned up draft available at 
http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet submitted it 
to IETF, pending the outcome of this discussion.

Our current intention is to withdraw this document from PKIX consideration, 
and finish it up within GGF.  (The previous draft-ietf-pkix-proxy-02 
expires this month.)  However, if there is a public ground swell to 
complete it within PKIX, we are happy to reconsider.

Meanwhile, this draft is currently in last-call in the GGF GSI working 
group, prior to submitting it for consideration to become a GFD.  We would 
be happy to receive and incorporate feedback to the latest GGF draft (see 
above URL), prior to the final submission (hopefully within in a couple weeks).

Thanks,
-Steve
------------------------------------------------------------------------
Steve Tuecke           MCS, Bldg 221, Office B-159  work: (630) 252-8711
[email-masked]     Argonne National Laboratory  cell: (630) 842-6917
http://www.mcs.anl.gov/~tuecke   Argonne, IL 60439   fax: (630) 252-5986

From: "L Williams" <[email-masked]>
To: <[email-masked]>
Subject: Try Again: Where does one specify PKI Path?
Date: Mon, 26 Aug 2002 20:00:52 -0700
Sender: [email-masked]

The June 22, 2002 draft of the LDAP schema and Syntaxes for PKIs specifies
the pkiPath attribute. Is the intent to add or define an accessMethod OID
for Authority Information Access to point to this attribute? If not, how
will it be used?

 -Laudon

Date: Mon, 26 Aug 2002 12:32:59 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-warranty-ext-01
Sender: [email-masked]

Lynn,

You are very right with your explanations.

... and this is why I do not believe that this extension proposal is useful.

Denis 
 
> somewhat aside, note that most financial risk management has moved past
> stale, static data ... even on a per transaction basis .... since the
> exploits/attacks on such infrastructures started using aggregation. the
> old-style "signing limit" checks attempted to manage risk & liability on a
> per transaction basis .... but quickly found that they were extremely
> vulnerable to aggregation risks. That is one of the forces leading to
> online operation in the financial industry (as opposed to an offline
> operation with trivial per transaction limits and no support for online
> management of aggregation).
> 
> A similar model might be various kinds of automobile insurance with per
> transaction limits .... however any aggregation risks tend to happen over a
> long enough period that processing tends to occur in "relative" real time
> (and they have been able to manage aggregation risks ... if nothing else by
> canceling the policy).
> 
> The problem for the insurance industry is given the alternatives between an
> offline paradigm and an online paradigm .... where the offline paradigm
> with basically per transaction limits .... and an online paradigm that can
> handle both per transaction and aggregation limits .... the offline
> paradigm leaves them wide-open to aggregation attacks/risks.  The problem
> for a certificate is that the policy & representation is static per
> transaction risk/limit ... and any migration to an offline paradigm with
> both support for per transaction as well as aggregation risk/limits
> obsoletes the requirement for the certificate.
> 
> Somewhat analogous is the hardware token (as a credential) ... when used
> purely in an offline mode, there have been  all sorts of aggregation risk.
> Typically the remedial action is to limit the per transaction exposure to a
> very trivial dollar value .... as a mechanism for attempting to bound the
> aggregation risk/exposure.
> 
> The problem for an indusrance industry risk managing in establishing policy
> rates .... isn't the per transaction limit risk .... but what is the worst
> case risk scenario for an offline paradigm with regard to transaction
> aggregation. The certificate doesn't contain a dynamic transaction count
> and/or any sort of dynamic value aggregation .... and/or even idea of how
> many times it has been used ... which is the unknown exposure facing the
> risk manager having to establish policy rates aka when they look at the
> risk exposure for establishing insurance rates .... it is the total risk
> exposure. A single per event bound doesn't tell them anything unless they
> can also put a reasonable bound on the maximum number of such events ....
> to arrive at the total risk.

Date: Mon, 26 Aug 2002 12:02:26 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: [email-masked]
Subject: Re: draft-ietf-pkix-warranty-ext-01
Sender: [email-masked]

Alice,

> Hi Denis, and others.

> Sorry to take so long reply but it took some time to digest all of your
> useful comments.

> Please see some of my responses in between yours.  I have done a fair amount
> of cutting to keep this thread from growing out of control, and inserted
> identifying initials in [ ] i.e., my original comments are [AS1]; yours
> Denis are [DP]; my responses today are [AS2].  Seems complex?  Intent is to
> make it easier to read.
> 
> Thanks.
> Alice Sturgeon
> Chair Canadian Advisory Committee - Information Technology Security
> ISO/IEC JTC1 SC 27
> and
> System Policy Architect SPYRUS
> 
> -----Original Message-----
>  Sent: July 31, 2002 11:13 AM
>  Subject: Re: draft-ietf-pkix-warranty-ext-01
> 
> [AS1] Issue # 1:  Should the warranty be an aspect of certification policy?
> If so, policy qualifiers would indicate the amount of coverage.  The reason
> for a warranty program is that a CA is not an insurance company and
> therefore cannot issue a policy of insurance in favor of the subscriber.

> [DP] Whether or not the insurance is direct or subcontracted is not the main
> point. The insurance is provided by the CA because the CA pays for it.

> [AS2] Agree. The insurance is provided by the CA through its insurer. The CA
> pays its insurer. The cost of insurance might or might not be passed on to
> subscribers; that would be a business decision on the part of the CA.

> [AS1] The CA will take out a certificate insurance policy with a licensed
> insurance company.  Different certificates will have different certificate
> policies and therefore will have a different risk profile.

> [DP] Since the certificate policy describes ALL aspects of the policy, if
> two certificates have the same CP then they have the same insurance and
> warranty limits. As RFC 3280 states: "Optional qualifiers, which MAY be
> present, are not expected to change the definition of the policy".

> [AS2] Agree. I think I did not word this properly.  Obviously, if two
> certificates have the same CP, then of course they have the same insurance
> coverage (assuming, as we do (as noted above) that the CA implementing the
> CP in certificates is providing the insurance to RPs through its (the CA's)
> insurer).

> [AS1] The insurance company will cover each certificate and type of
> certificate issued.  Hence the insurance company will sit behind the
> operations of the CA to cover the extended warranty program.  There will be
> a contractual relationship between the CA and  the subscriber, likely
> through the use of a Subscriber Agreement.  With respect to the relying
> party, the subscriber, if the subscriber opts for the extended warranty, has
> the opportunity to extend the financial trust relationship between them.  A
> relying party in encountering a certificate warranty program will know that
> an insurance company is covering the CA for any claims that fit within the
> warranty program.

> [DP] "any claims that fit within the warranty program". This is not
> understandable or machine processable. This is not visible in the warranty
> amount but this is even more important than the amount. So it is very
> questionable why the amount should be made visible and machine processable
> whereas the conditions of the warranty are not. I am not saying that it
> should be done visible as well, but this is more an argument to say that the
> amount only is quite insufficient.

> [AS2] In most cases, the amount will be sufficient to instill confidence in
> the transaction and to enable it to progress.  That's the basic intent of
> the proposed extension - building confidence in e-business. Again, perhaps
> my wording was misleading - I could have said, "for any claims that do not
> exceed the maximum amount as shown in 'currency amount' in the certificate".
> Is that more understandable?  It would be machine processable.
> CurrencyAmount  ::=  SEQUENCE  {
>        currency             INTEGER (1..999),
>        amount               INTEGER (0..MAX),

This still does not solve my concern. While, as you say, the basic intent of
the proposed extension is building confidence in e-business, in reality it
would build a FALSE confidence in e-busines, then doing more harm that
benefits. I disagree that processing only the amount field allows to build
confidence. The warranty conditions cannot be ignored, but cannot be easily
processed. The only field that is easily processable is the CP. A RP can
easily perfom an equality check on it.

But the real problem is worse. Incorporating static warranty conditions in a
certificate is not appropriate or would be appropriate only if there would
be some kind of on-line check done afterwards. The information would only be
used, to know whether or not it makes sense to do perform an on-line check
or not (and where). However, this is not the meaning of the proposed
extension.

Therefor I still object about the benefits of that extension.

Regards,

Denis

Date: Mon, 26 Aug 2002 11:59:45 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Laurence Lundblade <[email-masked]>
CC: Sharon Boeyen <[email-masked]>, "'Housley, Russ'" <[email-masked]>, [email-masked]
Subject: Re: Basic constraints processing for SSL
Sender: [email-masked]

Laurence,

[Sharon]

> > Just to add the X.509 voice to this discussion. With respect to the self
> > signed certificates, the statement made by Russ below was reinforced
> > some time ago through the processing of a defect report (DR) against the
> > base X.509 standard. As a result of that DR, the following sentence was
> > added to 12.4.3 of X.509:
> >
> > "Self-signed certificates, if encountered in the path, are ignored."
 
> So does this mean that the validity dates in trusted roots and/or
> self-signed certs are to be ignored, or is this part of a distinct trust
> anchor validation process? It seems like a bad thing to ignore the
> validity dates in trust anchors.

I fully agree. A self-signed certificate needs to include a validity period
otherwise it would not be a certificate !

So, if a self-signed certificate is used as a trust anchor, the validity
period cannot be ignored.

Now, if a self-signed certificate is NOT used as a trust anchor, it would
still make sense to add a validity period to the three current elements:

 - CA name,
 - PK algo and value, 
 - PK parameters.

> Similarly, does that mean the pathLen part of BasicConstraints should be
> ignored during path validation? The 3rd paragraph of section 6 in RFC 3280
> sort of implies that trusted roots aren't entirely ignored when it says
> "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". 

Path length is certainly a value that some CAs want to constrain, whatever
the local additional conditions of the RP may be.

To summarize, validity period has always to be considered.
Path length is to be considered if present in a self-signed certificate.

> 21 of the root certs in IE have pathLen. The value varies from 1 to
> 10.
> 
> I'm still having trouble with the term "CA certificate". Sort of seems
> like everyone knows what it is but me :-).  So if I pretend I have a "CA
> certificate" in my pocket, what do I have?

> a) A trust anchor (but not necessarily self-signed)

No. A trust anchor is not a certificate. 

> b) A self signed cert

Yes.

> c) A cert that's NOT an end entity

We do not have that kind of distinction. We can however know that a
certificate belongs to a CA, using the basic constraints extension.  

> d) An intermediate/branch cert (which obviously can't be self signed)

Yes.

> e) One with the CA=TRUE in BasicConstraints 

Yes.

> (if so can a cert without BasicConstraints ever be a "CA certificate")

No.

> f) Some combination of the above

No.
 
> Dean made the comment that it doesn't say what to do when BasicConstraints
> aren't present. 

RFC 3280 states:

   This extension MUST appear as a critical extension in all CA
   certificates that contain public keys used to validate digital
   signatures on certificates.  This extension MAY appear as a critical
   or non-critical extension in CA certificates that contain public keys
   used exclusively for purposes other than validating digital
   signatures on certificates. 

I would recognize that I do not recall the reason for the MAY. :-)

Denis

> This was generally (not just BasicConstraings) the
> difficult part - when the certs you get diverge from the standards and you
> know you have to process them. Adding that sort of text to the document
> (or a BCP document) would certainly be valuable.
> 
> LL

Date: Wed, 21 Aug 2002 09:48:48 -0700
From: Eric Murray <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Cc: phoffman <[email-masked]>, [email-masked]
Subject: Re: A  humour game
Sender: [email-masked]

On Tue, Aug 20, 2002 at 08:46:35PM -0700, Hallam-Baker, Phillip wrote:
> Before everyone piles onto Paul...
>  
> ... a couple of months ago I guy sent me a message accusing me of having
> sent him an email virus. Oddly enough the machine in question was turned
> off at the time and certainly disconnected from the net. Also the same
> guy had been sending me virus spam...
>  
> Basically the virus had been forging the from address on the @#$(*$
> message to cover its tracks.

This particular virus uses an old list of email addresses....
I have gotten a number of virus-generated emails "from" people
who long ago left the company they supposedly sent email from.
Some of them have been "from" Phil Karlton, who died in an accident
in 1996 or 1997.  

Since a lot of them are people I recognize from the security community who
were doing SSL stuff around 1996, I think that the virus writer snagged
addresses to forge from old archives of the ssl-talk or ietf-tls lists.

These days I look at the headers of any mail that looks suspicious
or wierd.

Eric

Date: Tue, 20 Aug 2002 21:55:14 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: "Manger, James H" <[email-masked]>
CC: [email-masked]
Subject: Re: PI DN: 00: comments
Sender: [email-masked]

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

"Manger, James H" wrote:
> 
> Nice work with draft-chadwick-pkix-pidn-00.txt.
> 
> 1.
> The PI-DN document (draft-chadwick-pkix-pidn-00.txt) suggests mapping a PI
> type to a subject name prefix.  This seems contrary to the main purpose of
> the PI document (draft-ietf-pkix-pi-05.txt), which is to have an identifier
> that is independent of most changes to the subject DN.

James

I see one of the purposes of the ID is to make subject DNs permanent (or
unchangeable) and this is therefore complementary to the PI document and
not contradictory to it.

> 
> The PI document (draft-ietf-pkix-pi-05.txt) does allow a PI type to be
> mapped to a DN, but it is to the issuer DN not the subject DN.

If one can do the former, then mapping to the latter should also be
possible, hence the new ID.

> 
> 2.
> The piAuth attribute is supposed to unambiguously identify an authority.
> The example in the document, piAuth=SSN, does NOT satisfy this property.  It
> is only unambiguous within the context of a sequence of dc=xxx attributes.

This is correct. This is because most PI authorities are subordinate to
some name space (mostly to country based ones, therefore they naturally
belong under C=xx or dc=xx, where xx is the 2 character country code).
If a PI authority is truly global/international in scope, then its
piAuth value can be the first RDN in the DN. But something like a driver
licencing authority cannot be a top level RDN, since every country in
the world has one of these.

> This is a serious limitation on allowed subject DNs.  [Additionally, not all
> URLs have a DNS name to convert to dc components]

Its true they could have an IP address instead. So I  should add a
mapping for these

> 
> 3.
> A subject DN includes (as prefixes) the DNs of its superiors in a naming
> hierarchy.  These other entities may have their own permanent identifiers so
> a DN may need to support different PIs in each RDN (e.g. a company number &
> an employee number).  Hence, a pi & piAuth pair should be in the same RDN.
>         cn=Tony + pi=1234 + piAuth=SSN, cn=Acme Inc + pi=789 + piAuth=DUNS,
> c=AU
> 
> If a pi & piAuth pair are attributes in an entry the only sensible way to
> incorporate then into DN is to include them in the same RDN.

Whilst I follow your argument I dont agree with its logic. A PI
authority and PI value form a natural hierarchy, and therefore naturally
lie one beneath the other in terms of a DN structure. So your example
above might more properly be written

cn=Tony + pi=1234, piAuth=SSN, cn= Acme Inc + pi=789, piAuth=DUNS
(finishing there, assuming DUNS numbers are globally unique and
international in scope, then c=AU would not be needed). However, is
there was only one Acme Inc in Australia (and there can ONLY EVER BE one
Acme Ltd in the UK as this is part of company registration), then o=Acme
inc, C=AU would be perfectly adequate to globally uniquely name the
company.

> 
> 4.
> Why not simply use the URI value as the piAuth value (instead of trying to
> split the URI into many attributes over multiple RDNs)?
>         pi=5445+piAuth=http://myorg.com/ssn
> 

I thought about this as one option. But as URIs are hierarchical anyway,
it seemed better to map these into DNs which are also hierarchical, and
therefore map between the elements of the hierarchies.

> 5.
> Using a string syntax (dotted decimal notation) to represent an OID in an
> ASN.1 type...  yuck.  This seems like a sure sign that something is wrong.
> 

(Aside. Well LDAP is full of that!!!.) But this would be the least
favoured option.

> 6.
> Perhaps we should use URNs: include the authority with the value in a single
> string.  (not sure about this)
> 

thanks for your comments

David

> --
> DN = distinguished name
> RDN = relative distinguished name
> PI = permanent identifier
> URI = uniform resource identifier
> DNS = domain name service
> OID = object identifier
> SSN = ?
> ASN.1 = abstract syntax notation
> 
> > ----------
> > From: [email-masked] [SMTP:[email-masked]]
> > Sent: Tuesday, 13 August 2002 9:27 pm
>         ..
> >       Title           : ..The use of Permanent Identifiers in LDAP
> > Distinguished Names
> >       Filename        : draft-chadwick-pkix-pidn-00.txt
>         ..
> > http://www.ietf.org/internet-drafts/draft-chadwick-pkix-pidn-00.txt
> >
> > -----
> > 2. Possible Alternative Mappings
> > i) SerialNumber=12345, PIAuth=DHSS, C=GB
> > ii) SerialNumber=12345, O=Department of Health and Social Security, C=GB
> > iii) PI=12345, O=Department of Health and Social Security, C=GB
> > iv) DHSSNo=12345, C=GB
> > v) PI=12345, PIAuth=DHSS, C=GB      [This is the approach recommended]
> > 4. PI Attributes
> > ( 1.2.826.0.1.3344810.1.1.34 NAME 'piAuth' SUP name )
> > ( 1.2.826.0.1.3344810.1.1.35 NAME 'pi' SUP name SINGLE-VALUE )
> > 5. Mapping suggestions
> > {5445,http://xmlns.nist.gov/ssn}--->
> > pi=5445,piAuth=ssn,dc=xlms,dc=nist,dc=gov
> > {5445,1.2.3.4.5}---> pi=5445,piAuth=SSN,dc=myorg,dc=com
> > {5445,1.2.3.4.5}---> pi=5445,piAuth=1.2.3.4.5

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------649CC47A3C9A457FB08CFD19
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------649CC47A3C9A457FB08CFD19--

From: "Hallam-Baker, Phillip" <[email-masked]>
To: phoffman <[email-masked]>, [email-masked]
Subject: RE: A  humour game
Date: Tue, 20 Aug 2002 20:46:35 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C248A3.CA290430
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000C_01C248A3.CA2C1170"

------=_NextPart_001_000C_01C248A3.CA2C1170
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Before everyone piles onto Paul...
 
... a couple of months ago I guy sent me a message accusing me of having
sent him an email virus. Oddly enough the machine in question was turned
off at the time and certainly disconnected from the net. Also the same
guy had been sending me virus spam...
 
Basically the virus had been forging the from address on the @#$(*$
message to cover its tracks.
 
Of course if Paul bothered to use a digital signature on his emails we
would know for sure...

-----Original Message-----
From: phoffman [mailto:[email-masked]]
Sent: Monday, July 08, 2002 11:29 PM
To: [email-masked]
Subject: A humour game

This is a special humour game
This game is my first work.
You're the first player.
I hope you would enjoy it. 

------=_NextPart_001_000C_01C248A3.CA2C1170
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 6.00.2716.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D557244303-21082002><FONT face=3DArial color=3D#0000ff =
size=3D2>Before=20
everyone piles onto Paul...</FONT></SPAN></DIV>
<DIV><SPAN class=3D557244303-21082002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D557244303-21082002><FONT face=3DArial color=3D#0000ff =
size=3D2>... a=20
couple of months ago I guy sent me a message accusing me of having sent =
him an=20
email virus. Oddly enough the machine in question was turned off at the =
time and=20
certainly disconnected from the net. Also the same guy had been sending =
me virus=20
spam...</FONT></SPAN></DIV>
<DIV><SPAN class=3D557244303-21082002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D557244303-21082002><FONT face=3DArial color=3D#0000ff =

size=3D2>Basically the virus had been forging the from address on the =
@#$(*$=20
message to cover its tracks.</FONT></SPAN></DIV>
<DIV><SPAN class=3D557244303-21082002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D557244303-21082002><FONT face=3DArial color=3D#0000ff =
size=3D2>Of=20
course if Paul bothered to use a digital signature on his emails we =
would know=20
for sure...</FONT></SPAN></DIV>
<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> phoffman=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, July 08, 2002 11:29=20
  PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> A humour=20
  game<BR><BR></FONT></DIV><FONT size=3D+0>This is a special humour =
game<BR>This=20
  game is my first work.<BR>You're the first player.<BR>I hope you would =
enjoy=20
  it.</FONT> </BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_000C_01C248A3.CA2C1170--

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

------=_NextPart_000_000B_01C248A3.CA290430--

From: "L Williams" <[email-masked]>
To: <[email-masked]>
Subject: Where does one specify PKI Path?
Date: Mon, 19 Aug 2002 21:07:15 -0700
Sender: [email-masked]

The June 22, 2002 draft of the LDAP schema and Syntaxes for PKIs specifies
the pkiPath attribute. Is the intent to add or define an accessMethod OID
for Authority Information Access to point to this attribute? If not, how
will it be used?

-Laudon

Date: Tue, 20 Aug 2002 14:27:03 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  PKIX OID arc
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

>and sure enough IANA sure enough has delegated the responsible for
>maintaining this OID arch to Russ.  This seems a bit odd to me.

It works fine, why mess with it?

Peter.

Date: Mon, 19 Aug 2002 11:41:17 -0700 (PDT)
From: Clifford Neuman <[email-masked]>
To: [email-masked]
Subject: CFP - Symposium on Network & Distributed Systems Security
Sender: [email-masked]

The Internet Society's (ISOC) annual Symposium on Network and Distributed
System Security (NDSS) brings together innovative and forward thinking
members of the Internet community including leading-edge security
researchers and implementers, globally-recognized security-technology
experts, and users from both the private and public sectors who design,
develop, exploit, and deploy the technologies that define network and
distributed system security.

If you are working on new and practical approaches to security problems
that are endemic to network and distributed systems, we invite you to
participate in NDSS'03 by submitting one or more technical papers and/or
panel proposals.  Submission details may be found at:

  http://www.isoc.org/isoc/conferences/ndss/03/cfp.shtml

NDSS'03 will again be held for three days in San Diego, California in
February, 2003.  One day of tutorials will be followed by two days of
technical sessions including refereed papers, invited talks, and panel
discussions and debates.

Please be aware that the NDSS'03 cut off date for paper and panel
submission is August 30, 2002.

All accepted papers will be published in The NDSS Proceedings by the
Internet Society.  There will also be an Outstanding Paper Award presented
at the Symposium to the author(s).  Submitted papers should not have been
previously published or be submitted simultaneously to a journal or to
another symposium or workshop with a published proceedings.

Please consider joining us at NDSS'03.  We look forward to hearing from you!

Clifford Neuman, 
Information Sciences Institute, University of Southern California
General Chair, NDSS'03 

Virgil Gligor, University of Maryland
Michael Reiter, Carnegie Mellon University
Program Chairs,  NDSS'03 

Date: Mon, 19 Aug 2002 09:58:34 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: PKIX OID arc
Sender: [email-masked]

I noticed on the IMC PKIX webpage (http://www.imc.org/ietf-pkix/):
  The official PKIX OID arc is maintained by Russ Housley and is
  reproduced here.

and sure enough IANA sure enough has delegated the responsible
for maintaining this OID arch to Russ.  This seems a bit odd
to me.  Official IETF registries should be maintained by IANA
under guidance established by the IETF.  Seems PKIX should
write a BCP which returns the registry function to IANA
and, if appropriate, recommend that new values be assigned
under an "Expert Review Required" policy.  The WG might
then recommend to the IESG that Russ be that expert.

Kurt

Subject: RE: draft-ietf-pkix-warranty-ext-01
To: <[email-masked]>
Cc: "Denis Pinkas" <[email-masked]>, [email-masked]
From: [email-masked]
Date: Fri, 16 Aug 2002 09:52:24 -0600
Sender: [email-masked]

somewhat aside, note that most financial risk management has moved past
stale, static data ... even on a per transaction basis .... since the
exploits/attacks on such infrastructures started using aggregation. the
old-style "signing limit" checks attempted to manage risk & liability on a
per transaction basis .... but quickly found that they were extremely
vulnerable to aggregation risks. That is one of the forces leading to
online operation in the financial industry (as opposed to an offline
operation with trivial per transaction limits and no support for online
management of aggregation).

A similar model might be various kinds of automobile insurance with per
transaction limits .... however any aggregation risks tend to happen over a
long enough period that processing tends to occur in "relative" real time
(and they have been able to manage aggregation risks ... if nothing else by
canceling the policy).

The problem for the insurance industry is given the alternatives between an
offline paradigm and an online paradigm .... where the offline paradigm
with basically per transaction limits .... and an online paradigm that can
handle both per transaction and aggregation limits .... the offline
paradigm leaves them wide-open to aggregation attacks/risks.  The problem
for a certificate is that the policy & representation is static per
transaction risk/limit ... and any migration to an offline paradigm with
both support for per transaction as well as aggregation risk/limits
obsoletes the requirement for the certificate.

Somewhat analogous is the hardware token (as a credential) ... when used
purely in an offline mode, there have been  all sorts of aggregation risk.
Typically the remedial action is to limit the per transaction exposure to a
very trivial dollar value .... as a mechanism for attempting to bound the
aggregation risk/exposure.

The problem for an indusrance industry risk managing in establishing policy
rates .... isn't the per transaction limit risk .... but what is the worst
case risk scenario for an offline paradigm with regard to transaction
aggregation. The certificate doesn't contain a dynamic transaction count
and/or any sort of dynamic value aggregation .... and/or even idea of how
many times it has been used ... which is the unknown exposure facing the
risk manager having to establish policy rates aka when they look at the
risk exposure for establishing insurance rates .... it is the total risk
exposure. A single per event bound doesn't tell them anything unless they
can also put a reasonable bound on the maximum number of such events ....
to arrive at the total risk.

Reply-To: <[email-masked]>
From: "Peter Hesse" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: certificate viewer for linux
Date: Fri, 16 Aug 2002 11:32:20 -0400
Importance: Normal
Sender: [email-masked]

Although I wasn't the individual that contacted Peter previously about this,
I figured I should go ahead and let everyone know that Gemini Security
Solutions has released a Windows GUI version of the DumpASN1 tool for free
download from our website.  It supports viewing, copy-paste, and printing of
any ASN.1 encoded object.

The application is available from
http://www.geminisecurity.com/guidumpasn.html and feedback is always
welcome.

--Peter

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Peter Gutmann
Sent: Wednesday, August 14, 2002 12:02 AM
To: [email-masked]; [email-masked]
Subject: Re: certificate viewer for linux

Geoffrey Elgey <[email-masked]> writes:

>Sorry, no GUI tools here, but I thought I would share some info on the two
>certificate dumping tools that I cannot live without.
>
>The first is Peter Guttman's dumpasn1 at
>http://www.cs.auckland.ac.nz/~pgut001/, which is excellent for checking
ASN.1
>values and offsets. Everyone should know about this.

There's a (Win32) GUI version of this being worked on by someone else, I'll
add
a link to it from my home page when it's released.

Peter.

Content-return: allowed
Date: Fri, 16 Aug 2002 07:22:42 -0700
From: Peter Williams <[email-masked]>
Subject: RE: Basic constraints processing for SSL
To: "'Laurence Lundblade '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Sender: [email-masked]

Laurence:

The contents and handling of certificate paths are an 
application protocol (e.g. https, ftps, frontpage/s, pops, pptp/s) 
matter,  not an X.509/PKIX   matter. The only thing X.509 is 
saying is that during the std procedure called "path processing" the
contents are processed according to the rules. This doesnt
mean other rules dont use the contents of paths, in parallel.
We all know how https has extra rules, concerning wild-cards
in cn name-forms, for example, that link association establishment
to a purported network identifer. We know some apps
should properly override the path processing results, when 
appropriate. ("sorry, FBI agent, you cant decrypt the 
terror notification, cos the user cert's been revoked" says
a bad civilian UA!)
 
Path processing is only one of the things we all do to
establish a security service. Scanning a list
of certs to enforce https rules or ensure "no obscene names",
is an application issue, for a kid-safe PKI tool perhaps; those 
rules are not something X.509 or PKIX should get involved in. 

Similarly, enabling an application cert path to
send arbitary certs in a path to pre-float a recipients
cache is quite a normal practice, from PEM days. Distributing 
well-known trust anchors via self-signed certs, is a similar 
acceptable practice. https praxis is what it is, and 
its simple mechanism for trust-anchor discovery and distriubtion
is remarkably effective, world wide today (thx to Microsoft 
CTL controls, mainly)

About the only time I can think that one might aim to deviates from
these https/PEM path principles is when the signed object has been
objectively notarized ; in which case the particular cert path that
the notary relies upon is a part of the acknowlegment that 
the notary agent performs  - to form the complete record of 
authentication. Cert paths and signatures are part 
of the "transmission data" of a message, legally; part of its 
"form" merely. A notary need not maintain in the record such data as 
received, when issuing an acknowledgement of identity,
based on verying the digital signature. The notary 
need only retain the sig and cert path (and trust anchor, and CTL) 
that was actually relied upon, discarding any other
superfluous tranmission data.

-----Original Message-----
From: Laurence Lundblade
To: Sharon Boeyen; 'Housley, Russ'
Cc: [email-masked]
Sent: 8/15/02 4:54 PM
Subject: RE: Basic constraints processing for SSL

At 11:11 AM 8/13/2002 -0400, Sharon Boeyen wrote:

Just to add the X.509 voice to this discussion. With respect to the self
signed certificates, the statement made by Russ below was reinforced
some time ago through the processing of a defect report (DR) against the
base X.509 standard. As a result of that DR, the following sentence was
added to 12.4.3 of X.509:

"Self-signed certificates, if encountered in the path, are ignored." 

So does this mean that the validity dates in trusted roots and/or
self-signed certs are to be ignored, or is this part of a distinct trust
anchor validation process? It seems like a bad thing to ignore the
validity dates in trust anchors.

Similarly, does that mean the pathLen part of BasicConstraints should be
ignored during path validation? The 3rd paragraph of section 6 in RFC
3280 sort of implies that trusted roots aren't entirely ignored when it
says "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". 21 of the root certs in IE have pathLen. The value varies
from 1 to 10.

I'm still having trouble with the term "CA certificate". Sort of seems
like everyone knows what it is but me :-).  So if I pretend I have a "CA
certificate" in my pocket, what do I have?
a) A trust anchor (but not necessarily self-signed)
b) A self signed cert
c) A cert that's NOT an end entity
d) An intermediate/branch cert (which obviously can't be self signed)
e) One with the CA=TRUE in BasicConstraints (if so can a cert without
BasicConstraints ever be a "CA certificate") 
f) Some combination of the above

Dean made the comment that it doesn't say what to do when
BasicConstraints aren't present. This was generally (not just
BasicConstraings) the difficult part - when the certs you get diverge
from the standards and you know you have to process them. Adding that
sort of text to the document (or a BCP document) would certainly be
valuable. 

LL

Reply-To: <[email-masked]>
From: "Alice Sturgeon" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-ietf-pkix-warranty-ext-01
Date: Fri, 16 Aug 2002 09:51:09 -0400
Importance: Normal
Sender: [email-masked]

Hi Denis, and others.
Sorry to take so long reply but it took some time to digest all of your
useful comments.
Please see some of my responses in between yours.  I have done a fair amount
of cutting to keep this thread from growing out of control, and inserted
identifying initials in [ ] i.e., my original comments are [AS1]; yours
Denis are [DP]; my responses today are [AS2].  Seems complex?  Intent is to
make it easier to read.

Thanks.
Alice Sturgeon
Chair Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect SPYRUS

-----Original Message-----
 Sent: July 31, 2002 11:13 AM
 Subject: Re: draft-ietf-pkix-warranty-ext-01

[AS1] Issue # 1:  Should the warranty be an aspect of certification policy?
If so, policy qualifiers would indicate the amount of coverage.  The reason
for a warranty program is that a CA is not an insurance company and
therefore cannot issue a policy of insurance in favor of the subscriber.
[DP] Whether or not the insurance is direct or subcontracted is not the main
point. The insurance is provided by the CA because the CA pays for it.
[AS2] Agree. The insurance is provided by the CA through its insurer. The CA
pays its insurer. The cost of insurance might or might not be passed on to
subscribers; that would be a business decision on the part of the CA.
[AS1] The CA will take out a certificate insurance policy with a licensed
insurance company.  Different certificates will have different certificate
policies and therefore will have a different risk profile.
[DP] Since the certificate policy describes ALL aspects of the policy, if
two certificates have the same CP then they have the same insurance and
warranty limits. As RFC 3280 states: "Optional qualifiers, which MAY be
present, are not expected to change the definition of the policy".
[AS2] Agree. I think I did not word this properly.  Obviously, if two
certificates have the same CP, then of course they have the same insurance
coverage (assuming, as we do (as noted above) that the CA implementing the
CP in certificates is providing the insurance to RPs through its (the CA's)
insurer).
[AS1] The insurance company will cover each certificate and type of
certificate issued.  Hence the insurance company will sit behind the
operations of the CA to cover the extended warranty program.  There will be
a contractual relationship between the CA and  the subscriber, likely
through the use of a Subscriber Agreement.  With respect to the relying
party, the subscriber, if the subscriber opts for the extended warranty, has
the opportunity to extend the financial trust relationship between them.  A
relying party in encountering a certificate warranty program will know that
an insurance company is covering the CA for any claims that fit within the
warranty program.
[DP] "any claims that fit within the warranty program". This is not
understandable or machine processable. This is not visible in the warranty
amount but this is even more important than the amount. So it is very
questionable why the amount should be made visible and machine processable
whereas the conditions of the warranty are not. I am not saying that it
should be done visible as well, but this is more an argument to say that the
amount only is quite insufficient.
[AS2] In most cases, the amount will be sufficient to instill confidence in
the transaction and to enable it to progress.  That's the basic intent of
the proposed extension - building confidence in e-business. Again, perhaps
my wording was misleading - I could have said, "for any claims that do not
exceed the maximum amount as shown in 'currency amount' in the certificate".
Is that more understandable?  It would be machine processable.
CurrencyAmount  ::=  SEQUENCE  {
       currency             INTEGER (1..999),
       amount               INTEGER (0..MAX),

From: "Housley, Russ" <[email-masked]>
To: Laurence Lundblade <[email-masked]>
Cc: Sharon Boeyen <[email-masked]>, [email-masked]
Date: Fri, 16 Aug 2002 09:26:54 -0400
Subject: RE: Basic constraints processing for SSL
Sender: [email-masked]

Laurence:

>>Just to add the X.509 voice to this discussion. With respect to the self 
>>signed certificates, the statement made by Russ below was reinforced some 
>>time ago through the processing of a defect report (DR) against the base 
>>X.509 standard. As a result of that DR, the following sentence was added 
>>to 12.4.3 of X.509:
>>
>>"Self-signed certificates, if encountered in the path, are ignored."
>
>So does this mean that the validity dates in trusted roots and/or 
>self-signed certs are to be ignored, or is this part of a distinct trust 
>anchor validation process? It seems like a bad thing to ignore the 
>validity dates in trust anchors.

The RFC does not require an implementor to use self-signed certificates to 
distribute trust anchor information.  Many vendors use this technique 
because it is a convenient way to bundle the information needed to define a 
trust anchor.  It also includes other information that is not needed to 
specify a trust anchor (by the definition in the RFC).

The validity period is the most obvious example.  Given the number of trust 
anchors that are embedded in brousers, the validity period provides an 
important service.  If the list were very small, say two or three, then the 
validity period would not be nearly as important.

>Similarly, does that mean the pathLen part of BasicConstraints should be 
>ignored during path validation? The 3rd paragraph of section 6 in RFC 3280 
>sort of implies that trusted roots aren't entirely ignored when it says 
>"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". 21 of the root certs in IE have pathLen. The value varies from 1 to 10.

This is another example.  An implementation that ignored the 
BasicConstraints associated with the self-signed certificate that defines a 
trust anchor would be compliant with the RFC.  However, an implementation 
that enforced the BasicConstraints associated with the self-signed 
certificate that defines a trust anchor would also be compliant with the RFC.

>I'm still having trouble with the term "CA certificate". Sort of seems 
>like everyone knows what it is but me :-).  So if I pretend I have a "CA 
>certificate" in my pocket, what do I have?
>a) A trust anchor (but not necessarily self-signed)
>b) A self signed cert
>c) A cert that's NOT an end entity
>d) An intermediate/branch cert (which obviously can't be self signed)
>e) One with the CA=TRUE in BasicConstraints (if so can a cert without 
>BasicConstraints ever be a "CA certificate")
>f) Some combination of the above

A CA certificate is not a trust anchor, and it is not the end entity 
certificate.  The CA certificate is any other certificate within the 
certification path.

Russ

Date: Thu, 15 Aug 2002 16:54:25 -0700
To: Sharon Boeyen <[email-masked]>, "'Housley, Russ'" <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: RE: Basic constraints processing for SSL
Cc: [email-masked]
Sender: [email-masked]

--=====================_285084509==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:11 AM 8/13/2002 -0400, Sharon Boeyen wrote:

>Just to add the X.509 voice to this discussion. With respect to the self 
>signed certificates, the statement made by Russ below was reinforced some 
>time ago through the processing of a defect report (DR) against the base 
>X.509 standard. As a result of that DR, the following sentence was added 
>to 12.4.3 of X.509:
>
>"Self-signed certificates, if encountered in the path, are ignored."

So does this mean that the validity dates in trusted roots and/or 
self-signed certs are to be ignored, or is this part of a distinct trust 
anchor validation process? It seems like a bad thing to ignore the validity 
dates in trust anchors.

Similarly, does that mean the pathLen part of BasicConstraints should be 
ignored during path validation? The 3rd paragraph of section 6 in RFC 3280 
sort of implies that trusted roots aren't entirely ignored when it says 
"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". 21 of the root certs in IE have pathLen. The value varies from 1 to 10.

I'm still having trouble with the term "CA certificate". Sort of seems like 
everyone knows what it is but me :-).  So if I pretend I have a "CA 
certificate" in my pocket, what do I have?
a) A trust anchor (but not necessarily self-signed)
b) A self signed cert
c) A cert that's NOT an end entity
d) An intermediate/branch cert (which obviously can't be self signed)
e) One with the CA=TRUE in BasicConstraints (if so can a cert without 
BasicConstraints ever be a "CA certificate")
f) Some combination of the above

Dean made the comment that it doesn't say what to do when BasicConstraints 
aren't present. This was generally (not just BasicConstraings) the 
difficult part - when the certs you get diverge from the standards and you 
know you have to process them. Adding that sort of text to the document (or 
a BCP document) would certainly be valuable.

LL

--=====================_285084509==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 11:11 AM 8/13/2002 -0400, Sharon Boeyen wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>Just to add the X.509
voice to this discussion. With respect to the self signed certificates,
the statement made by Russ below was reinforced some time ago through the
processing of a defect report (DR) against the base X.509 standard. As a
result of that DR, the following sentence was added to 12.4.3 of
X.509:<br>
</font><br>
<font size=2>&quot;Self-signed certificates, if encountered in the path,
are ignored.&quot;</font> </blockquote><br>
So does this mean that the validity dates in trusted roots and/or
self-signed certs are to be ignored, or is this part of a distinct trust
anchor validation process? It seems like a bad thing to ignore the
validity dates in trust anchors.<br><br>
Similarly, does that mean the pathLen part of BasicConstraints should be
ignored during path validation? The 3rd paragraph of section 6 in RFC
3280 sort of implies that trusted roots aren't entirely ignored when it
says &quot;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&quot;. 21 of the root certs in IE have pathLen. The value
varies from 1 to 10.<br><br>
<br><br>
<font size=2>I'm still having trouble with the term &quot;CA
certificate&quot;. Sort of seems like everyone knows what it is but me
:-).&nbsp; So if I pretend I have a &quot;CA certificate&quot; in my
pocket, what do I have?<br>
a) A trust anchor (but not necessarily self-signed)<br>
b) A self signed cert<br>
c) A cert that's NOT an end entity<br>
d) An intermediate/branch cert (which obviously can't be self
signed)<br>
e) One with the CA=TRUE in BasicConstraints (if so can a cert without
BasicConstraints ever be a &quot;CA certificate&quot;) <br>
f) Some combination of the above<br><br>
<br>
Dean made the comment that it doesn't say what to do when
BasicConstraints aren't present. This was generally (not just
BasicConstraings) the difficult part - when the certs you get diverge
from the standards and you know you have to process them. Adding that
sort of text to the document (or a BCP document) would certainly be
valuable. <br><br>
LL<br><br>
<br><br>
&nbsp;</font></html>

--=====================_285084509==_.ALT--

Date: Thu, 15 Aug 2002 11:09:41 -0400
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
To: "Sean P. Turner" <[email-masked]>
CC: IETF PKIX WG List <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Subject: Re: Objections Raised by the IESG on the Roadmap document
Sender: [email-masked]

I believe it goes beyond that. In general RFC level documents may not 
make references to any Internet Draft. So the whole discussion of which 
Internet Draft is at what status is out of line.

			-Jeff

Sean P. Turner wrote:
> Jeff,
> 
> Just to make sure - it's just the "STATUS: *" lines in section 4?
> 
> spt
> 
> "Jeffrey I. Schiller" wrote:
> 
> 
>>This is my fault, as I should have caught this before it got to the
>>IESG.
>>
>>The document contains a lot of status information on the various
>>Internet Drafts and RFCs that make up the PKIX Document set.
>>
>>Well, it is considered inappropriate for information that is as
>>dynamic as document status to be enshrined in an RFC.
>>
>>I suggest that we remove the status text from the document and
>>resubmit. The IESG recommends that the status information be placed on
>>a webpage, which can be linked from the IESG Charter Page. Of course
>>we would need someone to volunteer to keep that information up to
>>date.
>>
>>                        -Jeff
> 
> 
> 

From: "Manger, James H" <[email-masked]>
To: [email-masked]
Subject: PI DN: 00: comments
Date: Thu, 15 Aug 2002 17:38:53 +1000
Sender: [email-masked]

Nice work with draft-chadwick-pkix-pidn-00.txt.

1.
The PI-DN document (draft-chadwick-pkix-pidn-00.txt) suggests mapping a PI
type to a subject name prefix.  This seems contrary to the main purpose of
the PI document (draft-ietf-pkix-pi-05.txt), which is to have an identifier
that is independent of most changes to the subject DN.

The PI document (draft-ietf-pkix-pi-05.txt) does allow a PI type to be
mapped to a DN, but it is to the issuer DN not the subject DN.

2.
The piAuth attribute is supposed to unambiguously identify an authority.
The example in the document, piAuth=SSN, does NOT satisfy this property.  It
is only unambiguous within the context of a sequence of dc=xxx attributes.
This is a serious limitation on allowed subject DNs.  [Additionally, not all
URLs have a DNS name to convert to dc components]

3.
A subject DN includes (as prefixes) the DNs of its superiors in a naming
hierarchy.  These other entities may have their own permanent identifiers so
a DN may need to support different PIs in each RDN (e.g. a company number &
an employee number).  Hence, a pi & piAuth pair should be in the same RDN.
	cn=Tony + pi=1234 + piAuth=SSN, cn=Acme Inc + pi=789 + piAuth=DUNS,
c=AU

If a pi & piAuth pair are attributes in an entry the only sensible way to
incorporate then into DN is to include them in the same RDN.

4.
Why not simply use the URI value as the piAuth value (instead of trying to
split the URI into many attributes over multiple RDNs)?
	pi=5445+piAuth=http://myorg.com/ssn

5.
Using a string syntax (dotted decimal notation) to represent an OID in an
ASN.1 type...  yuck.  This seems like a sure sign that something is wrong.

6.
Perhaps we should use URNs: include the authority with the value in a single
string.  (not sure about this)

--
DN = distinguished name
RDN = relative distinguished name
PI = permanent identifier
URI = uniform resource identifier
DNS = domain name service
OID = object identifier
SSN = ?
ASN.1 = abstract syntax notation

> ----------
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Tuesday, 13 August 2002 9:27 pm
	..
> 	Title		: ..The use of Permanent Identifiers in LDAP
> Distinguished Names
> 	Filename	: draft-chadwick-pkix-pidn-00.txt
	..	
> http://www.ietf.org/internet-drafts/draft-chadwick-pkix-pidn-00.txt
> 
> -----
> 2. Possible Alternative Mappings 
> i) SerialNumber=12345, PIAuth=DHSS, C=GB
> ii) SerialNumber=12345, O=Department of Health and Social Security, C=GB
> iii) PI=12345, O=Department of Health and Social Security, C=GB
> iv) DHSSNo=12345, C=GB
> v) PI=12345, PIAuth=DHSS, C=GB      [This is the approach recommended]
> 4. PI Attributes 
> ( 1.2.826.0.1.3344810.1.1.34 NAME 'piAuth' SUP name ) 
> ( 1.2.826.0.1.3344810.1.1.35 NAME 'pi' SUP name SINGLE-VALUE ) 
> 5. Mapping suggestions
> {5445,http://xmlns.nist.gov/ssn}--->
> pi=5445,piAuth=ssn,dc=xlms,dc=nist,dc=gov 
> {5445,1.2.3.4.5}---> pi=5445,piAuth=SSN,dc=myorg,dc=com
> {5445,1.2.3.4.5}---> pi=5445,piAuth=1.2.3.4.5

Reply-To: <[email-masked]>
From: "Alice Sturgeon" <[email-masked]>
To: "Mohammad Awad" <[email-masked]>, <[email-masked]>
Subject: RE: authenticity of origin in the request 
Date: Wed, 14 Aug 2002 08:38:03 -0400
Importance: Normal
Sender: [email-masked]

There would be a number of other out-of-band methods to verify the
authenticity of a certificate request.  Some of these relate to prior
authorization from another authority, as in an organizational group policy
authorization, or batch processing methods, wherein the RA sends certificate
requests to a CA based on a database list previously authenticated by a
third party and submitted to the RA, under previously-agreed arrangements
(e.g., contract).  Note that with such methods there is an issue of shift of
liability with respect to verification of, in such cases, authorization of
cert requests.  Also, this only works for known relationships (RA/CA and
authorizing entity).

Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Mohammad Awad
Sent: August 14, 2002 4:19 AM
To: [email-masked]
Subject: authenticity of origin in the request

Hallo
If anyone, please have an answer to this question.
I read in RFC2511 that RA can verify that the certificate requestor is the
one who claims to be, by using a pre-shared key between them.
If that is not applicable, what are other solutions for the issue of
(authenticity of the origin of request)?

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx

Content-return: allowed
Date: Wed, 14 Aug 2002 05:06:47 -0700
From: Peter Williams <[email-masked]>
Subject: RE: Basic constraints processing for SSL
To: "'Tom Gindin '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Sender: [email-masked]

There are several areas of implementation
assumptions that will lead to many more debacles, 
in my view. I think we are in the situation
of the famous picture of the little Dutch
boy with his finger in the dyke.
 
a) PKIX compliance covers both v1 and v3 certs. When handling
a v1 CA cert in compliance with PKIX, obviously
one cannot use a basicConstraints control to enforce
the check of the subject as a CA.

b) I could poke several holes in several common S/MIME
implementations on v1 grounds, also - given how v1 certs are 
rarely "correctly handled" by UAs - usually  because of implementor 
assumptions about v3 controls. There are various "impropriety" 
holes in the commodity S/MIME emailers, when only one party is 
using the PEM 1422 cert management requirements for scanning the
local cache of certificate when handling a queried CRL,
(rather than path processing certs communicated within the 
message).

c) Its very unclear how many implementations handle the 3280
obligations to "parse" the unique identifier of v2/v3
certs, also, when CA communities override the recommendation
on their absence.

Peter.

-----Original Message-----
From: Tom Gindin
To: Dean Povey
Cc: Housley, Russ; Laurence Lundblade; [email-masked]
Sent: 8/13/02 6:45 PM
Subject: Re: Basic constraints processing for SSL

      The descriptions of the problem I have seen don't mention KeyUsage
at
all.  RFC 2459 (which was probably in force when this code was written)
insists that critical KeyUsage without KeyCertSign is invalid for CA
certificates, and RFC 3280 removes the dependence on criticality - any
KeyUsage without KeyCertSign is invalid for CA certificates.
      Are the IE/Konqueror implementations conforming to those
requirements
as well?  They would seem to provide an extra level of protection above
the
ones on basicConstraints.

            Tom Gindin

Dean Povey <[email-masked]>@mail.imc.org on 08/13/2002 07:17:59 PM

Sent by:    [email-masked]

To:    "Housley, Russ" <[email-masked]>
cc:    Laurence Lundblade <[email-masked]>, [email-masked]
Subject:    Re: Basic constraints processing for SSL

On Tue, 13 Aug 2002 09:49:55 -0400, "Housley, Russ" wrote:
>
>Laurence:
>
>Self-signed root certificates are a mechanism for distributing
information

>about trust anchors.  Note that they are not actually processed as CA
>certificates by the certification path validation algorithm.
>

This is true for trust anchors, however a closer inspection of RFC3280
shows that it is understandable why this error was made in IE/Konqueror.

The path validation algorithm from RFC3280 says:

    (k)  Verify that the certificate is a CA certificate (as specified
      in a basicConstraints extension or as verified out-of-band).

Which means that if basic constraints is not present the user should
check.
Note that the text in RFC3280 is clear and unambiguous that basic
constraints MUST be included in certificates, but it is vague about what
to
do when they are not.  It could be argued that the IE implementation is
conforming with RFC3280 (although from Sharon's comments, not with X.509
where the determination of isCA is much more explicit). I think you can
make the reasonable requirement, that in this case the implementation
should at least ask, but since the semantics of out-of-band checking are
never specified then this leaves too much wiggle room for the
implementation.

So I think this is also a defect in the PKIX spec.  It also highlights
the
problem with using BasicConstraints only for CAs.  I think that the
approach of putting a critical BasicConstraints extension with
isCA=FALSE
in EE certs is more compatible with the path validation algorithm, and
gives a clear and unambiguous indication of what the application should
do.

--
Dean Povey,             |em: [email-masked]|JCSI: Java security
toolkit
Wedgetail Communications|ph:  +61 7 3023 5139   |uPKI: Embedded/C PKI
toolkit
Level 14, 388 Queen St, |fax: +61 7 3864 1282   |uSSL: Embedded/C SSL
toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML
Signatures

From: "Mohammad Awad" <[email-masked]>
To: [email-masked]
Subject: authenticity of origin in the request 
Date: Wed, 14 Aug 2002 11:19:06 +0300
Sender: [email-masked]

Hallo
If anyone, please have an answer to this question.
I read in RFC2511 that RA can verify that the certificate requestor is the 
one who claims to be, by using a pre-shared key between them.
If that is not applicable, what are other solutions for the issue of 
(authenticity of the origin of request)?

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Date: Wed, 14 Aug 2002 16:01:45 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: certificate viewer for linux
Sender: [email-masked]

Geoffrey Elgey <[email-masked]> writes:

>Sorry, no GUI tools here, but I thought I would share some info on the two
>certificate dumping tools that I cannot live without.
>
>The first is Peter Guttman's dumpasn1 at
>http://www.cs.auckland.ac.nz/~pgut001/, which is excellent for checking ASN.1
>values and offsets. Everyone should know about this.

There's a (Win32) GUI version of this being worked on by someone else, I'll add
a link to it from my home page when it's released.

Peter.

Importance: Normal
Sensitivity: 
Subject: Re: Basic constraints processing for SSL
To: Dean Povey <[email-masked]>
Cc: "Housley, Russ" <[email-masked]>, Laurence Lundblade <[email-masked]>, [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Tue, 13 Aug 2002 21:45:31 -0400
Sender: [email-masked]

      The descriptions of the problem I have seen don't mention KeyUsage at
all.  RFC 2459 (which was probably in force when this code was written)
insists that critical KeyUsage without KeyCertSign is invalid for CA
certificates, and RFC 3280 removes the dependence on criticality - any
KeyUsage without KeyCertSign is invalid for CA certificates.
      Are the IE/Konqueror implementations conforming to those requirements
as well?  They would seem to provide an extra level of protection above the
ones on basicConstraints.

            Tom Gindin

Dean Povey <[email-masked]>@mail.imc.org on 08/13/2002 07:17:59 PM

Sent by:    [email-masked]

To:    "Housley, Russ" <[email-masked]>
cc:    Laurence Lundblade <[email-masked]>, [email-masked]
Subject:    Re: Basic constraints processing for SSL

On Tue, 13 Aug 2002 09:49:55 -0400, "Housley, Russ" wrote:
>
>Laurence:
>
>Self-signed root certificates are a mechanism for distributing information

>about trust anchors.  Note that they are not actually processed as CA
>certificates by the certification path validation algorithm.
>

This is true for trust anchors, however a closer inspection of RFC3280
shows that it is understandable why this error was made in IE/Konqueror.

The path validation algorithm from RFC3280 says:

    (k)  Verify that the certificate is a CA certificate (as specified
      in a basicConstraints extension or as verified out-of-band).

Which means that if basic constraints is not present the user should check.
Note that the text in RFC3280 is clear and unambiguous that basic
constraints MUST be included in certificates, but it is vague about what to
do when they are not.  It could be argued that the IE implementation is
conforming with RFC3280 (although from Sharon's comments, not with X.509
where the determination of isCA is much more explicit). I think you can
make the reasonable requirement, that in this case the implementation
should at least ask, but since the semantics of out-of-band checking are
never specified then this leaves too much wiggle room for the
implementation.

So I think this is also a defect in the PKIX spec.  It also highlights the
problem with using BasicConstraints only for CAs.  I think that the
approach of putting a critical BasicConstraints extension with isCA=FALSE
in EE certs is more compatible with the path validation algorithm, and
gives a clear and unambiguous indication of what the application should do.

--
Dean Povey,             |em: [email-masked]|JCSI: Java security
toolkit
Wedgetail Communications|ph:  +61 7 3023 5139   |uPKI: Embedded/C PKI
toolkit
Level 14, 388 Queen St, |fax: +61 7 3864 1282   |uSSL: Embedded/C SSL
toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML
Signatures

From: Dean Povey <[email-masked]>
To: "Housley, Russ" <[email-masked]>
cc: Laurence Lundblade <[email-masked]>, [email-masked]
Subject: Re: Basic constraints processing for SSL 
Date: Wed, 14 Aug 2002 09:17:59 +1000
Sender: [email-masked]

On Tue, 13 Aug 2002 09:49:55 -0400, "Housley, Russ" wrote: 
>
>Laurence:
>
>Self-signed root certificates are a mechanism for distributing information 
>about trust anchors.  Note that they are not actually processed as CA 
>certificates by the certification path validation algorithm.
>

This is true for trust anchors, however a closer inspection of RFC3280 
shows that it is understandable why this error was made in IE/Konqueror.

The path validation algorithm from RFC3280 says:

    (k)  Verify that the certificate is a CA certificate (as specified
      in a basicConstraints extension or as verified out-of-band).

Which means that if basic constraints is not present the user should check.
Note that the text in RFC3280 is clear and unambiguous that basic
constraints MUST be included in certificates, but it is vague about what to
do when they are not.  It could be argued that the IE implementation is
conforming with RFC3280 (although from Sharon's comments, not with X.509
where the determination of isCA is much more explicit). I think you can
make the reasonable requirement, that in this case the implementation
should at least ask, but since the semantics of out-of-band checking are
never specified then this leaves too much wiggle room for the 
implementation.

So I think this is also a defect in the PKIX spec.  It also highlights the
problem with using BasicConstraints only for CAs.  I think that the
approach of putting a critical BasicConstraints extension with isCA=FALSE
in EE certs is more compatible with the path validation algorithm, and
gives a clear and unambiguous indication of what the application should do.

-- 
Dean Povey,             |em: [email-masked]|JCSI: Java security toolkit
Wedgetail Communications|ph:  +61 7 3023 5139   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: +61 7 3864 1282   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures 

Date: Tue, 13 Aug 2002 16:53:40 -0400
From: Steve Hanna <[email-masked]>
To: Laurence Lundblade <[email-masked]>
CC: [email-masked]
Subject: Re: Basic constraints processing for SSL
Sender: [email-masked]

One more bit of clarification is in order. 

Laurence Lundblade wrote:
> I understand that an intermediate cert MUST have BasicConstraints
> for RFC 2459 / 3280 compliance, but is that a good thing for SSL?
> I assume that is what Netscape and Mozilla due to avoid the problem
> that IE has, but I haven't tested it yet. I also assume they only
> apply the requirement to intermediate certs and not roots due to
> the number of roots without the extension.

Extensions in trusted certificates are not processed during path
validation, according to RFC 3280. See section 6.1, which says
"When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path."

> It makes sense to me that trusted anchor roots are implicitly
> used to verify other certs and thus don't need BasicConstraints,
> however the first sentence of the 4th paragraph of 4.2.1.10 says
> they must have the extension, doesn't it?

No, since trusted certificates aren't processed during path
validation.

> Seems like the first paragraph of 4.2.1.10 could be improved.
> It says "The basic constraints extension identifies whether
> the subject of the certificate is a CA....". Is what is meant
> that the subject *names* a CA? In that case we have a problem
> with intermediate certs which don't necessarily name a CA in
> the subject but include BasicConstraints. If what is meant is
> that the cert can be used to verify other certs, then that's
> different and it's not very clear.

That sentence simply means that the basic constraints extension
identifies whether the subject is a CA. As the next sentence
indicates, if the cA boolean is false it indicates that the
subject is not a CA.

> In general I have trouble with the term "CA certificate"
> because I don't know if it means a trusted root certificate
> or a certificate used to verify other certificates. For
> example see 6.1.4 (k).

Section 6.1.4 only applies to certificates in the path, so
it clearly doesn't apply to trust anchors.

Steve

From: Sharon Boeyen <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Subject: RE: Basic constraints processing for SSL
Date: Tue, 13 Aug 2002 11:11:07 -0400
Sender: [email-masked]

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

------_=_NextPart_001_01C242DB.A682DBA0
Content-Type: text/plain

Just to add the X.509 voice to this discussion. With respect to the self
signed certificates, the statement made by Russ below was reinforced some
time ago through the processing of a defect report (DR) against the base
X.509 standard. As a result of that DR, the following sentence was added to
12.4.3 of X.509:

"Self-signed certificates, if encountered in the path, are ignored."

As for the intermediate CA certificates, X.509 is also very clear. Clause
8.4.2.1 Basic constraints extension states :

"If this extension is not present, or is flagged non-critical and is not
recognized by a certificate-using system, then the certificate is to be
considered an end-entity certificate and cannot be used to verify
certificate signatures."

and 
"If this extension is present and is flagged critical, or is flagged
non-critical but is recognized by the certificate-using system, then: 
 - if the value of cA is not set to true then the certifified public key
shall 
not be used to verify a certificate signature....."

as for EE certs, it also says:
"To constrain a certificate subject to being only an end entity, i.e. not a
CA, the issue can include this extension field containing only an empty
SEQUENCE value."

If you don't have a copy of X.509 and would like me to send you the complete
text for clause 8.4.2.1, let me know.

Sharon 

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Tuesday, August 13, 2002 9:50 AM
To: Laurence Lundblade
Cc: [email-masked]
Subject: Re: Basic constraints processing for SSL

Laurence:

Self-signed root certificates are a mechanism for distributing information 
about trust anchors.  Note that they are not actually processed as CA 
certificates by the certification path validation algorithm.

Russ

At 03:04 PM 8/12/2002 -0700, Laurence Lundblade wrote:
>Oops, should have looked at 3280.
>
>So now it's OK to have BasicConstraints in end entities. That helps a lot 
>with SSL compatibility.
>
>I understand that an intermediate cert MUST have BasicConstraints for RFC 
>2459 / 3280 compliance, but is that a good thing for SSL? I assume that is 
>what Netscape and Mozilla due to avoid the problem that IE has, but I 
>haven't tested it yet. I also assume they only apply the requirement to 
>intermediate certs and not roots due to the number of roots without the 
>extension.
>
>
>So now a few wording comments:
>
>It makes sense to me that trusted anchor roots are implicitly used to 
>verify other certs and thus don't need BasicConstraints, however the first 
>sentence of the 4th paragraph of 4.2.1.10 says they must have the 
>extension, doesn't it?
>
>Seems like the first paragraph of 4.2.1.10 could be improved. It says "The 
>basic constraints extension identifies whether the subject of the 
>certificate is a CA....". Is what is meant that the subject *names* a CA? 
>In that case we have a problem with intermediate certs which don't 
>necessarily name a CA in the subject but include BasicConstraints. If what 
>is meant is that the cert can be used to verify other certs, then that's 
>different and it's not very clear.
>
>In general I have trouble with the term "CA certificate" because I don't 
>know if it means a trusted root certificate or a certificate used to 
>verify other certificates. For example see 6.1.4 (k).
>
>LL
>
>
>
>
>At 04:58 PM 8/12/2002 -0400, Housley, Russ wrote:
>>Laurence:
>>
>>Please take a look at RFC 3280.  I think it provides a more complete 
>>description.
>>
>>A self-signed root certificate is a mechanism for distributing trust 
>>anchors.  As such, they need not contain any certificate extensions to 
>>provide the information necessary for the algorithm to function 
>>properly.  Intermediate CA certificates MUST contain the basic 
>>constraints extension with the cA bit set to conform to either RFC 2459 
>>or RFC 3280.
>>
>>Russ
>>
>>
>>At 11:16 AM 8/12/2002 -0700, Laurence Lundblade wrote:
>>
>>>I'd like to check my understanding of basic constraints processing for 
>>>SSL to be sure our implementation is right in light of the recent IE 
>>>problems. This group seems the best one to me, but send me off somewhere 
>>>else if you think there's a better place. I know there's no document or 
>>>standard and 2459 doesn't necessarily apply to SSL.
>>>
>>>
>>>RFC 2459 4.2.1.10 says that CA's must set CA to TRUE and end entities 
>>>should not have the extension present. That is the client software would 
>>>give an error when any cert without BasicConstraints and CA=TRUE is used 
>>>verify another cert.  That certainly will defend against the recently 
>>>published IE attack.
>>>
>>>However, if you examine the root / CA certs distributed with IE, a 
>>>number of them do NOT have the BasicConstraints extension. I believe the 
>>>yields section 4.2.1.10 unworkable for SSL. (I'm not suggesting a change 
>>>in 2459, just making the point that it doesn't seem to work for SSL).
>>>
>>>I think there are two possible implementations that might work for SSL:
>>>
>>>1) Require BasicConstraints and CA=TRUE for intermediate certs only, not 
>>>roots. This will defend against the attack. The (admittedly few) 
>>>intermediate certs I've seen to have BasicConstraints and CA=TRUE.
>>>
>>>2) If a cert is being used to verify another and BasicConstraints is 
>>>present, make sure it is false. This goes against 4.2.1.10 because it 
>>>says that end entities should not include BasicConstraints, but for SSL 
>>>the majority of the certs have it present and when present it it false.
>>>
>>>Comments?
>>>
>>>
>>>Further, I did an analysis of 50 or so random SSL server certs and found 
>>>the following:
>>>     15 VeriSign issued certs had BasicConstraints present, not 
>>> critical, CA=FALSE
>>>     10 RSA SSCA (VeriSign) issued certs had BasicConstraints present, 
>>> not critical, CA=FALSE
>>>     9 Thawte issued certs has BasicConstraints present, CRITICAL,
CA=FALSE
>>>     7 RSA SSCA (VeriSign) issued certs had no BasicConstraints present.
>>>     2 others had no BasicConstraints present.
>>>
>>>Clearly the majority have BasicConstraints present, CA=FALSE and I can 
>>>understand why a CA would do that. It helps defend against this attack 
>>>and has no down side. That it seems no SSL implementation would be so 
>>>strict that it would error out if BasicConstraints is present on an end 
>>>entity. I can also imagine that Thawte is trying to be extra 
>>>cautious  by making it critical, but what is confusing is why some RSA 
>>>SSCA certs have it present and some don't. Any ideas?
>>>
>>>Also, I did an analysis of the root / CA certs bundled with IE and go 
>>>the following:
>>>    34 had BasicConstraints present and critical
>>>    28 had BasicConstraints present and NOT critical
>>>    40 do not have BasicConstraints present
>>>
>>>The last number is the most troubling to me because it goes against RFC 
>>>2459, and because I can't imagine why a CA would do it. It would seem 
>>>either the CA operators aren't aware of this attack, or there's enough 
>>>bad software out there that chokes BasicConstraints being present, or it 
>>>doesn't matter because the check is never done on the root, just 
>>>intermediates as I suggest above.  Some of the CA's with no 
>>>BasicConstraints present are:
>>>    VeriSign Class 1
>>>    VeriSign Individual Software Publishers
>>>    ... many other VeriSign roots
>>>    C&W HKT SecureNet CA root
>>>    Japan Certification Services
>>>    RSA SSCA
>>>    Microsoft
>>>
>>>Thanks, LL
>>>
>>>
>>>
>>>
>>>,

------_=_NextPart_001_01C242DB.A682DBA0
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.2653.12">
<TITLE>RE: Basic constraints processing for SSL</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Just to add the X.509 voice to this discussion. With =
respect to the self signed certificates, the statement made by Russ =
below was reinforced some time ago through the processing of a defect =
report (DR) against the base X.509 standard. As a result of that DR, =
the following sentence was added to 12.4.3 of X.509:</FONT></P>

<P><FONT SIZE=3D2>&quot;Self-signed certificates, if encountered in the =
path, are ignored.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>As for the intermediate CA certificates, X.509 is =
also very clear. Clause 8.4.2.1 Basic constraints extension states =
:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;If this extension is not present, or is flagged =
non-critical and is not recognized by a certificate-using system, then =
the certificate is to be considered an end-entity certificate and =
cannot be used to verify certificate signatures.&quot;</FONT></P>

<P><FONT SIZE=3D2>and </FONT>
<BR><FONT SIZE=3D2>&quot;If this extension is present and is flagged =
critical, or is flagged non-critical but is recognized by the =
certificate-using system, then: </FONT></P>

<P><FONT SIZE=3D2>&nbsp;- if the value of cA is not set to true then =
the certifified public key shall </FONT>
<BR><FONT SIZE=3D2>not be used to verify a certificate =
signature.....&quot;</FONT>
</P>

<P><FONT SIZE=3D2>as for EE certs, it also says:</FONT>
<BR><FONT SIZE=3D2>&quot;To constrain a certificate subject to being =
only an end entity, i.e. not a CA, the issue can include this extension =
field containing only an empty SEQUENCE value.&quot;</FONT></P>

<P><FONT SIZE=3D2>If you don't have a copy of X.509 and would like me =
to send you the complete text for clause 8.4.2.1, let me know.</FONT>
</P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, August 13, 2002 9:50 AM</FONT>
<BR><FONT SIZE=3D2>To: Laurence Lundblade</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Basic constraints processing for =
SSL</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Laurence:</FONT>
</P>

<P><FONT SIZE=3D2>Self-signed root certificates are a mechanism for =
distributing information </FONT>
<BR><FONT SIZE=3D2>about trust anchors.&nbsp; Note that they are not =
actually processed as CA </FONT>
<BR><FONT SIZE=3D2>certificates by the certification path validation =
algorithm.</FONT>
</P>

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

<P><FONT SIZE=3D2>At 03:04 PM 8/12/2002 -0700, Laurence Lundblade =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Oops, should have looked at 3280.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;So now it's OK to have BasicConstraints in end =
entities. That helps a lot </FONT>
<BR><FONT SIZE=3D2>&gt;with SSL compatibility.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I understand that an intermediate cert MUST have =
BasicConstraints for RFC </FONT>
<BR><FONT SIZE=3D2>&gt;2459 / 3280 compliance, but is that a good thing =
for SSL? I assume that is </FONT>
<BR><FONT SIZE=3D2>&gt;what Netscape and Mozilla due to avoid the =
problem that IE has, but I </FONT>
<BR><FONT SIZE=3D2>&gt;haven't tested it yet. I also assume they only =
apply the requirement to </FONT>
<BR><FONT SIZE=3D2>&gt;intermediate certs and not roots due to the =
number of roots without the </FONT>
<BR><FONT SIZE=3D2>&gt;extension.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;So now a few wording comments:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;It makes sense to me that trusted anchor roots =
are implicitly used to </FONT>
<BR><FONT SIZE=3D2>&gt;verify other certs and thus don't need =
BasicConstraints, however the first </FONT>
<BR><FONT SIZE=3D2>&gt;sentence of the 4th paragraph of 4.2.1.10 says =
they must have the </FONT>
<BR><FONT SIZE=3D2>&gt;extension, doesn't it?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Seems like the first paragraph of 4.2.1.10 could =
be improved. It says &quot;The </FONT>
<BR><FONT SIZE=3D2>&gt;basic constraints extension identifies whether =
the subject of the </FONT>
<BR><FONT SIZE=3D2>&gt;certificate is a CA....&quot;. Is what is meant =
that the subject *names* a CA? </FONT>
<BR><FONT SIZE=3D2>&gt;In that case we have a problem with intermediate =
certs which don't </FONT>
<BR><FONT SIZE=3D2>&gt;necessarily name a CA in the subject but include =
BasicConstraints. If what </FONT>
<BR><FONT SIZE=3D2>&gt;is meant is that the cert can be used to verify =
other certs, then that's </FONT>
<BR><FONT SIZE=3D2>&gt;different and it's not very clear.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;In general I have trouble with the term &quot;CA =
certificate&quot; because I don't </FONT>
<BR><FONT SIZE=3D2>&gt;know if it means a trusted root certificate or a =
certificate used to </FONT>
<BR><FONT SIZE=3D2>&gt;verify other certificates. For example see 6.1.4 =
(k).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;LL</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;At 04:58 PM 8/12/2002 -0400, Housley, Russ =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Laurence:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Please take a look at RFC 3280.&nbsp; I =
think it provides a more complete </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;description.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;A self-signed root certificate is a =
mechanism for distributing trust </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;anchors.&nbsp; As such, they need not =
contain any certificate extensions to </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;provide the information necessary for the =
algorithm to function </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;properly.&nbsp; Intermediate CA certificates =
MUST contain the basic </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;constraints extension with the cA bit set to =
conform to either RFC 2459 </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;or RFC 3280.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Russ</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;At 11:16 AM 8/12/2002 -0700, Laurence =
Lundblade wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;I'd like to check my understanding of =
basic constraints processing for </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;SSL to be sure our implementation is =
right in light of the recent IE </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;problems. This group seems the best one =
to me, but send me off somewhere </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;else if you think there's a better =
place. I know there's no document or </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;standard and 2459 doesn't necessarily =
apply to SSL.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;RFC 2459 4.2.1.10 says that CA's must =
set CA to TRUE and end entities </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;should not have the extension present. =
That is the client software would </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;give an error when any cert without =
BasicConstraints and CA=3DTRUE is used </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;verify another cert.&nbsp; That =
certainly will defend against the recently </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;published IE attack.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;However, if you examine the root / CA =
certs distributed with IE, a </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;number of them do NOT have the =
BasicConstraints extension. I believe the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;yields section 4.2.1.10 unworkable for =
SSL. (I'm not suggesting a change </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;in 2459, just making the point that it =
doesn't seem to work for SSL).</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;I think there are two possible =
implementations that might work for SSL:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;1) Require BasicConstraints and =
CA=3DTRUE for intermediate certs only, not </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;roots. This will defend against the =
attack. The (admittedly few) </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;intermediate certs I've seen to have =
BasicConstraints and CA=3DTRUE.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;2) If a cert is being used to verify =
another and BasicConstraints is </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;present, make sure it is false. This =
goes against 4.2.1.10 because it </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;says that end entities should not =
include BasicConstraints, but for SSL </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;the majority of the certs have it =
present and when present it it false.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;Comments?</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;Further, I did an analysis of 50 or so =
random SSL server certs and found </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;the following:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; 15 VeriSign =
issued certs had BasicConstraints present, not </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; critical, CA=3DFALSE</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; 10 RSA SSCA =
(VeriSign) issued certs had BasicConstraints present, </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; not critical, CA=3DFALSE</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; 9 Thawte issued =
certs has BasicConstraints present, CRITICAL, CA=3DFALSE</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; 7 RSA SSCA =
(VeriSign) issued certs had no BasicConstraints present.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; 2 others had no =
BasicConstraints present.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;Clearly the majority have =
BasicConstraints present, CA=3DFALSE and I can </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;understand why a CA would do that. It =
helps defend against this attack </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;and has no down side. That it seems no =
SSL implementation would be so </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;strict that it would error out if =
BasicConstraints is present on an end </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;entity. I can also imagine that Thawte =
is trying to be extra </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;cautious&nbsp; by making it critical, =
but what is confusing is why some RSA </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;SSCA certs have it present and some =
don't. Any ideas?</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;Also, I did an analysis of the root / CA =
certs bundled with IE and go </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;the following:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; 34 had =
BasicConstraints present and critical</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; 28 had =
BasicConstraints present and NOT critical</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; 40 do not have =
BasicConstraints present</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;The last number is the most troubling to =
me because it goes against RFC </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;2459, and because I can't imagine why a =
CA would do it. It would seem </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;either the CA operators aren't aware of =
this attack, or there's enough </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;bad software out there that chokes =
BasicConstraints being present, or it </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;doesn't matter because the check is =
never done on the root, just </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;intermediates as I suggest above.&nbsp; =
Some of the CA's with no </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;BasicConstraints present are:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; VeriSign Class =
1</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; VeriSign Individual =
Software Publishers</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; ... many other =
VeriSign roots</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; C&amp;W HKT SecureNet =
CA root</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Japan Certification =
Services</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; RSA SSCA</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Microsoft</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;Thanks, LL</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;,</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C242DB.A682DBA0--

From: "Housley, Russ" <[email-masked]>
To: Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Date: Tue, 13 Aug 2002 09:49:55 -0400
Subject: Re: Basic constraints processing for SSL
Sender: [email-masked]

Laurence:

Self-signed root certificates are a mechanism for distributing information 
about trust anchors.  Note that they are not actually processed as CA 
certificates by the certification path validation algorithm.

Russ

At 03:04 PM 8/12/2002 -0700, Laurence Lundblade wrote:
>Oops, should have looked at 3280.
>
>So now it's OK to have BasicConstraints in end entities. That helps a lot 
>with SSL compatibility.
>
>I understand that an intermediate cert MUST have BasicConstraints for RFC 
>2459 / 3280 compliance, but is that a good thing for SSL? I assume that is 
>what Netscape and Mozilla due to avoid the problem that IE has, but I 
>haven't tested it yet. I also assume they only apply the requirement to 
>intermediate certs and not roots due to the number of roots without the 
>extension.
>
>
>So now a few wording comments:
>
>It makes sense to me that trusted anchor roots are implicitly used to 
>verify other certs and thus don't need BasicConstraints, however the first 
>sentence of the 4th paragraph of 4.2.1.10 says they must have the 
>extension, doesn't it?
>
>Seems like the first paragraph of 4.2.1.10 could be improved. It says "The 
>basic constraints extension identifies whether the subject of the 
>certificate is a CA....". Is what is meant that the subject *names* a CA? 
>In that case we have a problem with intermediate certs which don't 
>necessarily name a CA in the subject but include BasicConstraints. If what 
>is meant is that the cert can be used to verify other certs, then that's 
>different and it's not very clear.
>
>In general I have trouble with the term "CA certificate" because I don't 
>know if it means a trusted root certificate or a certificate used to 
>verify other certificates. For example see 6.1.4 (k).
>
>LL
>
>
>
>
>At 04:58 PM 8/12/2002 -0400, Housley, Russ wrote:
>>Laurence:
>>
>>Please take a look at RFC 3280.  I think it provides a more complete 
>>description.
>>
>>A self-signed root certificate is a mechanism for distributing trust 
>>anchors.  As such, they need not contain any certificate extensions to 
>>provide the information necessary for the algorithm to function 
>>properly.  Intermediate CA certificates MUST contain the basic 
>>constraints extension with the cA bit set to conform to either RFC 2459 
>>or RFC 3280.
>>
>>Russ
>>
>>
>>At 11:16 AM 8/12/2002 -0700, Laurence Lundblade wrote:
>>
>>>I'd like to check my understanding of basic constraints processing for 
>>>SSL to be sure our implementation is right in light of the recent IE 
>>>problems. This group seems the best one to me, but send me off somewhere 
>>>else if you think there's a better place. I know there's no document or 
>>>standard and 2459 doesn't necessarily apply to SSL.
>>>
>>>
>>>RFC 2459 4.2.1.10 says that CA's must set CA to TRUE and end entities 
>>>should not have the extension present. That is the client software would 
>>>give an error when any cert without BasicConstraints and CA=TRUE is used 
>>>verify another cert.  That certainly will defend against the recently 
>>>published IE attack.
>>>
>>>However, if you examine the root / CA certs distributed with IE, a 
>>>number of them do NOT have the BasicConstraints extension. I believe the 
>>>yields section 4.2.1.10 unworkable for SSL. (I'm not suggesting a change 
>>>in 2459, just making the point that it doesn't seem to work for SSL).
>>>
>>>I think there are two possible implementations that might work for SSL:
>>>
>>>1) Require BasicConstraints and CA=TRUE for intermediate certs only, not 
>>>roots. This will defend against the attack. The (admittedly few) 
>>>intermediate certs I've seen to have BasicConstraints and CA=TRUE.
>>>
>>>2) If a cert is being used to verify another and BasicConstraints is 
>>>present, make sure it is false. This goes against 4.2.1.10 because it 
>>>says that end entities should not include BasicConstraints, but for SSL 
>>>the majority of the certs have it present and when present it it false.
>>>
>>>Comments?
>>>
>>>
>>>Further, I did an analysis of 50 or so random SSL server certs and found 
>>>the following:
>>>     15 VeriSign issued certs had BasicConstraints present, not 
>>> critical, CA=FALSE
>>>     10 RSA SSCA (VeriSign) issued certs had BasicConstraints present, 
>>> not critical, CA=FALSE
>>>     9 Thawte issued certs has BasicConstraints present, CRITICAL, CA=FALSE
>>>     7 RSA SSCA (VeriSign) issued certs had no BasicConstraints present.
>>>     2 others had no BasicConstraints present.
>>>
>>>Clearly the majority have BasicConstraints present, CA=FALSE and I can 
>>>understand why a CA would do that. It helps defend against this attack 
>>>and has no down side. That it seems no SSL implementation would be so 
>>>strict that it would error out if BasicConstraints is present on an end 
>>>entity. I can also imagine that Thawte is trying to be extra 
>>>cautious  by making it critical, but what is confusing is why some RSA 
>>>SSCA certs have it present and some don't. Any ideas?
>>>
>>>Also, I did an analysis of the root / CA certs bundled with IE and go 
>>>the following:
>>>    34 had BasicConstraints present and critical
>>>    28 had BasicConstraints present and NOT critical
>>>    40 do not have BasicConstraints present
>>>
>>>The last number is the most troubling to me because it goes against RFC 
>>>2459, and because I can't imagine why a CA would do it. It would seem 
>>>either the CA operators aren't aware of this attack, or there's enough 
>>>bad software out there that chokes BasicConstraints being present, or it 
>>>doesn't matter because the check is never done on the root, just 
>>>intermediates as I suggest above.  Some of the CA's with no 
>>>BasicConstraints present are:
>>>    VeriSign Class 1
>>>    VeriSign Individual Software Publishers
>>>    ... many other VeriSign roots
>>>    C&W HKT SecureNet CA root
>>>    Japan Certification Services
>>>    RSA SSCA
>>>    Microsoft
>>>
>>>Thanks, LL
>>>
>>>
>>>
>>>
>>>,

Date: Tue, 13 Aug 2002 22:24:13 +1000
From: Geoffrey Elgey <[email-masked]>
To: [email-masked]
Subject: Re: certificate viewer for linux
Sender: [email-masked]

G'day,

> I want to have a certificate viewer for linux. It's prefered to be GUI. 
> Can anybody help me to find it?

Sorry, no GUI tools here, but I thought I would share some info on the 
two certificate dumping tools that I cannot live without.

The first is Peter Guttman's dumpasn1 at 
http://www.cs.auckland.ac.nz/~pgut001/, which is excellent for checking 
ASN.1 values and offsets. Everyone should know about this.

The second is a quick hack I developed as part of my company's uPKI 
product. It's called dumpasn1obj, which is a bit lame, but Peter had 
already taken dumpasn1 :-)

It may be useful for anyone doing PKI work if they need to dump certs, 
crls, extensions, PFX's, PKCS#10's, etc and associate names with values, 
rather than offsets.

It also allows you to extract "parts" of the value, such as 
"toBeSigned.issuer" or "toBeSigned.extensions[critical=true]", which I 
think is a pretty cool (though in practice mostly useless) feature :-)

A man page is at 
http://www.wedgetail.com/upki/doc/man/man1/dumpasn1obj.html, if you want 
to look at some uses. It's pretty much an alpha until I finalize the 
text encoding/decoding rules for a future release.

The tool is included as part of the uPKI evaluation binaries from 
www.wedgetail.com/upki. I'm not sure if it will ever be freely available 
though, but that's out of my hands :-(

Hope someone likes it.

Cheers,
Geoff

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-chadwick-pkix-pidn-00.txt
Date: Tue, 13 Aug 2002 07:27:21 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure The use of 
                          Permanent Identifiers in LDAP Distinguished Names
	Author(s)	: D. Chadwick
	Filename	: draft-chadwick-pkix-pidn-00.txt
	Pages		: 
	Date		: 12-Aug-02
	
This document defines a standard way of using Permanent Identifiers in 
LDAP distinguished names, in order to facilitate the allocation of 
globally unique distinguished names to PKI subjects, and to allow the 
certificates of these subjects to be easily retrieved from LDAP 
servers.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-chadwick-pkix-pidn-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-chadwick-pkix-pidn-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-chadwick-pkix-pidn-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-chadwick-pkix-pidn-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: "Ed Greshko" <[email-masked]>
To: "af Lamei" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: certificate viewer for linux
Date: Tue, 13 Aug 2002 17:21:33 +0800
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Hi,

  I want to have a certificate viewer for linux. It's prefered to be GUI.
Can anybody help me to find it?

Have you checked out http://www.iit.edu/~gawojar/ldap/features.html ?

Ed

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D102542009-13082002><FONT =
color=3D#0000ff>Hi,</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft>&nbsp;</DIV>
  <P>I want to have a certificate&nbsp;viewer for linux. It's prefered =
to be=20
  GUI. Can anybody help me to find it?&nbsp;<SPAN =
class=3D102542009-13082002><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></P></BLOCKQUOTE>
<P><SPAN class=3D102542009-13082002><FONT color=3D#0000ff>Have you =
checked out <A=20
href=3D"http://www.iit.edu/~gawojar/ldap/features.html">http://www.iit.ed=
u/~gawojar/ldap/features.html</A>&nbsp;?</FONT></SPAN></P>
<P><SPAN class=3D102542009-13082002><FONT =
color=3D#0000ff>Ed</FONT></SPAN></P>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <P><SPAN =
class=3D102542009-13082002>&nbsp;</SPAN></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0010_01C242ED.DF0A9410--

Date: Tue, 13 Aug 2002 00:37:50 -0700 (PDT)
From: af Lamei <[email-masked]>
Subject: certificate viewer for linux
To: [email-masked]
Sender: [email-masked]

--0-94754720-1029224270=:36974
Content-Type: text/plain; charset=us-ascii

hi,

I want to have a certificate viewer for linux. It's prefered to be GUI. Can anybody help me to find it? 

regards,

af 

---------------------------------
Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs
--0-94754720-1029224270=:36974
Content-Type: text/html; charset=us-ascii

<P>hi,</P>
<P>I want to have a certificate&nbsp;viewer for linux. It's prefered to be GUI. Can anybody help me to find it? </P>
<P>regards,</P>
<P>af </P><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/careers/mailsig/new/*http://www.hotjobs.com">HotJobs, a Yahoo! service</a> - Search Thousands of New Jobs
--0-94754720-1029224270=:36974--

Date: Tue, 13 Aug 2002 10:08:20 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Basic constraints processing for SSL
Sender: [email-masked]

Laurence Lundblade <[email-masked]> writes:

>However, if you examine the root / CA certs distributed with IE, a number of
>them do NOT have the BasicConstraints extension.

Yup.  There are also a number of CAs which do this which aren't hardcoded into
IE.  What's scary about this is that nothing seems to notice this problem
(I've had at least two CAs claim that the practice is OK because no software
objects to it).

Peter.

Date: Mon, 12 Aug 2002 15:04:32 -0700
To: "Housley, Russ" <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: Basic constraints processing for SSL
Cc: [email-masked]
Sender: [email-masked]

Oops, should have looked at 3280.

So now it's OK to have BasicConstraints in end entities. That helps a lot 
with SSL compatibility.

I understand that an intermediate cert MUST have BasicConstraints for RFC 
2459 / 3280 compliance, but is that a good thing for SSL? I assume that is 
what Netscape and Mozilla due to avoid the problem that IE has, but I 
haven't tested it yet. I also assume they only apply the requirement to 
intermediate certs and not roots due to the number of roots without the 
extension.

So now a few wording comments:

It makes sense to me that trusted anchor roots are implicitly used to 
verify other certs and thus don't need BasicConstraints, however the first 
sentence of the 4th paragraph of 4.2.1.10 says they must have the 
extension, doesn't it?

Seems like the first paragraph of 4.2.1.10 could be improved. It says "The 
basic constraints extension identifies whether the subject of the 
certificate is a CA....". Is what is meant that the subject *names* a CA? 
In that case we have a problem with intermediate certs which don't 
necessarily name a CA in the subject but include BasicConstraints. If what 
is meant is that the cert can be used to verify other certs, then that's 
different and it's not very clear.

In general I have trouble with the term "CA certificate" because I don't 
know if it means a trusted root certificate or a certificate used to verify 
other certificates. For example see 6.1.4 (k).

LL

At 04:58 PM 8/12/2002 -0400, Housley, Russ wrote:
>Laurence:
>
>Please take a look at RFC 3280.  I think it provides a more complete 
>description.
>
>A self-signed root certificate is a mechanism for distributing trust 
>anchors.  As such, they need not contain any certificate extensions to 
>provide the information necessary for the algorithm to function 
>properly.  Intermediate CA certificates MUST contain the basic constraints 
>extension with the cA bit set to conform to either RFC 2459 or RFC 3280.
>
>Russ
>
>
>At 11:16 AM 8/12/2002 -0700, Laurence Lundblade wrote:
>
>>I'd like to check my understanding of basic constraints processing for 
>>SSL to be sure our implementation is right in light of the recent IE 
>>problems. This group seems the best one to me, but send me off somewhere 
>>else if you think there's a better place. I know there's no document or 
>>standard and 2459 doesn't necessarily apply to SSL.
>>
>>
>>RFC 2459 4.2.1.10 says that CA's must set CA to TRUE and end entities 
>>should not have the extension present. That is the client software would 
>>give an error when any cert without BasicConstraints and CA=TRUE is used 
>>verify another cert.  That certainly will defend against the recently 
>>published IE attack.
>>
>>However, if you examine the root / CA certs distributed with IE, a number 
>>of them do NOT have the BasicConstraints extension. I believe the yields 
>>section 4.2.1.10 unworkable for SSL. (I'm not suggesting a change in 
>>2459, just making the point that it doesn't seem to work for SSL).
>>
>>I think there are two possible implementations that might work for SSL:
>>
>>1) Require BasicConstraints and CA=TRUE for intermediate certs only, not 
>>roots. This will defend against the attack. The (admittedly few) 
>>intermediate certs I've seen to have BasicConstraints and CA=TRUE.
>>
>>2) If a cert is being used to verify another and BasicConstraints is 
>>present, make sure it is false. This goes against 4.2.1.10 because it 
>>says that end entities should not include BasicConstraints, but for SSL 
>>the majority of the certs have it present and when present it it false.
>>
>>Comments?
>>
>>
>>Further, I did an analysis of 50 or so random SSL server certs and found 
>>the following:
>>     15 VeriSign issued certs had BasicConstraints present, not critical, 
>> CA=FALSE
>>     10 RSA SSCA (VeriSign) issued certs had BasicConstraints present, 
>> not critical, CA=FALSE
>>     9 Thawte issued certs has BasicConstraints present, CRITICAL, CA=FALSE
>>     7 RSA SSCA (VeriSign) issued certs had no BasicConstraints present.
>>     2 others had no BasicConstraints present.
>>
>>Clearly the majority have BasicConstraints present, CA=FALSE and I can 
>>understand why a CA would do that. It helps defend against this attack 
>>and has no down side. That it seems no SSL implementation would be so 
>>strict that it would error out if BasicConstraints is present on an end 
>>entity. I can also imagine that Thawte is trying to be extra cautious  by 
>>making it critical, but what is confusing is why some RSA SSCA certs have 
>>it present and some don't. Any ideas?
>>
>>Also, I did an analysis of the root / CA certs bundled with IE and go the 
>>following:
>>    34 had BasicConstraints present and critical
>>    28 had BasicConstraints present and NOT critical
>>    40 do not have BasicConstraints present
>>
>>The last number is the most troubling to me because it goes against RFC 
>>2459, and because I can't imagine why a CA would do it. It would seem 
>>either the CA operators aren't aware of this attack, or there's enough 
>>bad software out there that chokes BasicConstraints being present, or it 
>>doesn't matter because the check is never done on the root, just 
>>intermediates as I suggest above.  Some of the CA's with no 
>>BasicConstraints present are:
>>    VeriSign Class 1
>>    VeriSign Individual Software Publishers
>>    ... many other VeriSign roots
>>    C&W HKT SecureNet CA root
>>    Japan Certification Services
>>    RSA SSCA
>>    Microsoft
>>
>>Thanks, LL
>>
>>
>>
>>
>>,

Date: Tue, 13 Aug 2002 09:55:05 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Certificate Path Validation - criticality indicator
Sender: [email-masked]

Peter Sylvester <[email-masked]> writes:

>Tt seems to me that the treatmeant of the criticality indicator in the basic
>validation algorithm is a useless. As far as I see, the field is never tested
>at all in the algorithm.

It must be done that way for Windows compatibility :-).

Peter.

From: "Housley, Russ" <[email-masked]>
To: Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Date: Mon, 12 Aug 2002 16:58:48 -0400
Subject: Re: Basic constraints processing for SSL
Sender: [email-masked]

Laurence:

Please take a look at RFC 3280.  I think it provides a more complete 
description.

A self-signed root certificate is a mechanism for distributing trust 
anchors.  As such, they need not contain any certificate extensions to 
provide the information necessary for the algorithm to function 
properly.  Intermediate CA certificates MUST contain the basic constraints 
extension with the cA bit set to conform to either RFC 2459 or RFC 3280.

Russ

At 11:16 AM 8/12/2002 -0700, Laurence Lundblade wrote:

>I'd like to check my understanding of basic constraints processing for SSL 
>to be sure our implementation is right in light of the recent IE problems. 
>This group seems the best one to me, but send me off somewhere else if you 
>think there's a better place. I know there's no document or standard and 
>2459 doesn't necessarily apply to SSL.
>
>
>RFC 2459 4.2.1.10 says that CA's must set CA to TRUE and end entities 
>should not have the extension present. That is the client software would 
>give an error when any cert without BasicConstraints and CA=TRUE is used 
>verify another cert.  That certainly will defend against the recently 
>published IE attack.
>
>However, if you examine the root / CA certs distributed with IE, a number 
>of them do NOT have the BasicConstraints extension. I believe the yields 
>section 4.2.1.10 unworkable for SSL. (I'm not suggesting a change in 2459, 
>just making the point that it doesn't seem to work for SSL).
>
>I think there are two possible implementations that might work for SSL:
>
>1) Require BasicConstraints and CA=TRUE for intermediate certs only, not 
>roots. This will defend against the attack. The (admittedly few) 
>intermediate certs I've seen to have BasicConstraints and CA=TRUE.
>
>2) If a cert is being used to verify another and BasicConstraints is 
>present, make sure it is false. This goes against 4.2.1.10 because it says 
>that end entities should not include BasicConstraints, but for SSL the 
>majority of the certs have it present and when present it it false.
>
>Comments?
>
>
>Further, I did an analysis of 50 or so random SSL server certs and found 
>the following:
>     15 VeriSign issued certs had BasicConstraints present, not critical, 
> CA=FALSE
>     10 RSA SSCA (VeriSign) issued certs had BasicConstraints present, not 
> critical, CA=FALSE
>     9 Thawte issued certs has BasicConstraints present, CRITICAL, CA=FALSE
>     7 RSA SSCA (VeriSign) issued certs had no BasicConstraints present.
>     2 others had no BasicConstraints present.
>
>Clearly the majority have BasicConstraints present, CA=FALSE and I can 
>understand why a CA would do that. It helps defend against this attack and 
>has no down side. That it seems no SSL implementation would be so strict 
>that it would error out if BasicConstraints is present on an end entity. I 
>can also imagine that Thawte is trying to be extra cautious  by making it 
>critical, but what is confusing is why some RSA SSCA certs have it present 
>and some don't. Any ideas?
>
>Also, I did an analysis of the root / CA certs bundled with IE and go the 
>following:
>    34 had BasicConstraints present and critical
>    28 had BasicConstraints present and NOT critical
>    40 do not have BasicConstraints present
>
>The last number is the most troubling to me because it goes against RFC 
>2459, and because I can't imagine why a CA would do it. It would seem 
>either the CA operators aren't aware of this attack, or there's enough bad 
>software out there that chokes BasicConstraints being present, or it 
>doesn't matter because the check is never done on the root, just 
>intermediates as I suggest above.  Some of the CA's with no 
>BasicConstraints present are:
>    VeriSign Class 1
>    VeriSign Individual Software Publishers
>    ... many other VeriSign roots
>    C&W HKT SecureNet CA root
>    Japan Certification Services
>    RSA SSCA
>    Microsoft
>
>Thanks, LL
>
>
>
>
>,

Date: Mon, 12 Aug 2002 11:16:29 -0700
To: [email-masked]
From: Laurence Lundblade <[email-masked]>
Subject: Basic constraints processing for SSL
Sender: [email-masked]

I'd like to check my understanding of basic constraints processing for SSL 
to be sure our implementation is right in light of the recent IE problems. 
This group seems the best one to me, but send me off somewhere else if you 
think there's a better place. I know there's no document or standard and 
2459 doesn't necessarily apply to SSL.

RFC 2459 4.2.1.10 says that CA's must set CA to TRUE and end entities 
should not have the extension present. That is the client software would 
give an error when any cert without BasicConstraints and CA=TRUE is used 
verify another cert.  That certainly will defend against the recently 
published IE attack.

However, if you examine the root / CA certs distributed with IE, a number 
of them do NOT have the BasicConstraints extension. I believe the yields 
section 4.2.1.10 unworkable for SSL. (I'm not suggesting a change in 2459, 
just making the point that it doesn't seem to work for SSL).

I think there are two possible implementations that might work for SSL:

1) Require BasicConstraints and CA=TRUE for intermediate certs only, not 
roots. This will defend against the attack. The (admittedly few) 
intermediate certs I've seen to have BasicConstraints and CA=TRUE.

2) If a cert is being used to verify another and BasicConstraints is 
present, make sure it is false. This goes against 4.2.1.10 because it says 
that end entities should not include BasicConstraints, but for SSL the 
majority of the certs have it present and when present it it false.

Comments?

Further, I did an analysis of 50 or so random SSL server certs and found 
the following:
     15 VeriSign issued certs had BasicConstraints present, not critical, 
CA=FALSE
     10 RSA SSCA (VeriSign) issued certs had BasicConstraints present, not 
critical, CA=FALSE
     9 Thawte issued certs has BasicConstraints present, CRITICAL, CA=FALSE
     7 RSA SSCA (VeriSign) issued certs had no BasicConstraints present.
     2 others had no BasicConstraints present.

Clearly the majority have BasicConstraints present, CA=FALSE and I can 
understand why a CA would do that. It helps defend against this attack and 
has no down side. That it seems no SSL implementation would be so strict 
that it would error out if BasicConstraints is present on an end entity. I 
can also imagine that Thawte is trying to be extra cautious  by making it 
critical, but what is confusing is why some RSA SSCA certs have it present 
and some don't. Any ideas?

Also, I did an analysis of the root / CA certs bundled with IE and go the 
following:
    34 had BasicConstraints present and critical
    28 had BasicConstraints present and NOT critical
    40 do not have BasicConstraints present

The last number is the most troubling to me because it goes against RFC 
2459, and because I can't imagine why a CA would do it. It would seem 
either the CA operators aren't aware of this attack, or there's enough bad 
software out there that chokes BasicConstraints being present, or it 
doesn't matter because the check is never done on the root, just 
intermediates as I suggest above.  Some of the CA's with no 
BasicConstraints present are:
    VeriSign Class 1
    VeriSign Individual Software Publishers
    ... many other VeriSign roots
    C&W HKT SecureNet CA root
    Japan Certification Services
    RSA SSCA
    Microsoft

Thanks, LL

, 

Date: Mon, 12 Aug 2002 18:26:05 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Jeff Jacoby <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate Path Validation
Sender: [email-masked]

Jeff,

(...)

> > Note the basic path validation described in RFC3280 does *not* allow
> > validation in the past since it still says:
> >
> > "6.1.1  Inputs.  This algorithm assumes the following seven inputs are
> > provided to the path processing logic: (...) (b)  the current
> > date/time."
> >
> > :-(
> 
> However, the third paragraph in section 6.1 says:
> 
>   "The algorithm presented in this section validates the certificate
>    with respect to the current date and time.  A conformant
>    implementation MAY also support validation with respect to some point
>    in the past.  Note that mechanisms are not available for validating a
>    certificate with respect to a time outside the certificate validity
>    period."

Thanks for this remainder. Implementations MUST support validation for the
current time, but MAY also support validation in the past.

Denis
 
> Jeff

Date: Mon, 12 Aug 2002 09:11:56 -0700
From: Jeff Jacoby <[email-masked]>
Organization: RSA Security, Inc.
To: [email-masked]
Subject: Re: Certificate Path Validation
Sender: [email-masked]

Denis Pinkas wrote:
> 
> Santosh and Sharon,
> 
> > Sharon: Not only do I agree with you, but an appropriate
> interpretation of
> > both the X.509 and RFC 3280 is that aside from getting the following
> > information from the trust anchor, no fields in the base trust anchor
> > certificate (e.g., validity period) need to be processed:
> >
> >    * Issuer DN
> >    * Signature Algorithm
> >    * Public key
> >    * Parameters, if applicable
> 
> It is just obvious that the trust anchor shall be valid for the time the
> checking is being done.
> 
> Note the basic path validation described in RFC3280 does *not* allow
> validation in the past since it still says:
> 
> "6.1.1  Inputs.  This algorithm assumes the following seven inputs are
> provided to the path processing logic: (...) (b)  the current
> date/time."
> 
> :-(

However, the third paragraph in section 6.1 says:

  "The algorithm presented in this section validates the certificate
   with respect to the current date and time.  A conformant
   implementation MAY also support validation with respect to some point
   in the past.  Note that mechanisms are not available for validating a
   certificate with respect to a time outside the certificate validity
   period."

Jeff

Date: Mon, 12 Aug 2002 15:50:14 +0200 (MET DST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Certificate Path Validation - criticality indicator
Sender: [email-masked]

hi all,

Since one starts a new discussion about 3280, I repeat some
comment that I had send to the editors some time ago. 

Tt seems to me that the treatmeant of the criticality
indicator in the basic validation algorithm is a useless.
As far as I see, the field is never tested at all in the 
algorithm. 

Peter

From: "Santosh Chokhani" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Certificate Path Validation
Date: Mon, 12 Aug 2002 08:05:42 -0400
Importance: Normal
Sender: [email-masked]

Denis:

My interpretation of X.509 and RFC 3280 is that the validity period and
other checks in the trust anchor can be ignored during path validation.

An implementation that checks the validity period and other field is
still compliant.  It is simply doing checks that are not required.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Monday, August 12, 2002 5:26 AM
To: Santosh Chokhani; 'Sharon Boeyen'
Cc: [email-masked]
Subject: Re: Certificate Path Validation

Santosh and Sharon,

> Sharon: Not only do I agree with you, but an appropriate 
> interpretation of both the X.509 and RFC 3280 is that aside from 
> getting the following information from the trust anchor, no fields in 
> the base trust anchor certificate (e.g., validity period) need to be 
> processed:
>
>    * Issuer DN
>    * Signature Algorithm
>    * Public key
>    * Parameters, if applicable

It is just obvious that the trust anchor shall be valid for the time the
checking is being done.

Note the basic path validation described in RFC3280 does *not* allow
validation in the past since it still says:

"6.1.1  Inputs.  This algorithm assumes the following seven inputs are
provided to the path processing logic: (...) (b)  the current
date/time."

:-(

When CMP is being used, self-signed certificates can be used to make
sure that the trust anchor is currentltly valid and to smoothly change
the trust anchor.

Here again, self-signed certificates are not mandatory to be used, but
if they are used, then their validity period shall not be ignored.

In reply to Sharon, I have seen no text to say that some extensions in
self-signed certificates shall be ignored. If we had to do something
(which I do not currently think) then the approach should be to
constrain the format of self-signed certificates and to say that
self-signed certificate SHALL NOT contain or SHALL only contain such or
such extension, ... and we have not done that, AFAIK.

Denis

>    *
>
>      -----Original Message-----
>      From: [email-masked]
>      [mailto:[email-masked]] On Behalf Of Sharon Boeyen
>
>      Sent: Friday, August 09, 2002 1:59 PM
>      To: 'Steve Hanna'; Denis Pinkas
>      Cc: Sunil Agrawal; [email-masked]
>      Subject: RE: Certificate Path Validation
>
>      From a 509 standpoint I agree with Steve. I remember a defect
>      that we
>      progressed to make it clear that extensions in a self-signed
>      cert are NOT
>      used during path validation. I don't have it at my fingertips
>      but could dig it up if necessary.
>
>      As for name constraints, this is one area where, unlike all
>      those related to policy, the path validation procedure does NOT
>      have an input variable whereby a particular value can be input
>      as the initial set of permitted/excluded subtrees.
>      Cross-certificates are the only way to impose such restrictions
>      in the standard. In 10.3 of X.509 2000 note that the
>      initialization step for path validation sets the permitted
>      subtrees variable to unbounded and sets the excluded subtrees
>      variable to an empty set.
>
>      Note that in the current set of proposed enhancements to X.509,
>      (
>
ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output/6N12223CertEnhancem
ent4thWD.doc
>      )Issue number 5 proposes an enhancement that would allow the
>      permitted and excluded subtree variables to be initialized to
>      values other than unbounded and empty set respectively. However
>      that is not yet standardized, nor is it related to extensions in
>      self-signed certs.
>
>      -----Original Message-----
>      From: Steve Hanna [mailto:[email-masked]]
>      Sent: Friday, August 09, 2002 9:51 AM
>      To: Denis Pinkas
>      Cc: Sunil Agrawal; [email-masked]
>      Subject: Re: Certificate Path Validation
>
>
>      I agree with most things that Denis wrote, however...
>
>      Denis Pinkas wrote:
>      > If the trust anchor contains name restrictions, then they MUST
>      be
>      > used as part of the initial permitted_subtrees.
>
>      This does not agree with RFC 3280, which says in section 6.1.2,
>      subsection b that "the initial value [for the permitted_subtrees
>
>      state variable] for the set for Distinguished Names is the set
>      of
>      all Distinguished names; the initial value for the set of RFC822
>
>      names is the set of all RFC822 names, etc." Section 6.2 says
>      that
>      "an implementation MAY modify the algorithm to apply name
>      constraints to a specific trust anchor during the initialization
>
>      phase", so this is permitted but not part of the Basic Path
>      Validation algorithm described in section 6.1.
>
>      Denis also wrote:
>      > In addition, you can apply additional name restrictions. This
>      > means that the initial permitted_subtrees conditions may come
>      > both from name restritions contained in the self-signed
>      > certificate (if any) and from name restrictions external
>      > to the trust nchor (which may or may not be specified in
>      > the form of a self-signed certificate).
>
>      Again, RFC 3280 allows implementations to do this as a
>      supplement
>      to the Basic Path Validation algorithm. In fact, they are
>      allowed
>      to apply *any* additional restrictions on valid paths that they
>      like. Section 6.1 says "an application MAY augment this
>      algorithm
>      to further limit the set of valid paths." Applying additional
>      name constraints to trust anchors is just one example.
>
>      To provide some background, this topic has been discussed before
>
>      on the PKIX list (as have most PKI-related topics). Some people
>      believe that it's helpful to apply name constraints to trust
>      anchors to handle the case when they're only trusted for part
>      of the namespace. Others feel that this is best handled by
>      having a CA issue cross-certificates that contain those name
>      constraints and then making that CA be the trust anchor. The
>      former solution avoids the need to establish another CA. The
>      latter solution allows the constraints to be changed (or
>      additional
>      trust links established) without requiring every application
>      to update its trust anchors. This issue was resolved by having
>      RFC 3280 describe a Basic Path Validation algorithm that is
>      mandatory to implement and optional extensions to it, such as
>      name constraints on trust anchors.
>
>      -Steve
>

Date: Mon, 12 Aug 2002 12:27:01 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Enrique Velasco <[email-masked]>
CC: [email-masked]
Subject: Re: about Intermediate CA CRLs
Sender: [email-masked]

Enrique,

> Should an Intermediate CA Certificate include the CRL Distribution Point
> Extension?
 
> One might want to revoke an Intermediate CA Certificate if there's a key
> compromise, therefore publishing a CRL, but that would be completely useless
> if no one's checking it, so my first answer to my own question would be YES.
> 
> Then I wonder how can this be done, as the Root CA key should be off-line,
> as recommended.

RFC 3280 states: The CRL is signed using the CRL issuer's private key;

   The cRLDistributionPoints extension is a SEQUENCE of
   DistributionPoint.  A DistributionPoint consists of three fields,
   each of which is optional: distributionPoint, reasons, and cRLIssuer.
   While each of these fields is optional, a DistributionPoint MUST NOT
   consist of only the reasons field; either distributionPoint or
   cRLIssuer MUST be present.  If the certificate issuer is not the CRL
   issuer, then the cRLIssuer field MUST be present and contain the Name
   of the CRL issuer.  

This means that CRLs can be signed by a key different from the CA key.
To achieve that goal, the CA needs to issue a certificate to the CRL Issuer.
 
> I've noticed that only a few Intermediate CA Certificates include a CRL
> Distribution point, and those CRL are valid for several months. So I Imagine
> that issuing such CRL must be a manual (i.e.. not automated) process, done
> only when there is the urge to revoke the Intermediate CA Certificate.

Some products do not support CRL issuers with a key different from the CA
key, but if you want to keep the CA key as "off-line" as possible, RFC 3280
provides you with a solution.

> Any thoughts?
> 
> again,
> 
> Should an Intermediate CA Certificate include the CRL Distribution Point
> Extension?
> and how can this be done?

It is highly advisable to include in every certificate either a CDP
extension or an AIA extension, so that in an "Open PKI" any relying party
may know where to fetch the revocation status information (CRLs or OCSP
responses).

Denis  
 
>         Enrique Velasco
>         Acepta.com

Date: Mon, 12 Aug 2002 11:34:33 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Rob Stradling <[email-masked]>
CC: [email-masked]
Subject: Re: RFC3161 Timestamping AlgorithmIdentifiers
Sender: [email-masked]

Rob,

> We are currently implementing an RFC3161-compliant timestamping server.
> Various timestamping clients that we have downloaded always encode the
> MessageImprint->hashAlgorithm AlgorithmIdentifier with the "parameters"
> field missing. Whilst I accept that X.509 and RFC3280 define the
> AlgorithmIdentifier "parameters" field as OPTIONAL,

 RFC 3280 defines AlgorithmIdentifier as:

 AlgorithmIdentifier  ::=  SEQUENCE  {
      algorithm               OBJECT IDENTIFIER,
      parameters              ANY DEFINED BY algorithm OPTIONAL  }
                                 -- contains a value of the type
                                 -- registered for use with the
                                 -- algorithm object identifier value

 RFC 3161 does not make any additional interpretation of it. The content of
 the field parameters is only and fully dependent upon the algorithm.

 Denis

> surely this definition is "overridden" by PKCS#1 and RFC3279.  RFC3279
> (section 2.2.1) states, for MD2/MD5/SHA-1 with RSA, that "the parameters
> component of that type SHALL be the ASN.1 type NULL".  RFC2119, of course,
> defines "SHALL" as "an absolute requirement of the specification". If we
> follow PKCS#1 and RFC3279, we appear to be incompatible with other
> timestamping clients/servers.
> 
> 1). Who is technically correct?
>
> 2). Regardless of who is technically correct, should our timestamping server
> allow "parameters" to be OPTIONAL or not (for MD2/MD5/SHA-1 with RSA)
> in    
>
> a). the requests it receives?    
> b). the responses it generates? 
>
> Thanks in advance. 
>
> Rob StradlingComodo Research Lab

Date: Mon, 12 Aug 2002 11:26:04 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate Path Validation
Sender: [email-masked]

Santosh and Sharon,

> Sharon: Not only do I agree with you, but an appropriate interpretation of
> both the X.509 and RFC 3280 is that aside from getting the following
> information from the trust anchor, no fields in the base trust anchor
> certificate (e.g., validity period) need to be processed:
>
>    * Issuer DN
>    * Signature Algorithm
>    * Public key
>    * Parameters, if applicable

It is just obvious that the trust anchor shall be valid for the time the
checking is being done.

Note the basic path validation described in RFC3280 does *not* allow
validation in the past since it still says:

"6.1.1  Inputs.  This algorithm assumes the following seven inputs are
provided to the path processing logic: (...) (b)  the current date/time."

:-(

When CMP is being used, self-signed certificates can be used to make sure
that the trust anchor is currentltly valid and to smoothly change the trust
anchor.

Here again, self-signed certificates are not mandatory to be used, but if
they are used, then their validity period shall not be ignored.

In reply to Sharon, I have seen no text to say that some extensions in
self-signed certificates shall be ignored. If we had to do something (which
I do not currently think) then the approach should be to constrain the
format of self-signed certificates and to say that self-signed certificate
SHALL NOT contain or SHALL only contain such or such extension, ... and we
have not done that, AFAIK.

Denis

>    *
>
>      -----Original Message-----
>      From: [email-masked]
>      [mailto:[email-masked]] On Behalf Of Sharon Boeyen
>
>      Sent: Friday, August 09, 2002 1:59 PM
>      To: 'Steve Hanna'; Denis Pinkas
>      Cc: Sunil Agrawal; [email-masked]
>      Subject: RE: Certificate Path Validation
>
>      From a 509 standpoint I agree with Steve. I remember a defect
>      that we
>      progressed to make it clear that extensions in a self-signed
>      cert are NOT
>      used during path validation. I don't have it at my fingertips
>      but could dig it up if necessary.
>
>      As for name constraints, this is one area where, unlike all
>      those related to policy, the path validation procedure does NOT
>      have an input variable whereby a particular value can be input
>      as the initial set of permitted/excluded subtrees.
>      Cross-certificates are the only way to impose such restrictions
>      in the standard. In 10.3 of X.509 2000 note that the
>      initialization step for path validation sets the permitted
>      subtrees variable to unbounded and sets the excluded subtrees
>      variable to an empty set.
>
>      Note that in the current set of proposed enhancements to X.509,
>      (
>      ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output/6N12223CertEnhancement4thWD.doc
>      )Issue number 5 proposes an enhancement that would allow the
>      permitted and excluded subtree variables to be initialized to
>      values other than unbounded and empty set respectively. However
>      that is not yet standardized, nor is it related to extensions in
>      self-signed certs.
>
>      -----Original Message-----
>      From: Steve Hanna [mailto:[email-masked]]
>      Sent: Friday, August 09, 2002 9:51 AM
>      To: Denis Pinkas
>      Cc: Sunil Agrawal; [email-masked]
>      Subject: Re: Certificate Path Validation
>
>
>      I agree with most things that Denis wrote, however...
>
>      Denis Pinkas wrote:
>      > If the trust anchor contains name restrictions, then they MUST
>      be
>      > used as part of the initial permitted_subtrees.
>
>      This does not agree with RFC 3280, which says in section 6.1.2,
>      subsection b that "the initial value [for the permitted_subtrees
>
>      state variable] for the set for Distinguished Names is the set
>      of
>      all Distinguished names; the initial value for the set of RFC822
>
>      names is the set of all RFC822 names, etc." Section 6.2 says
>      that
>      "an implementation MAY modify the algorithm to apply name
>      constraints to a specific trust anchor during the initialization
>
>      phase", so this is permitted but not part of the Basic Path
>      Validation algorithm described in section 6.1.
>
>      Denis also wrote:
>      > In addition, you can apply additional name restrictions. This
>      > means that the initial permitted_subtrees conditions may come
>      > both from name restritions contained in the self-signed
>      > certificate (if any) and from name restrictions external
>      > to the trust nchor (which may or may not be specified in
>      > the form of a self-signed certificate).
>
>      Again, RFC 3280 allows implementations to do this as a
>      supplement
>      to the Basic Path Validation algorithm. In fact, they are
>      allowed
>      to apply *any* additional restrictions on valid paths that they
>      like. Section 6.1 says "an application MAY augment this
>      algorithm
>      to further limit the set of valid paths." Applying additional
>      name constraints to trust anchors is just one example.
>
>      To provide some background, this topic has been discussed before
>
>      on the PKIX list (as have most PKI-related topics). Some people
>      believe that it's helpful to apply name constraints to trust
>      anchors to handle the case when they're only trusted for part
>      of the namespace. Others feel that this is best handled by
>      having a CA issue cross-certificates that contain those name
>      constraints and then making that CA be the trust anchor. The
>      former solution avoids the need to establish another CA. The
>      latter solution allows the constraints to be changed (or
>      additional
>      trust links established) without requiring every application
>      to update its trust anchors. This issue was resolved by having
>      RFC 3280 describe a Basic Path Validation algorithm that is
>      mandatory to implement and optional extensions to it, such as
>      name constraints on trust anchors.
>
>      -Steve
>

Content-return: allowed
Date: Sun, 11 Aug 2002 05:23:14 -0700
From: Peter Williams <[email-masked]>
Subject: RE: OCSP concept question
To: "'Jean-Marc Desperrier '" <[email-masked]>, "'Gene Hilborn '" <[email-masked]>, "'ietf-pkix '" <[email-masked]>
Sender: [email-masked]

Peter dice que:

(a) We need to differentiate between the OCSP (P for protocol)
and services supported by the protocol. IETF never
standardized any OCSP services, note, though some OCSP service
semantics are implicit in some of our standard protocols
and profiles. 

(b) We can specify an archival service whenever we get together, note.
It doesnt have to be pure-OCSP, either. I'm far more interested in
real working systems, than well-architected abstract protocols,
personally. I think we can get a lot more milage from
the Internet's current support for CRL syntaxes, by innovating
with the commodity components.

(c) on the matter of MUST, SHOULD etc, structured CRL archival has 
never been mandatory in IETF, but has always been a part of the 
Internet model. See 1422:

"In the absence of ubiquitous X.500 directory services, the IPRA will
require 
each PCA to provide, for its users, robust database access to CRLs for the 
Internet hierarchy, i.e., the IPRA CRL, PCA CRLs, and CRLs from all CAs. 
The means by which this database is implemented is to be coordinated 
between the IPRA and PCAs. This database will be accessible via email 
as specified in RFC 1424, both for retrieval of (current) CRLs by any user, 
and for submission of new CRLs by CAs, PCAs and the IPRA. Individual 
PCAs also may elect to maintain CRL archives for their CAs, but this is 
not required by this policy."
 
Peter.

----------

SIDE BAR: for folks interested possibly in new work
in OCSP-archival matters:

(1) S/MIME archival

An OCSP responder supporting digital signatures in
a TNI-TCSEC evaluated network can support the original TNI definition of
non-repudiation by maintain an email-style archive record.
To support the proof semantics of ProofOfOriginWithNR, the
OCSP responder originates for local storage a signed S/MIME msg 
whose contents are: validated signatures/on-source-CRLs, and whatever
supporting certs and other (recursive) data were used to 
determine revocation status of the cert on the certification path 
that  supported the possibly-indirect CRL. 

The OCSP responder is responsible for records mgt - that is, 
resigning the "repository document" (a legal term) to maintain its
currency as an easily verifiable authenticated record.
There is nothing new in any of this, of course. 

Lets recall that S/MIME is both a writer-to-reader
email standard and a set of reusable, nestable security 
procedures. (See some recent IETF work on harmonizing
Allied X.400 EITs with the underlying CMSyntaxes)

For example, I specified non writer-to-reader use of PKCS7 for
Cisco's SCEP, back with Alex in 1996. That certificate
management standard (de facto) is probably now the most 
widely-used, open, remote automated router key management mechanism
in the Internet, and is a credit to our collective product
design judgements about PKCS7/CMS! Alex's getCRL facility
addition is probably the most widely used IPSEC revocation-mechanism 
in the world! Microsoft's support for it works v nicely,
and was easy to modify so that a CRL partition of just
the requested cert status is dynamically generated 
interactively! This gets OCSP-like behaviour via CMS syntaxes
support into legacy IPSEC router stacks that only supports CRL
syntaxes.

But back to the main point and conclusion:

An OCSP response can communicate the S/MIME signed
NR-repository msg mentioned above, bearing its NR-relevant archive
information, in the OCSP response. Dont forget, OCSP is a
framework: profiles and future standards can add message types 
to the protocol. The better implementations are built to plug in support
for such protocol extensions, in fielded systems, providing
their services according to detection of a cert policy value
in the requestor's user cert.

(2)R&D Specification Offer

On a slightly different but related tack, I have some 
profiling  templates for specifying OCSP protocols and validation
services, for fully-modelled OSI application processes, if any 
LARGE, fun projects would like to take part in an academic 
specification experiment with me (at cs.ucl.ac.uk, not valicert) 
on this type of advanced OCSP  usage. You'd need really to need 
to be familiar with the full  nomenclature of the OSI application 
layer model, however, to use the results for certification purposes.

Peter.

-----Original Message-----
From: Jean-Marc Desperrier
To: Gene Hilborn; ietf-pkix
Sent: 8/8/02 2:01 AM
Subject: Re: OCSP concept question

Gene Hilborn a dit :

>While both CRLs and OCSP have a defined syntax for conveying the
>information of WHEN a certificate was revoked, neither is required to
>indefinitely maintain this information as an historical record.
>
>RFC 2459 does not require or recommend archiving revocation after
expiry:
>"An entry may be removed from the CRL after appearing on one regularly
>scheduled CRL issued beyond the revoked certificate's validity period."
>
>RFC 2560 makes such archival information optional for OCSP:  'An OCSP
>responder MAY choose to retain revocation information beyond a
>certificate's expiration. The date obtained by subtracting this
retention
>interval value from the producedAt time in a response is defined as the
>certificate's "archive cutoff" date.'
>
>Thus, since CRLs and OCSP responders are not normally set up as
historical
>archives, they do not facilitate determining if and when a certificate
was
>revoked when they are consulted long after the expiry date on the
>certificate.
>
Which is why in my first answer, I said that the responder should better

check the information as soon as it receives the signature and save the 
response it received.

But still taking care of how he handles the case where the certificate 
was just on hold.

Content-return: allowed
Date: Sat, 10 Aug 2002 09:49:36 -0700
From: Peter Williams <[email-masked]>
Subject: RE: about Intermediate CA CRLs
To: "'Enrique Velasco '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

For PKIX purposes, intermediate CAs on a certification path
are no different to the CAs to which users are subscribed.

If two leaf CAs are in two disconnected hierarchies, and 
they cross-certify, then each is an intermediate CA in the
users's forward or reverse certification paths. Each CA cert
may bear a CRLDP. Path processing cannot assume that only
the subject's CA cert bears a CRLDP.

For example, a military messaging DUA collects both forward and 
reverse cert paths before releasing a signed directory opertion
requesting a signed response. It should check both forward and 
reverse paths for validity and  release policy compliance, 
following CRLDPs for both subject's CRLDPs, in the case given 
above. Which CA cert is an "intermediate" CA is obviously 
relative, and a matter of perspective. Such perspective should 
not matter to a local (or DPV-hosted) cert validation module.

Peter.

-----Original Message-----
From: Enrique Velasco
To: [email-masked]
Sent: 8/9/02 8:16 AM
Subject: about Intermediate CA CRLs

Should an Intermediate CA Certificate include the CRL Distribution Point
Extension?

From: "Santosh Chokhani" <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "'Steve Hanna'" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
Cc: "'Sunil Agrawal'" <[email-masked]>, <[email-masked]>
Subject: RE: Certificate Path Validation
Date: Fri, 9 Aug 2002 21:18:48 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0051_01C23FEA.5AF7C680
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Sharon:
 
Not only do I agree with you, but an appropriate interpretation of both
the X.509 and RFC 3280 is that aside from getting the following
information from the trust anchor, no fields in the base trust anchor
certificate (e.g., validity period) need to be processed:

*	Issuer DN
*	Signature Algorithm
*	Public key
*	Parameters, if applicable

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sharon Boeyen
Sent: Friday, August 09, 2002 1:59 PM
To: 'Steve Hanna'; Denis Pinkas
Cc: Sunil Agrawal; [email-masked]
Subject: RE: Certificate Path Validation

>From a 509 standpoint I agree with Steve. I remember a defect that we 
progressed to make it clear that extensions in a self-signed cert are
NOT 
used during path validation. I don't have it at my fingertips but could
dig it up if necessary. 

As for name constraints, this is one area where, unlike all those
related to policy, the path validation procedure does NOT have an input
variable whereby a particular value can be input as the initial set of
permitted/excluded subtrees. Cross-certificates are the only way to
impose such restrictions in the standard. In 10.3 of X.509 2000 note
that the initialization step for path validation sets the permitted
subtrees variable to unbounded and sets the excluded subtrees variable
to an empty set. 

Note that in the current set of proposed enhancements to X.509, (
ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output/6N12223CertEnhancem
ent4thWD.doc )Issue number 5 proposes an enhancement that would allow
the permitted and excluded subtree variables to be initialized to values
other than unbounded and empty set respectively. However that is not yet
standardized, nor is it related to extensions in self-signed certs.

-----Original Message----- 
From: Steve Hanna [mailto:[email-masked]] 
Sent: Friday, August 09, 2002 9:51 AM 
To: Denis Pinkas 
Cc: Sunil Agrawal; [email-masked] 
Subject: Re: Certificate Path Validation 

I agree with most things that Denis wrote, however... 

Denis Pinkas wrote: 
> If the trust anchor contains name restrictions, then they MUST be 
> used as part of the initial permitted_subtrees. 

This does not agree with RFC 3280, which says in section 6.1.2, 
subsection b that "the initial value [for the permitted_subtrees 
state variable] for the set for Distinguished Names is the set of 
all Distinguished names; the initial value for the set of RFC822 
names is the set of all RFC822 names, etc." Section 6.2 says that 
"an implementation MAY modify the algorithm to apply name 
constraints to a specific trust anchor during the initialization 
phase", so this is permitted but not part of the Basic Path 
Validation algorithm described in section 6.1. 

Denis also wrote: 
> In addition, you can apply additional name restrictions. This 
> means that the initial permitted_subtrees conditions may come 
> both from name restritions contained in the self-signed 
> certificate (if any) and from name restrictions external 
> to the trust nchor (which may or may not be specified in 
> the form of a self-signed certificate). 

Again, RFC 3280 allows implementations to do this as a supplement 
to the Basic Path Validation algorithm. In fact, they are allowed 
to apply *any* additional restrictions on valid paths that they 
like. Section 6.1 says "an application MAY augment this algorithm 
to further limit the set of valid paths." Applying additional 
name constraints to trust anchors is just one example. 

To provide some background, this topic has been discussed before 
on the PKIX list (as have most PKI-related topics). Some people 
believe that it's helpful to apply name constraints to trust 
anchors to handle the case when they're only trusted for part 
of the namespace. Others feel that this is best handled by 
having a CA issue cross-certificates that contain those name 
constraints and then making that CA be the trust anchor. The 
former solution avoids the need to establish another CA. The 
latter solution allows the constraints to be changed (or additional 
trust links established) without requiring every application 
to update its trust anchors. This issue was resolved by having 
RFC 3280 describe a Basic Path Validation algorithm that is 
mandatory to implement and optional extensions to it, such as 
name constraints on trust anchors. 

-Steve 

------=_NextPart_000_0051_01C23FEA.5AF7C680
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4916.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D232591600-10082002><FONT face=3DArial color=3D#0000ff =

size=3D2>Sharon:</FONT></SPAN></DIV>
<DIV><SPAN class=3D232591600-10082002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D232591600-10082002><FONT face=3DArial color=3D#0000ff =
size=3D2>Not=20
only do I agree with you, but an appropriate interpretation of both the =
X.509=20
and RFC 3280 is that aside from getting the following information from =
the trust=20
anchor, no fields in the base trust anchor certificate (e.g., validity =
period)=20
need to be processed:</FONT></SPAN></DIV>
<UL>
  <LI><SPAN class=3D232591600-10082002></SPAN><SPAN =
class=3D232591600-10082002><FONT=20
  face=3DArial color=3D#0000ff size=3D2>Issuer DN</FONT></SPAN></LI>
  <LI><SPAN class=3D232591600-10082002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Signature Algorithm</FONT></SPAN></LI>
  <LI><SPAN class=3D232591600-10082002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Public key</FONT></SPAN></LI>
  <LI><SPAN class=3D232591600-10082002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Parameters, if applicable</FONT></SPAN></LI></UL>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Sharon Boeyen<BR><B>Sent:</B> Friday, August 09, 2002 =
1:59=20
  PM<BR><B>To:</B> 'Steve Hanna'; Denis Pinkas<BR><B>Cc:</B> Sunil =
Agrawal;=20
  [email-masked]<BR><B>Subject:</B> RE: Certificate Path=20
  Validation<BR><BR></FONT></DIV>
  <P><FONT size=3D2>From a 509 standpoint I agree with Steve. I remember =
a defect=20
  that we </FONT><BR><FONT size=3D2>progressed to make it clear that =
extensions in=20
  a self-signed cert are NOT</FONT> <BR><FONT size=3D2>used during path=20
  validation. I don't have it at my fingertips but could dig it up if =
necessary.=20
  </FONT></P>
  <P><FONT size=3D2>As for name constraints, this is one area where, =
unlike all=20
  those related to policy, the path validation procedure does NOT have =
an input=20
  variable whereby a particular value can be input as the initial set of =

  permitted/excluded subtrees. Cross-certificates are the only way to =
impose=20
  such restrictions in the standard. In 10.3 of X.509 2000 note that the =

  initialization step for path validation sets the permitted subtrees =
variable=20
  to unbounded and sets the excluded subtrees variable to an empty set.=20
  </FONT></P>
  <P><FONT size=3D2>Note that in the current set of proposed =
enhancements to=20
  X.509, ( <A target=3D_blank=20
  =
href=3D"ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output/6N12223CertE=
nhancement4thWD.doc">ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output=
/6N12223CertEnhancement4thWD.doc</A>=20
  )Issue number 5 proposes an enhancement that would allow the permitted =
and=20
  excluded subtree variables to be initialized to values other than =
unbounded=20
  and empty set respectively. However that is not yet standardized, nor =
is it=20
  related to extensions in self-signed certs.</FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Steve=20
  Hanna [<A=20
  =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT=
>=20
  <BR><FONT size=3D2>Sent: Friday, August 09, 2002 9:51 AM</FONT> =
<BR><FONT=20
  size=3D2>To: Denis Pinkas</FONT> <BR><FONT size=3D2>Cc: Sunil Agrawal; =

  [email-masked]</FONT> <BR><FONT size=3D2>Subject: Re: Certificate =
Path=20
  Validation</FONT> </P><BR><BR>
  <P><FONT size=3D2>I agree with most things that Denis wrote, =
however...</FONT>=20
  </P>
  <P><FONT size=3D2>Denis Pinkas wrote:</FONT> <BR><FONT size=3D2>&gt; =
If the trust=20
  anchor contains name restrictions, then they MUST be</FONT> <BR><FONT=20
  size=3D2>&gt; used as part of the initial permitted_subtrees.</FONT> =
</P>
  <P><FONT size=3D2>This does not agree with RFC 3280, which says in =
section=20
  6.1.2,</FONT> <BR><FONT size=3D2>subsection b that "the initial value =
[for the=20
  permitted_subtrees</FONT> <BR><FONT size=3D2>state variable] for the =
set for=20
  Distinguished Names is the set of</FONT> <BR><FONT size=3D2>all =
Distinguished=20
  names; the initial value for the set of RFC822</FONT> <BR><FONT =
size=3D2>names=20
  is the set of all RFC822 names, etc." Section 6.2 says that</FONT> =
<BR><FONT=20
  size=3D2>"an implementation MAY modify the algorithm to apply =
name</FONT>=20
  <BR><FONT size=3D2>constraints to a specific trust anchor during the=20
  initialization</FONT> <BR><FONT size=3D2>phase", so this is permitted =
but not=20
  part of the Basic Path</FONT> <BR><FONT size=3D2>Validation algorithm =
described=20
  in section 6.1.</FONT> </P>
  <P><FONT size=3D2>Denis also wrote:</FONT> <BR><FONT size=3D2>&gt; In =
addition,=20
  you can apply additional name restrictions. This</FONT> <BR><FONT =
size=3D2>&gt;=20
  means that the initial permitted_subtrees conditions may come</FONT> =
<BR><FONT=20
  size=3D2>&gt; both from name restritions contained in the =
self-signed</FONT>=20
  <BR><FONT size=3D2>&gt; certificate (if any) and from name =
restrictions=20
  external</FONT> <BR><FONT size=3D2>&gt; to the trust nchor (which may =
or may not=20
  be specified in</FONT> <BR><FONT size=3D2>&gt; the form of a =
self-signed=20
  certificate).</FONT> </P>
  <P><FONT size=3D2>Again, RFC 3280 allows implementations to do this as =
a=20
  supplement</FONT> <BR><FONT size=3D2>to the Basic Path Validation =
algorithm. In=20
  fact, they are allowed</FONT> <BR><FONT size=3D2>to apply *any* =
additional=20
  restrictions on valid paths that they</FONT> <BR><FONT size=3D2>like. =
Section=20
  6.1 says "an application MAY augment this algorithm</FONT> <BR><FONT =
size=3D2>to=20
  further limit the set of valid paths." Applying additional</FONT> =
<BR><FONT=20
  size=3D2>name constraints to trust anchors is just one example.</FONT> =
</P>
  <P><FONT size=3D2>To provide some background, this topic has been =
discussed=20
  before</FONT> <BR><FONT size=3D2>on the PKIX list (as have most =
PKI-related=20
  topics). Some people</FONT> <BR><FONT size=3D2>believe that it's =
helpful to=20
  apply name constraints to trust</FONT> <BR><FONT size=3D2>anchors to =
handle the=20
  case when they're only trusted for part</FONT> <BR><FONT size=3D2>of =
the=20
  namespace. Others feel that this is best handled by</FONT> <BR><FONT=20
  size=3D2>having a CA issue cross-certificates that contain those =
name</FONT>=20
  <BR><FONT size=3D2>constraints and then making that CA be the trust =
anchor.=20
  The</FONT> <BR><FONT size=3D2>former solution avoids the need to =
establish=20
  another CA. The</FONT> <BR><FONT size=3D2>latter solution allows the =
constraints=20
  to be changed (or additional</FONT> <BR><FONT size=3D2>trust links =
established)=20
  without requiring every application</FONT> <BR><FONT size=3D2>to =
update its=20
  trust anchors. This issue was resolved by having</FONT> <BR><FONT =
size=3D2>RFC=20
  3280 describe a Basic Path Validation algorithm that is</FONT> =
<BR><FONT=20
  size=3D2>mandatory to implement and optional extensions to it, such =
as</FONT>=20
  <BR><FONT size=3D2>name constraints on trust anchors.</FONT> </P>
  <P><FONT size=3D2>-Steve</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0051_01C23FEA.5AF7C680--

From: Sharon Boeyen <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: Sunil Agrawal <[email-masked]>, [email-masked]
Subject: RE: Certificate Path Validation
Date: Fri, 9 Aug 2002 13:58:35 -0400 
Sender: [email-masked]

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

------_=_NextPart_001_01C23FCE.61B8A960
Content-Type: text/plain

>From a 509 standpoint I agree with Steve. I remember a defect that we 
progressed to make it clear that extensions in a self-signed cert are NOT
used during path validation. I don't have it at my fingertips but could dig
it up if necessary. 

As for name constraints, this is one area where, unlike all those related to
policy, the path validation procedure does NOT have an input variable
whereby a particular value can be input as the initial set of
permitted/excluded subtrees. Cross-certificates are the only way to impose
such restrictions in the standard. In 10.3 of X.509 2000 note that the
initialization step for path validation sets the permitted subtrees variable
to unbounded and sets the excluded subtrees variable to an empty set. 

Note that in the current set of proposed enhancements to X.509, (
ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output/6N12223CertEnhancement4
thWD.doc )Issue number 5 proposes an enhancement that would allow the
permitted and excluded subtree variables to be initialized to values other
than unbounded and empty set respectively. However that is not yet
standardized, nor is it related to extensions in self-signed certs.

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]]
Sent: Friday, August 09, 2002 9:51 AM
To: Denis Pinkas
Cc: Sunil Agrawal; [email-masked]
Subject: Re: Certificate Path Validation

I agree with most things that Denis wrote, however...

Denis Pinkas wrote:
> If the trust anchor contains name restrictions, then they MUST be
> used as part of the initial permitted_subtrees.

This does not agree with RFC 3280, which says in section 6.1.2,
subsection b that "the initial value [for the permitted_subtrees
state variable] for the set for Distinguished Names is the set of
all Distinguished names; the initial value for the set of RFC822
names is the set of all RFC822 names, etc." Section 6.2 says that
"an implementation MAY modify the algorithm to apply name
constraints to a specific trust anchor during the initialization
phase", so this is permitted but not part of the Basic Path
Validation algorithm described in section 6.1.

Denis also wrote:
> In addition, you can apply additional name restrictions. This
> means that the initial permitted_subtrees conditions may come
> both from name restritions contained in the self-signed
> certificate (if any) and from name restrictions external
> to the trust nchor (which may or may not be specified in
> the form of a self-signed certificate).

Again, RFC 3280 allows implementations to do this as a supplement
to the Basic Path Validation algorithm. In fact, they are allowed
to apply *any* additional restrictions on valid paths that they
like. Section 6.1 says "an application MAY augment this algorithm
to further limit the set of valid paths." Applying additional
name constraints to trust anchors is just one example.

To provide some background, this topic has been discussed before
on the PKIX list (as have most PKI-related topics). Some people
believe that it's helpful to apply name constraints to trust
anchors to handle the case when they're only trusted for part
of the namespace. Others feel that this is best handled by
having a CA issue cross-certificates that contain those name
constraints and then making that CA be the trust anchor. The
former solution avoids the need to establish another CA. The
latter solution allows the constraints to be changed (or additional
trust links established) without requiring every application
to update its trust anchors. This issue was resolved by having
RFC 3280 describe a Basic Path Validation algorithm that is
mandatory to implement and optional extensions to it, such as
name constraints on trust anchors.

-Steve

------_=_NextPart_001_01C23FCE.61B8A960
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.2653.12">
<TITLE>RE: Certificate Path Validation</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>From a 509 standpoint I agree with Steve. I remember =
a defect that we </FONT>
<BR><FONT SIZE=3D2>progressed to make it clear that extensions in a =
self-signed cert are NOT</FONT>
<BR><FONT SIZE=3D2>used during path validation. I don't have it at my =
fingertips but could dig it up if necessary. </FONT>
</P>

<P><FONT SIZE=3D2>As for name constraints, this is one area where, =
unlike all those related to policy, the path validation procedure does =
NOT have an input variable whereby a particular value can be input as =
the initial set of permitted/excluded subtrees. Cross-certificates are =
the only way to impose such restrictions in the standard. In 10.3 of =
X.509 2000 note that the initialization step for path validation sets =
the permitted subtrees variable to unbounded and sets the excluded =
subtrees variable to an empty set. </FONT></P>

<P><FONT SIZE=3D2>Note that in the current set of proposed enhancements =
to X.509, ( <A =
HREF=3D"ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output/6N12223Cert=
Enhancement4thWD.doc" =
TARGET=3D"_blank">ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output/6=
N12223CertEnhancement4thWD.doc</A> )Issue number 5 proposes an =
enhancement that would allow the permitted and excluded subtree =
variables to be initialized to values other than unbounded and empty =
set respectively. However that is not yet standardized, nor is it =
related to extensions in self-signed certs.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Steve Hanna [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Friday, August 09, 2002 9:51 AM</FONT>
<BR><FONT SIZE=3D2>To: Denis Pinkas</FONT>
<BR><FONT SIZE=3D2>Cc: Sunil Agrawal; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Certificate Path Validation</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>I agree with most things that Denis wrote, =
however...</FONT>
</P>

<P><FONT SIZE=3D2>Denis Pinkas wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; If the trust anchor contains name restrictions, =
then they MUST be</FONT>
<BR><FONT SIZE=3D2>&gt; used as part of the initial =
permitted_subtrees.</FONT>
</P>

<P><FONT SIZE=3D2>This does not agree with RFC 3280, which says in =
section 6.1.2,</FONT>
<BR><FONT SIZE=3D2>subsection b that &quot;the initial value [for the =
permitted_subtrees</FONT>
<BR><FONT SIZE=3D2>state variable] for the set for Distinguished Names =
is the set of</FONT>
<BR><FONT SIZE=3D2>all Distinguished names; the initial value for the =
set of RFC822</FONT>
<BR><FONT SIZE=3D2>names is the set of all RFC822 names, etc.&quot; =
Section 6.2 says that</FONT>
<BR><FONT SIZE=3D2>&quot;an implementation MAY modify the algorithm to =
apply name</FONT>
<BR><FONT SIZE=3D2>constraints to a specific trust anchor during the =
initialization</FONT>
<BR><FONT SIZE=3D2>phase&quot;, so this is permitted but not part of =
the Basic Path</FONT>
<BR><FONT SIZE=3D2>Validation algorithm described in section =
6.1.</FONT>
</P>

<P><FONT SIZE=3D2>Denis also wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; In addition, you can apply additional name =
restrictions. This</FONT>
<BR><FONT SIZE=3D2>&gt; means that the initial permitted_subtrees =
conditions may come</FONT>
<BR><FONT SIZE=3D2>&gt; both from name restritions contained in the =
self-signed</FONT>
<BR><FONT SIZE=3D2>&gt; certificate (if any) and from name restrictions =
external</FONT>
<BR><FONT SIZE=3D2>&gt; to the trust nchor (which may or may not be =
specified in</FONT>
<BR><FONT SIZE=3D2>&gt; the form of a self-signed certificate).</FONT>
</P>

<P><FONT SIZE=3D2>Again, RFC 3280 allows implementations to do this as =
a supplement</FONT>
<BR><FONT SIZE=3D2>to the Basic Path Validation algorithm. In fact, =
they are allowed</FONT>
<BR><FONT SIZE=3D2>to apply *any* additional restrictions on valid =
paths that they</FONT>
<BR><FONT SIZE=3D2>like. Section 6.1 says &quot;an application MAY =
augment this algorithm</FONT>
<BR><FONT SIZE=3D2>to further limit the set of valid paths.&quot; =
Applying additional</FONT>
<BR><FONT SIZE=3D2>name constraints to trust anchors is just one =
example.</FONT>
</P>

<P><FONT SIZE=3D2>To provide some background, this topic has been =
discussed before</FONT>
<BR><FONT SIZE=3D2>on the PKIX list (as have most PKI-related topics). =
Some people</FONT>
<BR><FONT SIZE=3D2>believe that it's helpful to apply name constraints =
to trust</FONT>
<BR><FONT SIZE=3D2>anchors to handle the case when they're only trusted =
for part</FONT>
<BR><FONT SIZE=3D2>of the namespace. Others feel that this is best =
handled by</FONT>
<BR><FONT SIZE=3D2>having a CA issue cross-certificates that contain =
those name</FONT>
<BR><FONT SIZE=3D2>constraints and then making that CA be the trust =
anchor. The</FONT>
<BR><FONT SIZE=3D2>former solution avoids the need to establish another =
CA. The</FONT>
<BR><FONT SIZE=3D2>latter solution allows the constraints to be changed =
(or additional</FONT>
<BR><FONT SIZE=3D2>trust links established) without requiring every =
application</FONT>
<BR><FONT SIZE=3D2>to update its trust anchors. This issue was resolved =
by having</FONT>
<BR><FONT SIZE=3D2>RFC 3280 describe a Basic Path Validation algorithm =
that is</FONT>
<BR><FONT SIZE=3D2>mandatory to implement and optional extensions to =
it, such as</FONT>
<BR><FONT SIZE=3D2>name constraints on trust anchors.</FONT>
</P>

<P><FONT SIZE=3D2>-Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C23FCE.61B8A960--

From: "Enrique Velasco" <[email-masked]>
To: <[email-masked]>
Subject: about Intermediate CA CRLs
Date: Fri, 9 Aug 2002 11:16:08 -0400
Importance: Normal
Sender: [email-masked]

Should an Intermediate CA Certificate include the CRL Distribution Point
Extension?

One might want to revoke an Intermediate CA Certificate if there's a key
compromise, therefore publishing a CRL, but that would be completely useless
if no one's checking it, so my first answer to my own question would be YES.

Then I wonder how can this be done, as the Root CA key should be off-line,
as recommended.

I've noticed that only a few Intermediate CA Certificates include a CRL
Distribution point, and those CRL are valid for several months. So I Imagine
that issuing such CRL must be a manual (i.e.. not automated) process, done
only when there is the urge to revoke the Intermediate CA Certificate.

Any thoughts?

again,

Should an Intermediate CA Certificate include the CRL Distribution Point
Extension?
and how can this be done?

	Enrique Velasco
	Acepta.com

Date: Fri, 09 Aug 2002 09:50:38 -0400
From: Steve Hanna <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: Sunil Agrawal <[email-masked]>, [email-masked]
Subject: Re: Certificate Path Validation
Sender: [email-masked]

I agree with most things that Denis wrote, however...

Denis Pinkas wrote:
> If the trust anchor contains name restrictions, then they MUST be
> used as part of the initial permitted_subtrees.

This does not agree with RFC 3280, which says in section 6.1.2,
subsection b that "the initial value [for the permitted_subtrees
state variable] for the set for Distinguished Names is the set of
all Distinguished names; the initial value for the set of RFC822
names is the set of all RFC822 names, etc." Section 6.2 says that
"an implementation MAY modify the algorithm to apply name
constraints to a specific trust anchor during the initialization
phase", so this is permitted but not part of the Basic Path
Validation algorithm described in section 6.1.

Denis also wrote:
> In addition, you can apply additional name restrictions. This
> means that the initial permitted_subtrees conditions may come
> both from name restritions contained in the self-signed
> certificate (if any) and from name restrictions external
> to the trust nchor (which may or may not be specified in
> the form of a self-signed certificate).

Again, RFC 3280 allows implementations to do this as a supplement
to the Basic Path Validation algorithm. In fact, they are allowed
to apply *any* additional restrictions on valid paths that they
like. Section 6.1 says "an application MAY augment this algorithm
to further limit the set of valid paths." Applying additional
name constraints to trust anchors is just one example.

To provide some background, this topic has been discussed before
on the PKIX list (as have most PKI-related topics). Some people
believe that it's helpful to apply name constraints to trust
anchors to handle the case when they're only trusted for part
of the namespace. Others feel that this is best handled by
having a CA issue cross-certificates that contain those name
constraints and then making that CA be the trust anchor. The
former solution avoids the need to establish another CA. The
latter solution allows the constraints to be changed (or additional
trust links established) without requiring every application
to update its trust anchors. This issue was resolved by having
RFC 3280 describe a Basic Path Validation algorithm that is
mandatory to implement and optional extensions to it, such as
name constraints on trust anchors.

-Steve

Date: Fri, 09 Aug 2002 15:00:03 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Sunil Agrawal <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate Path Validation
Sender: [email-masked]

Sunil,

> Dear PKIX WG:
> 
> I need some help on Certificate Path Validation.
> 
> If my trust anchor is a non self signed certificate, what should be the
> contents of the initial permitted_subtrees.

Any name restriction, if any, you want to apply for that trust anchor.

> permitted_subtrees is defined as "a set of root names for each name type
> (e.g., X.500 distinguished names, email addresses, or ip addresses) 
> defining a set of subtrees within which all subject names in subsequent 
> certificates in the certification path MUST fall".
> 
> The RFC 3280, section 6.1.2, subsection b, says
> 
> "the initial value for the set for Distinguished Names is the set of all
> Distinguished names;"
 
> So is the RFC recommending ignoring the Name constraints extension (if
> present) in the CA certificates that are higher in the hierarchy that 
> the trust anchor ?

There exist no "CA certificates that are higher in the hierarchy that the
trust anchor". So the sentence is not correct.

If the trust anchor contains name restrictions, then they MUST be used as
part of the initial permitted_subtrees. In addition, you can apply
additional name restrictions. This means that the initial permitted_subtrees
conditions may come both from name restritions contained in the self-signed
certificate (if any) and from name restrictions external to the trust anchor
(which may or may not be specified in the form of a self-signed
certificate). 
 
> Is the recommendation same for excluded_subtrees and other policies?

The same phylosohy applies.

Regards,

Denis

> TIA,
> Sunil

Date: Thu, 08 Aug 2002 13:40:02 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: "Jeffrey I. Schiller" <[email-masked]>
CC: IETF PKIX WG List <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Subject: Re: Objections Raised by the IESG on the Roadmap document
Sender: [email-masked]

Jeff,

Just to make sure - it's just the "STATUS: *" lines in section 4?

spt

"Jeffrey I. Schiller" wrote:

> This is my fault, as I should have caught this before it got to the
> IESG.
>
> The document contains a lot of status information on the various
> Internet Drafts and RFCs that make up the PKIX Document set.
>
> Well, it is considered inappropriate for information that is as
> dynamic as document status to be enshrined in an RFC.
>
> I suggest that we remove the status text from the document and
> resubmit. The IESG recommends that the status information be placed on
> a webpage, which can be linked from the IESG Charter Page. Of course
> we would need someone to volunteer to keep that information up to
> date.
>
>                         -Jeff

From: "Rob Stradling" <[email-masked]>
To: <[email-masked]>
Subject: RFC3161 Timestamping AlgorithmIdentifiers
Date: Thu, 8 Aug 2002 18:30:45 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

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

We are currently implementing an RFC3161-compliant timestamping server.  =
Various timestamping clients that we have downloaded always encode the =
MessageImprint->hashAlgorithm AlgorithmIdentifier with the "parameters" =
field missing.

Whilst I accept that X.509 and RFC3280 define the AlgorithmIdentifier =
"parameters" field as OPTIONAL, surely this definition is "overridden" =
by PKCS#1 and RFC3279.  RFC3279 (section 2.2.1) states, for =
MD2/MD5/SHA-1 with RSA, that "the parameters component of that type =
SHALL be the ASN.1 type NULL".  RFC2119, of course, defines "SHALL" as =
"an absolute requirement of the specification".

If we follow PKCS#1 and RFC3279, we appear to be incompatible with other =
timestamping clients/servers.

1). Who is technically correct?
2). Regardless of who is technically correct, should our timestamping =
server allow "parameters" to be OPTIONAL or not (for MD2/MD5/SHA-1 with =
RSA) in
    a). the requests it receives?
    b). the responses it generates?

Thanks in advance.

Rob Stradling
Comodo Research Lab

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>We are currently implementing an =
RFC3161-compliant=20
timestamping server.&nbsp; Various timestamping clients that we have =
downloaded=20
always encode the MessageImprint-&gt;hashAlgorithm =
AlgorithmIdentifier&nbsp;with=20
the "parameters" field missing.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Whilst I accept that X.509 and RFC3280 =
define the=20
AlgorithmIdentifier "parameters" field as OPTIONAL, surely this =
definition is=20
"overridden" by PKCS#1 and RFC3279.&nbsp; RFC3279&nbsp;(section 2.2.1) =
states,=20
for MD2/MD5/SHA-1 with RSA, that "the parameters&nbsp;component of that =
type=20
SHALL be the ASN.1 type NULL".&nbsp; RFC2119, =
of&nbsp;course,&nbsp;defines=20
"SHALL" as "an absolute requirement of the specification".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>If we follow PKCS#1 and RFC3279, we =
appear to be=20
incompatible with other timestamping clients/servers.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1). Who is technically =
correct?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2). Regardless of who is technically =
correct,=20
should our timestamping server allow "parameters" to be OPTIONAL or not =
(for=20
MD2/MD5/SHA-1 with RSA) in</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; a). the requests it=20
receives?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; b). the responses it =

generates?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks in advance.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Rob Stradling</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Comodo Research Lab</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0139_01C23F09.B5CC0EE0--

Date: Thu, 08 Aug 2002 13:27:57 -0400
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
To: IETF PKIX WG List <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Subject: Objections Raised by the IESG on the Roadmap document
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

This is my fault, as I should have caught this before it got to the
IESG.

The document contains a lot of status information on the various
Internet Drafts and RFCs that make up the PKIX Document set.

Well, it is considered inappropriate for information that is as
dynamic as document status to be enshrined in an RFC.

I suggest that we remove the status text from the document and
resubmit. The IESG recommends that the status information be placed on
a webpage, which can be linked from the IESG Charter Page. Of course
we would need someone to volunteer to keep that information up to
date.

			-Jeff

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

--------------ms060707090209080902070402--

Date: Thu, 8 Aug 2002 10:24:44 -0400
To: Jean-Marc Desperrier <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: final version of PKIX minutes
Cc: [email-masked]
Sender: [email-masked]

At 4:10 PM +0200 8/8/02, Jean-Marc Desperrier wrote:
>Stephen Kent a dit :
>
>>"Specification Problem around Multi PKI domain Experience in 
>>Challenge PKI 2001"
>>  - Ryu Inada (Japan Network Security Association)
>>When a page in English will be available, it will be advertised on 
>>the PKIX mailing list, probably in the September 2002 time frame. 
>>[see slides]
>
>I don't see much slides available, even from the report page  ( 
>http://www.ietf.org/ietf/02jul/pkix.txt ).
>
>The doc in the .pdf from
>http://www.ipa.go.jp/security/fy13/report/pki_interop/pki_interop.html
>seems a bit too large to hope it will be translated.

I transferred the slide yesterday, so I am not sure when they will be 
posted. Also, Tim has a fair number of the slides and will have to 
send them directly, as they were not relayed to me. I expect all of 
them will be there sometime next week.

Steve

Date: Thu, 08 Aug 2002 16:10:43 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: final version of PKIX minutes
Sender: [email-masked]

Stephen Kent a dit :

> "Specification Problem around Multi PKI domain Experience in Challenge 
> PKI 2001"
>  - Ryu Inada (Japan Network Security Association)
> When a page in English will be available, it will be advertised on the 
> PKIX mailing list, probably in the September 2002 time frame. [see slides]

I don't see much slides available, even from the report page  
( http://www.ietf.org/ietf/02jul/pkix.txt ).

The doc in the .pdf from
http://www.ipa.go.jp/security/fy13/report/pki_interop/pki_interop.html
seems a bit too large to hope it will be translated.

Date: Thu, 08 Aug 2002 11:01:50 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: Gene Hilborn <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: OCSP concept question
Sender: [email-masked]

Gene Hilborn a dit :

>While both CRLs and OCSP have a defined syntax for conveying the
>information of WHEN a certificate was revoked, neither is required to
>indefinitely maintain this information as an historical record.
>
>RFC 2459 does not require or recommend archiving revocation after expiry:
>"An entry may be removed from the CRL after appearing on one regularly
>scheduled CRL issued beyond the revoked certificate's validity period."
>
>RFC 2560 makes such archival information optional for OCSP:  'An OCSP
>responder MAY choose to retain revocation information beyond a
>certificate's expiration. The date obtained by subtracting this retention
>interval value from the producedAt time in a response is defined as the
>certificate's "archive cutoff" date.'
>
>Thus, since CRLs and OCSP responders are not normally set up as historical
>archives, they do not facilitate determining if and when a certificate was
>revoked when they are consulted long after the expiry date on the
>certificate.
>
Which is why in my first answer, I said that the responder should better 
check the information as soon as it receives the signature and save the 
response it received.

But still taking care of how he handles the case where the certificate 
was just on hold.

Date: Wed, 7 Aug 2002 17:22:29 -0400
To: [email-masked], [email-masked]
From: Stephen Kent <[email-masked]>
Subject: final version of PKIX minutes
Sender: [email-masked]

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

Edited by Steve Kent

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

The PKIX WG met once during the 53rd IETF. A total of approximately 185
individuals participated in the meeting.

Tim Polk began with a review of the agenda and document status.
	NIST will develop an interoperability test plan for RFC 3279 
& 3280, and submit to WG for review. Note 3 documents have now 
achieved RFC status. DPV/DPD requirements document in IESG last call. 
Roadmap, OCSP(v1)bis and PI documents in IESG queue. 2527bis ready 
now. CMP and CRMF have been awaiting documentation of test results 
for progression to Draft, but we will publish and cycle at Proposed. 
We still have 19 active IDs, which is a lot, but an improvement! [see 
slides]

Certificate Validation Protocol - Denis Pinkas (Bull)
	A candidate for meeting the DPV (but not DPD) requirements. 
User specifies validation policy to control path validation by a 
serverf if no policy specified, server employs local default, and 
notifies user of the policy (by OID). Allows user control over type 
of revocation checking to be done, time stamping of returned data, 
etc. Option for user to provide additional certificates and 
revocation status data. Optional requestor ID. Extensions permitted, 
e.g., to support inter-server use as well as client/server support. 
=46acilities are included to support NR use, but do not burden non-NR 
use. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-00.txt

SCVP Protocol - Ambarish Malpani (ValiCert)
Update on SCVP, changes to meet newly adopted requirements document. 
Uses CMS as basis. SCVP supports both DPD and DPV. Changes include 
references to policy by OID, references to certificates as 
alternative to sending certificates, client identifier added, query 
for client to discover policies supported by server, etc. [see 
slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-08.txt

Tim urges WG to begin examining protocols in detail. In order to be 
considered for DPV and DPD, any other candidate protocols, (e.g., 
OCSPv2) will have to be republished with any changes needed to meet 
requirements we have adopted. Hope is to make a decision before 
Atlanta IETF meeting, this fall.

Wireless LAN Certificate Extensions - Russ Housley (RSA Security)
IEEE 802.1X is looking at use of EAP-TLS for authentication in 
wireless LANs. Need extensions to support this application, when a 
user accesses different WLANs, e.g., home vs. work vs. airport, =8A. 
Proposal defines EKU values for EAP/PPP and EAP/WLAN applications. 
Want to automate selection of the right certificate for different 
access points. Each WLAN has one or more service set identifiers 
(SSIDs). Put a list of SSIDs into a certificate as an extension, to 
identify the WLAN. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt

Certificate Warranty Extension - Russ Housley (RSA Security) for Spyrus
	(The ID author, Alice Sturgeon could not attend, so the 
presentation was made by Russ.) This extension provides explicit data 
about warranties provided by the CA, including an explicit 
declaration of no warranty. It's a non-critical extension; NULL used 
to express no warranty, and there are provisions for extended 
warranty data too. Option to point to warranty data via URL. All of 
this can be gleaned from CP or CPS, but goal here is to make it easy 
for a machine to process. Subtle issues need to be discussed about 
why it is appropriate to use this extension, vs. using a policy 
extension with a specific policy and policy qualifiers to express 
monetary values. We have to be careful to not start a trend in 
creating a separate extension for each type of data that might appear 
in a CP/CPS and which might benefit from automated processing. [see 
slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt

Attribute Certificate Policies Extension - Denis Pinkas (Bull)
Two extensions, one provides policy info re an attribute certificate 
and one for locating the AA certificate. The first extension mimics 
the policy extension from PK certificates (but gets new OID because 
of wording issues), uses optional policy qualifiers to express 
freshness of the attribute certificate. Second extension is a URL, 
and is marked to indicate whether the location of a repository is 
public or private. Discussion about need for freshness info, possible 
separation of second extension as it is more general than this AC 
context, and the need to include policy info explicitly in the AC. 
[see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-00.txt

RFC 3161bis - Denis Pinkas (Bull)
  	Want to move to Draft, but need real interoperability tests 
to move forward. Will publish a matrix of tests to guide testers. 
Various minor changes to the document reviewed. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161bis-00.txt

Policy requirements for TSAs - Denis Pinkas (Bull)
	This document is derived from work in ETSI. Changes to 
terminology to align with 3161bis. This is targeted as an 
Informational RFC, with ETSI maintaining change control. Question is 
raised about whether we need a more generic policy requirements 
document for a wide range of PKI servers, e.g., CAs, AAs, TSAs, OCSP 
servers, DPD/DPV servers, etc. Although some core material is the 
same, major differences exist between PKI servers. Some text portions 
would certainly be re-usable in future policy documents. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-01.txt

PKIX Permanent Identifiers - Denis Pinkas (Bull)
	Document is with the IESG. Discussion of matching rule 
features. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-05.txt

Logotypes in X.509 Certificates - Stefan Santesson (AddTrust)
	Document now in third draft, and a fourth draft will be 
issued soon. Now can display logos at different resolutions, B+W vs. 
color, audio for vision impaired, language-specific logo selection, 
direct inclusion and indirect reference, etc. Three basic types of 
logos (community, issuer, client), plus loyalty, =8A. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-03.txt

LDAPv3 Issues Relevant to PKIX - David Chadwick (Univ. of Salford)
	There was a change from LDAPv2 to LDAPv3 which affects how 
certificates and related PKI data structures are stored. LDAPv3 added 
";binary" as a means of specifying transfer syntax for these objects, 
which should be transferred in BER form. Now, however, the LDAPv3 WG 
has decided to remove support for ;binary (which was optional), from 
the draft standard (due to ambiguities in its specification, and no 
consensus on how to resolve them) in an effort to progress to Draft, 
avoiding other problems associated with generic use of this feature. 
Plan is to reintroduce ;binary as an extension in the future, once 
the problems that caused it to be removed is resolved. PKIX WG 
members are requested to respond on the list, noting whether clients 
and servers make use of LDAPv2 or LDAPv3, and if the latter whether 
they use ;binary when interacting with LDAPv3 directories. For the 
first time a native transfer syntax for data items relevant to PKIX 
has been defined in the PKIX LDAP schema for PKIs and PMIs, and these 
produce the same bits on the wire as the ;binary transfer syntax. 
Therefore in the longer term the use of ;binary wont be needed. But 
there clearly is an immediate problem with the use of ;binary, which 
is why it is important for people on the list to respond to the 
imminent questionnaire. OpenLDAP now supports equality matching for 
certificates, as specified in the latest version of the LDAP schema 
IDs.

"Specification Problem around Multi PKI domain Experience in 
Challenge PKI 2001"
  - Ryu Inada (Japan Network Security Association)
	This is a report on the interoperability testing activities 
in Japan, not a PKIX activity. Test environment involved root CAs and 
9 subordinate CAs, a cross-certification model, and a bridge CA model 
representative of the Japanese government PKI. Applications included 
SSL, TLS, and S/MIME. Testing uncovered several areas that required 
clarification, in path validation and policy mapping. Also uncovered 
a number of CA non-compliance problems, e.g., mis-encoding of key 
usage, basic constraints in EE certificates, bad combinations of 
flags in key usage, etc. They hope to feedback results of tests in 
multi-domain PKIs to clarify the RFC 3280 issues. When a page in 
English will be available, it will be advertised on the PKIX mailing 
list, probably in the September 2002 time frame. [see slides]
--============_-1183367059==_ma============
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D"text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>final version of PKIX minutes</title></head><body>
<div><font face=3D"Courier" size=3D"+2" color=3D"#000000">Edited by Steve
Kent<br>
<br>
Chairs: Stephen Kent &lt;[email-masked]&gt;, Tim Polk
&lt;[email-masked]&gt;<br>
<br>
The PKIX WG met once during the 53rd IETF. A total of approximately
185<br>
individuals participated in the meeting.<br>
<br>
<br>
Tim Polk began with a review of the agenda and document status.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>NIST will develop an
interoperability test plan for RFC 3279 &amp; 3280, and submit to WG
for review. Note 3 documents have now achieved RFC status. DPV/DPD
requirements document in IESG last call. Roadmap, OCSP(v1)bis and PI
documents in IESG queue. 2527bis ready now. CMP and CRMF have been
awaiting documentation of test results for progression to Draft, but
we will publish and cycle at Proposed. We still have 19 active IDs,
which is a lot, but an improvement! [see slides]<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab><br>
Certificate Validation Protocol - Denis Pinkas (Bull)<br>
<x-tab>&nbsp;&nbsp; </x-tab>A candidate for meeting the DPV (but not
DPD) requirements. User specifies validation policy to control path
validation by a serverf if no policy specified, server employs local
default, and notifies user of the policy (by OID). Allows user control
over type of revocation checking to be done, time stamping of returned
data, etc. Option for user to provide additional certificates and
revocation status data. Optional requestor ID. Extensions permitted,
e.g., to support inter-server use as well as client/server support.
=46acilities are included to support NR use, but do not burden non-NR
use. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-00.txt<br>
<br>
SCVP Protocol - Ambarish Malpani (ValiCert)<br>
Update on SCVP, changes to meet newly adopted requirements document.
Uses CMS as basis. SCVP supports both DPD and DPV. Changes include
references to policy by OID, references to certificates as alternative
to sending certificates, client identifier added, query for client to
discover policies supported by server, etc. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-08.txt<br>
<br>
Tim urges WG to begin examining protocols in detail. In order to be
considered for DPV and DPD, any other candidate protocols, (e.g.,
OCSPv2) will have to be republished with any changes needed to meet
requirements we have adopted. Hope is to make a decision before
Atlanta IETF meeting, this fall.<br>
<br>
Wireless LAN Certificate Extensions - Russ Housley (RSA Security)<br>
IEEE 802.1X is looking at use of EAP-TLS for authentication in
wireless LANs. Need extensions to support this application, when a
user accesses different WLANs, e.g., home vs. work vs. airport, =8A.
Proposal defines EKU values for EAP/PPP and EAP/WLAN applications.
Want to automate selection of the right certificate for different
access points. Each WLAN has one or more service set identifiers
(SSIDs). Put a list of SSIDs into a certificate as an extension, to
identify the WLAN. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt<br
<br>
Certificate Warranty Extension - Russ Housley (RSA Security) for
Spyrus<br>
<x-tab>&nbsp;&nbsp; </x-tab>(The ID author, Alice Sturgeon could not
attend, so the presentation was made by Russ.) This extension provides
explicit data about warranties provided by the CA, including an
explicit declaration of no warranty. It's a non-critical extension;
NULL used to express no warranty, and there are provisions for
extended warranty data too. Option to point to warranty data via URL.
All of this can be gleaned from CP or CPS, but goal here is to make it
easy for a machine to process. Subtle issues need to be discussed
about why it is appropriate to use this extension, vs. using a policy
extension with a specific policy and policy qualifiers to express
monetary values. We have to be careful to not start a trend in
creating a separate extension for each type of data that might appear
in a CP/CPS and which might benefit from automated processing. [see
slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt<br
<br>
Attribute Certificate Policies Extension - Denis Pinkas (Bull)<br>
Two extensions, one provides policy info re an attribute certificate
and one for locating the AA certificate. The first extension mimics
the policy extension from PK certificates (but gets new OID because of
wording issues), uses optional policy qualifiers to express freshness
of the attribute certificate. Second extension is a URL, and is marked
to indicate whether the location of a repository is public or private.
Discussion about need for freshness info, possible separation of
second extension as it is more general than this AC context, and the
need to include policy info explicitly in the AC. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-0<span
></span>0.txt</font></div>
<div><font face=3D"Courier" size=3D"+2" color=3D"#000000"><br>
RFC 3161bis - Denis Pinkas (Bull)<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Want to move to
Draft, but need real interoperability tests to move forward. Will
publish a matrix of tests to guide testers. Various minor changes to
the document reviewed. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161bis-00.txt<br
<br>
Policy requirements for TSAs - Denis Pinkas (Bull)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>This document is derived
from work in ETSI. Changes to terminology to align with 3161bis. This
is targeted as an Informational RFC, with ETSI maintaining change
control. Question is raised about whether we need a more generic
policy requirements document for a wide range of PKI servers, e.g.,
CAs, AAs, TSAs, OCSP servers, DPD/DPV servers, etc. Although some core
material is the same, major differences exist between PKI servers.
Some text portions would certainly be re-usable in future policy
documents. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-01.txt<br>
<br>
PKIX Permanent Identifiers - Denis Pinkas (Bull)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Document is with the
IESG. Discussion of matching rule features. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-05.txt<x-tab
>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab><br>
<br>
Logotypes in X.509 Certificates - Stefan Santesson (AddTrust)<br>
<x-tab>&nbsp;&nbsp; </x-tab>Document now in third draft, and a fourth
draft will be issued soon. Now can display logos at different
resolutions, B+W vs. color, audio for vision impaired,
language-specific logo selection, direct inclusion and indirect
reference, etc. Three basic types of logos (community, issuer,
client), plus loyalty, =8A. [see slides]<u>
http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-03.txt<br
<br>
</u>LDAPv3 Issues Relevant to PKIX - David Chadwick (Univ. of
Salford)</font></div>
<div><font face=3D"Courier" size=3D"+2"
color=3D"#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>There was a change from LDAPv2 to LDAPv3 which affects how
certificates and related PKI data structures are stored. LDAPv3 added
";binary" as a means of specifying transfer syntax for these
objects, which should be transferred in BER form. Now, however, the
LDAPv3 WG has decided to remove support for ;binary (which was
optional), from the draft standard (due to ambiguities in its
specification, and no consensus on how to resolve them) in an effort
to progress to Draft, avoiding other problems associated with generic
use of this feature. Plan is to reintroduce ;binary as an extension in
the future, once the problems that caused it to be removed is
resolved. PKIX WG members are requested to respond on the list, noting
whether clients and servers make use of LDAPv2 or LDAPv3, and if the
latter whether they use ;binary when interacting with LDAPv3
directories. For the first time a native transfer syntax for data
items relevant to PKIX has been defined in the PKIX LDAP schema for
PKIs and PMIs, and these produce the same bits on the wire as the
;binary transfer syntax. Therefore in the longer term the use of
;binary wont be needed. But there clearly is an immediate problem with
the use of ;binary, which is why it is important for people on the
list to respond to the imminent questionnaire. OpenLDAP now supports
equality matching for certificates, as specified in the latest version
of the LDAP schema IDs.</font></div>
<div><font face=3D"Courier" size=3D"+2" color=3D"#000000"><br>
&quot;Specification Problem around Multi PKI domain Experience in
Challenge PKI 2001&quot;<br>
&nbsp;- Ryu Inada (Japan Network Security Association)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>This is a report
on the interoperability testing activities in Japan, not a PKIX
activity. Test environment involved root CAs and 9 subordinate CAs, a
cross-certification model, and a bridge CA model representative of the
Japanese government PKI. Applications included SSL, TLS, and S/MIME.
Testing uncovered several areas that required clarification, in path
validation and policy mapping. Also uncovered a number of CA
non-compliance problems, e.g., mis-encoding of key usage, basic
constraints in EE certificates, bad combinations of flags in key
usage, etc. They hope to feedback results of tests in multi-domain
PKIs to clarify the RFC 3280 issues. When a page in English will be
available, it will be advertised on the PKIX mailing list, probably in
the September 2002 time frame. [see slides]</font></div>
</body>
</html>
--============_-1183367059==_ma============--

Date: Wed, 07 Aug 2002 16:17:17 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: OCSP concept question
Sender: [email-masked]

On 4 Aug 2002 at 15:48, Haaino Beljaars wrote:

> If person A check the message against a CRL it would indicate at time T+2
> that the certificate was good at the moment of signing, this is because a
> CRL contains time and date when a certificate was revoked, but an OCSP
> response does not contian that information.

The OCSP response does contain that information, and A can know the 
certificate was revoked after the signature date.

But it can be only the case if A can really trust the time at which the 
data has been signed, ie if the signature has been timestamped or if A 
has a private trusted record of the time it received the data.
In the general case, A would better check the signature as soon as it 
receives the data, and save the answer if it says the certificat is 
valid for later use/proof.

Thomas Beckmann wrote ;

>Having in mind, that an OCSP responder does in general nothing else but
>checking a CRL and forwarding the requested information I cannot see a
>difference between the usage of CRLs and OCSP but the neccessity of retrieve
>actual CRLs.
>  
>
There's two different way of using OCSP.

Either the OCSP responder only has access to a CRL, and in that case the 
OCSP responder is only a proxy to avoid downloading the whole CRL before 
checking.
Or the OCSP responder has direct access to the database of the CA and 
can get information that is fresher that any CRL.

In the second cas, the difference is clear.
But even in the first case, the fact that client don't have to download 
the whole CRL means that in the case of large size CA with very large 
CRL, you can afford generating them much more often, and have fresher 
data that if the client must use directly the CRL to access the information.

Olle Mulmo a dit :

>Consider a scenario where a certificate is revoked with reason "onHold" for
>a period of time, and later it gets reinstated. If both these operations
>happen within a single CRL interval, you will never find out that this event
>occured if you rely on CRLs. OTOH, using OCSP you would find out about it.
>How should a verifier act in this case? Refuse or accept the signature? Put
>the verification step on hold until the cert is either cleared from
>suspicion or revoked "for real"?
>
A verifier should know it's the policy of this CA that it can put 
certificate on hold and decide what course of action that is adequate 
for him.

The motivation for revocation should indicate that the certificate is 
only "on hold" and can be used by the verifier to decide it's action.

Outside of a use where the way the verifier checks the signature is 
perfectly controled, ie certificate used only to sign transactions where 
there's a clear  agreement on that between the parties, or "intranet" 
use, it's therefore not a good idea for a CA to put certificates on hold.

> From: [email-masked]
>
> As for conclusions, IMO, the OCSP client should 'save' each ocsp response
> it receives, as this is the 'proof' that the cert was valid when it 
> was used.

It really needs to save the response to proove on what data it took it's 
decision.

It should beware of putting in a cache the revoked status of a 
certificate if it's not able to tell if it was just "on hold".

From: "Olle Mulmo" <[email-masked]>
To: <[email-masked]>, "Haaino Beljaars" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP concept question
Date: Wed, 7 Aug 2002 11:26:53 +0200
Importance: Normal
Sender: [email-masked]

There are weird cases as well...

Consider a scenario where a certificate is revoked with reason "onHold" for
a period of time, and later it gets reinstated. If both these operations
happen within a single CRL interval, you will never find out that this event
occured if you rely on CRLs. OTOH, using OCSP you would find out about it.

How should a verifier act in this case? Refuse or accept the signature? Put
the verification step on hold until the cert is either cleared from
suspicion or revoked "for real"?

This is, as Rob points out, a topic that can be discussed for hours. And I
don't think this list can provide a "correct" answer.

/Olle

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
Sent: den 6 augusti 2002 17:50
To: Haaino Beljaars
Cc: [email-masked]
Subject: Re: OCSP concept question

Howdy,

I'm definitely not an expert, however, I've had thoughts about this in the
past. Disregarding
internet-drafts  here is what I think.

As far as I realize, OCSP is a mechanism to check validity for a set of
certificates in real time,
i.e.  to answer the question(s), "Is this set of certificates valid NOW, HOW
long, and if not
since WHEN, and possibly WHY?"  CRLs are used to determine whether a
certificate was
valid at a particular time in the past, and when can we expect an update on
its validity?

(insert ideal certificate usage here)

The previous paragraph says little, but means a lot when we have to
interprete what it says.
Endless hours of discussion could arise from the paragraph, yet no
conclusions will be
reached, since the RFCs (2459 and 2560) do not dictate.

As for conclusions,  IMO, the OCSP client should 'save' each ocsp response
it receives, as
this is the 'proof' that the cert was valid when it was used.  By save I
mean the ocsp response
should be persistent.  Naturally, who knows what a lawyer would make of such
a packet, still,
it is the best we can do.

Please correct me!

-rob
[email-masked]

On 4 Aug 2002 at 15:48, Haaino Beljaars wrote:

>
> Hi,
>
> Hopefully somebody can help me with the follwoing questions and remarks:
>
> I send a signed message to person A, person A checks the status of my
certificate on time T by an OCSP request, and the status of my certificate
is 'good' according to the OCSP response. At time T+1 my certificate is
revoked. Person A checks my message again at time T+2.
>
> Question: what does the OCSP responder give back as status at T+2 ?
>
> * If the OCSP responder gives back 'revoked' at time T+2, then that is
correct at that moment in time, but it is wrong when you look at the time(T)
when the message was signed, because the message was signed when the
certificate status was still good.
>
> * If the OCSP responder gives back 'good': this indicates that an OCSP has
as a 'history' function. As far as I can read this is not the case in the
OCSP RFC.
>
> If person A check the message against a CRL it would indicate at time T+2
that the certificate was good at the moment of signing, this is because a
CRL contains time and date when a certificate was revoked, but an OCSP
response does not contian that information.
>
> According to this 'analysis' I get different answers concerning the status
of a certificate when I concult a CRL or OCSP?
>
> Why doesn't an OCSP response contain date and time when a certificate was
revoked?
>
> And why doesn't an OCSP response contain a signed time? How can I check
that the time the OCSP responder gives back is correct?
> Best regards,
> Haaino

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: AW: OCSP concept question
Date: Wed, 7 Aug 2002 11:03:06 +0200 
Sender: [email-masked]

I am not an OCSP expert as well but fortunately yesterday I read something
about the structure of OCSP responses.
I cross checked it with RFC 2560.
There a sequence containing the revocationTime is defined.
Having in mind, that an OCSP responder does in general nothing else but
checking a CRL and forwarding the requested information I cannot see a
difference between the usage of CRLs and OCSP but the neccessity of retrieve
actual CRLs.

Regards

Thomas Beckmann
 -------------------------------------
 Thomas Beckmann
 Fachgruppenleiter PKI und Trustcenter
 SchlumbergerSema -
 Competence Center Informatik GmbH 
 Lohberg 10 - 49716 Meppen - Germany
 tel: +49 5931-805-242
 mobil: +49 170 2802 343  
 fax: +49 5931-842-242
 mail: [email-masked]

> -----Ursprüngliche Nachricht-----
> Von: Haaino Beljaars [mailto:[email-masked]]
> Gesendet: Sonntag, 4. August 2002 15:48
> An: [email-masked]
> Betreff: OCSP concept question
> 
> 
> 
> Hi,
> 
> Hopefully somebody can help me with the follwoing questions 
> and remarks:
> 
> I send a signed message to person A, person A checks the 
> status of my certificate on time T by an OCSP request, and 
> the status of my certificate is 'good' according to the OCSP 
> response. At time T+1 my certificate is revoked. Person A 
> checks my message again at time T+2.
> 
> Question: what does the OCSP responder give back as status at T+2 ?
> 
> * If the OCSP responder gives back 'revoked' at time T+2, 
> then that is correct at that moment in time, but it is wrong 
> when you look at the time(T) when the message was signed, 
> because the message was signed when the certificate status 
> was still good.
> 
> * If the OCSP responder gives back 'good': this indicates 
> that an OCSP has as a 'history' function. As far as I can 
> read this is not the case in the OCSP RFC.
> 
> If person A check the message against a CRL it would indicate 
> at time T+2 that the certificate was good at the moment of 
> signing, this is because a CRL contains time and date when a 
> certificate was revoked, but an OCSP response does not 
> contian that information.
> 
> According to this 'analysis' I get different answers 
> concerning the status of a certificate when I concult a CRL or OCSP?
> 
> Why doesn't an OCSP response contain date and time when a 
> certificate was revoked? 
> 
> And why doesn't an OCSP response contain a signed time? How 
> can I check that the time the OCSP responder gives back is correct?
> 
> Best regards,
> Haaino
> 

From: [email-masked]
To: "Haaino Beljaars" <[email-masked]>
Date: Tue, 6 Aug 2002 17:49:58 +0200
Subject: Re: OCSP concept question
CC: [email-masked]
Content-description: Mail message body
Sender: [email-masked]

Howdy,

I'm definitely not an expert, however, I've had thoughts about this in the past. Disregarding 
internet-drafts  here is what I think.

As far as I realize, OCSP is a mechanism to check validity for a set of certificates in real time, 
i.e.  to answer the question(s), "Is this set of certificates valid NOW, HOW long, and if not 
since WHEN, and possibly WHY?"  CRLs are used to determine whether a certificate was 
valid at a particular time in the past, and when can we expect an update on its validity?

(insert ideal certificate usage here)

The previous paragraph says little, but means a lot when we have to interprete what it says.  
Endless hours of discussion could arise from the paragraph, yet no conclusions will be 
reached, since the RFCs (2459 and 2560) do not dictate.

As for conclusions,  IMO, the OCSP client should 'save' each ocsp response it receives, as 
this is the 'proof' that the cert was valid when it was used.  By save I mean the ocsp response 
should be persistent.  Naturally, who knows what a lawyer would make of such a packet, still, 
it is the best we can do.

Please correct me!

-rob
[email-masked]

On 4 Aug 2002 at 15:48, Haaino Beljaars wrote:

> 
> Hi,
> 
> Hopefully somebody can help me with the follwoing questions and remarks:
> 
> I send a signed message to person A, person A checks the status of my certificate on time T by an OCSP request, and the status of my certificate is 'good' according to the OCSP response. At time T+1 my certificate is revoked. Person A checks my message again at time T+2.
> 
> Question: what does the OCSP responder give back as status at T+2 ?
> 
> * If the OCSP responder gives back 'revoked' at time T+2, then that is correct at that moment in time, but it is wrong when you look at the time(T) when the message was signed, because the message was signed when the certificate status was still good.
> 
> * If the OCSP responder gives back 'good': this indicates that an OCSP has as a 'history' function. As far as I can read this is not the case in the OCSP RFC.
> 
> If person A check the message against a CRL it would indicate at time T+2 that the certificate was good at the moment of signing, this is because a CRL contains time and date when a certificate was revoked, but an OCSP response does not contian that information.
> 
> According to this 'analysis' I get different answers concerning the status of a certificate when I concult a CRL or OCSP?
> 
> Why doesn't an OCSP response contain date and time when a certificate was revoked? 
> 
> And why doesn't an OCSP response contain a signed time? How can I check that the time the OCSP responder gives back is correct?
> 
> Best regards,
> Haaino
> 

From: "Olle Mulmo" <[email-masked]>
To: "David Maurus" <[email-masked]>, "Haaino Beljaars" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP follow up
Date: Tue, 6 Aug 2002 15:50:48 +0200
Importance: Normal
Sender: [email-masked]

Haaino, David,

Revocation time *is* provided in an OCSP response, so you do have some
probability of answering historical questions. (Given of course that
you know when the signature was actually performed, but that opens up
for the whole nonrep/TSA discussion so I won't go there.)

   CertStatus ::= CHOICE {
       good        [0]     IMPLICIT NULL,
       revoked     [1]     IMPLICIT RevokedInfo,
       unknown     [2]     IMPLICIT UnknownInfo }

   RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

/Olle

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David Maurus
Sent: den 4 augusti 2002 17:28
To: Haaino Beljaars
Cc: [email-masked]
Subject: Re: OCSP follow up

Hello Haaino,

Haaino Beljaars wrote:

>Question: what is the response of the OCSP responder at time III ? 
>
The OCSP responder will only tell you the current state of the 
certificate. It does not know about the time of the signature. If you 
want to prove that the signature was valid at that time, you need to 
archive the OCSP answer, and you need a timestamp, since there is an 
attack scenario where OCSP is not sufficient:

Attacker A requests the status of banker B's certificate when it is 
still valid, then steals the private key of B. Now he can generate a 
signature with any signing time before he has stolen B's private key, 
and can show the valid OCSP response that prooves that the certificate 
was valid at that time.

Because of this, if you want to show that a signature you've received 
was valid at the point in time when you accepted it, you need to also 
request a timestamp from a trusted third party.

IMHO, it would have been very practical if timestamping had been made 
part of OCSP. If there are good reasons against that, I'd be happy to be 
enlighted...

Best Regards,
David

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-pr-tsa-02.txt
Date: Mon, 05 Aug 2002 07:44:19 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Policy Requirements for Time-Stamping Authorities
	Author(s)	: D. Pinkas, N. Pope, J. Ross
	Filename	: draft-ietf-pkix-pr-tsa-02.txt
	Pages		: 39
	Date		: 02-Aug-02
	
This document defines requirements for a baseline time-stamp policy 
for TSAs issuing time-stamp tokens, supported by public key 
certificates, with an accuracy of one second or better. A TSA may 
define its own policy which enhances the policy defined in the 
current document. Such a policy shall incorporate or further 
constrain the requirements identified in the current document. 
The contents of this Informational RFC is technically equivalent to
ETSI TS 102 023 [TS 102023]. The ETSI TS is under the
ETSI Copyright (C). Individual copies of this ETSI deliverable can 
be downloaded from http://www.etsi.org

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pr-tsa-02.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-pr-tsa-02.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-pr-tsa-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Sun, 04 Aug 2002 17:27:37 +0200
From: David Maurus <[email-masked]>
To: Haaino Beljaars <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP follow up
Sender: [email-masked]

Hello Haaino,

Haaino Beljaars wrote:

>Question: what is the response of the OCSP responder at time III ? 
>
The OCSP responder will only tell you the current state of the 
certificate. It does not know about the time of the signature. If you 
want to prove that the signature was valid at that time, you need to 
archive the OCSP answer, and you need a timestamp, since there is an 
attack scenario where OCSP is not sufficient:

Attacker A requests the status of banker B's certificate when it is 
still valid, then steals the private key of B. Now he can generate a 
signature with any signing time before he has stolen B's private key, 
and can show the valid OCSP response that prooves that the certificate 
was valid at that time.

Because of this, if you want to show that a signature you've received 
was valid at the point in time when you accepted it, you need to also 
request a timestamp from a trusted third party.

IMHO, it would have been very practical if timestamping had been made 
part of OCSP. If there are good reasons against that, I'd be happy to be 
enlighted...

Best Regards,
David

content-class: urn:content-classes:message
Subject: OCSP concept question
Date: Sun, 4 Aug 2002 15:48:05 +0200
From: "Haaino Beljaars" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi,

Hopefully somebody can help me with the follwoing questions and remarks:

I send a signed message to person A, person A checks the status of my certificate on time T by an OCSP request, and the status of my certificate is 'good' according to the OCSP response. At time T+1 my certificate is revoked. Person A checks my message again at time T+2.

Question: what does the OCSP responder give back as status at T+2 ?

* If the OCSP responder gives back 'revoked' at time T+2, then that is correct at that moment in time, but it is wrong when you look at the time(T) when the message was signed, because the message was signed when the certificate status was still good.

* If the OCSP responder gives back 'good': this indicates that an OCSP has as a 'history' function. As far as I can read this is not the case in the OCSP RFC.

If person A check the message against a CRL it would indicate at time T+2 that the certificate was good at the moment of signing, this is because a CRL contains time and date when a certificate was revoked, but an OCSP response does not contian that information.

According to this 'analysis' I get different answers concerning the status of a certificate when I concult a CRL or OCSP?

Why doesn't an OCSP response contain date and time when a certificate was revoked? 

And why doesn't an OCSP response contain a signed time? How can I check that the time the OCSP responder gives back is correct?

Best regards,
Haaino

Date: Fri, 02 Aug 2002 12:17:19 -0700
To: [email-masked]
From: Sunil Agrawal <[email-masked]>
Subject: Certificate Path Validation
Sender: [email-masked]

Dear PKIX WG:

I need some help on Certificate Path Validation.

If my trust anchor is a non self signed certificate, what should be the 
contents
of the initial permitted_subtrees.

permitted_subtrees is defined as "a set of root names for each name type 
(e.g.,
X.500 distinguished names, email addresses, or ip addresses) defining a set of
subtrees within which all subject names in subsequent certificates in the 
certification
path MUST fall".

The RFC 3280, section 6.1.2, subsection b, says

"the initial value for the set for Distinguished Names is the set of all 
Distinguished
names;"

So is the RFC recommending ignoring the Name constraints extension (if 
present) in
the CA certificates that are higher in the hierarchy that the trust anchor ?

Is the recommendation same for excluded_subtrees and other policies?

TIA,
Sunil

Date: Thu, 1 Aug 2002 23:09:27 -0700
From: "Hoyt L. Kesterson II" <[email-masked]>
To: "X.509": ;, "IETF LDAP" <[email-masked]>
Subject: announcement of x500 meeting
Sender: [email-masked]

The directory group will be meeting 16-20 September 2002 at the 
facilities of the National Institute of Standards and Technology. The 
meeting announcement is at 
ftp://ftp.bull.com/pub/OSIdirectory/NIST2002/6N12267announcement.pdf.

We will resolve ballot comments on the Friend Attribute PDAM and the 
Distributed Paged Results PDAM. The ballot period closes 10 August 
2002. We will advance the Working Documents on enhancements to 
certificates, on LDAP alignment, and on Related Entries.

The PDAMs and the Working Documents can be found at

    ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output

We will also be resolving comments against Draft Technical Corrigenda 
that are correcting defects against X.509/9594-8. The ballot period 
on these DTCs ends 15 September 2002. They can be found at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/Closing15September2002

      hoyt

Subject: Re: draft-ietf-pkix-warranty-ext-01
To: Denis Pinkas <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
From: "Adrian McCullagh" <[email-masked]>
Date: Fri, 2 Aug 2002 13:04:33 +1000
Sender: [email-masked]

Hi Denis and others,

In your last email on this topic you wrote:

     "The Certificate Warranty qualifier contains a direct pointer to a
subpart
   of the Certification Practice Statement (CPS) published by the CA.  The
   pointer is in the form of a URI.  Processing requirements for this
   qualifier are a local matter."

I do not think this is a good idea from both a commercial perspective and a
legal perspective.

Firstly, I believe that it is doubtful that a relying party will read a
CPS.  Mainly because nearly all of the CPS's that I have encountered have
been very enstensive and frankly are a difficult to read.  Basically they
are not what I would call consumer friendly.

Secondly, notwithstanding the Uniform Commercial Code, the burying of
certificate warranty provisions in a CPS could result in a Court holding
that the warranty limit can not be relied upon.  It really defeats the
exercise of extending the financial trust factor.

I agree that a URL pointer to the warranty provisions would be advantageous
which could (note I said could not would, I am undecided on this point at
this time) force the relying party to the url and maybe an acceptance
button on the website.

This last point needs to be thought out as it is creating an extra layer of
complexity which is not what I am really advocating.  This is a clear
example of where the law and the technology needs to be better debated.

Adrian McCullagh
Solicitor
Freehills

Direct 61 7 3258 6603
Telephone 61 7 3258 6666
Facsimile 61 7 3258 6444
http://www.freehills.com.au

--------------------------------------------------------------------
FREEHILLS
This email is confidential.  If you are not the intended  recipient,
you must not disclose  or  use the  information  contained in it. If
you have received this email in error,  please notify us immediately
by return email and delete the document.
Freehills is not responsible for any changes made to a document other
than those made by Freehills or for the effect of the changes on the
document's meaning.

Liability is limited by the Solicitors' Limitation of Liability Scheme,
approved under the Professional Standards Act 1994 (NSW)
--------------------------------------------------------------------

content-class: urn:content-classes:message
Subject: v2.1 Certificate Management Library (CML) Now Available
Date: Thu, 1 Aug 2002 13:24:36 -0400
From: "Pawling, John" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

All,

Getronics Government Solutions has delivered the Version 2.1 
Certificate Management Library (CML) for Microsoft Windows, 
Sun Solaris and Linux.  The v2.1 CML and documentation is 
freely available at:
<http://www.getronicsgov.com/hot/cml_home.htm>.  

Applications requiring Public Key Infrastructure (PKI) security 
services can use the CML to meet their X.509 certificate and 
Certificate Revocation List (CRL) processing requirements.  
The v2.1 CML is described in the v2.1 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path verification processing rules and SDN.706 profile.
It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile
requirements.  There are some unsupported features such as 
Delta CRLs.  The v2.1 CML Abstract Syntax Notation One (ASN.1)
decodes X.509 Certificates and CRLs.  It requires the v1.4
Enhanced SNACC ASN.1 software that is freely available from:
<http://www.getronicsgov.com/hot/snacc_home.htm>.

The CML provides robust certificate path building capabilities such
as using cross certificates.  The CML uses the accompanying Storage 
and Retrieval Library (SRL) (optionally) to provide local certificate
and CRL storage management functions.  The SRL (optionally) provides 
remote directory retrieval capabilities using the Lightweight
Directory Access Protocol (LDAP).

The CML has been thoroughly tested including validating X.509 
Certificates and CRLs created by a variety of Certification 
Authority (CA) products, and signed using the Digital Signature
Algorithm (DSA) and RSA algorithms.  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. 

v2.1 CML includes the following enhancements (compared to v2.0.1 
CML release):

1) To make it easier for integrators to retrieve and compile the
source code for the CML, Access Control Library (ACL), and S/MIME
Freeware Library (SFL), we delivered a consolidated release zip 
file including the source code, project files, make
files, and readme files for the SFL, CML, SRL, ACL, CTIL, and
CTILManager libraries.  

2) Enhanced to use a standard Exception class derived from the
C++ std::exception class that will enable applications to catch 
all exceptions using the standard class.  This enhancement will 
reduce the amount of time required to integrate the SFL, CML, ACL,
and eSNACC libraries into applications.  

3) Enhanced CML path-processing code to increase its compliance 
with the RFC 3280 IETF Public Key Infrastructure X.509 (PKIX) 
Certificate and Certificate Revocation List (CRL) profile 
requirements such as: special-case processing associated with 
intermediate self-issued certificates; non-self-signed trusted 
certificates used as trust anchors; and name constraints 
processing clarifications.  

4) Enhanced CML C++ Application Programming Interface (API) to 
increase the consistency of the APIs provided by the CML, SFL, 
and ACL.  

5) Enhanced to add support for processing the OrderedList 
extension specified in the 2000 X.509 Recommendation.

6) Enhanced CML C++ library to support name constraints processing
of the IPAddress GeneralName type.

7) Enhanced CML certification path building process to skip paths 
with known errors.  

8) Enhanced to add support for the X.520 pseudonym attribute in 
distinguished names.

9) Enhanced to add support for the OCSPSigning extended key usage
and anyExtendedKeyUsage object identifiers.

10) Enhanced CML ASN.1 decode routines that compose the cmlasn1 
library.

11) Enhanced to add the Attribute Certificate (AC) C++ Class to 
the cmlasn1 library.

12) See the CML web site and CML API document for further details.

v2.1 SRL includes the following enhancements (compared to v2.0.1 
SRL release):

1) Enhanced to perform Lightweight Directory Access Protocol (LDAP)
retrievals of ACs, Attribute Authority Revocation Lists, Attribute
Descriptor Certificates, CRLs, and Security Policy Information 
Files (SPIF).

2) Enhanced to use the current release of the GNU Data Base Manager.

3) Enhanced to add a "refresh period" field to the database to 
indicate when the SRL should attempt to retrieve updated CRLs from
 the directory. 

4) Enhanced to use the hash value of the database object as an 
index value.   

5) Enhanced to convert the previous CRL and Certificates database 
versions to the new versions.  

6) Enhanced the SRL_DatabaseRemove source code that includes the 
hash value as an argument.  

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 makes calls to an algorithm-independent CTIL API that provides
access to a variety of external crypto libraries.  There is a CTIL for 
each crypto library that maps the generic CTIL API calls to the 
specific calls for that crypto library.  Getronics provides CTILs for
the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and 
FORTEZZA Cryptologic Interface libraries.  Getronics also provides a 
PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used 
with the CML.  The underlying, external crypto libraries are not 
distributed as part of the CML software. 

The CML has been successfully tested with the v2.1 S/MIME Freeware 
Library (SFL) that is freely available from 
<http://www.getronicsgov.com/hot/sfl_home.htm>.  

The CML has been successfully tested with the Access Control 
Library (ACL) that is freely available to everyone from: 
<http://www.getronicsgov.com/hot/acl_home.htm>.

The CML has been successfully used to build and verify 
certificate paths used in the Bridge Certification Authority (BCA)
demonstration which includes cross-certified hierarchical and non-
hierarchical PKIs.  The BCA Interoperability Test Suite (BITS)
is a free and openly available test resource provided to 
facilitate vendor development of secure, interoperable Public
Key Enabled applications.  The CML has been used to successfully
develop and verify the BITS X.509 certification paths available
from <http://bcatest.atl.getronicsgov.com>.  

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 CML meets the requirements stated in the SDN.706 Certificate/
CRL Profile required by the U.S. Defense Message System (DMS) 
project.

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

content-class: urn:content-classes:message
Subject: v1.4 Enhanced SNACC Freeware Now Available
Date: Thu, 1 Aug 2002 11:46:37 -0400
From: "Pawling, John" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

All,

Getronics Government Solutions has delivered the v1.4 eSNACC
Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library
source code compilable for Linux, Sun Solaris 2.8 and Microsoft (MS) 
Windows NT/98/2000/XP.  The eSNACC software is freely available to
everyone from: <http://www.getronicsgov.com/hot/snacc_home.htm>.

The eSNACC ASN.1 software can be used to ASN.1 encode and decode
objects.  In past releases, Getronics improved the eSNACC C++ 
library to implement the Distinguished Encoding Rules (DER), 
support large ASN.1 INTEGERs, and improve memory usage.    

v1.4 eSNACC enhancements (compared to v1.3 R10 release):

1) Enhanced AsnInt class to support string form of large 
integers (binary & hex strings).   

2) Enhances AsnInt so that it does not use AsnOcts or 
CSM_Buffer. 

3) Remove CSM_Buffer as base class for AsnInt and all of 
the string classes.  Also deleted the xxxStringSNACC 
classes (i.e., BMPStringSNACC).  

4) Added the remaining asn-useful types (UTCTime, 
GeneralizedTime, etc.) into eSNACC C and C++ libraries as
native built-in types.  This removes the unnecessary
complexity of having to build a boot compiler prior to 
building the final compiler.

5) Enhanced to use a standard Exception class derived from the
C++ std::exception class that will enable applications to catch 
all exceptions using the standard class.  This enhancement will 
reduce the amount of time required to integrate the SFL, CML, ACL,
and eSNACC libraries into applications.  

6) Re-wrote makefiles to make build process easier and faster.

7) Enhanced AsnBits class to construct BitStrings from 
binary strings.

8) Added AsnSetOf and AsnSeqOf templates.

9) Moved BDecPdu to AsnType, so every type as access to it now.
This was done to reduce the number of symbols & methods the
compiler generates.
  
10) Enhanced compiler to remove -u switch because useful types
are now in the runtime library.

We successfully tested the v1.4 eSNACC ASN.1 C++ and C libraries
using the Simple Network Management Protocol (SNMP) v1 test
suite (18,000 test cases) developed by the University of Oulu.    

We tested the v1.4 eSNACC release with the v2.1 S/MIME
Freeware Library (SFL) available from 
<http://www.getronicsgov.com/hot/sfl_home.htm> that 
uses the eSNACC ASN.1 software to encode and decode the IETF 
S/MIME v3 Cryptographic Message Syntax (RFC 2630) and Enhanced
Security Services for S/MIME (RFC 2634) security protocol.  

We tested the v1.4 eSNACC release with the freeware v2.1
Certificate Management Library (CML) available from
<http://www.getronicsgov.com/hot/cml_home.htm> 
that uses the eSNACC ASN.1 software to encode and decode X.509 
certificates, attribute certificates and Certificate Revocation 
Lists as specified in the 2000 X.509 Recommendation.

We tested the v1.4 eSNACC release with the freeware v2.1 
Access Control Library (ACL) available from 
<http://www.getronicsgov.com/hot/acl_home.htm>
that uses the eSNACC ASN.1 software to encode and decode security
labels and other objects (such as Security Policy Information 
Files) required to provide rule based automated access control 
as specified in SDN.801.

The eSNACC ASN.1 software implements the majority of the 
ASN.1 encoding/decoding rules as specified in the 1988 X.209 
Recommendation.  It implements the DER as specified in the 1997 
X.690 Recommendation.  It does not support all of the latest ASN.1
features, but there are strategies that allow it to be used to 
produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note
that many of the PKIX specs, such as RFC 3280 and RFC 2630, include 
1988-compliant ASN.1 syntax modules which can be compiled using the
eSNACC compiler.  Getronics plans to enhance eSNACC to support 
additional ASN.1 features.

The eSNACC ASN.1 library is totally unencumbered as stated 
in the Enhanced SNACC Software Public License.  All source code
for the eSNACC software is being provided at no cost and with no
financial limitations regarding its use and distribution.  
Organizations can use the eSNACC software without paying
any royalties or licensing fees.  

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

We welcome all feedback regarding the eSNACC software.
If bugs are reported, then we will investigate each reported
bug and, if required, will produce a patch or an updated
release of the software to repair the bug. 

This release announcement was sent to several mail lists,
but please send all messages regarding the eSNACC 
software to the imc-snacc mail list ONLY.  Please do not send 
messages regarding the eSNACC software to any of the 
IETF mail lists.  We will respond to all messages sent to the
imc-snacc mail list.

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

Date: Thu, 1 Aug 2002 14:51:36 +0200 (MET DST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re:  TSP interoperability testing (RFC 3161)
Sender: [email-masked]

> 
> >At the Yokohama meeting, during my presentation on RFC3161bis, I advertised
> >that despite the existence of about 10 different implementations of RFC 3161,
> >interoperability testing of TSP had not yet been done.
> 
> Actually Peter Sylvester has done a fair bit of this with his TSA and assorted
> clients... in fact I think there's been quite a bit of informal testing, just
> no big grand unified test.

Indeed, since October 1st 2000, see http:://timestamping.edelweb.fr