Re: CPS Pointer

[Paul Hoffman / IMC <[e-mail]>]

At 2:32 PM -0400 4/30/01, Housley, Russ wrote:
>Trevor Freeman noticed we don't have any guidelines for what forms 
>of URI are supported with the CPS Pointer.  Presently, we say:
>
>    The CPS Pointer qualifier contains a pointer to a 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.  No action is mandated by this specification regardless
>    of the criticality value asserted for the extension.
>
>So, we are not mandating any behavior on the client.

Nor should we. The "client" might be offline, such as a mail user 
agent that uses S/MIME. The "client" might have no user interface for 
certificates, such as an IPsec box.

Let's be realistic: will the end user reading the CPS affect the 
actions in more that 0.000001% of PKI transactions? If a user has 
already loaded a root cert, there is essentially no chance that they 
will read a CPS after the fact.

I propose that you don't change anything.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA21041 for <[e-mail]>; Mon, 30 Apr 2001 23:32:50 -0700 (PDT)
Received: from [38.29.132.63] ([38.29.132.63]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA23700; Mon, 30 Apr 2001 23:32:00 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05001904b71403d1e953@[38.29.132.63]>
Date: Mon, 30 Apr 2001 23:31:38 -0700
To: OSI Directory List <[e-mail]>, "X.509":;
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: Defect resolution for X.509
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Hello

A new defect, DR 279, to X.509/9594-8 has been posted in pdf on the server at

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

The proposed resolutions for this defect and others have been 
incorporated into two Draft Technical Corrigenda and submitted to 
ISO/IEC SC6 for ballot.

The following URL points to Draft Technical Corrigenda 10 for the 
third edition (1997) of 9594-8

 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/8-DTC10%283rd%29.doc

The following URL points to Draft Technical Corrigenda 2 for the 
fourth edition (2000) of 9594-8

 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/8-DTC2%284th%29.doc

The ballot period for a DTC ballot is normally three months. National 
Bodies and Liaison Organizations may submit comments on these DTCs. 
Note that comments cannot come directly from individuals but must 
come as contributions from the organizations themselves.

please vote early and often

    hoyt


Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA02298; Mon, 30 Apr 2001 18:14:21 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100343b71397f1c8c4@[165.227.249.20]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Mon, 30 Apr 2001 15:40:04 -0700
To: "Housley, Russ" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: CPS Pointer
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 2:32 PM -0400 4/30/01, Housley, Russ wrote:
>Trevor Freeman noticed we don't have any guidelines for what forms 
>of URI are supported with the CPS Pointer.  Presently, we say:
>
>    The CPS Pointer qualifier contains a pointer to a 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.  No action is mandated by this specification regardless
>    of the criticality value asserted for the extension.
>
>So, we are not mandating any behavior on the client.

Nor should we. The "client" might be offline, such as a mail user 
agent that uses S/MIME. The "client" might have no user interface for 
certificates, such as an IPsec box.

Let's be realistic: will the end user reading the CPS affect the 
actions in more that 0.000001% of PKI transactions? If a user has 
already loaded a root cert, there is essentially no chance that they 
will read a CPS after the fact.

I propose that you don't change anything.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA20180 for <[e-mail]>; Mon, 30 Apr 2001 14:52:09 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id RAA02946; Mon, 30 Apr 2001 17:52:09 -0400 (EDT)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id <2YBR63H4>; Mon, 30 Apr 2001 17:57:31 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail], "'David A. Cooper'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: delta CRL security considerations
Date: Mon, 30 Apr 2001 17:56:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

This might be the time to mention a slightly different point about delta
CRLs and bandwidth. In David Cooper's paper, he assumes that the metric to
be optimized is peak bandwidth. While this is probably correct for many or
most organizations, it is at least possible that some will want to optimize
aggregate bandwidth. (For example, if you pay by the byte.) Almost any use
of delta CRLs will reduce this.

Hal

> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Monday, April 30, 2001 4:53 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: delta CRL security considerations
> 
> 
> Sam, I agree completely.  Maybe I fell into a semantic trap 
> by seeming to imply that "publish" meant "push all the way 
> out to every user, whether they want them or not."  That 
> wasn't my intent.  By "publish" I meant "make available in a 
> directory to anyone who looks there."
> 
> In most cases, the distance between the CA and a standard 
> repository or directory is probably measured in meters, so 
> that bandwidth is not much of a concern.  But the bandwidth 
> consumed by all of the users, and especially those that may 
> be at sea or otherwise have only limited communications 
> facilities available to them, is very much a concern.
> 
> Bob
> 
> >>> Sam Schaen <[e-mail]> 04/30/01 02:41PM >>>
> 
> 
> Bob Jueneman wrote:
> 
> > Tim,
> >
> > Publishing a full CRL every time a delta is published does 
> seem to negate most of the benefit of the delta CRL approach.
> >
> 
> I just wanted to dispute the above statement.  We [DOD] have 
> an architecture in which the CAs and Directories are 
> connected either by high speed LAN or ATM network.  We're not 
> as concerned about the bandwidth cost of pushing the full 
> CRLs to the directory as the total bandwidth from all the end 
> entities fetching CRLs from the directory.  To the extent 
> that end-entities can make use of delta CRLs
> instead of full CRLs, we think there would be an advantage in 
> our environment.  Clearly there will be other environments 
> that would be concerned with the cost of publishing the full CRL.
> 
> [snip]
> 
> 
> 


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA15164 for <[e-mail]>; Mon, 30 Apr 2001 13:53:33 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 30 Apr 2001 14:53:00 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Mon, 30 Apr 2001 14:52:59 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: delta CRL security considerations
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id NAA15166

Sam, I agree completely.  Maybe I fell into a semantic trap by seeming to imply that "publish" meant "push all the way out to every user, whether they want them or not."  That wasn't my intent.  By "publish" I meant "make available in a directory to anyone who looks there."

In most cases, the distance between the CA and a standard repository or directory is probably measured in meters, so that bandwidth is not much of a concern.  But the bandwidth consumed by all of the users, and especially those that may be at sea or otherwise have only limited communications facilities available to them, is very much a concern.

Bob

>>> Sam Schaen <[e-mail]> 04/30/01 02:41PM >>>


Bob Jueneman wrote:

> Tim,
>
> Publishing a full CRL every time a delta is published does seem to negate most of the benefit of the delta CRL approach.
>

I just wanted to dispute the above statement.  We [DOD] have an architecture in which the CAs and Directories are connected either by high speed LAN or ATM network.  We're not as concerned about the bandwidth cost of pushing the full CRLs to the directory as the total bandwidth from all the end entities fetching CRLs from the directory.  To the extent that end-entities can make use of delta CRLs
instead of full CRLs, we think there would be an advantage in our environment.  Clearly there will be other environments that would be concerned with the cost of publishing the full CRL.

[snip]





Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [128.29.154.90]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA14234 for <[e-mail]>; Mon, 30 Apr 2001 13:42:24 -0700 (PDT)
Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.9.3/8.9.3) with ESMTP id QAA12138; Mon, 30 Apr 2001 16:41:48 -0400 (EDT)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv2.mitre.org (8.9.3/8.9.3) with ESMTP id QAA27771; Mon, 30 Apr 2001 16:41:47 -0400 (EDT)
Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub2.mitre.org with SMTP id 6495061; Mon, 30 Apr 2001 16:41:44 -0400
Message-ID: <[e-mail]>
Date: Mon, 30 Apr 2001 16:41:29 -0400
From: Sam Schaen <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.76 [en]C-20010313M  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: delta CRL security considerations
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:

> Tim,
>
> Publishing a full CRL every time a delta is published does seem to negate most of the benefit of the delta CRL approach.
>

I just wanted to dispute the above statement.  We [DOD] have an architecture in which the CAs and Directories are connected either by high speed LAN or ATM network.  We're not as concerned about the bandwidth cost of pushing the full CRLs to the directory as the total bandwidth from all the end entities fetching CRLs from the directory.  To the extent that end-entities can make use of delta CRLs
instead of full CRLs, we think there would be an advantage in our environment.  Clearly there will be other environments that would be concerned with the cost of publishing the full CRL.

[snip]




Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA12360 for <[e-mail]>; Mon, 30 Apr 2001 13:17:06 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA375016; Mon, 30 Apr 2001 16:14:57 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id QAA57752; Mon, 30 Apr 2001 16:11:20 -0400
Importance: Normal
Subject: RE: keyCertSign and cRLSign Key Usage Bits
To: "Housley, Russ" <[e-mail]>
Cc: Sharon Boeyen <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 30 Apr 2001 16:16:29 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 04/30/2001 04:16:26 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     My reasoning is somewhat different, but I agree with Russ that in the
case where the CRL Signing certificate has the same subject name as the
issuing certificate for the certificates in the CRL the CRL signing
certificate is part of the core CA functionality and belongs in the
caCertificate attribute.  When the subject names match, it is probably
easiest to think of the two certificates as owned by separate modules
within the CA.
     This does not dispose of the signer of an AA's CRL, nor of the case
where the CA assigns a differently named entity to sign CRL's for it.

          Tom Gindin


"Housley, Russ" <[e-mail]> on 04/30/2001 03:21:13 PM

To:   Sharon Boeyen <[e-mail]>
cc:   [e-mail]
Subject:  RE: keyCertSign and cRLSign Key Usage Bits


Sharon:

In my view, certificates that contain public keys used to verify signatures

on certificates or CRLs belong to CAs, thus they belong in the
cACertificate attribute.

Russ

At 10:41 AM 4/26/2001 -0400, Sharon Boeyen wrote:
>That raises another point - if we modify all this "stuff" to allow
>entities other than authorities to sign CRLs, where would those
>certificates be stored? The subjects aren't CAs so they don't really
>belong in either of these attributes. Inventing another attribute and
>object class isn't very attractive either. Thoughts?




Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA11492 for <[e-mail]>; Mon, 30 Apr 2001 13:08:34 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Apr 2001 20:08:28 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA25013 for <[e-mail]>; Mon, 30 Apr 2001 16:08:35 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NS7KH>; Mon, 30 Apr 2001 16:08:34 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.3]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NS7KF; Mon, 30 Apr 2001 16:08:28 -0400
From: "Housley, Russ" <[e-mail]>
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 30 Apr 2001 16:08:20 -0400
Subject: Re: Dedicated CRL signing keys
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Dave:

The current text supports your position.  That is, CAs MAY use separate 
keys, and applications SHOULD be able to handle it.

Russ

= = = = = = = = = = =

5.1.1.3  signatureValue

    The signatureValue field contains a digital signature computed upon
    the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded tbsCertList
    is used as the input to the signature function.  This signature value
    is then ASN.1 encoded as a BIT STRING and included in the CRL's
    signatureValue field.  The details of this process are specified for
    each of the supported algorithms in [PKIXALGS].

    CAs MAY use one private key to digitally sign certificates and CRLs,
    or CAs MAY use separate private keys to digitally sign certificates
    and CRLs.  When separate private keys are employed, each of the
    public keys associated with these private keys is placed in a
    separate certificate, one with the keyCertSign bit set in the key
    usage extension, and one with the cRLSign bit set in the key usage
    extension (see sec. 4.2.1.3).  When separate private keys are
    employed, certificates issued by the CA contain one authority key
    identifier, and the corresponding CRLs contain a different authority
    key identifier.  The use of separate CA certificates for validation
    of certificate signatures and CRL signatures can offer improved
    security characteristics; however, it imposes a burden on
    applications, and it might limit interoperability.  Many applications
    construct a certification path, and then validate the certification
    path (see sec. 6).  CRL checking in turn requires a separate
    certification path to be constructed and validated for the CA's CRL
    signature validation certificate.  Applications that perform CRL
    checking MUST support certification path validation when certificates
    and CRLs are digitally signed with the same CA private key.  These
    applications SHOULD support certification path validation when
    certificates and CRLs are digitally signed with different CA private
    keys.


At 11:52 AM 4/30/2001 -0400, David P. Kemp wrote:
>If certificate-using applications MAY handle CRLs signed by a different key
>than the certificates, then CAs have no real ability to exercise that option.
>
>I believe:
>
>Certificate-using applications SHOULD handle CRLs signed by a different key
>than the certificates.
>
>Dave
>
>
>
>"Housley, Russ" wrote:
> > Yes.  So, I guess we agree.
> >
> > At 04:47 PM 4/26/2001 -0400, Santosh Chokhani wrote:
> > > Russ: Will a CA that signs the certificates and CRLs using different 
> keys,
> > > but same Issuer DN be considered compliant?  If yes, then we agree.
> > >
> > > From: Housley, Russ [mailto:[e-mail]]
> > > > Certificate-using applications must be able to handle certificates 
> and CRLs
> > > > signed by the same key.  Certificate-using applications may handle CRLs
> > > > signed by a different key than the certificates.
> > > >
> > > > If you agree with this position, then we agree.
> > > >
> > > > Russ


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA10903 for <[e-mail]>; Mon, 30 Apr 2001 13:03:21 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <J432YBX7>; Mon, 30 Apr 2001 16:02:50 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Date: Mon, 30 Apr 2001 15:56:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D1AF.AEE10B80"

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_01C0D1AF.AEE10B80
Content-Type: text/plain

>From recent exchanges on the list, I'm less convinced that we need to push 
a defect report against 509 on this topic right now. If we want to loosen 
some of the language in 509 we can do that through the regular process of
new
work. From your last few messages, I suspect things will be ok that way. If 
not let Hoyt and I know and we'll resurrect the defect.

Thanks
Sharon 


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Monday, April 30, 2001 3:21 PM
> To: Sharon Boeyen
> Cc: [e-mail]
> Subject: RE: keyCertSign and cRLSign Key Usage Bits
> 
> 
> Sharon:
> 
> In my view, certificates that contain public keys used to 
> verify signatures 
> on certificates or CRLs belong to CAs, thus they belong in the 
> cACertificate attribute.
> 
> Russ
> 
> At 10:41 AM 4/26/2001 -0400, Sharon Boeyen wrote:
> >That raises another point - if we modify all this "stuff" to allow 
> >entities other than authorities to sign CRLs, where would those 
> >certificates be stored? The subjects aren't CAs so they don't really 
> >belong in either of these attributes. Inventing another 
> attribute and 
> >object class isn't very attractive either. Thoughts?
> 

------_=_NextPart_001_01C0D1AF.AEE10B80
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: keyCertSign and cRLSign Key Usage Bits</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>From recent exchanges on the list, I'm less convinced that we need to push </FONT>
<BR><FONT SIZE=2>a defect report against 509 on this topic right now. If we want to loosen </FONT>
<BR><FONT SIZE=2>some of the language in 509 we can do that through the regular process of new</FONT>
<BR><FONT SIZE=2>work. From your last few messages, I suspect things will be ok that way. If </FONT>
<BR><FONT SIZE=2>not let Hoyt and I know and we'll resurrect the defect.</FONT>
</P>

<P><FONT SIZE=2>Thanks</FONT>
<BR><FONT SIZE=2>Sharon </FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Housley, Russ [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, April 30, 2001 3:21 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: keyCertSign and cRLSign Key Usage Bits</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sharon:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In my view, certificates that contain public keys used to </FONT>
<BR><FONT SIZE=2>&gt; verify signatures </FONT>
<BR><FONT SIZE=2>&gt; on certificates or CRLs belong to CAs, thus they belong in the </FONT>
<BR><FONT SIZE=2>&gt; cACertificate attribute.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Russ</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At 10:41 AM 4/26/2001 -0400, Sharon Boeyen wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;That raises another point - if we modify all this &quot;stuff&quot; to allow </FONT>
<BR><FONT SIZE=2>&gt; &gt;entities other than authorities to sign CRLs, where would those </FONT>
<BR><FONT SIZE=2>&gt; &gt;certificates be stored? The subjects aren't CAs so they don't really </FONT>
<BR><FONT SIZE=2>&gt; &gt;belong in either of these attributes. Inventing another </FONT>
<BR><FONT SIZE=2>&gt; attribute and </FONT>
<BR><FONT SIZE=2>&gt; &gt;object class isn't very attractive either. Thoughts?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D1AF.AEE10B80--


Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA09708 for <[e-mail]>; Mon, 30 Apr 2001 12:52:15 -0700 (PDT)
Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by nebula.x509.com (8.11.3/XCERT) with ESMTP id f3UJpib22367 for <[e-mail]>; Mon, 30 Apr 2001 12:51:44 -0700 (PDT)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.3/XCERT) with ESMTP id f3UJpih11989 for <[e-mail]>; Mon, 30 Apr 2001 12:51:44 -0700 (PDT)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <JXS703M1>; Mon, 30 Apr 2001 12:51:56 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.92]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NS68S; Mon, 30 Apr 2001 15:49:40 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 30 Apr 2001 14:32:27 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: CPS Pointer
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Trevor Freeman noticed we don't have any guidelines for what forms of URI 
are supported with the CPS Pointer.  Presently, we say:

    The CPS Pointer qualifier contains a pointer to a 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.  No action is mandated by this specification regardless
    of the criticality value asserted for the extension.

So, we are not mandating any behavior on the client.  Perhaps we should say 
something about the CA.  Trevor suggests that HTTP and FTP forms of URI are 
sufficient.  Does anyone see any reason to support other protocols for CPS 
fetching?

Russ


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA09516 for <[e-mail]>; Mon, 30 Apr 2001 12:49:57 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Apr 2001 19:49:50 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA23414 for <[e-mail]>; Mon, 30 Apr 2001 15:49:56 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <JY8NS69A>; Mon, 30 Apr 2001 15:49:56 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.92]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JY8NS68W; Mon, 30 Apr 2001 15:49:43 -0400
From: "Housley, Russ" <[e-mail]>
To: Sharon Boeyen <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 30 Apr 2001 15:21:13 -0400
Subject: RE: keyCertSign and cRLSign Key Usage Bits
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Sharon:

In my view, certificates that contain public keys used to verify signatures 
on certificates or CRLs belong to CAs, thus they belong in the 
cACertificate attribute.

Russ

At 10:41 AM 4/26/2001 -0400, Sharon Boeyen wrote:
>That raises another point - if we modify all this "stuff" to allow 
>entities other than authorities to sign CRLs, where would those 
>certificates be stored? The subjects aren't CAs so they don't really 
>belong in either of these attributes. Inventing another attribute and 
>object class isn't very attractive either. Thoughts?


Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA06047 for <[e-mail]>; Mon, 30 Apr 2001 11:10:32 -0700 (PDT)
Received: from 157.54.1.52 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Apr 2001 10:45:41 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 30 Apr 2001 10:45:45 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 30 Apr 2001 10:45:32 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 30 Apr 2001 10:45:23 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Dedicated CRL signing keys
Date: Mon, 30 Apr 2001 10:45:22 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Dedicated CRL signing keys
Thread-Index: AcDRjiuM9kZ3CvNDQ1m/cqxLcetmeAADdDLA
From: "Trevor Freeman" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 30 Apr 2001 17:45:23.0297 (UTC) FILETIME=[55070D10:01C0D19D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id LAA06049

I prefer the statement as is. Changing the may to a should does not get
the CAs off the hook. A CA has to make a decision as to what
expectations it has for the certificate consuming population of clients
it suports. A should is not a must, so this means that conformant
clients are not mandated to support CRLs signed with different keys.
Vendors thinking of implementing X.509 technology in constrained devices
will start looking at alternatives if the bar is set to high for
conformant client.

Trevor
-----Original Message-----
From: David P. Kemp [mailto:[e-mail]] 
Sent: Monday, April 30, 2001 8:53 AM
To: [e-mail]
Subject: Re: Dedicated CRL signing keys

If certificate-using applications MAY handle CRLs signed by a different
key
than the certificates, then CAs have no real ability to exercise that
option.

I believe:

Certificate-using applications SHOULD handle CRLs signed by a different
key
than the certificates.

Dave



"Housley, Russ" wrote:
> Yes.  So, I guess we agree.
> 
> At 04:47 PM 4/26/2001 -0400, Santosh Chokhani wrote:
> > Russ: Will a CA that signs the certificates and CRLs using different
keys,
> > but same Issuer DN be considered compliant?  If yes, then we agree.
> >
> > From: Housley, Russ [mailto:[e-mail]]
> > > Certificate-using applications must be able to handle certificates
and CRLs
> > > signed by the same key.  Certificate-using applications may handle
CRLs
> > > signed by a different key than the certificates.
> > >
> > > If you agree with this position, then we agree.
> > >
> > > Russ


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA01768 for <[e-mail]>; Mon, 30 Apr 2001 10:04:46 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 30 Apr 2001 11:04:07 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Mon, 30 Apr 2001 11:03:54 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: delta CRL security considerations
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA01770

Tim,

Publishing a full CRL every time a delta is published does seem to negate most of the benefit of the delta CRL approach.

But realistically, probably 90% or more of certificate revocations will be for relatively benign reasons -- someone changed their name, address, department, or even the organization they work for -- but their keys have not been compromised.

Without falling into the nonrepudiation tar pit, it may be worth observing that in virtually all of those cases, the individual involved is still liable for whatever they might have been liable for before their status changed, UNLESS there was a change in the extent to which an individual was acting as an authorized agent of the organization, e.g., a purchasing agent or an officer of the company.

You might want to consider adding something to the security considerations section that recommends that a full CRL be published along with a delta for any revocations for cause, such as key compromise or change or agency.  For the rest of the revocations, presumably it will be sufficient to wait until the next regularly scheduled CRL, whenever that is.

I'm not terribly concerned about minimally compliant relying party software.  Anyone who is using certificates for any important purpose, as opposed to say casual e-mail or routine SSL server certificates, will almost certainly not use such minimally compliant software.

Bob


Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software



>>> Tim Polk <[e-mail]> 04/27/01 02:39PM >>>
Folks,

It appears that the WG consensus is to remove the requirement for 
publication of full CRLs with every delta CRL from son-of-2459.  As a 
result, there is a possibility that minimally compliant PKI clients will 
not have the same information provided to clients that process delta 
CRLs.  It seems appropriate to note this fact in the security 
considerations section.  We are proposing insertion of four new sentences 
into the paragraph on revocation.  I have supplied the entire paragraph 
here.  The new text begins and ends with two asterisks.

-------- excerpt from security considerations ----

The availability and freshness of revocation information will affect the 
degree of assurance that ought to be placed in a certificate. While 
certificates expire naturally, events may occur during its natural lifetime 
which negate the binding between the subject and public key.  If revocation 
information is untimely or unavailable, the assurance associated with the 
binding is clearly reduced.  **Relying parties might not be able to process 
every critical extension that can appear in a CRL.  CAs SHOULD take extra 
care when making revocation information available only through CRLs that 
contain critical extensions, particularly if support for those extensions 
is not mandated by this profile.  For example, if revocation information is 
supplied using a combination of delta CRLs and full CRLs, and the delta 
CRLs are issued more frequently than the full CRLs, then relying parties 
that cannot handle the critical extensions related to delta CRL processing 
will not be able to obtain the most recent revocation 
information.  Alternatively, if a full CRL is issued whenever a delta CRL 
is issued, then timely revocation information will be available to all 
relying parties.**  Similarly, implementations of the Path Validation 
mechanism described in section 6 that omit revocation checking provide less 
assurance than those that support it.

----------------end of excerpt------------

Your comments would be appreciated.

Thanks,

Tim Polk



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA27302 for <[e-mail]>; Mon, 30 Apr 2001 08:55:28 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA11629 for <[e-mail]>; Mon, 30 Apr 2001 11:54:59 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Mon, 30 Apr 2001 11:52:57 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Dedicated CRL signing keys
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If certificate-using applications MAY handle CRLs signed by a different key
than the certificates, then CAs have no real ability to exercise that option.

I believe:

Certificate-using applications SHOULD handle CRLs signed by a different key
than the certificates.

Dave



"Housley, Russ" wrote:
> Yes.  So, I guess we agree.
> 
> At 04:47 PM 4/26/2001 -0400, Santosh Chokhani wrote:
> > Russ: Will a CA that signs the certificates and CRLs using different keys,
> > but same Issuer DN be considered compliant?  If yes, then we agree.
> >
> > From: Housley, Russ [mailto:[e-mail]]
> > > Certificate-using applications must be able to handle certificates and CRLs
> > > signed by the same key.  Certificate-using applications may handle CRLs
> > > signed by a different key than the certificates.
> > >
> > > If you agree with this position, then we agree.
> > >
> > > Russ


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA25094 for <[e-mail]>; Mon, 30 Apr 2001 08:45:03 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA11039 for <[e-mail]>; Mon, 30 Apr 2001 11:44:31 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Mon, 30 Apr 2001 11:42:24 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: keyCertSign and cRLSign Key Usage Bits
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

I am not concerned about mixing ACs and PKCs on one CRL.  I am concerned
about unnecessary complexity in the PKIX spec and unnecessary changes to
X.509.  You have expanded the description of the cRLSign bit from one
sentence to six for no good reason.  As Steve Kent says, 

   "We need to make a decision on whether a cert without a CA flag
    enabled can sign CRLs.  If so, then we need to modify a lot of text
    in 2459, and X.509, to say this clearly."

There is no security benefit to changing the text.  For that reason, I
oppose making it more complex. 

Rationale:

1) Previously, conforming clients could validate a CRL if the cRLSign
   bit is asserted and the cA flag is not asserted.  This change
   would declare such clients to be non-conforming.

2) There have been discussions here regarding the necessity of
   distinguishing between "authority" certificates and "non-authority"
   certificates for CRL validation.  If the cA flag is to be used
   to convey "authority-ness" for CRLs containing PKCs, what is the
   equivalent mechanism PKIX clients are expected to use to recognize
   the "authority" for CRLs containing ACs?

   My position is that no additional flag is needed in either the CA or
   the AA case.  If the CRL signer has a valid certificate with the
   cRLSign bit set, then it is an authority because the certificate
   signer (or it's parent) has said so. Requiring two flags in the
   same certificate is no more secure than requiring one.

3) The quote from the AC profile does not make sense to me.  If an
   authority can sign both PKCs and ACs, surely it can guarantee that
   it will not assign duplicate serial numbers.  There may be good
   (operational) reasons for using separate keys to sign PKCs and ACs,
   but "confusion regarding serial numbers and revocations" isn't
   one of them.

Dave



Russ Housley wrote:
> 
> Dave:
> 
> This is not a change.  Rather, it complements the AC profile.  The AC
> profile says:
> 
>     The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage
>     extension in the PKC MUST NOT explicitly indicate that the AC
>     issuer's public key cannot be used to validate a digital signature.
>     In order to avoid confusion regarding serial numbers and
>     revocations, an AC issuer MUST NOT also be a PKC Issuer.  That is,
>     an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST
>     NOT have a basicConstraints extension with the cA BOOLEAN set to
>     TRUE.
> 
> Since one issuer cannot issue both ACs and PKCs, then I would expect them
> to employ separate CRLs.
> 
> Are you suggesting that ACs and PKCs might be mixed together on one CRL
> using the indirect CRL mechanism?
> 
> Russ
> 
> At 08:47 AM 4/25/2001 -0400, David P. Kemp wrote:
> >Russ,
> >
> >Thanks.
> >
> >However, I am more concerned about the second paragraph than the
> >first.  Is Last Call the proper time to be proposing, discussing,
> >and ratifying such a novel and significant change to the path validation
> >algorithm?
> >
> >        Such AA certificates MUST NOT be used to verify signatures
> >        on CRLs containing revocation information for public key
> >        certificates;  ...
> >
> >Dave


Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id XAA29604 for <[e-mail]>; Sun, 29 Apr 2001 23:19:06 -0700 (PDT)
Received: from 157.54.9.104 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 29 Apr 2001 23:17:13 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 29 Apr 2001 23:16:37 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 29 Apr 2001 23:16:35 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Sun, 29 Apr 2001 23:16:32 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta CRL security considerations
Date: Sun, 29 Apr 2001 23:16:32 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta CRL security considerations
Thread-Index: AcDPYEXItwqJDXYHQKismYoppT+IDQB3L2ng
From: "Trevor Freeman" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 30 Apr 2001 06:16:33.0152 (UTC) FILETIME=[1A576800:01C0D13D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id XAA29606

A similar comment can be made on the use of the Issuing Distribution
Point extension, which is another, critical, but not mandated to be
suported extension in the CRL.

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]] 
Sent: Friday, April 27, 2001 2:21 PM
To: Tim Polk; [e-mail]
Subject: Re: delta CRL security considerations

I think this is OK, but similar words have to go into the deltaCRL 
section as well. Some implementors might not think through the really 
nasty implications of not issuing full CRLs when they should.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from cybersoft.cybersoftnet.com (IP.net118-62.psi.net.pa [200.46.118.62] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA25603 for <[e-mail]>; Sun, 29 Apr 2001 12:08:17 -0700 (PDT)
From: [e-mail]
Received: from 200.46.118.62 (rsvp-208-187-151-155.ac05.dlls.eli.net [208.187.151.155]) by cybersoft.cybersoftnet.com (2.5 Build 2639 (Berkeley 8.8.6)/8.8.4) with SMTP id OAA00534; Sun, 29 Apr 2001 14:07:55 -0500
Message-Id: <[e-mail]>
Received: from [e-mail] by [e-mail] (8.8.5/8.6.5) with SMTP id GAA04375 for <[e-mail]>; Sun, 29 Apr 2001 14:39:03 -0600 (EST)
To: [e-mail]
Date: Sun, 29 Apr 01 14:39:03 EST
Subject: toner supplies
Reply-To: [e-mail]
X-PMFLAGS: VCXFDSGDG
X-UIDL: FGHFHFG576
Comments: Authenticated sender is <[e-mail]>

PLEASE FORWARD TO THE PERSON
RESPONSIBLE FOR PURCHASING
YOUR LASER PRINTER SUPPLIES


**** VORTEX  SUPPLIES ****

-SPECIALS OF THE DAY ON LASER TONER SUPPLIES AT DISCOUNT PRICES--

 
LASER PRINTER TONER CARTRIDGES
COPIER AND FAX CARTRIDGES

WE ARE -->THE<-- PLACE TO BUY YOUR TONER CARTRIDGES BECAUSE YOU
SAVE UP TO 30% FROM OFFICE DEPOT'S, QUILL'S OR OFFICE MAX'S EVERY DAY
LOW PRICES

ORDER BY PHONE:[phone]
ORDER BY FAX: [phone]
CUSTOMER SERVICE: 1-888-248-2015
E-MAIL REMOVAL LINE: 1-888-248-4930 

UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED)
ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL.

PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS).


IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. 
IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER
NO SHIPPING CHARGES FOR ORDERS $49 OR OVER
ADD $4.75 FOR ORDERS UNDER $49.
C.O.D. ORDERS ADD $4.5 TO SHIPPING CHARGES.

FOR THOSE OF YOU WHO REQUIRE MORE INFORMATION ABOUT OUR COMPANY
INCUDING FEDERAL TAX ID NUMBER, CLOSEST SHIPPING OR CORPORATE ADDRESS IN THE
CONTINENTAL U.S.  OR  FOR CATALOG  REQUESTS PLEASE CALL OUR CUSTOMER
SERVICE LINE  1-888-248-2015 
 

OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE  AS FOLLOWS: 

(PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER)
                                 
HEWLETT PACKARD: (ON PAGE 2)
                                   
ITEM #1  LASERJET SERIES  4L,4P (74A)------------------------$44
ITEM #2  LASERJET SERIES  1100 (92A)-------------------------$44
ITEM #3  LASERJET SERIES  2 (95A)-------------------------------$39
ITEM #4  LASERJET SERIES  2P (75A)-----------------------------$54 
ITEM #5  LASERJET SERIES  5P,6P,5MP, 6MP (3903A)--$44
ITEM #6  LASERJET SERIES  5SI, 5000 (29A)------------------$95
ITEM #7  LASERJET SERIES  2100 (96A)-------------------------$74
ITEM #8  LASERJET SERIES  8100 (82X)-----------------------$145
ITEM #9  LASERJET SERIES  5L/6L (3906A0------------------$35
ITEM #10 LASERJET SERIES  4V-------------------------------------$95
ITEM #11 LASERJET SERIES 4000 (27X)-------------------------$72
ITEM #12 LASERJET SERIES 3SI/4SI (91A)--------------------$54
ITEM #13 LASERJET SERIES 4, 4M, 5,5M-----------------------$49

HEWLETT PACKARD FAX (ON PAGE 2)

ITEM #14 LASERFAX 500, 700 (FX1)----------$49
ITEM #15  LASERFAX 5000,7000 (FX2)------$54
ITEM #16  LASERFAX (FX3)------------------------$59
ITEM #17  LASERFAX (FX4)------------------------$54

LEXMARK/IBM (ON PAGE 3)

OPTRA 4019, 4029 HIGH YIELD---------------$89
OPTRA R, 4039, 4049 HIGH YIELD---------$105
OPTRA E----------------------------------------------------$59
OPTRA N--------------------------------------------------$115
OPTRA S--------------------------------------------------$165
-
EPSON (ON PAGE 4)

ACTION LASER 7000,7500,8000,9000-------$105
ACTION LASER 1000,1500-------------------------$105

CANON PRINTERS (ON PAGE 5)

 PLEASE CALL FOR MODELS AND UPDATED PRICES
 FOR CANON PRINTER CARTRIDGES

PANASONIC (0N PAGE 7)

NEC SERIES 2 MODELS 90 AND 95----------$105

APPLE (0N PAGE 8)

LASER WRITER PRO 600 or 16/600------------$49 
LASER WRITER SELECT 300,320,360---------$74
LASER WRITER 300 AND 320----------------------$54
LASER WRITER NT, 2NT------------------------------$54
LASER WRITER 12/640--------------------------------$79



CANON FAX (ON PAGE 9)

LASERCLASS 4000 (FX3)---------------------------$59
LASERCLASS 5000,6000,7000 (FX2)---------$54
LASERFAX 5000,7000 (FX2)----------------------$54
LASERFAX 8500,9000 (FX4)----------------------$54


CANON COPIERS (PAGE 10)

PC 3, 6RE, 7 AND 11 (A30)---------------------$69
PC 300,320,700,720 and 760 (E-40)--------$89

IF YOUR CARTRIDGE IS NOT LISTED CALL CUSTOMER SERVICE AT 1-888-248-2015 

90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS.

ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE 
RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY.



Received: from mail2.okwork.gov.tw (IDENT:root@[163.29.128.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA25798 for <[e-mail]>; Sat, 28 Apr 2001 06:25:53 -0700 (PDT)
From: [e-mail]
Received: from 44mexi7server42 (IDENT:[e-mail] [127.0.0.1]) by mail2.okwork.gov.tw (8.9.3/8.9.3) with SMTP id VAA06122 for [e-mail]; Sat, 28 Apr 2001 21:34:44 +0800
Date: Sat, 28 Apr 2001 21:34:44 +0800
Message-Id: <[e-mail]>
To: <[e-mail]>
Subject: ADV: Top Search Engine Placement
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit

Removal instructions below.

I saw your listing on the internet.

I work for a company that specializes
in getting clients web sites listed
as close to the top of the major 
search engines as possible.

Our fee is only $29.95 per month to
submit your site at least twice a
month to over 350 search engines 
and directories.

To get started and put your web site
in the fast lane, call our toll free
number below.


Mike Bender
888-532-8842


To be removed call: 888-800-6339 X1377




Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA29298 for <[e-mail]>; Fri, 27 Apr 2001 15:44:11 -0700 (PDT)
Received: from plippa [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.06) id A64225350044; Sat, 28 Apr 2001 00:44:18 +0200
Received: from 127.0.0.1 [127.0.0.1] by plippa (IAIK S/MIME Mapper 2.0 17/November/2000); Sat, 28 Apr 2001 00:45:30 +0100
From: "Peter Lipp" <[e-mail]>
To: <[e-mail]>
Subject: practical use of certain extensions
Date: Sat, 28 Apr 2001 00:45:27 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
In-Reply-To: <[e-mail]>

Folks,

while I understand the mechanics of some of the extensions or parts of them
specified in x.509 and the certificate profice, I have not been able to
imagine under which circumstances these things would be useful and used.
Could somebody be kind enough to scetch a practical real-world scenario
where this would be the case:

- inhibitPolicyMapping
- inhibitAnyPolicy, including value for certificates that may follow...

Peter




Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA23590 for <[e-mail]>; Fri, 27 Apr 2001 14:22:36 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JX8DJHNT>; Fri, 27 Apr 2001 17:22:08 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "David A. Cooper" <[e-mail]>
Cc: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Date: Fri, 27 Apr 2001 17:13:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CF5E.DD447320"

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_01C0CF5E.DD447320
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:

I think that checking the basic constraints for CRL is a security
requirement on the clients we can do without.  No one has given any security
benefit of it.  All added checks do is add to complexity and hinder
interoperability. 

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Friday, April 27, 2001 4:05 PM
To: David A. Cooper
Cc: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits


David:

My intent was to impose a requirement on the CAs and AAs.  I can see that 
the proposed wording imposes a difficult requirement on clients.

Would anyone object to the deletion of that sentence?

If not, I think that the current state of these paragraphs is:

       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on public key certificates.  If the
       keyCertSign bit is asserted, then the cA bit in the basic
       constraints extension (see 4.2.1.10) MUST also be asserted.  If
       neither the cRLSign bit nor the keyCertSign bit are asserted, then
       the cA bit in the basic constraints extension MUST NOT be
       asserted.

       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on a certificate revocation list (e.g.,
       a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
       Authority (AA) certificates that are used to verify signatures on
       CRLs.  If the cRLSign bit is asserted in a CA certificate, then
       the cA bit in the basic constraints extension (see 4.2.1.10) MUST
       also be asserted.  If the cRLSign bit is asserted in a AA
       certificate, then the cA bit in the basic constraints extension
       MUST NOT be asserted.  If neither the cRLSign bit nor the
       keyCertSign bit are asserted, then the cA bit in the basic
       constraints extension MUST NOT be asserted.

Russ

At 09:37 AM 4/26/2001 -0400, David A. Cooper wrote:
>AA certificates MUST NOT be used to verify signatures on CRLs containing 
>revocation information for public key certificates". The problem is that, 
>even if a single entity is not allowed to issued both public key 
>certificates and attribute certificates, there is the possibility that a 
>single, indirect CRL could cover both types of certificates. If one is 
>using a CRL to check the status of a public key certificate, then it is 
>clear that the text below requires that the certificate containing the key 
>needed to verify the CRL signature must have the cA bit set. But what 
>about when one is using a CRL to check the status of an attribute 
>certificate? The quote text seem to suggest that, if the cA bit is not set 
>in the certificate, the relying party is required to verify that the CRL 
>does not contain any revocation information for public key certificates. I 
>can't imagine that there was any intention to impose such a requirement, 
>but that is what the text seems to say.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: keyCertSign and cRLSign Key Usage Bits</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I think that checking the basic constraints for CRL =
is a security requirement on the clients we can do without.&nbsp; No =
one has given any security benefit of it.&nbsp; All added checks do is =
add to complexity and hinder interoperability. </FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, April 27, 2001 4:05 PM</FONT>
<BR><FONT SIZE=3D2>To: David A. Cooper</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: keyCertSign and cRLSign Key Usage =
Bits</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>My intent was to impose a requirement on the CAs and =
AAs.&nbsp; I can see that </FONT>
<BR><FONT SIZE=3D2>the proposed wording imposes a difficult requirement =
on clients.</FONT>
</P>

<P><FONT SIZE=3D2>Would anyone object to the deletion of that =
sentence?</FONT>
</P>

<P><FONT SIZE=3D2>If not, I think that the current state of these =
paragraphs is:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The keyCertSign =
bit is asserted when the subject public key is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for =
verifying a signature on public key certificates.&nbsp; If the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; keyCertSign bit =
is asserted, then the cA bit in the basic</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; constraints =
extension (see 4.2.1.10) MUST also be asserted.&nbsp; If</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; neither the =
cRLSign bit nor the keyCertSign bit are asserted, then</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cA bit in =
the basic constraints extension MUST NOT be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
asserted.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign bit =
is asserted when the subject public key is used</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for verifying a =
signature on a certificate revocation list (e.g.,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CRL or an =
ARL).&nbsp; This bit MUST be asserted in CA and Attribute</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authority (AA) =
certificates that are used to verify signatures on</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRLs.&nbsp; If =
the cRLSign bit is asserted in a CA certificate, then</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cA bit in =
the basic constraints extension (see 4.2.1.10) MUST</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; also be =
asserted.&nbsp; If the cRLSign bit is asserted in a AA</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate, =
then the cA bit in the basic constraints extension</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST NOT be =
asserted.&nbsp; If neither the cRLSign bit nor the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; keyCertSign bit =
are asserted, then the cA bit in the basic</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; constraints =
extension MUST NOT be asserted.</FONT>
</P>

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

<P><FONT SIZE=3D2>At 09:37 AM 4/26/2001 -0400, David A. Cooper =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;AA certificates MUST NOT be used to verify =
signatures on CRLs containing </FONT>
<BR><FONT SIZE=3D2>&gt;revocation information for public key =
certificates&quot;. The problem is that, </FONT>
<BR><FONT SIZE=3D2>&gt;even if a single entity is not allowed to issued =
both public key </FONT>
<BR><FONT SIZE=3D2>&gt;certificates and attribute certificates, there =
is the possibility that a </FONT>
<BR><FONT SIZE=3D2>&gt;single, indirect CRL could cover both types of =
certificates. If one is </FONT>
<BR><FONT SIZE=3D2>&gt;using a CRL to check the status of a public key =
certificate, then it is </FONT>
<BR><FONT SIZE=3D2>&gt;clear that the text below requires that the =
certificate containing the key </FONT>
<BR><FONT SIZE=3D2>&gt;needed to verify the CRL signature must have the =
cA bit set. But what </FONT>
<BR><FONT SIZE=3D2>&gt;about when one is using a CRL to check the =
status of an attribute </FONT>
<BR><FONT SIZE=3D2>&gt;certificate? The quote text seem to suggest =
that, if the cA bit is not set </FONT>
<BR><FONT SIZE=3D2>&gt;in the certificate, the relying party is =
required to verify that the CRL </FONT>
<BR><FONT SIZE=3D2>&gt;does not contain any revocation information for =
public key certificates. I </FONT>
<BR><FONT SIZE=3D2>&gt;can't imagine that there was any intention to =
impose such a requirement, </FONT>
<BR><FONT SIZE=3D2>&gt;but that is what the text seems to say.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CF5E.DD447320--


Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA23310; Fri, 27 Apr 2001 14:21:10 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100317b70f93139d7b@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 27 Apr 2001 14:21:06 -0700
To: Tim Polk <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: delta CRL security considerations
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I think this is OK, but similar words have to go into the deltaCRL 
section as well. Some implementors might not think through the really 
nasty implications of not issuing full CRLs when they should.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA20897 for <[e-mail]>; Fri, 27 Apr 2001 14:00:15 -0700 (PDT)
Received: from 157.54.9.100 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Apr 2001 13:56:39 -0700 (Pacific Daylight Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 27 Apr 2001 13:54:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta CRL security considerations
Date: Fri, 27 Apr 2001 13:54:34 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta CRL security considerations
Thread-Index: AcDPWtW1Gs8M8mg6Q7iM/jZ0go/t0AAAWGpg
From: "David Cross" <[e-mail]>
To: "Tim Polk" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Apr 2001 20:54:34.0883 (UTC) FILETIME=[43DC5D30:01C0CF5C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA20898

Sounds good

David B. Cross

 



-----Original Message-----
From: Tim Polk [mailto:[e-mail]] 
Sent: Friday, April 27, 2001 1:40 PM
To: [e-mail]
Subject: delta CRL security considerations


Folks,

It appears that the WG consensus is to remove the requirement for 
publication of full CRLs with every delta CRL from son-of-2459.  As a 
result, there is a possibility that minimally compliant PKI clients will

not have the same information provided to clients that process delta 
CRLs.  It seems appropriate to note this fact in the security 
considerations section.  We are proposing insertion of four new
sentences 
into the paragraph on revocation.  I have supplied the entire paragraph 
here.  The new text begins and ends with two asterisks.

-------- excerpt from security considerations ----

The availability and freshness of revocation information will affect the

degree of assurance that ought to be placed in a certificate. While 
certificates expire naturally, events may occur during its natural
lifetime 
which negate the binding between the subject and public key.  If
revocation 
information is untimely or unavailable, the assurance associated with
the 
binding is clearly reduced.  **Relying parties might not be able to
process 
every critical extension that can appear in a CRL.  CAs SHOULD take
extra 
care when making revocation information available only through CRLs that

contain critical extensions, particularly if support for those
extensions 
is not mandated by this profile.  For example, if revocation information
is 
supplied using a combination of delta CRLs and full CRLs, and the delta 
CRLs are issued more frequently than the full CRLs, then relying parties

that cannot handle the critical extensions related to delta CRL
processing 
will not be able to obtain the most recent revocation 
information.  Alternatively, if a full CRL is issued whenever a delta
CRL 
is issued, then timely revocation information will be available to all 
relying parties.**  Similarly, implementations of the Path Validation 
mechanism described in section 6 that omit revocation checking provide
less 
assurance than those that support it.

----------------end of excerpt------------

Your comments would be appreciated.

Thanks,

Tim Polk


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA19719 for <[e-mail]>; Fri, 27 Apr 2001 13:53:48 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3RKrdU23524; Fri, 27 Apr 2001 13:53:39 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Tim Polk" <[e-mail]>, <[e-mail]>
Subject: RE: delta CRL security considerations
Date: Fri, 27 Apr 2001 13:53:24 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Tim,

A proposed amendment.

Mike

> The availability and freshness of revocation information will
> affect the degree of assurance that ought to be placed in a
> certificate. While  certificates expire naturally, events may
> occur during its natural lifetime which negate the binding
> between the subject and public key.  If revocation information
> is untimely or unavailable, the assurance associated with the 
> binding is clearly reduced.
> To the extent these principles apply to the certificate and
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> CRL profiles which are the subject of this document,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> **Relying parties might not be able 
> to process every critical extension that can appear in a CRL.
> . . . 





Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA18661 for <[e-mail]>; Fri, 27 Apr 2001 13:41:43 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id QAA16109 for <[e-mail]>; Fri, 27 Apr 2001 16:41:44 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 27 Apr 2001 16:39:44 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: delta CRL security considerations
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,

It appears that the WG consensus is to remove the requirement for 
publication of full CRLs with every delta CRL from son-of-2459.  As a 
result, there is a possibility that minimally compliant PKI clients will 
not have the same information provided to clients that process delta 
CRLs.  It seems appropriate to note this fact in the security 
considerations section.  We are proposing insertion of four new sentences 
into the paragraph on revocation.  I have supplied the entire paragraph 
here.  The new text begins and ends with two asterisks.

-------- excerpt from security considerations ----

The availability and freshness of revocation information will affect the 
degree of assurance that ought to be placed in a certificate. While 
certificates expire naturally, events may occur during its natural lifetime 
which negate the binding between the subject and public key.  If revocation 
information is untimely or unavailable, the assurance associated with the 
binding is clearly reduced.  **Relying parties might not be able to process 
every critical extension that can appear in a CRL.  CAs SHOULD take extra 
care when making revocation information available only through CRLs that 
contain critical extensions, particularly if support for those extensions 
is not mandated by this profile.  For example, if revocation information is 
supplied using a combination of delta CRLs and full CRLs, and the delta 
CRLs are issued more frequently than the full CRLs, then relying parties 
that cannot handle the critical extensions related to delta CRL processing 
will not be able to obtain the most recent revocation 
information.  Alternatively, if a full CRL is issued whenever a delta CRL 
is issued, then timely revocation information will be available to all 
relying parties.**  Similarly, implementations of the Path Validation 
mechanism described in section 6 that omit revocation checking provide less 
assurance than those that support it.

----------------end of excerpt------------

Your comments would be appreciated.

Thanks,

Tim Polk


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA16517 for <[e-mail]>; Fri, 27 Apr 2001 13:11:59 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Apr 2001 20:11:56 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA19066 for <[e-mail]>; Fri, 27 Apr 2001 16:12:01 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JST3W9RP>; Fri, 27 Apr 2001 16:12:01 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.39]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JST3W9RN; Fri, 27 Apr 2001 16:11:57 -0400
From: "Housley, Russ" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 27 Apr 2001 16:05:04 -0400
Subject: RE: keyCertSign and cRLSign Key Usage Bits
In-Reply-To: <[e-mail]>
References: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

David:

My intent was to impose a requirement on the CAs and AAs.  I can see that 
the proposed wording imposes a difficult requirement on clients.

Would anyone object to the deletion of that sentence?

If not, I think that the current state of these paragraphs is:

       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on public key certificates.  If the
       keyCertSign bit is asserted, then the cA bit in the basic
       constraints extension (see 4.2.1.10) MUST also be asserted.  If
       neither the cRLSign bit nor the keyCertSign bit are asserted, then
       the cA bit in the basic constraints extension MUST NOT be
       asserted.

       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on a certificate revocation list (e.g.,
       a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
       Authority (AA) certificates that are used to verify signatures on
       CRLs.  If the cRLSign bit is asserted in a CA certificate, then
       the cA bit in the basic constraints extension (see 4.2.1.10) MUST
       also be asserted.  If the cRLSign bit is asserted in a AA
       certificate, then the cA bit in the basic constraints extension
       MUST NOT be asserted.  If neither the cRLSign bit nor the
       keyCertSign bit are asserted, then the cA bit in the basic
       constraints extension MUST NOT be asserted.

Russ

At 09:37 AM 4/26/2001 -0400, David A. Cooper wrote:
>AA certificates MUST NOT be used to verify signatures on CRLs containing 
>revocation information for public key certificates". The problem is that, 
>even if a single entity is not allowed to issued both public key 
>certificates and attribute certificates, there is the possibility that a 
>single, indirect CRL could cover both types of certificates. If one is 
>using a CRL to check the status of a public key certificate, then it is 
>clear that the text below requires that the certificate containing the key 
>needed to verify the CRL signature must have the cA bit set. But what 
>about when one is using a CRL to check the status of an attribute 
>certificate? The quote text seem to suggest that, if the cA bit is not set 
>in the certificate, the relying party is required to verify that the CRL 
>does not contain any revocation information for public key certificates. I 
>can't imagine that there was any intention to impose such a requirement, 
>but that is what the text seems to say.


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02149 for <[e-mail]>; Fri, 27 Apr 2001 08:42:52 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JRDR7L7Y; Fri, 27 Apr 2001 08:37:51 -0700
From: "Carlin Covey" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: delta-CRLs and NR
Date: Fri, 27 Apr 2001 08:43:26 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>

Russ,

I'm perfectly comfortable with your wording (and it seems better than mine).

- Carlin

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Thursday, April 26, 2001 11:43 AM
To: Carlin Covey
Cc: [e-mail]
Subject: RE: delta-CRLs and NR


Carlin:

I would prefer to leave the first sentence alone.  I think that it is
explanation of delta CRLs.  However, I like your point, and suggest the
addition of the following paragraph:

    When a conforming CA issues a delta CRL, the delta CRL MUST include a
    critical delta CRL indicator extension.

Russ


At 03:41 PM 4/24/2001 -0700, Carlin Covey wrote:
>David,
>
>Thank you for pointing out the "..less than or equal.."
>phrase.  I had missed the significance.
>
>My preference is that delta-CRL's be identified only by
>the deltaCRLIndicator extension, rather than the
>cRLScope extension.
>
>I propose that the following "sufficient condition" in the
>PKIX profile
>
>"The delta CRL indicator is a critical CRL extension
>that identifies a CRL as being a delta CRL."
>
>be reworded as a "necessary condition" along the lines of
>
>"A delta CRL MUST be identified via the delta CRL indicator
>extension, which MUST be marked as a critical CRL extension."
>
>
>Regards,
>
>Carlin
>
>____________________________
>
>-  Carlin Covey
>    Cylink Corporation
>
>
>-----Original Message-----
>From: David A. Cooper [mailto:[e-mail]]
>Sent: Tuesday, April 24, 2001 2:06 PM
>To: [e-mail]
>Subject: RE: delta-CRLs and NR
>
>
>Carlin,
>
>The quote that you included about the cRLScope extension is correct, but
the
>end result is (nearly) the same whether delta-CRLs are identified using the
>cRLScope extension or the deltaCRLIndicator extension. In addition to the
>text that you quoted, X.509 (Ed. 4 v7 is the latest) section 8.5.2.5 states
>the following about the cRLScope extension:
>
>          the cRLNumber referenced in the BaseRevocationInfo field of a
dCRL
>shall be less than or equal
>          to the cRLNumber of the most recently issued CRL that is complete
>for the applicable scope.
>
>So, while the base CRL referenced by the delta-CRL may not have been issued
>as a full CRL, there will be at least one CRL, issued as a full CRL,
against
>which the delta-CRL may be applied to obtain complete certificate status
>information. The full CRL may have been issued after the referenced base
>CRL, but one can still apply the delta-CRL to that full CRL.
>
>As to your second question, the PKIX certificate and CRL profile does not
>include the cRLScope extension. So, while X.509 provides two ways to
>identify a CRL as being a delta-CRL, PKIX only provides the
>deltaCRLIndicator. Would a CRL issuer that used the cRLScope extension be
>non-PKIX-compliant? I'll leave that to others to decide.
>
>Dave
>
>At 01:35 PM 4/24/01 -0700, Carlin Covey wrote:
> >David,
> >
> >You are correct for delta-CRLs defined with the deltaCRLIndicator, but
> >it is also possible to define delta-CRLs using the CRL scope extension.
> >
> >X.509 Ed. 4 v6 says the following in section 8.5.2.5 'CRL scope
extension':
> >
> >"In the crlScope case, the information in the baseRevocationInfo
> >component, indicates the point in time from which the CRL containing
> >this extension provides updates. Although this is done by referencing
> >a CRL, the referenced CRL may or may not be one that is complete for
> >the applicable scope, whereas the deltaCRLIdentifier extension references
> >an issued CRL that is complete for the applicable scope."
> >
> >In an earlier email I made the following observation and asked a
question:
> >
> >"I don't see anywhere in draft-ietf-pkix-new-part1-05 where it says
> >that a delta CRL must be identified by a deltaCRLIndicator extension.
> >It does say that "The delta CRL indicator is a critical CRL extension
> >that identifies a CRL as being a delta CRL."  This appears to be a
> >sufficient
> >condition, but not a necessary condition, for the CRL to be interpreted
as
>a
> >delta CRL.  So a PKIX-profile-compliant CRL-issuer could use the crlScope
> >extension rather than the deltaCRLIndicator extension to identify delta
> >CRLs?
> >
> >       -  Russ, is that right?"
> >
> >Regards,
> >
> >Carlin
> >
> >____________________________
> >
> >-  Carlin Covey
> >    Cylink Corporation
> >
> >
> >-----Original Message-----
> >From: David A. Cooper [mailto:[e-mail]]
> >Sent: Tuesday, April 24, 2001 12:44 PM
> >To: [e-mail]
> >Subject: RE: delta-CRLs and NR
> >
> >
> >This is a misunderstanding of the way that delta-CRLs work. A delta-CRL
> >specifies a base CRL and  provides a list of all certificates whose
status
> >has changed since the base CRL was issued. When using the
>deltaCRLIndicator,
> >the referenced base CRL must have been issued as a full CRL (i.e., not a
> >delta). Thus, one can always obtain complete revocation information by
> >applying a single delta-CRL to the base CRL that it references.
> >
> >If delta-CRLs are issued more frequently than full CRLs, this will just
>mean
> >that multiple delta-CRLs will reference the same full CRL as their base.
> >
> >With the current PKIX standard, one can always get complete revocation
> >information by just obtaining a full CRL. If the rules were relaxed, one
> >would be required to obtain one full CRL and one delta-CRL.
> >
> >Dave
> >
> >At 12:25 PM 4/24/01 -0700, Michael Myers wrote:
> > >I understand.  But the trajectory of the dialog seemed to be suggesting
> > >elimination the full CRL context, hence in that forward scenario one
>would
> > >have no choice but to face the accumulation task.  Also, the proposal
to
> > >enable a different period of production between a full CRL and its
> > >associated deltas (thus enabling periods of delta-only activity between
> >full
> > >CRL production) does suggest that there might exists cases where more
>than
> > >one delta is necessary to span the gap between fulls.
> >



Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA21517 for <[e-mail]>; Fri, 27 Apr 2001 06:31:39 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Apr 2001 13:31:35 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA16248 for <[e-mail]>; Fri, 27 Apr 2001 09:31:35 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JST3WV83>; Fri, 27 Apr 2001 09:31:34 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.117]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JST3WV8L; Fri, 27 Apr 2001 09:31:30 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 27 Apr 2001 08:58:35 -0400
Subject: RE: Dedicated CRL signing keys
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
Yes.&nbsp; So, I guess we agree.<br>
<br>
At 04:47 PM 4/26/2001 -0400, Santosh Chokhani wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">Russ:
Will a CA that signs the certificates and CRLs using different keys, but
same Issuer DN be considered compliant?&nbsp; If yes, then we
agree.</font><br>
&nbsp;<br>
<font face="Times New Roman, Times" size=2>-----Original
Message-----<br>
<b>From:</b> Housley, Russ
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]<br>
<b>Sent:</b> Thursday, April 26, 2001 4:36 PM<br>
<b>To:</b> Santosh Chokhani<br>
<b>Cc:</b> [e-mail]<br>
<b>Subject:</b> RE: Dedicated CRL signing keys<br>
<br>
</font>Santosh:<br>
<br>
<blockquote type=cite class=cite cite><font size=2>Optional is
sufficient.&nbsp; It should NOT be mandatory to have separate signing
keys for certificates and CRLs.</font> <br>
<font size=2>Thanks.&nbsp; I think we agree.</font> </blockquote><br>
If CAs issue CRLs, then the CA can sign certificates and CRLs with the
same key, or the CA can use separate keys.<br>
<br>
Certificate-using applications must be able to handle certificates and
CRLs signed by the same key.&nbsp; Certificate-using applications may
handle CRLs signed by a different key than the certificates.<br>
<br>
If you agree with this position, then we agree.<br>
<br>
Russ</blockquote></html>


Received: from gatekeeper.dep.no (gatekeeper.dep.no [132.150.8.1]) by above.proper.com (8.9.3/8.9.3) with SMTP id BAA00827 for <[e-mail]>; Fri, 27 Apr 2001 01:50:55 -0700 (PDT)
Received: by gatekeeper.dep.no (SMI-8.6/SMI-SVR4) id KAA12015; Fri, 27 Apr 2001 10:50:23 +0200
Received: from urias-gw.fos.dep.no(132.150.244.2) by gatekeeper via smap (V2.0) id xma011668; Fri, 27 Apr 01 10:48:52 +0200
Received: by B with Internet Mail Service (5.5.2653.19) id <DDQV3KF2>; Fri, 27 Apr 2001 10:53:18 +0200
Message-ID: <DFA3FCFD4822D4118DD400009290939904C6C9@B>
From: =?iso-8859-1?Q?Helge_L=E6greid?= <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Fri, 27 Apr 2001 10:52:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0CEF7.75AF98A0"

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

------_=_NextPart_000_01C0CEF7.75AF98A0
Content-Type: text/plain;
	charset="iso-8859-1"

subscribe


------_=_NextPart_000_01C0CEF7.75AF98A0
Content-Type: application/octet-stream;
	name="=?iso-8859-1?Q?Helge_L=E6greid=2Evcf?="
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="=?iso-8859-1?Q?Helge_L=E6greid=2Evcf?="

BEGIN:VCARD
VERSION:2.1
N:L=E6greid;Helge
FN:Helge L=E6greid
EMAIL;PREF;INTERNET:[e-mail]
REV:20010405T081650Z
END:VCARD

------_=_NextPart_000_01C0CEF7.75AF98A0--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA13713 for <[e-mail]>; Thu, 26 Apr 2001 13:57:07 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JV6F570L>; Thu, 26 Apr 2001 16:56:39 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys
Date: Thu, 26 Apr 2001 16:47:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE92.24FD48E0"

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_01C0CE92.24FD48E0
Content-Type: text/plain;
	charset="iso-8859-1"

Russ: Will a CA that signs the certificates and CRLs using different keys,
but same Issuer DN be considered compliant?  If yes, then we agree.
 
-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Thursday, April 26, 2001 4:36 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys


Santosh:



Optional is sufficient.  It should NOT be mandatory to have separate signing
keys for certificates and CRLs. 
Thanks.  I think we agree. 


If CAs issue CRLs, then the CA can sign certificates and CRLs with the same
key, or the CA can use separate keys.

Certificate-using applications must be able to handle certificates and CRLs
signed by the same key.  Certificate-using applications may handle CRLs
signed by a different key than the certificates.

If you agree with this position, then we agree.

Russ


------_=_NextPart_001_01C0CE92.24FD48E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=759415520-26042001>Russ: 
Will a CA that signs the certificates and CRLs using different keys, but same 
Issuer DN be considered compliant?&nbsp; If yes, then we 
agree.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=759415520-26042001></SPAN></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Housley, Russ 
[mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 26, 2001 4:36 
PM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B> 
[e-mail]<BR><B>Subject:</B> RE: Dedicated CRL signing 
keys<BR><BR></FONT></DIV>Santosh:<BR><BR>
<BLOCKQUOTE class=cite cite type="cite"><FONT size=2>Optional is 
  sufficient.&nbsp; It should NOT be mandatory to have separate signing keys for 
  certificates and CRLs.</FONT> <BR><FONT size=2>Thanks.&nbsp; I think we 
  agree.</FONT> </BLOCKQUOTE><BR>If CAs issue CRLs, then the CA can sign 
certificates and CRLs with the same key, or the CA can use separate 
keys.<BR><BR>Certificate-using applications must be able to handle certificates 
and CRLs signed by the same key.&nbsp; Certificate-using applications may handle 
CRLs signed by a different key than the certificates.<BR><BR>If you agree with 
this position, then we agree.<BR><BR>Russ<BR></BODY></HTML>

------_=_NextPart_001_01C0CE92.24FD48E0--


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA12640 for <[e-mail]>; Thu, 26 Apr 2001 13:47:34 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Apr 2001 20:47:32 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA10798 for <[e-mail]>; Thu, 26 Apr 2001 16:47:36 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JST3W3DH>; Thu, 26 Apr 2001 16:47:35 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JST3W3DB; Thu, 26 Apr 2001 16:47:30 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 26 Apr 2001 16:35:49 -0400
Subject: RE: Dedicated CRL signing keys
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
Santosh:<br>
<br>
<blockquote type=cite class=cite cite><font size=2>Optional is
sufficient.&nbsp; It should NOT be mandatory to have separate signing
keys for certificates and CRLs.</font> <br>
<font size=2>Thanks.&nbsp; I think we agree.</font> </blockquote><br>
If CAs issue CRLs, then the CA can sign certificates and CRLs with the
same key, or the CA can use separate keys.<br>
<br>
Certificate-using applications must be able to handle certificates and
CRLs signed by the same key.&nbsp; Certificate-using applications may
handle CRLs signed by a different key than the certificates.<br>
<br>
If you agree with this position, then we agree.<br>
<br>
Russ<br>
</html>


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA12641 for <[e-mail]>; Thu, 26 Apr 2001 13:47:34 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Apr 2001 20:47:32 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA10799 for <[e-mail]>; Thu, 26 Apr 2001 16:47:36 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JST3W3DG>; Thu, 26 Apr 2001 16:47:35 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JST3W3DD; Thu, 26 Apr 2001 16:47:31 -0400
From: "Housley, Russ" <[e-mail]>
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 26 Apr 2001 16:43:44 -0400
Subject: Re: keyCertSign and cRLSign Key Usage Bits
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Dave:

This is not a change.  Rather, it complements the AC profile.  The AC 
profile says:

    The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage
    extension in the PKC MUST NOT explicitly indicate that the AC
    issuer's public key cannot be used to validate a digital signature.
    In order to avoid confusion regarding serial numbers and
    revocations, an AC issuer MUST NOT also be a PKC Issuer.  That is,
    an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST
    NOT have a basicConstraints extension with the cA BOOLEAN set to
    TRUE.

Since one issuer cannot issue both ACs and PKCs, then I would expect them 
to employ separate CRLs.

Are you suggesting that ACs and PKCs might be mixed together on one CRL 
using the indirect CRL mechanism?

Russ

At 08:47 AM 4/25/2001 -0400, David P. Kemp wrote:
>Russ,
>
>Thanks.
>
>However, I am more concerned about the second paragraph than the
>first.  Is Last Call the proper time to be proposing, discussing,
>and ratifying such a novel and significant change to the path validation
>algorithm?
>
>        Such AA certificates MUST NOT be used to verify signatures
>        on CRLs containing revocation information for public key
>        certificates;  ...
>
>Dave


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA10380 for <[e-mail]>; Thu, 26 Apr 2001 13:19:31 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Apr 2001 20:19:29 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA08597 for <[e-mail]>; Thu, 26 Apr 2001 16:19:33 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JST3WNT9>; Thu, 26 Apr 2001 16:19:32 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JST3WNT7; Thu, 26 Apr 2001 16:19:30 -0400
From: "Housley, Russ" <[e-mail]>
To: Carlin Covey <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 26 Apr 2001 14:42:38 -0400
Subject: RE: delta-CRLs and NR
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Carlin:

I would prefer to leave the first sentence alone.  I think that it is 
explanation of delta CRLs.  However, I like your point, and suggest the 
addition of the following paragraph:

    When a conforming CA issues a delta CRL, the delta CRL MUST include a
    critical delta CRL indicator extension.

Russ


At 03:41 PM 4/24/2001 -0700, Carlin Covey wrote:
>David,
>
>Thank you for pointing out the "..less than or equal.."
>phrase.  I had missed the significance.
>
>My preference is that delta-CRL's be identified only by
>the deltaCRLIndicator extension, rather than the
>cRLScope extension.
>
>I propose that the following "sufficient condition" in the
>PKIX profile
>
>"The delta CRL indicator is a critical CRL extension
>that identifies a CRL as being a delta CRL."
>
>be reworded as a "necessary condition" along the lines of
>
>"A delta CRL MUST be identified via the delta CRL indicator
>extension, which MUST be marked as a critical CRL extension."
>
>
>Regards,
>
>Carlin
>
>____________________________
>
>-  Carlin Covey
>    Cylink Corporation
>
>
>-----Original Message-----
>From: David A. Cooper [mailto:[e-mail]]
>Sent: Tuesday, April 24, 2001 2:06 PM
>To: [e-mail]
>Subject: RE: delta-CRLs and NR
>
>
>Carlin,
>
>The quote that you included about the cRLScope extension is correct, but the
>end result is (nearly) the same whether delta-CRLs are identified using the
>cRLScope extension or the deltaCRLIndicator extension. In addition to the
>text that you quoted, X.509 (Ed. 4 v7 is the latest) section 8.5.2.5 states
>the following about the cRLScope extension:
>
>          the cRLNumber referenced in the BaseRevocationInfo field of a dCRL
>shall be less than or equal
>          to the cRLNumber of the most recently issued CRL that is complete
>for the applicable scope.
>
>So, while the base CRL referenced by the delta-CRL may not have been issued
>as a full CRL, there will be at least one CRL, issued as a full CRL, against
>which the delta-CRL may be applied to obtain complete certificate status
>information. The full CRL may have been issued after the referenced base
>CRL, but one can still apply the delta-CRL to that full CRL.
>
>As to your second question, the PKIX certificate and CRL profile does not
>include the cRLScope extension. So, while X.509 provides two ways to
>identify a CRL as being a delta-CRL, PKIX only provides the
>deltaCRLIndicator. Would a CRL issuer that used the cRLScope extension be
>non-PKIX-compliant? I'll leave that to others to decide.
>
>Dave
>
>At 01:35 PM 4/24/01 -0700, Carlin Covey wrote:
> >David,
> >
> >You are correct for delta-CRLs defined with the deltaCRLIndicator, but
> >it is also possible to define delta-CRLs using the CRL scope extension.
> >
> >X.509 Ed. 4 v6 says the following in section 8.5.2.5 'CRL scope extension':
> >
> >"In the crlScope case, the information in the baseRevocationInfo
> >component, indicates the point in time from which the CRL containing
> >this extension provides updates. Although this is done by referencing
> >a CRL, the referenced CRL may or may not be one that is complete for
> >the applicable scope, whereas the deltaCRLIdentifier extension references
> >an issued CRL that is complete for the applicable scope."
> >
> >In an earlier email I made the following observation and asked a question:
> >
> >"I don't see anywhere in draft-ietf-pkix-new-part1-05 where it says
> >that a delta CRL must be identified by a deltaCRLIndicator extension.
> >It does say that "The delta CRL indicator is a critical CRL extension
> >that identifies a CRL as being a delta CRL."  This appears to be a
> >sufficient
> >condition, but not a necessary condition, for the CRL to be interpreted as
>a
> >delta CRL.  So a PKIX-profile-compliant CRL-issuer could use the crlScope
> >extension rather than the deltaCRLIndicator extension to identify delta
> >CRLs?
> >
> >       -  Russ, is that right?"
> >
> >Regards,
> >
> >Carlin
> >
> >____________________________
> >
> >-  Carlin Covey
> >    Cylink Corporation
> >
> >
> >-----Original Message-----
> >From: David A. Cooper [mailto:[e-mail]]
> >Sent: Tuesday, April 24, 2001 12:44 PM
> >To: [e-mail]
> >Subject: RE: delta-CRLs and NR
> >
> >
> >This is a misunderstanding of the way that delta-CRLs work. A delta-CRL
> >specifies a base CRL and  provides a list of all certificates whose status
> >has changed since the base CRL was issued. When using the
>deltaCRLIndicator,
> >the referenced base CRL must have been issued as a full CRL (i.e., not a
> >delta). Thus, one can always obtain complete revocation information by
> >applying a single delta-CRL to the base CRL that it references.
> >
> >If delta-CRLs are issued more frequently than full CRLs, this will just
>mean
> >that multiple delta-CRLs will reference the same full CRL as their base.
> >
> >With the current PKIX standard, one can always get complete revocation
> >information by just obtaining a full CRL. If the rules were relaxed, one
> >would be required to obtain one full CRL and one delta-CRL.
> >
> >Dave
> >
> >At 12:25 PM 4/24/01 -0700, Michael Myers wrote:
> > >I understand.  But the trajectory of the dialog seemed to be suggesting
> > >elimination the full CRL context, hence in that forward scenario one
>would
> > >have no choice but to face the accumulation task.  Also, the proposal to
> > >enable a different period of production between a full CRL and its
> > >associated deltas (thus enabling periods of delta-only activity between
> >full
> > >CRL production) does suggest that there might exists cases where more
>than
> > >one delta is necessary to span the gap between fulls.
> >


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA10379 for <[e-mail]>; Thu, 26 Apr 2001 13:19:31 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Apr 2001 20:19:29 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA08593 for <[e-mail]>; Thu, 26 Apr 2001 16:19:32 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JST3WNT8>; Thu, 26 Apr 2001 16:19:32 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JST3WNTV; Thu, 26 Apr 2001 16:19:25 -0400
From: "Housley, Russ" <[e-mail]>
To: Carlin Covey <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 25 Apr 2001 15:50:54 -0400
Subject: RE: delta-CRLs and NR
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Carlin:

As David Cooper has already pointed out, only the deltaCRLIndicator is part 
of the profile.  The profile allows the use of other extensions.  However, 
other extensions SHOULD not be critical (since they reduce interoperability).

Russ

At 01:35 PM 4/24/2001 -0700, Carlin Covey wrote:
>David,
>
>You are correct for delta-CRLs defined with the deltaCRLIndicator, but
>it is also possible to define delta-CRLs using the CRL scope extension.
>
>X.509 Ed. 4 v6 says the following in section 8.5.2.5 'CRL scope extension':
>
>"In the crlScope case, the information in the baseRevocationInfo
>component, indicates the point in time from which the CRL containing
>this extension provides updates. Although this is done by referencing
>a CRL, the referenced CRL may or may not be one that is complete for
>the applicable scope, whereas the deltaCRLIdentifier extension references
>an issued CRL that is complete for the applicable scope."
>
>In an earlier email I made the following observation and asked a question:
>
>"I don't see anywhere in draft-ietf-pkix-new-part1-05 where it says
>that a delta CRL must be identified by a deltaCRLIndicator extension.
>It does say that "The delta CRL indicator is a critical CRL extension
>that identifies a CRL as being a delta CRL."  This appears to be a
>sufficient
>condition, but not a necessary condition, for the CRL to be interpreted as a
>delta CRL.  So a PKIX-profile-compliant CRL-issuer could use the crlScope
>extension rather than the deltaCRLIndicator extension to identify delta
>CRLs?
>
>       -  Russ, is that right?"
>
>Regards,
>
>Carlin
>
>____________________________
>
>-  Carlin Covey
>    Cylink Corporation
>
>
>-----Original Message-----
>From: David A. Cooper [mailto:[e-mail]]
>Sent: Tuesday, April 24, 2001 12:44 PM
>To: [e-mail]
>Subject: RE: delta-CRLs and NR
>
>
>This is a misunderstanding of the way that delta-CRLs work. A delta-CRL
>specifies a base CRL and  provides a list of all certificates whose status
>has changed since the base CRL was issued. When using the deltaCRLIndicator,
>the referenced base CRL must have been issued as a full CRL (i.e., not a
>delta). Thus, one can always obtain complete revocation information by
>applying a single delta-CRL to the base CRL that it references.
>
>If delta-CRLs are issued more frequently than full CRLs, this will just mean
>that multiple delta-CRLs will reference the same full CRL as their base.
>
>With the current PKIX standard, one can always get complete revocation
>information by just obtaining a full CRL. If the rules were relaxed, one
>would be required to obtain one full CRL and one delta-CRL.
>
>Dave
>
>At 12:25 PM 4/24/01 -0700, Michael Myers wrote:
> >I understand.  But the trajectory of the dialog seemed to be suggesting
> >elimination the full CRL context, hence in that forward scenario one would
> >have no choice but to face the accumulation task.  Also, the proposal to
> >enable a different period of production between a full CRL and its
> >associated deltas (thus enabling periods of delta-only activity between
>full
> >CRL production) does suggest that there might exists cases where more than
> >one delta is necessary to span the gap between fulls.


Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA04997 for <[e-mail]>; Thu, 26 Apr 2001 11:09:44 -0700 (PDT)
Received: from [38.29.65.91] ([38.29.65.91]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA02205; Thu, 26 Apr 2001 11:09:20 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05001900b70e0f5272bd@[38.29.132.105]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 26 Apr 2001 11:00:36 -0700
To: Sharon Boeyen <[e-mail]>, "'David P. Kemp'" <[e-mail]>, [e-mail]
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Cc: Sharon boeyen <[e-mail]>
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>RE: keyCertSign and cRLSign Key Usage
Bits</title></head><body>
<div>hi dave</div>
<div><br></div>
<div>this will be unusually short for me - i got 3 sets of guys
working on my roof</div>
<div><br></div>
<div>as i told sharon earlier today. the group created the ca and crl
keyusage flags early on in the work (i may be able to find the initial
contributions from nick pope). crl distribution point was just being
discussed, we wanted to shorten crls. the first proposal was to have
crls responsible for ranges of certificates (using the serial number).
later we decided to adopt the proposal to have the certificate point
to other crl locations but the first texts confined that to points
under the CA. later we expanded to the ability to point anywhere, e.g.
crl issuer.</div>
<div><br></div>
<div>i have proposed some text to sharon to describe how a non-ca
entity would be identified as a crl issuer for a set of
certificates.</div>
<div><br></div>
<div>i believe your proposed interpretation of using crlsign as an
indication of delegation is too divergent from that for ca sign. if CA
x issues a certificate to entity y with the CAsign flag on, x is
merely granting the right for CA y to issue certificates in CA y's
name, not CA x's. i think it is reasonable to keep the same
interpretation for cRLsign.</div>
<div><br></div>
<div>got to go talk to the electrician!</div>
<div><br></div>
<div>&nbsp;&nbsp; hoyt</div>
<div><br></div>
<div>At 1:27 PM -0400 4/26/01, Sharon Boeyen wrote:</div>
<blockquote type="cite" cite><font size="-1">Hi Dave, my understanding
of the crlsign bit is not that it is for delegating</font><br>
<font size="-1">that indirect authority, but that it is similar to the
keyCertSign bit in that</font><br>
<font size="-1">it indicates that the certified key can be used to
verify signatures on CRLs</font><br>
<font size="-1">issued by the subject of the containing cert. It has
nothing to do with delegating</font><br>
<font size="-1">authority to issue CRLs on behalf of the issuing CA
for the set of certificates issued</font><br>
<font size="-1">by that issuer.</font><br>
</blockquote>
<blockquote type="cite" cite><font size="-1">This bit would be
typically be set in any cert issued by one CA to another CA where
relying parties would beexpecting to verify signatures on both
certificates and CRLs issued by the subject authority and in
conjunction with a certification path that contains the cert with this
extension.</font><br>
</blockquote>
<blockquote type="cite" cite><font size="-1">Hoyt, can you comment
from the perspective of the historian??&nbsp;</font><br>
</blockquote>
<blockquote type="cite" cite><font size="-1">Sharon</font><br>
</blockquote>
<blockquote type="cite" cite><font size="-1">&gt; -----Original
Message-----</font><br>
<font size="-1">&gt; From: David P. Kemp [</font><a
href="mailto:[e-mail]"><font
size="-1">mailto:[e-mail]</font></a><font
size="-1">]</font><br>
<font size="-1">&gt; Sent: Thursday, April 26, 2001 12:35
PM</font><br>
<font size="-1">&gt; To: [e-mail]</font><br>
<font size="-1">&gt; Cc: Hoyt Kesterson</font><br>
<font size="-1">&gt; Subject: Re: keyCertSign and cRLSign Key Usage
Bits</font><br>
<font size="-1">&gt;</font><br>
<font size="-1">&gt;</font><br>
<font size="-1">&gt; The second point is one where some clarifying
language in X.509 and</font><br>
<font size="-1">&gt; PKIX might be useful.</font><br>
<font size="-1">&gt;</font><br>
<font size="-1">&gt; I've always assumed that the cRLSign bit is set
exclusively for the</font><br>
<font size="-1">&gt; purpose of delegating to an ICRLA or other agent
(including</font><br>
<font size="-1">&gt; the CA's own</font><br>
<font size="-1">&gt; online CRL-signing key which is different from
its offline</font><br>
<font size="-1">&gt; cert-signing</font><br>
<font size="-1">&gt; key).&nbsp; In other words, for these
certs:</font><br>
<font size="-1">&gt;</font><br>
<font size="-1">&gt;&nbsp;&nbsp;&nbsp; CA-1</font><br>
<font size="-1">&gt;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
CA-2-cert</font><br>
<font size="-1">&gt;&nbsp;&nbsp;&nbsp; CA-2</font><br>
<font size="-1">&gt;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
EE-cert</font><br>
<font size="-1">&gt;&nbsp;&nbsp;&nbsp; EE</font><br>
<font size="-1">&gt;</font><br>
<font size="-1">&gt; where CA-2-cert contains a critical keyUsage
extension with</font><br>
<font size="-1">&gt; keyCertSign</font><br>
<font size="-1">&gt; asserted and cRLSign *un-asserted*, the private
key which</font><br>
<font size="-1">&gt; signs EE-cert</font><br>
<font size="-1">&gt; also signs the CRL issued by CA-2 which covers
EE.&nbsp; A CA can always</font><br>
<font size="-1">&gt; revoke its own certificates without needing
permission from</font><br>
<font size="-1">&gt; an upstream CA.</font><br>
<font size="-1">&gt;</font><br>
<font size="-1">&gt; If CA-2-cert had cRLSign asserted, then CA-2
could also sign</font><br>
<font size="-1">&gt; CRLs covering</font><br>
<font size="-1">&gt; certificates signed by the private key which
signed CA-2-cert (CA-1's</font><br>
<font size="-1">&gt; private key).</font><br>
<font size="-1">&gt;</font><br>
<font size="-1">&gt; Is this not the intent of X.509?</font><br>
<font size="-1">&gt;</font><br>
<font size="-1">&gt; Dave</font><br>
<font size="-1">&gt;</font><br>
<font size="-1">&gt;</font><br>
<font size="-1">&gt;</font><br>
<font size="-1">&gt; Sharon Boeyen wrote:</font><br>
<font size="-1">&gt; &gt;</font><br>
<font size="-1">&gt; &gt; I agree with your first point but not
completely with the</font><br>
<font size="-1">&gt; second point. The</font><br>
<font size="-1">&gt; &gt; cRLSign bit means &quot;for verifying a CA's
signature on CRLs&quot;.</font><br>
<font size="-1">&gt; In a hierarchy,</font><br>
<font size="-1">&gt; &gt; for example, one might set this bit, along
with the</font><br>
<font size="-1">&gt; keyCertSign bit in a cert</font><br>
<font size="-1">&gt; &gt; issued to a subordinate CA. The CRLs that
you would anticipate that</font><br>
<font size="-1">&gt; &gt; subordinate CA to issue are ones for the set
of</font><br>
<font size="-1">&gt; certificates that the</font><br>
<font size="-1">&gt; &gt; subordinate issues, not ones for the certs
issued by the CA</font><br>
<font size="-1">&gt; issuing that</font><br>
<font size="-1">&gt; &gt; subordinate's certificate. That is not the
same delegation</font><br>
<font size="-1">&gt; we've been</font><br>
<font size="-1">&gt; &gt; discussing, where a CA hands off
responsibility for issuing</font></blockquote>
<blockquote type="cite" cite><font size="-1">&gt; CRLs for its
own</font><br>
<font size="-1">&gt; &gt; set of certificates to another entity. That
needs to be</font><br>
<font size="-1">&gt; indicated differently</font><br>
<font size="-1">&gt; &gt; so that a relying party knows what entity is
authorized to</font><br>
<font size="-1">&gt; issue CRLs 'on</font><br>
<font size="-1">&gt; &gt; behalf of' another CA.</font><br>
<font size="-1">&gt; &gt;</font><br>
<font size="-1">&gt; &gt; Sharon</font><br>
<font size="-1">&gt; &gt;</font><br>
<font size="-1">&gt; &gt; &gt; -----Original Message-----</font><br>
<font size="-1">&gt; &gt; &gt; From: David P. Kemp [</font><a
href="mailto:[e-mail]"><font
size="-1">mailto:[e-mail]</font></a><font
size="-1">]</font><br>
<font size="-1">&gt; &gt; &gt; Sent: Thursday, April 26, 2001 11:31
AM</font><br>
<font size="-1">&gt; &gt; &gt; To: [e-mail]</font><br>
<font size="-1">&gt; &gt; &gt; Cc: Hoyt Kesterson</font><br>
<font size="-1">&gt; &gt; &gt; Subject: Re: keyCertSign and cRLSign
Key Usage Bits</font><br>
<font size="-1">&gt; &gt; &gt;</font><br>
<font size="-1">&gt; &gt; &gt;</font><br>
<font size="-1">&gt; &gt; &gt; Sharon,</font><br>
<font size="-1">&gt; &gt; &gt;</font><br>
<font size="-1">&gt; &gt; &gt; 1) A cert issued for purposes of
verifying the signature on a</font><br>
<font size="-1">&gt; &gt; &gt; CRL contains</font><br>
<font size="-1">&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; at least the cRLSign
bit. The digitalSignature bit (which</font><br>
<font size="-1">&gt; &gt; &gt; is used for</font><br>
<font size="-1">&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; purposes other than
b, f, or g), is not necessary.</font><br>
<font size="-1">&gt; &gt; &gt;</font><br>
<font size="-1">&gt; &gt; &gt; 2) If a CRL is issued by an entity
other than the CA that</font><br>
<font size="-1">&gt; issues the</font><br>
<font size="-1">&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; certificate, that
delegation is identified with</font><br>
<font size="-1">&gt; integrity by the</font><br>
<font size="-1">&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; fact that the CA
which issued the EE certificate has</font><br>
<font size="-1">&gt; also issued</font><br>
<font size="-1">&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; issued a certificate
containing the cRLSign bit to the CA's</font><br>
<font size="-1">&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; revocation agent.&nbsp;
This agent is by definition an &quot;authority&quot;,</font><br>
<font size="-1">&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; by virtue of being
the subject of the cRLSign certificate.</font><br>
<font size="-1">&gt; &gt; &gt;</font><br>
<font size="-1">&gt; &gt; &gt; Dave</font><br>
<font size="-1">&gt; &gt; &gt;</font><br>
<font size="-1">&gt; &gt; &gt;</font><br>
<font size="-1">&gt; &gt; &gt; Sharon Boeyen wrote:</font><br>
<font size="-1">&gt; &gt; &gt; &gt;</font><br>
<font size="-1">&gt; &gt; &gt; &gt; Taking a step back at what is
'technically important'. A</font><br>
<font size="-1">&gt; &gt; &gt; cert issued for</font><br>
<font size="-1">&gt; &gt; &gt; &gt; purposes of cert signature
verification contains at least</font><br>
<font size="-1">&gt; &gt; &gt; the ca bit set and</font><br>
<font size="-1">&gt; &gt; &gt; &gt; the keyUsage keyCertSign. A cert
issued for purposes of</font><br>
<font size="-1">&gt; &gt; &gt; verifying the</font><br>
<font size="-1">&gt; &gt; &gt; &gt; signature on a CRL contains at
least the digitalSignature</font><br>
<font size="-1">&gt; &gt; &gt; and cRLSign bits of</font><br>
<font size="-1">&gt; &gt; &gt; &gt; keyUsage. If a CRL is to be issued
by an entity other the</font><br>
<font size="-1">&gt; &gt; &gt; CA that issues the</font><br>
<font size="-1">&gt; &gt; &gt; &gt; certificate, then there needs to
be a way to identify that</font><br>
<font size="-1">&gt; &gt; &gt; delegation with</font><br>
<font size="-1">&gt; &gt; &gt; &gt; integrity. If the
crlDistributionPoints extension is in the</font><br>
<font size="-1">&gt; &gt; &gt; certificate, this</font><br>
<font size="-1">&gt; &gt; &gt; &gt; can be done by populating the
cRLIssuer field and that</font><br>
<font size="-1">&gt; &gt; &gt; value needs to</font><br>
<font size="-1">&gt; &gt; &gt; &gt; correspond with the issuer name of
the CRL being used</font><br>
<font size="-1">&gt; (and the other</font><br>
<font size="-1">&gt; &gt; &gt; &gt; requirements outlined so nicely
by</font><br>
<font size="-1">&gt; &gt; &gt; &gt; Santosh in Annex B of 509 also
need to be met of course).</font><br>
<font size="-1">&gt; &gt; &gt; Other mechanisms</font><br>
<font size="-1">&gt; &gt; &gt; &gt; could also be used. As for the
schema, there was no problem</font><br>
<font size="-1">&gt; &gt; &gt; with the PKI</font><br>
<font size="-1">&gt; &gt; &gt; &gt; schema components as long as the
crl issuers were also</font><br>
<font size="-1">&gt; &gt; &gt; CAs(except that the</font><br>
<font size="-1">&gt; &gt; &gt; &gt; requirement for the CA bit to be
set in all cases</font><br>
<font size="-1">&gt; should probably be</font><br>
<font size="-1">&gt; &gt; &gt; &gt; removed).</font><br>
<font size="-1">&gt; &gt; &gt;</font><br>
<font size="-1">&gt;</font></blockquote>
<div><br></div>
</body>
</html>


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA02812 for <[e-mail]>; Thu, 26 Apr 2001 10:33:55 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <J432X6YY>; Thu, 26 Apr 2001 13:33:27 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Cc: Hoyt Kesterson <[e-mail]>
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Date: Thu, 26 Apr 2001 13:27:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE76.2FE7D840"

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_01C0CE76.2FE7D840
Content-Type: text/plain

Hi Dave, my understanding of the crlsign bit is not that it is for
delegating 
that indirect authority, but that it is similar to the keyCertSign bit in
that
it indicates that the certified key can be used to verify signatures on CRLs

issued by the subject of the containing cert. It has nothing to do with
delegating
authority to issue CRLs on behalf of the issuing CA for the set of
certificates issued 
by that issuer. 

This bit would be typically be set in any cert issued by one CA to another
CA where relying parties would beexpecting to verify signatures on both
certificates and CRLs issued by the subject authority and in conjunction
with a certification path that contains the cert with this extension. 

Hoyt, can you comment from the perspective of the historian??  

Sharon 

> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Thursday, April 26, 2001 12:35 PM
> To: [e-mail]
> Cc: Hoyt Kesterson
> Subject: Re: keyCertSign and cRLSign Key Usage Bits
> 
> 
> The second point is one where some clarifying language in X.509 and
> PKIX might be useful.
> 
> I've always assumed that the cRLSign bit is set exclusively for the
> purpose of delegating to an ICRLA or other agent (including 
> the CA's own
> online CRL-signing key which is different from its offline 
> cert-signing
> key).  In other words, for these certs:
> 
>    CA-1
>     |  CA-2-cert
>    CA-2
>     |  EE-cert
>    EE
> 
> where CA-2-cert contains a critical keyUsage extension with 
> keyCertSign
> asserted and cRLSign *un-asserted*, the private key which 
> signs EE-cert
> also signs the CRL issued by CA-2 which covers EE.  A CA can always
> revoke its own certificates without needing permission from 
> an upstream CA.
> 
> If CA-2-cert had cRLSign asserted, then CA-2 could also sign 
> CRLs covering
> certificates signed by the private key which signed CA-2-cert (CA-1's
> private key).
> 
> Is this not the intent of X.509?
> 
> Dave
> 
> 
> 
> Sharon Boeyen wrote:
> > 
> > I agree with your first point but not completely with the 
> second point. The
> > cRLSign bit means "for verifying a CA's signature on CRLs". 
> In a hierarchy,
> > for example, one might set this bit, along with the 
> keyCertSign bit in a cert
> > issued to a subordinate CA. The CRLs that you would anticipate that
> > subordinate CA to issue are ones for the set of 
> certificates that the
> > subordinate issues, not ones for the certs issued by the CA 
> issuing that
> > subordinate's certificate. That is not the same delegation 
> we've been
> > discussing, where a CA hands off responsibility for issuing 
> CRLs for its own
> > set of certificates to another entity. That needs to be 
> indicated differently
> > so that a relying party knows what entity is authorized to 
> issue CRLs 'on
> > behalf of' another CA.
> > 
> > Sharon
> > 
> > > -----Original Message-----
> > > From: David P. Kemp [mailto:[e-mail]]
> > > Sent: Thursday, April 26, 2001 11:31 AM
> > > To: [e-mail]
> > > Cc: Hoyt Kesterson
> > > Subject: Re: keyCertSign and cRLSign Key Usage Bits
> > >
> > >
> > > Sharon,
> > >
> > > 1) A cert issued for purposes of verifying the signature on a
> > > CRL contains
> > >    at least the cRLSign bit. The digitalSignature bit (which
> > > is used for
> > >    purposes other than b, f, or g), is not necessary.
> > >
> > > 2) If a CRL is issued by an entity other than the CA that 
> issues the
> > >    certificate, that delegation is identified with 
> integrity by the
> > >    fact that the CA which issued the EE certificate has 
> also issued
> > >    issued a certificate containing the cRLSign bit to the CA's
> > >    revocation agent.  This agent is by definition an "authority",
> > >    by virtue of being the subject of the cRLSign certificate.
> > >
> > > Dave
> > >
> > >
> > > Sharon Boeyen wrote:
> > > >
> > > > Taking a step back at what is 'technically important'. A
> > > cert issued for
> > > > purposes of cert signature verification contains at least
> > > the ca bit set and
> > > > the keyUsage keyCertSign. A cert issued for purposes of
> > > verifying the
> > > > signature on a CRL contains at least the digitalSignature
> > > and cRLSign bits of
> > > > keyUsage. If a CRL is to be issued by an entity other the
> > > CA that issues the
> > > > certificate, then there needs to be a way to identify that
> > > delegation with
> > > > integrity. If the crlDistributionPoints extension is in the
> > > certificate, this
> > > > can be done by populating the cRLIssuer field and that
> > > value needs to
> > > > correspond with the issuer name of the CRL being used 
> (and the other
> > > > requirements outlined so nicely by
> > > > Santosh in Annex B of 509 also need to be met of course).
> > > Other mechanisms
> > > > could also be used. As for the schema, there was no problem
> > > with the PKI
> > > > schema components as long as the crl issuers were also
> > > CAs(except that the
> > > > requirement for the CA bit to be set in all cases 
> should probably be
> > > > removed).
> > >
> 

------_=_NextPart_001_01C0CE76.2FE7D840
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: keyCertSign and cRLSign Key Usage Bits</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Dave, my understanding of the crlsign bit is not =
that it is for delegating </FONT>
<BR><FONT SIZE=3D2>that indirect authority, but that it is similar to =
the keyCertSign bit in that</FONT>
<BR><FONT SIZE=3D2>it indicates that the certified key can be used to =
verify signatures on CRLs </FONT>
<BR><FONT SIZE=3D2>issued by the subject of the containing cert. It has =
nothing to do with delegating</FONT>
<BR><FONT SIZE=3D2>authority to issue CRLs on behalf of the issuing CA =
for the set of certificates issued </FONT>
<BR><FONT SIZE=3D2>by that issuer. </FONT>
</P>

<P><FONT SIZE=3D2>This bit would be typically be set in any cert issued =
by one CA to another CA where relying parties would beexpecting to =
verify signatures on both certificates and CRLs issued by the subject =
authority and in conjunction with a certification path that contains =
the cert with this extension. </FONT></P>

<P><FONT SIZE=3D2>Hoyt, can you comment from the perspective of the =
historian??&nbsp; </FONT>
</P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David P. Kemp [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, April 26, 2001 12:35 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Hoyt Kesterson</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: keyCertSign and cRLSign Key Usage =
Bits</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The second point is one where some clarifying =
language in X.509 and</FONT>
<BR><FONT SIZE=3D2>&gt; PKIX might be useful.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I've always assumed that the cRLSign bit is set =
exclusively for the</FONT>
<BR><FONT SIZE=3D2>&gt; purpose of delegating to an ICRLA or other =
agent (including </FONT>
<BR><FONT SIZE=3D2>&gt; the CA's own</FONT>
<BR><FONT SIZE=3D2>&gt; online CRL-signing key which is different from =
its offline </FONT>
<BR><FONT SIZE=3D2>&gt; cert-signing</FONT>
<BR><FONT SIZE=3D2>&gt; key).&nbsp; In other words, for these =
certs:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; CA-1</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; =
CA-2-cert</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; CA-2</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; EE-cert</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; EE</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; where CA-2-cert contains a critical keyUsage =
extension with </FONT>
<BR><FONT SIZE=3D2>&gt; keyCertSign</FONT>
<BR><FONT SIZE=3D2>&gt; asserted and cRLSign *un-asserted*, the private =
key which </FONT>
<BR><FONT SIZE=3D2>&gt; signs EE-cert</FONT>
<BR><FONT SIZE=3D2>&gt; also signs the CRL issued by CA-2 which covers =
EE.&nbsp; A CA can always</FONT>
<BR><FONT SIZE=3D2>&gt; revoke its own certificates without needing =
permission from </FONT>
<BR><FONT SIZE=3D2>&gt; an upstream CA.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If CA-2-cert had cRLSign asserted, then CA-2 =
could also sign </FONT>
<BR><FONT SIZE=3D2>&gt; CRLs covering</FONT>
<BR><FONT SIZE=3D2>&gt; certificates signed by the private key which =
signed CA-2-cert (CA-1's</FONT>
<BR><FONT SIZE=3D2>&gt; private key).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is this not the intent of X.509?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sharon Boeyen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I agree with your first point but not =
completely with the </FONT>
<BR><FONT SIZE=3D2>&gt; second point. The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; cRLSign bit means &quot;for verifying a =
CA's signature on CRLs&quot;. </FONT>
<BR><FONT SIZE=3D2>&gt; In a hierarchy,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for example, one might set this bit, along =
with the </FONT>
<BR><FONT SIZE=3D2>&gt; keyCertSign bit in a cert</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; issued to a subordinate CA. The CRLs that =
you would anticipate that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; subordinate CA to issue are ones for the =
set of </FONT>
<BR><FONT SIZE=3D2>&gt; certificates that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; subordinate issues, not ones for the certs =
issued by the CA </FONT>
<BR><FONT SIZE=3D2>&gt; issuing that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; subordinate's certificate. That is not the =
same delegation </FONT>
<BR><FONT SIZE=3D2>&gt; we've been</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; discussing, where a CA hands off =
responsibility for issuing </FONT>
<BR><FONT SIZE=3D2>&gt; CRLs for its own</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; set of certificates to another entity. =
That needs to be </FONT>
<BR><FONT SIZE=3D2>&gt; indicated differently</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; so that a relying party knows what entity =
is authorized to </FONT>
<BR><FONT SIZE=3D2>&gt; issue CRLs 'on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; behalf of' another CA.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sharon</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: David P. Kemp [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Thursday, April 26, 2001 11:31 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: Hoyt Kesterson</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: Re: keyCertSign and cRLSign =
Key Usage Bits</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sharon,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; 1) A cert issued for purposes of =
verifying the signature on a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; CRL contains</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; at least the =
cRLSign bit. The digitalSignature bit (which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; is used for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; purposes other than =
b, f, or g), is not necessary.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; 2) If a CRL is issued by an entity =
other than the CA that </FONT>
<BR><FONT SIZE=3D2>&gt; issues the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; certificate, that =
delegation is identified with </FONT>
<BR><FONT SIZE=3D2>&gt; integrity by the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; fact that the CA =
which issued the EE certificate has </FONT>
<BR><FONT SIZE=3D2>&gt; also issued</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; issued a =
certificate containing the cRLSign bit to the CA's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; revocation =
agent.&nbsp; This agent is by definition an =
&quot;authority&quot;,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; by virtue of being =
the subject of the cRLSign certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sharon Boeyen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Taking a step back at what is =
'technically important'. A</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; cert issued for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; purposes of cert signature =
verification contains at least</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the ca bit set and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; the keyUsage keyCertSign. A cert =
issued for purposes of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; verifying the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; signature on a CRL contains at =
least the digitalSignature</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; and cRLSign bits of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; keyUsage. If a CRL is to be =
issued by an entity other the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; CA that issues the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; certificate, then there needs to =
be a way to identify that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; delegation with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; integrity. If the =
crlDistributionPoints extension is in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; certificate, this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; can be done by populating the =
cRLIssuer field and that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; value needs to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; correspond with the issuer name =
of the CRL being used </FONT>
<BR><FONT SIZE=3D2>&gt; (and the other</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; requirements outlined so nicely =
by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Santosh in Annex B of 509 also =
need to be met of course).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Other mechanisms</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; could also be used. As for the =
schema, there was no problem</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; with the PKI</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; schema components as long as the =
crl issuers were also</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; CAs(except that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; requirement for the CA bit to be =
set in all cases </FONT>
<BR><FONT SIZE=3D2>&gt; should probably be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; removed).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CE76.2FE7D840--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA01533 for <[e-mail]>; Thu, 26 Apr 2001 10:15:25 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JV6F5Y8S>; Thu, 26 Apr 2001 13:14:56 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "David P. Kemp" <[e-mail]>, [e-mail]
Cc: Hoyt Kesterson <[e-mail]>
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Date: Thu, 26 Apr 2001 13:06:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE73.2BFCE9D0"

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_01C0CE73.2BFCE9D0
Content-Type: text/plain;
	charset="iso-8859-1"

Dave:

Not that alone.

As we have discussed in this thread, for operational security
considerations, a CA may have a separate key (but the same name) for signing
CRL.  That key may be certified by the CA itself and/or the CA's parent.

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Thursday, April 26, 2001 12:35 PM
To: [e-mail]
Cc: Hoyt Kesterson
Subject: Re: keyCertSign and cRLSign Key Usage Bits


The second point is one where some clarifying language in X.509 and
PKIX might be useful.

I've always assumed that the cRLSign bit is set exclusively for the
purpose of delegating to an ICRLA or other agent (including the CA's own
online CRL-signing key which is different from its offline cert-signing
key).  In other words, for these certs:

   CA-1
    |  CA-2-cert
   CA-2
    |  EE-cert
   EE

where CA-2-cert contains a critical keyUsage extension with keyCertSign
asserted and cRLSign *un-asserted*, the private key which signs EE-cert
also signs the CRL issued by CA-2 which covers EE.  A CA can always
revoke its own certificates without needing permission from an upstream CA.

If CA-2-cert had cRLSign asserted, then CA-2 could also sign CRLs covering
certificates signed by the private key which signed CA-2-cert (CA-1's
private key).

Is this not the intent of X.509?

Dave



Sharon Boeyen wrote:
> 
> I agree with your first point but not completely with the second point.
The
> cRLSign bit means "for verifying a CA's signature on CRLs". In a
hierarchy,
> for example, one might set this bit, along with the keyCertSign bit in a
cert
> issued to a subordinate CA. The CRLs that you would anticipate that
> subordinate CA to issue are ones for the set of certificates that the
> subordinate issues, not ones for the certs issued by the CA issuing that
> subordinate's certificate. That is not the same delegation we've been
> discussing, where a CA hands off responsibility for issuing CRLs for its
own
> set of certificates to another entity. That needs to be indicated
differently
> so that a relying party knows what entity is authorized to issue CRLs 'on
> behalf of' another CA.
> 
> Sharon
> 
> > -----Original Message-----
> > From: David P. Kemp [mailto:[e-mail]]
> > Sent: Thursday, April 26, 2001 11:31 AM
> > To: [e-mail]
> > Cc: Hoyt Kesterson
> > Subject: Re: keyCertSign and cRLSign Key Usage Bits
> >
> >
> > Sharon,
> >
> > 1) A cert issued for purposes of verifying the signature on a
> > CRL contains
> >    at least the cRLSign bit. The digitalSignature bit (which
> > is used for
> >    purposes other than b, f, or g), is not necessary.
> >
> > 2) If a CRL is issued by an entity other than the CA that issues the
> >    certificate, that delegation is identified with integrity by the
> >    fact that the CA which issued the EE certificate has also issued
> >    issued a certificate containing the cRLSign bit to the CA's
> >    revocation agent.  This agent is by definition an "authority",
> >    by virtue of being the subject of the cRLSign certificate.
> >
> > Dave
> >
> >
> > Sharon Boeyen wrote:
> > >
> > > Taking a step back at what is 'technically important'. A
> > cert issued for
> > > purposes of cert signature verification contains at least
> > the ca bit set and
> > > the keyUsage keyCertSign. A cert issued for purposes of
> > verifying the
> > > signature on a CRL contains at least the digitalSignature
> > and cRLSign bits of
> > > keyUsage. If a CRL is to be issued by an entity other the
> > CA that issues the
> > > certificate, then there needs to be a way to identify that
> > delegation with
> > > integrity. If the crlDistributionPoints extension is in the
> > certificate, this
> > > can be done by populating the cRLIssuer field and that
> > value needs to
> > > correspond with the issuer name of the CRL being used (and the other
> > > requirements outlined so nicely by
> > > Santosh in Annex B of 509 also need to be met of course).
> > Other mechanisms
> > > could also be used. As for the schema, there was no problem
> > with the PKI
> > > schema components as long as the crl issuers were also
> > CAs(except that the
> > > requirement for the CA bit to be set in all cases should probably be
> > > removed).
> >

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: keyCertSign and cRLSign Key Usage Bits</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>Not that alone.</FONT>
</P>

<P><FONT SIZE=3D2>As we have discussed in this thread, for operational =
security considerations, a CA may have a separate key (but the same =
name) for signing CRL.&nbsp; That key may be certified by the CA itself =
and/or the CA's parent.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David P. Kemp [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, April 26, 2001 12:35 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: Hoyt Kesterson</FONT>
<BR><FONT SIZE=3D2>Subject: Re: keyCertSign and cRLSign Key Usage =
Bits</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The second point is one where some clarifying =
language in X.509 and</FONT>
<BR><FONT SIZE=3D2>PKIX might be useful.</FONT>
</P>

<P><FONT SIZE=3D2>I've always assumed that the cRLSign bit is set =
exclusively for the</FONT>
<BR><FONT SIZE=3D2>purpose of delegating to an ICRLA or other agent =
(including the CA's own</FONT>
<BR><FONT SIZE=3D2>online CRL-signing key which is different from its =
offline cert-signing</FONT>
<BR><FONT SIZE=3D2>key).&nbsp; In other words, for these certs:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; CA-1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; |&nbsp; CA-2-cert</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; CA-2</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; |&nbsp; EE-cert</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; EE</FONT>
</P>

<P><FONT SIZE=3D2>where CA-2-cert contains a critical keyUsage =
extension with keyCertSign</FONT>
<BR><FONT SIZE=3D2>asserted and cRLSign *un-asserted*, the private key =
which signs EE-cert</FONT>
<BR><FONT SIZE=3D2>also signs the CRL issued by CA-2 which covers =
EE.&nbsp; A CA can always</FONT>
<BR><FONT SIZE=3D2>revoke its own certificates without needing =
permission from an upstream CA.</FONT>
</P>

<P><FONT SIZE=3D2>If CA-2-cert had cRLSign asserted, then CA-2 could =
also sign CRLs covering</FONT>
<BR><FONT SIZE=3D2>certificates signed by the private key which signed =
CA-2-cert (CA-1's</FONT>
<BR><FONT SIZE=3D2>private key).</FONT>
</P>

<P><FONT SIZE=3D2>Is this not the intent of X.509?</FONT>
</P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Sharon Boeyen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I agree with your first point but not =
completely with the second point. The</FONT>
<BR><FONT SIZE=3D2>&gt; cRLSign bit means &quot;for verifying a CA's =
signature on CRLs&quot;. In a hierarchy,</FONT>
<BR><FONT SIZE=3D2>&gt; for example, one might set this bit, along with =
the keyCertSign bit in a cert</FONT>
<BR><FONT SIZE=3D2>&gt; issued to a subordinate CA. The CRLs that you =
would anticipate that</FONT>
<BR><FONT SIZE=3D2>&gt; subordinate CA to issue are ones for the set of =
certificates that the</FONT>
<BR><FONT SIZE=3D2>&gt; subordinate issues, not ones for the certs =
issued by the CA issuing that</FONT>
<BR><FONT SIZE=3D2>&gt; subordinate's certificate. That is not the same =
delegation we've been</FONT>
<BR><FONT SIZE=3D2>&gt; discussing, where a CA hands off responsibility =
for issuing CRLs for its own</FONT>
<BR><FONT SIZE=3D2>&gt; set of certificates to another entity. That =
needs to be indicated differently</FONT>
<BR><FONT SIZE=3D2>&gt; so that a relying party knows what entity is =
authorized to issue CRLs 'on</FONT>
<BR><FONT SIZE=3D2>&gt; behalf of' another CA.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sharon</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: David P. Kemp [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, April 26, 2001 11:31 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: Hoyt Kesterson</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: keyCertSign and cRLSign Key =
Usage Bits</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sharon,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1) A cert issued for purposes of verifying =
the signature on a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; CRL contains</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; at least the cRLSign =
bit. The digitalSignature bit (which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; is used for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; purposes other than b, =
f, or g), is not necessary.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2) If a CRL is issued by an entity other =
than the CA that issues the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; certificate, that =
delegation is identified with integrity by the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; fact that the CA which =
issued the EE certificate has also issued</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; issued a certificate =
containing the cRLSign bit to the CA's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; revocation agent.&nbsp; =
This agent is by definition an &quot;authority&quot;,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; by virtue of being the =
subject of the cRLSign certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sharon Boeyen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Taking a step back at what is =
'technically important'. A</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; cert issued for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; purposes of cert signature =
verification contains at least</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the ca bit set and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the keyUsage keyCertSign. A cert =
issued for purposes of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; verifying the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; signature on a CRL contains at least =
the digitalSignature</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and cRLSign bits of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; keyUsage. If a CRL is to be issued by =
an entity other the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; CA that issues the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; certificate, then there needs to be a =
way to identify that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; delegation with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; integrity. If the =
crlDistributionPoints extension is in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificate, this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; can be done by populating the =
cRLIssuer field and that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; value needs to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; correspond with the issuer name of =
the CRL being used (and the other</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; requirements outlined so nicely =
by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Santosh in Annex B of 509 also need =
to be met of course).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Other mechanisms</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; could also be used. As for the =
schema, there was no problem</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with the PKI</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; schema components as long as the crl =
issuers were also</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; CAs(except that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; requirement for the CA bit to be set =
in all cases should probably be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; removed).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CE73.2BFCE9D0--


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA28714 for <[e-mail]>; Thu, 26 Apr 2001 09:37:09 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA28576; Thu, 26 Apr 2001 12:36:40 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Thu, 26 Apr 2001 12:34:44 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Hoyt Kesterson <[e-mail]>
Subject: Re: keyCertSign and cRLSign Key Usage Bits
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The second point is one where some clarifying language in X.509 and
PKIX might be useful.

I've always assumed that the cRLSign bit is set exclusively for the
purpose of delegating to an ICRLA or other agent (including the CA's own
online CRL-signing key which is different from its offline cert-signing
key).  In other words, for these certs:

   CA-1
    |  CA-2-cert
   CA-2
    |  EE-cert
   EE

where CA-2-cert contains a critical keyUsage extension with keyCertSign
asserted and cRLSign *un-asserted*, the private key which signs EE-cert
also signs the CRL issued by CA-2 which covers EE.  A CA can always
revoke its own certificates without needing permission from an upstream CA.

If CA-2-cert had cRLSign asserted, then CA-2 could also sign CRLs covering
certificates signed by the private key which signed CA-2-cert (CA-1's
private key).

Is this not the intent of X.509?

Dave



Sharon Boeyen wrote:
> 
> I agree with your first point but not completely with the second point. The
> cRLSign bit means "for verifying a CA's signature on CRLs". In a hierarchy,
> for example, one might set this bit, along with the keyCertSign bit in a cert
> issued to a subordinate CA. The CRLs that you would anticipate that
> subordinate CA to issue are ones for the set of certificates that the
> subordinate issues, not ones for the certs issued by the CA issuing that
> subordinate's certificate. That is not the same delegation we've been
> discussing, where a CA hands off responsibility for issuing CRLs for its own
> set of certificates to another entity. That needs to be indicated differently
> so that a relying party knows what entity is authorized to issue CRLs 'on
> behalf of' another CA.
> 
> Sharon
> 
> > -----Original Message-----
> > From: David P. Kemp [mailto:[e-mail]]
> > Sent: Thursday, April 26, 2001 11:31 AM
> > To: [e-mail]
> > Cc: Hoyt Kesterson
> > Subject: Re: keyCertSign and cRLSign Key Usage Bits
> >
> >
> > Sharon,
> >
> > 1) A cert issued for purposes of verifying the signature on a
> > CRL contains
> >    at least the cRLSign bit. The digitalSignature bit (which
> > is used for
> >    purposes other than b, f, or g), is not necessary.
> >
> > 2) If a CRL is issued by an entity other than the CA that issues the
> >    certificate, that delegation is identified with integrity by the
> >    fact that the CA which issued the EE certificate has also issued
> >    issued a certificate containing the cRLSign bit to the CA's
> >    revocation agent.  This agent is by definition an "authority",
> >    by virtue of being the subject of the cRLSign certificate.
> >
> > Dave
> >
> >
> > Sharon Boeyen wrote:
> > >
> > > Taking a step back at what is 'technically important'. A
> > cert issued for
> > > purposes of cert signature verification contains at least
> > the ca bit set and
> > > the keyUsage keyCertSign. A cert issued for purposes of
> > verifying the
> > > signature on a CRL contains at least the digitalSignature
> > and cRLSign bits of
> > > keyUsage. If a CRL is to be issued by an entity other the
> > CA that issues the
> > > certificate, then there needs to be a way to identify that
> > delegation with
> > > integrity. If the crlDistributionPoints extension is in the
> > certificate, this
> > > can be done by populating the cRLIssuer field and that
> > value needs to
> > > correspond with the issuer name of the CRL being used (and the other
> > > requirements outlined so nicely by
> > > Santosh in Annex B of 509 also need to be met of course).
> > Other mechanisms
> > > could also be used. As for the schema, there was no problem
> > with the PKI
> > > schema components as long as the crl issuers were also
> > CAs(except that the
> > > requirement for the CA bit to be set in all cases should probably be
> > > removed).
> >


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA27380 for <[e-mail]>; Thu, 26 Apr 2001 09:13:18 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JV6F5X8L>; Thu, 26 Apr 2001 12:12:49 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Cc: Hoyt Kesterson <[e-mail]>
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Date: Thu, 26 Apr 2001 12:07:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE6A.ED718930"

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_01C0CE6A.ED718930
Content-Type: text/plain

I agree with your first point but not completely with the second point. The
cRLSign bit means "for verifying a CA's signature on CRLs". In a hierarchy,
for example, one might set this bit, along with the keyCertSign bit in a
cert issued to a subordinate CA. The CRLs that you would anticipate that
subordinate CA to issue are ones for the set of certificates that the
subordinate issues, not ones for the certs issued by the CA issuing that
subordinate's certificate. That is not the same delegation we've been
discussing, where a CA hands off responsibility for issuing CRLs for its own
set of certificates to another entity. That needs to be indicated
differently so that a relying party knows what entity is authorized to issue
CRLs 'on behalf of' another CA. 

Sharon

> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Thursday, April 26, 2001 11:31 AM
> To: [e-mail]
> Cc: Hoyt Kesterson
> Subject: Re: keyCertSign and cRLSign Key Usage Bits
> 
> 
> Sharon,
> 
> 1) A cert issued for purposes of verifying the signature on a 
> CRL contains
>    at least the cRLSign bit. The digitalSignature bit (which 
> is used for
>    purposes other than b, f, or g), is not necessary.
> 
> 2) If a CRL is issued by an entity other than the CA that issues the
>    certificate, that delegation is identified with integrity by the
>    fact that the CA which issued the EE certificate has also issued
>    issued a certificate containing the cRLSign bit to the CA's
>    revocation agent.  This agent is by definition an "authority",
>    by virtue of being the subject of the cRLSign certificate.
> 
> Dave
> 
> 
> Sharon Boeyen wrote:
> > 
> > Taking a step back at what is 'technically important'. A 
> cert issued for
> > purposes of cert signature verification contains at least 
> the ca bit set and
> > the keyUsage keyCertSign. A cert issued for purposes of 
> verifying the
> > signature on a CRL contains at least the digitalSignature 
> and cRLSign bits of
> > keyUsage. If a CRL is to be issued by an entity other the 
> CA that issues the
> > certificate, then there needs to be a way to identify that 
> delegation with
> > integrity. If the crlDistributionPoints extension is in the 
> certificate, this
> > can be done by populating the cRLIssuer field and that 
> value needs to
> > correspond with the issuer name of the CRL being used (and the other
> > requirements outlined so nicely by
> > Santosh in Annex B of 509 also need to be met of course). 
> Other mechanisms
> > could also be used. As for the schema, there was no problem 
> with the PKI
> > schema components as long as the crl issuers were also 
> CAs(except that the
> > requirement for the CA bit to be set in all cases should probably be
> > removed).
> 

------_=_NextPart_001_01C0CE6A.ED718930
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: keyCertSign and cRLSign Key Usage Bits</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with your first point but not completely with =
the second point. The cRLSign bit means &quot;for verifying a CA's =
signature on CRLs&quot;. In a hierarchy, for example, one might set =
this bit, along with the keyCertSign bit in a cert issued to a =
subordinate CA. The CRLs that you would anticipate that subordinate CA =
to issue are ones for the set of certificates that the subordinate =
issues, not ones for the certs issued by the CA issuing that =
subordinate's certificate. That is not the same delegation we've been =
discussing, where a CA hands off responsibility for issuing CRLs for =
its own set of certificates to another entity. That needs to be =
indicated differently so that a relying party knows what entity is =
authorized to issue CRLs 'on behalf of' another CA. </FONT></P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David P. Kemp [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, April 26, 2001 11:31 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Hoyt Kesterson</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: keyCertSign and cRLSign Key Usage =
Bits</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sharon,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1) A cert issued for purposes of verifying the =
signature on a </FONT>
<BR><FONT SIZE=3D2>&gt; CRL contains</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; at least the cRLSign bit. The =
digitalSignature bit (which </FONT>
<BR><FONT SIZE=3D2>&gt; is used for</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; purposes other than b, f, or =
g), is not necessary.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2) If a CRL is issued by an entity other than =
the CA that issues the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; certificate, that delegation =
is identified with integrity by the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; fact that the CA which issued =
the EE certificate has also issued</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; issued a certificate =
containing the cRLSign bit to the CA's</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; revocation agent.&nbsp; This =
agent is by definition an &quot;authority&quot;,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; by virtue of being the =
subject of the cRLSign certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sharon Boeyen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Taking a step back at what is 'technically =
important'. A </FONT>
<BR><FONT SIZE=3D2>&gt; cert issued for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; purposes of cert signature verification =
contains at least </FONT>
<BR><FONT SIZE=3D2>&gt; the ca bit set and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the keyUsage keyCertSign. A cert issued =
for purposes of </FONT>
<BR><FONT SIZE=3D2>&gt; verifying the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; signature on a CRL contains at least the =
digitalSignature </FONT>
<BR><FONT SIZE=3D2>&gt; and cRLSign bits of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; keyUsage. If a CRL is to be issued by an =
entity other the </FONT>
<BR><FONT SIZE=3D2>&gt; CA that issues the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificate, then there needs to be a way =
to identify that </FONT>
<BR><FONT SIZE=3D2>&gt; delegation with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; integrity. If the crlDistributionPoints =
extension is in the </FONT>
<BR><FONT SIZE=3D2>&gt; certificate, this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; can be done by populating the cRLIssuer =
field and that </FONT>
<BR><FONT SIZE=3D2>&gt; value needs to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; correspond with the issuer name of the CRL =
being used (and the other</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirements outlined so nicely by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Santosh in Annex B of 509 also need to be =
met of course). </FONT>
<BR><FONT SIZE=3D2>&gt; Other mechanisms</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; could also be used. As for the schema, =
there was no problem </FONT>
<BR><FONT SIZE=3D2>&gt; with the PKI</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; schema components as long as the crl =
issuers were also </FONT>
<BR><FONT SIZE=3D2>&gt; CAs(except that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirement for the CA bit to be set in =
all cases should probably be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; removed).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CE6A.ED718930--


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21359 for <[e-mail]>; Thu, 26 Apr 2001 08:33:40 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA26043; Thu, 26 Apr 2001 11:33:11 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Thu, 26 Apr 2001 11:31:11 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Hoyt Kesterson <[e-mail]>
Subject: Re: keyCertSign and cRLSign Key Usage Bits
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sharon,

1) A cert issued for purposes of verifying the signature on a CRL contains
   at least the cRLSign bit. The digitalSignature bit (which is used for
   purposes other than b, f, or g), is not necessary.

2) If a CRL is issued by an entity other than the CA that issues the
   certificate, that delegation is identified with integrity by the
   fact that the CA which issued the EE certificate has also issued
   issued a certificate containing the cRLSign bit to the CA's
   revocation agent.  This agent is by definition an "authority",
   by virtue of being the subject of the cRLSign certificate.

Dave


Sharon Boeyen wrote:
> 
> Taking a step back at what is 'technically important'. A cert issued for
> purposes of cert signature verification contains at least the ca bit set and
> the keyUsage keyCertSign. A cert issued for purposes of verifying the
> signature on a CRL contains at least the digitalSignature and cRLSign bits of
> keyUsage. If a CRL is to be issued by an entity other the CA that issues the
> certificate, then there needs to be a way to identify that delegation with
> integrity. If the crlDistributionPoints extension is in the certificate, this
> can be done by populating the cRLIssuer field and that value needs to
> correspond with the issuer name of the CRL being used (and the other
> requirements outlined so nicely by
> Santosh in Annex B of 509 also need to be met of course). Other mechanisms
> could also be used. As for the schema, there was no problem with the PKI
> schema components as long as the crl issuers were also CAs(except that the
> requirement for the CA bit to be set in all cases should probably be
> removed).


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17129 for <[e-mail]>; Thu, 26 Apr 2001 08:07:46 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JV6F5W9M>; Thu, 26 Apr 2001 11:07:16 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Sharon Boeyen <[e-mail]>, Santosh Chokhani <[e-mail]>, "David A. Cooper" <[e-mail]>, [e-mail]
Cc: "Hoyt Kesterson (E-mail)" <[e-mail]>
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Date: Thu, 26 Apr 2001 10:58:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE61.55A85A60"

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_01C0CE61.55A85A60
Content-Type: text/plain;
	charset="iso-8859-1"

My suggestion is NOT to change the standard.  That is require the CRL signer
to be a caCertificate and make sure that the basic constraint extension is
present with cA flag set to .TRUE.
 
My suggestion is however that the clients be not required to validate all
this except cRLSign bit in the keyUsage extension.
 
 
-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]]
Sent: Thursday, April 26, 2001 10:42 AM
To: Santosh Chokhani; David A. Cooper; [e-mail]
Cc: Hoyt Kesterson (E-mail)
Subject: RE: keyCertSign and cRLSign Key Usage Bits


Santosh I see your point on the schema - actually 509 contains the exact
same text and would also need to 
be modified. I assume that the appropriate change would be to delete the
text that requires the ca bit to be set in 
any cert that goes into the cACertificate attribute. As for the
crossCertificatePair attribute, I guess it would need
to be lifted there as well (assuming a CA would want to issue a cert to
another CA for purposes of verifying signatures
on CRLs but not on certificates)?
 
That raises another point - if we modify all this "stuff" to allow entities
other than authorities to sign CRLs, where 
would those certificates be stored? The subjects aren't CAs so they don't
really belong in either of these attributes. Inventing another attribute and
object class isn't very attractive either. Thoughts?
 
Dave, I realize you weren't suggesting we do this, but I do want to say that
I would not support changing the 
meaning of the ca bit in basic constraints. That is there as one of many
'business controls" that a CA can use to 
ensure that the certificate it issues (containing those constraints), when
used by conforming path validation systems, 
achieves that CAs intended result. That is very specific, very important,
and I wouldn't want to see it generalized. 
Nor would I support requiring any ties between the basicConstraints
extension and other extensions within X.509. 509
needs to remain flexible to allow PKIX and other profiles to determine their
own requirements for such combinations.
 
As for the definition of a CA, in addition to issuing certificates it has
responsibility for certificate revocation, which it may perform directly or
delegate to another 'authority/entity'. If that delegation can be to an
entity other than an authority, then you still have a schema problem
regardless of what you do with the ca bit and keyUsage. 
 
Taking a step back at what is 'technically important'. A cert issued for
purposes of cert signature verification contains at least the ca bit set and
the keyUsage keyCertSign. A cert issued for purposes of verifying the
signature on a CRL contains at least the digitalSignature and cRLSign bits
of keyUsage. If a CRL is to be issued by an entity other the CA that issues
the certificate, then there needs to be a way to identify that delegation
with integrity. If the crlDistributionPoints extension is in the
certificate, this can be done by populating the cRLIssuer field and that
value needs to correspond with the issuer name of the CRL being used (and
the other requirements outlined so nicely by 
Santosh in Annex B of 509 also need to be met of course). Other mechanisms
could also be used. As for the schema, there was no problem with the PKI
schema components as long as the crl issuers were also CAs(except that the
requirement for the CA bit to be set in all cases should probably be
removed). 
 
Assuming PKIX reaches consensus on wanting entities other than authorities
to issue crls, then additional schema work is at least needed and some
re-writing of text in 509 to permit that would also be needed. Hoyt and I
have already 
started working on a proposed draft defect report for that text, in
anticipation of that consensus, but we haven't looked
at schema implications yet.     
 
 
 -----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, April 26, 2001 9:53 AM
To: David A. Cooper; [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits



Dave:
 
My opinion are based on the fact that the current X.509 text says that CA
issues CRLs.  Thus, if the key is used to sign the CRL, it is a CA and hence
the caCertificate.
 
I think this is not a security issue (in my mind).  We need to make sure
that the X.509 language and ldap schema align.
 
I still believe that those clients that do not make checks that are not
relevant to security, should be considered compliant.
 
-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Thursday, April 26, 2001 9:37 AM
To: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits


Santosh,

I think you bring up an interesting issue with the LDAP schema no matter
what we do. As I pointed out yesterday, a CA may have a key pair that it
only uses for PKI transaction messages. A certificate that includes the
public key from this key pair would only have the digitalSignature KeyUsage
bit set. The proposed text below states that the cA bit in basicConstraints
should not be set. So, we would still have cases in which a certificate has
been issued to a CA and either basicConstraints is absent or cA is set to
false. (Technically, according to RFC 2587, we are OK if basicConstraints is
absent, but this isn't really a good way out of the problem). A CA may also
be issued a certificate in which the public key is intended to be used for
key management. Same problem.

I asked yesterday what the meaning of the cA bit was. X.509 states that
"[t]he cA component indicates if the certified public key may be used to
verify certificate signatures." Do we intend to change X.509 and PKIX to
state that the cA bit should be set whenever the subject is a CA? If not,
then the LDAP schema will need to deal with certificates issued to CAs in
which either basicConstraints is absent or is present with cA set to FALSE.
If so, then we need to change the text to eliminate any tying between the cA
bit and the contents of KeyUsage.

If we want to go with the proposed text below, then we will need to change
both X.509 and PKIX to state that "the cA component indicates if the
certified public key may be used to verify certificate or CRL signatures".
We will also need to do something about the awkward connection between the
cA bit and CRLs. Currently the text states that the cA bit should be set if
the CRL issuing subject is issuing CRLs that cover public key certificates,
but not attribute certificates. It further states that " 

AA certificates MUST NOT be used to verify signatures on CRLs containing
revocation information for public key certificates". The problem is that,
even if a single entity is not allowed to issued both public key
certificates and attribute certificates, there is the possibility that a
single, indirect CRL could cover both types of certificates. If one is using
a CRL to check the status of a public key certificate, then it is clear that
the text below requires that the certificate containing the key needed to
verify the CRL signature must have the cA bit set. But what about when one
is using a CRL to check the status of an attribute certificate? The quote
text seem to suggest that, if the cA bit is not set in the certificate, the
relying party is required to verify that the CRL does not contain any
revocation information for public key certificates. I can't imagine that
there was any intention to impose such a requirement, but that is what the
text seems to say.



I think I have made my own opinion on this topic clear. X.509 does not state
that the cA bit in basicConstraints should be set if the subject is a CA, it
states that the bit should be set if the certified public key may be used to
verify certificate signatures. The two are not synonymous.  If we change the
standard to state that the cA bit indicates whether the subject is a CA, it
may solve the LDAP schema problem, but it will require that the remove any
dependencies between the cA bit and the KeyUsage extension.

As Tony said yesterday, we need to go back and clearly define the terms we
are using. X.509 defines a CA as an entity that issues public key
certificates. Is this the correct definition? Or is a CA an entity that
issues public key certificates or CRLs that provide revocation information
about public key certificates? Or it is something else? Does the cA bit
indicate if the certified public key can be used to verify signatures on
certificates, as X.509 states, or does it indicate that the subject is a CA,
or something else? If we can't get agreement that the standard means what it
says, how can we expect people to understand the standard?

Dave

At 08:20 AM 4/26/01 -0400, Santosh Chokhani wrote:


Steve:
 
My rationale is as follows: There is no security benefit to checking the
bit.  The basic constraints and associated path length may determine whether
a CA can create a CA or not.  But, that is only useful for certificate path
and since keyCertSign bit will not be set, the entity will NOT be able to
create new CAs.
 
So, I think check is not relevant from security viewpoint.
 
Now, it may break some of the language (again not security) in ldap schema
if we populate the certificate in caCertificate or crossCertificatePair and
do not set the basic constraints.
 
So, it is a mixed bag.  I still think we should ask for the CAs to set the
basic constraint bit so the ldap schema does not get screwed up and NOT
require the client to check the bit.  My rule on clients is simple.
Maximize security and interoperability.  Make all checks that are security
relevant and no more and that will lead to greater interoperability.
 
 
-----Original Message-----
From: Stephen Kent [ mailto:[e-mail] <mailto:[e-mail]> ]
Sent: Wednesday, April 25, 2001 3:51 PM
To: Ambarish Malpani
Cc: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits

At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:



I agree, also.

Ambarish


I disagree. We need to make a decision on whether a cert without a CA flag
enabled can sign CRLs. If so, then we need to modify a lot of text in 2459,
and in X.509, to say this clearly. Suggesting that a client be "forgiving"
in this context is not a viable proposal for a standard.

Steve



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



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

From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Tuesday, April 24, 2001 8:22 AM 

To: Housley, Russ; [e-mail] 

Subject: RE: keyCertSign and cRLSign Key Usage Bits



Russ: I agree with the text.



I also know that Steve Kent and Sharon Boeyen feel that X.509 states that
only CA can issue CRL (the context of my comments being PKI only and not
PMI).



But, using the theory that you suggest that the client be forgiving, I would
consider a client compliant if it did NOT check the basic constraint
extension while verifying a signature on a CRL.  It need to ensure that the
cRLSign bit is set in the keyUsage extension.



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

From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Tuesday, April 24, 2001 10:37 AM 

To: [e-mail] 

Subject: keyCertSign and cRLSign Key Usage Bits





The consensus on these bits is not totally clear to me.  Yet, several 

points have been consistently, and I think that the following text 

incorporates them.  The debate regarding he linkage between these bits and 

the cA bit in the basic constraints extension does not seem to be over, and 

I have not made any changes in that area.  Please use this new thread to 

discuss any remaining unresolved points.



       The keyCertSign bit is asserted when the subject public key is 

       used for verifying a signature on public key certificates.  This 

       bit MUST only be asserted in CA certificates.  If the keyCertSign 

       bit is asserted, then the cA bit in the basic constraints 

       extension (see 4.2.1.10) MUST also be asserted.  If neither the 

       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit 

       in the basic constraints extension MUST NOT be asserted.



       The cRLSign bit is asserted when the subject public key is used 

       for verifying a signature on a certificate revocation list (e.g., 

       a CRL or an ARL).  This bit MUST be asserted in CA and Attribute 

       Authority (AA) certificates that are used to verify signatures on 

       CRLs.  If the cRLSign bit is asserted in a CA certificate, then 

       the cA bit in the basic constraints extension (see 4.2.1.10) MUST 

       also be asserted.  If the cRLSign bit is asserted in a AA 

       certificate, then the cA bit in the basic constraints extension 

       MUST NOT be asserted.  Such AA certificates MUST NOT be used to 

       verify signatures on CRLs containing revocation information for 

       public key certificates; however, these AA certificates MAY be 

       used to verify signatures on CRLs containing revocation 

       information concerning attribute certificates.  If neither the 

       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit 

       in the basic constraints extension MUST NOT be asserted.



Russ 



------_=_NextPart_001_01C0CE61.55A85A60
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=917120415-26042001>My 
suggestion is NOT to change the standard.&nbsp; That is require the CRL signer 
to be a caCertificate and make sure that the basic constraint extension is 
present with cA flag set to .TRUE.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=917120415-26042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=917120415-26042001>My 
suggestion is however that the clients be not required to validate all this 
except cRLSign bit in the keyUsage extension.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen 
[mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 26, 2001 
10:42 AM<BR><B>To:</B> Santosh Chokhani; David A. Cooper; 
[e-mail]<BR><B>Cc:</B> Hoyt Kesterson (E-mail)<BR><B>Subject:</B> RE: 
keyCertSign and cRLSign Key Usage Bits<BR><BR></FONT></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial 
size=2>Santosh I see your point on the schema - actually 509 contains the exact 
same text and would also need to </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial size=2>be 
modified. I assume that the appropriate change would be to delete the text that 
requires the ca bit to be set in </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial size=2>any 
cert that goes into the cACertificate attribute. As for the crossCertificatePair 
attribute, I guess it would need</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial size=2>to be 
lifted there as well (assuming a CA would want to issue a cert to another CA for 
purposes of verifying signatures</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial size=2>on 
CRLs but not on certificates)?</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial size=2>That 
raises another point - if we modify all this "stuff" to allow entities other 
than authorities to sign CRLs, where </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial size=2>would 
those certificates be stored? The subjects&nbsp;aren't CAs so they don't really 
belong in either of these attributes.</FONT></SPAN><SPAN 
class=786041614-26042001><FONT color=#0000ff face=Arial size=2> 
</FONT></SPAN><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial 
size=2>Inventing another attribute and object class isn't very attractive 
either. Thoughts?</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial size=2>Dave, 
I realize you weren't suggesting we do this, but I do want to say that I would 
not support changing the </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial 
size=2>meaning of the ca bit in basic constraints. That is there as one of many 
'business controls" that a CA can use to </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial size=2>ensure 
that the certificate it issues (containing those constraints), when used by 
conforming path validation systems, </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial 
size=2>achieves that CAs intended result. That is very specific, very important, 
and I wouldn't want to see it generalized. </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial size=2>Nor 
would I support requiring any ties between the basicConstraints extension and 
other extensions within X.509. 509</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial size=2>needs 
to remain flexible to allow PKIX and other profiles to determine their own 
requirements for such combinations.</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial size=2>As for 
the definition of a CA, in addition to issuing certificates it has 
responsibility for certificate revocation, which it may perform directly or 
delegate to another 'authority/entity'. If that delegation can be to an entity 
other than an authority, then you still have a schema problem regardless of what 
you do with the ca bit and keyUsage. </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001>Taking a step back at what is 'technically important'. 
A cert issued for purposes of cert signature verification contains at least the 
ca bit set and the keyUsage keyCertSign. A cert issued for purposes of verifying 
the signature on a CRL contains at least the digitalSignature and cRLSign bits 
of keyUsage.&nbsp;If a CRL is to be issued by an entity other the CA that issues 
the certificate, then there needs to be a way to identify that delegation with 
integrity. If the crlDistributionPoints extension is in the certificate, this 
can be done by populating the cRLIssuer field and that value needs to correspond 
with the issuer name of the CRL being used (and the other requirements outlined 
so nicely by </SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001>Santosh in Annex B of 509 also need to be met of 
course).&nbsp;Other mechanisms could also be used. As for the schema, there was 
no problem with the&nbsp;PKI schema components as long as the crl issuers were 
also CAs(except that the requirement for the CA bit to be set in all cases 
should probably be removed).&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001>Assuming PKIX reaches consensus on wanting entities 
other than authorities to issue crls, then additional schema work&nbsp;is at 
least needed and some re-writing of text in 509 to permit that&nbsp;would also 
be needed. Hoyt and I have already&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001>started working on a proposed draft defect report for 
that text, in anticipation of that consensus, but we haven't 
looked</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001>at schema implications yet. 
&nbsp;&nbsp;</SPAN></FONT></FONT></FONT><FONT face=Arial><FONT size=2><FONT 
color=#0000ff><SPAN 
class=786041614-26042001>&nbsp;&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV><SPAN class=786041614-26042001><FONT color=#0000ff face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=786041614-26042001></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=786041614-26042001><FONT color=#0000ff 
face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=786041614-26042001>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Santosh Chokhani [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 
26, 2001 9:53 AM<BR><B>To:</B> David A. Cooper; 
[e-mail]<BR><B>Subject:</B> RE: keyCertSign and cRLSign Key Usage 
Bits<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=04585913-26042001>Dave:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=04585913-26042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=04585913-26042001>My 
  opinion are based on the fact that the current X.509 text says that CA issues 
  CRLs.&nbsp; Thus, if the key is used to sign the CRL, it is a CA and hence the 
  caCertificate.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=04585913-26042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=04585913-26042001>I 
  think this is not a security issue (in my mind).&nbsp; We need to make sure 
  that the X.509 language and ldap schema align.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=04585913-26042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=04585913-26042001>I 
  still believe that those clients that do not make checks that are not relevant 
  to security, should be considered compliant.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
  size=2>-----Original Message-----<BR><B>From:</B> David A. Cooper 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 26, 2001 9:37 
  AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> RE: keyCertSign and 
  cRLSign Key Usage Bits<BR><BR></FONT></DIV>Santosh,<BR><BR>I think you bring 
  up an interesting issue with the LDAP schema no matter what we do. As I 
  pointed out yesterday, a CA may have a key pair that it only uses for PKI 
  transaction messages. A certificate that includes the public key from this key 
  pair would only have the digitalSignature KeyUsage bit set. The proposed text 
  below states that the cA bit in basicConstraints should not be set. So, we 
  would still have cases in which a certificate has been issued to a CA and 
  either basicConstraints is absent or cA is set to false. (Technically, 
  according to RFC 2587, we are OK if basicConstraints is absent, but this isn't 
  really a good way out of the problem). A CA may also be issued a certificate 
  in which the public key is intended to be used for key management. Same 
  problem.<BR><BR>I asked yesterday what the meaning of the cA bit was. X.509 
  states that "[t]he <FONT size=2>cA</FONT> component indicates if the certified 
  public key may be used to verify certificate signatures." Do we intend to 
  change X.509 and PKIX to state that the cA bit should be set whenever the 
  subject is a CA? If not, then the LDAP schema will need to deal with 
  certificates issued to CAs in which either basicConstraints is absent or is 
  present with cA set to FALSE. If so, then we need to change the text to 
  eliminate any tying between the cA bit and the contents of KeyUsage.<BR><BR>If 
  we want to go with the proposed text below, then we will need to change both 
  X.509 and PKIX to state that "the cA component indicates if the certified 
  public key may be used to verify certificate or CRL signatures". We will also 
  need to do something about the awkward connection between the cA bit and CRLs. 
  Currently the text states that the cA bit should be set if the CRL issuing 
  subject is issuing CRLs that cover public key certificates, but not attribute 
  certificates. It further states that " 
  <BLOCKQUOTE><FONT size=2>AA certificates MUST NOT be used to verify 
    signatures on CRLs containing revocation information for public key 
    certificates". The problem is that, even if a single entity is not allowed 
    to issued both public key certificates and attribute certificates, there is 
    the possibility that a single, indirect CRL could cover both types of 
    certificates. If one is using a CRL to check the status of a public key 
    certificate, then it is clear that the text below requires that the 
    certificate containing the key needed to verify the CRL signature must have 
    the cA bit set. But what about when one is using a CRL to check the status 
    of an attribute certificate? The quote text seem to suggest that, if the cA 
    bit is not set in the certificate, the relying party is required to verify 
    that the CRL does not contain any revocation information for public key 
    certificates. I can't imagine that there was any intention to impose such a 
    requirement, but that is what the text seems to 
  say.<BR><BR></FONT></BLOCKQUOTE>I think I have made my own opinion on this 
  topic clear. X.509 does not state that the cA bit in basicConstraints should 
  be set if the subject is a CA, it states that the bit should be set if the 
  certified public key may be used to verify certificate signatures. The two are 
  not synonymous.&nbsp; If we change the standard to state that the cA bit 
  indicates whether the subject is a CA, it may solve the LDAP schema problem, 
  but it will require that the remove any dependencies between the cA bit and 
  the KeyUsage extension.<BR><BR>As Tony said yesterday, we need to go back and 
  clearly define the terms we are using. X.509 defines a CA as an entity that 
  issues public key certificates. Is this the correct definition? Or is a CA an 
  entity that issues public key certificates or CRLs that provide revocation 
  information about public key certificates? Or it is something else? Does the 
  cA bit indicate if the certified public key can be used to verify signatures 
  on certificates, as X.509 states, or does it indicate that the subject is a 
  CA, or something else? If we can't get agreement that the standard means what 
  it says, how can we expect people to understand the 
  standard?<BR><BR>Dave<BR><BR>At 08:20 AM 4/26/01 -0400, Santosh Chokhani 
  wrote:<BR><FONT color=#0000ff face=arial size=2>
  <BLOCKQUOTE cite type="cite">Steve:</FONT><BR>&nbsp;<BR><FONT color=#0000ff 
    face=arial size=2>My rationale is as follows: There is no security benefit 
    to checking the bit.&nbsp; The basic constraints and associated path length 
    may determine whether a CA can create a CA or not.&nbsp; But, that is only 
    useful for certificate path and since keyCertSign bit will not be set, the 
    entity will NOT be able to create new CAs.</FONT><BR>&nbsp;<BR><FONT 
    color=#0000ff face=arial size=2>So, I think check is not relevant from 
    security viewpoint.</FONT><BR>&nbsp;<BR><FONT color=#0000ff face=arial 
    size=2>Now, it may break some of the language (again not security) in ldap 
    schema if we populate the certificate in caCertificate or 
    crossCertificatePair and do not set the basic 
    constraints.</FONT><BR>&nbsp;<BR><FONT color=#0000ff face=arial size=2>So, 
    it is a mixed bag.&nbsp; I still think we should ask for the CAs to set the 
    basic constraint bit so the ldap schema does not get screwed up and NOT 
    require the client to check the bit.&nbsp; My rule on clients is 
    simple.&nbsp; Maximize security and interoperability.&nbsp; Make all checks 
    that are security relevant and no more and that will lead to greater 
    interoperability.</FONT><BR>&nbsp;<BR>&nbsp;<BR><FONT 
    face="Times New Roman, Times" size=2>-----Original 
    Message-----<BR><B>From:</B> Stephen Kent [<A href="mailto:[e-mail]" 
    eudora="autourl">mailto:[e-mail]</A>]<BR><B>Sent:</B> Wednesday, April 
    25, 2001 3:51 PM<BR><B>To:</B> Ambarish Malpani<BR><B>Cc:</B> 
    [e-mail]<BR><B>Subject:</B> RE: keyCertSign and cRLSign Key Usage 
    Bits<BR><BR></FONT>At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:<BR>
    <BLOCKQUOTE cite type="cite"><BR><FONT color=#0000ff face=arial size=2>I 
      agree, also.<BR><BR>Ambarish</FONT></BLOCKQUOTE><BR>I disagree. We need to 
    make a decision on whether a cert without a CA flag enabled can sign CRLs. 
    If so, then we need to modify a lot of text in 2459, and in X.509, to say 
    this clearly. Suggesting that a client be "forgiving" in this context is not 
    a viable proposal for a standard.<BR><BR>Steve<BR>
    <BLOCKQUOTE cite type="cite"><BR>&nbsp;<BR><FONT 
      size=2>---------------------------------------------------------------------<BR>Ambarish 
      Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      650.567.5457<BR>ValiCert, 
      Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      [e-mail]<BR>339 N. Bernardo 
      Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      </FONT><A href="http://www.valicert.com/"><FONT 
      size=2>http://www.valicert.com</A><BR>Mountain View, CA 94043</FONT> 
      <BLOCKQUOTE><FONT face=tahoma size=2>
        <DL>
          <DD>-----Original Message----- 
          <DD>From:</B> Santosh Chokhani [<A href="mailto:[e-mail]" 
          eudora="autourl">mailto:[e-mail]</A>] 
          <DD>Sent:</B> Tuesday, April 24, 2001 8:22 AM 
          <DD>To:</B> Housley, Russ; [e-mail] 
          <DD>Subject:</B> RE: keyCertSign and cRLSign Key Usage 
          Bits</FONT><BR><BR>
          <DD>Russ: I agree with the text.<BR><BR>
          <DD>I also know that Steve Kent and Sharon Boeyen feel that X.509 
          states that only CA can issue CRL (the context of my comments being 
          PKI only and not PMI).<BR><BR>
          <DD>But, using the theory that you suggest that the client be 
          forgiving, I would consider a client compliant if it did NOT check the 
          basic constraint extension while verifying a signature on a CRL.&nbsp; 
          It need to ensure that the cRLSign bit is set in the keyUsage 
          extension.<BR><BR>
          <DD>-----Original Message----- 
          <DD>From: Housley, Russ [<A 
          href="mailto:[e-mail]">mailto:[e-mail]</A>] 

          <DD>Sent: Tuesday, April 24, 2001 10:37 AM 
          <DD>To: [e-mail] 
          <DD>Subject: keyCertSign and cRLSign Key Usage Bits<BR><BR><BR><BR>
          <DD>The consensus on these bits is not totally clear to me.&nbsp; Yet, 
          several 
          <DD>points have been consistently, and I think that the following text 

          <DD>incorporates them.&nbsp; The debate regarding he linkage between 
          these bits and 
          <DD>the cA bit in the basic constraints extension does not seem to be 
          over, and 
          <DD>I have not made any changes in that area.&nbsp; Please use this 
          new thread to 
          <DD>discuss any remaining unresolved points.<BR><BR>
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The keyCertSign bit is 
          asserted when the subject public key is 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for verifying a 
          signature on public key certificates.&nbsp; This 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit MUST only be asserted in 
          CA certificates.&nbsp; If the keyCertSign 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit is asserted, then the cA 
          bit in the basic constraints 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension (see 4.2.1.10) MUST 
          also be asserted.&nbsp; If neither the 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the 
          keyCertSign bit are asserted, then the cA bit 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic constraints 
          extension MUST NOT be asserted.<BR><BR>
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign bit is asserted 
          when the subject public key is used 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for verifying a signature on 
          a certificate revocation list (e.g., 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CRL or an ARL).&nbsp; This 
          bit MUST be asserted in CA and Attribute 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authority (AA) certificates 
          that are used to verify signatures on 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRLs.&nbsp; If the cRLSign 
          bit is asserted in a CA certificate, then 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cA bit in the basic 
          constraints extension (see 4.2.1.10) MUST 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; also be asserted.&nbsp; If 
          the cRLSign bit is asserted in a AA 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate, then the cA bit 
          in the basic constraints extension 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST NOT be asserted.&nbsp; 
          Such AA certificates MUST NOT be used to 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify signatures on CRLs 
          containing revocation information for 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public key certificates; 
          however, these AA certificates MAY be 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify signatures on 
          CRLs containing revocation 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information concerning 
          attribute certificates.&nbsp; If neither the 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the 
          keyCertSign bit are asserted, then the cA bit 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic constraints 
          extension MUST NOT be asserted.<BR><BR>
          <DD>Russ 
</DD></DL></BLOCKQUOTE></BLOCKQUOTE><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0CE61.55A85A60--


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA16434 for <[e-mail]>; Thu, 26 Apr 2001 07:53:22 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <J432X6KM>; Thu, 26 Apr 2001 10:52:52 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: "'Tony Bartoletti'" <[e-mail]>, "David A. Cooper" <[e-mail]>, [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)
Date: Thu, 26 Apr 2001 10:46:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE5F.BF5BE6E0"

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_01C0CE5F.BF5BE6E0
Content-Type: text/plain

Hi Tom,

Quite honestly I think the text for the schema was written when we all
envisioned 
CAs issuing CRLs for the certificates they issued. Anything else (like
indirect or 
non CA issuers) wasn't at the forefront of our minds when we labored over
that text.

That was such a long long long debate that when we reached words that nobody
objected
strongly to, I think we were all just happy to have it done. We focused so
much on the 
which certs go where between self issued and non self-issued that CRL
signing was 
not a key contributor to at least my thought process :-( I suspect that
needs revisting.

Sharon 

> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: Thursday, April 26, 2001 10:01 AM
> To: Sharon Boeyen
> Cc: 'Tony Bartoletti'; David A. Cooper; [e-mail]
> Subject: RE: cA flag and CRL issuers (was Re: Last Call:
> draft-ietf-pkix-new-part1-06.txt comments)
> 
> 
> 
>      Thanks for clearing that up.  On a related subject, do 
> self-issued
> (i.e. having the same issuer and subject name, but not self-signed)
> CRL-signing certificates get published in the directory's 
> caCertificate
> attribute or the userCertificate one?  How about other 
> certificates issued
> with the same subject DN as the CA certificate?
> 
>           Tom Gindin
> 
> 
> Sharon Boeyen <[e-mail]> on 04/25/2001 03:34:33 PM
> 
> To:   "'Tony Bartoletti'" <[e-mail]>, "David A. Cooper"
>       <[e-mail]>, [e-mail]
> cc:
> Subject:  RE: cA flag and CRL issuers (was Re: Last Call:   
> draft-ietf-pkix
>       -new-part1-06.txt comments)
> 
> 
> Tony, since PKIX profiles 509, here are answers from that 
> standard. While
> PKIX may
> use different language to describe these, they should still 
> be aligned with
> the
> basic definitions.
> 
> 
> Hope that helps
> Sharon
> 
> 
> > -----Original Message-----
> > From: Tony Bartoletti [mailto:[e-mail]]
> > Sent: Wednesday, April 25, 2001 2:54 PM
> > To: David A. Cooper; [e-mail]
> > Subject: Re: cA flag and CRL issuers (was Re: Last Call:
> > draft-ietf-pkix-new-part1-06.txt comments)
> >
> >
> > All,
> >
> > In trying to parse this issue (and Russ Housley's previous
> > proposed text) it
> > appears that terminology needs a bit of shoring up, at least for me.
> >
> > Can anyone answer these "simple" questions?
> >
> > 1.  Is a "CA Certificate" defined to be:
> >
> >      a.  A certificate whose subject is a CA
> >      b.  A certificate with "cA" bit set.
> >      c.  A certificate with either kCertSign or cRLSign set?
> >
> >          (Are (a) and (b) equivalent "if its a CA certificate"?)
> 
> 
> Clause 7 "A CA-certificate is a certificate issued by a CA to 
> a subject
> that is itslef a CA and therefore is capable of issuing public-key
> certificates." It then goes on to define the different types of
> CA-certificate (Self issued, Self signed and cross).
> 
> 
> No a) and b) are not strictly equivalent. Clause 8.4.2.1 on basic
> constraints "...with the certified public key being used to verify
> certificate signatures", that's the key to use of that bit in the
> extension.
> 
> 
> >
> > 2.  Is the term "public key certificate" intended to represent:
> >
> >      a.  Only certificates that bind keys to "DN/Identity"
> >      b.  Certificates that bind keys to anything (e.g., 
> "attributes")
> >
> >      For instance, is an "Attribute Certificate" considered to be a
> >      subset of "public key certificates", or not?
> 
> 
> No, attribute certificates are not subsets of public-key 
> certificates. They
> are
> 'certificates' but do NOT contain a public-key and are therefore not a
> subset.
> (see 3.3.1 and 3.3.4.4)
> >
> > 3.  Is an "AA" considered to be:
> >
> >      a.  A "CA that certifies attributes and not DN/Identity",
> >          (yet still a CA, since they author/authorize certificates.)
> >      b.  Not a CA, since the term CA is "reserved" to "DN/Identity"
> >
> 
> 
> No an AA is not a CA of any sort. CA is an authority for public-key
> certificates only and AA is an authority for attribute 
> certificates only
> (see 3.3.2 and 3.3.16. The term 'authority' used alone is defined to
> include
> both (see 3.3.6).
> 
> 
> > 4.  Is an "AA Certificate" a form of "CA Certificate" or not?
> >      (Answer should be derived from response to (3).
> 
> 
> No. (as per response to 3)
> >
> > 5.  If both "CRLs and ARLs" are examples of "certificate
> > revocation lists"
> >      then is an ARL:
> >
> >      a.  An instance of CRL (that happens not to revoke any
> > DN/ID certs)?
> >      b.  Never a CRL, since every CRL involves DN/ID certificates?
> 
> 
> Actually 509 added specific acronyms for each type of CRL. What used
> to be called an "ARL" (Authority Revocation List) is now a "CARL"
> Certification Authority Revocation List) and is a revocation list of
> public-key
> certificates issued to CAs that are no longer considered valid by the
> certificate issuer (3.3.17). The equivalent of that for attribute
> authorities
> would be an AARL (Attribute Authority Revocation List)as 
> defined in 3.3.3.
> 
> 
> >
> > I submit that more than half of the dialogs/debates on this list can
> > be traced to confusion regarding these fundamental terms.
> >
> > ___tony___
> >
> >
> > At 01:25 PM 4/25/01 -0400, David A. Cooper wrote:
> > >Steve,
> > >
> > >If we are going to change PKIX to require the cA bit in
> > basicConstraints
> > >to be set even when the subject public key can only be used
> > to verify
> > >signatures on CRLs, then we need to be sure that the text
> > clearly explains
> > >to readers when the cA bit should or should not be set. Currently
> > >new-part1-06 states that "[t]he cA bit indicates if the
> > certified public
> > >key may be used to verify signatures on other certificates."
> > The clearly
> > >is not accurate, since if the cA bit is set one still does not know
> > >whether the subject public key may be used to verify signatures on
> > >certificates. One must look at the keyUsage extension to make that
> > >determination.
> > >
> > >I think it would be helpful to the discussion that we are
> > having if you
> > >would clearly state your interpretation of the meaning of
> > the cA bit in
> > >basicConstraints.
> > >
> > >  From what I have read so far, it appears that you believe
> > that the cA
> > > bit should be used to indicate if the subject of the
> > certificate is a CA.
> > > But, if this is the case, then new-part1-06 still does not
> > accurately
> > > reflect your notion of the cA bit. Currently the text
> > states that the cA
> > > bit may only be set if the keyCertSign bit or the cRLSign
> > bit in keyUsage
> > > is set. However, a CA does more than just issue
> > certificates and CRLs. A
> > > CA may have a private key dedicated to signing PKI
> > transaction messages
> > > (e.g., certification response, revocation response,
> > proof-of-possession
> > > challenge). If a certificate were issued to a CA with its
> > PKI transaction
> > > message verification key as the subject public key, neither the
> > > keyCertSign nor the cRLSign bit in KeyUsage would be set,
> > but the subject
> > > of the certificate would still be a CA.
> > >
> > >So, should the cA bit be used to indicate if the certificate
> > subject is a
> > >CA or to indicate that the subject public key may be used to verify
> > >signatures on certificates and/or CRLs? If the latter, then not all
> > >certificates issued to CAs will have the cA bit set.
> > >
> > >Dave
> > >
> > >At 01:31 PM 4/20/01 -0400, Stephen Kent wrote:
> > > >>The description of basic constraints in X.509 further
> > supports the idea
> > > that the cA bit is used to specify certificate issuing, not
> > certificate
> > > and/or CRL issuing:
> > > >>
> > > >>"This field indicates if the subject may act as a CA, with the
> > > certified public key being used to verify certificate
> > signatures. ... The
> > > cA component indicates if the certified public key may be
> > used to verify
> > > certificate signatures. ... if the value of cA is not set to
> > true then the
> > > certified public key shall not be used to verify a
> > certificate signature"
> > > >>
> > > >>
> > > >>pkix-new-part1-05 states something similar:
> > > >>
> > > >>"The cA bit indicates if the certified public key may be
> > used to verify
> > > signatures on other certificates. If the cA bit is
> > asserted, then the
> > > keyCertSign bit in the key usage extension (see 4.2.1.3)
> > MUST also be
> > > asserted. If the cA bit is not asserted, then the
> > keyCertSign bit in the
> > > key usage extension MUST NOT be asserted."
> > > >
> > > >again, this supports the notion that a CA signs certs, 
> but it says
> > > nothing about whether a CA or some other entity signs 
> CRLs. We have
> > > uncovered a number of instances where less than perfect
> > wording has lead
> > > to confusion and our recent dialogue suggests that some of
> > the quotes you
> > > cite are examples of this.
> >
> > Tony Bartoletti 925-422-3881 <[e-mail]>
> > Information Operations, Warfare and Assurance Center
> > Lawrence Livermore National Laboratory
> > Livermore, CA 94551-9900
> >
> >
> >
> >
> 
> 
> 

------_=_NextPart_001_01C0CE5F.BF5BE6E0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Tom,</FONT>
</P>

<P><FONT SIZE=2>Quite honestly I think the text for the schema was written when we all envisioned </FONT>
<BR><FONT SIZE=2>CAs issuing CRLs for the certificates they issued. Anything else (like indirect or </FONT>
<BR><FONT SIZE=2>non CA issuers) wasn't at the forefront of our minds when we labored over that text.</FONT>
</P>

<P><FONT SIZE=2>That was such a long long long debate that when we reached words that nobody objected</FONT>
<BR><FONT SIZE=2>strongly to, I think we were all just happy to have it done. We focused so much on the </FONT>
<BR><FONT SIZE=2>which certs go where between self issued and non self-issued that CRL signing was </FONT>
<BR><FONT SIZE=2>not a key contributor to at least my thought process :-( I suspect that needs revisting.</FONT>
</P>

<P><FONT SIZE=2>Sharon </FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Tom Gindin [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, April 26, 2001 10:01 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'Tony Bartoletti'; David A. Cooper; [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: cA flag and CRL issuers (was Re: Last Call:</FONT>
<BR><FONT SIZE=2>&gt; draft-ietf-pkix-new-part1-06.txt comments)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thanks for clearing that up.&nbsp; On a related subject, do </FONT>
<BR><FONT SIZE=2>&gt; self-issued</FONT>
<BR><FONT SIZE=2>&gt; (i.e. having the same issuer and subject name, but not self-signed)</FONT>
<BR><FONT SIZE=2>&gt; CRL-signing certificates get published in the directory's </FONT>
<BR><FONT SIZE=2>&gt; caCertificate</FONT>
<BR><FONT SIZE=2>&gt; attribute or the userCertificate one?&nbsp; How about other </FONT>
<BR><FONT SIZE=2>&gt; certificates issued</FONT>
<BR><FONT SIZE=2>&gt; with the same subject DN as the CA certificate?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom Gindin</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sharon Boeyen &lt;[e-mail]&gt; on 04/25/2001 03:34:33 PM</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; To:&nbsp;&nbsp; &quot;'Tony Bartoletti'&quot; &lt;[e-mail]&gt;, &quot;David A. Cooper&quot;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;[e-mail]&gt;, [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; cc:</FONT>
<BR><FONT SIZE=2>&gt; Subject:&nbsp; RE: cA flag and CRL issuers (was Re: Last Call:&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; draft-ietf-pkix</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -new-part1-06.txt comments)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tony, since PKIX profiles 509, here are answers from that </FONT>
<BR><FONT SIZE=2>&gt; standard. While</FONT>
<BR><FONT SIZE=2>&gt; PKIX may</FONT>
<BR><FONT SIZE=2>&gt; use different language to describe these, they should still </FONT>
<BR><FONT SIZE=2>&gt; be aligned with</FONT>
<BR><FONT SIZE=2>&gt; the</FONT>
<BR><FONT SIZE=2>&gt; basic definitions.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hope that helps</FONT>
<BR><FONT SIZE=2>&gt; Sharon</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Tony Bartoletti [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Wednesday, April 25, 2001 2:54 PM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: David A. Cooper; [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: Re: cA flag and CRL issuers (was Re: Last Call:</FONT>
<BR><FONT SIZE=2>&gt; &gt; draft-ietf-pkix-new-part1-06.txt comments)</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; All,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; In trying to parse this issue (and Russ Housley's previous</FONT>
<BR><FONT SIZE=2>&gt; &gt; proposed text) it</FONT>
<BR><FONT SIZE=2>&gt; &gt; appears that terminology needs a bit of shoring up, at least for me.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Can anyone answer these &quot;simple&quot; questions?</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 1.&nbsp; Is a &quot;CA Certificate&quot; defined to be:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.&nbsp; A certificate whose subject is a CA</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.&nbsp; A certificate with &quot;cA&quot; bit set.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c.&nbsp; A certificate with either kCertSign or cRLSign set?</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Are (a) and (b) equivalent &quot;if its a CA certificate&quot;?)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Clause 7 &quot;A CA-certificate is a certificate issued by a CA to </FONT>
<BR><FONT SIZE=2>&gt; a subject</FONT>
<BR><FONT SIZE=2>&gt; that is itslef a CA and therefore is capable of issuing public-key</FONT>
<BR><FONT SIZE=2>&gt; certificates.&quot; It then goes on to define the different types of</FONT>
<BR><FONT SIZE=2>&gt; CA-certificate (Self issued, Self signed and cross).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No a) and b) are not strictly equivalent. Clause 8.4.2.1 on basic</FONT>
<BR><FONT SIZE=2>&gt; constraints &quot;...with the certified public key being used to verify</FONT>
<BR><FONT SIZE=2>&gt; certificate signatures&quot;, that's the key to use of that bit in the</FONT>
<BR><FONT SIZE=2>&gt; extension.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 2.&nbsp; Is the term &quot;public key certificate&quot; intended to represent:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.&nbsp; Only certificates that bind keys to &quot;DN/Identity&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.&nbsp; Certificates that bind keys to anything (e.g., </FONT>
<BR><FONT SIZE=2>&gt; &quot;attributes&quot;)</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For instance, is an &quot;Attribute Certificate&quot; considered to be a</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; subset of &quot;public key certificates&quot;, or not?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No, attribute certificates are not subsets of public-key </FONT>
<BR><FONT SIZE=2>&gt; certificates. They</FONT>
<BR><FONT SIZE=2>&gt; are</FONT>
<BR><FONT SIZE=2>&gt; 'certificates' but do NOT contain a public-key and are therefore not a</FONT>
<BR><FONT SIZE=2>&gt; subset.</FONT>
<BR><FONT SIZE=2>&gt; (see 3.3.1 and 3.3.4.4)</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 3.&nbsp; Is an &quot;AA&quot; considered to be:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.&nbsp; A &quot;CA that certifies attributes and not DN/Identity&quot;,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (yet still a CA, since they author/authorize certificates.)</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.&nbsp; Not a CA, since the term CA is &quot;reserved&quot; to &quot;DN/Identity&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No an AA is not a CA of any sort. CA is an authority for public-key</FONT>
<BR><FONT SIZE=2>&gt; certificates only and AA is an authority for attribute </FONT>
<BR><FONT SIZE=2>&gt; certificates only</FONT>
<BR><FONT SIZE=2>&gt; (see 3.3.2 and 3.3.16. The term 'authority' used alone is defined to</FONT>
<BR><FONT SIZE=2>&gt; include</FONT>
<BR><FONT SIZE=2>&gt; both (see 3.3.6).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 4.&nbsp; Is an &quot;AA Certificate&quot; a form of &quot;CA Certificate&quot; or not?</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Answer should be derived from response to (3).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No. (as per response to 3)</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 5.&nbsp; If both &quot;CRLs and ARLs&quot; are examples of &quot;certificate</FONT>
<BR><FONT SIZE=2>&gt; &gt; revocation lists&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; then is an ARL:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.&nbsp; An instance of CRL (that happens not to revoke any</FONT>
<BR><FONT SIZE=2>&gt; &gt; DN/ID certs)?</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.&nbsp; Never a CRL, since every CRL involves DN/ID certificates?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Actually 509 added specific acronyms for each type of CRL. What used</FONT>
<BR><FONT SIZE=2>&gt; to be called an &quot;ARL&quot; (Authority Revocation List) is now a &quot;CARL&quot;</FONT>
<BR><FONT SIZE=2>&gt; Certification Authority Revocation List) and is a revocation list of</FONT>
<BR><FONT SIZE=2>&gt; public-key</FONT>
<BR><FONT SIZE=2>&gt; certificates issued to CAs that are no longer considered valid by the</FONT>
<BR><FONT SIZE=2>&gt; certificate issuer (3.3.17). The equivalent of that for attribute</FONT>
<BR><FONT SIZE=2>&gt; authorities</FONT>
<BR><FONT SIZE=2>&gt; would be an AARL (Attribute Authority Revocation List)as </FONT>
<BR><FONT SIZE=2>&gt; defined in 3.3.3.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; I submit that more than half of the dialogs/debates on this list can</FONT>
<BR><FONT SIZE=2>&gt; &gt; be traced to confusion regarding these fundamental terms.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; ___tony___</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; At 01:25 PM 4/25/01 -0400, David A. Cooper wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Steve,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;If we are going to change PKIX to require the cA bit in</FONT>
<BR><FONT SIZE=2>&gt; &gt; basicConstraints</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;to be set even when the subject public key can only be used</FONT>
<BR><FONT SIZE=2>&gt; &gt; to verify</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;signatures on CRLs, then we need to be sure that the text</FONT>
<BR><FONT SIZE=2>&gt; &gt; clearly explains</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;to readers when the cA bit should or should not be set. Currently</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;new-part1-06 states that &quot;[t]he cA bit indicates if the</FONT>
<BR><FONT SIZE=2>&gt; &gt; certified public</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;key may be used to verify signatures on other certificates.&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; The clearly</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;is not accurate, since if the cA bit is set one still does not know</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;whether the subject public key may be used to verify signatures on</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;certificates. One must look at the keyUsage extension to make that</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;determination.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;I think it would be helpful to the discussion that we are</FONT>
<BR><FONT SIZE=2>&gt; &gt; having if you</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;would clearly state your interpretation of the meaning of</FONT>
<BR><FONT SIZE=2>&gt; &gt; the cA bit in</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;basicConstraints.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp; From what I have read so far, it appears that you believe</FONT>
<BR><FONT SIZE=2>&gt; &gt; that the cA</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; bit should be used to indicate if the subject of the</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate is a CA.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; But, if this is the case, then new-part1-06 still does not</FONT>
<BR><FONT SIZE=2>&gt; &gt; accurately</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; reflect your notion of the cA bit. Currently the text</FONT>
<BR><FONT SIZE=2>&gt; &gt; states that the cA</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; bit may only be set if the keyCertSign bit or the cRLSign</FONT>
<BR><FONT SIZE=2>&gt; &gt; bit in keyUsage</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; is set. However, a CA does more than just issue</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificates and CRLs. A</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; CA may have a private key dedicated to signing PKI</FONT>
<BR><FONT SIZE=2>&gt; &gt; transaction messages</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; (e.g., certification response, revocation response,</FONT>
<BR><FONT SIZE=2>&gt; &gt; proof-of-possession</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; challenge). If a certificate were issued to a CA with its</FONT>
<BR><FONT SIZE=2>&gt; &gt; PKI transaction</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; message verification key as the subject public key, neither the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; keyCertSign nor the cRLSign bit in KeyUsage would be set,</FONT>
<BR><FONT SIZE=2>&gt; &gt; but the subject</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; of the certificate would still be a CA.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;So, should the cA bit be used to indicate if the certificate</FONT>
<BR><FONT SIZE=2>&gt; &gt; subject is a</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;CA or to indicate that the subject public key may be used to verify</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;signatures on certificates and/or CRLs? If the latter, then not all</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;certificates issued to CAs will have the cA bit set.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Dave</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;At 01:31 PM 4/20/01 -0400, Stephen Kent wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&gt;The description of basic constraints in X.509 further</FONT>
<BR><FONT SIZE=2>&gt; &gt; supports the idea</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; that the cA bit is used to specify certificate issuing, not</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; and/or CRL issuing:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&gt;&quot;This field indicates if the subject may act as a CA, with the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; certified public key being used to verify certificate</FONT>
<BR><FONT SIZE=2>&gt; &gt; signatures. ... The</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; cA component indicates if the certified public key may be</FONT>
<BR><FONT SIZE=2>&gt; &gt; used to verify</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; certificate signatures. ... if the value of cA is not set to</FONT>
<BR><FONT SIZE=2>&gt; &gt; true then the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; certified public key shall not be used to verify a</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate signature&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&gt;pkix-new-part1-05 states something similar:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&gt;&quot;The cA bit indicates if the certified public key may be</FONT>
<BR><FONT SIZE=2>&gt; &gt; used to verify</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; signatures on other certificates. If the cA bit is</FONT>
<BR><FONT SIZE=2>&gt; &gt; asserted, then the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; keyCertSign bit in the key usage extension (see 4.2.1.3)</FONT>
<BR><FONT SIZE=2>&gt; &gt; MUST also be</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; asserted. If the cA bit is not asserted, then the</FONT>
<BR><FONT SIZE=2>&gt; &gt; keyCertSign bit in the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; key usage extension MUST NOT be asserted.&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;again, this supports the notion that a CA signs certs, </FONT>
<BR><FONT SIZE=2>&gt; but it says</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; nothing about whether a CA or some other entity signs </FONT>
<BR><FONT SIZE=2>&gt; CRLs. We have</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; uncovered a number of instances where less than perfect</FONT>
<BR><FONT SIZE=2>&gt; &gt; wording has lead</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; to confusion and our recent dialogue suggests that some of</FONT>
<BR><FONT SIZE=2>&gt; &gt; the quotes you</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; cite are examples of this.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Tony Bartoletti 925-422-3881 &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Information Operations, Warfare and Assurance Center</FONT>
<BR><FONT SIZE=2>&gt; &gt; Lawrence Livermore National Laboratory</FONT>
<BR><FONT SIZE=2>&gt; &gt; Livermore, CA 94551-9900</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CE5F.BF5BE6E0--


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA16085 for <[e-mail]>; Thu, 26 Apr 2001 07:48:08 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <J432X6JW>; Thu, 26 Apr 2001 10:47:39 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "David A. Cooper" <[e-mail]>, [e-mail]
Cc: "Hoyt Kesterson (E-mail)" <[e-mail]>
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Date: Thu, 26 Apr 2001 10:41:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE5F.05F12A80"

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_01C0CE5F.05F12A80
Content-Type: text/plain;
	charset="iso-8859-1"

Santosh I see your point on the schema - actually 509 contains the exact
same text and would also need to 
be modified. I assume that the appropriate change would be to delete the
text that requires the ca bit to be set in 
any cert that goes into the cACertificate attribute. As for the
crossCertificatePair attribute, I guess it would need
to be lifted there as well (assuming a CA would want to issue a cert to
another CA for purposes of verifying signatures
on CRLs but not on certificates)?
 
That raises another point - if we modify all this "stuff" to allow entities
other than authorities to sign CRLs, where 
would those certificates be stored? The subjects aren't CAs so they don't
really belong in either of these attributes. Inventing another attribute and
object class isn't very attractive either. Thoughts?
 
Dave, I realize you weren't suggesting we do this, but I do want to say that
I would not support changing the 
meaning of the ca bit in basic constraints. That is there as one of many
'business controls" that a CA can use to 
ensure that the certificate it issues (containing those constraints), when
used by conforming path validation systems, 
achieves that CAs intended result. That is very specific, very important,
and I wouldn't want to see it generalized. 
Nor would I support requiring any ties between the basicConstraints
extension and other extensions within X.509. 509
needs to remain flexible to allow PKIX and other profiles to determine their
own requirements for such combinations.
 
As for the definition of a CA, in addition to issuing certificates it has
responsibility for certificate revocation, which it may perform directly or
delegate to another 'authority/entity'. If that delegation can be to an
entity other than an authority, then you still have a schema problem
regardless of what you do with the ca bit and keyUsage. 
 
Taking a step back at what is 'technically important'. A cert issued for
purposes of cert signature verification contains at least the ca bit set and
the keyUsage keyCertSign. A cert issued for purposes of verifying the
signature on a CRL contains at least the digitalSignature and cRLSign bits
of keyUsage. If a CRL is to be issued by an entity other the CA that issues
the certificate, then there needs to be a way to identify that delegation
with integrity. If the crlDistributionPoints extension is in the
certificate, this can be done by populating the cRLIssuer field and that
value needs to correspond with the issuer name of the CRL being used (and
the other requirements outlined so nicely by 
Santosh in Annex B of 509 also need to be met of course). Other mechanisms
could also be used. As for the schema, there was no problem with the PKI
schema components as long as the crl issuers were also CAs(except that the
requirement for the CA bit to be set in all cases should probably be
removed). 
 
Assuming PKIX reaches consensus on wanting entities other than authorities
to issue crls, then additional schema work is at least needed and some
re-writing of text in 509 to permit that would also be needed. Hoyt and I
have already 
started working on a proposed draft defect report for that text, in
anticipation of that consensus, but we haven't looked
at schema implications yet.     
 
 
 -----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, April 26, 2001 9:53 AM
To: David A. Cooper; [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits



Dave:
 
My opinion are based on the fact that the current X.509 text says that CA
issues CRLs.  Thus, if the key is used to sign the CRL, it is a CA and hence
the caCertificate.
 
I think this is not a security issue (in my mind).  We need to make sure
that the X.509 language and ldap schema align.
 
I still believe that those clients that do not make checks that are not
relevant to security, should be considered compliant.
 
-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Thursday, April 26, 2001 9:37 AM
To: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits


Santosh,

I think you bring up an interesting issue with the LDAP schema no matter
what we do. As I pointed out yesterday, a CA may have a key pair that it
only uses for PKI transaction messages. A certificate that includes the
public key from this key pair would only have the digitalSignature KeyUsage
bit set. The proposed text below states that the cA bit in basicConstraints
should not be set. So, we would still have cases in which a certificate has
been issued to a CA and either basicConstraints is absent or cA is set to
false. (Technically, according to RFC 2587, we are OK if basicConstraints is
absent, but this isn't really a good way out of the problem). A CA may also
be issued a certificate in which the public key is intended to be used for
key management. Same problem.

I asked yesterday what the meaning of the cA bit was. X.509 states that
"[t]he cA component indicates if the certified public key may be used to
verify certificate signatures." Do we intend to change X.509 and PKIX to
state that the cA bit should be set whenever the subject is a CA? If not,
then the LDAP schema will need to deal with certificates issued to CAs in
which either basicConstraints is absent or is present with cA set to FALSE.
If so, then we need to change the text to eliminate any tying between the cA
bit and the contents of KeyUsage.

If we want to go with the proposed text below, then we will need to change
both X.509 and PKIX to state that "the cA component indicates if the
certified public key may be used to verify certificate or CRL signatures".
We will also need to do something about the awkward connection between the
cA bit and CRLs. Currently the text states that the cA bit should be set if
the CRL issuing subject is issuing CRLs that cover public key certificates,
but not attribute certificates. It further states that " 

AA certificates MUST NOT be used to verify signatures on CRLs containing
revocation information for public key certificates". The problem is that,
even if a single entity is not allowed to issued both public key
certificates and attribute certificates, there is the possibility that a
single, indirect CRL could cover both types of certificates. If one is using
a CRL to check the status of a public key certificate, then it is clear that
the text below requires that the certificate containing the key needed to
verify the CRL signature must have the cA bit set. But what about when one
is using a CRL to check the status of an attribute certificate? The quote
text seem to suggest that, if the cA bit is not set in the certificate, the
relying party is required to verify that the CRL does not contain any
revocation information for public key certificates. I can't imagine that
there was any intention to impose such a requirement, but that is what the
text seems to say.



I think I have made my own opinion on this topic clear. X.509 does not state
that the cA bit in basicConstraints should be set if the subject is a CA, it
states that the bit should be set if the certified public key may be used to
verify certificate signatures. The two are not synonymous.  If we change the
standard to state that the cA bit indicates whether the subject is a CA, it
may solve the LDAP schema problem, but it will require that the remove any
dependencies between the cA bit and the KeyUsage extension.

As Tony said yesterday, we need to go back and clearly define the terms we
are using. X.509 defines a CA as an entity that issues public key
certificates. Is this the correct definition? Or is a CA an entity that
issues public key certificates or CRLs that provide revocation information
about public key certificates? Or it is something else? Does the cA bit
indicate if the certified public key can be used to verify signatures on
certificates, as X.509 states, or does it indicate that the subject is a CA,
or something else? If we can't get agreement that the standard means what it
says, how can we expect people to understand the standard?

Dave

At 08:20 AM 4/26/01 -0400, Santosh Chokhani wrote:


Steve:
 
My rationale is as follows: There is no security benefit to checking the
bit.  The basic constraints and associated path length may determine whether
a CA can create a CA or not.  But, that is only useful for certificate path
and since keyCertSign bit will not be set, the entity will NOT be able to
create new CAs.
 
So, I think check is not relevant from security viewpoint.
 
Now, it may break some of the language (again not security) in ldap schema
if we populate the certificate in caCertificate or crossCertificatePair and
do not set the basic constraints.
 
So, it is a mixed bag.  I still think we should ask for the CAs to set the
basic constraint bit so the ldap schema does not get screwed up and NOT
require the client to check the bit.  My rule on clients is simple.
Maximize security and interoperability.  Make all checks that are security
relevant and no more and that will lead to greater interoperability.
 
 
-----Original Message-----
From: Stephen Kent [ mailto:[e-mail] <mailto:[e-mail]> ]
Sent: Wednesday, April 25, 2001 3:51 PM
To: Ambarish Malpani
Cc: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits

At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:



I agree, also.

Ambarish


I disagree. We need to make a decision on whether a cert without a CA flag
enabled can sign CRLs. If so, then we need to modify a lot of text in 2459,
and in X.509, to say this clearly. Suggesting that a client be "forgiving"
in this context is not a viable proposal for a standard.

Steve



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



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

From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Tuesday, April 24, 2001 8:22 AM 

To: Housley, Russ; [e-mail] 

Subject: RE: keyCertSign and cRLSign Key Usage Bits



Russ: I agree with the text.



I also know that Steve Kent and Sharon Boeyen feel that X.509 states that
only CA can issue CRL (the context of my comments being PKI only and not
PMI).



But, using the theory that you suggest that the client be forgiving, I would
consider a client compliant if it did NOT check the basic constraint
extension while verifying a signature on a CRL.  It need to ensure that the
cRLSign bit is set in the keyUsage extension.



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

From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Tuesday, April 24, 2001 10:37 AM 

To: [e-mail] 

Subject: keyCertSign and cRLSign Key Usage Bits





The consensus on these bits is not totally clear to me.  Yet, several 

points have been consistently, and I think that the following text 

incorporates them.  The debate regarding he linkage between these bits and 

the cA bit in the basic constraints extension does not seem to be over, and 

I have not made any changes in that area.  Please use this new thread to 

discuss any remaining unresolved points.



       The keyCertSign bit is asserted when the subject public key is 

       used for verifying a signature on public key certificates.  This 

       bit MUST only be asserted in CA certificates.  If the keyCertSign 

       bit is asserted, then the cA bit in the basic constraints 

       extension (see 4.2.1.10) MUST also be asserted.  If neither the 

       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit 

       in the basic constraints extension MUST NOT be asserted.



       The cRLSign bit is asserted when the subject public key is used 

       for verifying a signature on a certificate revocation list (e.g., 

       a CRL or an ARL).  This bit MUST be asserted in CA and Attribute 

       Authority (AA) certificates that are used to verify signatures on 

       CRLs.  If the cRLSign bit is asserted in a CA certificate, then 

       the cA bit in the basic constraints extension (see 4.2.1.10) MUST 

       also be asserted.  If the cRLSign bit is asserted in a AA 

       certificate, then the cA bit in the basic constraints extension 

       MUST NOT be asserted.  Such AA certificates MUST NOT be used to 

       verify signatures on CRLs containing revocation information for 

       public key certificates; however, these AA certificates MAY be 

       used to verify signatures on CRLs containing revocation 

       information concerning attribute certificates.  If neither the 

       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit 

       in the basic constraints extension MUST NOT be asserted.



Russ 



------_=_NextPart_001_01C0CE5F.05F12A80
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff 
size=2>Santosh I see your point on the schema - actually 509 contains the exact 
same text and would also need to </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff size=2>be 
modified. I assume that the appropriate change would be to delete the text that 
requires the ca bit to be set in </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff size=2>any 
cert that goes into the cACertificate attribute. As for the crossCertificatePair 
attribute, I guess it would need</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff size=2>to be 
lifted there as well (assuming a CA would want to issue a cert to another CA for 
purposes of verifying signatures</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff size=2>on 
CRLs but not on certificates)?</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff size=2>That 
raises another point - if we modify all this "stuff" to allow entities other 
than authorities to sign CRLs, where </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff size=2>would 
those certificates be stored? The subjects&nbsp;aren't CAs so they don't really 
belong in either of these attributes.</FONT></SPAN><SPAN 
class=786041614-26042001><FONT face=Arial color=#0000ff size=2> 
</FONT></SPAN><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff 
size=2>Inventing another attribute and object class isn't very attractive 
either. Thoughts?</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff size=2>Dave, 
I realize you weren't suggesting we do this, but I do want to say that I would 
not support changing the </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff 
size=2>meaning of the ca bit in basic constraints. That is there as one of many 
'business controls" that a CA can use to </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff size=2>ensure 
that the certificate it issues (containing those constraints), when used by 
conforming path validation systems, </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff 
size=2>achieves that CAs intended result. That is very specific, very important, 
and I wouldn't want to see it generalized. </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff size=2>Nor 
would I support requiring any ties between the basicConstraints extension and 
other extensions within X.509. 509</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff size=2>needs 
to remain flexible to allow PKIX and other profiles to determine their own 
requirements for such combinations.</FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff size=2>As for 
the definition of a CA, in addition to issuing certificates it has 
responsibility for certificate revocation, which it may perform directly or 
delegate to another 'authority/entity'. If that delegation can be to an entity 
other than an authority, then you still have a schema problem regardless of what 
you do with the ca bit and keyUsage. </FONT></SPAN></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001>Taking a step back at what is 'technically important'. 
A cert issued for purposes of cert signature verification contains at least the 
ca bit set and the keyUsage keyCertSign. A cert issued for purposes of verifying 
the signature on a CRL contains at least the digitalSignature and cRLSign bits 
of keyUsage.&nbsp;If a CRL is to be issued by an entity other the CA that issues 
the certificate, then there needs to be a way to identify that delegation with 
integrity. If the crlDistributionPoints extension is in the certificate, this 
can be done by populating the cRLIssuer field and that value needs to correspond 
with the issuer name of the CRL being used (and the other requirements outlined 
so nicely by </SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001>Santosh in Annex B of 509 also need to be met of 
course).&nbsp;Other mechanisms could also be used. As for the schema, there was 
no problem with the&nbsp;PKI schema components as long as the crl issuers were 
also CAs(except that the requirement for the CA bit to be set in all cases 
should probably be removed).&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001>Assuming PKIX reaches consensus on wanting entities 
other than authorities to issue crls, then additional schema work&nbsp;is at 
least needed and some re-writing of text in 509 to permit that&nbsp;would also 
be needed. Hoyt and I have already&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001>started working on a proposed draft defect report for 
that text, in anticipation of that consensus, but we haven't 
looked</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
class=786041614-26042001>at schema implications yet. 
&nbsp;&nbsp;</SPAN></FONT></FONT></FONT><FONT face=Arial><FONT size=2><FONT 
color=#0000ff><SPAN 
class=786041614-26042001>&nbsp;&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV><SPAN class=786041614-26042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=786041614-26042001></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=786041614-26042001><FONT face=Arial 
color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=786041614-26042001>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Santosh Chokhani [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 
26, 2001 9:53 AM<BR><B>To:</B> David A. Cooper; 
[e-mail]<BR><B>Subject:</B> RE: keyCertSign and cRLSign Key Usage 
Bits<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=04585913-26042001>Dave:</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=04585913-26042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=04585913-26042001>My 
  opinion are based on the fact that the current X.509 text says that CA issues 
  CRLs.&nbsp; Thus, if the key is used to sign the CRL, it is a CA and hence the 
  caCertificate.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=04585913-26042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=04585913-26042001>I 
  think this is not a security issue (in my mind).&nbsp; We need to make sure 
  that the X.509 language and ldap schema align.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=04585913-26042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=04585913-26042001>I 
  still believe that those clients that do not make checks that are not relevant 
  to security, should be considered compliant.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
  size=2>-----Original Message-----<BR><B>From:</B> David A. Cooper 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 26, 2001 9:37 
  AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> RE: keyCertSign and 
  cRLSign Key Usage Bits<BR><BR></FONT></DIV>Santosh,<BR><BR>I think you bring 
  up an interesting issue with the LDAP schema no matter what we do. As I 
  pointed out yesterday, a CA may have a key pair that it only uses for PKI 
  transaction messages. A certificate that includes the public key from this key 
  pair would only have the digitalSignature KeyUsage bit set. The proposed text 
  below states that the cA bit in basicConstraints should not be set. So, we 
  would still have cases in which a certificate has been issued to a CA and 
  either basicConstraints is absent or cA is set to false. (Technically, 
  according to RFC 2587, we are OK if basicConstraints is absent, but this isn't 
  really a good way out of the problem). A CA may also be issued a certificate 
  in which the public key is intended to be used for key management. Same 
  problem.<BR><BR>I asked yesterday what the meaning of the cA bit was. X.509 
  states that "[t]he <FONT size=2>cA</FONT> component indicates if the certified 
  public key may be used to verify certificate signatures." Do we intend to 
  change X.509 and PKIX to state that the cA bit should be set whenever the 
  subject is a CA? If not, then the LDAP schema will need to deal with 
  certificates issued to CAs in which either basicConstraints is absent or is 
  present with cA set to FALSE. If so, then we need to change the text to 
  eliminate any tying between the cA bit and the contents of KeyUsage.<BR><BR>If 
  we want to go with the proposed text below, then we will need to change both 
  X.509 and PKIX to state that "the cA component indicates if the certified 
  public key may be used to verify certificate or CRL signatures". We will also 
  need to do something about the awkward connection between the cA bit and CRLs. 
  Currently the text states that the cA bit should be set if the CRL issuing 
  subject is issuing CRLs that cover public key certificates, but not attribute 
  certificates. It further states that " 
  <BLOCKQUOTE><FONT size=2>AA certificates MUST NOT be used to verify 
    signatures on CRLs containing revocation information for public key 
    certificates". The problem is that, even if a single entity is not allowed 
    to issued both public key certificates and attribute certificates, there is 
    the possibility that a single, indirect CRL could cover both types of 
    certificates. If one is using a CRL to check the status of a public key 
    certificate, then it is clear that the text below requires that the 
    certificate containing the key needed to verify the CRL signature must have 
    the cA bit set. But what about when one is using a CRL to check the status 
    of an attribute certificate? The quote text seem to suggest that, if the cA 
    bit is not set in the certificate, the relying party is required to verify 
    that the CRL does not contain any revocation information for public key 
    certificates. I can't imagine that there was any intention to impose such a 
    requirement, but that is what the text seems to 
  say.<BR><BR></FONT></BLOCKQUOTE>I think I have made my own opinion on this 
  topic clear. X.509 does not state that the cA bit in basicConstraints should 
  be set if the subject is a CA, it states that the bit should be set if the 
  certified public key may be used to verify certificate signatures. The two are 
  not synonymous.&nbsp; If we change the standard to state that the cA bit 
  indicates whether the subject is a CA, it may solve the LDAP schema problem, 
  but it will require that the remove any dependencies between the cA bit and 
  the KeyUsage extension.<BR><BR>As Tony said yesterday, we need to go back and 
  clearly define the terms we are using. X.509 defines a CA as an entity that 
  issues public key certificates. Is this the correct definition? Or is a CA an 
  entity that issues public key certificates or CRLs that provide revocation 
  information about public key certificates? Or it is something else? Does the 
  cA bit indicate if the certified public key can be used to verify signatures 
  on certificates, as X.509 states, or does it indicate that the subject is a 
  CA, or something else? If we can't get agreement that the standard means what 
  it says, how can we expect people to understand the 
  standard?<BR><BR>Dave<BR><BR>At 08:20 AM 4/26/01 -0400, Santosh Chokhani 
  wrote:<BR><FONT face=arial color=#0000ff size=2>
  <BLOCKQUOTE type="cite" cite>Steve:</FONT><BR>&nbsp;<BR><FONT face=arial 
    color=#0000ff size=2>My rationale is as follows: There is no security 
    benefit to checking the bit.&nbsp; The basic constraints and associated path 
    length may determine whether a CA can create a CA or not.&nbsp; But, that is 
    only useful for certificate path and since keyCertSign bit will not be set, 
    the entity will NOT be able to create new CAs.</FONT><BR>&nbsp;<BR><FONT 
    face=arial color=#0000ff size=2>So, I think check is not relevant from 
    security viewpoint.</FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff 
    size=2>Now, it may break some of the language (again not security) in ldap 
    schema if we populate the certificate in caCertificate or 
    crossCertificatePair and do not set the basic 
    constraints.</FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff size=2>So, 
    it is a mixed bag.&nbsp; I still think we should ask for the CAs to set the 
    basic constraint bit so the ldap schema does not get screwed up and NOT 
    require the client to check the bit.&nbsp; My rule on clients is 
    simple.&nbsp; Maximize security and interoperability.&nbsp; Make all checks 
    that are security relevant and no more and that will lead to greater 
    interoperability.</FONT><BR>&nbsp;<BR>&nbsp;<BR><FONT 
    face="Times New Roman, Times" size=2>-----Original 
    Message-----<BR><B>From:</B> Stephen Kent [<A href="mailto:[e-mail]" 
    eudora="autourl">mailto:[e-mail]</A>]<BR><B>Sent:</B> Wednesday, April 
    25, 2001 3:51 PM<BR><B>To:</B> Ambarish Malpani<BR><B>Cc:</B> 
    [e-mail]<BR><B>Subject:</B> RE: keyCertSign and cRLSign Key Usage 
    Bits<BR><BR></FONT>At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:<BR>
    <BLOCKQUOTE type="cite" cite><BR><FONT face=arial color=#0000ff size=2>I 
      agree, also.<BR><BR>Ambarish</FONT></BLOCKQUOTE><BR>I disagree. We need to 
    make a decision on whether a cert without a CA flag enabled can sign CRLs. 
    If so, then we need to modify a lot of text in 2459, and in X.509, to say 
    this clearly. Suggesting that a client be "forgiving" in this context is not 
    a viable proposal for a standard.<BR><BR>Steve<BR>
    <BLOCKQUOTE type="cite" cite><BR>&nbsp;<BR><FONT 
      size=2>---------------------------------------------------------------------<BR>Ambarish 
      Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      650.567.5457<BR>ValiCert, 
      Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      [e-mail]<BR>339 N. Bernardo 
      Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      </FONT><A href="http://www.valicert.com/"><FONT 
      size=2>http://www.valicert.com</A><BR>Mountain View, CA 94043</FONT> 
      <BLOCKQUOTE><FONT face=tahoma size=2>
        <DL>
          <DD>-----Original Message----- 
          <DD>From:</B> Santosh Chokhani [<A href="mailto:[e-mail]" 
          eudora="autourl">mailto:[e-mail]</A>] 
          <DD>Sent:</B> Tuesday, April 24, 2001 8:22 AM 
          <DD>To:</B> Housley, Russ; [e-mail] 
          <DD>Subject:</B> RE: keyCertSign and cRLSign Key Usage 
          Bits</FONT><BR><BR>
          <DD>Russ: I agree with the text.<BR><BR>
          <DD>I also know that Steve Kent and Sharon Boeyen feel that X.509 
          states that only CA can issue CRL (the context of my comments being 
          PKI only and not PMI).<BR><BR>
          <DD>But, using the theory that you suggest that the client be 
          forgiving, I would consider a client compliant if it did NOT check the 
          basic constraint extension while verifying a signature on a CRL.&nbsp; 
          It need to ensure that the cRLSign bit is set in the keyUsage 
          extension.<BR><BR>
          <DD>-----Original Message----- 
          <DD>From: Housley, Russ [<A 
          href="mailto:[e-mail]">mailto:[e-mail]</A>] 

          <DD>Sent: Tuesday, April 24, 2001 10:37 AM 
          <DD>To: [e-mail] 
          <DD>Subject: keyCertSign and cRLSign Key Usage Bits<BR><BR><BR><BR>
          <DD>The consensus on these bits is not totally clear to me.&nbsp; Yet, 
          several 
          <DD>points have been consistently, and I think that the following text 

          <DD>incorporates them.&nbsp; The debate regarding he linkage between 
          these bits and 
          <DD>the cA bit in the basic constraints extension does not seem to be 
          over, and 
          <DD>I have not made any changes in that area.&nbsp; Please use this 
          new thread to 
          <DD>discuss any remaining unresolved points.<BR><BR>
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The keyCertSign bit is 
          asserted when the subject public key is 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for verifying a 
          signature on public key certificates.&nbsp; This 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit MUST only be asserted in 
          CA certificates.&nbsp; If the keyCertSign 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit is asserted, then the cA 
          bit in the basic constraints 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension (see 4.2.1.10) MUST 
          also be asserted.&nbsp; If neither the 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the 
          keyCertSign bit are asserted, then the cA bit 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic constraints 
          extension MUST NOT be asserted.<BR><BR>
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign bit is asserted 
          when the subject public key is used 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for verifying a signature on 
          a certificate revocation list (e.g., 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CRL or an ARL).&nbsp; This 
          bit MUST be asserted in CA and Attribute 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authority (AA) certificates 
          that are used to verify signatures on 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRLs.&nbsp; If the cRLSign 
          bit is asserted in a CA certificate, then 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cA bit in the basic 
          constraints extension (see 4.2.1.10) MUST 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; also be asserted.&nbsp; If 
          the cRLSign bit is asserted in a AA 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate, then the cA bit 
          in the basic constraints extension 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST NOT be asserted.&nbsp; 
          Such AA certificates MUST NOT be used to 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify signatures on CRLs 
          containing revocation information for 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public key certificates; 
          however, these AA certificates MAY be 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify signatures on 
          CRLs containing revocation 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information concerning 
          attribute certificates.&nbsp; If neither the 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the 
          keyCertSign bit are asserted, then the cA bit 
          <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic constraints 
          extension MUST NOT be asserted.<BR><BR>
          <DD>Russ 
</DD></DL></BLOCKQUOTE></BLOCKQUOTE><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0CE5F.05F12A80--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA13631 for <[e-mail]>; Thu, 26 Apr 2001 07:02:42 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JV6F5V4R>; Thu, 26 Apr 2001 10:02:12 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "David A. Cooper" <[e-mail]>, [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Date: Thu, 26 Apr 2001 09:53:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE58.3F8CA640"

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_01C0CE58.3F8CA640
Content-Type: text/plain;
	charset="iso-8859-1"

Dave:
 
My opinion are based on the fact that the current X.509 text says that CA
issues CRLs.  Thus, if the key is used to sign the CRL, it is a CA and hence
the caCertificate.
 
I think this is not a security issue (in my mind).  We need to make sure
that the X.509 language and ldap schema align.
 
I still believe that those clients that do not make checks that are not
relevant to security, should be considered compliant.
 
-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Thursday, April 26, 2001 9:37 AM
To: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits


Santosh,

I think you bring up an interesting issue with the LDAP schema no matter
what we do. As I pointed out yesterday, a CA may have a key pair that it
only uses for PKI transaction messages. A certificate that includes the
public key from this key pair would only have the digitalSignature KeyUsage
bit set. The proposed text below states that the cA bit in basicConstraints
should not be set. So, we would still have cases in which a certificate has
been issued to a CA and either basicConstraints is absent or cA is set to
false. (Technically, according to RFC 2587, we are OK if basicConstraints is
absent, but this isn't really a good way out of the problem). A CA may also
be issued a certificate in which the public key is intended to be used for
key management. Same problem.

I asked yesterday what the meaning of the cA bit was. X.509 states that
"[t]he cA component indicates if the certified public key may be used to
verify certificate signatures." Do we intend to change X.509 and PKIX to
state that the cA bit should be set whenever the subject is a CA? If not,
then the LDAP schema will need to deal with certificates issued to CAs in
which either basicConstraints is absent or is present with cA set to FALSE.
If so, then we need to change the text to eliminate any tying between the cA
bit and the contents of KeyUsage.

If we want to go with the proposed text below, then we will need to change
both X.509 and PKIX to state that "the cA component indicates if the
certified public key may be used to verify certificate or CRL signatures".
We will also need to do something about the awkward connection between the
cA bit and CRLs. Currently the text states that the cA bit should be set if
the CRL issuing subject is issuing CRLs that cover public key certificates,
but not attribute certificates. It further states that " 

AA certificates MUST NOT be used to verify signatures on CRLs containing
revocation information for public key certificates". The problem is that,
even if a single entity is not allowed to issued both public key
certificates and attribute certificates, there is the possibility that a
single, indirect CRL could cover both types of certificates. If one is using
a CRL to check the status of a public key certificate, then it is clear that
the text below requires that the certificate containing the key needed to
verify the CRL signature must have the cA bit set. But what about when one
is using a CRL to check the status of an attribute certificate? The quote
text seem to suggest that, if the cA bit is not set in the certificate, the
relying party is required to verify that the CRL does not contain any
revocation information for public key certificates. I can't imagine that
there was any intention to impose such a requirement, but that is what the
text seems to say.



I think I have made my own opinion on this topic clear. X.509 does not state
that the cA bit in basicConstraints should be set if the subject is a CA, it
states that the bit should be set if the certified public key may be used to
verify certificate signatures. The two are not synonymous.  If we change the
standard to state that the cA bit indicates whether the subject is a CA, it
may solve the LDAP schema problem, but it will require that the remove any
dependencies between the cA bit and the KeyUsage extension.

As Tony said yesterday, we need to go back and clearly define the terms we
are using. X.509 defines a CA as an entity that issues public key
certificates. Is this the correct definition? Or is a CA an entity that
issues public key certificates or CRLs that provide revocation information
about public key certificates? Or it is something else? Does the cA bit
indicate if the certified public key can be used to verify signatures on
certificates, as X.509 states, or does it indicate that the subject is a CA,
or something else? If we can't get agreement that the standard means what it
says, how can we expect people to understand the standard?

Dave

At 08:20 AM 4/26/01 -0400, Santosh Chokhani wrote:


Steve:
 
My rationale is as follows: There is no security benefit to checking the
bit.  The basic constraints and associated path length may determine whether
a CA can create a CA or not.  But, that is only useful for certificate path
and since keyCertSign bit will not be set, the entity will NOT be able to
create new CAs.
 
So, I think check is not relevant from security viewpoint.
 
Now, it may break some of the language (again not security) in ldap schema
if we populate the certificate in caCertificate or crossCertificatePair and
do not set the basic constraints.
 
So, it is a mixed bag.  I still think we should ask for the CAs to set the
basic constraint bit so the ldap schema does not get screwed up and NOT
require the client to check the bit.  My rule on clients is simple.
Maximize security and interoperability.  Make all checks that are security
relevant and no more and that will lead to greater interoperability.
 
 
-----Original Message-----
From: Stephen Kent [ mailto:[e-mail] <mailto:[e-mail]> ]
Sent: Wednesday, April 25, 2001 3:51 PM
To: Ambarish Malpani
Cc: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits

At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:



I agree, also.

Ambarish


I disagree. We need to make a decision on whether a cert without a CA flag
enabled can sign CRLs. If so, then we need to modify a lot of text in 2459,
and in X.509, to say this clearly. Suggesting that a client be "forgiving"
in this context is not a viable proposal for a standard.

Steve



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



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

From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Tuesday, April 24, 2001 8:22 AM 

To: Housley, Russ; [e-mail] 

Subject: RE: keyCertSign and cRLSign Key Usage Bits



Russ: I agree with the text.



I also know that Steve Kent and Sharon Boeyen feel that X.509 states that
only CA can issue CRL (the context of my comments being PKI only and not
PMI).



But, using the theory that you suggest that the client be forgiving, I would
consider a client compliant if it did NOT check the basic constraint
extension while verifying a signature on a CRL.  It need to ensure that the
cRLSign bit is set in the keyUsage extension.



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

From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Tuesday, April 24, 2001 10:37 AM 

To: [e-mail] 

Subject: keyCertSign and cRLSign Key Usage Bits





The consensus on these bits is not totally clear to me.  Yet, several 

points have been consistently, and I think that the following text 

incorporates them.  The debate regarding he linkage between these bits and 

the cA bit in the basic constraints extension does not seem to be over, and 

I have not made any changes in that area.  Please use this new thread to 

discuss any remaining unresolved points.



       The keyCertSign bit is asserted when the subject public key is 

       used for verifying a signature on public key certificates.  This 

       bit MUST only be asserted in CA certificates.  If the keyCertSign 

       bit is asserted, then the cA bit in the basic constraints 

       extension (see 4.2.1.10) MUST also be asserted.  If neither the 

       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit 

       in the basic constraints extension MUST NOT be asserted.



       The cRLSign bit is asserted when the subject public key is used 

       for verifying a signature on a certificate revocation list (e.g., 

       a CRL or an ARL).  This bit MUST be asserted in CA and Attribute 

       Authority (AA) certificates that are used to verify signatures on 

       CRLs.  If the cRLSign bit is asserted in a CA certificate, then 

       the cA bit in the basic constraints extension (see 4.2.1.10) MUST 

       also be asserted.  If the cRLSign bit is asserted in a AA 

       certificate, then the cA bit in the basic constraints extension 

       MUST NOT be asserted.  Such AA certificates MUST NOT be used to 

       verify signatures on CRLs containing revocation information for 

       public key certificates; however, these AA certificates MAY be 

       used to verify signatures on CRLs containing revocation 

       information concerning attribute certificates.  If neither the 

       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit 

       in the basic constraints extension MUST NOT be asserted.



Russ 



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=04585913-26042001>Dave:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=04585913-26042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=04585913-26042001>My 
opinion are based on the fact that the current X.509 text says that CA issues 
CRLs.&nbsp; Thus, if the key is used to sign the CRL, it is a CA and hence the 
caCertificate.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=04585913-26042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=04585913-26042001>I think 
this is not a security issue (in my mind).&nbsp; We need to make sure that the 
X.509 language and ldap schema align.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=04585913-26042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=04585913-26042001>I still 
believe that those clients that do not make checks that are not relevant to 
security, should be considered compliant.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> David A. Cooper 
[mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 26, 2001 9:37 
AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> RE: keyCertSign and 
cRLSign Key Usage Bits<BR><BR></FONT></DIV>Santosh,<BR><BR>I think you bring up 
an interesting issue with the LDAP schema no matter what we do. As I pointed out 
yesterday, a CA may have a key pair that it only uses for PKI transaction 
messages. A certificate that includes the public key from this key pair would 
only have the digitalSignature KeyUsage bit set. The proposed text below states 
that the cA bit in basicConstraints should not be set. So, we would still have 
cases in which a certificate has been issued to a CA and either basicConstraints 
is absent or cA is set to false. (Technically, according to RFC 2587, we are OK 
if basicConstraints is absent, but this isn't really a good way out of the 
problem). A CA may also be issued a certificate in which the public key is 
intended to be used for key management. Same problem.<BR><BR>I asked yesterday 
what the meaning of the cA bit was. X.509 states that "[t]he <FONT 
size=2>cA</FONT> component indicates if the certified public key may be used to 
verify certificate signatures." Do we intend to change X.509 and PKIX to state 
that the cA bit should be set whenever the subject is a CA? If not, then the 
LDAP schema will need to deal with certificates issued to CAs in which either 
basicConstraints is absent or is present with cA set to FALSE. If so, then we 
need to change the text to eliminate any tying between the cA bit and the 
contents of KeyUsage.<BR><BR>If we want to go with the proposed text below, then 
we will need to change both X.509 and PKIX to state that "the cA component 
indicates if the certified public key may be used to verify certificate or CRL 
signatures". We will also need to do something about the awkward connection 
between the cA bit and CRLs. Currently the text states that the cA bit should be 
set if the CRL issuing subject is issuing CRLs that cover public key 
certificates, but not attribute certificates. It further states that "
<BLOCKQUOTE><FONT size=2>AA certificates MUST NOT be used to verify signatures 
  on CRLs containing revocation information for public key certificates". The 
  problem is that, even if a single entity is not allowed to issued both public 
  key certificates and attribute certificates, there is the possibility that a 
  single, indirect CRL could cover both types of certificates. If one is using a 
  CRL to check the status of a public key certificate, then it is clear that the 
  text below requires that the certificate containing the key needed to verify 
  the CRL signature must have the cA bit set. But what about when one is using a 
  CRL to check the status of an attribute certificate? The quote text seem to 
  suggest that, if the cA bit is not set in the certificate, the relying party 
  is required to verify that the CRL does not contain any revocation information 
  for public key certificates. I can't imagine that there was any intention to 
  impose such a requirement, but that is what the text seems to 
  say.<BR><BR></FONT></BLOCKQUOTE>I think I have made my own opinion on this topic 
clear. X.509 does not state that the cA bit in basicConstraints should be set if 
the subject is a CA, it states that the bit should be set if the certified 
public key may be used to verify certificate signatures. The two are not 
synonymous.&nbsp; If we change the standard to state that the cA bit indicates 
whether the subject is a CA, it may solve the LDAP schema problem, but it will 
require that the remove any dependencies between the cA bit and the KeyUsage 
extension.<BR><BR>As Tony said yesterday, we need to go back and clearly define 
the terms we are using. X.509 defines a CA as an entity that issues public key 
certificates. Is this the correct definition? Or is a CA an entity that issues 
public key certificates or CRLs that provide revocation information about public 
key certificates? Or it is something else? Does the cA bit indicate if the 
certified public key can be used to verify signatures on certificates, as X.509 
states, or does it indicate that the subject is a CA, or something else? If we 
can't get agreement that the standard means what it says, how can we expect 
people to understand the standard?<BR><BR>Dave<BR><BR>At 08:20 AM 4/26/01 -0400, 
Santosh Chokhani wrote:<BR><FONT color=#0000ff face=arial size=2>
<BLOCKQUOTE cite type="cite">Steve:</FONT><BR>&nbsp;<BR><FONT color=#0000ff 
  face=arial size=2>My rationale is as follows: There is no security benefit to 
  checking the bit.&nbsp; The basic constraints and associated path length may 
  determine whether a CA can create a CA or not.&nbsp; But, that is only useful 
  for certificate path and since keyCertSign bit will not be set, the entity 
  will NOT be able to create new CAs.</FONT><BR>&nbsp;<BR><FONT color=#0000ff 
  face=arial size=2>So, I think check is not relevant from security 
  viewpoint.</FONT><BR>&nbsp;<BR><FONT color=#0000ff face=arial size=2>Now, it 
  may break some of the language (again not security) in ldap schema if we 
  populate the certificate in caCertificate or crossCertificatePair and do not 
  set the basic constraints.</FONT><BR>&nbsp;<BR><FONT color=#0000ff face=arial 
  size=2>So, it is a mixed bag.&nbsp; I still think we should ask for the CAs to 
  set the basic constraint bit so the ldap schema does not get screwed up and 
  NOT require the client to check the bit.&nbsp; My rule on clients is 
  simple.&nbsp; Maximize security and interoperability.&nbsp; Make all checks 
  that are security relevant and no more and that will lead to greater 
  interoperability.</FONT><BR>&nbsp;<BR>&nbsp;<BR><FONT 
  face="Times New Roman, Times" size=2>-----Original 
  Message-----<BR><B>From:</B> Stephen Kent [<A href="mailto:[e-mail]" 
  eudora="autourl">mailto:[e-mail]</A>]<BR><B>Sent:</B> Wednesday, April 25, 
  2001 3:51 PM<BR><B>To:</B> Ambarish Malpani<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> RE: keyCertSign and cRLSign Key Usage 
  Bits<BR><BR></FONT>At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:<BR>
  <BLOCKQUOTE cite type="cite"><BR><FONT color=#0000ff face=arial size=2>I 
    agree, also.<BR><BR>Ambarish</FONT></BLOCKQUOTE><BR>I disagree. We need to 
  make a decision on whether a cert without a CA flag enabled can sign CRLs. If 
  so, then we need to modify a lot of text in 2459, and in X.509, to say this 
  clearly. Suggesting that a client be "forgiving" in this context is not a 
  viable proposal for a standard.<BR><BR>Steve<BR>
  <BLOCKQUOTE cite type="cite"><BR>&nbsp;<BR><FONT 
    size=2>---------------------------------------------------------------------<BR>Ambarish 
    Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    650.567.5457<BR>ValiCert, 
    Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    [e-mail]<BR>339 N. Bernardo 
    Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><A href="http://www.valicert.com/"><FONT 
    size=2>http://www.valicert.com</A><BR>Mountain View, CA 94043</FONT>
    <BLOCKQUOTE><FONT face=tahoma size=2>
      <DL>
        <DD>-----Original Message----- 
        <DD>From:</B> Santosh Chokhani [<A href="mailto:[e-mail]" 
        eudora="autourl">mailto:[e-mail]</A>] 
        <DD>Sent:</B> Tuesday, April 24, 2001 8:22 AM 
        <DD>To:</B> Housley, Russ; [e-mail] 
        <DD>Subject:</B> RE: keyCertSign and cRLSign Key Usage 
        Bits</FONT><BR><BR>
        <DD>Russ: I agree with the text.<BR><BR>
        <DD>I also know that Steve Kent and Sharon Boeyen feel that X.509 states 
        that only CA can issue CRL (the context of my comments being PKI only 
        and not PMI).<BR><BR>
        <DD>But, using the theory that you suggest that the client be forgiving, 
        I would consider a client compliant if it did NOT check the basic 
        constraint extension while verifying a signature on a CRL.&nbsp; It need 
        to ensure that the cRLSign bit is set in the keyUsage extension.<BR><BR>
        <DD>-----Original Message----- 
        <DD>From: Housley, Russ [<A 
        href="mailto:[e-mail]">mailto:[e-mail]</A>] 

        <DD>Sent: Tuesday, April 24, 2001 10:37 AM 
        <DD>To: [e-mail] 
        <DD>Subject: keyCertSign and cRLSign Key Usage Bits<BR><BR><BR><BR>
        <DD>The consensus on these bits is not totally clear to me.&nbsp; Yet, 
        several 
        <DD>points have been consistently, and I think that the following text 
        <DD>incorporates them.&nbsp; The debate regarding he linkage between 
        these bits and 
        <DD>the cA bit in the basic constraints extension does not seem to be 
        over, and 
        <DD>I have not made any changes in that area.&nbsp; Please use this new 
        thread to 
        <DD>discuss any remaining unresolved points.<BR><BR>
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The keyCertSign bit is asserted 
        when the subject public key is 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for verifying a signature 
        on public key certificates.&nbsp; This 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit MUST only be asserted in CA 
        certificates.&nbsp; If the keyCertSign 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit is asserted, then the cA 
        bit in the basic constraints 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension (see 4.2.1.10) MUST 
        also be asserted.&nbsp; If neither the 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the keyCertSign 
        bit are asserted, then the cA bit 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic constraints 
        extension MUST NOT be asserted.<BR><BR>
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign bit is asserted 
        when the subject public key is used 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for verifying a signature on a 
        certificate revocation list (e.g., 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CRL or an ARL).&nbsp; This 
        bit MUST be asserted in CA and Attribute 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authority (AA) certificates 
        that are used to verify signatures on 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRLs.&nbsp; If the cRLSign bit 
        is asserted in a CA certificate, then 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cA bit in the basic 
        constraints extension (see 4.2.1.10) MUST 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; also be asserted.&nbsp; If the 
        cRLSign bit is asserted in a AA 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate, then the cA bit in 
        the basic constraints extension 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST NOT be asserted.&nbsp; 
        Such AA certificates MUST NOT be used to 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify signatures on CRLs 
        containing revocation information for 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public key certificates; 
        however, these AA certificates MAY be 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify signatures on 
        CRLs containing revocation 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information concerning 
        attribute certificates.&nbsp; If neither the 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the keyCertSign 
        bit are asserted, then the cA bit 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic constraints 
        extension MUST NOT be asserted.<BR><BR>
        <DD>Russ </DD></DL></BLOCKQUOTE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0CE58.3F8CA640--


Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA13301 for <[e-mail]>; Thu, 26 Apr 2001 07:00:39 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA352828; Thu, 26 Apr 2001 09:59:05 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id JAA22362; Thu, 26 Apr 2001 09:55:32 -0400
Importance: Normal
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)
To: Sharon Boeyen <[e-mail]>
Cc: "'Tony Bartoletti'" <[e-mail]>, "David A. Cooper" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 26 Apr 2001 10:00:33 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 04/26/2001 10:00:30 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     Thanks for clearing that up.  On a related subject, do self-issued
(i.e. having the same issuer and subject name, but not self-signed)
CRL-signing certificates get published in the directory's caCertificate
attribute or the userCertificate one?  How about other certificates issued
with the same subject DN as the CA certificate?

          Tom Gindin


Sharon Boeyen <[e-mail]> on 04/25/2001 03:34:33 PM

To:   "'Tony Bartoletti'" <[e-mail]>, "David A. Cooper"
      <[e-mail]>, [e-mail]
cc:
Subject:  RE: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix
      -new-part1-06.txt comments)


Tony, since PKIX profiles 509, here are answers from that standard. While
PKIX may
use different language to describe these, they should still be aligned with
the
basic definitions.


Hope that helps
Sharon


> -----Original Message-----
> From: Tony Bartoletti [mailto:[e-mail]]
> Sent: Wednesday, April 25, 2001 2:54 PM
> To: David A. Cooper; [e-mail]
> Subject: Re: cA flag and CRL issuers (was Re: Last Call:
> draft-ietf-pkix-new-part1-06.txt comments)
>
>
> All,
>
> In trying to parse this issue (and Russ Housley's previous
> proposed text) it
> appears that terminology needs a bit of shoring up, at least for me.
>
> Can anyone answer these "simple" questions?
>
> 1.  Is a "CA Certificate" defined to be:
>
>      a.  A certificate whose subject is a CA
>      b.  A certificate with "cA" bit set.
>      c.  A certificate with either kCertSign or cRLSign set?
>
>          (Are (a) and (b) equivalent "if its a CA certificate"?)


Clause 7 "A CA-certificate is a certificate issued by a CA to a subject
that is itslef a CA and therefore is capable of issuing public-key
certificates." It then goes on to define the different types of
CA-certificate (Self issued, Self signed and cross).


No a) and b) are not strictly equivalent. Clause 8.4.2.1 on basic
constraints "...with the certified public key being used to verify
certificate signatures", that's the key to use of that bit in the
extension.


>
> 2.  Is the term "public key certificate" intended to represent:
>
>      a.  Only certificates that bind keys to "DN/Identity"
>      b.  Certificates that bind keys to anything (e.g., "attributes")
>
>      For instance, is an "Attribute Certificate" considered to be a
>      subset of "public key certificates", or not?


No, attribute certificates are not subsets of public-key certificates. They
are
'certificates' but do NOT contain a public-key and are therefore not a
subset.
(see 3.3.1 and 3.3.4.4)
>
> 3.  Is an "AA" considered to be:
>
>      a.  A "CA that certifies attributes and not DN/Identity",
>          (yet still a CA, since they author/authorize certificates.)
>      b.  Not a CA, since the term CA is "reserved" to "DN/Identity"
>


No an AA is not a CA of any sort. CA is an authority for public-key
certificates only and AA is an authority for attribute certificates only
(see 3.3.2 and 3.3.16. The term 'authority' used alone is defined to
include
both (see 3.3.6).


> 4.  Is an "AA Certificate" a form of "CA Certificate" or not?
>      (Answer should be derived from response to (3).


No. (as per response to 3)
>
> 5.  If both "CRLs and ARLs" are examples of "certificate
> revocation lists"
>      then is an ARL:
>
>      a.  An instance of CRL (that happens not to revoke any
> DN/ID certs)?
>      b.  Never a CRL, since every CRL involves DN/ID certificates?


Actually 509 added specific acronyms for each type of CRL. What used
to be called an "ARL" (Authority Revocation List) is now a "CARL"
Certification Authority Revocation List) and is a revocation list of
public-key
certificates issued to CAs that are no longer considered valid by the
certificate issuer (3.3.17). The equivalent of that for attribute
authorities
would be an AARL (Attribute Authority Revocation List)as defined in 3.3.3.


>
> I submit that more than half of the dialogs/debates on this list can
> be traced to confusion regarding these fundamental terms.
>
> ___tony___
>
>
> At 01:25 PM 4/25/01 -0400, David A. Cooper wrote:
> >Steve,
> >
> >If we are going to change PKIX to require the cA bit in
> basicConstraints
> >to be set even when the subject public key can only be used
> to verify
> >signatures on CRLs, then we need to be sure that the text
> clearly explains
> >to readers when the cA bit should or should not be set. Currently
> >new-part1-06 states that "[t]he cA bit indicates if the
> certified public
> >key may be used to verify signatures on other certificates."
> The clearly
> >is not accurate, since if the cA bit is set one still does not know
> >whether the subject public key may be used to verify signatures on
> >certificates. One must look at the keyUsage extension to make that
> >determination.
> >
> >I think it would be helpful to the discussion that we are
> having if you
> >would clearly state your interpretation of the meaning of
> the cA bit in
> >basicConstraints.
> >
> >  From what I have read so far, it appears that you believe
> that the cA
> > bit should be used to indicate if the subject of the
> certificate is a CA.
> > But, if this is the case, then new-part1-06 still does not
> accurately
> > reflect your notion of the cA bit. Currently the text
> states that the cA
> > bit may only be set if the keyCertSign bit or the cRLSign
> bit in keyUsage
> > is set. However, a CA does more than just issue
> certificates and CRLs. A
> > CA may have a private key dedicated to signing PKI
> transaction messages
> > (e.g., certification response, revocation response,
> proof-of-possession
> > challenge). If a certificate were issued to a CA with its
> PKI transaction
> > message verification key as the subject public key, neither the
> > keyCertSign nor the cRLSign bit in KeyUsage would be set,
> but the subject
> > of the certificate would still be a CA.
> >
> >So, should the cA bit be used to indicate if the certificate
> subject is a
> >CA or to indicate that the subject public key may be used to verify
> >signatures on certificates and/or CRLs? If the latter, then not all
> >certificates issued to CAs will have the cA bit set.
> >
> >Dave
> >
> >At 01:31 PM 4/20/01 -0400, Stephen Kent wrote:
> > >>The description of basic constraints in X.509 further
> supports the idea
> > that the cA bit is used to specify certificate issuing, not
> certificate
> > and/or CRL issuing:
> > >>
> > >>"This field indicates if the subject may act as a CA, with the
> > certified public key being used to verify certificate
> signatures. ... The
> > cA component indicates if the certified public key may be
> used to verify
> > certificate signatures. ... if the value of cA is not set to
> true then the
> > certified public key shall not be used to verify a
> certificate signature"
> > >>
> > >>
> > >>pkix-new-part1-05 states something similar:
> > >>
> > >>"The cA bit indicates if the certified public key may be
> used to verify
> > signatures on other certificates. If the cA bit is
> asserted, then the
> > keyCertSign bit in the key usage extension (see 4.2.1.3)
> MUST also be
> > asserted. If the cA bit is not asserted, then the
> keyCertSign bit in the
> > key usage extension MUST NOT be asserted."
> > >
> > >again, this supports the notion that a CA signs certs, but it says
> > nothing about whether a CA or some other entity signs CRLs. We have
> > uncovered a number of instances where less than perfect
> wording has lead
> > to confusion and our recent dialogue suggests that some of
> the quotes you
> > cite are examples of this.
>
> Tony Bartoletti 925-422-3881 <[e-mail]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900
>
>
>
>





Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA11962 for <[e-mail]>; Thu, 26 Apr 2001 06:37:22 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id JAA05667 for <[e-mail]>; Thu, 26 Apr 2001 09:37:19 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 26 Apr 2001 09:37:03 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: keyCertSign and cRLSign Key Usage Bits
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_4052544==_.ALT"

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

Santosh,

I think you bring up an interesting issue with the LDAP schema no matter what we do. As I pointed out yesterday, a CA may have a key pair that it only uses for PKI transaction messages. A certificate that includes the public key from this key pair would only have the digitalSignature KeyUsage bit set. The proposed text below states that the cA bit in basicConstraints should not be set. So, we would still have cases in which a certificate has been issued to a CA and either basicConstraints is absent or cA is set to false. (Technically, according to RFC 2587, we are OK if basicConstraints is absent, but this isn't really a good way out of the problem). A CA may also be issued a certificate in which the public key is intended to be used for key management. Same problem.

I asked yesterday what the meaning of the cA bit was. X.509 states that "[t]he cA component indicates if the certified public key may be used to verify certificate signatures." Do we intend to change X.509 and PKIX to state that the cA bit should be set whenever the subject is a CA? If not, then the LDAP schema will need to deal with certificates issued to CAs in which either basicConstraints is absent or is present with cA set to FALSE. If so, then we need to change the text to eliminate any tying between the cA bit and the contents of KeyUsage.

If we want to go with the proposed text below, then we will need to change both X.509 and PKIX to state that "the cA component indicates if the certified public key may be used to verify certificate or CRL signatures". We will also need to do something about the awkward connection between the cA bit and CRLs. Currently the text states that the cA bit should be set if the CRL issuing subject is issuing CRLs that cover public key certificates, but not attribute certificates. It further states that "
>AA certificates MUST NOT be used to verify signatures on CRLs containing revocation information for public key certificates". The problem is that, even if a single entity is not allowed to issued both public key certificates and attribute certificates, there is the possibility that a single, indirect CRL could cover both types of certificates. If one is using a CRL to check the status of a public key certificate, then it is clear that the text below requires that the certificate containing the key needed to verify the CRL signature must have the cA bit set. But what about when one is using a CRL to check the status of an attribute certificate? The quote text seem to suggest that, if the cA bit is not set in the certificate, the relying party is required to verify that the CRL does not contain any revocation information for public key certificates. I can't imagine that there was any intention to impose such a requirement, but that is what the text seems to say.
>
I think I have made my own opinion on this topic clear. X.509 does not state that the cA bit in basicConstraints should be set if the subject is a CA, it states that the bit should be set if the certified public key may be used to verify certificate signatures. The two are not synonymous.  If we change the standard to state that the cA bit indicates whether the subject is a CA, it may solve the LDAP schema problem, but it will require that the remove any dependencies between the cA bit and the KeyUsage extension.

As Tony said yesterday, we need to go back and clearly define the terms we are using. X.509 defines a CA as an entity that issues public key certificates. Is this the correct definition? Or is a CA an entity that issues public key certificates or CRLs that provide revocation information about public key certificates? Or it is something else? Does the cA bit indicate if the certified public key can be used to verify signatures on certificates, as X.509 states, or does it indicate that the subject is a CA, or something else? If we can't get agreement that the standard means what it says, how can we expect people to understand the standard?

Dave

At 08:20 AM 4/26/01 -0400, Santosh Chokhani wrote:
>Steve:
>  
>My rationale is as follows: There is no security benefit to checking the bit.  The basic constraints and associated path length may determine whether a CA can create a CA or not.  But, that is only useful for certificate path and since keyCertSign bit will not be set, the entity will NOT be able to create new CAs.
>  
>So, I think check is not relevant from security viewpoint.
>  
>Now, it may break some of the language (again not security) in ldap schema if we populate the certificate in caCertificate or crossCertificatePair and do not set the basic constraints.
>  
>So, it is a mixed bag.  I still think we should ask for the CAs to set the basic constraint bit so the ldap schema does not get screwed up and NOT require the client to check the bit.  My rule on clients is simple.  Maximize security and interoperability.  Make all checks that are security relevant and no more and that will lead to greater interoperability.
>  
>  
>-----Original Message-----
>From: Stephen Kent [mailto:[e-mail]]
>Sent: Wednesday, April 25, 2001 3:51 PM
>To: Ambarish Malpani
>Cc: [e-mail]
>Subject: RE: keyCertSign and cRLSign Key Usage Bits
>
>At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:
>>  
>>I agree, also.
>>
>>Ambarish
>
>I disagree. We need to make a decision on whether a cert without a CA flag enabled can sign CRLs. If so, then we need to modify a lot of text in 2459, and in X.509, to say this clearly. Suggesting that a client be "forgiving" in this context is not a viable proposal for a standard.
>
>Steve
>>
>>  
>>---------------------------------------------------------------------
>>Ambarish Malpani
>>Architect                                                650.567.5457
>>ValiCert, Inc.                                  [e-mail]
>>339 N. Bernardo Ave.                          <http://www.valicert.com/>http://www.valicert.com
>>Mountain View, CA 94043
>>>-----Original Message----- 
>>>From: Santosh Chokhani [mailto:[e-mail]] 
>>>Sent: Tuesday, April 24, 2001 8:22 AM 
>>>To: Housley, Russ; [e-mail] 
>>>Subject: RE: keyCertSign and cRLSign Key Usage Bits
>>>
>>>Russ: I agree with the text.
>>>
>>>I also know that Steve Kent and Sharon Boeyen feel that X.509 states that only CA can issue CRL (the context of my comments being PKI only and not PMI).
>>>
>>>But, using the theory that you suggest that the client be forgiving, I would consider a client compliant if it did NOT check the basic constraint extension while verifying a signature on a CRL.  It need to ensure that the cRLSign bit is set in the keyUsage extension.
>>>
>>>-----Original Message----- 
>>>From: Housley, Russ [<mailto:[e-mail]>mailto:[e-mail]] 
>>>Sent: Tuesday, April 24, 2001 10:37 AM 
>>>To: [e-mail] 
>>>Subject: keyCertSign and cRLSign Key Usage Bits
>>>
>>>
>>>
>>>The consensus on these bits is not totally clear to me.  Yet, several 
>>>points have been consistently, and I think that the following text 
>>>incorporates them.  The debate regarding he linkage between these bits and 
>>>the cA bit in the basic constraints extension does not seem to be over, and 
>>>I have not made any changes in that area.  Please use this new thread to 
>>>discuss any remaining unresolved points.
>>>
>>>        The keyCertSign bit is asserted when the subject public key is 
>>>        used for verifying a signature on public key certificates.  This 
>>>        bit MUST only be asserted in CA certificates.  If the keyCertSign 
>>>        bit is asserted, then the cA bit in the basic constraints 
>>>        extension (see 4.2.1.10) MUST also be asserted.  If neither the 
>>>        cRLSign bit nor the keyCertSign bit are asserted, then the cA bit 
>>>        in the basic constraints extension MUST NOT be asserted.
>>>
>>>        The cRLSign bit is asserted when the subject public key is used 
>>>        for verifying a signature on a certificate revocation list (e.g., 
>>>        a CRL or an ARL).  This bit MUST be asserted in CA and Attribute 
>>>        Authority (AA) certificates that are used to verify signatures on 
>>>        CRLs.  If the cRLSign bit is asserted in a CA certificate, then 
>>>        the cA bit in the basic constraints extension (see 4.2.1.10) MUST 
>>>        also be asserted.  If the cRLSign bit is asserted in a AA 
>>>        certificate, then the cA bit in the basic constraints extension 
>>>        MUST NOT be asserted.  Such AA certificates MUST NOT be used to 
>>>        verify signatures on CRLs containing revocation information for 
>>>        public key certificates; however, these AA certificates MAY be 
>>>        used to verify signatures on CRLs containing revocation 
>>>        information concerning attribute certificates.  If neither the 
>>>        cRLSign bit nor the keyCertSign bit are asserted, then the cA bit 
>>>        in the basic constraints extension MUST NOT be asserted.
>>>
>>>Russ 
>

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

<html>
Santosh,<br>
<br>
I think you bring up an interesting issue with the LDAP schema no matter
what we do. As I pointed out yesterday, a CA may have a key pair that it
only uses for PKI transaction messages. A certificate that includes the
public key from this key pair would only have the digitalSignature
KeyUsage bit set. The proposed text below states that the cA bit in
basicConstraints should not be set. So, we would still have cases in
which a certificate has been issued to a CA and either basicConstraints
is absent or cA is set to false. (Technically, according to RFC 2587, we
are OK if basicConstraints is absent, but this isn't really a good way
out of the problem). A CA may also be issued a certificate in which the
public key is intended to be used for key management. Same problem.<br>
<br>
I asked yesterday what the meaning of the cA bit was. X.509 states that
&quot;[t]he <font size=3D2>cA</font> component indicates if the certified
public key may be used to verify certificate signatures.&quot; Do we
intend to change X.509 and PKIX to state that the cA bit should be set
whenever the subject is a CA? If not, then the LDAP schema will need to
deal with certificates issued to CAs in which either basicConstraints is
absent or is present with cA set to FALSE. If so, then we need to change
the text to eliminate any tying between the cA bit and the contents of
KeyUsage.<br>
<br>
If we want to go with the proposed text below, then we will need to
change both X.509 and PKIX to state that &quot;the cA component indicates
if the certified public key may be used to verify certificate or CRL
signatures&quot;. We will also need to do something about the awkward
connection between the cA bit and CRLs. Currently the text states that
the cA bit should be set if the CRL issuing subject is issuing CRLs that
cover public key certificates, but not attribute certificates. It further
states that &quot;<blockquote><font size=3D2>AA certificates MUST NOT be
used to verify signatures on CRLs containing revocation information for
public key certificates&quot;. The problem is that, even if a single
entity is not allowed to issued both public key certificates and
attribute certificates, there is the possibility that a single, indirect
CRL could cover both types of certificates. If one is using a CRL to
check the status of a public key certificate, then it is clear that the
text below requires that the certificate containing the key needed to
verify the CRL signature must have the cA bit set. But what about when
one is using a CRL to check the status of an attribute certificate? The
quote text seem to suggest that, if the cA bit is not set in the
certificate, the relying party is required to verify that the CRL does
not contain any revocation information for public key certificates. I
can't imagine that there was any intention to impose such a requirement,
but that is what the text seems to say.<br>
<br>
</font></blockquote>I think I have made my own opinion on this topic
clear. X.509 does not state that the cA bit in basicConstraints should be
set if the subject is a CA, it states that the bit should be set if the
certified public key may be used to verify certificate signatures. The
two are not synonymous.&nbsp; If we change the standard to state that the
cA bit indicates whether the subject is a CA, it may solve the LDAP
schema problem, but it will require that the remove any dependencies
between the cA bit and the KeyUsage extension.<br>
<br>
As Tony said yesterday, we need to go back and clearly define the terms
we are using. X.509 defines a CA as an entity that issues public key
certificates. Is this the correct definition? Or is a CA an entity that
issues public key certificates or CRLs that provide revocation
information about public key certificates? Or it is something else? Does
the cA bit indicate if the certified public key can be used to verify
signatures on certificates, as X.509 states, or does it indicate that the
subject is a CA, or something else? If we can't get agreement that the
standard means what it says, how can we expect people to understand the
standard?<br>
<br>
Dave<br>
<br>
At 08:20 AM 4/26/01 -0400, Santosh Chokhani wrote:<br>
<font face=3D"arial" size=3D2 color=3D"#0000FF"><blockquote type=3Dcite=
 cite>Steve:</font><br>
&nbsp;<br>
<font face=3D"arial" size=3D2 color=3D"#0000FF">My rationale is as follows:
There is no security benefit to checking the bit.&nbsp; The basic
constraints and associated path length may determine whether a CA can
create a CA or not.&nbsp; But, that is only useful for certificate path
and since keyCertSign bit will not be set, the entity will NOT be able to
create new CAs.</font><br>
&nbsp;<br>
<font face=3D"arial" size=3D2 color=3D"#0000FF">So, I think check is not
relevant from security viewpoint.</font><br>
&nbsp;<br>
<font face=3D"arial" size=3D2 color=3D"#0000FF">Now, it may break some of th=
e
language (again not security) in ldap schema if we populate the
certificate in caCertificate or crossCertificatePair and do not set the
basic constraints.</font><br>
&nbsp;<br>
<font face=3D"arial" size=3D2 color=3D"#0000FF">So, it is a mixed bag.&nbsp;=
 I
still think we should ask for the CAs to set the basic constraint bit so
the ldap schema does not get screwed up and NOT require the client to
check the bit.&nbsp; My rule on clients is simple.&nbsp; Maximize
security and interoperability.&nbsp; Make all checks that are security
relevant and no more and that will lead to greater
interoperability.</font><br>
&nbsp;<br>
&nbsp;<br>
<font face=3D"Times New Roman, Times" size=3D2>-----Original
Message-----<br>
<b>From:</b> Stephen Kent
[<a href=3D"mailto:[e-mail]"=
 eudora=3D"autourl">mailto:[e-mail]</a>]<br>
<b>Sent:</b> Wednesday, April 25, 2001 3:51 PM<br>
<b>To:</b> Ambarish Malpani<br>
<b>Cc:</b> [e-mail]<br>
<b>Subject:</b> RE: keyCertSign and cRLSign Key Usage Bits<br>
<br>
</font>At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:<br>
<blockquote type=3Dcite cite>&nbsp;<br>
<font face=3D"arial" size=3D2 color=3D"#0000FF">I agree, also.<br>
<br>
Ambarish</font></blockquote><br>
I disagree. We need to make a decision on whether a cert without a CA
flag enabled can sign CRLs. If so, then we need to modify a lot of text
in 2459, and in X.509, to say this clearly. Suggesting that a client be
&quot;forgiving&quot; in this context is not a viable proposal for a
standard.<br>
<br>
Steve<br>
<blockquote type=3Dcite cite><br>
&nbsp;<br>
<font=
 size=3D2>------------------------------------------------------------------=
---<br>
Ambarish Malpani<br>
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
650.567.5457<br>
ValiCert,
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[e-mail]<br>
339 N. Bernardo
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font>
<a href=3D"http://www.valicert.com/"><font=
 size=3D2>http://www.valicert.com</a><br>
Mountain View, CA 94043</font><blockquote><font face=3D"tahoma" size=3D2>
<dl>
<dd>-----Original Message-----
<dd>From:</b> Santosh Chokhani
[<a href=3D"mailto:[e-mail]"=
 eudora=3D"autourl">mailto:[e-mail]</a>]
<dd>Sent:</b> Tuesday, April 24, 2001 8:22 AM
<dd>To:</b> Housley, Russ; [e-mail]
<dd>Subject:</b> RE: keyCertSign and cRLSign Key Usage Bits</font><br>
<br>

<dd>Russ: I agree with the text.<br>
<br>

<dd>I also know that Steve Kent and Sharon Boeyen feel that X.509 states
that only CA can issue CRL (the context of my comments being PKI only and
not PMI).<br>
<br>

<dd>But, using the theory that you suggest that the client be forgiving,
I would consider a client compliant if it did NOT check the basic
constraint extension while verifying a signature on a CRL.&nbsp; It need
to ensure that the cRLSign bit is set in the keyUsage extension.<br>
<br>

<dd>-----Original Message-----
<dd>From: Housley, Russ
[<a=
 href=3D"mailto:[e-mail]">mailto:[e-mail]</a=
>]
<dd>Sent: Tuesday, April 24, 2001 10:37 AM
<dd>To: [e-mail]
<dd>Subject: keyCertSign and cRLSign Key Usage Bits<br>
<br>
<br>
<br>

<dd>The consensus on these bits is not totally clear to me.&nbsp; Yet,
several
<dd>points have been consistently, and I think that the following text
<dd>incorporates them.&nbsp; The debate regarding he linkage between
these bits and
<dd>the cA bit in the basic constraints extension does not seem to be
over, and
<dd>I have not made any changes in that area.&nbsp; Please use this new
thread to
<dd>discuss any remaining unresolved points.<br>
<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The keyCertSign bit is asserted
when the subject public key is
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for verifying a signature
on public key certificates.&nbsp; This
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit MUST only be asserted in CA
certificates.&nbsp; If the keyCertSign
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit is asserted, then the cA bit
in the basic constraints
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension (see 4.2.1.10) MUST
also be asserted.&nbsp; If neither the
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the keyCertSign
bit are asserted, then the cA bit
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic constraints
extension MUST NOT be asserted.<br>
<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign bit is asserted when
the subject public key is used
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for verifying a signature on a
certificate revocation list (e.g.,
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CRL or an ARL).&nbsp; This bit
MUST be asserted in CA and Attribute
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authority (AA) certificates that
are used to verify signatures on
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRLs.&nbsp; If the cRLSign bit
is asserted in a CA certificate, then
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cA bit in the basic
constraints extension (see 4.2.1.10) MUST
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; also be asserted.&nbsp; If the
cRLSign bit is asserted in a AA
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate, then the cA bit in
the basic constraints extension
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST NOT be asserted.&nbsp; Such
AA certificates MUST NOT be used to
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify signatures on CRLs
containing revocation information for
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public key certificates;
however, these AA certificates MAY be
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify signatures on
CRLs containing revocation
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information concerning attribute
certificates.&nbsp; If neither the
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the keyCertSign
bit are asserted, then the cA bit
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic constraints
extension MUST NOT be asserted.<br>
<br>

<dd>Russ
</dl></blockquote></blockquote><br>
</html>

--=====================_4052544==_.ALT--



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA11353 for <[e-mail]>; Thu, 26 Apr 2001 06:30:40 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JV6F5VC0>; Thu, 26 Apr 2001 09:30:13 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, [e-mail]
Cc: Sharon Boeyen <[e-mail]>, Peter Williams <[e-mail]>
Subject: RE: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix -new-part1-06.txt comments)
Date: Thu, 26 Apr 2001 09:24:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE54.368451F0"

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_01C0CE54.368451F0
Content-Type: text/plain

Tony, on the binding of a key to attributes the 509 standard has at least
2 ways to do this. One is to include the attributes of interest 
in a public-key certificate in the subjectDirectoryAttributes extension.
If, however you want to use the more flexible approach of assigning
attributes
through attribute certificates, then there are 3 ways to identify the 
holder of the attribute certificate. One of those is to identify the user
with the baseCertificateID component that points directly to a specific 
public-key certificate for that user. If this mechanism is used, that 
means that in order for the holder to use the privileges assigned in 
the attribute cert, they must be authenticated using the indicated
public-key 
certificate (the user's DN can optionally also be present in order to help 
the verifier locate that public-key certificate). There are some other
interesting 
PMI extensions as well including one that allows the issuer of the attribute

certificate to indicate the certificate policies that are the only
acceptable 
ones for the associated public-key certificate used for authentication. So
there 
are mechanisms for relating the use of attribute certs for authorization
with the 
PKI used for authentication.

In 2459, the use of CRL (I believe) applies to two cases. In one instance it
is the 
full and complete CRL (including all revocation noticies for all certs of
all types 
issued by a CA) and in the other case it equates to what 509 defines as an
EPRL (End-
Entity Public-key Certificate Revocation List). The 2459 use of ARL equates
to 
the 509 CARL (Certification Authority Revocation List). 

509 also defines AARL and ACRL for the equivalent in the attribute cert
space.

As for the issuance of a single CRL that contains both revocation notices
for public-key 
and for attribute certs, 509 does allow this as well. In the reasonCode
extension (8.5.2.2) and in the cRLDistributionPoints extension (8.56.2.1)
you'll find that we added 2 new reasons (privilegeWithdrawn and
aaCompromise) to the existing set, so a CRL can cover any combination of
reason codes. In the crlScope (8.5.2.5) extension you'll find 
that we use the term "authority" rather than CA so that could inclode both.
In the issuingDistributionPoint extension (8.6.2.2) there are now
onlyContainsUserCerts, onlyContainsAuthorityCerts and
onlyContainsAttributeCerts, so all combinations are 
permitted. 

Cheers,
Sharon  

Hope that helps
Sharon

> -----Original Message-----
> From: Tony Bartoletti [mailto:[e-mail]]
> Sent: Wednesday, April 25, 2001 5:28 PM
> To: [e-mail]
> Cc: Sharon Boeyen; Peter Williams
> Subject: RE: cA flag and CRL issuers (was Re: Last Call: 
> draft-ietf-pkix
> -new-part1-06.txt comments)
> 
> 
> 
> Sharon and Peter,
> 
> Thank you both for the explanations.  I now understand that an
> "attribute certificate" does NOT certify a key.  Thus, an "AA"
> is not an "[Attribute] Certificate Authority" (A-CA) but rather
> is an "[Attribute Certificate] Authority]" (AC-A).  What is
> called a "CA" is actually a "(Public) Key Certificate Authority".
> 
> Are there no instruments that attest (e.g.):
> 
>     "(anonymous) signer with this key is 21 years old"?
> 
> That is, bind a "key to attributes, sans DN/Identity"?
> Could a CA do this using PMI extension attributes?
> 
> Finally, does anyone know if the PKIX "CRL/ARL" maps to
> CARL/AARL?  And does this imply that no one can sign or
> verify a list containing both PKC and AC revocations?
> 
> Thanks again for your previous (extensive) response!
> 
> ___tony___
> 
> 
> Tony Bartoletti 925-422-3881 <[e-mail]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900
> 
> 
> 
> 

------_=_NextPart_001_01C0CE54.368451F0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: cA flag and CRL issuers (was Re: Last Call:   =
draft-ietf-pkix -new-part1-06.txt comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Tony, on the binding of a key to attributes the 509 =
standard has at least</FONT>
<BR><FONT SIZE=3D2>2 ways to do this. One is to include the attributes =
of interest </FONT>
<BR><FONT SIZE=3D2>in a public-key certificate in the =
subjectDirectoryAttributes extension.</FONT>
<BR><FONT SIZE=3D2>If, however you want to use the more flexible =
approach of assigning attributes</FONT>
<BR><FONT SIZE=3D2>through attribute certificates, then there are 3 =
ways to identify the </FONT>
<BR><FONT SIZE=3D2>holder of the attribute certificate. One of those is =
to identify the user</FONT>
<BR><FONT SIZE=3D2>with the baseCertificateID component that points =
directly to a specific </FONT>
<BR><FONT SIZE=3D2>public-key certificate for that user. If this =
mechanism is used, that </FONT>
<BR><FONT SIZE=3D2>means that in order for the holder to use the =
privileges assigned in </FONT>
<BR><FONT SIZE=3D2>the attribute cert, they must be authenticated using =
the indicated public-key </FONT>
<BR><FONT SIZE=3D2>certificate (the user's DN can optionally also be =
present in order to help </FONT>
<BR><FONT SIZE=3D2>the verifier locate that public-key certificate). =
There are some other interesting </FONT>
<BR><FONT SIZE=3D2>PMI extensions as well including one that allows the =
issuer of the attribute </FONT>
<BR><FONT SIZE=3D2>certificate to indicate the certificate policies =
that are the only acceptable </FONT>
<BR><FONT SIZE=3D2>ones for the associated public-key certificate used =
for authentication. So there </FONT>
<BR><FONT SIZE=3D2>are mechanisms for relating the use of attribute =
certs for authorization with the </FONT>
<BR><FONT SIZE=3D2>PKI used for authentication.</FONT>
</P>

<P><FONT SIZE=3D2>In 2459, the use of CRL (I believe) applies to two =
cases. In one instance it is the </FONT>
<BR><FONT SIZE=3D2>full and complete CRL (including all revocation =
noticies for all certs of all types </FONT>
<BR><FONT SIZE=3D2>issued by a CA) and in the other case it equates to =
what 509 defines as an EPRL (End-</FONT>
<BR><FONT SIZE=3D2>Entity Public-key Certificate Revocation List). The =
2459 use of ARL equates to </FONT>
<BR><FONT SIZE=3D2>the 509 CARL (Certification Authority Revocation =
List). </FONT>
</P>

<P><FONT SIZE=3D2>509 also defines AARL and ACRL for the equivalent in =
the attribute cert space.</FONT>
</P>

<P><FONT SIZE=3D2>As for the issuance of a single CRL that contains =
both revocation notices for public-key </FONT>
<BR><FONT SIZE=3D2>and for attribute certs, 509 does allow this as =
well. In the reasonCode extension (8.5.2.2) and in the =
cRLDistributionPoints extension (8.56.2.1) you'll find that we added 2 =
new reasons (privilegeWithdrawn and aaCompromise) to the existing set, =
so a CRL can cover any combination of reason codes. In the crlScope =
(8.5.2.5) extension you'll find </FONT></P>

<P><FONT SIZE=3D2>that we use the term &quot;authority&quot; rather =
than CA so that could inclode both. In the issuingDistributionPoint =
extension (8.6.2.2) there are now onlyContainsUserCerts, =
onlyContainsAuthorityCerts and onlyContainsAttributeCerts, so all =
combinations are </FONT></P>

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

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

<P><FONT SIZE=3D2>Hope that helps</FONT>
<BR><FONT SIZE=3D2>Sharon</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Tony Bartoletti [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, April 25, 2001 5:28 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Sharon Boeyen; Peter Williams</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: cA flag and CRL issuers (was Re: =
Last Call: </FONT>
<BR><FONT SIZE=3D2>&gt; draft-ietf-pkix</FONT>
<BR><FONT SIZE=3D2>&gt; -new-part1-06.txt comments)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sharon and Peter,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thank you both for the explanations.&nbsp; I =
now understand that an</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;attribute certificate&quot; does NOT =
certify a key.&nbsp; Thus, an &quot;AA&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; is not an &quot;[Attribute] Certificate =
Authority&quot; (A-CA) but rather</FONT>
<BR><FONT SIZE=3D2>&gt; is an &quot;[Attribute Certificate] =
Authority]&quot; (AC-A).&nbsp; What is</FONT>
<BR><FONT SIZE=3D2>&gt; called a &quot;CA&quot; is actually a =
&quot;(Public) Key Certificate Authority&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Are there no instruments that attest =
(e.g.):</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;(anonymous) =
signer with this key is 21 years old&quot;?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; That is, bind a &quot;key to attributes, sans =
DN/Identity&quot;?</FONT>
<BR><FONT SIZE=3D2>&gt; Could a CA do this using PMI extension =
attributes?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Finally, does anyone know if the PKIX =
&quot;CRL/ARL&quot; maps to</FONT>
<BR><FONT SIZE=3D2>&gt; CARL/AARL?&nbsp; And does this imply that no =
one can sign or</FONT>
<BR><FONT SIZE=3D2>&gt; verify a list containing both PKC and AC =
revocations?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks again for your previous (extensive) =
response!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ___tony___</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Tony Bartoletti 925-422-3881 =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Information Operations, Warfare and Assurance =
Center</FONT>
<BR><FONT SIZE=3D2>&gt; Lawrence Livermore National Laboratory</FONT>
<BR><FONT SIZE=3D2>&gt; Livermore, CA 94551-9900</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>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CE54.368451F0--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA06138 for <[e-mail]>; Thu, 26 Apr 2001 05:30:18 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JV6F54HR>; Thu, 26 Apr 2001 08:29:48 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Stephen Kent <[e-mail]>, Ambarish Malpani <[e-mail]>
Cc: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Date: Thu, 26 Apr 2001 08:20:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE4B.5758CB80"

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_01C0CE4B.5758CB80
Content-Type: text/plain;
	charset="iso-8859-1"

Steve:
 
My rationale is as follows: There is no security benefit to checking the
bit.  The basic constraints and associated path length may determine whether
a CA can create a CA or not.  But, that is only useful for certificate path
and since keyCertSign bit will not be set, the entity will NOT be able to
create new CAs.
 
So, I think check is not relevant from security viewpoint.
 
Now, it may break some of the language (again not security) in ldap schema
if we populate the certificate in caCertificate or crossCertificatePair and
do not set the basic constraints.
 
So, it is a mixed bag.  I still think we should ask for the CAs to set the
basic constraint bit so the ldap schema does not get screwed up and NOT
require the client to check the bit.  My rule on clients is simple.
Maximize security and interoperability.  Make all checks that are security
relevant and no more and that will lead to greater interoperability.
 
 
-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, April 25, 2001 3:51 PM
To: Ambarish Malpani
Cc: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits


At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:

 

I agree, also.


Ambarish


I disagree. We need to make a decision on whether a cert without a CA flag
enabled can sign CRLs. If so, then we need to modify a lot of text in 2459,
and in X.509, to say this clearly. Suggesting that a client be "forgiving"
in this context is not a viable proposal for a standard.

Steve


 

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


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 8:22 AM
To: Housley, Russ; [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits


Russ: I agree with the text.


I also know that Steve Kent and Sharon Boeyen feel that X.509 states that
only CA can issue CRL (the context of my comments being PKI only and not
PMI).


But, using the theory that you suggest that the client be forgiving, I would
consider a client compliant if it did NOT check the basic constraint
extension while verifying a signature on a CRL.  It need to ensure that the
cRLSign bit is set in the keyUsage extension.


-----Original Message-----
From: Housley, Russ [  <mailto:[e-mail]>
mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 10:37 AM
To: [e-mail]
Subject: keyCertSign and cRLSign Key Usage Bits



The consensus on these bits is not totally clear to me.  Yet, several
points have been consistently, and I think that the following text
incorporates them.  The debate regarding he linkage between these bits and
the cA bit in the basic constraints extension does not seem to be over, and
I have not made any changes in that area.  Please use this new thread to
discuss any remaining unresolved points.


       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on public key certificates.  This
       bit MUST only be asserted in CA certificates.  If the keyCertSign
       bit is asserted, then the cA bit in the basic constraints
       extension (see 4.2.1.10) MUST also be asserted.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.


       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on a certificate revocation list (e.g.,
       a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
       Authority (AA) certificates that are used to verify signatures on
       CRLs.  If the cRLSign bit is asserted in a CA certificate, then
       the cA bit in the basic constraints extension (see 4.2.1.10) MUST
       also be asserted.  If the cRLSign bit is asserted in a AA
       certificate, then the cA bit in the basic constraints extension
       MUST NOT be asserted.  Such AA certificates MUST NOT be used to
       verify signatures on CRLs containing revocation information for
       public key certificates; however, these AA certificates MAY be
       used to verify signatures on CRLs containing revocation
       information concerning attribute certificates.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.


Russ



------_=_NextPart_001_01C0CE4B.5758CB80
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: keyCertSign and cRLSign Key Usage Bits</TITLE>

<STYLE type=text/css>BLOCKQUOTE {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
DL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
UL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
OL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
LI {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
</STYLE>

<META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=394012212-26042001>Steve:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=394012212-26042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=394012212-26042001>My 
rationale is as follows: There is no security benefit to checking the bit.&nbsp; 
The basic constraints and associated path length may determine whether a CA can 
create a CA or not.&nbsp; But, that is only useful for certificate path and 
since keyCertSign bit will not be set, the entity will NOT be able to create new 
CAs.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=394012212-26042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=394012212-26042001>So, I 
think check is not relevant from security viewpoint.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=394012212-26042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=394012212-26042001>Now, 
it may break some of the language (again not security) in ldap schema if we 
populate the certificate in caCertificate or crossCertificatePair and do not set 
the basic constraints.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=394012212-26042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=394012212-26042001>So, it 
is a mixed bag.&nbsp; I still think we should ask for the CAs to set the basic 
constraint bit so the ldap schema does not get screwed up and NOT require the 
client to check the bit.&nbsp; My rule on clients is simple.&nbsp; Maximize 
security and interoperability.&nbsp; Make all checks that are security relevant 
and no more and that will lead to greater interoperability.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=394012212-26042001></SPAN></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Stephen Kent 
[mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, April 25, 2001 3:51 
PM<BR><B>To:</B> Ambarish Malpani<BR><B>Cc:</B> 
[e-mail]<BR><B>Subject:</B> RE: keyCertSign and cRLSign Key Usage 
Bits<BR><BR></FONT></DIV>
<DIV>At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:</DIV>
<BLOCKQUOTE cite type="cite">&nbsp;</BLOCKQUOTE>
<BLOCKQUOTE cite type="cite"><FONT color=#0000ff face=Arial size=-1>I agree, 
  also.</FONT></BLOCKQUOTE>
<BLOCKQUOTE cite type="cite"><FONT color=#0000ff face=Arial 
  size=-1><BR>Ambarish</FONT></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>I disagree. We need to make a decision on whether a cert without a CA flag 
enabled can sign CRLs. If so, then we need to modify a lot of text in 2459, and 
in X.509, to say this clearly. Suggesting that a client be "forgiving" in this 
context is not a viable proposal for a standard.</DIV>
<DIV><BR>Steve</DIV>
<BLOCKQUOTE cite type="cite"><BR>&nbsp;</BLOCKQUOTE>
<BLOCKQUOTE cite type="cite"><FONT 
  size=-1>---------------------------------------------------------------------<BR>Ambarish 
  Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp; 
  650.567.5457<BR>ValiCert, 
  Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  [e-mail]<BR>339 N. Bernardo 
  Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;</FONT> 
  <A href="http://www.valicert.com/"><FONT 
  size=-1>http://www.valicert.com</FONT></A><FONT size=-1><BR>Mountain View, CA 
  94043</FONT><BR>
  <BLOCKQUOTE><FONT face=Tahoma size=-1>-----Original 
    Message-----<BR><B>From:</B> Santosh Chokhani 
    [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, April 24, 2001 8:22 
    AM<BR><B>To:</B> Housley, Russ; [e-mail]<BR><B>Subject:</B> RE: 
    keyCertSign and cRLSign Key Usage Bits</FONT><BR><FONT face=Tahoma 
    size=-1></FONT></BLOCKQUOTE>
  <BLOCKQUOTE><FONT size=-1>Russ: I agree with the text.</FONT><BR></BLOCKQUOTE>
  <BLOCKQUOTE><FONT size=-1>I also know that Steve Kent and Sharon Boeyen feel 
    that X.509 states that only CA can issue CRL (the context of my comments 
    being PKI only and not PMI).</FONT><BR></BLOCKQUOTE>
  <BLOCKQUOTE><FONT size=-1>But, using the theory that you suggest that the 
    client be forgiving, I would consider a client compliant if it did NOT check 
    the basic constraint extension while verifying a signature on a CRL.&nbsp; 
    It need to ensure that the cRLSign bit is set in the keyUsage 
    extension.</FONT><BR></BLOCKQUOTE>
  <BLOCKQUOTE><FONT size=-1>-----Original Message-----</FONT><BR><FONT 
    size=-1>From: Housley, Russ [</FONT><A 
    href="mailto:[e-mail]"><FONT 
    size=-1>mailto:[e-mail]</FONT></A><FONT 
    size=-1>]</FONT><BR><FONT size=-1>Sent: Tuesday, April 24, 2001 10:37 
    AM</FONT><BR><FONT size=-1>To: [e-mail]</FONT><BR><FONT 
    size=-1>Subject: keyCertSign and cRLSign Key Usage 
Bits</FONT><BR></BLOCKQUOTE>
  <BLOCKQUOTE><BR></BLOCKQUOTE>
  <BLOCKQUOTE><FONT size=-1>The consensus on these bits is not totally clear 
    to me.&nbsp; Yet, several</FONT><BR><FONT size=-1>points have been 
    consistently, and I think that the following text</FONT><BR><FONT 
    size=-1>incorporates them.&nbsp; The debate regarding he linkage between 
    these bits and</FONT><BR><FONT size=-1>the cA bit in the basic constraints 
    extension does not seem to be over, and</FONT><BR><FONT size=-1>I have not 
    made any changes in that area.&nbsp; Please use this new thread 
    to</FONT><BR><FONT size=-1>discuss any remaining unresolved 
    points.</FONT><BR></BLOCKQUOTE>
  <BLOCKQUOTE><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The 
    keyCertSign bit is asserted when the subject public key is</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for verifying a signature 
    on public key certificates.&nbsp; This</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit MUST only be asserted in CA 
    certificates.&nbsp; If the keyCertSign</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit is asserted, then the cA 
    bit in the basic constraints</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension (see 4.2.1.10) MUST 
    also be asserted.&nbsp; If neither the</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the keyCertSign 
    bit are asserted, then the cA bit</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic constraints 
    extension MUST NOT be asserted.</FONT><BR></BLOCKQUOTE>
  <BLOCKQUOTE><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign 
    bit is asserted when the subject public key is used</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for verifying a signature on a 
    certificate revocation list (e.g.,</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CRL or an ARL).&nbsp; This 
    bit MUST be asserted in CA and Attribute</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authority (AA) certificates 
    that are used to verify signatures on</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRLs.&nbsp; If the cRLSign bit 
    is asserted in a CA certificate, then</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cA bit in the basic 
    constraints extension (see 4.2.1.10) MUST</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; also be asserted.&nbsp; If the 
    cRLSign bit is asserted in a AA</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate, then the cA bit in 
    the basic constraints extension</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST NOT be asserted.&nbsp; 
    Such AA certificates MUST NOT be used to</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify signatures on CRLs 
    containing revocation information for</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public key certificates; 
    however, these AA certificates MAY be</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify signatures on 
    CRLs containing revocation</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information concerning 
    attribute certificates.&nbsp; If neither the</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the keyCertSign 
    bit are asserted, then the cA bit</FONT><BR><FONT 
    size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic constraints 
    extension MUST NOT be asserted.</FONT><BR></BLOCKQUOTE>
  <BLOCKQUOTE><FONT size=-1>Russ</FONT></BLOCKQUOTE></BLOCKQUOTE>
<DIV><BR></DIV></BODY></HTML>

------_=_NextPart_001_01C0CE4B.5758CB80--


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA01022 for <[e-mail]>; Thu, 26 Apr 2001 04:21:14 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28072; Thu, 26 Apr 2001 07:21:14 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-josefsson-pkix-dns-00.txt
Date: Thu, 26 Apr 2001 07:21:13 -0400
Sender: [e-mail]

--NextPart

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


	Title		: Internet X.509 Public Key Infrastructure Operational 
                          Protocols - DNS
	Author(s)	: S. Josefsson
	Filename	: draft-josefsson-pkix-dns-00.txt
	Pages		: 9
	Date		: 25-Apr-01
	
The protocol conventions described in this document satisfy some of
the operational requirements of the Internet Public Key
Infrastructure (PKI).  This document specifies the conventions for
using the Domain Name System (DNS) to obtain certificates and
certificate revocation lists (CRLs) from PKI repositories. 
Additional mechanisms addressing PKIX operational requirements are
specified in separate documents.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-josefsson-pkix-dns-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-josefsson-pkix-dns-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-josefsson-pkix-dns-00.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA00817 for <[e-mail]>; Thu, 26 Apr 2001 04:20:09 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27850; Thu, 26 Apr 2001 07:20:09 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-2797-bis-00.txt
Date: Thu, 26 Apr 2001 07:20:08 -0400
Sender: [e-mail]

--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		: Certificate Management Messages over CMS
	Author(s)	: M. Myers, X. Liu, J. Schaad, J. Weinstein
	Filename	: draft-ietf-pkix-2797-bis-00.txt
	Pages		: 
	Date		: 09-Mar-01
	
This document defines a Certificate Management protocol using CMS
(CMC).  This protocol addresses two immediate needs within the
Internet PKI community:
1. The need for an interface to public key certification products
and    services based on [CMS] and [PKCS10], and
2. The need in [SMIMEV3] for a certificate enrollment protocol for
DSA-signed certificates with Diffie-Hellman public keys.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-2797-bis-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-2797-bis-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-2797-bis-00.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA14881 for <[e-mail]>; Thu, 26 Apr 2001 01:24:26 -0700 (PDT)
From: [e-mail]
Received: from frmta004.netfr.alcatel.fr (frmta004.netfr.alcatel.fr [155.132.182.160]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id KAA16156 for <[e-mail]>; Thu, 26 Apr 2001 10:24:11 +0200 (MET DST)
Received: by frmta004.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C1256A3A.002E2211 ; Thu, 26 Apr 2001 10:23:53 +0200
X-Lotus-FromDomain: ALCATEL
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 26 Apr 2001 10:23:47 +0200
Subject: unsubscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

unsubscribe




Received: from blue01.identrus.com ([216.213.93.123]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA20504 for <[e-mail]>; Wed, 25 Apr 2001 17:48:39 -0700 (PDT)
Received: by BLUE01 with Internet Mail Service (5.5.2653.19) id <JP9YGWYA>; Wed, 25 Apr 2001 20:46:58 -0400
Message-ID: <2B55DABB95C4D4119C1300508BD953F11442D5@BLUE01>
From: Dave Oshman <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Date: Wed, 25 Apr 2001 20:46:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CDEA.5FD1CC00"

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_01C0CDEA.5FD1CC00
Content-Type: text/plain;
	charset="iso-8859-1"

Steve--
2459 does not seem to disallow this now. It is simply not clear on it. I
agree that the standard needs to be unambiguous. We need to clearly define
what CA=true means. If it means the PK in this cert is used to verify
signatures on certificates, then this means that the CA flag should not be
set for a CRL Signing certificate.
Regards,
Dave

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, April 25, 2001 3:51 PM
To: Ambarish Malpani
Cc: [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits


At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:

 

I agree, also.


Ambarish


I disagree. We need to make a decision on whether a cert without a CA flag
enabled can sign CRLs. If so, then we need to modify a lot of text in 2459,
and in X.509, to say this clearly. Suggesting that a client be "forgiving"
in this context is not a viable proposal for a standard.

Steve


 

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


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 8:22 AM
To: Housley, Russ; [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits


Russ: I agree with the text.


I also know that Steve Kent and Sharon Boeyen feel that X.509 states that
only CA can issue CRL (the context of my comments being PKI only and not
PMI).


But, using the theory that you suggest that the client be forgiving, I would
consider a client compliant if it did NOT check the basic constraint
extension while verifying a signature on a CRL.  It need to ensure that the
cRLSign bit is set in the keyUsage extension.


-----Original Message-----
From: Housley, Russ [  <mailto:[e-mail]>
mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 10:37 AM
To: [e-mail]
Subject: keyCertSign and cRLSign Key Usage Bits



The consensus on these bits is not totally clear to me.  Yet, several
points have been consistently, and I think that the following text
incorporates them.  The debate regarding he linkage between these bits and
the cA bit in the basic constraints extension does not seem to be over, and
I have not made any changes in that area.  Please use this new thread to
discuss any remaining unresolved points.


       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on public key certificates.  This
       bit MUST only be asserted in CA certificates.  If the keyCertSign
       bit is asserted, then the cA bit in the basic constraints
       extension (see 4.2.1.10) MUST also be asserted.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.


       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on a certificate revocation list (e.g.,
       a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
       Authority (AA) certificates that are used to verify signatures on
       CRLs.  If the cRLSign bit is asserted in a CA certificate, then
       the cA bit in the basic constraints extension (see 4.2.1.10) MUST
       also be asserted.  If the cRLSign bit is asserted in a AA
       certificate, then the cA bit in the basic constraints extension
       MUST NOT be asserted.  Such AA certificates MUST NOT be used to
       verify signatures on CRLs containing revocation information for
       public key certificates; however, these AA certificates MAY be
       used to verify signatures on CRLs containing revocation
       information concerning attribute certificates.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.


Russ



------_=_NextPart_001_01C0CDEA.5FD1CC00
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">
<TITLE>RE: keyCertSign and cRLSign Key Usage Bits</TITLE>

<STYLE type=3Dtext/css>BLOCKQUOTE {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
DL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
UL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
OL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
LI {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D212354400-26042001>Steve--</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D212354400-26042001>2459=20
does not seem to disallow this now. It is simply not clear on it. I =
agree that=20
the standard needs to be unambiguous. We need to clearly define what =
CA=3Dtrue=20
means. If it means the PK in this cert is used to verify signatures on=20
certificates, then this means that the CA flag should not be set for a =
CRL=20
Signing certificate.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D212354400-26042001>Regards,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D212354400-26042001>Dave</SPAN></FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Stephen Kent=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, April 25, 2001 3:51=20
  PM<BR><B>To:</B> Ambarish Malpani<BR><B>Cc:</B>=20
  [e-mail]<BR><B>Subject:</B> RE: keyCertSign and cRLSign Key =
Usage=20
  Bits<BR><BR></DIV></FONT>
  <DIV>At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:</DIV>
  <BLOCKQUOTE cite type=3D"cite">&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE cite type=3D"cite"><FONT color=3D#0000ff face=3DArial =
size=3D-1>I agree,=20
    also.</FONT></BLOCKQUOTE>
  <BLOCKQUOTE cite type=3D"cite"><FONT color=3D#0000ff face=3DArial=20
    size=3D-1><BR>Ambarish</FONT></BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>I disagree. We need to make a decision on whether a cert without =
a CA=20
  flag enabled can sign CRLs. If so, then we need to modify a lot of =
text in=20
  2459, and in X.509, to say this clearly. Suggesting that a client be=20
  "forgiving" in this context is not a viable proposal for a =
standard.</DIV>
  <DIV><BR>Steve</DIV>
  <BLOCKQUOTE cite type=3D"cite"><BR>&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE cite type=3D"cite"><FONT=20
    =
size=3D-1>--------------------------------------------------------------=
-------<BR>Ambarish=20
    =
Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;=20
    650.567.5457<BR>ValiCert,=20
    =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN></=
SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
    [e-mail]<BR>339 N. Bernardo=20
    =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN></=
SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
SPAN></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=20
    <A href=3D"http://www.valicert.com/"><FONT=20
    size=3D-1>http://www.valicert.com</FONT></A><FONT =
size=3D-1><BR>Mountain View,=20
    CA 94043</FONT><BR>
    <BLOCKQUOTE><FONT face=3DTahoma size=3D-1>-----Original=20
      Message-----<BR><B>From:</B> Santosh Chokhani=20
      [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, April 24, =
2001=20
      8:22 AM<BR><B>To:</B> Housley, Russ; =
[e-mail]<BR><B>Subject:</B>=20
      RE: keyCertSign and cRLSign Key Usage Bits</FONT><BR><FONT =
face=3DTahoma=20
      size=3D-1></FONT></BLOCKQUOTE>
    <BLOCKQUOTE><FONT size=3D-1>Russ: I agree with the=20
    text.</FONT><BR></BLOCKQUOTE>
    <BLOCKQUOTE><FONT size=3D-1>I also know that Steve Kent and Sharon =
Boeyen=20
      feel that X.509 states that only CA can issue CRL (the context of =
my=20
      comments being PKI only and not PMI).</FONT><BR></BLOCKQUOTE>
    <BLOCKQUOTE><FONT size=3D-1>But, using the theory that you suggest =
that the=20
      client be forgiving, I would consider a client compliant if it =
did NOT=20
      check the basic constraint extension while verifying a signature =
on a=20
      CRL.&nbsp; It need to ensure that the cRLSign bit is set in the =
keyUsage=20
      extension.</FONT><BR></BLOCKQUOTE>
    <BLOCKQUOTE><FONT size=3D-1>-----Original =
Message-----</FONT><BR><FONT=20
      size=3D-1>From: Housley, Russ [</FONT><A=20
      href=3D"mailto:[e-mail]"><FONT=20
      size=3D-1>mailto:[e-mail]</FONT></A><FONT=20
      size=3D-1>]</FONT><BR><FONT size=3D-1>Sent: Tuesday, April 24, =
2001 10:37=20
      AM</FONT><BR><FONT size=3D-1>To: =
[e-mail]</FONT><BR><FONT=20
      size=3D-1>Subject: keyCertSign and cRLSign Key Usage=20
    Bits</FONT><BR></BLOCKQUOTE>
    <BLOCKQUOTE><BR></BLOCKQUOTE>
    <BLOCKQUOTE><FONT size=3D-1>The consensus on these bits is not =
totally clear=20
      to me.&nbsp; Yet, several</FONT><BR><FONT size=3D-1>points have =
been=20
      consistently, and I think that the following text</FONT><BR><FONT =

      size=3D-1>incorporates them.&nbsp; The debate regarding he =
linkage between=20
      these bits and</FONT><BR><FONT size=3D-1>the cA bit in the basic =
constraints=20
      extension does not seem to be over, and</FONT><BR><FONT =
size=3D-1>I have not=20
      made any changes in that area.&nbsp; Please use this new thread=20
      to</FONT><BR><FONT size=3D-1>discuss any remaining unresolved=20
      points.</FONT><BR></BLOCKQUOTE>
    <BLOCKQUOTE><FONT size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The=20
      keyCertSign bit is asserted when the subject public key =
is</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for verifying =
a=20
      signature on public key certificates.&nbsp; This</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit MUST only be =
asserted in=20
      CA certificates.&nbsp; If the keyCertSign</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit is asserted, =
then the cA=20
      bit in the basic constraints</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension (see =
4.2.1.10) MUST=20
      also be asserted.&nbsp; If neither the</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor =
the=20
      keyCertSign bit are asserted, then the cA bit</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic =
constraints=20
      extension MUST NOT be asserted.</FONT><BR></BLOCKQUOTE>
    <BLOCKQUOTE><FONT size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The cRLSign=20
      bit is asserted when the subject public key is =
used</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for verifying a =
signature on=20
      a certificate revocation list (e.g.,</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CRL or an =
ARL).&nbsp; This=20
      bit MUST be asserted in CA and Attribute</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authority (AA) =
certificates=20
      that are used to verify signatures on</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRLs.&nbsp; If the =
cRLSign=20
      bit is asserted in a CA certificate, then</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cA bit in the =
basic=20
      constraints extension (see 4.2.1.10) MUST</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; also be =
asserted.&nbsp; If=20
      the cRLSign bit is asserted in a AA</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate, then =
the cA bit=20
      in the basic constraints extension</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST NOT be =
asserted.&nbsp;=20
      Such AA certificates MUST NOT be used to</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify signatures =
on CRLs=20
      containing revocation information for</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public key =
certificates;=20
      however, these AA certificates MAY be</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify =
signatures on=20
      CRLs containing revocation</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information =
concerning=20
      attribute certificates.&nbsp; If neither the</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor =
the=20
      keyCertSign bit are asserted, then the cA bit</FONT><BR><FONT=20
      size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic =
constraints=20
      extension MUST NOT be asserted.</FONT><BR></BLOCKQUOTE>
    <BLOCKQUOTE><FONT size=3D-1>Russ</FONT></BLOCKQUOTE></BLOCKQUOTE>
  <DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0CDEA.5FD1CC00--


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA20072 for <[e-mail]>; Wed, 25 Apr 2001 17:37:40 -0700 (PDT)
Received: from [128.33.238.17] (TC017.BBN.COM [128.33.238.17]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA14952; Wed, 25 Apr 2001 20:37:39 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05010400b70cdaa78f2e@[128.33.238.94]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 25 Apr 2001 15:50:45 -0400
To: Ambarish Malpani <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1223877090==_ma============"

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

At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:
>
>I agree, also.
>
>Ambarish

I disagree. We need to make a decision on whether a cert without a CA 
flag enabled can sign CRLs. If so, then we need to modify a lot of 
text in 2459, and in X.509, to say this clearly. Suggesting that a 
client be "forgiving" in this context is not a viable proposal for a 
standard.

Steve
>
>
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect                                                650.567.5457
>ValiCert, Inc.                                  [e-mail]
>339 N. Bernardo Ave.                          
><http://www.valicert.com/>http://www.valicert.com
>Mountain View, CA 94043
>
>-----Original Message-----
>From: Santosh Chokhani [mailto:[e-mail]]
>Sent: Tuesday, April 24, 2001 8:22 AM
>To: Housley, Russ; [e-mail]
>Subject: RE: keyCertSign and cRLSign Key Usage Bits
>
>Russ: I agree with the text.
>
>I also know that Steve Kent and Sharon Boeyen feel that X.509 states 
>that only CA can issue CRL (the context of my comments being PKI 
>only and not PMI).
>
>But, using the theory that you suggest that the client be forgiving, 
>I would consider a client compliant if it did NOT check the basic 
>constraint extension while verifying a signature on a CRL.  It need 
>to ensure that the cRLSign bit is set in the keyUsage extension.
>
>-----Original Message-----
>From: Housley, Russ 
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Tuesday, April 24, 2001 10:37 AM
>To: [e-mail]
>Subject: keyCertSign and cRLSign Key Usage Bits
>
>
>The consensus on these bits is not totally clear to me.  Yet, several
>points have been consistently, and I think that the following text
>incorporates them.  The debate regarding he linkage between these bits and
>the cA bit in the basic constraints extension does not seem to be over, and
>I have not made any changes in that area.  Please use this new thread to
>discuss any remaining unresolved points.
>
>        The keyCertSign bit is asserted when the subject public key is
>        used for verifying a signature on public key certificates.  This
>        bit MUST only be asserted in CA certificates.  If the keyCertSign
>        bit is asserted, then the cA bit in the basic constraints
>        extension (see 4.2.1.10) MUST also be asserted.  If neither the
>        cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
>        in the basic constraints extension MUST NOT be asserted.
>
>        The cRLSign bit is asserted when the subject public key is used
>        for verifying a signature on a certificate revocation list (e.g.,
>        a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
>        Authority (AA) certificates that are used to verify signatures on
>        CRLs.  If the cRLSign bit is asserted in a CA certificate, then
>        the cA bit in the basic constraints extension (see 4.2.1.10) MUST
>        also be asserted.  If the cRLSign bit is asserted in a AA
>        certificate, then the cA bit in the basic constraints extension
>        MUST NOT be asserted.  Such AA certificates MUST NOT be used to
>        verify signatures on CRLs containing revocation information for
>        public key certificates; however, these AA certificates MAY be
>        used to verify signatures on CRLs containing revocation
>        information concerning attribute certificates.  If neither the
>        cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
>        in the basic constraints extension MUST NOT be asserted.
>
>Russ

--============_-1223877090==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>RE: keyCertSign and cRLSign Key Usage
Bits</title></head><body>
<div>At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:</div>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#0000FF">I agree, also.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#0000FF"><br>
Ambarish</font></blockquote>
<div><br></div>
<div>I disagree. We need to make a decision on whether a cert without
a CA flag enabled can sign CRLs. If so, then we need to modify a lot
of text in 2459, and in X.509, to say this clearly. Suggesting that a
client be &quot;forgiving&quot; in this context is not a viable
proposal for a standard.</div>
<div><br>
Steve</div>
<blockquote type="cite" cite>&nbsp;<br>
</blockquote>
<blockquote type="cite" cite><font
size="-1"
>---------------------------------------------------------------------<br
>
Ambarish Malpani<br>
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; 650.567.5457<br>
ValiCert,
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[e-mail]<br>
339 N. Bernardo
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;</font> <a
href="http://www.valicert.com/"><font
size="-1">http://www.valicert.com</font></a><font size="-1"><br>
Mountain View, CA 94043</font><br>
<blockquote><font face="Tahoma" size="-1">-----Original
Message-----<br>
<b>From:</b> Santosh Chokhani [mailto:[e-mail]]<br>
<b>Sent:</b> Tuesday, April 24, 2001 8:22 AM<br>
<b>To:</b> Housley, Russ; [e-mail]<br>
<b>Subject:</b> RE: keyCertSign and cRLSign Key Usage Bits</font><br>
<font face="Tahoma" size="-1"></font></blockquote>
<blockquote><font size="-1">Russ: I agree with the text.</font><br>
</blockquote>
<blockquote><font size="-1">I also know that Steve Kent and Sharon
Boeyen feel that X.509 states that only CA can issue CRL (the context
of my comments being PKI only and not PMI).</font><br>
</blockquote>
<blockquote><font size="-1">But, using the theory that you suggest
that the client be forgiving, I would consider a client compliant if
it did NOT check the basic constraint extension while verifying a
signature on a CRL.&nbsp; It need to ensure that the cRLSign bit is
set in the keyUsage extension.</font><br>
</blockquote>
<blockquote><font size="-1">-----Original Message-----</font><br>
<font size="-1">From: Housley, Russ [</font><a
href="mailto:[e-mail]"><font
size="-1">mailto:[e-mail]</font></a><font
size="-1">]</font><br>
<font size="-1">Sent: Tuesday, April 24, 2001 10:37 AM</font><br>
<font size="-1">To: [e-mail]</font><br>
<font size="-1">Subject: keyCertSign and cRLSign Key Usage
Bits</font><br>
</blockquote>
<blockquote><br></blockquote>
<blockquote><font size="-1">The consensus on these bits is not totally
clear to me.&nbsp; Yet, several</font><br>
<font size="-1">points have been consistently, and I think that the
following text</font><br>
<font size="-1">incorporates them.&nbsp; The debate regarding he
linkage between these bits and</font><br>
<font size="-1">the cA bit in the basic constraints extension does not
seem to be over, and</font><br>
<font size="-1">I have not made any changes in that area.&nbsp; Please
use this new thread to</font><br>
<font size="-1">discuss any remaining unresolved points.</font><br>
</blockquote>
<blockquote><font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The
keyCertSign bit is asserted when the subject public key is</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for
verifying a signature on public key certificates.&nbsp;
This</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit MUST only be
asserted in CA certificates.&nbsp; If the keyCertSign</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit is asserted,
then the cA bit in the basic constraints</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension (see
4.2.1.10) MUST also be asserted.&nbsp; If neither the</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor
the keyCertSign bit are asserted, then the cA bit</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic
constraints extension MUST NOT be asserted.</font><br>
</blockquote>
<blockquote><font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The
cRLSign bit is asserted when the subject public key is used</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for verifying a
signature on a certificate revocation list (e.g.,</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CRL or an
ARL).&nbsp; This bit MUST be asserted in CA and Attribute</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authority (AA)
certificates that are used to verify signatures on</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRLs.&nbsp; If
the cRLSign bit is asserted in a CA certificate, then</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cA bit in the
basic constraints extension (see 4.2.1.10) MUST</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; also be
asserted.&nbsp; If the cRLSign bit is asserted in a AA</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate, then
the cA bit in the basic constraints extension</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST NOT be
asserted.&nbsp; Such AA certificates MUST NOT be used to</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify signatures
on CRLs containing revocation information for</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public key
certificates; however, these AA certificates MAY be</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify
signatures on CRLs containing revocation</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information
concerning attribute certificates.&nbsp; If neither the</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor
the keyCertSign bit are asserted, then the cA bit</font><br>
<font size="-1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic
constraints extension MUST NOT be asserted.</font><br>
</blockquote>
<blockquote><font size="-1">Russ</font></blockquote>
</blockquote>
<div><br></div>
</body>
</html>
--============_-1223877090==_ma============--


Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA16427 for <[e-mail]>; Wed, 25 Apr 2001 14:23:18 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id OAA10894; Wed, 25 Apr 2001 14:22:48 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id OAA23360; Wed, 25 Apr 2001 14:22:48 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 25 Apr 2001 14:27:44 -0700
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix -new-part1-06.txt comments)
Cc: Sharon Boeyen <[e-mail]>, Peter Williams <[e-mail]>
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Sharon and Peter,

Thank you both for the explanations.  I now understand that an
"attribute certificate" does NOT certify a key.  Thus, an "AA"
is not an "[Attribute] Certificate Authority" (A-CA) but rather
is an "[Attribute Certificate] Authority]" (AC-A).  What is
called a "CA" is actually a "(Public) Key Certificate Authority".

Are there no instruments that attest (e.g.):

    "(anonymous) signer with this key is 21 years old"?

That is, bind a "key to attributes, sans DN/Identity"?
Could a CA do this using PMI extension attributes?

Finally, does anyone know if the PKIX "CRL/ARL" maps to
CARL/AARL?  And does this imply that no one can sign or
verify a list containing both PKC and AC revocations?

Thanks again for your previous (extensive) response!

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA14457 for <[e-mail]>; Wed, 25 Apr 2001 12:40:49 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <J43HQZK7>; Wed, 25 Apr 2001 15:40:19 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, "David A. Cooper" <[e-mail]>, [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix -new-part1-06.txt comments)
Date: Wed, 25 Apr 2001 15:34:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CDBE.C166BD30"

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_01C0CDBE.C166BD30
Content-Type: text/plain;
	charset="iso-8859-1"

Tony, since PKIX profiles 509, here are answers from that standard. While
PKIX may 
use different language to describe these, they should still be aligned with
the 
basic definitions. 

Hope that helps
Sharon

> -----Original Message-----
> From: Tony Bartoletti [mailto:[e-mail]]
> Sent: Wednesday, April 25, 2001 2:54 PM
> To: David A. Cooper; [e-mail]
> Subject: Re: cA flag and CRL issuers (was Re: Last Call:
> draft-ietf-pkix-new-part1-06.txt comments)
> 
> 
> All,
> 
> In trying to parse this issue (and Russ Housley's previous 
> proposed text) it
> appears that terminology needs a bit of shoring up, at least for me.
> 
> Can anyone answer these "simple" questions?
> 
> 1.  Is a "CA Certificate" defined to be:
> 
>      a.  A certificate whose subject is a CA
>      b.  A certificate with "cA" bit set.
>      c.  A certificate with either kCertSign or cRLSign set?
> 
>          (Are (a) and (b) equivalent "if its a CA certificate"?)

Clause 7 "A CA-certificate is a certificate issued by a CA to a subject that
is itslef a CA and therefore is capable of issuing public-key certificates."
It then goes on to define the different types of CA-certificate (Self
issued, Self signed and cross).

No a) and b) are not strictly equivalent. Clause 8.4.2.1 on basic
constraints "...with the certified public key being used to verify
certificate signatures", that's the key to use of that bit in the extension.
> 
> 2.  Is the term "public key certificate" intended to represent:
> 
>      a.  Only certificates that bind keys to "DN/Identity"
>      b.  Certificates that bind keys to anything (e.g., "attributes")
> 
>      For instance, is an "Attribute Certificate" considered to be a
>      subset of "public key certificates", or not?

No, attribute certificates are not subsets of public-key certificates. They
are 
'certificates' but do NOT contain a public-key and are therefore not a
subset.
(see 3.3.1 and 3.3.4.4)
> 
> 3.  Is an "AA" considered to be:
> 
>      a.  A "CA that certifies attributes and not DN/Identity",
>          (yet still a CA, since they author/authorize certificates.)
>      b.  Not a CA, since the term CA is "reserved" to "DN/Identity"
> 

No an AA is not a CA of any sort. CA is an authority for public-key
certificates only and AA is an authority for attribute certificates only 
(see 3.3.2 and 3.3.16. The term 'authority' used alone is defined to include
both (see 3.3.6). 

> 4.  Is an "AA Certificate" a form of "CA Certificate" or not?
>      (Answer should be derived from response to (3).

No. (as per response to 3)  
> 
> 5.  If both "CRLs and ARLs" are examples of "certificate 
> revocation lists"
>      then is an ARL:
> 
>      a.  An instance of CRL (that happens not to revoke any 
> DN/ID certs)?
>      b.  Never a CRL, since every CRL involves DN/ID certificates?

Actually 509 added specific acronyms for each type of CRL. What used 
to be called an "ARL" (Authority Revocation List) is now a "CARL" 
Certification Authority Revocation List) and is a revocation list of
public-key
certificates issued to CAs that are no longer considered valid by the 
certificate issuer (3.3.17). The equivalent of that for attribute
authorities 
would be an AARL (Attribute Authority Revocation List)as defined in 3.3.3.  

> 
> I submit that more than half of the dialogs/debates on this list can
> be traced to confusion regarding these fundamental terms.
> 
> ___tony___
> 
> 
> At 01:25 PM 4/25/01 -0400, David A. Cooper wrote:
> >Steve,
> >
> >If we are going to change PKIX to require the cA bit in 
> basicConstraints 
> >to be set even when the subject public key can only be used 
> to verify 
> >signatures on CRLs, then we need to be sure that the text 
> clearly explains 
> >to readers when the cA bit should or should not be set. Currently 
> >new-part1-06 states that "[t]he cA bit indicates if the 
> certified public 
> >key may be used to verify signatures on other certificates." 
> The clearly 
> >is not accurate, since if the cA bit is set one still does not know 
> >whether the subject public key may be used to verify signatures on 
> >certificates. One must look at the keyUsage extension to make that 
> >determination.
> >
> >I think it would be helpful to the discussion that we are 
> having if you 
> >would clearly state your interpretation of the meaning of 
> the cA bit in 
> >basicConstraints.
> >
> >  From what I have read so far, it appears that you believe 
> that the cA 
> > bit should be used to indicate if the subject of the 
> certificate is a CA. 
> > But, if this is the case, then new-part1-06 still does not 
> accurately 
> > reflect your notion of the cA bit. Currently the text 
> states that the cA 
> > bit may only be set if the keyCertSign bit or the cRLSign 
> bit in keyUsage 
> > is set. However, a CA does more than just issue 
> certificates and CRLs. A 
> > CA may have a private key dedicated to signing PKI 
> transaction messages 
> > (e.g., certification response, revocation response, 
> proof-of-possession 
> > challenge). If a certificate were issued to a CA with its 
> PKI transaction 
> > message verification key as the subject public key, neither the 
> > keyCertSign nor the cRLSign bit in KeyUsage would be set, 
> but the subject 
> > of the certificate would still be a CA.
> >
> >So, should the cA bit be used to indicate if the certificate 
> subject is a 
> >CA or to indicate that the subject public key may be used to verify 
> >signatures on certificates and/or CRLs? If the latter, then not all 
> >certificates issued to CAs will have the cA bit set.
> >
> >Dave
> >
> >At 01:31 PM 4/20/01 -0400, Stephen Kent wrote:
> > >>The description of basic constraints in X.509 further 
> supports the idea 
> > that the cA bit is used to specify certificate issuing, not 
> certificate 
> > and/or CRL issuing:
> > >>
> > >>"This field indicates if the subject may act as a CA, with the 
> > certified public key being used to verify certificate 
> signatures. ... The 
> > cA component indicates if the certified public key may be 
> used to verify 
> > certificate signatures. ... if the value of cA is not set to 
> true then the 
> > certified public key shall not be used to verify a 
> certificate signature"
> > >>
> > >>
> > >>pkix-new-part1-05 states something similar:
> > >>
> > >>"The cA bit indicates if the certified public key may be 
> used to verify 
> > signatures on other certificates. If the cA bit is 
> asserted, then the 
> > keyCertSign bit in the key usage extension (see 4.2.1.3) 
> MUST also be 
> > asserted. If the cA bit is not asserted, then the 
> keyCertSign bit in the 
> > key usage extension MUST NOT be asserted."
> > >
> > >again, this supports the notion that a CA signs certs, but it says 
> > nothing about whether a CA or some other entity signs CRLs. We have 
> > uncovered a number of instances where less than perfect 
> wording has lead 
> > to confusion and our recent dialogue suggests that some of 
> the quotes you 
> > cite are examples of this.
> 
> Tony Bartoletti 925-422-3881 <[e-mail]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900
> 
> 
> 
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: cA flag and CRL issuers (was Re: Last Call:   =
draft-ietf-pkix-new-part1-06.txt comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Tony, since PKIX profiles 509, here are answers from =
that standard. While PKIX may </FONT>
<BR><FONT SIZE=3D2>use different language to describe these, they =
should still be aligned with the </FONT>
<BR><FONT SIZE=3D2>basic definitions. </FONT>
</P>

<P><FONT SIZE=3D2>Hope that helps</FONT>
<BR><FONT SIZE=3D2>Sharon</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Tony Bartoletti [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, April 25, 2001 2:54 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: David A. Cooper; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: cA flag and CRL issuers (was Re: =
Last Call:</FONT>
<BR><FONT SIZE=3D2>&gt; draft-ietf-pkix-new-part1-06.txt =
comments)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In trying to parse this issue (and Russ =
Housley's previous </FONT>
<BR><FONT SIZE=3D2>&gt; proposed text) it</FONT>
<BR><FONT SIZE=3D2>&gt; appears that terminology needs a bit of shoring =
up, at least for me.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Can anyone answer these &quot;simple&quot; =
questions?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1.&nbsp; Is a &quot;CA Certificate&quot; =
defined to be:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.&nbsp; A =
certificate whose subject is a CA</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.&nbsp; A =
certificate with &quot;cA&quot; bit set.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c.&nbsp; A =
certificate with either kCertSign or cRLSign set?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(Are (a) and (b) equivalent &quot;if its a CA =
certificate&quot;?)</FONT>
</P>

<P><FONT SIZE=3D2>Clause 7 &quot;A CA-certificate is a certificate =
issued by a CA to a subject that is itslef a CA and therefore is =
capable of issuing public-key certificates.&quot; It then goes on to =
define the different types of CA-certificate (Self issued, Self signed =
and cross).</FONT></P>

<P><FONT SIZE=3D2>No a) and b) are not strictly equivalent. Clause =
8.4.2.1 on basic constraints &quot;...with the certified public key =
being used to verify certificate signatures&quot;, that's the key to =
use of that bit in the extension.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2.&nbsp; Is the term &quot;public key =
certificate&quot; intended to represent:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.&nbsp; Only =
certificates that bind keys to &quot;DN/Identity&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.&nbsp; =
Certificates that bind keys to anything (e.g., =
&quot;attributes&quot;)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For instance, is =
an &quot;Attribute Certificate&quot; considered to be a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; subset of =
&quot;public key certificates&quot;, or not?</FONT>
</P>

<P><FONT SIZE=3D2>No, attribute certificates are not subsets of =
public-key certificates. They are </FONT>
<BR><FONT SIZE=3D2>'certificates' but do NOT contain a public-key and =
are therefore not a subset.</FONT>
<BR><FONT SIZE=3D2>(see 3.3.1 and 3.3.4.4)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 3.&nbsp; Is an &quot;AA&quot; considered to =
be:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.&nbsp; A =
&quot;CA that certifies attributes and not DN/Identity&quot;,</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(yet still a CA, since they author/authorize certificates.)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.&nbsp; Not a =
CA, since the term CA is &quot;reserved&quot; to =
&quot;DN/Identity&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>No an AA is not a CA of any sort. CA is an authority =
for public-key</FONT>
<BR><FONT SIZE=3D2>certificates only and AA is an authority for =
attribute certificates only </FONT>
<BR><FONT SIZE=3D2>(see 3.3.2 and 3.3.16. The term 'authority' used =
alone is defined to include</FONT>
<BR><FONT SIZE=3D2>both (see 3.3.6). </FONT>
</P>

<P><FONT SIZE=3D2>&gt; 4.&nbsp; Is an &quot;AA Certificate&quot; a form =
of &quot;CA Certificate&quot; or not?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Answer should be =
derived from response to (3).</FONT>
</P>

<P><FONT SIZE=3D2>No. (as per response to 3)&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 5.&nbsp; If both &quot;CRLs and ARLs&quot; are =
examples of &quot;certificate </FONT>
<BR><FONT SIZE=3D2>&gt; revocation lists&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; then is an =
ARL:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.&nbsp; An =
instance of CRL (that happens not to revoke any </FONT>
<BR><FONT SIZE=3D2>&gt; DN/ID certs)?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.&nbsp; Never a =
CRL, since every CRL involves DN/ID certificates?</FONT>
</P>

<P><FONT SIZE=3D2>Actually 509 added specific acronyms for each type of =
CRL. What used </FONT>
<BR><FONT SIZE=3D2>to be called an &quot;ARL&quot; (Authority =
Revocation List) is now a &quot;CARL&quot; </FONT>
<BR><FONT SIZE=3D2>Certification Authority Revocation List) and is a =
revocation list of public-key</FONT>
<BR><FONT SIZE=3D2>certificates issued to CAs that are no longer =
considered valid by the </FONT>
<BR><FONT SIZE=3D2>certificate issuer (3.3.17). The equivalent of that =
for attribute authorities </FONT>
<BR><FONT SIZE=3D2>would be an AARL (Attribute Authority Revocation =
List)as defined in 3.3.3.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I submit that more than half of the =
dialogs/debates on this list can</FONT>
<BR><FONT SIZE=3D2>&gt; be traced to confusion regarding these =
fundamental terms.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ___tony___</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 01:25 PM 4/25/01 -0400, David A. Cooper =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Steve,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;If we are going to change PKIX to require =
the cA bit in </FONT>
<BR><FONT SIZE=3D2>&gt; basicConstraints </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;to be set even when the subject public key =
can only be used </FONT>
<BR><FONT SIZE=3D2>&gt; to verify </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;signatures on CRLs, then we need to be sure =
that the text </FONT>
<BR><FONT SIZE=3D2>&gt; clearly explains </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;to readers when the cA bit should or should =
not be set. Currently </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;new-part1-06 states that &quot;[t]he cA bit =
indicates if the </FONT>
<BR><FONT SIZE=3D2>&gt; certified public </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;key may be used to verify signatures on =
other certificates.&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; The clearly </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;is not accurate, since if the cA bit is set =
one still does not know </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;whether the subject public key may be used =
to verify signatures on </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;certificates. One must look at the keyUsage =
extension to make that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;determination.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I think it would be helpful to the =
discussion that we are </FONT>
<BR><FONT SIZE=3D2>&gt; having if you </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;would clearly state your interpretation of =
the meaning of </FONT>
<BR><FONT SIZE=3D2>&gt; the cA bit in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;basicConstraints.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; From what I have read so far, it =
appears that you believe </FONT>
<BR><FONT SIZE=3D2>&gt; that the cA </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; bit should be used to indicate if the =
subject of the </FONT>
<BR><FONT SIZE=3D2>&gt; certificate is a CA. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; But, if this is the case, then =
new-part1-06 still does not </FONT>
<BR><FONT SIZE=3D2>&gt; accurately </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; reflect your notion of the cA bit. =
Currently the text </FONT>
<BR><FONT SIZE=3D2>&gt; states that the cA </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; bit may only be set if the keyCertSign bit =
or the cRLSign </FONT>
<BR><FONT SIZE=3D2>&gt; bit in keyUsage </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; is set. However, a CA does more than just =
issue </FONT>
<BR><FONT SIZE=3D2>&gt; certificates and CRLs. A </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; CA may have a private key dedicated to =
signing PKI </FONT>
<BR><FONT SIZE=3D2>&gt; transaction messages </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (e.g., certification response, revocation =
response, </FONT>
<BR><FONT SIZE=3D2>&gt; proof-of-possession </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; challenge). If a certificate were issued =
to a CA with its </FONT>
<BR><FONT SIZE=3D2>&gt; PKI transaction </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; message verification key as the subject =
public key, neither the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; keyCertSign nor the cRLSign bit in =
KeyUsage would be set, </FONT>
<BR><FONT SIZE=3D2>&gt; but the subject </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of the certificate would still be a =
CA.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;So, should the cA bit be used to indicate =
if the certificate </FONT>
<BR><FONT SIZE=3D2>&gt; subject is a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;CA or to indicate that the subject public =
key may be used to verify </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;signatures on certificates and/or CRLs? If =
the latter, then not all </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;certificates issued to CAs will have the cA =
bit set.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Dave</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;At 01:31 PM 4/20/01 -0400, Stephen Kent =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;The description of basic =
constraints in X.509 further </FONT>
<BR><FONT SIZE=3D2>&gt; supports the idea </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that the cA bit is used to specify =
certificate issuing, not </FONT>
<BR><FONT SIZE=3D2>&gt; certificate </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and/or CRL issuing:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&quot;This field indicates if the =
subject may act as a CA, with the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certified public key being used to verify =
certificate </FONT>
<BR><FONT SIZE=3D2>&gt; signatures. ... The </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; cA component indicates if the certified =
public key may be </FONT>
<BR><FONT SIZE=3D2>&gt; used to verify </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificate signatures. ... if the value =
of cA is not set to </FONT>
<BR><FONT SIZE=3D2>&gt; true then the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certified public key shall not be used to =
verify a </FONT>
<BR><FONT SIZE=3D2>&gt; certificate signature&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;pkix-new-part1-05 states something =
similar:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&quot;The cA bit indicates if the =
certified public key may be </FONT>
<BR><FONT SIZE=3D2>&gt; used to verify </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; signatures on other certificates. If the =
cA bit is </FONT>
<BR><FONT SIZE=3D2>&gt; asserted, then the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; keyCertSign bit in the key usage extension =
(see 4.2.1.3) </FONT>
<BR><FONT SIZE=3D2>&gt; MUST also be </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; asserted. If the cA bit is not asserted, =
then the </FONT>
<BR><FONT SIZE=3D2>&gt; keyCertSign bit in the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; key usage extension MUST NOT be =
asserted.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;again, this supports the notion that a =
CA signs certs, but it says </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; nothing about whether a CA or some other =
entity signs CRLs. We have </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; uncovered a number of instances where less =
than perfect </FONT>
<BR><FONT SIZE=3D2>&gt; wording has lead </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to confusion and our recent dialogue =
suggests that some of </FONT>
<BR><FONT SIZE=3D2>&gt; the quotes you </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; cite are examples of this.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Tony Bartoletti 925-422-3881 =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Information Operations, Warfare and Assurance =
Center</FONT>
<BR><FONT SIZE=3D2>&gt; Lawrence Livermore National Laboratory</FONT>
<BR><FONT SIZE=3D2>&gt; Livermore, CA 94551-9900</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>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CDBE.C166BD30--


Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA13370 for <[e-mail]>; Wed, 25 Apr 2001 11:50:11 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id LAA16170; Wed, 25 Apr 2001 11:49:42 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA16014; Wed, 25 Apr 2001 11:49:42 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 25 Apr 2001 11:54:09 -0700
To: "David A. Cooper" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix-new-part1-06.txt comments)
In-Reply-To: <[e-mail]>
References: <p05010410b7051d55d9b1@[128.33.4.39]> <[e-mail]> <[e-mail]> <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id LAA13371

All,

In trying to parse this issue (and Russ Housley's previous proposed text) it
appears that terminology needs a bit of shoring up, at least for me.

Can anyone answer these "simple" questions?

1.  Is a "CA Certificate" defined to be:

     a.  A certificate whose subject is a CA
     b.  A certificate with "cA" bit set.
     c.  A certificate with either kCertSign or cRLSign set?

         (Are (a) and (b) equivalent "if its a CA certificate"?)

2.  Is the term "public key certificate" intended to represent:

     a.  Only certificates that bind keys to "DN/Identity"
     b.  Certificates that bind keys to anything (e.g., "attributes")

     For instance, is an "Attribute Certificate" considered to be a
     subset of "public key certificates", or not?

3.  Is an "AA" considered to be:

     a.  A "CA that certifies attributes and not DN/Identity",
         (yet still a CA, since they author/authorize certificates.)
     b.  Not a CA, since the term CA is "reserved" to "DN/Identity"

4.  Is an "AA Certificate" a form of "CA Certificate" or not?
     (Answer should be derived from response to (3).

5.  If both "CRLs and ARLs" are examples of "certificate revocation lists"
     then is an ARL:

     a.  An instance of CRL (that happens not to revoke any DN/ID certs)?
     b.  Never a CRL, since every CRL involves DN/ID certificates?

I submit that more than half of the dialogs/debates on this list can
be traced to confusion regarding these fundamental terms.

___tony___


At 01:25 PM 4/25/01 -0400, David A. Cooper wrote:
>Steve,
>
>If we are going to change PKIX to require the cA bit in basicConstraints 
>to be set even when the subject public key can only be used to verify 
>signatures on CRLs, then we need to be sure that the text clearly explains 
>to readers when the cA bit should or should not be set. Currently 
>new-part1-06 states that "[t]he cA bit indicates if the certified public 
>key may be used to verify signatures on other certificates." The clearly 
>is not accurate, since if the cA bit is set one still does not know 
>whether the subject public key may be used to verify signatures on 
>certificates. One must look at the keyUsage extension to make that 
>determination.
>
>I think it would be helpful to the discussion that we are having if you 
>would clearly state your interpretation of the meaning of the cA bit in 
>basicConstraints.
>
>  From what I have read so far, it appears that you believe that the cA 
> bit should be used to indicate if the subject of the certificate is a CA. 
> But, if this is the case, then new-part1-06 still does not accurately 
> reflect your notion of the cA bit. Currently the text states that the cA 
> bit may only be set if the keyCertSign bit or the cRLSign bit in keyUsage 
> is set. However, a CA does more than just issue certificates and CRLs. A 
> CA may have a private key dedicated to signing PKI transaction messages 
> (e.g., certification response, revocation response, proof-of-possession 
> challenge). If a certificate were issued to a CA with its PKI transaction 
> message verification key as the subject public key, neither the 
> keyCertSign nor the cRLSign bit in KeyUsage would be set, but the subject 
> of the certificate would still be a CA.
>
>So, should the cA bit be used to indicate if the certificate subject is a 
>CA or to indicate that the subject public key may be used to verify 
>signatures on certificates and/or CRLs? If the latter, then not all 
>certificates issued to CAs will have the cA bit set.
>
>Dave
>
>At 01:31 PM 4/20/01 -0400, Stephen Kent wrote:
> >>The description of basic constraints in X.509 further supports the idea 
> that the cA bit is used to specify certificate issuing, not certificate 
> and/or CRL issuing:
> >>
> >>"This field indicates if the subject may act as a CA, with the 
> certified public key being used to verify certificate signatures. … The 
> cA component indicates if the certified public key may be used to verify 
> certificate signatures. … if the value of cA is not set to true then the 
> certified public key shall not be used to verify a certificate signature"
> >>
> >>
> >>pkix-new-part1-05 states something similar:
> >>
> >>"The cA bit indicates if the certified public key may be used to verify 
> signatures on other certificates. If the cA bit is asserted, then the 
> keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also be 
> asserted. If the cA bit is not asserted, then the keyCertSign bit in the 
> key usage extension MUST NOT be asserted."
> >
> >again, this supports the notion that a CA signs certs, but it says 
> nothing about whether a CA or some other entity signs CRLs. We have 
> uncovered a number of instances where less than perfect wording has lead 
> to confusion and our recent dialogue suggests that some of the quotes you 
> cite are examples of this.

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA10270 for <[e-mail]>; Wed, 25 Apr 2001 10:25:38 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id NAA21167 for <[e-mail]>; Wed, 25 Apr 2001 13:25:38 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 25 Apr 2001 13:25:23 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix-new-part1-06.txt comments)
In-Reply-To: <p05010410b7051d55d9b1@[128.33.4.39]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA10272

Steve,

If we are going to change PKIX to require the cA bit in basicConstraints to be set even when the subject public key can only be used to verify signatures on CRLs, then we need to be sure that the text clearly explains to readers when the cA bit should or should not be set. Currently new-part1-06 states that "[t]he cA bit indicates if the certified public key may be used to verify signatures on other certificates." The clearly is not accurate, since if the cA bit is set one still does not know whether the subject public key may be used to verify signatures on certificates. One must look at the keyUsage extension to make that determination.

I think it would be helpful to the discussion that we are having if you would clearly state your interpretation of the meaning of the cA bit in basicConstraints.

 From what I have read so far, it appears that you believe that the cA bit should be used to indicate if the subject of the certificate is a CA. But, if this is the case, then new-part1-06 still does not accurately reflect your notion of the cA bit. Currently the text states that the cA bit may only be set if the keyCertSign bit or the cRLSign bit in keyUsage is set. However, a CA does more than just issue certificates and CRLs. A CA may have a private key dedicated to signing PKI transaction messages (e.g., certification response, revocation response, proof-of-possession challenge). If a certificate were issued to a CA with its PKI transaction message verification key as the subject public key, neither the keyCertSign nor the cRLSign bit in KeyUsage would be set, but the subject of the certificate would still be a CA.

So, should the cA bit be used to indicate if the certificate subject is a CA or to indicate that the subject public key may be used to verify signatures on certificates and/or CRLs? If the latter, then not all certificates issued to CAs will have the cA bit set.

Dave

At 01:31 PM 4/20/01 -0400, Stephen Kent wrote:
>>The description of basic constraints in X.509 further supports the idea that the cA bit is used to specify certificate issuing, not certificate and/or CRL issuing:
>>
>>"This field indicates if the subject may act as a CA, with the certified public key being used to verify certificate signatures. … The cA component indicates if the certified public key may be used to verify certificate signatures. … if the value of cA is not set to true then the certified public key shall not be used to verify a certificate signature"
>>
>>
>>pkix-new-part1-05 states something similar:
>>
>>"The cA bit indicates if the certified public key may be used to verify signatures on other certificates. If the cA bit is asserted, then the keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also be asserted. If the cA bit is not asserted, then the keyCertSign bit in the key usage extension MUST NOT be asserted."
>
>again, this supports the notion that a CA signs certs, but it says nothing about whether a CA or some other entity signs CRLs. We have uncovered a number of instances where less than perfect wording has lead to confusion and our recent dialogue suggests that some of the quotes you cite are examples of this.




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA08528 for <[e-mail]>; Wed, 25 Apr 2001 09:58:02 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA23749; Wed, 25 Apr 2001 12:56:55 -0400 (EDT)
Message-Id: <[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, * ALL FIREBURST USERS * <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Steve Hanna (SUN)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>
Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
Date: Wed, 25 Apr 2001 13:00:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;     boundary="------------InterScan_NT_MIME_Boundary"

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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CDA9.2E45D730"

------_=_NextPart_001_01C0CDA9.2E45D730
Content-Type: text/plain;
	charset="ISO-8859-1"

This is a reminder that showings of the Department of Defense Bridge
Certification Authority Technology Demonstration will begin tomorrow.  There
are about 110 open slots (total) for those who would like to view one of our
nine scheduled demonstrations.

If you have already registered for the demonstration, you should have
received an e-mail confirmation that you have been registered.  A network
failure here on 6 - 9 April may have prevented some of your registration
requests from being received.  If you did not receive an e-mail
confirmation, please re-register.

Demonstration dates, times, directions, and registration instructions are
included below.

Dave Fillingham
NSA

> -----Original Message-----
> From:	Fillingham,  David W. 
> Sent:	Friday, April 06, 2001 10:49 AM
> To:	'[e-mail]'; 'KPCMWG'; 'DoD PKI TWG'; '[e-mail]';
> 'Bridge CA Mail List'; 'BCA Integration'; * ALL FIREBURST USERS *; 'Steve
> Capps'; Wagner, Clark J.; '[e-mail]';
> '[e-mail]'; 'Steve Hanna (SUN)'; 'Susan Dernik'
> Subject:	DoD Bridge Certification Authority Phase II Demonstrations
> 
> For the last few years, the National Security Agency has led the
> development of Bridge Certification Authority (BCA) technology
> demonstrations.  In 1999, Phase One of the Department of Defense BCA
> Technology Demonstration showed the technical feasibility of achieving
> signed e-mail interoperability using multi-vendor cross-certification in
> conjunction with chained directory systems.
>  
> Phase Two of the demonstration is now ready to be shown.  Phase Two of the
> DoD Bridge CA Phase II Technology Demonstration includes: 
>  
> Technologies: 
>  
> --  Certificate chain building in complex certificate graphs;
> --  Integration of both mesh-style cross-certified PKIs and hierarchical
> PKIs;
> --  Multi-signature/hash algorithm processing in certificate chains;
> --  Certificate acceptance/rejection based on Certificate Policy
> processing, including policy mapping;
> --  Transitive trust limitation using Name Constraints processing;
> --  Access Control using X.509 compliant attribute certificates (same
> attribute certificates used for e-mail and web based access control);
> --  E-mail access control using S/MIME V3 labeling;
> --  E-mail encryption using public key certificates authenticated via a
> Bridge Certification Authority;
> --  Border Directories; 
> --  Multivendor directory interoperation via X.500 chaining; and,
> --  Transparent sharing of certificate revocation information across
> several  PKIs using products of multiple PKI vendors.
>  
> Client Applications: 
>  
> --  Baltimore Technologies MailSecure enabled Microsoft Outlook
> --  Entrust Enabled Microsoft Outlook
> --  Getronics S/MIME Freeware Library, Certificate Management Library, and
> Access Control Library enabled Qualcomm Eudora
> --  Getronics Certificate Management Library and Access Control Library
> enabled Netscape Web Server
>  
> Freeware Libraries:
>  
> --  Cygnacom Certificate Path Development Library
>      <http://www.cygnacom.com/products/index.htm>
> 
> --  Getronics S/MIME (Version 3) Freeware Library
>      <http://www.getronicsgov.com/hot/sfl_home.htm>
> 
> --  Getronics Certificate Management Library
>      <http://www.getronicsgov.com/hot/cml_home.htm>
> 
> -- Getronics Access Control Library
>           <http://www.getronicsgov.com/hot/acl_home.htm>
> 
> CA vendor interoperability demonstrations: 
>  
> --  Baltimore Technologies 
> --  Entrust Technologies
> --  Motorola 
> --  SPYRUS 
>  
> Directory Interoperability:
> 
> --  Entrust ICL
> --  Entegrity Safepages Directory
> 
> Demonstrations will be held at the following locations and dates (note
> that you MUST REGISTER to attend!  Registration information is provided
> below):
>  
> ----------
> CygnaCom
> Suite 100 West
> 7927 Jones Branch Dr.
> McLean, Virginia
>  
> Directions to CygnaCom are located at:
> <http://www.cygnacom.com/contact/directions.htm> 
>  
> 26 April 2001 - 0900
>  
> 26 April 2001 - 1300
>  
> 16 May 2001 - 0900
>  
> 16 May 2001 - 1300
>  
> ---------
> Getronics Government Solutions
> 141 National Business Parkway, Suite 210
> Annapolis Junction, Maryland
>  
> From Washington DC: Take I-95 north; take MD Rt 32 east exit; take Dorsey
> Run exit; at stop sign turn left on Dorsey Run; at stop light turn right
> on
> Guilford Road which becomes National Business Pkwy. 
>  
> From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit; stay
> in right lane of the exit which runs into National Business Pkwy; make a
> right on National Business Pkwy.
>  
> 30 April 2001 - 1300
>  
> 8 May 2001 - 0900
>  
> 8 May 2001 - 1300
>  
> 24 May 2001 - 0900
>  
> 24 May 2001 - 1300 
>  
> ---------
>  
> All showings last about half a day - with a mixture of conference room
> briefings and laboratory demonstrations.
>  
> We are limited by available demonstration space to an absolute maximum of
> 20 participants at each showing.  
>  
> IMPORTANT:  PLEASE REGISTER WITH LISA FAULKNER ([e-mail]
> <mailto:[e-mail]>) AND MYSELF ([e-mail]
> <mailto:[e-mail]>) IF YOU PLAN TO ATTEND.  IF YOU DO NOT
> REGISTER TO ATTEND, YOU WILL NOT BE ADMITTED TO THE DEMONSTRATION.
>  
> Please provide the following information to register:
>  
> --  Name
> --  Organization
> --  E-mail address
> --  Date and time of the demonstration showing you wish to attend (with
> alternates, if possible)
>  
> We look forward to seeing you at the demonstration!
>  
> Dave Fillingham
> NSA
> 
> 

------_=_NextPart_001_01C0CDA9.2E45D730
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: DoD Bridge Certification Authority Phase II =
Demonstrations</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">This is a reminder =
that showings of the Department of Defense Bridge Certification =
Authority Technology Demonstration will begin tomorrow.&nbsp; There are =
about 110 open slots (total) for those who would like to view one of =
our nine scheduled demonstrations.</FONT></P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">If you have already =
registered for the demonstration, you should have received an e-mail =
confirmation that you have been registered.&nbsp; A network failure =
here on 6 - 9 April may have prevented some of your registration =
requests from being received.&nbsp; If you did not receive an e-mail =
confirmation, please re-register.</FONT></P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Demonstration dates, =
times, directions, and registration instructions are included =
below.</FONT>
</P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Dave =
Fillingham</FONT>
<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">NSA</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Fillingham,&nbsp; David W. </FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, April 06, 2001 10:49 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'[e-mail]'; 'KPCMWG'; 'DoD PKI TWG'; =
'[e-mail]'; 'Bridge CA Mail List'; 'BCA Integration'; * ALL =
FIREBURST USERS *; 'Steve Capps'; Wagner, Clark J.; =
'[e-mail]'; '[e-mail]'; 'Steve =
Hanna (SUN)'; 'Susan Dernik'</FONT></P>

<P><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">DoD Bridge Certification Authority =
Phase II Demonstrations</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For the last few years, the National =
Security Agency has led the development of Bridge Certification =
Authority (BCA) technology demonstrations.&nbsp; In 1999, Phase One of =
the Department of Defense BCA Technology Demonstration showed the =
technical feasibility of achieving signed e-mail interoperability using =
multi-vendor cross-certification in conjunction with chained directory =
systems.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Phase Two of the demonstration is now =
ready to be shown.&nbsp; Phase Two of the DoD Bridge CA Phase II =
Technology Demonstration includes: </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Technologies: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Certificate chain building =
in complex certificate graphs;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Integration of both =
mesh-style cross-certified PKIs and hierarchical PKIs;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Multi-signature/hash =
algorithm processing in certificate chains;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Certificate =
acceptance/rejection based on Certificate Policy processing, including =
policy mapping;<BR>
--&nbsp; Transitive trust limitation using Name Constraints =
processing;<BR>
--&nbsp; Access Control using X.509 compliant attribute certificates =
(same attribute certificates used for e-mail and web based access =
control);</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; E-mail access control using =
S/MIME V3 labeling;<BR>
--&nbsp; E-mail encryption using public key certificates authenticated =
via a Bridge Certification Authority;<BR>
--&nbsp; Border Directories;<BR>
--&nbsp; Multivendor directory interoperation via X.500 chaining; =
and,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Transparent sharing of =
certificate revocation information across several&nbsp; PKIs using =
products of multiple PKI vendors.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Client Applications: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Baltimore Technologies =
MailSecure enabled Microsoft Outlook</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Entrust Enabled Microsoft =
Outlook<BR>
--&nbsp; Getronics S/MIME Freeware Library, Certificate Management =
Library, and Access Control Library enabled Qualcomm Eudora<BR>
--&nbsp; Getronics Certificate Management Library and Access Control =
Library enabled Netscape Web Server</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Freeware Libraries:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Cygnacom Certificate Path =
Development Library</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.cygnacom.com/products/index.htm" =
TARGET=3D"_blank">http://www.cygnacom.com/products/index.htm</A>&gt;</FO=
NT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Getronics S/MIME (Version 3) =
Freeware Library</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/sfl_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/sfl_home.htm</A>&gt;</=
FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Getronics Certificate =
Management Library</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/cml_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/cml_home.htm</A>&gt;</=
FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- Getronics Access Control =
Library</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;<A HREF=3D"http://www.getronicsgov.com/hot/acl_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/acl_home.htm</A>&gt;</=
FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">CA vendor interoperability =
demonstrations: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Baltimore Technologies<BR>
--&nbsp; Entrust Technologies<BR>
--&nbsp; Motorola<BR>
--&nbsp; SPYRUS </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Directory Interoperability:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Entrust ICL</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Entegrity Safepages =
Directory</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Demonstrations will be held at the =
following locations and dates (note that you MUST REGISTER to =
attend!&nbsp; Registration information is provided below):</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">----------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">CygnaCom</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Suite 100 West</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">7927 Jones Branch Dr.<BR>
McLean, Virginia</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Directions to CygnaCom are located =
at:&nbsp;<U> &lt;<A =
HREF=3D"http://www.cygnacom.com/contact/directions.htm" =
TARGET=3D"_blank">http://www.cygnacom.com/contact/directions.htm</A>&gt;=
</U> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">26 April 2001 - 0900</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">26 April 2001 - 1300</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">16 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">16 May 2001 - 1300</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">---------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Getronics Government Solutions</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">141 National Business Parkway, Suite =
210</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Annapolis Junction, Maryland</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From Washington DC: Take I-95 north; =
take MD Rt 32 east exit; take Dorsey</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Run exit; at stop sign turn left on =
Dorsey Run; at stop light turn right on</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Guilford Road which becomes National =
Business Pkwy. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From Baltimore: Take BW Parkway (295) =
south; take MD Rt 32 west exit; stay</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in right lane of the exit which runs =
into National Business Pkwy; make a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">right on National Business =
Pkwy.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">30 April 2001 - 1300</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">8 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">8 May 2001 - 1300</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">24 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">24 May 2001 - 1300 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">---------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">All showings last about half a day - =
with a mixture of conference room briefings and laboratory =
demonstrations.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">We are limited by available =
demonstration space to an absolute maximum of 20 participants at each =
showing.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">IMPORTANT:&nbsp; PLEASE REGISTER WITH =
LISA FAULKNER (</FONT><U><FONT SIZE=3D2 =
FACE=3D"Arial">[e-mail] &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
&gt;</FONT></U><FONT SIZE=3D2 FACE=3D"Arial">) AND MYSELF =
(</FONT><U><FONT SIZE=3D2 FACE=3D"Arial">[e-mail] &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
&gt;</FONT></U><FONT SIZE=3D2 FACE=3D"Arial">) IF YOU PLAN TO =
ATTEND.&nbsp; IF YOU DO NOT REGISTER TO ATTEND, YOU WILL NOT BE =
ADMITTED TO THE DEMONSTRATION.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Please provide the following =
information to register:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Name</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Organization</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; E-mail address</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Date and time of the =
demonstration showing you wish to attend (with alternates, if =
possible)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">We look forward to seeing you at the =
demonstration!</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Dave Fillingham</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">NSA</FONT>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C0CDA9.2E45D730--

--------------InterScan_NT_MIME_Boundary--


Received: from sol4.rmc.ca (sol4.rmc.ca [137.94.1.134]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA03175 for <[e-mail]>; Wed, 25 Apr 2001 08:00:57 -0700 (PDT)
Received: from rmc.ca ([137.94.177.160]) by sol4.rmc.ca (Netscape Messaging Server 4.1) with ESMTP id GCCSAO00.841 for <[e-mail]>; Wed, 25 Apr 2001 10:59:12 -0400 
Message-ID: <[e-mail]>
Date: Wed, 25 Apr 2001 10:58:17 -0400
From: "David Deplanche" <[e-mail]>
Organization: RMC ECE
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
Content-Type: multipart/mixed; boundary="------------71E1A6F4427435816D5C0D31"

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



--------------71E1A6F4427435816D5C0D31
Content-Type: text/x-vcard; charset=us-ascii;
 name="deplanche-d.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dave DePlanche
Content-Disposition: attachment;
 filename="deplanche-d.vcf"

begin:vcard 
n:DePlanche;Dave
tel;cell:613-540-3103
tel;fax:[phone]
tel;work:613-541-6000 ext 6453
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Dave DePlanche
end:vcard

--------------71E1A6F4427435816D5C0D31--



Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA27097 for <[e-mail]>; Wed, 25 Apr 2001 06:11:59 -0700 (PDT)
From: [e-mail]
Received: from frmta004.netfr.alcatel.fr (frmta004.netfr.alcatel.fr [155.132.182.160]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id PAA20499 for <[e-mail]>; Wed, 25 Apr 2001 15:11:45 +0200 (MET DST)
Received: by frmta004.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C1256A39.00486F33 ; Wed, 25 Apr 2001 15:11:10 +0200
X-Lotus-FromDomain: ALCATEL
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 25 Apr 2001 15:10:50 +0200
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

unsubscribe




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA26253 for <[e-mail]>; Wed, 25 Apr 2001 05:49:46 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA13854 for <[e-mail]>; Wed, 25 Apr 2001 08:49:17 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Wed, 25 Apr 2001 08:47:15 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: keyCertSign and cRLSign Key Usage Bits
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

Thanks.

However, I am more concerned about the second paragraph than the
first.  Is Last Call the proper time to be proposing, discussing,
and ratifying such a novel and significant change to the path validation
algorithm?

       Such AA certificates MUST NOT be used to verify signatures
       on CRLs containing revocation information for public key
       certificates;  ...

Dave



Russ Housley wrote:
> 
> Dave:
> 
> If the cA bit is asserted, then it is a CA certificate.  However, the
> keyCertSign and/or the cRLSign bits tell what the CA is going to do with
> this particular public key.
> 
> I have no problem deleting the second sentence.
> 
> Russ
> 
> At 02:48 PM 4/24/2001 -0400, David P. Kemp wrote:
> >Russ,
> >
> >With regard to keyCertSign:
> >
> >I still don't see a definition of "CA certificates", so I still think
> >sentence 2 ("This bit MUST only be asserted in CA certificates.") should
> >be deleted.  Is the following true?
> >
> >    If the cA bit or the keyCertSign bit is asserted, then the
> >    certificate is a CA certificate.
> >    If neither the cA bit nor the keyCertSign bit are asserted, then
> >    the certificate is not a CA certificate.
> >
> >If those statements are true, then sentence 2 adds nothing except
> >confusion: there is the question of whether it is the identical
> >requirement to sentence 3 or a different requirement.
> >
> >Sentences 3 and 4 are quite sufficient; sentence 2 should be deleted.
> >
> >---------------------------------------------------------------------
> >
> >The second paragraph assumes that we have consensus that the cA bit
> >should be used to determine which authorities can revoke which certs.
> >I don't believe there is consensus on that point.
> >
> >Additionally:
> >
> >* Sentences 1 and 2 are redundant; only one of them is needed.
> >
> >* Sentence 3 does not contain any useful information about cRLSign.
> >(If the cRLSign bit is *not* asserted in a CA certificate, the cA bit
> >must still be asserted.)
> >
> >* Sentence 4 is a policy statement unrelated to CRL signing. Do we have
> >consensus that a CA may not also be an AA?  If so, that policy should
> >be stated under attribute certificate issuance, not under key usage.
> >
> >* Sentence 5 does not define "AA certificates".  Should an AA be able
> >to sign CRLs using a new key which lists ACs signed with the old key?
> >Should an AA be able to delegate CRL signing to a key that cannot sign
> >ACs?  (I believe the consensus is yes on both counts.)  If so, and if
> >PKIX is to have a testable requirement along the lines of your new
> >langage, then it must tell implementations how to recognize an
> >"AA certificate", including one that can revoke but cannot sign ACs.
> >
> >* The final sentence is repeated verbatim from paragraph 1; does it have
> >any greater effect if written twice?
> >
> >-------------------
> >
> >I propose something quite close to the language in new-part1-04.  The
> >rest of your new cRLSign language is just fluff because there is no way
> >to determine whether an application complies with it.
> >
> >
> >         The keyCertSign bit is asserted when the subject public key
> >         is used for verifying a signature on public key certificates.
> >         If the keyCertSign bit is asserted, then the cA bit in the basic
> >         constraints extension (see 4.2.1.10) MUST also be asserted.
> >         If neither the keyCertSign bit nor the cRLSign bit are asserted,
> >         then the cA bit in the basic constraints extension MUST NOT be
> >         asserted.
> >
> >         The cRLSign bit MUST be asserted when the subject public key is
> >         used for verifying a signature on certificate revocation lists
> >         (e.g., CRLs or ARLs).
> >             {If the cRLSign bit is asserted, then either the cA bit
> >              in the basic constraints extension or the the authority
> >              bit in the basicAttConstraints extension MUST also be
> >              asserted.}*
> >
> >
> >* The last sentence, in {braces}, is an example of how one might
> >write a testable requirement.  I don't actually believe it should be
> >included in 2459bis.
> >
> >If PKIX wants to use the cA bit to control revocation, and it
> >is not going to profile X.509's SOAIdentifier or basicAttConstraints
> >extensions, then it MUST use something other than handwaving to
> >distinguish EE certs from AA certs.  That's why I don't believe there
> >should be any linkage between the cRLSign bit and the cA bit.
> >
> >Dave
> >
> >
> >
> >
> >"Housley, Russ" wrote:
> > >
> > > The consensus on these bits is not totally clear to me.  Yet, several
> > > points have been consistently, and I think that the following text
> > > incorporates them.  The debate regarding he linkage between these bits and
> > > the cA bit in the basic constraints extension does not seem to be over, and
> > > I have not made any changes in that area.  Please use this new thread to
> > > discuss any remaining unresolved points.
> > >
> > >        The keyCertSign bit is asserted when the subject public key is
> > >        used for verifying a signature on public key certificates.  This
> > >        bit MUST only be asserted in CA certificates.  If the keyCertSign
> > >        bit is asserted, then the cA bit in the basic constraints
> > >        extension (see 4.2.1.10) MUST also be asserted.  If neither the
> > >        cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
> > >        in the basic constraints extension MUST NOT be asserted.
> > >
> > >        The cRLSign bit is asserted when the subject public key is used
> > >        for verifying a signature on a certificate revocation list (e.g.,
> > >        a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
> > >        Authority (AA) certificates that are used to verify signatures on
> > >        CRLs.  If the cRLSign bit is asserted in a CA certificate, then
> > >        the cA bit in the basic constraints extension (see 4.2.1.10) MUST
> > >        also be asserted.  If the cRLSign bit is asserted in a AA
> > >        certificate, then the cA bit in the basic constraints extension
> > >        MUST NOT be asserted.  Such AA certificates MUST NOT be used to
> > >        verify signatures on CRLs containing revocation information for
> > >        public key certificates; however, these AA certificates MAY be
> > >        used to verify signatures on CRLs containing revocation
> > >        information concerning attribute certificates.  If neither the
> > >        cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
> > >        in the basic constraints extension MUST NOT be asserted.
> > >
> > > Russ


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA17604 for <[e-mail]>; Wed, 25 Apr 2001 03:35:08 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JTZ236VN>; Wed, 25 Apr 2001 06:34:38 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: David Cross <[e-mail]>, "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys
Date: Wed, 25 Apr 2001 06:25:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CD72.168848D0"

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_01C0CD72.168848D0
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:

Optional is sufficient.  It should NOT be mandatory to have separate signing
keys for certificates and CRLs.

Thanks.  I think we agree.

-----Original Message-----
From: David Cross [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 9:21 PM
To: Housley, Russ; Santosh Chokhani
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys


Optional please - it will take time to build up a large support base for
this on the client side.

David B. Cross
 

 



-----Original Message-----
From: Housley, Russ [mailto:[e-mail]] 
Sent: Tuesday, April 24, 2001 5:55 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys


Santosh:

The profile already allows CAs and clients to include the features your
are 
advocating.  We are debating which are mandatory to implement vs.
optional.

Russ


At 03:41 PM 4/24/2001 -0400, Santosh Chokhani wrote:

>Russ:
>
>May be there is a middle ground in terms not requiring the clients to
>process the chains, but also not declaring PKI that have CA and clients

>that conform to this.
>
>I would like us to accommodate both without requiring ALL clients to 
>have
>the capability.
>
>For example, we can say that the client need not process these types of
>trust paths, but CA who use separate keys and clients who can build and

>process these chains are also compliant.
>
>-----Original Message-----
>From: Housley, Russ
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Tuesday, April 24, 2001 2:27 PM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: Dedicated CRL signing keys
>
>Santosh:
>
>Interoperability is just as important as security.  Further, complexity

>leads to implementation flaws which reduces security.  In several 
>places, the working group has decided that interoperability is more 
>important than security.  In fact, the PKIX profile does not require 
>that a CA issue CRLs (see section 3.3, last paragraph).
>
>The PKIX profile places requirements on CAs and clients.  How can we 
>say that clients MUST be able to handle certs and CRLs signed with 
>different keys when we do not require CAs to issue them at all?  
>Further, placing such a requirement on clients forces them to be able 
>to build certification paths during CRL checking.  We already know that

>some clients cannot do this (an interoperability issue).  And, asking 
>them to do so will add complexity (a security assurance issue).
>
>Russ
>
>At 08:54 AM 4/24/2001 -0400, Santosh Chokhani wrote:
>
> >Russ:
> >
> >One of your comments yesterday was that we can make a choice between 
> >simpler client and operational security when I said that some 
> >implementations require separate CRL signing keys for operational 
> >security reasons.
> >
> >While I agree with you that this is a trade-off an enterprise needs 
> >to make.  But, I think the Internet RFC should not make such a 
> >choice.  I am saying that the RFC should permit both:  simple client 
> >(same key for certificate and CRL signing) as well as different keys 
> >for certificate and CRL signing.
> >
> >PKIX working group is after all, all about security.  We should not 
> >say that a secure implementation is not compliant with PKIX.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Dedicated CRL signing keys</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>Optional is sufficient.&nbsp; It should NOT be =
mandatory to have separate signing keys for certificates and =
CRLs.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks.&nbsp; I think we agree.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David Cross [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 24, 2001 9:21 PM</FONT>
<BR><FONT SIZE=3D2>To: Housley, Russ; Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Dedicated CRL signing keys</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Optional please - it will take time to build up a =
large support base for</FONT>
<BR><FONT SIZE=3D2>this on the client side.</FONT>
</P>

<P><FONT SIZE=3D2>David B. Cross</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 24, 2001 5:55 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Dedicated CRL signing keys</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>The profile already allows CAs and clients to include =
the features your</FONT>
<BR><FONT SIZE=3D2>are </FONT>
<BR><FONT SIZE=3D2>advocating.&nbsp; We are debating which are =
mandatory to implement vs.</FONT>
<BR><FONT SIZE=3D2>optional.</FONT>
</P>

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

<P><FONT SIZE=3D2>At 03:41 PM 4/24/2001 -0400, Santosh Chokhani =
wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Russ:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;May be there is a middle ground in terms not =
requiring the clients to</FONT>
<BR><FONT SIZE=3D2>&gt;process the chains, but also not declaring PKI =
that have CA and clients</FONT>
</P>

<P><FONT SIZE=3D2>&gt;that conform to this.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I would like us to accommodate both without =
requiring ALL clients to </FONT>
<BR><FONT SIZE=3D2>&gt;have</FONT>
<BR><FONT SIZE=3D2>&gt;the capability.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;For example, we can say that the client need not =
process these types of</FONT>
<BR><FONT SIZE=3D2>&gt;trust paths, but CA who use separate keys and =
clients who can build and</FONT>
</P>

<P><FONT SIZE=3D2>&gt;process these chains are also compliant.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Housley, Russ</FONT>
<BR><FONT SIZE=3D2>&gt;[&lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>&gt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Tuesday, April 24, 2001 2:27 PM</FONT>
<BR><FONT SIZE=3D2>&gt;To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE: Dedicated CRL signing keys</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Santosh:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Interoperability is just as important as =
security.&nbsp; Further, complexity</FONT>
</P>

<P><FONT SIZE=3D2>&gt;leads to implementation flaws which reduces =
security.&nbsp; In several </FONT>
<BR><FONT SIZE=3D2>&gt;places, the working group has decided that =
interoperability is more </FONT>
<BR><FONT SIZE=3D2>&gt;important than security.&nbsp; In fact, the PKIX =
profile does not require </FONT>
<BR><FONT SIZE=3D2>&gt;that a CA issue CRLs (see section 3.3, last =
paragraph).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;The PKIX profile places requirements on CAs and =
clients.&nbsp; How can we </FONT>
<BR><FONT SIZE=3D2>&gt;say that clients MUST be able to handle certs =
and CRLs signed with </FONT>
<BR><FONT SIZE=3D2>&gt;different keys when we do not require CAs to =
issue them at all?&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;Further, placing such a requirement on clients =
forces them to be able </FONT>
<BR><FONT SIZE=3D2>&gt;to build certification paths during CRL =
checking.&nbsp; We already know that</FONT>
</P>

<P><FONT SIZE=3D2>&gt;some clients cannot do this (an interoperability =
issue).&nbsp; And, asking </FONT>
<BR><FONT SIZE=3D2>&gt;them to do so will add complexity (a security =
assurance issue).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Russ</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;At 08:54 AM 4/24/2001 -0400, Santosh Chokhani =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Russ:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;One of your comments yesterday was that we =
can make a choice between </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;simpler client and operational security =
when I said that some </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;implementations require separate CRL =
signing keys for operational </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;security reasons.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;While I agree with you that this is a =
trade-off an enterprise needs </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;to make.&nbsp; But, I think the Internet =
RFC should not make such a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;choice.&nbsp; I am saying that the RFC =
should permit both:&nbsp; simple client </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;(same key for certificate and CRL signing) =
as well as different keys </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;for certificate and CRL signing.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;PKIX working group is after all, all about =
security.&nbsp; We should not </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;say that a secure implementation is not =
compliant with PKIX.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CD72.168848D0--


Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id SAA08034 for <[e-mail]>; Tue, 24 Apr 2001 18:35:14 -0700 (PDT)
Received: from 157.54.9.108 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Apr 2001 18:21:06 -0700 (Pacific Daylight Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 24 Apr 2001 18:20:39 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Dedicated CRL signing keys
Date: Tue, 24 Apr 2001 18:20:38 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Dedicated CRL signing keys
Thread-Index: AcDNI7SsRdAelb+BTDucBrXkx0yMFgAAgCiw
From: "David Cross" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 25 Apr 2001 01:20:39.0329 (UTC) FILETIME=[F02C4110:01C0CD25]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id SAA08035

Optional please - it will take time to build up a large support base for
this on the client side.

David B. Cross
 

 



-----Original Message-----
From: Housley, Russ [mailto:[e-mail]] 
Sent: Tuesday, April 24, 2001 5:55 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys


Santosh:

The profile already allows CAs and clients to include the features your
are 
advocating.  We are debating which are mandatory to implement vs.
optional.

Russ


At 03:41 PM 4/24/2001 -0400, Santosh Chokhani wrote:

>Russ:
>
>May be there is a middle ground in terms not requiring the clients to
>process the chains, but also not declaring PKI that have CA and clients

>that conform to this.
>
>I would like us to accommodate both without requiring ALL clients to 
>have
>the capability.
>
>For example, we can say that the client need not process these types of
>trust paths, but CA who use separate keys and clients who can build and

>process these chains are also compliant.
>
>-----Original Message-----
>From: Housley, Russ
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Tuesday, April 24, 2001 2:27 PM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: Dedicated CRL signing keys
>
>Santosh:
>
>Interoperability is just as important as security.  Further, complexity

>leads to implementation flaws which reduces security.  In several 
>places, the working group has decided that interoperability is more 
>important than security.  In fact, the PKIX profile does not require 
>that a CA issue CRLs (see section 3.3, last paragraph).
>
>The PKIX profile places requirements on CAs and clients.  How can we 
>say that clients MUST be able to handle certs and CRLs signed with 
>different keys when we do not require CAs to issue them at all?  
>Further, placing such a requirement on clients forces them to be able 
>to build certification paths during CRL checking.  We already know that

>some clients cannot do this (an interoperability issue).  And, asking 
>them to do so will add complexity (a security assurance issue).
>
>Russ
>
>At 08:54 AM 4/24/2001 -0400, Santosh Chokhani wrote:
>
> >Russ:
> >
> >One of your comments yesterday was that we can make a choice between 
> >simpler client and operational security when I said that some 
> >implementations require separate CRL signing keys for operational 
> >security reasons.
> >
> >While I agree with you that this is a trade-off an enterprise needs 
> >to make.  But, I think the Internet RFC should not make such a 
> >choice.  I am saying that the RFC should permit both:  simple client 
> >(same key for certificate and CRL signing) as well as different keys 
> >for certificate and CRL signing.
> >
> >PKIX working group is after all, all about security.  We should not 
> >say that a secure implementation is not compliant with PKIX.


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id RAA05575 for <[e-mail]>; Tue, 24 Apr 2001 17:59:10 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Apr 2001 00:59:11 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id UAA16646 for <[e-mail]>; Tue, 24 Apr 2001 20:59:12 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JST3VQGS>; Tue, 24 Apr 2001 20:59:13 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.56]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JST3VQGR; Tue, 24 Apr 2001 20:59:07 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 24 Apr 2001 20:54:57 -0400
Subject: RE: Dedicated CRL signing keys
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Santosh:

The profile already allows CAs and clients to include the features your are 
advocating.  We are debating which are mandatory to implement vs. optional.

Russ


At 03:41 PM 4/24/2001 -0400, Santosh Chokhani wrote:

>Russ:
>
>May be there is a middle ground in terms not requiring the clients to 
>process the chains, but also not declaring PKI that have CA and clients 
>that conform to this.
>
>I would like us to accommodate both without requiring ALL clients to have 
>the capability.
>
>For example, we can say that the client need not process these types of 
>trust paths, but CA who use separate keys and clients who can build and 
>process these chains are also compliant.
>
>-----Original Message-----
>From: Housley, Russ 
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Tuesday, April 24, 2001 2:27 PM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: Dedicated CRL signing keys
>
>Santosh:
>
>Interoperability is just as important as security.  Further, complexity
>leads to implementation flaws which reduces security.  In several places,
>the working group has decided that interoperability is more important than
>security.  In fact, the PKIX profile does not require that a CA issue CRLs
>(see section 3.3, last paragraph).
>
>The PKIX profile places requirements on CAs and clients.  How can we say
>that clients MUST be able to handle certs and CRLs signed with different
>keys when we do not require CAs to issue them at all?  Further, placing
>such a requirement on clients forces them to be able to build certification
>paths during CRL checking.  We already know that some clients cannot do
>this (an interoperability issue).  And, asking them to do so will add
>complexity (a security assurance issue).
>
>Russ
>
>At 08:54 AM 4/24/2001 -0400, Santosh Chokhani wrote:
>
> >Russ:
> >
> >One of your comments yesterday was that we can make a choice between
> >simpler client and operational security when I said that some
> >implementations require separate CRL signing keys for operational security
> >reasons.
> >
> >While I agree with you that this is a trade-off an enterprise needs to
> >make.  But, I think the Internet RFC should not make such a choice.  I am
> >saying that the RFC should permit both:  simple client (same key for
> >certificate and CRL signing) as well as different keys for certificate and
> >CRL signing.
> >
> >PKIX working group is after all, all about security.  We should not say
> >that a secure implementation is not compliant with PKIX.


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA27820 for <[e-mail]>; Tue, 24 Apr 2001 15:42:10 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JRDR7BKD; Tue, 24 Apr 2001 15:37:17 -0700
From: "Carlin Covey" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs and NR
Date: Tue, 24 Apr 2001 15:41:03 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>

David,

Thank you for pointing out the "..less than or equal.."
phrase.  I had missed the significance.

My preference is that delta-CRL's be identified only by
the deltaCRLIndicator extension, rather than the
cRLScope extension.

I propose that the following "sufficient condition" in the
PKIX profile

"The delta CRL indicator is a critical CRL extension
that identifies a CRL as being a delta CRL."

be reworded as a "necessary condition" along the lines of

"A delta CRL MUST be identified via the delta CRL indicator
extension, which MUST be marked as a critical CRL extension."


Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation


-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 2:06 PM
To: [e-mail]
Subject: RE: delta-CRLs and NR


Carlin,

The quote that you included about the cRLScope extension is correct, but the
end result is (nearly) the same whether delta-CRLs are identified using the
cRLScope extension or the deltaCRLIndicator extension. In addition to the
text that you quoted, X.509 (Ed. 4 v7 is the latest) section 8.5.2.5 states
the following about the cRLScope extension:

         the cRLNumber referenced in the BaseRevocationInfo field of a dCRL
shall be less than or equal
         to the cRLNumber of the most recently issued CRL that is complete
for the applicable scope.

So, while the base CRL referenced by the delta-CRL may not have been issued
as a full CRL, there will be at least one CRL, issued as a full CRL, against
which the delta-CRL may be applied to obtain complete certificate status
information. The full CRL may have been issued after the referenced base
CRL, but one can still apply the delta-CRL to that full CRL.

As to your second question, the PKIX certificate and CRL profile does not
include the cRLScope extension. So, while X.509 provides two ways to
identify a CRL as being a delta-CRL, PKIX only provides the
deltaCRLIndicator. Would a CRL issuer that used the cRLScope extension be
non-PKIX-compliant? I'll leave that to others to decide.

Dave

At 01:35 PM 4/24/01 -0700, Carlin Covey wrote:
>David,
>
>You are correct for delta-CRLs defined with the deltaCRLIndicator, but
>it is also possible to define delta-CRLs using the CRL scope extension.
>
>X.509 Ed. 4 v6 says the following in section 8.5.2.5 'CRL scope extension':
>
>"In the crlScope case, the information in the baseRevocationInfo
>component, indicates the point in time from which the CRL containing
>this extension provides updates. Although this is done by referencing
>a CRL, the referenced CRL may or may not be one that is complete for
>the applicable scope, whereas the deltaCRLIdentifier extension references
>an issued CRL that is complete for the applicable scope."
>
>In an earlier email I made the following observation and asked a question:
>
>"I don't see anywhere in draft-ietf-pkix-new-part1-05 where it says
>that a delta CRL must be identified by a deltaCRLIndicator extension.
>It does say that "The delta CRL indicator is a critical CRL extension
>that identifies a CRL as being a delta CRL."  This appears to be a
>sufficient
>condition, but not a necessary condition, for the CRL to be interpreted as
a
>delta CRL.  So a PKIX-profile-compliant CRL-issuer could use the crlScope
>extension rather than the deltaCRLIndicator extension to identify delta
>CRLs?
>
>       -  Russ, is that right?"
>
>Regards,
>
>Carlin
>
>____________________________
>
>-  Carlin Covey
>    Cylink Corporation
>
>
>-----Original Message-----
>From: David A. Cooper [mailto:[e-mail]]
>Sent: Tuesday, April 24, 2001 12:44 PM
>To: [e-mail]
>Subject: RE: delta-CRLs and NR
>
>
>This is a misunderstanding of the way that delta-CRLs work. A delta-CRL
>specifies a base CRL and  provides a list of all certificates whose status
>has changed since the base CRL was issued. When using the
deltaCRLIndicator,
>the referenced base CRL must have been issued as a full CRL (i.e., not a
>delta). Thus, one can always obtain complete revocation information by
>applying a single delta-CRL to the base CRL that it references.
>
>If delta-CRLs are issued more frequently than full CRLs, this will just
mean
>that multiple delta-CRLs will reference the same full CRL as their base.
>
>With the current PKIX standard, one can always get complete revocation
>information by just obtaining a full CRL. If the rules were relaxed, one
>would be required to obtain one full CRL and one delta-CRL.
>
>Dave
>
>At 12:25 PM 4/24/01 -0700, Michael Myers wrote:
> >I understand.  But the trajectory of the dialog seemed to be suggesting
> >elimination the full CRL context, hence in that forward scenario one
would
> >have no choice but to face the accumulation task.  Also, the proposal to
> >enable a different period of production between a full CRL and its
> >associated deltas (thus enabling periods of delta-only activity between
>full
> >CRL production) does suggest that there might exists cases where more
than
> >one delta is necessary to span the gap between fulls.
>




Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA22660 for <[e-mail]>; Tue, 24 Apr 2001 14:26:27 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Apr 2001 21:26:28 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAB08458 for <[e-mail]>; Tue, 24 Apr 2001 17:26:29 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JST3V344>; Tue, 24 Apr 2001 17:26:29 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.3]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JST3V34Q; Tue, 24 Apr 2001 17:26:25 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 24 Apr 2001 17:23:54 -0400
Subject: RE: Dedicated CRL signing keys
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Santosh:

I know.  The point is that a simple client will encounter an unsupported 
extension.

David Cooper has pointed out that this has the effect that clients that 
might otherwise be able to use the CRL will not be able to use it.  I am no 
longer advocating this approach.

Russ

At 03:21 PM 4/24/2001 -0400, Santosh Chokhani wrote:

>Russ:
>
>But the semantics of that extension does NOT mean that the CRL is signed 
>by a different key.
>
>Actually, a CA typically uses this extension, chops up the CRL and signs 
>them all using the SAME key.
>
>-----Original Message-----
>From: Housley, Russ 
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Tuesday, April 24, 2001 3:11 PM
>To: Santosh Chokhani
>Cc: Santosh Chokhani; [e-mail]
>Subject: RE: Dedicated CRL signing keys
>
>At 05:25 PM 4/23/2001 -0400, Santosh Chokhani wrote:
> > >First, I think that the restriction that a CA who desires to issue
> > >Indirect CRL needs to set itself up as a separate name is unduly
> > >restrictive.  There is no need for a CA to do that.  A CA can issue a 
> full
> > >CRL as well as an Indirect CRL and populate these in the same or 
> different
> > >entries (i.e., CRL DP) in the directory.  Please review Annex B of X.509
> > >for how to process CRL.  So, may be Russ can explain why this requirement
> > >comes about.
> >
> >I agree that the use of a separate name is overly restrictive.  That
> >portion of my suggestion was, in hind sight, a bad idea.  As Tim Polk
> >pointed out, CAs cannot change their names when they rekey.
> >
> >I think that everyone agrees that a CA makes a commitment to provide some
> >form of revocation information for the duration of the certificate
> >life.  When CRLs are employed, does the CA use the same key to sign the CRL
> >as was used to sign the certificate?  Clearly, the CA is permitted to use
> >different keys -- the key usage bits are there to allow this
> >separation.  However, several clients cannot handle this situation, and
> >they would like to see an error message that says "unsupported feature"
> >instead of "signature invalid."
> >
> >Perhaps CA rekey will lead us to an answer.  When a CA rekeys, does it are
> >subsequent CRLs signed with the new key or the old one?  A CA could
> >generate one CRL with each key.  They two CRLs could even be distributed by
> >different distribution point to avoid the download of CRLs that cannot be
> >employed.  Alternatively, the CA could publish one CRL signed with the new
> >key.  This leads to the scenario where cert path construction must be
> >evoked to generate validate the CRL when trying to validate a certificate
> >signed by the old key.  This is the behavior that we are trying to make
> >SHOULD.
> >
> >Therefore, the CA MUST generate the CRL using the same key as was used to
> >sign the certificate, or it MUST include an extension in the CRL to
> >indicate that cert path construction might be needed to validate the CRL
> >signature.  I proposed that an Issuing Distribution Point (IDP) CRL
> >extension might be the correct approach.  The IDP extension will not be
> >supported by the simple clients, so they can generate the "unsupported
> >feature" error, and the more complex clients can use the information in the
> >IDP to support path construction.  They will of course, also use Authority
> >Key Identifier extension.
> >
> >{Santosh Says: Item 1 will require a change to the IDP extension
> >syntax.  Would n't that make PKIX non-compliant with X.509?)
>
>The IDP syntax is:
>
>     issuingDistributionPoint ::= SEQUENCE {
>          distributionPoint       [0] DistributionPointName OPTIONAL,
>          onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
>          onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
>          onlySomeReasons         [3] ReasonFlags OPTIONAL,
>          indirectCRL             [4] BOOLEAN DEFAULT FALSE }
>
>I was simply suggesting that this extension be present if the CRL is signed
>with a key other than the one used to sign the certificate.  I would expect
>the distributionPoint field to be present (probably with a URL
>(ldap://...)).  The boolean flags would be set based on the contents of the
>CRL (probably all FALSE).  The reason codes would also be set based on the
>contents of the CRL (probably absent).
>
>Russ


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA21642 for <[e-mail]>; Tue, 24 Apr 2001 14:16:12 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Apr 2001 21:16:12 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA07728 for <[e-mail]>; Tue, 24 Apr 2001 17:16:12 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JST3V3PW>; Tue, 24 Apr 2001 17:16:12 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.3]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JST3V3PR; Tue, 24 Apr 2001 17:16:03 -0400
From: "Housley, Russ" <[e-mail]>
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 24 Apr 2001 15:51:53 -0400
Subject: Re: keyCertSign and cRLSign Key Usage Bits
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Dave:

If the cA bit is asserted, then it is a CA certificate.  However, the 
keyCertSign and/or the cRLSign bits tell what the CA is going to do with 
this particular public key.

I have no problem deleting the second sentence.

Russ



At 02:48 PM 4/24/2001 -0400, David P. Kemp wrote:
>Russ,
>
>With regard to keyCertSign:
>
>I still don't see a definition of "CA certificates", so I still think
>sentence 2 ("This bit MUST only be asserted in CA certificates.") should
>be deleted.  Is the following true?
>
>    If the cA bit or the keyCertSign bit is asserted, then the
>    certificate is a CA certificate.
>    If neither the cA bit nor the keyCertSign bit are asserted, then
>    the certificate is not a CA certificate.
>
>If those statements are true, then sentence 2 adds nothing except
>confusion: there is the question of whether it is the identical
>requirement to sentence 3 or a different requirement.
>
>Sentences 3 and 4 are quite sufficient; sentence 2 should be deleted.
>
>---------------------------------------------------------------------
>
>The second paragraph assumes that we have consensus that the cA bit
>should be used to determine which authorities can revoke which certs.
>I don't believe there is consensus on that point.
>
>Additionally:
>
>* Sentences 1 and 2 are redundant; only one of them is needed.
>
>* Sentence 3 does not contain any useful information about cRLSign.
>(If the cRLSign bit is *not* asserted in a CA certificate, the cA bit
>must still be asserted.)
>
>* Sentence 4 is a policy statement unrelated to CRL signing. Do we have
>consensus that a CA may not also be an AA?  If so, that policy should
>be stated under attribute certificate issuance, not under key usage.
>
>* Sentence 5 does not define "AA certificates".  Should an AA be able
>to sign CRLs using a new key which lists ACs signed with the old key?
>Should an AA be able to delegate CRL signing to a key that cannot sign
>ACs?  (I believe the consensus is yes on both counts.)  If so, and if
>PKIX is to have a testable requirement along the lines of your new
>langage, then it must tell implementations how to recognize an
>"AA certificate", including one that can revoke but cannot sign ACs.
>
>* The final sentence is repeated verbatim from paragraph 1; does it have
>any greater effect if written twice?
>
>-------------------
>
>I propose something quite close to the language in new-part1-04.  The
>rest of your new cRLSign language is just fluff because there is no way
>to determine whether an application complies with it.
>
>
>         The keyCertSign bit is asserted when the subject public key
>         is used for verifying a signature on public key certificates.
>         If the keyCertSign bit is asserted, then the cA bit in the basic
>         constraints extension (see 4.2.1.10) MUST also be asserted.
>         If neither the keyCertSign bit nor the cRLSign bit are asserted,
>         then the cA bit in the basic constraints extension MUST NOT be
>         asserted.
>
>         The cRLSign bit MUST be asserted when the subject public key is
>         used for verifying a signature on certificate revocation lists
>         (e.g., CRLs or ARLs).
>             {If the cRLSign bit is asserted, then either the cA bit
>              in the basic constraints extension or the the authority
>              bit in the basicAttConstraints extension MUST also be
>              asserted.}*
>
>
>* The last sentence, in {braces}, is an example of how one might
>write a testable requirement.  I don't actually believe it should be
>included in 2459bis.
>
>If PKIX wants to use the cA bit to control revocation, and it
>is not going to profile X.509's SOAIdentifier or basicAttConstraints
>extensions, then it MUST use something other than handwaving to
>distinguish EE certs from AA certs.  That's why I don't believe there
>should be any linkage between the cRLSign bit and the cA bit.
>
>Dave
>
>
>
>
>"Housley, Russ" wrote:
> >
> > The consensus on these bits is not totally clear to me.  Yet, several
> > points have been consistently, and I think that the following text
> > incorporates them.  The debate regarding he linkage between these bits and
> > the cA bit in the basic constraints extension does not seem to be over, and
> > I have not made any changes in that area.  Please use this new thread to
> > discuss any remaining unresolved points.
> >
> >        The keyCertSign bit is asserted when the subject public key is
> >        used for verifying a signature on public key certificates.  This
> >        bit MUST only be asserted in CA certificates.  If the keyCertSign
> >        bit is asserted, then the cA bit in the basic constraints
> >        extension (see 4.2.1.10) MUST also be asserted.  If neither the
> >        cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
> >        in the basic constraints extension MUST NOT be asserted.
> >
> >        The cRLSign bit is asserted when the subject public key is used
> >        for verifying a signature on a certificate revocation list (e.g.,
> >        a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
> >        Authority (AA) certificates that are used to verify signatures on
> >        CRLs.  If the cRLSign bit is asserted in a CA certificate, then
> >        the cA bit in the basic constraints extension (see 4.2.1.10) MUST
> >        also be asserted.  If the cRLSign bit is asserted in a AA
> >        certificate, then the cA bit in the basic constraints extension
> >        MUST NOT be asserted.  Such AA certificates MUST NOT be used to
> >        verify signatures on CRLs containing revocation information for
> >        public key certificates; however, these AA certificates MAY be
> >        used to verify signatures on CRLs containing revocation
> >        information concerning attribute certificates.  If neither the
> >        cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
> >        in the basic constraints extension MUST NOT be asserted.
> >
> > Russ


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA20597 for <[e-mail]>; Tue, 24 Apr 2001 14:06:27 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA20747 for <[e-mail]>; Tue, 24 Apr 2001 17:06:28 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 24 Apr 2001 17:05:59 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: delta-CRLs and NR
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Carlin,

The quote that you included about the cRLScope extension is correct, but the end result is (nearly) the same whether delta-CRLs are identified using the cRLScope extension or the deltaCRLIndicator extension. In addition to the text that you quoted, X.509 (Ed. 4 v7 is the latest) section 8.5.2.5 states the following about the cRLScope extension:

         the cRLNumber referenced in the BaseRevocationInfo field of a dCRL shall be less than or equal
         to the cRLNumber of the most recently issued CRL that is complete for the applicable scope.

So, while the base CRL referenced by the delta-CRL may not have been issued as a full CRL, there will be at least one CRL, issued as a full CRL, against which the delta-CRL may be applied to obtain complete certificate status information. The full CRL may have been issued after the referenced base CRL, but one can still apply the delta-CRL to that full CRL.

As to your second question, the PKIX certificate and CRL profile does not include the cRLScope extension. So, while X.509 provides two ways to identify a CRL as being a delta-CRL, PKIX only provides the deltaCRLIndicator. Would a CRL issuer that used the cRLScope extension be non-PKIX-compliant? I'll leave that to others to decide.

Dave

At 01:35 PM 4/24/01 -0700, Carlin Covey wrote:
>David,
>
>You are correct for delta-CRLs defined with the deltaCRLIndicator, but
>it is also possible to define delta-CRLs using the CRL scope extension.
>
>X.509 Ed. 4 v6 says the following in section 8.5.2.5 'CRL scope extension':
>
>"In the crlScope case, the information in the baseRevocationInfo
>component, indicates the point in time from which the CRL containing
>this extension provides updates. Although this is done by referencing
>a CRL, the referenced CRL may or may not be one that is complete for
>the applicable scope, whereas the deltaCRLIdentifier extension references
>an issued CRL that is complete for the applicable scope."
>
>In an earlier email I made the following observation and asked a question:
>
>"I don't see anywhere in draft-ietf-pkix-new-part1-05 where it says
>that a delta CRL must be identified by a deltaCRLIndicator extension.
>It does say that "The delta CRL indicator is a critical CRL extension
>that identifies a CRL as being a delta CRL."  This appears to be a
>sufficient
>condition, but not a necessary condition, for the CRL to be interpreted as a
>delta CRL.  So a PKIX-profile-compliant CRL-issuer could use the crlScope
>extension rather than the deltaCRLIndicator extension to identify delta
>CRLs?
>
>       -  Russ, is that right?"
>
>Regards,
>
>Carlin
>
>____________________________
>
>-  Carlin Covey
>    Cylink Corporation
>
>
>-----Original Message-----
>From: David A. Cooper [mailto:[e-mail]]
>Sent: Tuesday, April 24, 2001 12:44 PM
>To: [e-mail]
>Subject: RE: delta-CRLs and NR
>
>
>This is a misunderstanding of the way that delta-CRLs work. A delta-CRL
>specifies a base CRL and  provides a list of all certificates whose status
>has changed since the base CRL was issued. When using the deltaCRLIndicator,
>the referenced base CRL must have been issued as a full CRL (i.e., not a
>delta). Thus, one can always obtain complete revocation information by
>applying a single delta-CRL to the base CRL that it references.
>
>If delta-CRLs are issued more frequently than full CRLs, this will just mean
>that multiple delta-CRLs will reference the same full CRL as their base.
>
>With the current PKIX standard, one can always get complete revocation
>information by just obtaining a full CRL. If the rules were relaxed, one
>would be required to obtain one full CRL and one delta-CRL.
>
>Dave
>
>At 12:25 PM 4/24/01 -0700, Michael Myers wrote:
> >I understand.  But the trajectory of the dialog seemed to be suggesting
> >elimination the full CRL context, hence in that forward scenario one would
> >have no choice but to face the accumulation task.  Also, the proposal to
> >enable a different period of production between a full CRL and its
> >associated deltas (thus enabling periods of delta-only activity between
>full
> >CRL production) does suggest that there might exists cases where more than
> >one delta is necessary to span the gap between fulls.
>




Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA18123; Tue, 24 Apr 2001 13:49:05 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95F5JS9>; Tue, 24 Apr 2001 16:49:39 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Subject: v1.9.1 Certificate Management Library Now Available
Date: Tue, 24 Apr 2001 16:49:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

Getronics Government Solutions has delivered the Version 1.9.1 Certificate
Management Library (CML) for MS Windows, Solaris 2.7 and Linux.  The v1.9.1
CML is freely available to everyone from the Getronics CML web page
<http://www.getronicsgov.com/hot/cml_home.htm>.  This release includes bug
fixes for the v1.9 CML release, and the integration of the new SNACC string
conversion functions into the CML.  The v1.9.1 CML requires the latest SNACC
release (v1.3 R6).  Older versions of the SNACC library will not work.
SNACC v1.3 R6 can be downloaded from
<http://www.getronicsgov.com/hot/snacc_home.htm>.

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

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

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

 1. Modified DN conversion functions to use new SNACC string conversion
functions. 
    Fixed bug in buildRdnString() that incorrectly escaped UTF8 strings. 
 
 2. Added call to new SNACC ASN1Terminate() function to free up the global
hash tables 
    used to perform the decoding of the ASN.1 ANYs.

 3. Corrected logic on freeing objects, when a free callback function was
passed in.

 4. Modified CMU_BreakUpCertPair and its underlying functions.

 5. Corrected argument to function call CMU_genname2str, when the
Distribution Point
    name refers to a full name. 

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

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

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

The v1.9.1 CML uses the Getronics v1.3 R6 Enhanced SNACC ASN.1 Library to
encode/decode objects.  Getronics has successfully tested the v1.9.1 CML 
with the SNACC and CTIL DLLs delivered in conjunction with the v1.10 SFL.
Source code for the Getronics-developed CTILs is available from
<http://www.getronicsgov.com/hot/sfl_home.htm>.  The actual crypto libraries

are not provided with the CML or SFL.  They must be independently obtained
from the appropriate source.  

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

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

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

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

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA16963 for <[e-mail]>; Tue, 24 Apr 2001 13:36:57 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JRDR7A5R; Tue, 24 Apr 2001 13:32:05 -0700
From: "Carlin Covey" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs and NR
Date: Tue, 24 Apr 2001 13:35:50 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>

David,

You are correct for delta-CRLs defined with the deltaCRLIndicator, but
it is also possible to define delta-CRLs using the CRL scope extension.

X.509 Ed. 4 v6 says the following in section 8.5.2.5 'CRL scope extension':

"In the crlScope case, the information in the baseRevocationInfo
component, indicates the point in time from which the CRL containing
this extension provides updates. Although this is done by referencing
a CRL, the referenced CRL may or may not be one that is complete for
the applicable scope, whereas the deltaCRLIdentifier extension references
an issued CRL that is complete for the applicable scope."

In an earlier email I made the following observation and asked a question:

"I don't see anywhere in draft-ietf-pkix-new-part1-05 where it says
that a delta CRL must be identified by a deltaCRLIndicator extension.
It does say that "The delta CRL indicator is a critical CRL extension
that identifies a CRL as being a delta CRL."  This appears to be a
sufficient
condition, but not a necessary condition, for the CRL to be interpreted as a
delta CRL.  So a PKIX-profile-compliant CRL-issuer could use the crlScope
extension rather than the deltaCRLIndicator extension to identify delta
CRLs?

      -  Russ, is that right?"

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation


-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 12:44 PM
To: [e-mail]
Subject: RE: delta-CRLs and NR


This is a misunderstanding of the way that delta-CRLs work. A delta-CRL
specifies a base CRL and  provides a list of all certificates whose status
has changed since the base CRL was issued. When using the deltaCRLIndicator,
the referenced base CRL must have been issued as a full CRL (i.e., not a
delta). Thus, one can always obtain complete revocation information by
applying a single delta-CRL to the base CRL that it references.

If delta-CRLs are issued more frequently than full CRLs, this will just mean
that multiple delta-CRLs will reference the same full CRL as their base.

With the current PKIX standard, one can always get complete revocation
information by just obtaining a full CRL. If the rules were relaxed, one
would be required to obtain one full CRL and one delta-CRL.

Dave

At 12:25 PM 4/24/01 -0700, Michael Myers wrote:
>I understand.  But the trajectory of the dialog seemed to be suggesting
>elimination the full CRL context, hence in that forward scenario one would
>have no choice but to face the accumulation task.  Also, the proposal to
>enable a different period of production between a full CRL and its
>associated deltas (thus enabling periods of delta-only activity between
full
>CRL production) does suggest that there might exists cases where more than
>one delta is necessary to span the gap between fulls.




Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA13647 for <[e-mail]>; Tue, 24 Apr 2001 12:50:26 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JSB1PMNF>; Tue, 24 Apr 2001 15:49:56 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys
Date: Tue, 24 Apr 2001 15:41:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCF6.7FC34A60"

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_01C0CCF6.7FC34A60
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:

May be there is a middle ground in terms not requiring the clients to
process the chains, but also not declaring PKI that have CA and clients that
conform to this.

I would like us to accommodate both without requiring ALL clients to have
the capability.

For example, we can say that the client need not process these types of
trust paths, but CA who use separate keys and clients who can build and
process these chains are also compliant.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 2:27 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys


Santosh:

Interoperability is just as important as security.  Further, complexity 
leads to implementation flaws which reduces security.  In several places, 
the working group has decided that interoperability is more important than 
security.  In fact, the PKIX profile does not require that a CA issue CRLs 
(see section 3.3, last paragraph).

The PKIX profile places requirements on CAs and clients.  How can we say 
that clients MUST be able to handle certs and CRLs signed with different 
keys when we do not require CAs to issue them at all?  Further, placing 
such a requirement on clients forces them to be able to build certification 
paths during CRL checking.  We already know that some clients cannot do 
this (an interoperability issue).  And, asking them to do so will add 
complexity (a security assurance issue).

Russ


At 08:54 AM 4/24/2001 -0400, Santosh Chokhani wrote:

>Russ:
>
>One of your comments yesterday was that we can make a choice between 
>simpler client and operational security when I said that some 
>implementations require separate CRL signing keys for operational security 
>reasons.
>
>While I agree with you that this is a trade-off an enterprise needs to 
>make.  But, I think the Internet RFC should not make such a choice.  I am 
>saying that the RFC should permit both:  simple client (same key for 
>certificate and CRL signing) as well as different keys for certificate and 
>CRL signing.
>
>PKIX working group is after all, all about security.  We should not say 
>that a secure implementation is not compliant with PKIX.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Dedicated CRL signing keys</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>May be there is a middle ground in terms not =
requiring the clients to process the chains, but also not declaring PKI =
that have CA and clients that conform to this.</FONT></P>

<P><FONT SIZE=3D2>I would like us to accommodate both without requiring =
ALL clients to have the capability.</FONT>
</P>

<P><FONT SIZE=3D2>For example, we can say that the client need not =
process these types of trust paths, but CA who use separate keys and =
clients who can build and process these chains are also =
compliant.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 24, 2001 2:27 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Dedicated CRL signing keys</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>Interoperability is just as important as =
security.&nbsp; Further, complexity </FONT>
<BR><FONT SIZE=3D2>leads to implementation flaws which reduces =
security.&nbsp; In several places, </FONT>
<BR><FONT SIZE=3D2>the working group has decided that interoperability =
is more important than </FONT>
<BR><FONT SIZE=3D2>security.&nbsp; In fact, the PKIX profile does not =
require that a CA issue CRLs </FONT>
<BR><FONT SIZE=3D2>(see section 3.3, last paragraph).</FONT>
</P>

<P><FONT SIZE=3D2>The PKIX profile places requirements on CAs and =
clients.&nbsp; How can we say </FONT>
<BR><FONT SIZE=3D2>that clients MUST be able to handle certs and CRLs =
signed with different </FONT>
<BR><FONT SIZE=3D2>keys when we do not require CAs to issue them at =
all?&nbsp; Further, placing </FONT>
<BR><FONT SIZE=3D2>such a requirement on clients forces them to be able =
to build certification </FONT>
<BR><FONT SIZE=3D2>paths during CRL checking.&nbsp; We already know =
that some clients cannot do </FONT>
<BR><FONT SIZE=3D2>this (an interoperability issue).&nbsp; And, asking =
them to do so will add </FONT>
<BR><FONT SIZE=3D2>complexity (a security assurance issue).</FONT>
</P>

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

<P><FONT SIZE=3D2>At 08:54 AM 4/24/2001 -0400, Santosh Chokhani =
wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Russ:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;One of your comments yesterday was that we can =
make a choice between </FONT>
<BR><FONT SIZE=3D2>&gt;simpler client and operational security when I =
said that some </FONT>
<BR><FONT SIZE=3D2>&gt;implementations require separate CRL signing =
keys for operational security </FONT>
<BR><FONT SIZE=3D2>&gt;reasons.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;While I agree with you that this is a trade-off =
an enterprise needs to </FONT>
<BR><FONT SIZE=3D2>&gt;make.&nbsp; But, I think the Internet RFC should =
not make such a choice.&nbsp; I am </FONT>
<BR><FONT SIZE=3D2>&gt;saying that the RFC should permit both:&nbsp; =
simple client (same key for </FONT>
<BR><FONT SIZE=3D2>&gt;certificate and CRL signing) as well as =
different keys for certificate and </FONT>
<BR><FONT SIZE=3D2>&gt;CRL signing.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;PKIX working group is after all, all about =
security.&nbsp; We should not say </FONT>
<BR><FONT SIZE=3D2>&gt;that a secure implementation is not compliant =
with PKIX.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CCF6.7FC34A60--


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA12723 for <[e-mail]>; Tue, 24 Apr 2001 12:43:53 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA21336 for <[e-mail]>; Tue, 24 Apr 2001 15:43:54 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 24 Apr 2001 15:43:45 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: delta-CRLs and NR
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

This is a misunderstanding of the way that delta-CRLs work. A delta-CRL specifies a base CRL and  provides a list of all certificates whose status has changed since the base CRL was issued. When using the deltaCRLIndicator, the referenced base CRL must have been issued as a full CRL (i.e., not a delta). Thus, one can always obtain complete revocation information by applying a single delta-CRL to the base CRL that it references.

If delta-CRLs are issued more frequently than full CRLs, this will just mean that multiple delta-CRLs will reference the same full CRL as their base.

With the current PKIX standard, one can always get complete revocation information by just obtaining a full CRL. If the rules were relaxed, one would be required to obtain one full CRL and one delta-CRL.

Dave

At 12:25 PM 4/24/01 -0700, Michael Myers wrote:
>I understand.  But the trajectory of the dialog seemed to be suggesting
>elimination the full CRL context, hence in that forward scenario one would
>have no choice but to face the accumulation task.  Also, the proposal to
>enable a different period of production between a full CRL and its
>associated deltas (thus enabling periods of delta-only activity between full
>CRL production) does suggest that there might exists cases where more than
>one delta is necessary to span the gap between fulls.




Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA12693 for <[e-mail]>; Tue, 24 Apr 2001 12:43:48 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3OJhVq11577; Tue, 24 Apr 2001 12:43:31 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs and NR
Date: Tue, 24 Apr 2001 12:42:02 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

Santosh,

I think we might be saying the same thing using different words.

Mike

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 12:23 PM
To: Michael Myers; Santosh Chokhani; Tom Gindin
Cc: David P. Kemp; [e-mail]
Subject: RE: delta-CRLs and NR


Even if you eliminate the full CRL, each delta refers to a "full CRL base".
The base may have been issues some time BC.  It does NOT matter.

BTW, a pragmatic way to issue deltas is to issue a base also periodically.



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA11759 for <[e-mail]>; Tue, 24 Apr 2001 12:33:03 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JSB1PMDD>; Tue, 24 Apr 2001 15:32:33 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Michael Myers <[e-mail]>, Santosh Chokhani <[e-mail]>, Tom Gindin <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: RE: delta-CRLs and NR
Date: Tue, 24 Apr 2001 15:23:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCF4.12D74C00"

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_01C0CCF4.12D74C00
Content-Type: text/plain;
	charset="iso-8859-1"

Mike:

Your last statement in contradiction with my grasp of X.509

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 3:26 PM
To: Santosh Chokhani; Tom Gindin
Cc: David P. Kemp; [e-mail]
Subject: RE: delta-CRLs and NR


I understand.  But the trajectory of the dialog seemed to be suggesting
elimination the full CRL context, hence in that forward scenario one would
have no choice but to face the accumulation task.  Also, the proposal to
enable a different period of production between a full CRL and its
associated deltas (thus enabling periods of delta-only activity between full
CRL production) does suggest that there might exists cases where more than
one delta is necessary to span the gap between fulls.

Mike


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 12:11 PM
To: Michael Myers; Tom Gindin
Cc: David P. Kemp; [e-mail]
Subject: RE: delta-CRLs and NR


Mike:
You do NOT need to accumulate all the relevant deltas.  You only need the
referenced base or later and the delta in "your hand" to create a full
revocation picture.

------_=_NextPart_001_01C0CCF4.12D74C00
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: delta-CRLs and NR</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Mike:</FONT>
</P>

<P><FONT SIZE=2>Your last statement in contradiction with my grasp of X.509</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Michael Myers [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, April 24, 2001 3:26 PM</FONT>
<BR><FONT SIZE=2>To: Santosh Chokhani; Tom Gindin</FONT>
<BR><FONT SIZE=2>Cc: David P. Kemp; [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: RE: delta-CRLs and NR</FONT>
</P>
<BR>

<P><FONT SIZE=2>I understand.&nbsp; But the trajectory of the dialog seemed to be suggesting</FONT>
<BR><FONT SIZE=2>elimination the full CRL context, hence in that forward scenario one would</FONT>
<BR><FONT SIZE=2>have no choice but to face the accumulation task.&nbsp; Also, the proposal to</FONT>
<BR><FONT SIZE=2>enable a different period of production between a full CRL and its</FONT>
<BR><FONT SIZE=2>associated deltas (thus enabling periods of delta-only activity between full</FONT>
<BR><FONT SIZE=2>CRL production) does suggest that there might exists cases where more than</FONT>
<BR><FONT SIZE=2>one delta is necessary to span the gap between fulls.</FONT>
</P>

<P><FONT SIZE=2>Mike</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Santosh Chokhani [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, April 24, 2001 12:11 PM</FONT>
<BR><FONT SIZE=2>To: Michael Myers; Tom Gindin</FONT>
<BR><FONT SIZE=2>Cc: David P. Kemp; [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: RE: delta-CRLs and NR</FONT>
</P>
<BR>

<P><FONT SIZE=2>Mike:</FONT>
<BR><FONT SIZE=2>You do NOT need to accumulate all the relevant deltas.&nbsp; You only need the</FONT>
<BR><FONT SIZE=2>referenced base or later and the delta in &quot;your hand&quot; to create a full</FONT>
<BR><FONT SIZE=2>revocation picture.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CCF4.12D74C00--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA11525 for <[e-mail]>; Tue, 24 Apr 2001 12:32:04 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JSB1PMCM>; Tue, 24 Apr 2001 15:31:35 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Michael Myers <[e-mail]>, Santosh Chokhani <[e-mail]>, Tom Gindin <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: RE: delta-CRLs and NR
Date: Tue, 24 Apr 2001 15:22:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCF3.EFF42CD0"

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_01C0CCF3.EFF42CD0
Content-Type: text/plain;
	charset="iso-8859-1"

Even if you eliminate the full CRL, each delta refers to a "full CRL base".
The base may have been issues some time BC.  It does NOT matter.

BTW, a pragmatic way to issue deltas is to issue a base also periodically.

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 3:26 PM
To: Santosh Chokhani; Tom Gindin
Cc: David P. Kemp; [e-mail]
Subject: RE: delta-CRLs and NR


I understand.  But the trajectory of the dialog seemed to be suggesting
elimination the full CRL context, hence in that forward scenario one would
have no choice but to face the accumulation task.  Also, the proposal to
enable a different period of production between a full CRL and its
associated deltas (thus enabling periods of delta-only activity between full
CRL production) does suggest that there might exists cases where more than
one delta is necessary to span the gap between fulls.

Mike


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 12:11 PM
To: Michael Myers; Tom Gindin
Cc: David P. Kemp; [e-mail]
Subject: RE: delta-CRLs and NR


Mike:
You do NOT need to accumulate all the relevant deltas.  You only need the
referenced base or later and the delta in "your hand" to create a full
revocation picture.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta-CRLs and NR</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Even if you eliminate the full CRL, each delta refers =
to a &quot;full CRL base&quot;.&nbsp; The base may have been issues =
some time BC.&nbsp; It does NOT matter.</FONT></P>

<P><FONT SIZE=3D2>BTW, a pragmatic way to issue deltas is to issue a =
base also periodically.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael Myers [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 24, 2001 3:26 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani; Tom Gindin</FONT>
<BR><FONT SIZE=3D2>Cc: David P. Kemp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta-CRLs and NR</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I understand.&nbsp; But the trajectory of the dialog =
seemed to be suggesting</FONT>
<BR><FONT SIZE=3D2>elimination the full CRL context, hence in that =
forward scenario one would</FONT>
<BR><FONT SIZE=3D2>have no choice but to face the accumulation =
task.&nbsp; Also, the proposal to</FONT>
<BR><FONT SIZE=3D2>enable a different period of production between a =
full CRL and its</FONT>
<BR><FONT SIZE=3D2>associated deltas (thus enabling periods of =
delta-only activity between full</FONT>
<BR><FONT SIZE=3D2>CRL production) does suggest that there might exists =
cases where more than</FONT>
<BR><FONT SIZE=3D2>one delta is necessary to span the gap between =
fulls.</FONT>
</P>

<P><FONT SIZE=3D2>Mike</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 24, 2001 12:11 PM</FONT>
<BR><FONT SIZE=3D2>To: Michael Myers; Tom Gindin</FONT>
<BR><FONT SIZE=3D2>Cc: David P. Kemp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta-CRLs and NR</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Mike:</FONT>
<BR><FONT SIZE=3D2>You do NOT need to accumulate all the relevant =
deltas.&nbsp; You only need the</FONT>
<BR><FONT SIZE=3D2>referenced base or later and the delta in &quot;your =
hand&quot; to create a full</FONT>
<BR><FONT SIZE=3D2>revocation picture.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CCF3.EFF42CD0--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA11166 for <[e-mail]>; Tue, 24 Apr 2001 12:30:29 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JSB1PMB1>; Tue, 24 Apr 2001 15:29:59 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: Santosh Chokhani <[e-mail]>, [e-mail]
Subject: RE: Dedicated CRL signing keys
Date: Tue, 24 Apr 2001 15:21:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCF3.B68BFA40"

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_01C0CCF3.B68BFA40
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:

But the semantics of that extension does NOT mean that the CRL is signed by
a different key.

Actually, a CA typically uses this extension, chops up the CRL and signs
them all using the SAME key.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 3:11 PM
To: Santosh Chokhani
Cc: Santosh Chokhani; [e-mail]
Subject: RE: Dedicated CRL signing keys


At 05:25 PM 4/23/2001 -0400, Santosh Chokhani wrote:
> >First, I think that the restriction that a CA who desires to issue
> >Indirect CRL needs to set itself up as a separate name is unduly
> >restrictive.  There is no need for a CA to do that.  A CA can issue a
full
> >CRL as well as an Indirect CRL and populate these in the same or
different
> >entries (i.e., CRL DP) in the directory.  Please review Annex B of X.509
> >for how to process CRL.  So, may be Russ can explain why this requirement
> >comes about.
>
>I agree that the use of a separate name is overly restrictive.  That
>portion of my suggestion was, in hind sight, a bad idea.  As Tim Polk
>pointed out, CAs cannot change their names when they rekey.
>
>I think that everyone agrees that a CA makes a commitment to provide some
>form of revocation information for the duration of the certificate
>life.  When CRLs are employed, does the CA use the same key to sign the CRL
>as was used to sign the certificate?  Clearly, the CA is permitted to use
>different keys -- the key usage bits are there to allow this
>separation.  However, several clients cannot handle this situation, and
>they would like to see an error message that says "unsupported feature"
>instead of "signature invalid."
>
>Perhaps CA rekey will lead us to an answer.  When a CA rekeys, does it are
>subsequent CRLs signed with the new key or the old one?  A CA could
>generate one CRL with each key.  They two CRLs could even be distributed by
>different distribution point to avoid the download of CRLs that cannot be
>employed.  Alternatively, the CA could publish one CRL signed with the new
>key.  This leads to the scenario where cert path construction must be
>evoked to generate validate the CRL when trying to validate a certificate
>signed by the old key.  This is the behavior that we are trying to make 
>SHOULD.
>
>Therefore, the CA MUST generate the CRL using the same key as was used to
>sign the certificate, or it MUST include an extension in the CRL to
>indicate that cert path construction might be needed to validate the CRL
>signature.  I proposed that an Issuing Distribution Point (IDP) CRL
>extension might be the correct approach.  The IDP extension will not be
>supported by the simple clients, so they can generate the "unsupported
>feature" error, and the more complex clients can use the information in the
>IDP to support path construction.  They will of course, also use Authority
>Key Identifier extension.
>
>{Santosh Says: Item 1 will require a change to the IDP extension 
>syntax.  Would n't that make PKIX non-compliant with X.509?)


The IDP syntax is:

    issuingDistributionPoint ::= SEQUENCE {
         distributionPoint       [0] DistributionPointName OPTIONAL,
         onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
         onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
         onlySomeReasons         [3] ReasonFlags OPTIONAL,
         indirectCRL             [4] BOOLEAN DEFAULT FALSE }

I was simply suggesting that this extension be present if the CRL is signed 
with a key other than the one used to sign the certificate.  I would expect 
the distributionPoint field to be present (probably with a URL 
(ldap://...)).  The boolean flags would be set based on the contents of the 
CRL (probably all FALSE).  The reason codes would also be set based on the 
contents of the CRL (probably absent).

Russ

------_=_NextPart_001_01C0CCF3.B68BFA40
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Dedicated CRL signing keys</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Russ:</FONT>
</P>

<P><FONT SIZE=2>But the semantics of that extension does NOT mean that the CRL is signed by a different key.</FONT>
</P>

<P><FONT SIZE=2>Actually, a CA typically uses this extension, chops up the CRL and signs them all using the SAME key.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Housley, Russ [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, April 24, 2001 3:11 PM</FONT>
<BR><FONT SIZE=2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=2>Cc: Santosh Chokhani; [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: RE: Dedicated CRL signing keys</FONT>
</P>
<BR>

<P><FONT SIZE=2>At 05:25 PM 4/23/2001 -0400, Santosh Chokhani wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;First, I think that the restriction that a CA who desires to issue</FONT>
<BR><FONT SIZE=2>&gt; &gt;Indirect CRL needs to set itself up as a separate name is unduly</FONT>
<BR><FONT SIZE=2>&gt; &gt;restrictive.&nbsp; There is no need for a CA to do that.&nbsp; A CA can issue a full</FONT>
<BR><FONT SIZE=2>&gt; &gt;CRL as well as an Indirect CRL and populate these in the same or different</FONT>
<BR><FONT SIZE=2>&gt; &gt;entries (i.e., CRL DP) in the directory.&nbsp; Please review Annex B of X.509</FONT>
<BR><FONT SIZE=2>&gt; &gt;for how to process CRL.&nbsp; So, may be Russ can explain why this requirement</FONT>
<BR><FONT SIZE=2>&gt; &gt;comes about.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I agree that the use of a separate name is overly restrictive.&nbsp; That</FONT>
<BR><FONT SIZE=2>&gt;portion of my suggestion was, in hind sight, a bad idea.&nbsp; As Tim Polk</FONT>
<BR><FONT SIZE=2>&gt;pointed out, CAs cannot change their names when they rekey.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I think that everyone agrees that a CA makes a commitment to provide some</FONT>
<BR><FONT SIZE=2>&gt;form of revocation information for the duration of the certificate</FONT>
<BR><FONT SIZE=2>&gt;life.&nbsp; When CRLs are employed, does the CA use the same key to sign the CRL</FONT>
<BR><FONT SIZE=2>&gt;as was used to sign the certificate?&nbsp; Clearly, the CA is permitted to use</FONT>
<BR><FONT SIZE=2>&gt;different keys -- the key usage bits are there to allow this</FONT>
<BR><FONT SIZE=2>&gt;separation.&nbsp; However, several clients cannot handle this situation, and</FONT>
<BR><FONT SIZE=2>&gt;they would like to see an error message that says &quot;unsupported feature&quot;</FONT>
<BR><FONT SIZE=2>&gt;instead of &quot;signature invalid.&quot;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Perhaps CA rekey will lead us to an answer.&nbsp; When a CA rekeys, does it are</FONT>
<BR><FONT SIZE=2>&gt;subsequent CRLs signed with the new key or the old one?&nbsp; A CA could</FONT>
<BR><FONT SIZE=2>&gt;generate one CRL with each key.&nbsp; They two CRLs could even be distributed by</FONT>
<BR><FONT SIZE=2>&gt;different distribution point to avoid the download of CRLs that cannot be</FONT>
<BR><FONT SIZE=2>&gt;employed.&nbsp; Alternatively, the CA could publish one CRL signed with the new</FONT>
<BR><FONT SIZE=2>&gt;key.&nbsp; This leads to the scenario where cert path construction must be</FONT>
<BR><FONT SIZE=2>&gt;evoked to generate validate the CRL when trying to validate a certificate</FONT>
<BR><FONT SIZE=2>&gt;signed by the old key.&nbsp; This is the behavior that we are trying to make </FONT>
<BR><FONT SIZE=2>&gt;SHOULD.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Therefore, the CA MUST generate the CRL using the same key as was used to</FONT>
<BR><FONT SIZE=2>&gt;sign the certificate, or it MUST include an extension in the CRL to</FONT>
<BR><FONT SIZE=2>&gt;indicate that cert path construction might be needed to validate the CRL</FONT>
<BR><FONT SIZE=2>&gt;signature.&nbsp; I proposed that an Issuing Distribution Point (IDP) CRL</FONT>
<BR><FONT SIZE=2>&gt;extension might be the correct approach.&nbsp; The IDP extension will not be</FONT>
<BR><FONT SIZE=2>&gt;supported by the simple clients, so they can generate the &quot;unsupported</FONT>
<BR><FONT SIZE=2>&gt;feature&quot; error, and the more complex clients can use the information in the</FONT>
<BR><FONT SIZE=2>&gt;IDP to support path construction.&nbsp; They will of course, also use Authority</FONT>
<BR><FONT SIZE=2>&gt;Key Identifier extension.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;{Santosh Says: Item 1 will require a change to the IDP extension </FONT>
<BR><FONT SIZE=2>&gt;syntax.&nbsp; Would n't that make PKIX non-compliant with X.509?)</FONT>
</P>
<BR>

<P><FONT SIZE=2>The IDP syntax is:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; issuingDistributionPoint ::= SEQUENCE {</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; distributionPoint&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [0] DistributionPointName OPTIONAL,</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; onlyContainsUserCerts&nbsp;&nbsp; [1] BOOLEAN DEFAULT FALSE,</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; onlyContainsCACerts&nbsp;&nbsp;&nbsp;&nbsp; [2] BOOLEAN DEFAULT FALSE,</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; onlySomeReasons&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [3] ReasonFlags OPTIONAL,</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indirectCRL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [4] BOOLEAN DEFAULT FALSE }</FONT>
</P>

<P><FONT SIZE=2>I was simply suggesting that this extension be present if the CRL is signed </FONT>
<BR><FONT SIZE=2>with a key other than the one used to sign the certificate.&nbsp; I would expect </FONT>
<BR><FONT SIZE=2>the distributionPoint field to be present (probably with a URL </FONT>
<BR><FONT SIZE=2>(ldap://...)).&nbsp; The boolean flags would be set based on the contents of the </FONT>
<BR><FONT SIZE=2>CRL (probably all FALSE).&nbsp; The reason codes would also be set based on the </FONT>
<BR><FONT SIZE=2>contents of the CRL (probably absent).</FONT>
</P>

<P><FONT SIZE=2>Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CCF3.B68BFA40--


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA10731 for <[e-mail]>; Tue, 24 Apr 2001 12:27:25 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3OJRGq10114; Tue, 24 Apr 2001 12:27:17 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs and NR
Date: Tue, 24 Apr 2001 12:25:48 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

I understand.  But the trajectory of the dialog seemed to be suggesting
elimination the full CRL context, hence in that forward scenario one would
have no choice but to face the accumulation task.  Also, the proposal to
enable a different period of production between a full CRL and its
associated deltas (thus enabling periods of delta-only activity between full
CRL production) does suggest that there might exists cases where more than
one delta is necessary to span the gap between fulls.

Mike


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 12:11 PM
To: Michael Myers; Tom Gindin
Cc: David P. Kemp; [e-mail]
Subject: RE: delta-CRLs and NR


Mike:
You do NOT need to accumulate all the relevant deltas.  You only need the
referenced base or later and the delta in "your hand" to create a full
revocation picture.



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA10018 for <[e-mail]>; Tue, 24 Apr 2001 12:20:30 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JSB1PL59>; Tue, 24 Apr 2001 15:20:00 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Michael Myers <[e-mail]>, Tom Gindin <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: RE: delta-CRLs and NR
Date: Tue, 24 Apr 2001 15:11:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCF2.51AC6B60"

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_01C0CCF2.51AC6B60
Content-Type: text/plain;
	charset="iso-8859-1"

Mike:

You do NOT need to accumulate all the relevant deltas.  You only need the
referenced base or later and the delta in "your hand" to create a full
revocation picture.

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 2:32 PM
To: Tom Gindin
Cc: David P. Kemp; [e-mail]
Subject: RE: delta-CRLs and NR


Tom,

Perhaps I should have used the term "dispute resolution process" instead of
"non-repudiation".  I was thinking more in terms of that process and the
general notion that one can never have too much documentation proving one's
point--i.e. in this case the indisputably "full" CRL-- whereas in day to day
activities the efficiencies gained by deltas cover what undoubtedly will be
the vastly larger number of undisputed transactions.

So I was thinking that it would be unwise for us to needlessly burden 99%(?)
of the solution space to address issues associated with the remaining 1%,
hence break out fulls from deltas.  Now, I'm not a lawyer, but that all
said, I think the assured presence of a full CRL in the case of a "dispute
resolution event" would very useful to that 1%.  One is otherwise faced with
proving that one had fully accumulated all relevant deltas.  Thus mandate
fulls as an assured baseline regardless of the PKI context, but with perhaps
a longer production period that nonetheless contributes evidence to a
possible discovery process.  Again, I'm not a lawyer, but I have played with
them on the street.

Ultimately, I'm still convinced that the only effective resolution is a
dynamically produced, digitally signed assertion (i.e. OCSPv2 with its DPV
extension).  But that's an entirely different buffalo hunt.

Mike



> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: Tuesday, April 24, 2001 10:43 AM
> To: Michael Myers
> Cc: David P. Kemp; [e-mail]
> Subject: RE: delta-CRLs and NR
>
>
>
>      When non-repudiation is an actual practice, doesn't the revocation
> status need to be checked as of a time no earlier than the actual
> signature
> of the non-repudiable message or document?  And won't a full CRL (or a
> delta, for that matter) rarely have been published with such an effective
> time at the time an RP initially receives such a message or document?
>      It is perfectly true that it is much easier to check a
> single full CRL
> than a CRL with deltas.  However, I don't see why the problem is more
> severe for NR except that an NR system is even less tolerant of false
> negatives on revocation than authentication is.
>
>           Tom Gindin
>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta-CRLs and NR</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>You do NOT need to accumulate all the relevant =
deltas.&nbsp; You only need the referenced base or later and the delta =
in &quot;your hand&quot; to create a full revocation =
picture.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael Myers [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 24, 2001 2:32 PM</FONT>
<BR><FONT SIZE=3D2>To: Tom Gindin</FONT>
<BR><FONT SIZE=3D2>Cc: David P. Kemp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta-CRLs and NR</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>Perhaps I should have used the term &quot;dispute =
resolution process&quot; instead of</FONT>
<BR><FONT SIZE=3D2>&quot;non-repudiation&quot;.&nbsp; I was thinking =
more in terms of that process and the</FONT>
<BR><FONT SIZE=3D2>general notion that one can never have too much =
documentation proving one's</FONT>
<BR><FONT SIZE=3D2>point--i.e. in this case the indisputably =
&quot;full&quot; CRL-- whereas in day to day</FONT>
<BR><FONT SIZE=3D2>activities the efficiencies gained by deltas cover =
what undoubtedly will be</FONT>
<BR><FONT SIZE=3D2>the vastly larger number of undisputed =
transactions.</FONT>
</P>

<P><FONT SIZE=3D2>So I was thinking that it would be unwise for us to =
needlessly burden 99%(?)</FONT>
<BR><FONT SIZE=3D2>of the solution space to address issues associated =
with the remaining 1%,</FONT>
<BR><FONT SIZE=3D2>hence break out fulls from deltas.&nbsp; Now, I'm =
not a lawyer, but that all</FONT>
<BR><FONT SIZE=3D2>said, I think the assured presence of a full CRL in =
the case of a &quot;dispute</FONT>
<BR><FONT SIZE=3D2>resolution event&quot; would very useful to that =
1%.&nbsp; One is otherwise faced with</FONT>
<BR><FONT SIZE=3D2>proving that one had fully accumulated all relevant =
deltas.&nbsp; Thus mandate</FONT>
<BR><FONT SIZE=3D2>fulls as an assured baseline regardless of the PKI =
context, but with perhaps</FONT>
<BR><FONT SIZE=3D2>a longer production period that nonetheless =
contributes evidence to a</FONT>
<BR><FONT SIZE=3D2>possible discovery process.&nbsp; Again, I'm not a =
lawyer, but I have played with</FONT>
<BR><FONT SIZE=3D2>them on the street.</FONT>
</P>

<P><FONT SIZE=3D2>Ultimately, I'm still convinced that the only =
effective resolution is a</FONT>
<BR><FONT SIZE=3D2>dynamically produced, digitally signed assertion =
(i.e. OCSPv2 with its DPV</FONT>
<BR><FONT SIZE=3D2>extension).&nbsp; But that's an entirely different =
buffalo hunt.</FONT>
</P>

<P><FONT SIZE=3D2>Mike</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Tom Gindin [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, April 24, 2001 10:43 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Michael Myers</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: David P. Kemp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: delta-CRLs and NR</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When =
non-repudiation is an actual practice, doesn't the revocation</FONT>
<BR><FONT SIZE=3D2>&gt; status need to be checked as of a time no =
earlier than the actual</FONT>
<BR><FONT SIZE=3D2>&gt; signature</FONT>
<BR><FONT SIZE=3D2>&gt; of the non-repudiable message or =
document?&nbsp; And won't a full CRL (or a</FONT>
<BR><FONT SIZE=3D2>&gt; delta, for that matter) rarely have been =
published with such an effective</FONT>
<BR><FONT SIZE=3D2>&gt; time at the time an RP initially receives such =
a message or document?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It is perfectly =
true that it is much easier to check a</FONT>
<BR><FONT SIZE=3D2>&gt; single full CRL</FONT>
<BR><FONT SIZE=3D2>&gt; than a CRL with deltas.&nbsp; However, I don't =
see why the problem is more</FONT>
<BR><FONT SIZE=3D2>&gt; severe for NR except that an NR system is even =
less tolerant of false</FONT>
<BR><FONT SIZE=3D2>&gt; negatives on revocation than authentication =
is.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Tom Gindin</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CCF2.51AC6B60--


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA09558 for <[e-mail]>; Tue, 24 Apr 2001 12:18:50 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Apr 2001 19:18:50 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA28089; Tue, 24 Apr 2001 15:18:46 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JS35YVTT>; Tue, 24 Apr 2001 15:18:46 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.102]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JS35YVTR; Tue, 24 Apr 2001 15:18:40 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: Santosh Chokhani <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 24 Apr 2001 15:10:42 -0400
Subject: RE: Dedicated CRL signing keys
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:25 PM 4/23/2001 -0400, Santosh Chokhani wrote:
> >First, I think that the restriction that a CA who desires to issue
> >Indirect CRL needs to set itself up as a separate name is unduly
> >restrictive.  There is no need for a CA to do that.  A CA can issue a full
> >CRL as well as an Indirect CRL and populate these in the same or different
> >entries (i.e., CRL DP) in the directory.  Please review Annex B of X.509
> >for how to process CRL.  So, may be Russ can explain why this requirement
> >comes about.
>
>I agree that the use of a separate name is overly restrictive.  That
>portion of my suggestion was, in hind sight, a bad idea.  As Tim Polk
>pointed out, CAs cannot change their names when they rekey.
>
>I think that everyone agrees that a CA makes a commitment to provide some
>form of revocation information for the duration of the certificate
>life.  When CRLs are employed, does the CA use the same key to sign the CRL
>as was used to sign the certificate?  Clearly, the CA is permitted to use
>different keys -- the key usage bits are there to allow this
>separation.  However, several clients cannot handle this situation, and
>they would like to see an error message that says "unsupported feature"
>instead of "signature invalid."
>
>Perhaps CA rekey will lead us to an answer.  When a CA rekeys, does it are
>subsequent CRLs signed with the new key or the old one?  A CA could
>generate one CRL with each key.  They two CRLs could even be distributed by
>different distribution point to avoid the download of CRLs that cannot be
>employed.  Alternatively, the CA could publish one CRL signed with the new
>key.  This leads to the scenario where cert path construction must be
>evoked to generate validate the CRL when trying to validate a certificate
>signed by the old key.  This is the behavior that we are trying to make 
>SHOULD.
>
>Therefore, the CA MUST generate the CRL using the same key as was used to
>sign the certificate, or it MUST include an extension in the CRL to
>indicate that cert path construction might be needed to validate the CRL
>signature.  I proposed that an Issuing Distribution Point (IDP) CRL
>extension might be the correct approach.  The IDP extension will not be
>supported by the simple clients, so they can generate the "unsupported
>feature" error, and the more complex clients can use the information in the
>IDP to support path construction.  They will of course, also use Authority
>Key Identifier extension.
>
>{Santosh Says: Item 1 will require a change to the IDP extension 
>syntax.  Would n't that make PKIX non-compliant with X.509?)


The IDP syntax is:

    issuingDistributionPoint ::= SEQUENCE {
         distributionPoint       [0] DistributionPointName OPTIONAL,
         onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
         onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
         onlySomeReasons         [3] ReasonFlags OPTIONAL,
         indirectCRL             [4] BOOLEAN DEFAULT FALSE }

I was simply suggesting that this extension be present if the CRL is signed 
with a key other than the one used to sign the certificate.  I would expect 
the distributionPoint field to be present (probably with a URL 
(ldap://...)).  The boolean flags would be set based on the contents of the 
CRL (probably all FALSE).  The reason codes would also be set based on the 
contents of the CRL (probably absent).

Russ


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA09559 for <[e-mail]>; Tue, 24 Apr 2001 12:18:51 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Apr 2001 19:18:51 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA28090; Tue, 24 Apr 2001 15:18:46 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JS35YVTS>; Tue, 24 Apr 2001 15:18:46 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.102]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JS35YVTQ; Tue, 24 Apr 2001 15:18:39 -0400
From: "Housley, Russ" <[e-mail]>
To: Sharon Boeyen <[e-mail]>
Cc: "'Carlin Covey'" <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 24 Apr 2001 15:03:14 -0400
Subject: RE: delta-CRLs (was Re: Last  Call:draft-ietf-pkix-new-part1-06.t xt  comments)
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I strongly agree with this observation.

At 04:10 PM 4/23/2001 -0400, Sharon Boeyen wrote:
>I suspect indirectDeltas are beyond the scope of what 2459 plans to cover


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA08180 for <[e-mail]>; Tue, 24 Apr 2001 11:50:33 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA25671 for <[e-mail]>; Tue, 24 Apr 2001 14:50:05 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Tue, 24 Apr 2001 14:48:09 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: keyCertSign and cRLSign Key Usage Bits
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

With regard to keyCertSign:

I still don't see a definition of "CA certificates", so I still think
sentence 2 ("This bit MUST only be asserted in CA certificates.") should
be deleted.  Is the following true?

   If the cA bit or the keyCertSign bit is asserted, then the
   certificate is a CA certificate.
   If neither the cA bit nor the keyCertSign bit are asserted, then
   the certificate is not a CA certificate.

If those statements are true, then sentence 2 adds nothing except
confusion: there is the question of whether it is the identical
requirement to sentence 3 or a different requirement.

Sentences 3 and 4 are quite sufficient; sentence 2 should be deleted.

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

The second paragraph assumes that we have consensus that the cA bit
should be used to determine which authorities can revoke which certs.
I don't believe there is consensus on that point.

Additionally:

* Sentences 1 and 2 are redundant; only one of them is needed.

* Sentence 3 does not contain any useful information about cRLSign.
(If the cRLSign bit is *not* asserted in a CA certificate, the cA bit
must still be asserted.)

* Sentence 4 is a policy statement unrelated to CRL signing. Do we have
consensus that a CA may not also be an AA?  If so, that policy should
be stated under attribute certificate issuance, not under key usage.

* Sentence 5 does not define "AA certificates".  Should an AA be able
to sign CRLs using a new key which lists ACs signed with the old key?
Should an AA be able to delegate CRL signing to a key that cannot sign
ACs?  (I believe the consensus is yes on both counts.)  If so, and if
PKIX is to have a testable requirement along the lines of your new
langage, then it must tell implementations how to recognize an
"AA certificate", including one that can revoke but cannot sign ACs.

* The final sentence is repeated verbatim from paragraph 1; does it have
any greater effect if written twice?

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

I propose something quite close to the language in new-part1-04.  The
rest of your new cRLSign language is just fluff because there is no way
to determine whether an application complies with it.


        The keyCertSign bit is asserted when the subject public key
        is used for verifying a signature on public key certificates.
        If the keyCertSign bit is asserted, then the cA bit in the basic
        constraints extension (see 4.2.1.10) MUST also be asserted.
        If neither the keyCertSign bit nor the cRLSign bit are asserted,
        then the cA bit in the basic constraints extension MUST NOT be
        asserted.

        The cRLSign bit MUST be asserted when the subject public key is
        used for verifying a signature on certificate revocation lists
        (e.g., CRLs or ARLs).
            {If the cRLSign bit is asserted, then either the cA bit
             in the basic constraints extension or the the authority
             bit in the basicAttConstraints extension MUST also be
             asserted.}*


* The last sentence, in {braces}, is an example of how one might
write a testable requirement.  I don't actually believe it should be
included in 2459bis.

If PKIX wants to use the cA bit to control revocation, and it
is not going to profile X.509's SOAIdentifier or basicAttConstraints
extensions, then it MUST use something other than handwaving to
distinguish EE certs from AA certs.  That's why I don't believe there
should be any linkage between the cRLSign bit and the cA bit.

Dave




"Housley, Russ" wrote:
> 
> The consensus on these bits is not totally clear to me.  Yet, several
> points have been consistently, and I think that the following text
> incorporates them.  The debate regarding he linkage between these bits and
> the cA bit in the basic constraints extension does not seem to be over, and
> I have not made any changes in that area.  Please use this new thread to
> discuss any remaining unresolved points.
> 
>        The keyCertSign bit is asserted when the subject public key is
>        used for verifying a signature on public key certificates.  This
>        bit MUST only be asserted in CA certificates.  If the keyCertSign
>        bit is asserted, then the cA bit in the basic constraints
>        extension (see 4.2.1.10) MUST also be asserted.  If neither the
>        cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
>        in the basic constraints extension MUST NOT be asserted.
> 
>        The cRLSign bit is asserted when the subject public key is used
>        for verifying a signature on a certificate revocation list (e.g.,
>        a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
>        Authority (AA) certificates that are used to verify signatures on
>        CRLs.  If the cRLSign bit is asserted in a CA certificate, then
>        the cA bit in the basic constraints extension (see 4.2.1.10) MUST
>        also be asserted.  If the cRLSign bit is asserted in a AA
>        certificate, then the cA bit in the basic constraints extension
>        MUST NOT be asserted.  Such AA certificates MUST NOT be used to
>        verify signatures on CRLs containing revocation information for
>        public key certificates; however, these AA certificates MAY be
>        used to verify signatures on CRLs containing revocation
>        information concerning attribute certificates.  If neither the
>        cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
>        in the basic constraints extension MUST NOT be asserted.
> 
> Russ


Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA07985 for <[e-mail]>; Tue, 24 Apr 2001 11:50:06 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA63472; Tue, 24 Apr 2001 14:48:09 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id OAA61920; Tue, 24 Apr 2001 14:44:40 -0400
Importance: Normal
Subject: RE: delta-CRLs and NR
To: "Michael Myers" <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 24 Apr 2001 14:49:40 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 04/24/2001 02:49:35 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     The dispute resolver's point of view is indeed the critical one for
NR.  However, 2459 section 5.2.4 says that it only takes one delta CRL in
combination with its base CRL to give all the information in a full CRL
with the effective time of the delta.  Thus, the data to be checked during
dispute resolution would only need to consist of either a full CRL with
time after the document signature or of a delta CRL with such a time along
with its base CRL, as would the data which the RP or escrow holder need to
archive.  Thank you for your help on this, as I need to clarify some
wording in the techNR draft.

          Tom Gindin


"Michael Myers" <[e-mail]> on 04/24/2001 02:31:45 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject:  RE: delta-CRLs and NR


Tom,

Perhaps I should have used the term "dispute resolution process" instead of
"non-repudiation".  I was thinking more in terms of that process and the
general notion that one can never have too much documentation proving one's
point--i.e. in this case the indisputably "full" CRL-- whereas in day to
day
activities the efficiencies gained by deltas cover what undoubtedly will be
the vastly larger number of undisputed transactions.

So I was thinking that it would be unwise for us to needlessly burden 99%
(?)
of the solution space to address issues associated with the remaining 1%,
hence break out fulls from deltas.  Now, I'm not a lawyer, but that all
said, I think the assured presence of a full CRL in the case of a "dispute
resolution event" would very useful to that 1%.  One is otherwise faced
with
proving that one had fully accumulated all relevant deltas.  Thus mandate
fulls as an assured baseline regardless of the PKI context, but with
perhaps
a longer production period that nonetheless contributes evidence to a
possible discovery process.  Again, I'm not a lawyer, but I have played
with
them on the street.

Ultimately, I'm still convinced that the only effective resolution is a
dynamically produced, digitally signed assertion (i.e. OCSPv2 with its DPV
extension).  But that's an entirely different buffalo hunt.

Mike



> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: Tuesday, April 24, 2001 10:43 AM
> To: Michael Myers
> Cc: David P. Kemp; [e-mail]
> Subject: RE: delta-CRLs and NR
>
>
>
>      When non-repudiation is an actual practice, doesn't the revocation
> status need to be checked as of a time no earlier than the actual
> signature
> of the non-repudiable message or document?  And won't a full CRL (or a
> delta, for that matter) rarely have been published with such an effective
> time at the time an RP initially receives such a message or document?
>      It is perfectly true that it is much easier to check a
> single full CRL
> than a CRL with deltas.  However, I don't see why the problem is more
> severe for NR except that an NR system is even less tolerant of false
> negatives on revocation than authentication is.
>
>           Tom Gindin
>







Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA07479 for <[e-mail]>; Tue, 24 Apr 2001 11:44:02 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id LAA28442; Tue, 24 Apr 2001 11:43:33 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA13575; Tue, 24 Apr 2001 11:43:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 24 Apr 2001 11:48:30 -0700
To: "Housley, Russ" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: keyCertSign and cRLSign Key Usage Bits
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 10:36 AM 4/24/01 -0400, Housley, Russ wrote:
>The consensus on these bits is not totally clear to me.  Yet, several 
>points have been consistently, and I think that the following text 
>incorporates them.  The debate regarding he linkage between these bits and 
>the cA bit in the basic constraints extension does not seem to be over, 
>and I have not made any changes in that area.  Please use this new thread 
>to discuss any remaining unresolved points.
>
>       The keyCertSign bit is asserted when the subject public key is
>       used for verifying a signature on public key certificates.  This
>       bit MUST only be asserted in CA certificates.  If the keyCertSign
>       bit is asserted, then the cA bit in the basic constraints
>       extension (see 4.2.1.10) MUST also be asserted.  If neither the
>       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
>       in the basic constraints extension MUST NOT be asserted.

Russ,

Just a clarification on grammar.  I find the statement,

>       "This bit MUST only be asserted in CA certificates"

to be a source of ambiguity.  It can be interpreted either as

A)      It is a "MUST" that the bit be set ONLY in CA certificates.

         I.e., "bit asserted" implies "CA certificate"

         (This is the correct grammatical interpretation.)
or

B)      It is a "MUST" that the bit be set ONLY in CA certificates,
         AND the bit MUST BE set in all CA certificates.

         I.e., "bit asserted" IFF "CA certificate"

         (This is not what is grammatically implied by the statement,
         but it "sounds like" it is.)

___tony___



Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA07025 for <[e-mail]>; Tue, 24 Apr 2001 11:38:04 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Apr 2001 18:38:04 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA24234 for <[e-mail]>; Tue, 24 Apr 2001 14:38:05 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <JS35YT7X>; Tue, 24 Apr 2001 14:38:05 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.102]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JS35YT7M; Tue, 24 Apr 2001 14:38:00 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 24 Apr 2001 14:26:38 -0400
Subject: RE: Dedicated CRL signing keys
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Santosh:

Interoperability is just as important as security.  Further, complexity 
leads to implementation flaws which reduces security.  In several places, 
the working group has decided that interoperability is more important than 
security.  In fact, the PKIX profile does not require that a CA issue CRLs 
(see section 3.3, last paragraph).

The PKIX profile places requirements on CAs and clients.  How can we say 
that clients MUST be able to handle certs and CRLs signed with different 
keys when we do not require CAs to issue them at all?  Further, placing 
such a requirement on clients forces them to be able to build certification 
paths during CRL checking.  We already know that some clients cannot do 
this (an interoperability issue).  And, asking them to do so will add 
complexity (a security assurance issue).

Russ


At 08:54 AM 4/24/2001 -0400, Santosh Chokhani wrote:

>Russ:
>
>One of your comments yesterday was that we can make a choice between 
>simpler client and operational security when I said that some 
>implementations require separate CRL signing keys for operational security 
>reasons.
>
>While I agree with you that this is a trade-off an enterprise needs to 
>make.  But, I think the Internet RFC should not make such a choice.  I am 
>saying that the RFC should permit both:  simple client (same key for 
>certificate and CRL signing) as well as different keys for certificate and 
>CRL signing.
>
>PKIX working group is after all, all about security.  We should not say 
>that a secure implementation is not compliant with PKIX.


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA06649 for <[e-mail]>; Tue, 24 Apr 2001 11:33:16 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3OIXDq03633; Tue, 24 Apr 2001 11:33:13 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs and NR
Date: Tue, 24 Apr 2001 11:31:45 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

Tom,

Perhaps I should have used the term "dispute resolution process" instead of
"non-repudiation".  I was thinking more in terms of that process and the
general notion that one can never have too much documentation proving one's
point--i.e. in this case the indisputably "full" CRL-- whereas in day to day
activities the efficiencies gained by deltas cover what undoubtedly will be
the vastly larger number of undisputed transactions.

So I was thinking that it would be unwise for us to needlessly burden 99%(?)
of the solution space to address issues associated with the remaining 1%,
hence break out fulls from deltas.  Now, I'm not a lawyer, but that all
said, I think the assured presence of a full CRL in the case of a "dispute
resolution event" would very useful to that 1%.  One is otherwise faced with
proving that one had fully accumulated all relevant deltas.  Thus mandate
fulls as an assured baseline regardless of the PKI context, but with perhaps
a longer production period that nonetheless contributes evidence to a
possible discovery process.  Again, I'm not a lawyer, but I have played with
them on the street.

Ultimately, I'm still convinced that the only effective resolution is a
dynamically produced, digitally signed assertion (i.e. OCSPv2 with its DPV
extension).  But that's an entirely different buffalo hunt.

Mike



> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: Tuesday, April 24, 2001 10:43 AM
> To: Michael Myers
> Cc: David P. Kemp; [e-mail]
> Subject: RE: delta-CRLs and NR
>
>
>
>      When non-repudiation is an actual practice, doesn't the revocation
> status need to be checked as of a time no earlier than the actual
> signature
> of the non-repudiable message or document?  And won't a full CRL (or a
> delta, for that matter) rarely have been published with such an effective
> time at the time an RP initially receives such a message or document?
>      It is perfectly true that it is much easier to check a
> single full CRL
> than a CRL with deltas.  However, I don't see why the problem is more
> severe for NR except that an NR system is even less tolerant of false
> negatives on revocation than authentication is.
>
>           Tom Gindin
>



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA04530 for <[e-mail]>; Tue, 24 Apr 2001 10:56:31 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 24 Apr 2001 10:56:41 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Tue, 24 Apr 2001 10:56:41 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26P72Z>; Tue, 24 Apr 2001 10:55:20 -0700
Content-return: allowed
Date: Tue, 24 Apr 2001 10:55:20 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: keyCertSign and cRLSign Key Usage Bits
To: "'Santosh Chokhani'" <[e-mail]>, "Housley, Russ" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_zhpmWWWEGepGsY3IvLfDxg)"

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_zhpmWWWEGepGsY3IvLfDxg)
Content-type: text/plain; charset="iso-8859-1"

 
I agree, also.

Ambarish
 

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


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 8:22 AM
To: Housley, Russ; [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits



Russ: I agree with the text. 

I also know that Steve Kent and Sharon Boeyen feel that X.509 states that
only CA can issue CRL (the context of my comments being PKI only and not
PMI).

But, using the theory that you suggest that the client be forgiving, I would
consider a client compliant if it did NOT check the basic constraint
extension while verifying a signature on a CRL.  It need to ensure that the
cRLSign bit is set in the keyUsage extension.

-----Original Message----- 
From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Tuesday, April 24, 2001 10:37 AM 
To: [e-mail] 
Subject: keyCertSign and cRLSign Key Usage Bits 


The consensus on these bits is not totally clear to me.  Yet, several 
points have been consistently, and I think that the following text 
incorporates them.  The debate regarding he linkage between these bits and 
the cA bit in the basic constraints extension does not seem to be over, and 
I have not made any changes in that area.  Please use this new thread to 
discuss any remaining unresolved points. 

       The keyCertSign bit is asserted when the subject public key is 
       used for verifying a signature on public key certificates.  This 
       bit MUST only be asserted in CA certificates.  If the keyCertSign 
       bit is asserted, then the cA bit in the basic constraints 
       extension (see 4.2.1.10) MUST also be asserted.  If neither the 
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit 
       in the basic constraints extension MUST NOT be asserted. 

       The cRLSign bit is asserted when the subject public key is used 
       for verifying a signature on a certificate revocation list (e.g., 
       a CRL or an ARL).  This bit MUST be asserted in CA and Attribute 
       Authority (AA) certificates that are used to verify signatures on 
       CRLs.  If the cRLSign bit is asserted in a CA certificate, then 
       the cA bit in the basic constraints extension (see 4.2.1.10) MUST 
       also be asserted.  If the cRLSign bit is asserted in a AA 
       certificate, then the cA bit in the basic constraints extension 
       MUST NOT be asserted.  Such AA certificates MUST NOT be used to 
       verify signatures on CRLs containing revocation information for 
       public key certificates; however, these AA certificates MAY be 
       used to verify signatures on CRLs containing revocation 
       information concerning attribute certificates.  If neither the 
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit 
       in the basic constraints extension MUST NOT be asserted. 

Russ 


--Boundary_(ID_zhpmWWWEGepGsY3IvLfDxg)
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">
<TITLE>RE: keyCertSign and cRLSign Key Usage Bits</TITLE>

<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D292385617-24042001><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
agree, also.</FONT></SPAN></DIV>
<DIV><SPAN class=3D292385617-24042001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><BR>Ambarish</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT=20
size=3D2>---------------------------------------------------------------=
------<BR>Ambarish=20
Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
650.567.5457<BR>ValiCert,=20
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[e-mail]<BR>339 N. Bernardo=20
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
<A target=3D_blank=20
href=3D"http://www.valicert.com/">http://www.valicert.com</A><BR>Mountai=
n View, CA=20
94043<BR></FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, April 24, =
2001 8:22=20
  AM<BR><B>To:</B> Housley, Russ; [e-mail]<BR><B>Subject:</B> =
RE:=20
  keyCertSign and cRLSign Key Usage Bits<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Russ: I agree with the text.</FONT> </P>
  <P><FONT size=3D2>I also know that Steve Kent and Sharon Boeyen feel =
that X.509=20
  states that only CA can issue CRL (the context of my comments being =
PKI only=20
  and not PMI).</FONT></P>
  <P><FONT size=3D2>But, using the theory that you suggest that the =
client be=20
  forgiving, I would consider a client compliant if it did NOT check =
the basic=20
  constraint extension while verifying a signature on a CRL.&nbsp; It =
need to=20
  ensure that the cRLSign bit is set in the keyUsage =
extension.</FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Housley, Russ [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Tuesday, April 24, 2001 10:37 AM</FONT> =
<BR><FONT=20
  size=3D2>To: [e-mail]</FONT> <BR><FONT size=3D2>Subject: =
keyCertSign and=20
  cRLSign Key Usage Bits</FONT> </P><BR>
  <P><FONT size=3D2>The consensus on these bits is not totally clear to =
me.&nbsp;=20
  Yet, several </FONT><BR><FONT size=3D2>points have been consistently, =
and I=20
  think that the following text </FONT><BR><FONT size=3D2>incorporates =
them.&nbsp;=20
  The debate regarding he linkage between these bits and =
</FONT><BR><FONT=20
  size=3D2>the cA bit in the basic constraints extension does not seem =
to be over,=20
  and </FONT><BR><FONT size=3D2>I have not made any changes in that =
area.&nbsp;=20
  Please use this new thread to </FONT><BR><FONT size=3D2>discuss any =
remaining=20
  unresolved points.</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
keyCertSign bit is=20
  asserted when the subject public key is</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for verifying a =
signature on=20
  public key certificates.&nbsp; This</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit MUST only be =
asserted in CA=20
  certificates.&nbsp; If the keyCertSign</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit is asserted, then =
the cA bit=20
  in the basic constraints</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension (see =
4.2.1.10) MUST also=20
  be asserted.&nbsp; If neither the</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the =
keyCertSign=20
  bit are asserted, then the cA bit</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic =
constraints extension=20
  MUST NOT be asserted.</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign =
bit is=20
  asserted when the subject public key is used</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for verifying a =
signature on a=20
  certificate revocation list (e.g.,</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CRL or an ARL).&nbsp; =
This bit=20
  MUST be asserted in CA and Attribute</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authority (AA) =
certificates that=20
  are used to verify signatures on</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRLs.&nbsp; If the =
cRLSign bit is=20
  asserted in a CA certificate, then</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cA bit in the basic =

  constraints extension (see 4.2.1.10) MUST</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; also be asserted.&nbsp; =
If the=20
  cRLSign bit is asserted in a AA</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate, then the =
cA bit in=20
  the basic constraints extension</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST NOT be =
asserted.&nbsp; Such=20
  AA certificates MUST NOT be used to</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify signatures on =
CRLs=20
  containing revocation information for</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public key =
certificates; however,=20
  these AA certificates MAY be</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify =
signatures on CRLs=20
  containing revocation</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information concerning =
attribute=20
  certificates.&nbsp; If neither the</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor the =
keyCertSign=20
  bit are asserted, then the cA bit</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic =
constraints extension=20
  MUST NOT be asserted.</FONT> </P>
  <P><FONT size=3D2>Russ </FONT></P></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_zhpmWWWEGepGsY3IvLfDxg)--


Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA03635 for <[e-mail]>; Tue, 24 Apr 2001 10:43:27 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA291390; Tue, 24 Apr 2001 13:41:10 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id NAA73886; Tue, 24 Apr 2001 13:37:41 -0400
Importance: Normal
Subject: RE: delta-CRLs and NR
To: "Michael Myers" <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 24 Apr 2001 13:42:44 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 04/24/2001 01:42:36 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     When non-repudiation is an actual practice, doesn't the revocation
status need to be checked as of a time no earlier than the actual signature
of the non-repudiable message or document?  And won't a full CRL (or a
delta, for that matter) rarely have been published with such an effective
time at the time an RP initially receives such a message or document?
     It is perfectly true that it is much easier to check a single full CRL
than a CRL with deltas.  However, I don't see why the problem is more
severe for NR except that an NR system is even less tolerant of false
negatives on revocation than authentication is.

          Tom Gindin


"Michael Myers" <[e-mail]> on 04/23/2001 02:30:39 PM

To:   "David P. Kemp" <[e-mail]>, <[e-mail]>
cc:
Subject:  RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt
      comments)


Dave,

But in a broader sense, isn't that precisely the problem directory
replication is all about?

It would be useful to hear of empirical studies establishing the extent to
which PKI information management today dominates directory (X.500, LDAP)
operations.  I advocate that we need to know what today's ground truth
tells
us before we flip this parity bit; else wiggle the text as I proposed and
so
provide everybody the tuning knobs they want to tailor the standard to
local
needs.

More tactically, one could produce a full CRL as a "backup" but let the
delta practice take the burden of timeliness and bandwidth efficiency.  But
in all cases where non-repudiation becomes a true (vice theoretical) issue,
there MUST be a full CRL around somewhere that cleanly establishes a
context.  Else one is faced with reconstituting the full context via
re-accumulation of all the relevant deltas.  Not an easy task either, and
one prone to error.  Given the ease with which a full CRL can be produced
(assuming mechanisms are in place to produce deltas), just crontab two
periods:  a "full" production and a "delta" production, with the period of
the latter shorter than the former.  You don't have to push the full CRL
all
over the place, but at a minimum certainly have it available.

A systems-level tradeoff, as always.  But dumping full CRLs entirely and
trusting deltas exclusively isn't something I'd advocate to any enterprise
concerned about its risk management practices.

Mike

> -----Original Message-----
> From: [e-mail]
> . . .
> The problem is that once the full CRL is signed, it is transmitted across
> the network to directory/database/repository replicas and to clients.
> If you are a PKI provider (as I am), and you have to provision 3.5
> million subscribers, the cost of that provisioning with full CRLs is
> prohibitive, whereas the cost of provisioning with deltas is not.







Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA01097 for <[e-mail]>; Tue, 24 Apr 2001 10:08:19 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JSB1PJL8>; Tue, 24 Apr 2001 13:07:49 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Tom Gindin <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail], "Russell Housley (E-mail)" <[e-mail]>
Subject: RE: Dedicated CRL signing keys
Date: Tue, 24 Apr 2001 12:58:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCDF.DA264B90"

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_01C0CCDF.DA264B90
Content-Type: text/plain;
	charset="iso-8859-1"

Tom:

I agree with most of what you said.  If the CRL signing certificate is
self-issued, then it should appear in caCertificate attribute.

But, if it is issued by another authority, then it must appear in the
crossCertificatePair attribute.  In addition, if the issuing authority is in
the domain of the subject CA, it must also appear in the caCertificate
attribute.

The above is based on my understanding on LDAP schema language we agreed to
back in 1998 or 1999 after much debate. 

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 1:02 PM
To: Santosh Chokhani
Cc: [e-mail]; Russell Housley (E-mail)
Subject: RE: Dedicated CRL signing keys



     On a related point, is it agreed by all that directory publication of
CRL signing certificates with the same DN as the CA signing certificate
should occur in the caCertificate attribute, and thus a directory-enabled
client may find CRL signing certificates by scanning that attribute for
certificates which either contain the CRLSign bit within the KeyUsage
extension or don't contain the KeyUsage extension at all?  RFC 2587 doesn't
say anything about this as far as I can tell.

          Tom Gindin


Santosh Chokhani <[e-mail]> on 04/24/2001 08:54:47 AM

To:   [e-mail], "Russell Housley (E-mail)"
      <[e-mail]>
cc:
Subject:  RE: Dedicated CRL signing keys


Russ:


One of your comments yesterday was that we can make a choice between
simpler client and operational security when I said that some
implementations require separate CRL signing keys for operational security
reasons.


While I agree with you that this is a trade-off an enterprise needs to
make.  But, I think the Internet RFC should not make such a choice.  I am
saying that the RFC should permit both:  simple client (same key for
certificate and CRL signing) as well as different keys for certificate and
CRL signing.


PKIX working group is after all, all about security.  We should not say
that a secure implementation is not compliant with PKIX.



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Dedicated CRL signing keys</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I agree with most of what you said.&nbsp; If the CRL =
signing certificate is self-issued, then it should appear in =
caCertificate attribute.</FONT></P>

<P><FONT SIZE=3D2>But, if it is issued by another authority, then it =
must appear in the crossCertificatePair attribute.&nbsp; In addition, =
if the issuing authority is in the domain of the subject CA, it must =
also appear in the caCertificate attribute.</FONT></P>

<P><FONT SIZE=3D2>The above is based on my understanding on LDAP schema =
language we agreed to back in 1998 or 1999 after much debate. </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tom Gindin [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Tuesday, April 24, 2001 1:02 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; Russell Housley =
(E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Dedicated CRL signing keys</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; On a related point, is it =
agreed by all that directory publication of</FONT>
<BR><FONT SIZE=3D2>CRL signing certificates with the same DN as the CA =
signing certificate</FONT>
<BR><FONT SIZE=3D2>should occur in the caCertificate attribute, and =
thus a directory-enabled</FONT>
<BR><FONT SIZE=3D2>client may find CRL signing certificates by scanning =
that attribute for</FONT>
<BR><FONT SIZE=3D2>certificates which either contain the CRLSign bit =
within the KeyUsage</FONT>
<BR><FONT SIZE=3D2>extension or don't contain the KeyUsage extension at =
all?&nbsp; RFC 2587 doesn't</FONT>
<BR><FONT SIZE=3D2>say anything about this as far as I can tell.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom =
Gindin</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Santosh Chokhani &lt;[e-mail]&gt; on =
04/24/2001 08:54:47 AM</FONT>
</P>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; [e-mail], &quot;Russell =
Housley (E-mail)&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>cc:</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; RE: Dedicated CRL signing keys</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>One of your comments yesterday was that we can make a =
choice between</FONT>
<BR><FONT SIZE=3D2>simpler client and operational security when I said =
that some</FONT>
<BR><FONT SIZE=3D2>implementations require separate CRL signing keys =
for operational security</FONT>
<BR><FONT SIZE=3D2>reasons.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>While I agree with you that this is a trade-off an =
enterprise needs to</FONT>
<BR><FONT SIZE=3D2>make.&nbsp; But, I think the Internet RFC should not =
make such a choice.&nbsp; I am</FONT>
<BR><FONT SIZE=3D2>saying that the RFC should permit both:&nbsp; simple =
client (same key for</FONT>
<BR><FONT SIZE=3D2>certificate and CRL signing) as well as different =
keys for certificate and</FONT>
<BR><FONT SIZE=3D2>CRL signing.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>PKIX working group is after all, all about =
security.&nbsp; We should not say</FONT>
<BR><FONT SIZE=3D2>that a secure implementation is not compliant with =
PKIX.</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C0CCDF.DA264B90--


Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00537 for <[e-mail]>; Tue, 24 Apr 2001 10:03:14 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA144092; Tue, 24 Apr 2001 13:00:45 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id MAA81494; Tue, 24 Apr 2001 12:56:53 -0400
Importance: Normal
Subject: RE: Dedicated CRL signing keys
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail], "Russell Housley (E-mail)" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 24 Apr 2001 13:01:53 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 04/24/2001 01:02:11 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     On a related point, is it agreed by all that directory publication of
CRL signing certificates with the same DN as the CA signing certificate
should occur in the caCertificate attribute, and thus a directory-enabled
client may find CRL signing certificates by scanning that attribute for
certificates which either contain the CRLSign bit within the KeyUsage
extension or don't contain the KeyUsage extension at all?  RFC 2587 doesn't
say anything about this as far as I can tell.

          Tom Gindin


Santosh Chokhani <[e-mail]> on 04/24/2001 08:54:47 AM

To:   [e-mail], "Russell Housley (E-mail)"
      <[e-mail]>
cc:
Subject:  RE: Dedicated CRL signing keys


Russ:


One of your comments yesterday was that we can make a choice between
simpler client and operational security when I said that some
implementations require separate CRL signing keys for operational security
reasons.


While I agree with you that this is a trade-off an enterprise needs to
make.  But, I think the Internet RFC should not make such a choice.  I am
saying that the RFC should permit both:  simple client (same key for
certificate and CRL signing) as well as different keys for certificate and
CRL signing.


PKIX working group is after all, all about security.  We should not say
that a secure implementation is not compliant with PKIX.





Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21270 for <[e-mail]>; Tue, 24 Apr 2001 08:31:51 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JSB1PHXQ>; Tue, 24 Apr 2001 11:31:18 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: RE: keyCertSign and cRLSign Key Usage Bits
Date: Tue, 24 Apr 2001 11:22:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCD2.5E0DB910"

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_01C0CCD2.5E0DB910
Content-Type: text/plain;
	charset="iso-8859-1"

Russ: I agree with the text.

I also know that Steve Kent and Sharon Boeyen feel that X.509 states that
only CA can issue CRL (the context of my comments being PKI only and not
PMI).

But, using the theory that you suggest that the client be forgiving, I would
consider a client compliant if it did NOT check the basic constraint
extension while verifying a signature on a CRL.  It need to ensure that the
cRLSign bit is set in the keyUsage extension.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Tuesday, April 24, 2001 10:37 AM
To: [e-mail]
Subject: keyCertSign and cRLSign Key Usage Bits


The consensus on these bits is not totally clear to me.  Yet, several 
points have been consistently, and I think that the following text 
incorporates them.  The debate regarding he linkage between these bits and 
the cA bit in the basic constraints extension does not seem to be over, and 
I have not made any changes in that area.  Please use this new thread to 
discuss any remaining unresolved points.

       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on public key certificates.  This
       bit MUST only be asserted in CA certificates.  If the keyCertSign
       bit is asserted, then the cA bit in the basic constraints
       extension (see 4.2.1.10) MUST also be asserted.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.

       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on a certificate revocation list (e.g.,
       a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
       Authority (AA) certificates that are used to verify signatures on
       CRLs.  If the cRLSign bit is asserted in a CA certificate, then
       the cA bit in the basic constraints extension (see 4.2.1.10) MUST
       also be asserted.  If the cRLSign bit is asserted in a AA
       certificate, then the cA bit in the basic constraints extension
       MUST NOT be asserted.  Such AA certificates MUST NOT be used to
       verify signatures on CRLs containing revocation information for
       public key certificates; however, these AA certificates MAY be
       used to verify signatures on CRLs containing revocation
       information concerning attribute certificates.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.

Russ 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: keyCertSign and cRLSign Key Usage Bits</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ: I agree with the text.</FONT>
</P>

<P><FONT SIZE=3D2>I also know that Steve Kent and Sharon Boeyen feel =
that X.509 states that only CA can issue CRL (the context of my =
comments being PKI only and not PMI).</FONT></P>

<P><FONT SIZE=3D2>But, using the theory that you suggest that the =
client be forgiving, I would consider a client compliant if it did NOT =
check the basic constraint extension while verifying a signature on a =
CRL.&nbsp; It need to ensure that the cRLSign bit is set in the =
keyUsage extension.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 24, 2001 10:37 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: keyCertSign and cRLSign Key Usage =
Bits</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The consensus on these bits is not totally clear to =
me.&nbsp; Yet, several </FONT>
<BR><FONT SIZE=3D2>points have been consistently, and I think that the =
following text </FONT>
<BR><FONT SIZE=3D2>incorporates them.&nbsp; The debate regarding he =
linkage between these bits and </FONT>
<BR><FONT SIZE=3D2>the cA bit in the basic constraints extension does =
not seem to be over, and </FONT>
<BR><FONT SIZE=3D2>I have not made any changes in that area.&nbsp; =
Please use this new thread to </FONT>
<BR><FONT SIZE=3D2>discuss any remaining unresolved points.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The keyCertSign =
bit is asserted when the subject public key is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for =
verifying a signature on public key certificates.&nbsp; This</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit MUST only =
be asserted in CA certificates.&nbsp; If the keyCertSign</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit is =
asserted, then the cA bit in the basic constraints</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension (see =
4.2.1.10) MUST also be asserted.&nbsp; If neither the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor =
the keyCertSign bit are asserted, then the cA bit</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic =
constraints extension MUST NOT be asserted.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign bit =
is asserted when the subject public key is used</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for verifying a =
signature on a certificate revocation list (e.g.,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CRL or an =
ARL).&nbsp; This bit MUST be asserted in CA and Attribute</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authority (AA) =
certificates that are used to verify signatures on</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CRLs.&nbsp; If =
the cRLSign bit is asserted in a CA certificate, then</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cA bit in =
the basic constraints extension (see 4.2.1.10) MUST</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; also be =
asserted.&nbsp; If the cRLSign bit is asserted in a AA</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate, =
then the cA bit in the basic constraints extension</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST NOT be =
asserted.&nbsp; Such AA certificates MUST NOT be used to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify =
signatures on CRLs containing revocation information for</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public key =
certificates; however, these AA certificates MAY be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify =
signatures on CRLs containing revocation</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information =
concerning attribute certificates.&nbsp; If neither the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cRLSign bit nor =
the keyCertSign bit are asserted, then the cA bit</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic =
constraints extension MUST NOT be asserted.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C0CCD2.5E0DB910--


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA16654 for <[e-mail]>; Tue, 24 Apr 2001 07:41:07 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Apr 2001 14:41:06 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA03449 for <[e-mail]>; Tue, 24 Apr 2001 10:41:07 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <HK1A35GC>; Tue, 24 Apr 2001 10:41:03 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.120]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HK1A35F3; Tue, 24 Apr 2001 10:40:22 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 24 Apr 2001 10:36:49 -0400
Subject: keyCertSign and cRLSign Key Usage Bits
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

The consensus on these bits is not totally clear to me.  Yet, several 
points have been consistently, and I think that the following text 
incorporates them.  The debate regarding he linkage between these bits and 
the cA bit in the basic constraints extension does not seem to be over, and 
I have not made any changes in that area.  Please use this new thread to 
discuss any remaining unresolved points.

       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on public key certificates.  This
       bit MUST only be asserted in CA certificates.  If the keyCertSign
       bit is asserted, then the cA bit in the basic constraints
       extension (see 4.2.1.10) MUST also be asserted.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.

       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on a certificate revocation list (e.g.,
       a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
       Authority (AA) certificates that are used to verify signatures on
       CRLs.  If the cRLSign bit is asserted in a CA certificate, then
       the cA bit in the basic constraints extension (see 4.2.1.10) MUST
       also be asserted.  If the cRLSign bit is asserted in a AA
       certificate, then the cA bit in the basic constraints extension
       MUST NOT be asserted.  Such AA certificates MUST NOT be used to
       verify signatures on CRLs containing revocation information for
       public key certificates; however, these AA certificates MAY be
       used to verify signatures on CRLs containing revocation
       information concerning attribute certificates.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.

Russ 


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA16511 for <[e-mail]>; Tue, 24 Apr 2001 07:40:26 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Apr 2001 14:40:25 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA03350 for <[e-mail]>; Tue, 24 Apr 2001 10:40:26 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <HK1A35FQ>; Tue, 24 Apr 2001 10:40:26 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.120]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HK1A35FK; Tue, 24 Apr 2001 10:40:19 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 24 Apr 2001 09:43:32 -0400
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

I agree with Steve Hanna's observation.  However, I think that we can 
include a bit of notice in section 6.1.  I propose the following 
replacement paragraph:

    A particular certification path may not, however, be appropriate for
    all applications.  Therefore, an application MAY augment this
    algorithm to further limit the set of valid paths.  The path
    validation process also determines the set of certificate policies
    that are valid for this path, based on the certificate policies
    extension, policy mapping extension, policy constraints extension,
    and inhibit any-policy extension.  To achieve this, the path
    validation algorithm constructs a valid policy tree.  If the set of
    certificate policies that are valid for this path is not empty, then
    the result will be a valid policy tree of depth n, otherwise the
    result will be a null valid policy tree.

I suggest that we replace the first paragraph of section 6.2. with:

    The path validation algorithm describes the process of validating a
    single certification path.  While each certification path begins with
    a specific trust anchor, there is no requirement that all
    certification paths validated by a particular system share a single
    trust anchor.  An implementation that supports multiple trust anchors
    MAY augment the algorithm presented in section 6.1 to further limit
    the set of valid certification paths which begin with a particular
    trust anchor.  For example, an implementation MAY modify the
    algorithm to apply name constraints to a specific trust anchor during
    the initialization phase, or the application MAY require the presence
    of a particular alternative name form in the end entity certificate,
    or the application MAY impose requirements on application-specific
    extensions.  Thus, the path validation algorithm presented in section
    6.1 defines the minimum conditions for a path to be considered valid.

Russ


At 05:45 PM 4/19/2001 +0200, Denis Pinkas wrote:
>One topic per message: This one about applying constraints to the path
>validation algorithm.
>
>In section 6.2 we now have:
>
>    The path validation algorithm describes the process of validating a
>    single certification path.  While each path begins with a specific
>    trust anchor, there is no requirement that all paths validated by a
>    particular system share a single trust anchor.  An implementation
>    that supports multiple trust anchors may augment the algorithm
>    prresented in section 6.1 to further limit the set of valid paths
>
>...Please a single r for prresented.
>
>    which begin with a particular trust anchor.  For example, an
>    implementation may specify name constraints that apply to a specific
>    trust anchor.
>
>
>While the sentence is true in the case of multiple trust anchors it is as
>well valid for a single one. So a similar sentence is needed in section 6.1.
>
>In section 6.1 the text says:
>
>    A particular certification path may not, however, be appropriate for
>    all applications.  The path validation process also determines the
>    set of certificate policies that are valid for this path, based on
>    the certificate policies extension, policy mapping extension, policy
>    constraints extension, and inhibit any-policy extension.
>
>The text should rather say:
>
>    An application may augment the algorithm presented in section 6.1
>    to further limit the set of valid paths. For example, an
>    implementation may specify additional constraints like name
>    constraints or specific extensions that apply to the application.
>    Therefor the conditions which are described in this section are
>    minimum conditions. The path validation process described in this
>    section determines the minimum conditions that are to be fulfilled
>    by the certification path for the set of certificate policies
>    that are valid for this path, based on the certificate policies
>    extension, policy mapping extension, policy constraints extension,
>    and inhibit any-policy extension, as well as for the name
>    constraints, if any.
>
>The main difference between 6.1 and 6.2 is that the additional contraints
>(policy or name constraints) apply globally to the path validation algorithm
>when there is one trust anchor (6.1), but may apply on every trust anchor
>where there are multiple trust anchors (6.2).
>
>Denis


Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA13439 for <[e-mail]>; Tue, 24 Apr 2001 06:48:52 -0700 (PDT)
Received: from cooper.entegrity.com (dave.entegrity.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GFR1BYSQ; Tue, 24 Apr 2001 06:49:12 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 24 Apr 2001 15:44:57 +0200
To: "Carlin Covey" <[e-mail]>, "Michael Myers" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, [e-mail]
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:17 PM 4/23/01 -0700, Carlin Covey wrote:
>I vote with Mike and Santosh.

I also agree with this proposal.

Nada


>- Carlin
>
>-----Original Message-----
>From: Michael Myers [mailto:[e-mail]]
>Sent: Monday, April 23, 2001 12:24 PM
>To: Santosh Chokhani; Russ Housley; [e-mail]
>Subject: RE: delta-CRLs (was Re: Last
>Call:draft-ietf-pkix-new-part1-06.txt comments)
>
>
>Santosh,
>
>That is precisely what I'm proposing for the WG's consideration.  But I do
>strongly advocate for a SHALL on full CRL production in any case.  Deltas
>are a systems-level tuning tool.
>
>Mike
>
>
>-----Original Message-----
>From: Santosh Chokhani [mailto:[e-mail]]
>Sent: Monday, April 23, 2001 11:44 AM
>To: Michael Myers; Santosh Chokhani; Russ Housley; [e-mail]
>Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt
>comments)
>
>
>Mike:
>I think you are saying that delta can be produced more frequently and there
>need not be a full CRL issued when a delta is issued.
>If the above is correct paraphrasing of your statement, then I agree.



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA09028 for <[e-mail]>; Tue, 24 Apr 2001 06:04:08 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JRXLFD9S>; Tue, 24 Apr 2001 09:03:38 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: [e-mail], "Russell Housley (E-mail)" <[e-mail]>
Subject: RE: Dedicated CRL signing keys
Date: Tue, 24 Apr 2001 08:54:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCBD.BDC2F650"

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_01C0CCBD.BDC2F650
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:

One of your comments yesterday was that we can make a choice between simpler
client and operational security when I said that some implementations
require separate CRL signing keys for operational security reasons.

While I agree with you that this is a trade-off an enterprise needs to make.
But, I think the Internet RFC should not make such a choice.  I am saying
that the RFC should permit both:  simple client (same key for certificate
and CRL signing) as well as different keys for certificate and CRL signing.

PKIX working group is after all, all about security.  We should not say that
a secure implementation is not compliant with PKIX.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Dedicated CRL signing keys</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>One of your comments yesterday was that we can make a =
choice between simpler client and operational security when I said that =
some implementations require separate CRL signing keys for operational =
security reasons.</FONT></P>

<P><FONT SIZE=3D2>While I agree with you that this is a trade-off an =
enterprise needs to make.&nbsp; But, I think the Internet RFC should =
not make such a choice.&nbsp; I am saying that the RFC should permit =
both:&nbsp; simple client (same key for certificate and CRL signing) as =
well as different keys for certificate and CRL signing.</FONT></P>

<P><FONT SIZE=3D2>PKIX working group is after all, all about =
security.&nbsp; We should not say that a secure implementation is not =
compliant with PKIX.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CCBD.BDC2F650--


Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA06657 for <[e-mail]>; Tue, 24 Apr 2001 05:34:05 -0700 (PDT)
Received: from cooper.entegrity.com (dave.entegrity.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GFR1BYJM; Tue, 24 Apr 2001 05:34:24 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 24 Apr 2001 14:30:10 +0200
To: "David A. Cooper" <[e-mail]>, [e-mail]
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: RE: Dedicated CRL signing keys
In-Reply-To: <[e-mail]>
References: <[e-mail]. com> <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:45 PM 4/23/01 -0400, David A. Cooper wrote:
>Russ,
>
>I have a problem with the idea that we need to include a critical 
>extension in any CRL where some of the certificates covered by that CRL 
>were signed using a different key than the one used to sign the CRL.
>
>The main problem that I see is the CA rekey issue. Suppose that a CA 
>rekeys and then issues a single CRL, signed with its new private key, that 
>covers all of its unexpired certificates. The older certificates issued by 
>this CA will have been signed with the old key, but the newer certificates 
>will have been signed with the same (new) key as the CRL. As things stand 
>at the moment, simple clients will be able to use the CRL when validating 
>the "new" certificates and will fail when using the CRL to validate "old" 
>certificates. If we place a critical extension in the CRL that the simple 
>clients can not process, then they won't be able to use the CRL to 
>validate any certificates. So, adding a critical extension would actually 
>reduce the functionality of simple clients.
>
>I also believe that there is already sufficient information available in 
>the CRLs. A client can simply compare the authority key identifier in the 
>certificate and the corresponding CRL. If they differ, the client will 
>know that the certificate and CRL were signed using different keys and can 
>return an "unsupported feature" error just as if the CRL contained an 
>unrecognized critical extension.

This is my viewpoint exactly. I agree with Dave's reasoning.

Nada



>Right now, simple clients will return an error if a certificate and its 
>corresponding CRL were signed using different keys. Simple clients that 
>want to provide an "unsupported feature" error message instead of 
>"signature invalid" can compare authority key identifiers in order to 
>determine which error message to return. If we force the CRLs to include 
>critical extensions, we will be unnecessarily increasing the number of 
>cases in which simple clients are unable to validate CRLs. So, I think we 
>should leave things as they are.
>
>Dave
>
>At 04:21 PM 4/23/01 -0400, Housley, Russ wrote:
> >I think that everyone agrees that a CA makes a commitment to provide 
> some form of revocation information for the duration of the certificate 
> life.  When CRLs are employed, does the CA use the same key to sign the 
> CRL as was used to sign the certificate?  Clearly, the CA is permitted to 
> use different keys -- the key usage bits are there to allow this 
> separation.  However, several clients cannot handle this situation, and 
> they would like to see an error message that says "unsupported feature" 
> instead of "signature invalid."
> >
> >Perhaps CA rekey will lead us to an answer.  When a CA rekeys, does it 
> are subsequent CRLs signed with the new key or the old one?  A CA could 
> generate one CRL with each key.  They two CRLs could even be distributed 
> by different distribution point to avoid the download of CRLs that cannot 
> be employed.  Alternatively, the CA could publish one CRL signed with the 
> new key.  This leads to the scenario where cert path construction must be 
> evoked to generate validate the CRL when trying to validate a certificate 
> signed by the old key.  This is the behavior that we are trying to make SHOULD.
> >
> >Therefore, the CA MUST generate the CRL using the same key as was used 
> to sign the certificate, or it MUST include an extension in the CRL to 
> indicate that cert path construction might be needed to validate the CRL 
> signature.  I proposed that an Issuing Distribution Point (IDP) CRL 
> extension might be the correct approach.  The IDP extension will not be 
> supported by the simple clients, so they can generate the "unsupported 
> feature" error, and the more complex clients can use the information in 
> the IDP to support path construction.  They will of course, also use 
> Authority Key Identifier extension.



Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.9.3/8.9.3) with SMTP id XAA23200 for <[e-mail]>; Mon, 23 Apr 2001 23:03:54 -0700 (PDT)
Received: from 157.54.7.67 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Apr 2001 20:26:19 -0700 (Pacific Daylight Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 23 Apr 2001 20:25:43 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt comments)
Date: Mon, 23 Apr 2001 20:25:41 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt comments)
Thread-Index: AcDMTIKFVQsVyGgzSCqQScMdPhA3ZgAIYLvA
From: "David Cross" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 24 Apr 2001 03:25:43.0553 (UTC) FILETIME=[3EA03710:01C0CC6E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id XAA23203

Sorry, but to be blunt, how is this any different from an OCSP aware
client from a CRL aware client?

The CA operator knows and anticipates the needs of clients and builds a
publication schedule and revocation architecture accordingly.
 
David B. Cross
 



-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]] 
Sent: Monday, April 23, 2001 4:21 PM
To: Ambarish Malpani; [e-mail]
Subject: RE: delta-CRLs (was Re:
LastCall:draft-ietf-pkix-new-part1-06.txt comments)


At 1:02 PM -0700 4/23/01, Ambarish Malpani wrote:
>     Even if you are requiring clients to pull the CRLs from your 
>directory, you still need to have enough bandwidth to and replication 
>of the directory to support all the clients who need to pull the new 
>CRL every time it is issued.

The alternative is that some users would have a different (that is, 
better) list of what is in the CRL than others, and those others 
would have no way of knowing that their list of revoked certificates 
is incomplete. That seems pretty awful to me. To be a bit crass, if 
you don't have the bandwidth, force your users use delta CRLs, or 
don't be a CA.

If for some reason the wording in son-of-2459 goes towards not 
requiring a new CRL being issued, there also needs to be a fairly 
stern warning both in the delta CRL section and in the security 
considerations section saying that some users will have different 
views of what certificates have been revoked, and that they won't 
know it.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA19549 for <[e-mail]>; Mon, 23 Apr 2001 21:25:56 -0700 (PDT)
Received: from kreicher (dialup-209.246.90.76.NewYork1.Level3.net [209.246.90.76]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id VAA28007 for <[e-mail]>; Mon, 23 Apr 2001 21:25:50 -0700 (PDT)
Message-Id: <[e-mail]>
From: elan <[e-mail]>
To: [e-mail]
Subject: Thought this would be of interest!
X-Mailer: Mail Bomber
Reply-To: [e-mail]
Date: Tue, 24 Apr 2001 00:27:11 -0500
Mime-Version: 1.0
Content-Type: text/html; charset=us-ascii

Hello,
How are you? We are a Pop/R&B sister duo who write and perform our own songs. If you like, you can hear our songs for free at http://www.mp3.com/elan2. We are sure you will enjoy them and we appreciate the support.

<P>
<center><a href="http://www.mp3.com/elan2"><img src="http://www.candlesend.com/elanbanner.gif" width="468" height="60" border="0" ></a></center>
<P>


Received: from chalfont.mail.uk.easynet.net (chalfont.mail.uk.easynet.net [195.40.1.44]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA16131; Mon, 23 Apr 2001 19:29:03 -0700 (PDT)
Received: from localhost (tnt-13-102.easynet.co.uk [212.134.22.102]) by chalfont.mail.uk.easynet.net (Postfix) with ESMTP id F0559F9805; Tue, 24 Apr 2001 03:28:41 +0100 (BST)
X-Sender: [e-mail]
From: "Southern Internet Ltd." <[e-mail]>
To: "Laptop Free of charge" <[e-mail]>
Date: Tue, 24 Apr 2001 03:41:17 +0100
Subject: A Laptop for 25 US Dollars
Reply-To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_001__28140776_13277,96"
Message-Id: <[e-mail]>

This is a Multipart MIME message.

------=_NextPart_001__28140776_13277,96
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

THIS OFFER IS AVAILABLE TO EVERY CUSTOMER SUBJECT TO THE FOLLOWING COMPETITION: 
OMNIBOOK XE3 P3-700 ...
All you need to do to get this Laptop Free of charge, is to purchase the "File 
Crypt Programme" and answer correctly the 60 Questions which will be posted over 
60 Days. Info at: [e-mail]

------=_NextPart_001__28140776_13277,96
Content-Type: image/jpeg; name="omnibook.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="omnibook.jpeg"
Content-Length: 4038

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAKQAA/+4ADkFkb2JlAGTAAAAA
Af/bAIQADAgICAkIDAkJDBELCQsRFA8MDA8UFxISFBISFxYRFBMTFBEWFhobHRsaFiMjJiYj
IzIyMjIyODg4ODg4ODg4OAEMCwsMDgwPDQ0PFA4ODhQUDxAQDxQcExMUExMcIxoWFhYWGiMg
Ih0dHSIgJiYjIyYmMDAuMDA4ODg4ODg4ODg4/8AAEQgAfQB9AwEiAAIRAQMRAf/EAIgAAAIC
AwEAAAAAAAAAAAAAAAABBgcDBAUCAQEBAQEAAAAAAAAAAAAAAAAAAQIDEAACAQMCAwUGBAUE
AwEAAAABAgMAEQQSBSExIkFRYRMGcYGRMiMUoUJSB8FicpIVgqIzQ7HRJBYRAQEAAgICAgID
AAAAAAAAAAABEQIhMUESUWHwgZGhIv/aAAwDAQACEQMRAD8AtS4ovQOQp0CvRenRQK9F6dFA
r0Xp1FvX+VlDbYtuw5TBNnOEeZWKlEBF7spBA7fYCKSZEovReqOwfUOHiFf8buGVBIoKfVkk
Ctc/MQzMtz7rVI8L11v8Kj6seVGBwMihv90dr1r1TKzr0XqBxfudKkirlbcXjI6pIHBIP9D9
nvrsYf7helsp/LbKONIACUyEaO1+XG1qmKZSS9F68QZGPkIJMeVJozyaNgw+K1kqKV6LinS7
aAHIU6Q5CnQFFFFAUUUUBVVfuHvBM+dIjcYlGNBY/me6G3s6zVl7pmDB2/IyzziQlb9rclHv
a1UL6rzWmmghLFidWRIe0s/Sl/Gwv761rxLUviOEeAt3V5SWSJtUTtG3ehKn8KCa8HnWVdCL
1BuMfB2Wde6RePxWxrcT1FiygDJidT3giRR7NXEVwCaVXNTETPbN2hx21bdmCBnsWCuY2PZx
B01KsP15v2MQJmTJQD/sWxP+pbVUVbGPnZePYQzOg7gen+08Kvt8wwvCD9z9mEix7hBPiXAv
Pp8yG7chqXqHvWpR/ktv+x/yX3CfY6PM+4v0ae+9UX6cyM3dss4k4SWNYnfVps1/lReHDqcg
cqtP/CJ/+P8A8f1+Rq1abf8AX5ltVv02+pSydnPSVDkKdIchTrKiiiigKKKKCJ/uFneXgwYC
taTJe5H8q8P/ACao/cskZWfkTr8jNpT+helfwFWF+4+7K+5Zrq3DEjGNGRw62up+BZqrIcBa
tXqRJ3XomvJNF6RrKkaVFFAUCimoLMFAuSbAeJoJ3+32C7ASIPrZcgRD2hU4X/ua/uq6ft4f
t/tdP0dHl6ezTbTb4VAv292pUlRSpKYUY6v5zw/E6vhVg9tb28a/nLM80DkKdIchTrDQoooo
CsWVkJjY0uRIQqQozsTyAUXrLUc/cDMlw/TGTJGupWZEkNyLKzeHe1l99BTXqvNaVkjY9czN
kSj2kqv8aj96ku8bBkZc5yYJlZyAvlP02Ci3S/EH32qP5WDl4j6MmJoj2ahwPsYcDWtpcpMM
JpGi9FZUUUUUBXR9P433G6RXGpIryMD/AC/L/utXOqWeidvedrqLyZMixR+wG3w1H8KuszYl
6W96Jwhj7QJyPqZTar8PkXpXl7z767/bWPGx48bHjx4haOJQi+xRbsrJ20z/AKz9mOMAchTp
DkK1MndcPGuC/mSD8idRv49g99TGVblY5p4MdDJPIsUY5s5Cj4muDl75nTKy4unGuCFZh5je
08hXCyo5mbzsstmELqeSZ/lZeN8fykYaj2K6W8TW/S+U9kgyvV+ICse3wyZskhKxsLRxMw/K
JJLAnwHGo3uHqPN3KObDy5Fhx3GiRFibyzq6fK6gZHbjx0C1YJ8h5JDAhdGdA0uPEUTImZ7e
UrRJriZT2sjK1j4VqMFbzIw8YOKqws0atJHhq/yQx45/+qOXWLEoeF+XIU4nhGtLseSsGrBy
NTqWBaYiRC38rx9QI7mv2ca5ks8uHEIs9ZsdAQrzyoMrCdz2a0RSnDsIJHjXQDSxMrYMhxBK
SsCs/mwwxyC5nmnQMwdnFrTJ2+FZJcyPJWJM2AeXlnTjSMwTzQOlpRa0Li4t06a1mX6T+0Rl
xdnzZRDHE+PkOQI3xwZI3LGy2j59X8vwrSytgzoCxiAyFTgwjvrW36o2AYfCpf8A4bakzBlY
8kuBkMyyYn2y2KMvAWx5OtheuT6gwvUCbhJueSxylLJCuYgEQfy0VQoS/YBx8azZ8z+FlRRl
ZSQwII5g8DRUrhbA3CMR5EkOTkcAUkUxSg/pD94+HdWplemUYM+HIUsbeXJxAPdrX/1WcfC5
R8AkgDiTwAq4v212fTkJKR0YUdr9nmMLfHi1VrtuzZse5RfcQkRxnWW5qdPyi44cTar39Ibd
9ls0RYWlyPqt32I6QfdxqziW/o7sdul206XbWVRre98bE3E4WUGTDZEdJYzYi4IOr9Qv2fj2
Vi+m8PmwsJIRzZOQ/qXmvvFd/P2vB3GIJlxh9IIVhwZb9xqKZnpTP25xLhyzS4qOGb7dtE4S
3ILyJB7vhW9dozYyluFxyrXnzIoF1ySLGvexsT7BzNYTuEHks2URNECA8kQCTI5PASwGytx/
Tb2Gs33uBktaZ45XQXVoFuxU9ovpaK35h+Fbyzhpvk400MkTeZDA5DNdTGj95IHUvKxawPjT
fGwpY0VohAmNdsYMWbGvdeqF4285SCRb5h299enxhIR5EikniQxtyFzY9vCsEcUcDGRCXdvm
C9MZt+ofmpjJnDTy9tnhXzpeuGW7yzhws2RJJw0fd46+WyDgdM3eRyFaUoaGaZJpDDPIhOZp
C4xVLfVijhXVjTt+cEG/G/OuqzzJr8tzEZFKv5Z03U8CD2N7xWjLjQLEEZBBhJ1SQwxiSJ2W
2gy40upCAb6tNial0s65WbRqHUJHjSAxZJ6I8aJDHKqIfqPJiPpPUOoeXLz8TQma4ZvKfzIF
kMTtEur5l6iMQfVubXBkDAG/dx8Rxea74RDQkyLI2s+dG0a8I2iQFZIf08JL2rxIzdRJXRis
YsUsWkggAI4Lkxt5sbC35uXK3bWeVeck4e5CJMqFXSFNEaqymRQp67qgVYxxB6mX+FEO3rjR
OMGfzokazQyXZge5GAvakCksSrGC6xn6k8hRF1EEsyZUP/Ne5sulufOsQn1sgg1ZmTHbTkOA
kKsCbNHEnDUL8CbmrBv+n8bI3PecfCZftw51GRrMt1GpgtjY+F+NXIiLGiovyoAo9g4VWnor
0rvJ3uDc8yMxYWMpkEsltUsjAhViTsQA31W49lWbWLVgpdtOl21FA5CnSHIU6Dm7n6f23cj5
ksejJHy5CcHFu/v99RrJ9P521qCkJyYYw2jLxCY8lA3E61uRIPA3qb0VZtYlit5ckFQyFc5W
uWaFdE6hbdU+Oem3EDUpHGho3AZgCVRmVmtYqymxVgeKkVNdy9P7buN2kQxTn/vhOhz/AFW+
Ye2otuXpfeNuPnbe5yIlvdl/5APFO33V013jN1ct251jLWsQeP8AGvS7hjliMyERyC4dkU2H
9ScCD7K09xlaBgIDHkCQaozHICqg8tZNjet+0Zw85PkyoySoGVrFh2GxuLg8DWj5mGjTrChy
ZJjdo72hUE3IYfnuePVfjyFdDbfTe7b099LOnNrdEQ954samm1egNtxfLkzD9y6dQiHTEG9g
+b31z22jUiE7Z6X3bfZgzAtCCASemFB3X7bDsFT/AGP0Ztm1hJJVXJyk4q5XSi92lOPLvNd9
I0jQJGoRFFlVRYAeAFeqxa1IKKKKiil206XbQAvblRfwp0UCv4UX8KdFAr+FF/CnRQc7dNi2
7dIyMmK0trLMllkH+rt99c3C9E7Xjz+dOXySPlVrKo/t4mpHRV5wnDwiJGgSNQiKLKqgAACv
V/CnRUUr+FF/CnRQK/hRfwp0UCv4Ucb8qdFB/9k=

------=_NextPart_001__28140776_13277,96--



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA09987 for <[e-mail]>; Mon, 23 Apr 2001 17:17:24 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JQV3DWB1; Mon, 23 Apr 2001 17:12:36 -0700
From: "Carlin Covey" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Mon, 23 Apr 2001 17:17:53 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

I vote with Mike and Santosh.

- Carlin

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Monday, April 23, 2001 12:24 PM
To: Santosh Chokhani; Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)


Santosh,

That is precisely what I'm proposing for the WG's consideration.  But I do
strongly advocate for a SHALL on full CRL production in any case.  Deltas
are a systems-level tuning tool.

Mike


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Monday, April 23, 2001 11:44 AM
To: Michael Myers; Santosh Chokhani; Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt
comments)


Mike:
I think you are saying that delta can be produced more frequently and there
need not be a full CRL issued when a delta is issued.
If the above is correct paraphrasing of your statement, then I agree.



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA08184 for <[e-mail]>; Mon, 23 Apr 2001 16:42:53 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JQV3DV8H; Mon, 23 Apr 2001 16:38:01 -0700
From: "Carlin Covey" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last  Call:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Mon, 23 Apr 2001 16:43:18 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C0CC14.80256340"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

This is a multi-part message in MIME format.

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

RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt
comments)Sharon,

Thanks for shining some light on the X.509 delta CRL discussions.  So it
actually IS
the intent of X.509 to permit a dCRL to reference multiple base CRLs?  That
was the
interpretation that I placed on the words from section 9  X.509 Ed. 4 draft
v6:
 "A dCRL may also be an indirect CRL in that it may contain updated
revocation
information related to base CRLs issued by one or more than one
authorities."
I was beginning to think I had misinterpreted the text.

Let me see if I can figure out how these multiple base CRLs are referenced
in a dCRL.

>From X.509 Section 9 : "A dCRL includes either a deltaCRLIndicator or a
crlScope
extension to indicate the base revocation information that is being updated
with this dCRL."

But the deltaCRLIndicator extension references the base CRL issuer only by
implication,
i.e. it is assumed that the base CRL issuer is the same as the dCRL issuer.

So if a dCRL references multiple base CRLs, it must do so via the
baseRevocationInfo
component of the crlScope extension.

>From X.509 Section 9 :  "Because of the potential for conflicting
information a CRL shall
not contain both the deltaCRLIndicator extension and a crlScope extension
with the
baseRevocationInfo component."

So a dCRL that references multiple base CRLs cannot include the
deltaCRLIndicator extension.

      -  Sharon, is that right?

I don't see anywhere in draft-ietf-pkix-new-part1-05 where it says that a
delta CRL must be
identified by a deltaCRLIndicator extension.  It does say that "The delta
CRL indicator is
a critical CRL extension that identifies a CRL as being a delta CRL."  This
appears to be
a sufficient condition, but not a necessary condition, for the CRL to be
interpreted as a
delta CRL.  So a PKIX-profile-compliant CRL-issuer could use the crlScope
extension rather
than the deltaCRLIndicator extension to identify delta CRLs?

      -  Russ, is that right?

>From draft-ietf-pkix-new-part1-05 section 5.2.4: "Both the delta CRL and the
complete CRL
MUST include the CRL number extension (see sec. 5.2.3). The CRL number
extension in the
delta CRL and the complete CRL MUST contain the same value. "

But in order for the CRL number extension in the delta CRL and in the
complete CRL to
contain the same value, there would have to be only one base CRL per delta
CRL or
there would have to be multiple CRL number extensions in the delta CRL
(without a good
way of matching them to the base CRLs).

I guess draft-ietf-pkix-new-part1-05 isn't intended to support multiple base
CRLs per delta CRL.

      -  Russ, is that right?

Just musing  ......
Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation



  -----Original Message-----
  From: Sharon Boeyen [mailto:[e-mail]]
  Sent: Monday, April 23, 2001 1:10 PM
  To: 'Carlin Covey'; Russ Housley; [e-mail]
  Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)


  Carlin, you are correct. That 'indirect delta' is a new facility added
into the 4th edition X.509. One example that was used in those discussions
was where there might be several CAs operating within a given domain
(perhaps a large multinational organization) and each issues its own CRLs on
a regular basis. Once retrieved, these CRLs may be cached at the validation
step and used until their expiry. However, that multinational may want to
issue a single delta CRL every minute and that CRL would contain revocation
notices for all the CAs within the organization but perhaps only for the
keyCompromise reason. I think you raise an interesting point because in this
type of environment the CA that issues the delta could not issue any single
corresponding base. However, I suspect indirectDeltas are beyond the scope
of what 2459 plans to cover?

  Sharon

  >


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: delta-CRLs (was Re: Last =
Call:draft-ietf-pkix-new-part1-06.txt comments)</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001>Sharon,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001>Thanks=20
for shining some light on the X.509 delta CRL discussions.&nbsp; So it =
actually=20
IS</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001>the=20
intent of X.509 to permit a dCRL to reference multiple base CRLs?&nbsp; =
That was=20
the </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001>interpretation that I placed on the words =
from section=20
9&nbsp; <FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001>X.509 Ed. 4 draft =
v6:</SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>&nbsp;"A dCRL may=20
also be an indirect CRL </SPAN></FONT><FONT color=3D#0000ff face=3DArial =

size=3D2><SPAN class=3D730544716-23042001>in that it may contain updated =
revocation=20
</SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>information=20
related to base CRLs </SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D730544716-23042001>issued by one or more than one=20
authorities."</SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN class=3D730544716-23042001>I =
was beginning=20
to think I had misinterpreted the text.&nbsp; =
</SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>Let me see if I=20
can figure out how these multiple base CRLs are referenced in a=20
dCRL.</SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>From X.509=20
Section 9 : "A dCRL includes either a deltaCRLIndicator or a crlScope=20
</SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>extension=20
</SPAN></FONT></SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D396575621-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D730544716-23042001>to indicate the base revocation information =
that is=20
being updated with this dCRL."</SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>But the=20
deltaCRLIndicator <FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D730544716-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D396575621-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D730544716-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D396575621-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D730544716-23042001>extension references the base CRL=20
issuer</SPAN></FONT></SPAN></FONT></SPAN></FONT></SPAN></FONT></SPAN></FO=
NT></SPAN></FONT></SPAN></FONT></SPAN></FONT><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN class=3D730544716-23042001> =
only by=20
implication,=20
</SPAN></FONT></SPAN></FONT></SPAN></FONT></SPAN></FONT></SPAN></FONT></S=
PAN></FONT></SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>i.e. it is=20
assumed that the base CRL issuer is the same as the dCRL=20
issuer.</SPAN></FONT></SPAN></FONT></SPAN></FONT></SPAN></FONT></SPAN></F=
ONT></SPAN></FONT></SPAN></FONT></SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT></SPAN></FONT></SPAN></FONT></SP=
AN></FONT></SPAN></FONT></SPAN></FONT>So=20
if a dCRL <FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D730544716-23042001>references</SPAN></FONT></SPAN></FONT><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN class=3D730544716-23042001> =
multiple base=20
CRLs, it must do so via the baseRevocationInfo=20
</SPAN></FONT></SPAN></FONT></SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>component of=20
the</SPAN></FONT></SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D396575621-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D730544716-23042001> crlScope <FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D396575621-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D730544716-23042001>extension.&nbsp;=20
</SPAN></FONT></SPAN></FONT></SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT></SPAN></FONT></SPAN></FONT></SP=
AN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT></SPAN></FONT><FONT =
color=3D#0000ff=20
face=3DArial size=3D2><SPAN class=3D396575621-23042001><FONT =
color=3D#0000ff face=3DArial=20
size=3D2><SPAN class=3D730544716-23042001>From X.509 Section 9=20
:&nbsp;</SPAN></FONT></SPAN></FONT>&nbsp;</SPAN></FONT></SPAN></FONT></SP=
AN></FONT></SPAN></FONT><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>"Because of the=20
potential for conflicting information a CRL shall=20
</SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>not contain both=20
</SPAN></FONT></SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D396575621-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D730544716-23042001>the deltaCRLIndicator extension and a =
crlScope=20
extension with the </SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001>baseRevocationInfo component." =
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT>&nbsp;</SPAN></FONT><FONT =
color=3D#0000ff=20
face=3DArial size=3D2><SPAN class=3D396575621-23042001><FONT =
color=3D#0000ff face=3DArial=20
size=3D2><SPAN =
class=3D730544716-23042001></SPAN></FONT>&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001>So a=20
dCRL that references multiple base CRLs cannot include the =
deltaCRLIndicator=20
extension.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp;=20
</SPAN></FONT>Sharon, is that right?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001>I=20
don't see anywhere in draft-ietf-pkix-new-part1-05 where it says that a =
delta=20
CRL must be </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001>identified by a deltaCRLIndicator =
extension.&nbsp; It=20
does say that "The delta CRL indicator is </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001>a=20
critical CRL extension that identifies a CRL as being a delta=20
CRL."&nbsp;&nbsp;This appears to be</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001>a=20
sufficient condition, but not a necessary condition, for the CRL to be=20
interpreted as a&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001>delta=20
CRL.&nbsp; So a PKIX-profile-compliant CRL-issuer could use the crlScope =

extension rather </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001>than=20
the deltaCRLIndicator extension to identify delta =
CRLs?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp; Russ, =
is that=20
right?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001>&nbsp;</SPAN></FONT></DIV>
<DIV><SPAN class=3D396575621-23042001><FONT size=3D2><FONT =
face=3DArial><FONT=20
color=3D#0000ff><SPAN style=3D"mso-fareast-font-family: 'MS =
Mincho'"><SPAN=20
class=3D396575621-23042001>From draft-ietf-pkix-new-part1-05 section =
5.2.4:=20
"</SPAN>Both the delta CRL and the complete CRL <BR>MUST =
</SPAN></FONT><FONT=20
color=3D#0000ff><SPAN style=3D"mso-fareast-font-family: 'MS =
Mincho'">include the CRL=20
number </SPAN><SPAN style=3D"mso-fareast-font-family: 'MS =
Mincho'"></FONT><FONT=20
color=3D#0000ff>extension </FONT></SPAN></FONT></FONT><FONT =
face=3DArial><FONT=20
size=3D2><FONT color=3D#0000ff><SPAN=20
style=3D"mso-fareast-font-family: 'MS Mincho'">(see sec. 5.2.3). The CRL =
number=20
extension in the <BR>delta CRL and the complete CRL MUST contain the =
same value.=20
"</SPAN></SPAN></FONT></FONT></FONT><FONT color=3D#0000ff><SPAN=20
class=3D396575621-23042001></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff><SPAN class=3D396575621-23042001><FONT =
face=3DArial=20
size=3D2></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff><SPAN class=3D396575621-23042001><FONT =
face=3DArial=20
size=3D2>But in order for the CRL number extension in the delta CRL and =
in the=20
complete CRL to<BR>contain the same value, there would have to be only =
one base=20
CRL per delta CRL or </FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff><SPAN class=3D396575621-23042001><FONT =
face=3DArial=20
size=3D2>there would have to be multiple CRL number extensions in=20
the</FONT></SPAN></FONT><FONT color=3D#0000ff><SPAN =
class=3D396575621-23042001><FONT=20
face=3DArial size=3D2> delta CRL (without a =
good</FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff><SPAN class=3D396575621-23042001><FONT =
face=3DArial=20
size=3D2>way of matching them to the base CRLs). =
</FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff><SPAN=20
class=3D396575621-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D396575621-23042001>I=20
guess draft-ietf-pkix-new-part1-05 isn't intended to support multiple =
base CRLs=20
per delta CRL.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff><SPAN class=3D396575621-23042001><FONT =
face=3DArial=20
size=3D2><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D396575621-23042001></SPAN></FONT></SPAN></FONT></FONT></SPAN></FO=
NT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff><SPAN class=3D396575621-23042001><FONT =
face=3DArial=20
size=3D2><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D396575621-23042001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp;=20
</SPAN></FONT>Russ, is that =
right?</SPAN></FONT></FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff><SPAN class=3D396575621-23042001><FONT =
face=3DArial=20
size=3D2><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D396575621-23042001></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</DIV=
>
<DIV><FONT color=3D#0000ff><SPAN class=3D396575621-23042001><FONT =
face=3DArial=20
size=3D2>Just musing&nbsp; ......&nbsp;&nbsp; </FONT></DIV>
<DIV>
<DIV><FONT color=3D#0000ff><SPAN class=3D730544716-23042001>
<P><FONT face=3DArial=20
size=3D2>Regards,<BR><BR>Carlin<BR><BR>____________________________<BR><B=
R>-&nbsp;=20
Carlin Covey<BR>&nbsp;&nbsp; Cylink Corporation =
</FONT></P></SPAN></FONT></DIV>
<DIV><SPAN class=3D730544716-23042001>
<P><FONT color=3D#0000ff><SPAN =
class=3D730544716-23042001></SPAN></FONT><FONT=20
face=3DArial size=3D2>&nbsp;</FONT></P></SPAN></DIV></SPAN></FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, April 23, =
2001 1:10=20
  PM<BR><B>To:</B> 'Carlin Covey'; Russ Housley;=20
  [e-mail]<BR><B>Subject:</B> RE: delta-CRLs (was Re: Last=20
  Call:draft-ietf-pkix-new-part1-06.txt comments)<BR><BR></DIV></FONT>
  <P><FONT size=3D2>Carlin, you are correct. That 'indirect delta' is a =
new=20
  facility added into the 4th edition X.509. One example that was used =
in those=20
  discussions was where there might be several CAs operating within a =
given=20
  domain (perhaps a large multinational organization) and each issues =
its own=20
  CRLs on a regular basis. Once retrieved, these CRLs may be cached at =
the=20
  validation step and used until their expiry. However, that =
multinational may=20
  want to issue a single delta CRL every minute and that CRL would =
contain=20
  revocation notices for all the CAs within the organization but perhaps =
only=20
  for the keyCompromise reason. I think you raise an interesting point =
because=20
  in this type of environment the CA that issues the delta could not =
issue any=20
  single corresponding base. However, I suspect indirectDeltas are =
beyond the=20
  scope of what 2459 plans to cover?</FONT></P>
  <P><FONT size=3D2>Sharon </FONT></P>
  <P><FONT size=3D2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000A_01C0CC14.80256340--



Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA06656; Mon, 23 Apr 2001 16:20:47 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100809b70a6882b2ea@[165.227.249.20]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Mon, 23 Apr 2001 16:20:54 -0700
To: Ambarish Malpani <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt comments)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 1:02 PM -0700 4/23/01, Ambarish Malpani wrote:
>     Even if you are requiring clients to pull the CRLs from your
>directory, you still need to have enough bandwidth to and replication
>of the directory to support all the clients who need to pull the
>new CRL every time it is issued.

The alternative is that some users would have a different (that is, 
better) list of what is in the CRL than others, and those others 
would have no way of knowing that their list of revoked certificates 
is incomplete. That seems pretty awful to me. To be a bit crass, if 
you don't have the bandwidth, force your users use delta CRLs, or 
don't be a CA.

If for some reason the wording in son-of-2459 goes towards not 
requiring a new CRL being issued, there also needs to be a fairly 
stern warning both in the delta CRL section and in the security 
considerations section saying that some users will have different 
views of what certificates have been revoked, and that they won't 
know it.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA00384 for <[e-mail]>; Mon, 23 Apr 2001 14:50:00 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JPVNWZF8>; Mon, 23 Apr 2001 17:49:33 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "David A. Cooper" <[e-mail]>, [e-mail]
Subject: RE: Dedicated CRL signing keys
Date: Mon, 23 Apr 2001 17:40:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CC3E.0B4BCE90"

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_01C0CC3E.0B4BCE90
Content-Type: text/plain;
	charset="iso-8859-1"

I think we should not try to fix the problem of rekey by further
complicating the CRL.

We should either let the CA issue multiple CRLs (no need for IDP) or let the
clients develop two paths: one for the certificate and one for the CRL.

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Monday, April 23, 2001 5:45 PM
To: [e-mail]
Subject: RE: Dedicated CRL signing keys


Russ,

I have a problem with the idea that we need to include a critical extension
in any CRL where some of the certificates covered by that CRL were signed
using a different key than the one used to sign the CRL.

The main problem that I see is the CA rekey issue. Suppose that a CA rekeys
and then issues a single CRL, signed with its new private key, that covers
all of its unexpired certificates. The older certificates issued by this CA
will have been signed with the old key, but the newer certificates will have
been signed with the same (new) key as the CRL. As things stand at the
moment, simple clients will be able to use the CRL when validating the "new"
certificates and will fail when using the CRL to validate "old"
certificates. If we place a critical extension in the CRL that the simple
clients can not process, then they won't be able to use the CRL to validate
any certificates. So, adding a critical extension would actually reduce the
functionality of simple clients.

I also believe that there is already sufficient information available in the
CRLs. A client can simply compare the authority key identifier in the
certificate and the corresponding CRL. If they differ, the client will know
that the certificate and CRL were signed using different keys and can return
an "unsupported feature" error just as if the CRL contained an unrecognized
critical extension.

Right now, simple clients will return an error if a certificate and its
corresponding CRL were signed using different keys. Simple clients that want
to provide an "unsupported feature" error message instead of "signature
invalid" can compare authority key identifiers in order to determine which
error message to return. If we force the CRLs to include critical
extensions, we will be unnecessarily increasing the number of cases in which
simple clients are unable to validate CRLs. So, I think we should leave
things as they are.

Dave 

At 04:21 PM 4/23/01 -0400, Housley, Russ wrote:
>I think that everyone agrees that a CA makes a commitment to provide some
form of revocation information for the duration of the certificate life.
When CRLs are employed, does the CA use the same key to sign the CRL as was
used to sign the certificate?  Clearly, the CA is permitted to use different
keys -- the key usage bits are there to allow this separation.  However,
several clients cannot handle this situation, and they would like to see an
error message that says "unsupported feature" instead of "signature
invalid."
>
>Perhaps CA rekey will lead us to an answer.  When a CA rekeys, does it are
subsequent CRLs signed with the new key or the old one?  A CA could generate
one CRL with each key.  They two CRLs could even be distributed by different
distribution point to avoid the download of CRLs that cannot be employed.
Alternatively, the CA could publish one CRL signed with the new key.  This
leads to the scenario where cert path construction must be evoked to
generate validate the CRL when trying to validate a certificate signed by
the old key.  This is the behavior that we are trying to make SHOULD.
>
>Therefore, the CA MUST generate the CRL using the same key as was used to
sign the certificate, or it MUST include an extension in the CRL to indicate
that cert path construction might be needed to validate the CRL signature.
I proposed that an Issuing Distribution Point (IDP) CRL extension might be
the correct approach.  The IDP extension will not be supported by the simple
clients, so they can generate the "unsupported feature" error, and the more
complex clients can use the information in the IDP to support path
construction.  They will of course, also use Authority Key Identifier
extension.


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Dedicated CRL signing keys</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I think we should not try to fix the problem of rekey =
by further complicating the CRL.</FONT>
</P>

<P><FONT SIZE=3D2>We should either let the CA issue multiple CRLs (no =
need for IDP) or let the clients develop two paths: one for the =
certificate and one for the CRL.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David A. Cooper [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 23, 2001 5:45 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Dedicated CRL signing keys</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>I have a problem with the idea that we need to =
include a critical extension in any CRL where some of the certificates =
covered by that CRL were signed using a different key than the one used =
to sign the CRL.</FONT></P>

<P><FONT SIZE=3D2>The main problem that I see is the CA rekey issue. =
Suppose that a CA rekeys and then issues a single CRL, signed with its =
new private key, that covers all of its unexpired certificates. The =
older certificates issued by this CA will have been signed with the old =
key, but the newer certificates will have been signed with the same =
(new) key as the CRL. As things stand at the moment, simple clients =
will be able to use the CRL when validating the &quot;new&quot; =
certificates and will fail when using the CRL to validate =
&quot;old&quot; certificates. If we place a critical extension in the =
CRL that the simple clients can not process, then they won't be able to =
use the CRL to validate any certificates. So, adding a critical =
extension would actually reduce the functionality of simple =
clients.</FONT></P>

<P><FONT SIZE=3D2>I also believe that there is already sufficient =
information available in the CRLs. A client can simply compare the =
authority key identifier in the certificate and the corresponding CRL. =
If they differ, the client will know that the certificate and CRL were =
signed using different keys and can return an &quot;unsupported =
feature&quot; error just as if the CRL contained an unrecognized =
critical extension.</FONT></P>

<P><FONT SIZE=3D2>Right now, simple clients will return an error if a =
certificate and its corresponding CRL were signed using different keys. =
Simple clients that want to provide an &quot;unsupported feature&quot; =
error message instead of &quot;signature invalid&quot; can compare =
authority key identifiers in order to determine which error message to =
return. If we force the CRLs to include critical extensions, we will be =
unnecessarily increasing the number of cases in which simple clients =
are unable to validate CRLs. So, I think we should leave things as they =
are.</FONT></P>

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

<P><FONT SIZE=3D2>At 04:21 PM 4/23/01 -0400, Housley, Russ =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;I think that everyone agrees that a CA makes a =
commitment to provide some form of revocation information for the =
duration of the certificate life.&nbsp; When CRLs are employed, does =
the CA use the same key to sign the CRL as was used to sign the =
certificate?&nbsp; Clearly, the CA is permitted to use different keys =
-- the key usage bits are there to allow this separation.&nbsp; =
However, several clients cannot handle this situation, and they would =
like to see an error message that says &quot;unsupported feature&quot; =
instead of &quot;signature invalid.&quot;</FONT></P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Perhaps CA rekey will lead us to an answer.&nbsp;=
 When a CA rekeys, does it are subsequent CRLs signed with the new key =
or the old one?&nbsp; A CA could generate one CRL with each key.&nbsp; =
They two CRLs could even be distributed by different distribution point =
to avoid the download of CRLs that cannot be employed.&nbsp; =
Alternatively, the CA could publish one CRL signed with the new =
key.&nbsp; This leads to the scenario where cert path construction must =
be evoked to generate validate the CRL when trying to validate a =
certificate signed by the old key.&nbsp; This is the behavior that we =
are trying to make SHOULD.</FONT></P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Therefore, the CA MUST generate the CRL using =
the same key as was used to sign the certificate, or it MUST include an =
extension in the CRL to indicate that cert path construction might be =
needed to validate the CRL signature.&nbsp; I proposed that an Issuing =
Distribution Point (IDP) CRL extension might be the correct =
approach.&nbsp; The IDP extension will not be supported by the simple =
clients, so they can generate the &quot;unsupported feature&quot; =
error, and the more complex clients can use the information in the IDP =
to support path construction.&nbsp; They will of course, also use =
Authority Key Identifier extension.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CC3E.0B4BCE90--


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29924 for <[e-mail]>; Mon, 23 Apr 2001 14:45:38 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA27920 for <[e-mail]>; Mon, 23 Apr 2001 17:45:37 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 23 Apr 2001 17:45:05 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: Dedicated CRL signing keys
In-Reply-To: <[e-mail]. com>
References: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Russ,

I have a problem with the idea that we need to include a critical extension in any CRL where some of the certificates covered by that CRL were signed using a different key than the one used to sign the CRL.

The main problem that I see is the CA rekey issue. Suppose that a CA rekeys and then issues a single CRL, signed with its new private key, that covers all of its unexpired certificates. The older certificates issued by this CA will have been signed with the old key, but the newer certificates will have been signed with the same (new) key as the CRL. As things stand at the moment, simple clients will be able to use the CRL when validating the "new" certificates and will fail when using the CRL to validate "old" certificates. If we place a critical extension in the CRL that the simple clients can not process, then they won't be able to use the CRL to validate any certificates. So, adding a critical extension would actually reduce the functionality of simple clients.

I also believe that there is already sufficient information available in the CRLs. A client can simply compare the authority key identifier in the certificate and the corresponding CRL. If they differ, the client will know that the certificate and CRL were signed using different keys and can return an "unsupported feature" error just as if the CRL contained an unrecognized critical extension.

Right now, simple clients will return an error if a certificate and its corresponding CRL were signed using different keys. Simple clients that want to provide an "unsupported feature" error message instead of "signature invalid" can compare authority key identifiers in order to determine which error message to return. If we force the CRLs to include critical extensions, we will be unnecessarily increasing the number of cases in which simple clients are unable to validate CRLs. So, I think we should leave things as they are.

Dave 

At 04:21 PM 4/23/01 -0400, Housley, Russ wrote:
>I think that everyone agrees that a CA makes a commitment to provide some form of revocation information for the duration of the certificate life.  When CRLs are employed, does the CA use the same key to sign the CRL as was used to sign the certificate?  Clearly, the CA is permitted to use different keys -- the key usage bits are there to allow this separation.  However, several clients cannot handle this situation, and they would like to see an error message that says "unsupported feature" instead of "signature invalid."
>
>Perhaps CA rekey will lead us to an answer.  When a CA rekeys, does it are subsequent CRLs signed with the new key or the old one?  A CA could generate one CRL with each key.  They two CRLs could even be distributed by different distribution point to avoid the download of CRLs that cannot be employed.  Alternatively, the CA could publish one CRL signed with the new key.  This leads to the scenario where cert path construction must be evoked to generate validate the CRL when trying to validate a certificate signed by the old key.  This is the behavior that we are trying to make SHOULD.
>
>Therefore, the CA MUST generate the CRL using the same key as was used to sign the certificate, or it MUST include an extension in the CRL to indicate that cert path construction might be needed to validate the CRL signature.  I proposed that an Issuing Distribution Point (IDP) CRL extension might be the correct approach.  The IDP extension will not be supported by the simple clients, so they can generate the "unsupported feature" error, and the more complex clients can use the information in the IDP to support path construction.  They will of course, also use Authority Key Identifier extension.




Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29308 for <[e-mail]>; Mon, 23 Apr 2001 14:34:19 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JPVNWZAA>; Mon, 23 Apr 2001 17:33:52 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys
Date: Mon, 23 Apr 2001 17:25:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CC3B.DADAC100"

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_01C0CC3B.DADAC100
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:

See comments in line

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, April 23, 2001 4:21 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys


Santosh:

Thanks for posting your summary of the thread.  I hope it will allow us to 
focus on the issues, and reach consensus quickly.

>First, I think that the restriction that a CA who desires to issue 
>Indirect CRL needs to set itself up as a separate name is unduly 
>restrictive.  There is no need for a CA to do that.  A CA can issue a full 
>CRL as well as an Indirect CRL and populate these in the same or different 
>entries (i.e., CRL DP) in the directory.  Please review Annex B of X.509 
>for how to process CRL.  So, may be Russ can explain why this requirement 
>comes about.

I agree that the use of a separate name is overly restrictive.  That 
portion of my suggestion was, in hind sight, a bad idea.  As Tim Polk 
pointed out, CAs cannot change their names when they rekey.

I think that everyone agrees that a CA makes a commitment to provide some 
form of revocation information for the duration of the certificate 
life.  When CRLs are employed, does the CA use the same key to sign the CRL 
as was used to sign the certificate?  Clearly, the CA is permitted to use 
different keys -- the key usage bits are there to allow this 
separation.  However, several clients cannot handle this situation, and 
they would like to see an error message that says "unsupported feature" 
instead of "signature invalid."

Perhaps CA rekey will lead us to an answer.  When a CA rekeys, does it are 
subsequent CRLs signed with the new key or the old one?  A CA could 
generate one CRL with each key.  They two CRLs could even be distributed by 
different distribution point to avoid the download of CRLs that cannot be 
employed.  Alternatively, the CA could publish one CRL signed with the new 
key.  This leads to the scenario where cert path construction must be 
evoked to generate validate the CRL when trying to validate a certificate 
signed by the old key.  This is the behavior that we are trying to make
SHOULD.

Therefore, the CA MUST generate the CRL using the same key as was used to 
sign the certificate, or it MUST include an extension in the CRL to 
indicate that cert path construction might be needed to validate the CRL 
signature.  I proposed that an Issuing Distribution Point (IDP) CRL 
extension might be the correct approach.  The IDP extension will not be 
supported by the simple clients, so they can generate the "unsupported 
feature" error, and the more complex clients can use the information in the 
IDP to support path construction.  They will of course, also use Authority 
Key Identifier extension.

{Santosh Says: Item 1 will require a change to the IDP extension syntax.
Would n't that make PKIX non-compliant with X.509?)

>Second, when we say that a CA may not use different keys for signing 
>certificates and CRLs, we are again not thinking of 
>operations.  Operationally, a CA is going to rekey.  When it does, it will 
>have issued the certificates using the old key and will sign CRL with new 
>key.  There are your different keys.

The simple CA could reasonably expect the CA to generate CRLs using the 
same key that was used to sign certificates until all of the certificates 
signed with that key have expired.

(Santosh Says: That is what I have been advocating.  But, mandating that a
CA retain old private keys and issue multiple CRLs may be excessive.)

>Also, I think a standard should be flexible and promote security.  From 
>operational security viewpoint, a CA may not want to keep the certificate 
>signing key active all the time, but may need to keep the CRL signing key 
>active to help meet CRL issuance obligations.  This will mean a separate 
>CRL signing key since compromise of that key still does not compromise 
>anything.  The attacker needs to compromise some subscriber keys to create 
>a true compromise, denial-of-service notwithstanding.  Thus, we should 
>accommodate separate keys for certificates and CRLs.

We need to balance the complexity of the software that we expect the 
clients to handle and CA operational security.  Errors in either place will 
lead to vulnerabilities.

>In short, requiring the CA to use a different name to issue indirect CRL 
>is not well-grounded and should be deleted.

Agree.

>Requiring a CA to use different key for indirect CRL is not well-grounded 
>and should be deleted.

I do not recall a discussion on this point.  Usually, Indirect CRLs are 
employed to delegate CRL generation responsibility.  I would expect the two 
authorities to have different keys.

(Santosh Says: But there is nothing in X.509 that a designated CA can not
issue its own regular CRL and issue an indirect CRL for its peers.  The
designated CA may use the same key.  The requirement you are levying has
marginal benefit for the directories and clients who do not do multi-valued
attributes and that only if the CA does NOT use a CRL DP for the indirect
CRL.  There is no particular need or requirement for having a separate name
or a separate key)

>Requiring the same key for certificate and CRL signing may not be possible 
>due to rekey or operational security requirements and should be deleted.

We need to be pragmatic with respect to simple clients.  I hope that I made 
my thoughts clear above.

(Santosh Says: I think the best engineering solution is for the CA to keep
the old keys and sign multiple CRLs.  That said, I do not want to mandate it
and I  for sure want the PKIX community to approve the RFC knowing this
implication.)

>Finally, as to Steve Farrell's question regarding client simplicity, I 
>wish I could answer that.  The client will need intelligence to handle 
>rekey and secure CA who use different keys for certificate and CRL signing.

Again, I hope that I made my thoughts clear above.

Russ

------_=_NextPart_001_01C0CC3B.DADAC100
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Dedicated CRL signing keys</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Russ:</FONT>
</P>

<P><FONT SIZE=2>See comments in line</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Housley, Russ [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Monday, April 23, 2001 4:21 PM</FONT>
<BR><FONT SIZE=2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: RE: Dedicated CRL signing keys</FONT>
</P>
<BR>

<P><FONT SIZE=2>Santosh:</FONT>
</P>

<P><FONT SIZE=2>Thanks for posting your summary of the thread.&nbsp; I hope it will allow us to </FONT>
<BR><FONT SIZE=2>focus on the issues, and reach consensus quickly.</FONT>
</P>

<P><FONT SIZE=2>&gt;First, I think that the restriction that a CA who desires to issue </FONT>
<BR><FONT SIZE=2>&gt;Indirect CRL needs to set itself up as a separate name is unduly </FONT>
<BR><FONT SIZE=2>&gt;restrictive.&nbsp; There is no need for a CA to do that.&nbsp; A CA can issue a full </FONT>
<BR><FONT SIZE=2>&gt;CRL as well as an Indirect CRL and populate these in the same or different </FONT>
<BR><FONT SIZE=2>&gt;entries (i.e., CRL DP) in the directory.&nbsp; Please review Annex B of X.509 </FONT>
<BR><FONT SIZE=2>&gt;for how to process CRL.&nbsp; So, may be Russ can explain why this requirement </FONT>
<BR><FONT SIZE=2>&gt;comes about.</FONT>
</P>

<P><FONT SIZE=2>I agree that the use of a separate name is overly restrictive.&nbsp; That </FONT>
<BR><FONT SIZE=2>portion of my suggestion was, in hind sight, a bad idea.&nbsp; As Tim Polk </FONT>
<BR><FONT SIZE=2>pointed out, CAs cannot change their names when they rekey.</FONT>
</P>

<P><FONT SIZE=2>I think that everyone agrees that a CA makes a commitment to provide some </FONT>
<BR><FONT SIZE=2>form of revocation information for the duration of the certificate </FONT>
<BR><FONT SIZE=2>life.&nbsp; When CRLs are employed, does the CA use the same key to sign the CRL </FONT>
<BR><FONT SIZE=2>as was used to sign the certificate?&nbsp; Clearly, the CA is permitted to use </FONT>
<BR><FONT SIZE=2>different keys -- the key usage bits are there to allow this </FONT>
<BR><FONT SIZE=2>separation.&nbsp; However, several clients cannot handle this situation, and </FONT>
<BR><FONT SIZE=2>they would like to see an error message that says &quot;unsupported feature&quot; </FONT>
<BR><FONT SIZE=2>instead of &quot;signature invalid.&quot;</FONT>
</P>

<P><FONT SIZE=2>Perhaps CA rekey will lead us to an answer.&nbsp; When a CA rekeys, does it are </FONT>
<BR><FONT SIZE=2>subsequent CRLs signed with the new key or the old one?&nbsp; A CA could </FONT>
<BR><FONT SIZE=2>generate one CRL with each key.&nbsp; They two CRLs could even be distributed by </FONT>
<BR><FONT SIZE=2>different distribution point to avoid the download of CRLs that cannot be </FONT>
<BR><FONT SIZE=2>employed.&nbsp; Alternatively, the CA could publish one CRL signed with the new </FONT>
<BR><FONT SIZE=2>key.&nbsp; This leads to the scenario where cert path construction must be </FONT>
<BR><FONT SIZE=2>evoked to generate validate the CRL when trying to validate a certificate </FONT>
<BR><FONT SIZE=2>signed by the old key.&nbsp; This is the behavior that we are trying to make SHOULD.</FONT>
</P>

<P><FONT SIZE=2>Therefore, the CA MUST generate the CRL using the same key as was used to </FONT>
<BR><FONT SIZE=2>sign the certificate, or it MUST include an extension in the CRL to </FONT>
<BR><FONT SIZE=2>indicate that cert path construction might be needed to validate the CRL </FONT>
<BR><FONT SIZE=2>signature.&nbsp; I proposed that an Issuing Distribution Point (IDP) CRL </FONT>
<BR><FONT SIZE=2>extension might be the correct approach.&nbsp; The IDP extension will not be </FONT>
<BR><FONT SIZE=2>supported by the simple clients, so they can generate the &quot;unsupported </FONT>
<BR><FONT SIZE=2>feature&quot; error, and the more complex clients can use the information in the </FONT>
<BR><FONT SIZE=2>IDP to support path construction.&nbsp; They will of course, also use Authority </FONT>
<BR><FONT SIZE=2>Key Identifier extension.</FONT>
</P>

<P><FONT SIZE=2>{Santosh Says: Item 1 will require a change to the IDP extension syntax.&nbsp; Would n't that make PKIX non-compliant with X.509?)</FONT></P>

<P><FONT SIZE=2>&gt;Second, when we say that a CA may not use different keys for signing </FONT>
<BR><FONT SIZE=2>&gt;certificates and CRLs, we are again not thinking of </FONT>
<BR><FONT SIZE=2>&gt;operations.&nbsp; Operationally, a CA is going to rekey.&nbsp; When it does, it will </FONT>
<BR><FONT SIZE=2>&gt;have issued the certificates using the old key and will sign CRL with new </FONT>
<BR><FONT SIZE=2>&gt;key.&nbsp; There are your different keys.</FONT>
</P>

<P><FONT SIZE=2>The simple CA could reasonably expect the CA to generate CRLs using the </FONT>
<BR><FONT SIZE=2>same key that was used to sign certificates until all of the certificates </FONT>
<BR><FONT SIZE=2>signed with that key have expired.</FONT>
</P>

<P><FONT SIZE=2>(Santosh Says: That is what I have been advocating.&nbsp; But, mandating that a CA retain old private keys and issue multiple CRLs may be excessive.)</FONT></P>

<P><FONT SIZE=2>&gt;Also, I think a standard should be flexible and promote security.&nbsp; From </FONT>
<BR><FONT SIZE=2>&gt;operational security viewpoint, a CA may not want to keep the certificate </FONT>
<BR><FONT SIZE=2>&gt;signing key active all the time, but may need to keep the CRL signing key </FONT>
<BR><FONT SIZE=2>&gt;active to help meet CRL issuance obligations.&nbsp; This will mean a separate </FONT>
<BR><FONT SIZE=2>&gt;CRL signing key since compromise of that key still does not compromise </FONT>
<BR><FONT SIZE=2>&gt;anything.&nbsp; The attacker needs to compromise some subscriber keys to create </FONT>
<BR><FONT SIZE=2>&gt;a true compromise, denial-of-service notwithstanding.&nbsp; Thus, we should </FONT>
<BR><FONT SIZE=2>&gt;accommodate separate keys for certificates and CRLs.</FONT>
</P>

<P><FONT SIZE=2>We need to balance the complexity of the software that we expect the </FONT>
<BR><FONT SIZE=2>clients to handle and CA operational security.&nbsp; Errors in either place will </FONT>
<BR><FONT SIZE=2>lead to vulnerabilities.</FONT>
</P>

<P><FONT SIZE=2>&gt;In short, requiring the CA to use a different name to issue indirect CRL </FONT>
<BR><FONT SIZE=2>&gt;is not well-grounded and should be deleted.</FONT>
</P>

<P><FONT SIZE=2>Agree.</FONT>
</P>

<P><FONT SIZE=2>&gt;Requiring a CA to use different key for indirect CRL is not well-grounded </FONT>
<BR><FONT SIZE=2>&gt;and should be deleted.</FONT>
</P>

<P><FONT SIZE=2>I do not recall a discussion on this point.&nbsp; Usually, Indirect CRLs are </FONT>
<BR><FONT SIZE=2>employed to delegate CRL generation responsibility.&nbsp; I would expect the two </FONT>
<BR><FONT SIZE=2>authorities to have different keys.</FONT>
</P>

<P><FONT SIZE=2>(Santosh Says: But there is nothing in X.509 that a designated CA can not issue its own regular CRL and issue an indirect CRL for its peers.&nbsp; The designated CA may use the same key.&nbsp; The requirement you are levying has marginal benefit for the directories and clients who do not do multi-valued attributes and that only if the CA does NOT use a CRL DP for the indirect CRL.&nbsp; There is no particular need or requirement for having a separate name or a separate key)</FONT></P>

<P><FONT SIZE=2>&gt;Requiring the same key for certificate and CRL signing may not be possible </FONT>
<BR><FONT SIZE=2>&gt;due to rekey or operational security requirements and should be deleted.</FONT>
</P>

<P><FONT SIZE=2>We need to be pragmatic with respect to simple clients.&nbsp; I hope that I made </FONT>
<BR><FONT SIZE=2>my thoughts clear above.</FONT>
</P>

<P><FONT SIZE=2>(Santosh Says: I think the best engineering solution is for the CA to keep the old keys and sign multiple CRLs.&nbsp; That said, I do not want to mandate it and I&nbsp; for sure want the PKIX community to approve the RFC knowing this implication.)</FONT></P>

<P><FONT SIZE=2>&gt;Finally, as to Steve Farrell's question regarding client simplicity, I </FONT>
<BR><FONT SIZE=2>&gt;wish I could answer that.&nbsp; The client will need intelligence to handle </FONT>
<BR><FONT SIZE=2>&gt;rekey and secure CA who use different keys for certificate and CRL signing.</FONT>
</P>

<P><FONT SIZE=2>Again, I hope that I made my thoughts clear above.</FONT>
</P>

<P><FONT SIZE=2>Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CC3B.DADAC100--


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA22910 for <[e-mail]>; Mon, 23 Apr 2001 13:22:39 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Apr 2001 20:22:41 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA17703 for <[e-mail]>; Mon, 23 Apr 2001 16:22:41 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <HK1A3R00>; Mon, 23 Apr 2001 16:22:41 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HK1A3R07; Mon, 23 Apr 2001 16:22:34 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 23 Apr 2001 16:21:19 -0400
Subject: RE: Dedicated CRL signing keys
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Santosh:

Thanks for posting your summary of the thread.  I hope it will allow us to 
focus on the issues, and reach consensus quickly.

>First, I think that the restriction that a CA who desires to issue 
>Indirect CRL needs to set itself up as a separate name is unduly 
>restrictive.  There is no need for a CA to do that.  A CA can issue a full 
>CRL as well as an Indirect CRL and populate these in the same or different 
>entries (i.e., CRL DP) in the directory.  Please review Annex B of X.509 
>for how to process CRL.  So, may be Russ can explain why this requirement 
>comes about.

I agree that the use of a separate name is overly restrictive.  That 
portion of my suggestion was, in hind sight, a bad idea.  As Tim Polk 
pointed out, CAs cannot change their names when they rekey.

I think that everyone agrees that a CA makes a commitment to provide some 
form of revocation information for the duration of the certificate 
life.  When CRLs are employed, does the CA use the same key to sign the CRL 
as was used to sign the certificate?  Clearly, the CA is permitted to use 
different keys -- the key usage bits are there to allow this 
separation.  However, several clients cannot handle this situation, and 
they would like to see an error message that says "unsupported feature" 
instead of "signature invalid."

Perhaps CA rekey will lead us to an answer.  When a CA rekeys, does it are 
subsequent CRLs signed with the new key or the old one?  A CA could 
generate one CRL with each key.  They two CRLs could even be distributed by 
different distribution point to avoid the download of CRLs that cannot be 
employed.  Alternatively, the CA could publish one CRL signed with the new 
key.  This leads to the scenario where cert path construction must be 
evoked to generate validate the CRL when trying to validate a certificate 
signed by the old key.  This is the behavior that we are trying to make SHOULD.

Therefore, the CA MUST generate the CRL using the same key as was used to 
sign the certificate, or it MUST include an extension in the CRL to 
indicate that cert path construction might be needed to validate the CRL 
signature.  I proposed that an Issuing Distribution Point (IDP) CRL 
extension might be the correct approach.  The IDP extension will not be 
supported by the simple clients, so they can generate the "unsupported 
feature" error, and the more complex clients can use the information in the 
IDP to support path construction.  They will of course, also use Authority 
Key Identifier extension.

>Second, when we say that a CA may not use different keys for signing 
>certificates and CRLs, we are again not thinking of 
>operations.  Operationally, a CA is going to rekey.  When it does, it will 
>have issued the certificates using the old key and will sign CRL with new 
>key.  There are your different keys.

The simple CA could reasonably expect the CA to generate CRLs using the 
same key that was used to sign certificates until all of the certificates 
signed with that key have expired.

>Also, I think a standard should be flexible and promote security.  From 
>operational security viewpoint, a CA may not want to keep the certificate 
>signing key active all the time, but may need to keep the CRL signing key 
>active to help meet CRL issuance obligations.  This will mean a separate 
>CRL signing key since compromise of that key still does not compromise 
>anything.  The attacker needs to compromise some subscriber keys to create 
>a true compromise, denial-of-service notwithstanding.  Thus, we should 
>accommodate separate keys for certificates and CRLs.

We need to balance the complexity of the software that we expect the 
clients to handle and CA operational security.  Errors in either place will 
lead to vulnerabilities.

>In short, requiring the CA to use a different name to issue indirect CRL 
>is not well-grounded and should be deleted.

Agree.

>Requiring a CA to use different key for indirect CRL is not well-grounded 
>and should be deleted.

I do not recall a discussion on this point.  Usually, Indirect CRLs are 
employed to delegate CRL generation responsibility.  I would expect the two 
authorities to have different keys.

>Requiring the same key for certificate and CRL signing may not be possible 
>due to rekey or operational security requirements and should be deleted.

We need to be pragmatic with respect to simple clients.  I hope that I made 
my thoughts clear above.

>Finally, as to Steve Farrell's question regarding client simplicity, I 
>wish I could answer that.  The client will need intelligence to handle 
>rekey and secure CA who use different keys for certificate and CRL signing.

Again, I hope that I made my thoughts clear above.

Russ


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA22871 for <[e-mail]>; Mon, 23 Apr 2001 13:22:28 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Apr 2001 20:22:30 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA17671 for <[e-mail]>; Mon, 23 Apr 2001 16:22:30 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <HK1A3R0W>; Mon, 23 Apr 2001 16:22:30 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HK1A3R0S; Mon, 23 Apr 2001 16:22:26 -0400
From: "Housley, Russ" <[e-mail]>
To: Carlin Covey <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 23 Apr 2001 15:31:38 -0400
Subject: RE: delta-CRLs (was Re: Last  Call:draft-ietf-pkix-new-part1-06.txt  comments)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Carlin:

I was hoping to start the dialogue regarding the security considerations text.

Russ

At 10:28 AM 4/23/2001 -0700, Carlin Covey wrote:
>Russ,
>
>Two obvious candidates for alternative text are (1)
>substituting MAY for MUST and (2) substituting SHOULD
>for MUST in the sentence:
>
>"A dCRL may also be an indirect CRL in that it may
>contain updated revocation information related to
>base CRLs issued by one or more than one authorities."
>
>I think that these alternative wordings have been
>either stated or implied by various persons in the
>course of this discussion.
>
>Were you asking for some alternative text to go
>into the security considerations section?
>
>Regards,
>
>Carlin
>
>____________________________
>
>-  Carlin Covey
>    Cylink Corporation
>
>
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Monday, April 23, 2001 7:27 AM
>To: [e-mail]
>Subject: RE: delta-CRLs (was Re: Last
>Call:draft-ietf-pkix-new-part1-06.txt comments)
>
>
>All:
>
>Trevor, Ambarish, Denis, David, and others have proposed the removal of the
>requirement that CAs post a full CRL whenever a delta-CRL is
>posted.  Trevor's suggestion that the consequences of a CA posting a
>delta-CRL without posting a full CRL could be discussed in a single
>paragraph in the Security Considerations section.
>
>Paul and Mike have suggested that the current text is fine.
>
>A few people have contributed to the thread but not made their own position
>clear.  Perhaps they are only academically interested.  Or, perhaps the
>dialogue is helping them reach their own conclusion.  I do not
>know.  Regardless, most people have been silent on this issue.
>
>I would like one of the proponents  for removing the requirement to suggest
>alternative text, and I would like to hear from more people about the
>proposed revision.
>
>We are in Working Group Last Call.  I would like to reach consensus on this
>issue, make the necessary change (if any), and get the document to the
>IESG.  Many other working groups are waiting for our document.
>
>Russ


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA22188 for <[e-mail]>; Mon, 23 Apr 2001 13:16:24 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <2VH1ATFN>; Mon, 23 Apr 2001 16:15:54 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Carlin Covey'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: RE: delta-CRLs (was Re: Last  Call:draft-ietf-pkix-new-part1-06.t xt  comments)
Date: Mon, 23 Apr 2001 16:10:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CC31.69B50A30"

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_01C0CC31.69B50A30
Content-Type: text/plain

Carlin, you are correct. That 'indirect delta' is a new facility added into
the 4th edition X.509. One example that was used in those discussions was
where there might be several CAs operating within a given domain (perhaps a
large multinational organization) and each issues its own CRLs on a regular
basis. Once retrieved, these CRLs may be cached at the validation step and
used until their expiry. However, that multinational may want to issue a
single delta CRL every minute and that CRL would contain revocation notices
for all the CAs within the organization but perhaps only for the
keyCompromise reason. I think you raise an interesting point because in this
type of environment the CA that issues the delta could not issue any single
corresponding base. However, I suspect indirectDeltas are beyond the scope
of what 2459 plans to cover?

Sharon 

> -----Original Message-----
> From: Carlin Covey [mailto:[e-mail]]
> Sent: Monday, April 23, 2001 1:28 PM
> To: Russ Housley; [e-mail]
> Subject: RE: delta-CRLs (was Re: Last
> Call:draft-ietf-pkix-new-part1-06.txt comments)
> 
> 
> Russ,
> 
> Two obvious candidates for alternative text are (1)
> substituting MAY for MUST and (2) substituting SHOULD
> for MUST in the sentence:
> 
> "A dCRL may also be an indirect CRL in that it may
> contain updated revocation information related to
> base CRLs issued by one or more than one authorities."
> 
> I think that these alternative wordings have been
> either stated or implied by various persons in the
> course of this discussion.
> 
> Were you asking for some alternative text to go
> into the security considerations section?
> 
> Regards,
> 
> Carlin
> 
> ____________________________
> 
> -  Carlin Covey
>    Cylink Corporation
> 
> 
> 
> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Monday, April 23, 2001 7:27 AM
> To: [e-mail]
> Subject: RE: delta-CRLs (was Re: Last
> Call:draft-ietf-pkix-new-part1-06.txt comments)
> 
> 
> All:
> 
> Trevor, Ambarish, Denis, David, and others have proposed the 
> removal of the
> requirement that CAs post a full CRL whenever a delta-CRL is
> posted.  Trevor's suggestion that the consequences of a CA posting a
> delta-CRL without posting a full CRL could be discussed in a single
> paragraph in the Security Considerations section.
> 
> Paul and Mike have suggested that the current text is fine.
> 
> A few people have contributed to the thread but not made 
> their own position
> clear.  Perhaps they are only academically interested.  Or, 
> perhaps the
> dialogue is helping them reach their own conclusion.  I do not
> know.  Regardless, most people have been silent on this issue.
> 
> I would like one of the proponents  for removing the 
> requirement to suggest
> alternative text, and I would like to hear from more people about the
> proposed revision.
> 
> We are in Working Group Last Call.  I would like to reach 
> consensus on this
> issue, make the necessary change (if any), and get the document to the
> IESG.  Many other working groups are waiting for our document.
> 
> Russ
> 

------_=_NextPart_001_01C0CC31.69B50A30
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta-CRLs (was Re: Last  =
Call:draft-ietf-pkix-new-part1-06.txt  comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Carlin, you are correct. That 'indirect delta' is a =
new facility added into the 4th edition X.509. One example that was =
used in those discussions was where there might be several CAs =
operating within a given domain (perhaps a large multinational =
organization) and each issues its own CRLs on a regular basis. Once =
retrieved, these CRLs may be cached at the validation step and used =
until their expiry. However, that multinational may want to issue a =
single delta CRL every minute and that CRL would contain revocation =
notices for all the CAs within the organization but perhaps only for =
the keyCompromise reason. I think you raise an interesting point =
because in this type of environment the CA that issues the delta could =
not issue any single corresponding base. However, I suspect =
indirectDeltas are beyond the scope of what 2459 plans to =
cover?</FONT></P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Carlin Covey [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, April 23, 2001 1:28 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Russ Housley; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: delta-CRLs (was Re: Last</FONT>
<BR><FONT SIZE=3D2>&gt; Call:draft-ietf-pkix-new-part1-06.txt =
comments)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Two obvious candidates for alternative text are =
(1)</FONT>
<BR><FONT SIZE=3D2>&gt; substituting MAY for MUST and (2) substituting =
SHOULD</FONT>
<BR><FONT SIZE=3D2>&gt; for MUST in the sentence:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;A dCRL may also be an indirect CRL in =
that it may</FONT>
<BR><FONT SIZE=3D2>&gt; contain updated revocation information related =
to</FONT>
<BR><FONT SIZE=3D2>&gt; base CRLs issued by one or more than one =
authorities.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think that these alternative wordings have =
been</FONT>
<BR><FONT SIZE=3D2>&gt; either stated or implied by various persons in =
the</FONT>
<BR><FONT SIZE=3D2>&gt; course of this discussion.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Were you asking for some alternative text to =
go</FONT>
<BR><FONT SIZE=3D2>&gt; into the security considerations =
section?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Carlin</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ____________________________</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -&nbsp; Carlin Covey</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Cylink Corporation</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Russ Housley [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, April 23, 2001 7:27 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: delta-CRLs (was Re: Last</FONT>
<BR><FONT SIZE=3D2>&gt; Call:draft-ietf-pkix-new-part1-06.txt =
comments)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; All:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Trevor, Ambarish, Denis, David, and others have =
proposed the </FONT>
<BR><FONT SIZE=3D2>&gt; removal of the</FONT>
<BR><FONT SIZE=3D2>&gt; requirement that CAs post a full CRL whenever a =
delta-CRL is</FONT>
<BR><FONT SIZE=3D2>&gt; posted.&nbsp; Trevor's suggestion that the =
consequences of a CA posting a</FONT>
<BR><FONT SIZE=3D2>&gt; delta-CRL without posting a full CRL could be =
discussed in a single</FONT>
<BR><FONT SIZE=3D2>&gt; paragraph in the Security Considerations =
section.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Paul and Mike have suggested that the current =
text is fine.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A few people have contributed to the thread but =
not made </FONT>
<BR><FONT SIZE=3D2>&gt; their own position</FONT>
<BR><FONT SIZE=3D2>&gt; clear.&nbsp; Perhaps they are only academically =
interested.&nbsp; Or, </FONT>
<BR><FONT SIZE=3D2>&gt; perhaps the</FONT>
<BR><FONT SIZE=3D2>&gt; dialogue is helping them reach their own =
conclusion.&nbsp; I do not</FONT>
<BR><FONT SIZE=3D2>&gt; know.&nbsp; Regardless, most people have been =
silent on this issue.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would like one of the proponents&nbsp; for =
removing the </FONT>
<BR><FONT SIZE=3D2>&gt; requirement to suggest</FONT>
<BR><FONT SIZE=3D2>&gt; alternative text, and I would like to hear from =
more people about the</FONT>
<BR><FONT SIZE=3D2>&gt; proposed revision.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We are in Working Group Last Call.&nbsp; I =
would like to reach </FONT>
<BR><FONT SIZE=3D2>&gt; consensus on this</FONT>
<BR><FONT SIZE=3D2>&gt; issue, make the necessary change (if any), and =
get the document to the</FONT>
<BR><FONT SIZE=3D2>&gt; IESG.&nbsp; Many other working groups are =
waiting for our document.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CC31.69B50A30--


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA21027 for <[e-mail]>; Mon, 23 Apr 2001 13:04:04 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 23 Apr 2001 13:04:14 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Mon, 23 Apr 2001 13:04:14 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26PXYG>; Mon, 23 Apr 2001 13:02:56 -0700
Content-return: allowed
Date: Mon, 23 Apr 2001 13:02:53 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt comments)
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Hi Paul,
    Even if you are requiring clients to pull the CRLs from your
directory, you still need to have enough bandwidth to and replication
of the directory to support all the clients who need to pull the
new CRL every time it is issued.

Ambarish

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


> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Monday, April 23, 2001 11:51 AM
> To: David P. Kemp; [e-mail]
> Subject: Re: delta-CRLs (was Re:
> LastCall:draft-ietf-pkix-new-part1-06.txt comments)
> 
> 
> At 12:50 PM -0400 4/23/01, David P. Kemp wrote:
> >I'll refer you to Russ' message of Jan 18 "Re: Two questions 
> on delta-CRL":
> >
> >   "I think we may be splitting hairs on the term "issue". I am not
> >    sure that I would consider a CRL that was generated but not
> >    distributed to be "issued".
> 
> I think we are splitting hairs on what "distributed" means.
> 
> >The problem is not that it is too burdensome for a CA to 
> have a cron job
> >that sweeps the database and signs a full CRL every time it 
> signs a delta.
> >The problem is that once the full CRL is signed, it is 
> transmitted across
> >the network to directory/database/repository replicas and to clients.
> 
> "Transmitted"? The only common form of "push" on the Internet is 
> email, and I know of no CRL-over-email distribution schemes. Much 
> more common is that the CA simply puts the newly-issued CRL on its 
> FTP/web server and waits for people who want the CRL to come to them.
> 
> Some people have automated jobs that mirror the CRLs every day or 
> even more often; these folks have already calculated the cost of 
> mirroring so often (and of not using delta CRLs).
> 
> >If you are a PKI provider (as I am), and you have to provision 3.5
> >million subscribers, the cost of that provisioning with full CRLs is
> >prohibitive, whereas the cost of provisioning with deltas is not.
> 
> You do not have to provision them with the latest CRL; you simply 
> need to let them get the latest CRL when they feel like it. Or, 
> better yet, tell them to get the delta CRL; that is why you issued 
> it, yes?
> 
> >If Russ (i.e. the PKIX WG) would make a clear statement that "issue"
> >means "sign and place in one repository", vice "sign and distribute
> >to all RPs", then I would have no problem with the current MUST
> >requirement.  But if a CRL is not deemed to be "issued" unless it is
> >available to all, then I strongly agree with Trevor, David Cross, and
> >Ambarish that the requirement to "issue" a full CRL for every delta
> >must be relaxed.
> 
> We agree here, other than I would say "issue" means "sign and place 
> in at least all the repositories that are pointed to in any CRL 
> Distribution Point URI."
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA19571 for <[e-mail]>; Mon, 23 Apr 2001 12:46:43 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA22379 for <[e-mail]>; Mon, 23 Apr 2001 15:46:15 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Mon, 23 Apr 2001 15:44:26 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: delta-CRLs (was Re:  LastCall:draft-ietf-pkix-new-part1-06.txtcomments)
References: <[e-mail]> <p0510080eb70895081561@[192.168.1.13]> <[e-mail]> <p05100802b70a28cbba9d@[165.227.249.20]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Hoffman / IMC wrote:
> 
> "Transmitted"? The only common form of "push" on the Internet is
> email, and I know of no CRL-over-email distribution schemes. Much
> more common is that the CA simply puts the newly-issued CRL on its
> FTP/web server and waits for people who want the CRL to come to them.

[dpk] Push or pull, smtp or ftp or http or ldap, the bits are carried
across the net in some manner.  The bits are what I'm talking about,
not the protocol.

> Some people have automated jobs that mirror the CRLs every day or
> even more often; these folks have already calculated the cost of
> mirroring so often (and of not using delta CRLs).

[dpk] Great! That's what I'd like to see to reduce latency below what
you'd get from a pure (client-demand-driven) pull architecture.  But by
"more often", do you mean every hour, for 3.5 M subscribers, 3 year
certificate validity, and 22% per year revocation rate?  Do the math,
and you'll see what I mean.

> You do not have to provision them with the latest CRL; you simply
> need to let them get the latest CRL when they feel like it. Or,
> better yet, tell them to get the delta CRL; that is why you issued
> it, yes?

[dpk] Yes, that's the point.  And if clients can get delta CRLs every
hour, what's the reason for PKIX requiring CAs to "issue" full CRLs
every hour?

I agree completely with Mike Myers - no one is suggesting getting rid
of full CRLs; deltas can't work without first being initialized by a
full.  But PKIX should say that clients that can't handle deltas are
stuck with whatever fulls are available (24 hours) instead of promising
those clients that they can have 1 hour fulls regardless of the cost
to the infrastructure.

Dave


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA17970 for <[e-mail]>; Mon, 23 Apr 2001 12:25:26 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3NJPGd16810; Mon, 23 Apr 2001 12:25:16 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Mon, 23 Apr 2001 12:23:48 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

Santosh,

That is precisely what I'm proposing for the WG's consideration.  But I do
strongly advocate for a SHALL on full CRL production in any case.  Deltas
are a systems-level tuning tool.

Mike


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Monday, April 23, 2001 11:44 AM
To: Michael Myers; Santosh Chokhani; Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt
comments)


Mike:
I think you are saying that delta can be produced more frequently and there
need not be a full CRL issued when a delta is issued.
If the above is correct paraphrasing of your statement, then I agree.



Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA17506 for <[e-mail]>; Mon, 23 Apr 2001 12:22:34 -0700 (PDT)
Received: from 157.54.9.101 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 22 Apr 2001 19:48:34 -0700 (Pacific Daylight Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 22 Apr 2001 19:50:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Sun, 22 Apr 2001 19:44:46 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt  comments)
Thread-Index: AcDLmtMLSDPxfs3sRuyqpWlK+DiLEgAA7FmA
From: "David Cross" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 23 Apr 2001 02:50:33.0177 (UTC) FILETIME=[2A54A490:01C0CBA0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id MAA17507

Mike:

Yes, exactly, if I understand your statement correctly.  With network
replication and bandwidth limitations, the goal of many SHOULD be to
issue a base CRL less frequently with a longer validity and more
delta-CRLs with increased frequency and shorter validity.  This in my
mind is the orignal intent and ideal scenario for delta-CRL usage.  

Having a goal of making identical revocation status information to both
delta-aware and non delta-aware clients may be noble, but invariably
detracts from the ideal scenario described above.  If all CA vendors
would be compliant in issuing both, this would surely hurt
implementations and deployments due to the negative consequences to an
infrastructure.

 
David B. Cross
 



-----Original Message-----
From: Michael Myers [mailto:[e-mail]] 


Dave,

Recognizing broader enterprise issues, somwhere there's nonetheless a
middle ground where the mandatory practice of a full CRL complements the
optional practice of issuing deltas.  The period of the former MAY,
perhaps SHOULD, be longer than the latter in the presence of the delta
practice.  Your thoughts?

Mike



> -----Original Message-----
> From: David Cross [mailto:[e-mail]]
>
>
> It may not be a burden to a CA, but it very well likely may be burden 
> for the underlying replication and distribution architecture to push a

> full CRL every time a delta-CRL is issued.  It is the bigger picture 
> of the issue outside of the CA and PKI aspects.
>
>
> David B. Cross
>


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA16829 for <[e-mail]>; Mon, 23 Apr 2001 12:09:53 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JPVNWWWC>; Mon, 23 Apr 2001 15:09:23 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Carlin Covey <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: RE: delta-CRLs (was Re: Last  Call:draft-ietf-pkix-new-part1-06.t xt  comments)
Date: Mon, 23 Apr 2001 15:00:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CC27.AC1015A0"

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_01C0CC27.AC1015A0
Content-Type: text/plain;
	charset="iso-8859-1"

Carlin:

I did not reply to your earlier e-mail.  But, I think a delta is always to a
base issued by the same authority.  Thus, delta being an indirect means that
the same authority that is issuing the delta had issued a base CRL that
happens to be an indirect CRL.  Thus, delta is also an indirect and hence
may contain critical crlEntry extension of issuerDN.

-----Original Message-----
From: Carlin Covey [mailto:[e-mail]]
Sent: Monday, April 23, 2001 1:28 PM
To: Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)


Russ,

Two obvious candidates for alternative text are (1)
substituting MAY for MUST and (2) substituting SHOULD
for MUST in the sentence:

"A dCRL may also be an indirect CRL in that it may
contain updated revocation information related to
base CRLs issued by one or more than one authorities."

I think that these alternative wordings have been
either stated or implied by various persons in the
course of this discussion.

Were you asking for some alternative text to go
into the security considerations section?

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation



-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Monday, April 23, 2001 7:27 AM
To: [e-mail]
Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)


All:

Trevor, Ambarish, Denis, David, and others have proposed the removal of the
requirement that CAs post a full CRL whenever a delta-CRL is
posted.  Trevor's suggestion that the consequences of a CA posting a
delta-CRL without posting a full CRL could be discussed in a single
paragraph in the Security Considerations section.

Paul and Mike have suggested that the current text is fine.

A few people have contributed to the thread but not made their own position
clear.  Perhaps they are only academically interested.  Or, perhaps the
dialogue is helping them reach their own conclusion.  I do not
know.  Regardless, most people have been silent on this issue.

I would like one of the proponents  for removing the requirement to suggest
alternative text, and I would like to hear from more people about the
proposed revision.

We are in Working Group Last Call.  I would like to reach consensus on this
issue, make the necessary change (if any), and get the document to the
IESG.  Many other working groups are waiting for our document.

Russ

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta-CRLs (was Re: Last  =
Call:draft-ietf-pkix-new-part1-06.txt  comments)</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I did not reply to your earlier e-mail.&nbsp; But, I =
think a delta is always to a base issued by the same authority.&nbsp; =
Thus, delta being an indirect means that the same authority that is =
issuing the delta had issued a base CRL that happens to be an indirect =
CRL.&nbsp; Thus, delta is also an indirect and hence may contain =
critical crlEntry extension of issuerDN.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Carlin Covey [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 23, 2001 1:28 PM</FONT>
<BR><FONT SIZE=3D2>To: Russ Housley; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta-CRLs (was Re: Last</FONT>
<BR><FONT SIZE=3D2>Call:draft-ietf-pkix-new-part1-06.txt =
comments)</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>Two obvious candidates for alternative text are =
(1)</FONT>
<BR><FONT SIZE=3D2>substituting MAY for MUST and (2) substituting =
SHOULD</FONT>
<BR><FONT SIZE=3D2>for MUST in the sentence:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;A dCRL may also be an indirect CRL in that it =
may</FONT>
<BR><FONT SIZE=3D2>contain updated revocation information related =
to</FONT>
<BR><FONT SIZE=3D2>base CRLs issued by one or more than one =
authorities.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>I think that these alternative wordings have =
been</FONT>
<BR><FONT SIZE=3D2>either stated or implied by various persons in =
the</FONT>
<BR><FONT SIZE=3D2>course of this discussion.</FONT>
</P>

<P><FONT SIZE=3D2>Were you asking for some alternative text to =
go</FONT>
<BR><FONT SIZE=3D2>into the security considerations section?</FONT>
</P>

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

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

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

<P><FONT SIZE=3D2>-&nbsp; Carlin Covey</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Cylink Corporation</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Russ Housley [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 23, 2001 7:27 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta-CRLs (was Re: Last</FONT>
<BR><FONT SIZE=3D2>Call:draft-ietf-pkix-new-part1-06.txt =
comments)</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>Trevor, Ambarish, Denis, David, and others have =
proposed the removal of the</FONT>
<BR><FONT SIZE=3D2>requirement that CAs post a full CRL whenever a =
delta-CRL is</FONT>
<BR><FONT SIZE=3D2>posted.&nbsp; Trevor's suggestion that the =
consequences of a CA posting a</FONT>
<BR><FONT SIZE=3D2>delta-CRL without posting a full CRL could be =
discussed in a single</FONT>
<BR><FONT SIZE=3D2>paragraph in the Security Considerations =
section.</FONT>
</P>

<P><FONT SIZE=3D2>Paul and Mike have suggested that the current text is =
fine.</FONT>
</P>

<P><FONT SIZE=3D2>A few people have contributed to the thread but not =
made their own position</FONT>
<BR><FONT SIZE=3D2>clear.&nbsp; Perhaps they are only academically =
interested.&nbsp; Or, perhaps the</FONT>
<BR><FONT SIZE=3D2>dialogue is helping them reach their own =
conclusion.&nbsp; I do not</FONT>
<BR><FONT SIZE=3D2>know.&nbsp; Regardless, most people have been silent =
on this issue.</FONT>
</P>

<P><FONT SIZE=3D2>I would like one of the proponents&nbsp; for removing =
the requirement to suggest</FONT>
<BR><FONT SIZE=3D2>alternative text, and I would like to hear from more =
people about the</FONT>
<BR><FONT SIZE=3D2>proposed revision.</FONT>
</P>

<P><FONT SIZE=3D2>We are in Working Group Last Call.&nbsp; I would like =
to reach consensus on this</FONT>
<BR><FONT SIZE=3D2>issue, make the necessary change (if any), and get =
the document to the</FONT>
<BR><FONT SIZE=3D2>IESG.&nbsp; Many other working groups are waiting =
for our document.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C0CC27.AC1015A0--


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA16554 for <[e-mail]>; Mon, 23 Apr 2001 12:07:43 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Apr 2001 19:07:44 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA10364 for <[e-mail]>; Mon, 23 Apr 2001 15:07:40 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <HK1A3QNT>; Mon, 23 Apr 2001 15:07:40 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.85 [10.3.1.85]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HK1A3QNQ; Mon, 23 Apr 2001 15:07:37 -0400
From: "Housley, Russ" <[e-mail]>
To: Carlin Covey <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 23 Apr 2001 15:07:28 -0400
Subject: RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt comments)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Carlin:

By my reading of RFC 2459, the CA must generate and make publicly available 
a CRL every time that it generates a delta-CRL.

Russ

At 11:47 AM 4/23/2001 -0700, Carlin Covey wrote:
>Russ,
>
>A CA might wish to generate a dCRL simply for the purpose of
>handing it off to an OCSP responder, with no intention of the
>dCRL falling into the hands of RPs.  Since the CA does not
>"issue" the dCRL, apparently the CA does not need to generate
>a full CRL?
>
>Regards,
>
>Carlin
>
>____________________________
>
>-  Carlin Covey
>    Cylink Corporation
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of David P. Kemp
>Sent: Monday, April 23, 2001 9:51 AM
>To: [e-mail]
>Subject: Re: delta-CRLs (was Re:
>LastCall:draft-ietf-pkix-new-part1-06.txt comments)
>
>
>Paul,
>
>I'll refer you to Russ' message of Jan 18 "Re: Two questions on delta-CRL":
>
>   "I think we may be splitting hairs on the term "issue". I am not
>    sure that I would consider a CRL that was generated but not
>    distributed to be "issued".
>
>The problem is not that it is too burdensome for a CA to have a cron job
>that sweeps the database and signs a full CRL every time it signs a delta.
>The problem is that once the full CRL is signed, it is transmitted across
>the network to directory/database/repository replicas and to clients.
>If you are a PKI provider (as I am), and you have to provision 3.5
>million subscribers, the cost of that provisioning with full CRLs is
>prohibitive, whereas the cost of provisioning with deltas is not.
>
>If Russ (i.e. the PKIX WG) would make a clear statement that "issue"
>means "sign and place in one repository", vice "sign and distribute
>to all RPs", then I would have no problem with the current MUST
>requirement.  But if a CRL is not deemed to be "issued" unless it is
>available to all, then I strongly agree with Trevor, David Cross, and
>Ambarish that the requirement to "issue" a full CRL for every delta
>must be relaxed.
>
>Dave K
>
>
>
>
>Paul Hoffman / IMC wrote:
> >
> > At 6:03 PM -0700 4/21/01, Ambarish Malpani wrote:
> > >Russ, the problem with this is that CAs might be unwilling to issue
> > >delta-CRLs because issuing a full CRL every time is too
> > >burdensome.
> >
> > Could you describe how it is "too burdensome"? Maybe I'm being naive,
> > not being a CA, but asking a CA to sign a second document (the full
> > CRL) at the time that it signs the first document (the delta-CRL)
> > really doesn't seem that onerous.
> >
> > I think the current requirement is fine.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15882 for <[e-mail]>; Mon, 23 Apr 2001 11:52:57 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JPVNWWMQ>; Mon, 23 Apr 2001 14:52:27 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Michael Myers <[e-mail]>, Santosh Chokhani <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t  comments)
Date: Mon, 23 Apr 2001 14:43:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CC25.4F111630"

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_01C0CC25.4F111630
Content-Type: text/plain;
	charset="iso-8859-1"

Mike:

I think you are saying that delta can be produced more frequently and there
need not be a full CRL issued when a delta is issued.

If the above is correct paraphrasing of your statement, then I agree.

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Monday, April 23, 2001 1:53 PM
To: Santosh Chokhani; Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)



Santosh,

Which is the core concept behind my proposal for a middle ground on this
issue.  Your thoughts on that?

Mike

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Monday, April 23, 2001 10:35 AM
To: Michael Myers; Santosh Chokhani; Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt
comments)


> . . . once you got the referenced or later base and apply the delta to it,
you have the current stuff.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta-CRLs (was Re: Last =
Call:draft-ietf-pkix-new-part1-06.txt  comments)</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I think you are saying that delta can be produced =
more frequently and there&nbsp; need not be a full CRL issued when a =
delta is issued.</FONT></P>

<P><FONT SIZE=3D2>If the above is correct paraphrasing of your =
statement, then I agree.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael Myers [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Monday, April 23, 2001 1:53 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani; Russ Housley; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta-CRLs (was Re: Last</FONT>
<BR><FONT SIZE=3D2>Call:draft-ietf-pkix-new-part1-06.txt =
comments)</FONT>
</P>
<BR>
<BR>

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

<P><FONT SIZE=3D2>Which is the core concept behind my proposal for a =
middle ground on this</FONT>
<BR><FONT SIZE=3D2>issue.&nbsp; Your thoughts on that?</FONT>
</P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 23, 2001 10:35 AM</FONT>
<BR><FONT SIZE=3D2>To: Michael Myers; Santosh Chokhani; Russ Housley; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta-CRLs (was Re: Last =
Call:draft-ietf-pkix-new-part1-06.txt</FONT>
<BR><FONT SIZE=3D2>comments)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; . . . once you got the referenced or later base =
and apply the delta to it,</FONT>
<BR><FONT SIZE=3D2>you have the current stuff.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CC25.4F111630--


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15604 for <[e-mail]>; Mon, 23 Apr 2001 11:52:11 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2LAW5VBG; Mon, 23 Apr 2001 11:47:22 -0700
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt   comments)
Date: Mon, 23 Apr 2001 11:47:13 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

Russ,

A CA might wish to generate a dCRL simply for the purpose of
handing it off to an OCSP responder, with no intention of the
dCRL falling into the hands of RPs.  Since the CA does not
"issue" the dCRL, apparently the CA does not need to generate
a full CRL?

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of David P. Kemp
Sent: Monday, April 23, 2001 9:51 AM
To: [e-mail]
Subject: Re: delta-CRLs (was Re:
LastCall:draft-ietf-pkix-new-part1-06.txt comments)


Paul,

I'll refer you to Russ' message of Jan 18 "Re: Two questions on delta-CRL":

  "I think we may be splitting hairs on the term "issue". I am not
   sure that I would consider a CRL that was generated but not
   distributed to be "issued".

The problem is not that it is too burdensome for a CA to have a cron job
that sweeps the database and signs a full CRL every time it signs a delta.
The problem is that once the full CRL is signed, it is transmitted across
the network to directory/database/repository replicas and to clients.
If you are a PKI provider (as I am), and you have to provision 3.5
million subscribers, the cost of that provisioning with full CRLs is
prohibitive, whereas the cost of provisioning with deltas is not.

If Russ (i.e. the PKIX WG) would make a clear statement that "issue"
means "sign and place in one repository", vice "sign and distribute
to all RPs", then I would have no problem with the current MUST
requirement.  But if a CRL is not deemed to be "issued" unless it is
available to all, then I strongly agree with Trevor, David Cross, and
Ambarish that the requirement to "issue" a full CRL for every delta
must be relaxed.

Dave K




Paul Hoffman / IMC wrote:
> 
> At 6:03 PM -0700 4/21/01, Ambarish Malpani wrote:
> >Russ, the problem with this is that CAs might be unwilling to issue
> >delta-CRLs because issuing a full CRL every time is too
> >burdensome.
> 
> Could you describe how it is "too burdensome"? Maybe I'm being naive,
> not being a CA, but asking a CA to sign a second document (the full
> CRL) at the time that it signs the first document (the delta-CRL)
> really doesn't seem that onerous.
> 
> I think the current requirement is fine.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium



Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15458; Mon, 23 Apr 2001 11:51:12 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100802b70a28cbba9d@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <p0510080eb70895081561@[192.168.1.13]> <[e-mail]>
Date: Mon, 23 Apr 2001 11:51:18 -0700
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt comments)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 12:50 PM -0400 4/23/01, David P. Kemp wrote:
>I'll refer you to Russ' message of Jan 18 "Re: Two questions on delta-CRL":
>
>   "I think we may be splitting hairs on the term "issue". I am not
>    sure that I would consider a CRL that was generated but not
>    distributed to be "issued".

I think we are splitting hairs on what "distributed" means.

>The problem is not that it is too burdensome for a CA to have a cron job
>that sweeps the database and signs a full CRL every time it signs a delta.
>The problem is that once the full CRL is signed, it is transmitted across
>the network to directory/database/repository replicas and to clients.

"Transmitted"? The only common form of "push" on the Internet is 
email, and I know of no CRL-over-email distribution schemes. Much 
more common is that the CA simply puts the newly-issued CRL on its 
FTP/web server and waits for people who want the CRL to come to them.

Some people have automated jobs that mirror the CRLs every day or 
even more often; these folks have already calculated the cost of 
mirroring so often (and of not using delta CRLs).

>If you are a PKI provider (as I am), and you have to provision 3.5
>million subscribers, the cost of that provisioning with full CRLs is
>prohibitive, whereas the cost of provisioning with deltas is not.

You do not have to provision them with the latest CRL; you simply 
need to let them get the latest CRL when they feel like it. Or, 
better yet, tell them to get the delta CRL; that is why you issued 
it, yes?

>If Russ (i.e. the PKIX WG) would make a clear statement that "issue"
>means "sign and place in one repository", vice "sign and distribute
>to all RPs", then I would have no problem with the current MUST
>requirement.  But if a CRL is not deemed to be "issued" unless it is
>available to all, then I strongly agree with Trevor, David Cross, and
>Ambarish that the requirement to "issue" a full CRL for every delta
>must be relaxed.

We agree here, other than I would say "issue" means "sign and place 
in at least all the repositories that are pointed to in any CRL 
Distribution Point URI."

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA14718 for <[e-mail]>; Mon, 23 Apr 2001 11:32:07 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3NIW6d13198; Mon, 23 Apr 2001 11:32:07 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt   comments)
Date: Mon, 23 Apr 2001 11:30:39 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

Dave,

But in a broader sense, isn't that precisely the problem directory
replication is all about?

It would be useful to hear of empirical studies establishing the extent to
which PKI information management today dominates directory (X.500, LDAP)
operations.  I advocate that we need to know what today's ground truth tells
us before we flip this parity bit; else wiggle the text as I proposed and so
provide everybody the tuning knobs they want to tailor the standard to local
needs.

More tactically, one could produce a full CRL as a "backup" but let the
delta practice take the burden of timeliness and bandwidth efficiency.  But
in all cases where non-repudiation becomes a true (vice theoretical) issue,
there MUST be a full CRL around somewhere that cleanly establishes a
context.  Else one is faced with reconstituting the full context via
re-accumulation of all the relevant deltas.  Not an easy task either, and
one prone to error.  Given the ease with which a full CRL can be produced
(assuming mechanisms are in place to produce deltas), just crontab two
periods:  a "full" production and a "delta" production, with the period of
the latter shorter than the former.  You don't have to push the full CRL all
over the place, but at a minimum certainly have it available.

A systems-level tradeoff, as always.  But dumping full CRLs entirely and
trusting deltas exclusively isn't something I'd advocate to any enterprise
concerned about its risk management practices.

Mike

> -----Original Message-----
> From: [e-mail]
> . . .
> The problem is that once the full CRL is signed, it is transmitted across
> the network to directory/database/repository replicas and to clients.
> If you are a PKI provider (as I am), and you have to provision 3.5
> million subscribers, the cost of that provisioning with full CRLs is
> prohibitive, whereas the cost of provisioning with deltas is not.



Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA14242 for <[e-mail]>; Mon, 23 Apr 2001 11:23:35 -0700 (PDT)
Received: from 157.54.9.101 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Apr 2001 06:39:18 -0700 (Pacific Daylight Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 19 Apr 2001 06:39:07 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Help Sought on Netscape Revocation URL causing MS Programs to hang
Date: Thu, 19 Apr 2001 06:39:06 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Help Sought on Netscape Revocation URL causing MS Programs to hang
Thread-Index: AcDIdFtBiqL/mHnUTCenzPDH/gBAGQAYYSxg
From: "David Cross" <[e-mail]>
To: "Ron Segal" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 19 Apr 2001 13:39:07.0303 (UTC) FILETIME=[1B4E0B70:01C0C8D6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id LAA14243

I will pass on the job offer, but have you verified that the URLs are
valid that are listed in the certificate?  If the URLs are no longer
valid or cannot be reached, that might explain the behaviour.  If you
want to send me the certificate chain (privately), we can take a look at
it.

David B. Cross
 

 



-----Original Message-----
From: Ron Segal [mailto:[e-mail]] 
Sent: Wednesday, April 18, 2001 6:59 PM
To: [e-mail]
Subject: Help Sought on Netscape Revocation URL causing MS Programs to
hang


Hi Folks

If an X.509 v3 certificate contains a proprietary NetscapeRevocationURL
extension and a Microsoft program (eg email or browser) is configured to
do automatic CRL Distribution Point Checking, then the Microsoft program
will hang and timeout after about 5 minutes.

Does anybody know of a fix for this problem, e.g. a registry
configuration (no cynicism please!)?

We are aware that if a cert has both the NetscapeRevocationURL and CRL
Distribution Point extensions, then no problem.

Your help would be greatly appreciated (and maybe you can get a job at
Baycorp!).

Very best regards

Ron

--------------
Ron Segal
Business Development Manager
Baycorp ID Services Ltd
PO Box 5052, Wellington, New Zealand

Mailto: [e-mail]
Tel:   +64 (4)  499 4231
DD:    +64 (4)  499 4261
Mob:   [phone]
Fax:   +64 (4)  499 4233
Web:   http://www.baycorpid.com



Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA13262 for <[e-mail]>; Mon, 23 Apr 2001 11:07:02 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3NI4wd10709; Mon, 23 Apr 2001 11:04:58 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t  comments)
Date: Mon, 23 Apr 2001 11:03:31 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

So let's just issue them in different periods with deltas more frequent than
the full.


-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]]
Sent: Monday, April 23, 2001 9:40 AM
To: Santosh Chokhani; Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t
comments)


I agree with Santosh. Forcing the issuance of a full CRL each time a delta
is issued removes the primary value of issuing the delta in the first place.



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA12920 for <[e-mail]>; Mon, 23 Apr 2001 11:04:50 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2LAW545B; Mon, 23 Apr 2001 10:59:35 -0700
From: "Carlin Covey" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t  comments)
Date: Mon, 23 Apr 2001 10:59:27 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C0CBE4.77139D10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C0CBE4.77139D10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt
comments)Russ and Sharon,

X.509 Ed. 4 draft v6 says in section 9  "A dCRL may also be an indirect CRL
in that it may contain updated revocation information related to base CRLs
issued by one or more than one authorities."

In this case in order to comply with the current PKIX profile requirement
below,
the CA that issued the dCRL would also have to issue a full indirect CRL for
all the authorities whose CRLs were updated by the dCRL.  That much I
understand, I think.

            Current PKIX profile requirement:  "When a conforming CA issues
            a delta CRL, the CA MUST also issue a CRL that is complete for
            the given scope."


But I'm puzzled by another point.   It looks to me like X.509 permits a dCRL
to contain a crlScope extension that limits the scope of the certificates
for
which the dCRL is authoritative (using onlyContains or onlySomeReasons,
for instance).  In fact, it seems that different CA's could issue indirect
dCRLs
for various scopes (e.g. user certificate, attribute certificate,
keyCompromise,
certificateHold, etc.), but reference a base CRL that covers a larger scope.
In that case, I suppose each of the dCRL issuers must also issue a "full
CRL".
But what constitutes a full "CRL that is complete for the given scope."?  Is
it
the given scope of the dCRL, or the given scope of the base CRL?  That is,
does
each "full CRL" cover only the scope of the dCRL, even if the dCRL's base
CRL
covers additional scope (e.g. additional reason codes, or additional
certificate
types)?

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation



  -----Original Message-----
  From: Sharon Boeyen [mailto:[e-mail]]
  Sent: Monday, April 23, 2001 9:40 AM
  To: Santosh Chokhani; Russ Housley; [e-mail]
  Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx
t comments)


  I agree with Santosh. Forcing the issuance of a full CRL each time a delta
is issued removes the primary value of issuing the delta in the first place.

------=_NextPart_000_0000_01C0CBE4.77139D10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: delta-CRLs (was Re: Last =
Call:draft-ietf-pkix-new-part1-06.txt comments)</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>Russ=20
and Sharon,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>X.509=20
Ed. 4 draft v6 says in section 9&nbsp; "A dCRL may also be an indirect =
CRL=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>in=20
that it may contain updated revocation information related to base CRLs=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>issued=20
by one or more than one authorities."</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>In=20
this case in order to comply with the current PKIX profile requirement=20
below,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>the CA=20
that issued the dCRL would also have to issue a full indirect CRL=20
for</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>all=20
the authorities whose CRLs were updated by the dCRL.&nbsp; That much I=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001>understand, I =
think.&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D730544716-23042001>
<P><FONT size=3D2><FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
class=3D730544716-23042001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
Current PKIX profile requirement:&nbsp; </SPAN>"When a conforming CA=20
issues&nbsp;</FONT></FONT><BR><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
class=3D730544716-23042001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
</SPAN>a delta CRL, </FONT><FONT face=3DArial></FONT><FONT=20
color=3D#0000ff></FONT><FONT size=3D2>the CA MUST also issue a CRL that =
is complete=20
for&nbsp;<BR><SPAN=20
class=3D730544716-23042001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
</SPAN>the given scope."</FONT></FONT></FONT></P></SPAN></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>But=20
I'm puzzled by another point.&nbsp; &nbsp;It looks to me like X.509 =
permits a=20
dCRL</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>to=20
contain a crlScope extension that limits the scope of the certificates=20
for</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>which=20
the dCRL is authoritative (using onlyContains or=20
onlySomeReasons,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>for=20
instance).&nbsp; In fact, it seems that different CA's could issue =
indirect=20
dCRLs</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>for=20
various scopes (e.g. user certificate, attribute certificate,=20
keyCompromise,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001>certificateHold, etc.), but reference a base =
CRL that=20
covers a larger scope.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>In=20
that case, I suppose each of the dCRL issuers must</SPAN></FONT><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN class=3D730544716-23042001> =
also=20
issue</SPAN></FONT><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001> a "full CRL".&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>But=20
what constitutes&nbsp;a full&nbsp;"CRL that is complete for<SPAN=20
class=3D730544716-23042001> </SPAN>the given scope."?&nbsp; Is=20
it</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>the=20
given scope of the dCRL, or the given scope of the base CRL?&nbsp; That =
is,=20
does</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>each=20
"full CRL"&nbsp;cover only the scope of the dCRL, even if the dCRL's =
base=20
CRL</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>covers=20
additional scope (e.g. additional reason codes, or additional=20
certificate</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001>types)?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>
<P><FONT=20
size=3D2>Regards,<BR><BR>Carlin<BR><BR>____________________________<BR><B=
R>-&nbsp;=20
Carlin Covey<BR>&nbsp;&nbsp; Cylink Corporation =
</FONT></P></SPAN></FONT></DIV>
<DIV><SPAN class=3D730544716-23042001>
<P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D730544716-23042001></SPAN></FONT></FONT></FONT>&nbsp;</P></SPAN><=
/DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, April 23, =
2001 9:40=20
  AM<BR><B>To:</B> Santosh Chokhani; Russ Housley;=20
  [e-mail]<BR><B>Subject:</B> RE: delta-CRLs (was Re: Last=20
  Call:draft-ietf-pkix-new-part1-06.tx t comments)<BR><BR></DIV></FONT>
  <DIV><SPAN class=3D229484416-23042001><FONT color=3D#0000ff =
face=3DArial size=3D2>I=20
  agree with Santosh. Forcing the issuance of a full CRL each time a =
delta is=20
  issued removes the primary value of issuing the delta in the first=20
  place.</FONT></SPAN></DIV></BLOCKQUOTE></DIV></BODY></HTML>

------=_NextPart_000_0000_01C0CBE4.77139D10--



Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA12143 for <[e-mail]>; Mon, 23 Apr 2001 10:57:01 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3NHspd09796; Mon, 23 Apr 2001 10:54:52 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Mon, 23 Apr 2001 10:53:25 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

Santosh,

Which is the core concept behind my proposal for a middle ground on this
issue.  Your thoughts on that?

Mike

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Monday, April 23, 2001 10:35 AM
To: Michael Myers; Santosh Chokhani; Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt
comments)


> . . . once you got the referenced or later base and apply the delta to it,
you have the current stuff.



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA11096 for <[e-mail]>; Mon, 23 Apr 2001 10:43:54 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JPVNWVFS>; Mon, 23 Apr 2001 13:43:24 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Michael Myers <[e-mail]>, Santosh Chokhani <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t  comments)
Date: Mon, 23 Apr 2001 13:34:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CC1B.A9840A00"

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_01C0CC1B.A9840A00
Content-Type: text/plain;
	charset="iso-8859-1"

Delta CRL concept is lot simpler than folks make out it to be.  If a
compliant client takes a delta and a base that is referenced by the delta or
a later base, it has the current full picture.

As Sharon said, requiring a full CRL defeats the delta purpose.

Again, once you got the referenced or later base and apply the delta to it,
you have the current stuff.

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Monday, April 23, 2001 12:48 PM
To: Santosh Chokhani; Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)


Santosh,

I disagree.  I remain concerned about divergence from the standard database
maintenance practice of producing a "full" and a set of "deltas".  Towards
support of non-repudiation, I would expect that most who wish to make a case
on the basis of CRLs would prefer to make their case on the basis of a full
CRL.

At issue I believe is the notion that one MUST produce a full CRL every time
a delta is produced.  I suggest that this lock-step production process does
indeed needlessly impact enterprise infrastructures as Trevor observed.

Russ, I propose as a middle ground text establishing that:

1. full CRLs are a SHALL in all cases, thus contributing to
interoperability;

2. that the periods of production of a full CRL and its corresponding deltas
MAY be identical, thus yeilding the intent of the current text; but

4. when practiced, the production of deltas SHALL at a minimum be less than
that of the period of production of the corresponding full CRL, thus
enabling systems-level tuning to achieve a locally acceptable balance
between timeliness, effective non-repudiation support, generally accepted
database maintainence principles and infrastructure overhead.

And of course, deltas are a MAY.

I'll write this up as a drop-in to the current text depending on how
consensus flows on the proposal.

Mike


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Monday, April 23, 2001 8:45 AM
To: Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt
comments)


I have been quite on this.  I am firmly in favor of NOT having the
requirement (i.e., delete the requirement): "CA post a full CRL whenever a
delta CRL is issued".
-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Monday, April 23, 2001 10:27 AM
To: [e-mail]
Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)


All:
Trevor, Ambarish, Denis, David, and others have proposed the removal of the
requirement that CAs post a full CRL whenever a delta-CRL is
posted.  Trevor's suggestion that the consequences of a CA posting a
delta-CRL without posting a full CRL could be discussed in a single
paragraph in the Security Considerations section.
Paul and Mike have suggested that the current text is fine.
A few people have contributed to the thread but not made their own position
clear.  Perhaps they are only academically interested.  Or, perhaps the
dialogue is helping them reach their own conclusion.  I do not
know.  Regardless, most people have been silent on this issue.
I would like one of the proponents  for removing the requirement to suggest
alternative text, and I would like to hear from more people about the
proposed revision.
We are in Working Group Last Call.  I would like to reach consensus on this
issue, make the necessary change (if any), and get the document to the
IESG.  Many other working groups are waiting for our document.
Russ

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta-CRLs (was Re: Last =
Call:draft-ietf-pkix-new-part1-06.txt  comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Delta CRL concept is lot simpler than folks make out =
it to be.&nbsp; If a compliant client takes a delta and a base that is =
referenced by the delta or a later base, it has the current full =
picture.</FONT></P>

<P><FONT SIZE=3D2>As Sharon said, requiring a full CRL defeats the =
delta purpose.</FONT>
</P>

<P><FONT SIZE=3D2>Again, once you got the referenced or later base and =
apply the delta to it, you have the current stuff.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael Myers [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Monday, April 23, 2001 12:48 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani; Russ Housley; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta-CRLs (was Re: Last</FONT>
<BR><FONT SIZE=3D2>Call:draft-ietf-pkix-new-part1-06.txt =
comments)</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>I disagree.&nbsp; I remain concerned about divergence =
from the standard database</FONT>
<BR><FONT SIZE=3D2>maintenance practice of producing a &quot;full&quot; =
and a set of &quot;deltas&quot;.&nbsp; Towards</FONT>
<BR><FONT SIZE=3D2>support of non-repudiation, I would expect that most =
who wish to make a case</FONT>
<BR><FONT SIZE=3D2>on the basis of CRLs would prefer to make their case =
on the basis of a full</FONT>
<BR><FONT SIZE=3D2>CRL.</FONT>
</P>

<P><FONT SIZE=3D2>At issue I believe is the notion that one MUST =
produce a full CRL every time</FONT>
<BR><FONT SIZE=3D2>a delta is produced.&nbsp; I suggest that this =
lock-step production process does</FONT>
<BR><FONT SIZE=3D2>indeed needlessly impact enterprise infrastructures =
as Trevor observed.</FONT>
</P>

<P><FONT SIZE=3D2>Russ, I propose as a middle ground text establishing =
that:</FONT>
</P>

<P><FONT SIZE=3D2>1. full CRLs are a SHALL in all cases, thus =
contributing to</FONT>
<BR><FONT SIZE=3D2>interoperability;</FONT>
</P>

<P><FONT SIZE=3D2>2. that the periods of production of a full CRL and =
its corresponding deltas</FONT>
<BR><FONT SIZE=3D2>MAY be identical, thus yeilding the intent of the =
current text; but</FONT>
</P>

<P><FONT SIZE=3D2>4. when practiced, the production of deltas SHALL at =
a minimum be less than</FONT>
<BR><FONT SIZE=3D2>that of the period of production of the =
corresponding full CRL, thus</FONT>
<BR><FONT SIZE=3D2>enabling systems-level tuning to achieve a locally =
acceptable balance</FONT>
<BR><FONT SIZE=3D2>between timeliness, effective non-repudiation =
support, generally accepted</FONT>
<BR><FONT SIZE=3D2>database maintainence principles and infrastructure =
overhead.</FONT>
</P>

<P><FONT SIZE=3D2>And of course, deltas are a MAY.</FONT>
</P>

<P><FONT SIZE=3D2>I'll write this up as a drop-in to the current text =
depending on how</FONT>
<BR><FONT SIZE=3D2>consensus flows on the proposal.</FONT>
</P>

<P><FONT SIZE=3D2>Mike</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 23, 2001 8:45 AM</FONT>
<BR><FONT SIZE=3D2>To: Russ Housley; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta-CRLs (was Re: Last =
Call:draft-ietf-pkix-new-part1-06.txt</FONT>
<BR><FONT SIZE=3D2>comments)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I have been quite on this.&nbsp; I am firmly in favor =
of NOT having the</FONT>
<BR><FONT SIZE=3D2>requirement (i.e., delete the requirement): &quot;CA =
post a full CRL whenever a</FONT>
<BR><FONT SIZE=3D2>delta CRL is issued&quot;.</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Russ Housley [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 23, 2001 10:27 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta-CRLs (was Re: Last</FONT>
<BR><FONT SIZE=3D2>Call:draft-ietf-pkix-new-part1-06.txt =
comments)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>All:</FONT>
<BR><FONT SIZE=3D2>Trevor, Ambarish, Denis, David, and others have =
proposed the removal of the</FONT>
<BR><FONT SIZE=3D2>requirement that CAs post a full CRL whenever a =
delta-CRL is</FONT>
<BR><FONT SIZE=3D2>posted.&nbsp; Trevor's suggestion that the =
consequences of a CA posting a</FONT>
<BR><FONT SIZE=3D2>delta-CRL without posting a full CRL could be =
discussed in a single</FONT>
<BR><FONT SIZE=3D2>paragraph in the Security Considerations =
section.</FONT>
<BR><FONT SIZE=3D2>Paul and Mike have suggested that the current text =
is fine.</FONT>
<BR><FONT SIZE=3D2>A few people have contributed to the thread but not =
made their own position</FONT>
<BR><FONT SIZE=3D2>clear.&nbsp; Perhaps they are only academically =
interested.&nbsp; Or, perhaps the</FONT>
<BR><FONT SIZE=3D2>dialogue is helping them reach their own =
conclusion.&nbsp; I do not</FONT>
<BR><FONT SIZE=3D2>know.&nbsp; Regardless, most people have been silent =
on this issue.</FONT>
<BR><FONT SIZE=3D2>I would like one of the proponents&nbsp; for =
removing the requirement to suggest</FONT>
<BR><FONT SIZE=3D2>alternative text, and I would like to hear from more =
people about the</FONT>
<BR><FONT SIZE=3D2>proposed revision.</FONT>
<BR><FONT SIZE=3D2>We are in Working Group Last Call.&nbsp; I would =
like to reach consensus on this</FONT>
<BR><FONT SIZE=3D2>issue, make the necessary change (if any), and get =
the document to the</FONT>
<BR><FONT SIZE=3D2>IESG.&nbsp; Many other working groups are waiting =
for our document.</FONT>
<BR><FONT SIZE=3D2>Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CC1B.A9840A00--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA10694 for <[e-mail]>; Mon, 23 Apr 2001 10:40:24 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JPVNWVDQ>; Mon, 23 Apr 2001 13:39:55 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: [e-mail], Trevor Freeman <[e-mail]>
Cc: Russ Housley <[e-mail]>, [e-mail]
Subject: RE: Dedicated CRL signing keys
Date: Mon, 23 Apr 2001 13:31:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CC1B.2C837590"

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_01C0CC1B.2C837590
Content-Type: text/plain;
	charset="iso-8859-1"

Folks:

Over the last few days, I have suppressed the urge to respond to this
thread, largely because while I have a great deal of respect for the
individuals debating this and know them personally, there either seems to be
a general misunderstanding of the concepts, or their positions seems to be
misstated, or they seem to have simply not explained themselves well enough.


Also, this chain seems to imply that several issues are getting mixed.

So, here is my take on it all.

First, I think that the restriction that a CA who desires to issue Indirect
CRL needs to set itself up as a separate name is unduly restrictive.  There
is no need for a CA to do that.  A CA can issue a full CRL as well as an
Indirect CRL and populate these in the same or different entries (i.e., CRL
DP) in the directory.  Please review Annex B of X.509 for how to process
CRL.  So, may be Russ can explain why this requirement comes about.

Second, when we say that a CA may not use different keys for signing
certificates and CRLs, we are again not thinking of operations.
Operationally, a CA is going to rekey.  When it does, it will have issued
the certificates using the old key and will sign CRL with new key.  There
are your different keys.

Also, I think a standard should be flexible and promote security.  From
operational security viewpoint, a CA may not want to keep the certificate
signing key active all the time, but may need to keep the CRL signing key
active to help meet CRL issuance obligations.  This will mean a separate CRL
signing key since compromise of that key still does not compromise anything.
The attacker needs to compromise some subscriber keys to create a true
compromise, denial-of-service notwithstanding.  Thus, we should accommodate
separate keys for certificates and CRLs.

In short, requiring the CA to use a different name to issue indirect CRL is
not well-grounded and should be deleted.  Requiring a CA to use different
key for indirect CRL is not well-grounded and should be deleted.  Requiring
the same key for certificate and CRL signing may not be possible due to
rekey or operational security requirements and should be deleted.


Finally, as to Steve Farrell's question regarding client simplicity, I wish
I could answer that.  The client will need intelligence to handle rekey and
secure CA who use different keys for certificate and CRL signing.

-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]]
Sent: Saturday, April 21, 2001 4:08 PM
To: Trevor Freeman
Cc: Russ Housley; [e-mail]
Subject: Re: Dedicated CRL signing keys



Hi Trevor,

I'm sympathetic and would also like to see a nice solution that'd 
ease graceful failure for clients. However, if the proposal breaks
existing CAs then its not a solution (as Tim pointed out for a
different reason).

Stephen.

Trevor Freeman wrote:
> 
> Stephen,
> The route problem is that this is an optional feature, and the net
> result with the current proposal of profile compliant clients who
> encounter a CA operating with this option will simply be a signature
> failure. This presents a fairly high bar to anyone trying to establish
> why the revocation check is failing. The rational behind using a
> critical extension in the CRL is that now the conformant client knows
> that failure is by design without understanding what the problem is
> since it does not understand the extension and can return a more
> informative error like option not supported.
> Trevor
> 
> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Thursday, April 19, 2001 7:07 AM
> To: Russ Housley
> Cc: Trevor Freeman; [e-mail]
> Subject: Re: Dedicated CRL signing keys
> 
> Russ,
> 
> That'd be a bad resolution since it would break deployed CAs who
> use the same name and different cert and CRL signing keys (and
> those do exist and are operating).
> 
> Any other ideas or should we just require clients to understand
> what's going on based on key usage?
> 
> Stephen.
> 
> Russ Housley wrote:
> >
> > Trevor:
> >
> > I propose the following solution that builds on the Indirect CRL
> > capabilities that are already available.  When a CA wants to employ
> > separate private keys to sign certificates and CRLs, then that CA MUST
> > delegate CRL signing to a separate authority.  That separate authority
> MUST
> > have a different Distinguished Name that the CA, but it could be
> operated
> > by the same organization.  In this way, the IDP CRL extension would
> flag
> > the "unusual" circumstances.  Clients that do not support Indirect
> CRLs can
> > fail gracefully (unsupported optional feature), and clients that
> support
> > Indirect CRLs can happily handle the certificates and CRLs.
> >
> > Thoughts?
> >
> > Russ
> >
> > At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
> > >There has been some discussion regarding the proposal to have CRLs
> > >signed with CA keys which do not also sign certificates. Since this
> will
> > >not be a mandatory to implement feature, I am concerned about the
> impact
> > >on pkix compliant clients who encounter CRL signed in this way, and
> how
> > >we expect them to behave. What seem unacceptable with the current
> > >proposal is that the signage check on the CRL will fail, and the
> client
> > >will have little clue as to why and if this failure is expected. The
> > >information in the chain, while present, is in the CAs certificate,
> is
> > >difficult to find and subtle so would be easily missed by someone
> > >debugging this problem. I would like to see some clearer indication
> in a
> > >critical extension in the CRL itself that would indicate what was
> going
> > >on. In expressing these semantics in a critical extension, we
> maintain
> > >the principal that if you don't understand the extension, the client
> > >knows to fail due to its own inadequacies and that failure is by
> design,
> > >therefore allowing the client's to return an error unsupported option
> > >rather than invalid signature.
> > >Trevor
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Dedicated CRL signing keys</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>Over the last few days, I have suppressed the urge to =
respond to this thread, largely because while I have a great deal of =
respect for the individuals debating this and know them personally, =
there either seems to be a general misunderstanding of the concepts, or =
their positions seems to be misstated, or they seem to have simply not =
explained themselves well enough.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Also, this chain seems to imply that several issues =
are getting mixed.</FONT>
</P>

<P><FONT SIZE=3D2>So, here is my take on it all.</FONT>
</P>

<P><FONT SIZE=3D2>First, I think that the restriction that a CA who =
desires to issue Indirect CRL needs to set itself up as a separate name =
is unduly restrictive.&nbsp; There is no need for a CA to do =
that.&nbsp; A CA can issue a full CRL as well as an Indirect CRL and =
populate these in the same or different entries (i.e., CRL DP) in the =
directory.&nbsp; Please review Annex B of X.509 for how to process =
CRL.&nbsp; So, may be Russ can explain why this requirement comes =
about.</FONT></P>

<P><FONT SIZE=3D2>Second, when we say that a CA may not use different =
keys for signing certificates and CRLs, we are again not thinking of =
operations.&nbsp; Operationally, a CA is going to rekey.&nbsp; When it =
does, it will have issued the certificates using the old key and will =
sign CRL with new key.&nbsp; There are your different keys.</FONT></P>

<P><FONT SIZE=3D2>Also, I think a standard should be flexible and =
promote security.&nbsp; From operational security viewpoint, a CA may =
not want to keep the certificate signing key active all the time, but =
may need to keep the CRL signing key active to help meet CRL issuance =
obligations.&nbsp; This will mean a separate CRL signing key since =
compromise of that key still does not compromise anything.&nbsp; The =
attacker needs to compromise some subscriber keys to create a true =
compromise, denial-of-service notwithstanding.&nbsp; Thus, we should =
accommodate separate keys for certificates and CRLs.</FONT></P>

<P><FONT SIZE=3D2>In short, requiring the CA to use a different name to =
issue indirect CRL is not well-grounded and should be deleted.&nbsp; =
Requiring a CA to use different key for indirect CRL is not =
well-grounded and should be deleted.&nbsp; Requiring the same key for =
certificate and CRL signing may not be possible due to rekey or =
operational security requirements and should be deleted.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Finally, as to Steve Farrell's question regarding =
client simplicity, I wish I could answer that.&nbsp; The client will =
need intelligence to handle rekey and secure CA who use different keys =
for certificate and CRL signing.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stephen Farrell [<A =
HREF=3D"mailto:[e-mail]">mailto:stephen.farrell@balt=
imore.ie</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Saturday, April 21, 2001 4:08 PM</FONT>
<BR><FONT SIZE=3D2>To: Trevor Freeman</FONT>
<BR><FONT SIZE=3D2>Cc: Russ Housley; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Dedicated CRL signing keys</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi Trevor,</FONT>
</P>

<P><FONT SIZE=3D2>I'm sympathetic and would also like to see a nice =
solution that'd </FONT>
<BR><FONT SIZE=3D2>ease graceful failure for clients. However, if the =
proposal breaks</FONT>
<BR><FONT SIZE=3D2>existing CAs then its not a solution (as Tim pointed =
out for a</FONT>
<BR><FONT SIZE=3D2>different reason).</FONT>
</P>

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

<P><FONT SIZE=3D2>Trevor Freeman wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Stephen,</FONT>
<BR><FONT SIZE=3D2>&gt; The route problem is that this is an optional =
feature, and the net</FONT>
<BR><FONT SIZE=3D2>&gt; result with the current proposal of profile =
compliant clients who</FONT>
<BR><FONT SIZE=3D2>&gt; encounter a CA operating with this option will =
simply be a signature</FONT>
<BR><FONT SIZE=3D2>&gt; failure. This presents a fairly high bar to =
anyone trying to establish</FONT>
<BR><FONT SIZE=3D2>&gt; why the revocation check is failing. The =
rational behind using a</FONT>
<BR><FONT SIZE=3D2>&gt; critical extension in the CRL is that now the =
conformant client knows</FONT>
<BR><FONT SIZE=3D2>&gt; that failure is by design without understanding =
what the problem is</FONT>
<BR><FONT SIZE=3D2>&gt; since it does not understand the extension and =
can return a more</FONT>
<BR><FONT SIZE=3D2>&gt; informative error like option not =
supported.</FONT>
<BR><FONT SIZE=3D2>&gt; Trevor</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Stephen Farrell [<A =
HREF=3D"mailto:[e-mail]">mailto:stephen.farrell@balt=
imore.ie</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, April 19, 2001 7:07 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Russ Housley</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Trevor Freeman; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Dedicated CRL signing keys</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; That'd be a bad resolution since it would break =
deployed CAs who</FONT>
<BR><FONT SIZE=3D2>&gt; use the same name and different cert and CRL =
signing keys (and</FONT>
<BR><FONT SIZE=3D2>&gt; those do exist and are operating).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Any other ideas or should we just require =
clients to understand</FONT>
<BR><FONT SIZE=3D2>&gt; what's going on based on key usage?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Stephen.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ Housley wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Trevor:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I propose the following solution that =
builds on the Indirect CRL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; capabilities that are already =
available.&nbsp; When a CA wants to employ</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; separate private keys to sign certificates =
and CRLs, then that CA MUST</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; delegate CRL signing to a separate =
authority.&nbsp; That separate authority</FONT>
<BR><FONT SIZE=3D2>&gt; MUST</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; have a different Distinguished Name that =
the CA, but it could be</FONT>
<BR><FONT SIZE=3D2>&gt; operated</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; by the same organization.&nbsp; In this =
way, the IDP CRL extension would</FONT>
<BR><FONT SIZE=3D2>&gt; flag</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the &quot;unusual&quot; =
circumstances.&nbsp; Clients that do not support Indirect</FONT>
<BR><FONT SIZE=3D2>&gt; CRLs can</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; fail gracefully (unsupported optional =
feature), and clients that</FONT>
<BR><FONT SIZE=3D2>&gt; support</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Indirect CRLs can happily handle the =
certificates and CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Thoughts?</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; At 01:32 PM 4/18/2001 -0700, Trevor =
Freeman wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;There has been some discussion =
regarding the proposal to have CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;signed with CA keys which do not also =
sign certificates. Since this</FONT>
<BR><FONT SIZE=3D2>&gt; will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;not be a mandatory to implement =
feature, I am concerned about the</FONT>
<BR><FONT SIZE=3D2>&gt; impact</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;on pkix compliant clients who =
encounter CRL signed in this way, and</FONT>
<BR><FONT SIZE=3D2>&gt; how</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;we expect them to behave. What seem =
unacceptable with the current</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;proposal is that the signage check on =
the CRL will fail, and the</FONT>
<BR><FONT SIZE=3D2>&gt; client</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;will have little clue as to why and if =
this failure is expected. The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;information in the chain, while =
present, is in the CAs certificate,</FONT>
<BR><FONT SIZE=3D2>&gt; is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;difficult to find and subtle so would =
be easily missed by someone</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;debugging this problem. I would like =
to see some clearer indication</FONT>
<BR><FONT SIZE=3D2>&gt; in a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;critical extension in the CRL itself =
that would indicate what was</FONT>
<BR><FONT SIZE=3D2>&gt; going</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;on. In expressing these semantics in a =
critical extension, we</FONT>
<BR><FONT SIZE=3D2>&gt; maintain</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;the principal that if you don't =
understand the extension, the client</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;knows to fail due to its own =
inadequacies and that failure is by</FONT>
<BR><FONT SIZE=3D2>&gt; design,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;therefore allowing the client's to =
return an error unsupported option</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;rather than invalid signature.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Trevor</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; =
____________________________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Stephen Farrell</FONT>
<BR><FONT SIZE=3D2>&gt; Baltimore Technologies,&nbsp;&nbsp; tel: =
(direct line) [phone]</FONT>
<BR><FONT SIZE=3D2>&gt; 39 Parkgate =
Street,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax: [phone] =
7000</FONT>
<BR><FONT SIZE=3D2>&gt; Dublin =
8.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"mailto:[e-mail]">mailto:stephen.farrell@balt=
imore.ie</A></FONT>
<BR><FONT SIZE=3D2>&gt; =
Ireland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF=3D"http://www.baltimore.com" =
TARGET=3D"_blank">http://www.baltimore.com</A></FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT =
SIZE=3D2>____________________________________________________________</F=
ONT>
<BR><FONT SIZE=3D2>Stephen =
Farrell&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>Baltimore Technologies,&nbsp;&nbsp; tel: (direct =
line) [phone]</FONT>
<BR><FONT SIZE=3D2>39 Parkgate =
Street,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax: [phone] =
7000</FONT>
<BR><FONT SIZE=3D2>Dublin =
8.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"mailto:[e-mail]">mailto:stephen.farrell@balt=
imore.ie</A></FONT>
<BR><FONT =
SIZE=3D2>Ireland&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; <A =
HREF=3D"http://www.baltimore.com" =
TARGET=3D"_blank">http://www.baltimore.com</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CC1B.2C837590--


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA09788 for <[e-mail]>; Mon, 23 Apr 2001 10:33:04 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2LAW5448; Mon, 23 Apr 2001 10:28:13 -0700
From: "Carlin Covey" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t  comments)
Date: Mon, 23 Apr 2001 10:28:05 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C0CBE0.156A3A50"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C0CBE0.156A3A50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt
comments)Russ and Sharon,

X.509 Ed. 4 draft v6 says in section 9  "A dCRL may also be an indirect CRL
in that it may contain updated revocation information related to base CRLs
issued by one or more than one authorities."

In this case in order to comply with the current PKIX profile requirement
below,
the CA that issued the dCRL would also have to issue a full indirect CRL for
all the authorities whose CRLs were updated by the dCRL.  That much I
understand, I think.

            Current PKIX profile requirement:  "When a conforming CA issues
            a delta CRL, the CA MUST also issue a CRL that is complete for
            the given scope."


But I'm puzzled by another point.   It looks to me like X.509 permits a dCRL
to contain a crlScope extension that limits the scope of the certificates
for
which the dCRL is authoritative (using onlyContains or onlySomeReasons,
for instance).  In fact, it seems that different CA's could issue indirect
dCRLs
for various scopes (e.g. user certificate, attribute certificate,
keyCompromise,
certificateHold, etc.), but reference a base CRL that covers a larger scope.
In that case, I suppose each of the dCRL issuers must also issue a "full
CRL".
But what constitutes a full "CRL that is complete for the given scope."?  Is
it
the given scope of the dCRL, or the given scope of the base CRL?  That is,
does
each "full CRL" cover only the scope of the dCRL, even if the dCRL's base
CRL
covers additional scope (e.g. additional reason codes, or additional
certificate
types)?

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation



  -----Original Message-----
  From: Sharon Boeyen [mailto:[e-mail]]
  Sent: Monday, April 23, 2001 9:40 AM
  To: Santosh Chokhani; Russ Housley; [e-mail]
  Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx
t comments)


  I agree with Santosh. Forcing the issuance of a full CRL each time a delta
is issued removes the primary value of issuing the delta in the first place.
    -----Original Message-----
    From: Santosh Chokhani [mailto:[e-mail]]
    Sent: Monday, April 23, 2001 11:45 AM
    To: Russ Housley; [e-mail]
    Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.tx t comments)


    I have been quite on this.  I am firmly in favor of NOT having the
requirement (i.e., delete the requirement): "CA post a full CRL whenever a
delta CRL is issued".

    -----Original Message-----
    From: Russ Housley [mailto:[e-mail]]
    Sent: Monday, April 23, 2001 10:27 AM
    To: [e-mail]
    Subject: RE: delta-CRLs (was Re: Last
    Call:draft-ietf-pkix-new-part1-06.txt comments)



    All:

    Trevor, Ambarish, Denis, David, and others have proposed the removal of
the
    requirement that CAs post a full CRL whenever a delta-CRL is
    posted.  Trevor's suggestion that the consequences of a CA posting a
    delta-CRL without posting a full CRL could be discussed in a single
    paragraph in the Security Considerations section.

    Paul and Mike have suggested that the current text is fine.

    A few people have contributed to the thread but not made their own
position
    clear.  Perhaps they are only academically interested.  Or, perhaps the
    dialogue is helping them reach their own conclusion.  I do not
    know.  Regardless, most people have been silent on this issue.

    I would like one of the proponents  for removing the requirement to
suggest
    alternative text, and I would like to hear from more people about the
    proposed revision.

    We are in Working Group Last Call.  I would like to reach consensus on
this
    issue, make the necessary change (if any), and get the document to the
    IESG.  Many other working groups are waiting for our document.

    Russ


------=_NextPart_000_0000_01C0CBE0.156A3A50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: delta-CRLs (was Re: Last =
Call:draft-ietf-pkix-new-part1-06.txt comments)</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>Russ=20
and Sharon,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>X.509=20
Ed. 4 draft v6 says in section 9&nbsp; "A dCRL may also be an indirect =
CRL=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>in=20
that it may contain updated revocation information related to base CRLs=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>issued=20
by one or more than one authorities."</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>In=20
this case in order to comply with the current PKIX profile requirement=20
below,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>the CA=20
that issued the dCRL would also have to issue a full indirect CRL=20
for</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>all=20
the authorities whose CRLs were updated by the dCRL.&nbsp; That much I=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001>understand, I =
think.&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D730544716-23042001>
<P><FONT size=3D2><FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
class=3D730544716-23042001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
Current PKIX profile requirement:&nbsp; </SPAN>"When a conforming CA=20
issues&nbsp;</FONT></FONT><BR><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
class=3D730544716-23042001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
</SPAN>a delta CRL, </FONT><FONT face=3DArial></FONT><FONT=20
color=3D#0000ff></FONT><FONT size=3D2>the CA MUST also issue a CRL that =
is complete=20
for&nbsp;<BR><SPAN=20
class=3D730544716-23042001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
</SPAN>the given scope."</FONT></FONT></FONT></P></SPAN></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>But=20
I'm puzzled by another point.&nbsp; &nbsp;It looks to me like X.509 =
permits a=20
dCRL</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>to=20
contain a crlScope extension that limits the scope of the certificates=20
for</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>which=20
the dCRL is authoritative (using onlyContains or=20
onlySomeReasons,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>for=20
instance).&nbsp; In fact, it seems that different CA's could issue =
indirect=20
dCRLs</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>for=20
various scopes (e.g. user certificate, attribute certificate,=20
keyCompromise,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001>certificateHold, etc.), but reference a base =
CRL that=20
covers a larger scope.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>In=20
that case, I suppose each of the dCRL issuers must</SPAN></FONT><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN class=3D730544716-23042001> =
also=20
issue</SPAN></FONT><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001> a "full CRL".&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>But=20
what constitutes&nbsp;a full&nbsp;"CRL that is complete for<SPAN=20
class=3D730544716-23042001> </SPAN>the given scope."?&nbsp; Is=20
it</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>the=20
given scope of the dCRL, or the given scope of the base CRL?&nbsp; That =
is,=20
does</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>each=20
"full CRL"&nbsp;cover only the scope of the dCRL, even if the dCRL's =
base=20
CRL</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>covers=20
additional scope (e.g. additional reason codes, or additional=20
certificate</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001>types)?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D730544716-23042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D730544716-23042001>
<P><FONT=20
size=3D2>Regards,<BR><BR>Carlin<BR><BR>____________________________<BR><B=
R>-&nbsp;=20
Carlin Covey<BR>&nbsp;&nbsp; Cylink Corporation =
</FONT></P></SPAN></FONT></DIV>
<DIV><SPAN class=3D730544716-23042001>
<P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D730544716-23042001></SPAN></FONT></FONT></FONT>&nbsp;</P></SPAN><=
/DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, April 23, =
2001 9:40=20
  AM<BR><B>To:</B> Santosh Chokhani; Russ Housley;=20
  [e-mail]<BR><B>Subject:</B> RE: delta-CRLs (was Re: Last=20
  Call:draft-ietf-pkix-new-part1-06.tx t comments)<BR><BR></DIV></FONT>
  <DIV><SPAN class=3D229484416-23042001><FONT color=3D#0000ff =
face=3DArial size=3D2>I=20
  agree with Santosh. Forcing the issuance of a full CRL each time a =
delta is=20
  issued removes the primary value of issuing the delta in the first=20
  place.</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani =

    [mailto:[e-mail]]<BR><B>Sent:</B> Monday, April 23, =
2001 11:45=20
    AM<BR><B>To:</B> Russ Housley; [e-mail]<BR><B>Subject:</B> =
RE:=20
    delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t=20
    comments)<BR><BR></FONT></DIV>
    <P><FONT size=3D2>I have been quite on this.&nbsp; I am firmly in =
favor of NOT=20
    having the requirement (i.e., delete the requirement): "CA post a =
full CRL=20
    whenever a delta CRL is issued".</FONT></P>
    <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
    Russ Housley [<A=20
    =
href=3D"mailto:[e-mail]">mailto:[e-mail]<=
/A>]</FONT>=20
    <BR><FONT size=3D2>Sent: Monday, April 23, 2001 10:27 AM</FONT> =
<BR><FONT=20
    size=3D2>To: [e-mail]</FONT> <BR><FONT size=3D2>Subject: =
RE: delta-CRLs=20
    (was Re: Last</FONT> <BR><FONT =
size=3D2>Call:draft-ietf-pkix-new-part1-06.txt=20
    comments)</FONT> </P><BR>
    <P><FONT size=3D2>All:</FONT> </P>
    <P><FONT size=3D2>Trevor, Ambarish, Denis, David, and others have =
proposed the=20
    removal of the </FONT><BR><FONT size=3D2>requirement that CAs post a =
full CRL=20
    whenever a delta-CRL is </FONT><BR><FONT size=3D2>posted.&nbsp; =
Trevor's=20
    suggestion that the consequences of a CA posting a </FONT><BR><FONT=20
    size=3D2>delta-CRL without posting a full CRL could be discussed in =
a single=20
    </FONT><BR><FONT size=3D2>paragraph in the Security Considerations=20
    section.</FONT> </P>
    <P><FONT size=3D2>Paul and Mike have suggested that the current text =
is=20
    fine.</FONT> </P>
    <P><FONT size=3D2>A few people have contributed to the thread but =
not made=20
    their own position </FONT><BR><FONT size=3D2>clear.&nbsp; Perhaps =
they are=20
    only academically interested.&nbsp; Or, perhaps the </FONT><BR><FONT =

    size=3D2>dialogue is helping them reach their own conclusion.&nbsp; =
I do not=20
    </FONT><BR><FONT size=3D2>know.&nbsp; Regardless, most people have =
been silent=20
    on this issue.</FONT> </P>
    <P><FONT size=3D2>I would like one of the proponents&nbsp; for =
removing the=20
    requirement to suggest </FONT><BR><FONT size=3D2>alternative text, =
and I would=20
    like to hear from more people about the </FONT><BR><FONT =
size=3D2>proposed=20
    revision.</FONT> </P>
    <P><FONT size=3D2>We are in Working Group Last Call.&nbsp; I would =
like to=20
    reach consensus on this </FONT><BR><FONT size=3D2>issue, make the =
necessary=20
    change (if any), and get the document to the </FONT><BR><FONT=20
    size=3D2>IESG.&nbsp; Many other working groups are waiting for our=20
    document.</FONT> </P>
    <P><FONT size=3D2>Russ =
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0000_01C0CBE0.156A3A50--



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA09751 for <[e-mail]>; Mon, 23 Apr 2001 10:32:59 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2LAW5446; Mon, 23 Apr 2001 10:28:09 -0700
From: "Carlin Covey" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last  Call:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Mon, 23 Apr 2001 10:28:02 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Russ,

Two obvious candidates for alternative text are (1)
substituting MAY for MUST and (2) substituting SHOULD
for MUST in the sentence:

"A dCRL may also be an indirect CRL in that it may
contain updated revocation information related to
base CRLs issued by one or more than one authorities."

I think that these alternative wordings have been
either stated or implied by various persons in the
course of this discussion.

Were you asking for some alternative text to go
into the security considerations section?

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation



-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Monday, April 23, 2001 7:27 AM
To: [e-mail]
Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)


All:

Trevor, Ambarish, Denis, David, and others have proposed the removal of the
requirement that CAs post a full CRL whenever a delta-CRL is
posted.  Trevor's suggestion that the consequences of a CA posting a
delta-CRL without posting a full CRL could be discussed in a single
paragraph in the Security Considerations section.

Paul and Mike have suggested that the current text is fine.

A few people have contributed to the thread but not made their own position
clear.  Perhaps they are only academically interested.  Or, perhaps the
dialogue is helping them reach their own conclusion.  I do not
know.  Regardless, most people have been silent on this issue.

I would like one of the proponents  for removing the requirement to suggest
alternative text, and I would like to hear from more people about the
proposed revision.

We are in Working Group Last Call.  I would like to reach consensus on this
issue, make the necessary change (if any), and get the document to the
IESG.  Many other working groups are waiting for our document.

Russ



Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA09304 for <[e-mail]>; Mon, 23 Apr 2001 10:29:46 -0700 (PDT)
Received: from 157.54.7.67 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Apr 2001 16:08:40 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 19 Apr 2001 16:08:39 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 19 Apr 2001 16:08:33 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Apr 2001 16:08:14 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Help Sought on Netscape Revocation URL causing MS Programs to hang
Date: Thu, 19 Apr 2001 16:08:14 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Help Sought on Netscape Revocation URL causing MS Programs to hang
Thread-Index: AcDJGN3ODRDWl9AjS+SNpRkqttZ4WgADIGhw
From: "Trevor Freeman" <[e-mail]>
To: "Ron Segal" <[e-mail]>, "David Cross" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 19 Apr 2001 23:08:14.0536 (UTC) FILETIME=[9CA44C80:01C0C925]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA09305

Hi Ron
Sorry for the confusion, it is fixed in Windows XP. Revocation handling
is done as part of CryptoAPI which is an OS component.
Trevor

-----Original Message-----
From: Ron Segal [mailto:[e-mail]] 
Sent: Thursday, April 19, 2001 2:32 PM
To: David Cross
Cc: [e-mail]
Subject: RE: Help Sought on Netscape Revocation URL causing MS Programs
to hang

Hi David

Thanks for your offer to checkout the certificate chain.

Actually a clear explanation has now been offered by free Microsoft
support(unexpectedly rapid and knowedgable service I might add,
particularly
as it was a free web query).

It seems that if the revocation check itself is to a secure server
(https)
and the server certificate itself has a Nescape revocation extension a
recursive revocation process can occur.  Microsoft are providing a
partial
fix for this in their new version of Office (XP) by detecting the
recursion
and halting the process.  If this happens the revocation check will fail
to
provide revocation status. The optimum solution is to remove the
Netscape
revocation extension from the server certificate.

I'm copying this to the list so that others will see that the problem
has
been 'solved', and the solution (please note server cert providers!).

Hope that I did not miss any messages and personally thanked everybody
who
responded, at least that was the intention.

Very best regards

Ron


--------------
Ron Segal
Business Development Manager
Baycorp ID Services Ltd
PO Box 5052, Wellington, New Zealand

Mailto: [e-mail]
Tel:   +64 (9)  356 5801
DD:    +64 (4)  499 4261
Mob:   [phone]
Fax:   +64 (9)  356 5818
Web:   http://www.baycorpid.com


If you received a warning on reading this email, please go to
<http://www.baycorpid.com/settings/email.asp> to update your settings


-----Original Message-----
From: David Cross [mailto:[e-mail]]
Sent: Friday, 20 April 2001 1:39 a.m.
To: Ron Segal; [e-mail]
Subject: RE: Help Sought on Netscape Revocation URL causing MS Programs
to hang


I will pass on the job offer, but have you verified that the URLs are
valid that are listed in the certificate?  If the URLs are no longer
valid or cannot be reached, that might explain the behaviour.  If you
want to send me the certificate chain (privately), we can take a look at
it.

David B. Cross






-----Original Message-----
From: Ron Segal [mailto:[e-mail]]
Sent: Wednesday, April 18, 2001 6:59 PM
To: [e-mail]
Subject: Help Sought on Netscape Revocation URL causing MS Programs to
hang


Hi Folks

If an X.509 v3 certificate contains a proprietary NetscapeRevocationURL
extension and a Microsoft program (eg email or browser) is configured to
do automatic CRL Distribution Point Checking, then the Microsoft program
will hang and timeout after about 5 minutes.

Does anybody know of a fix for this problem, e.g. a registry
configuration (no cynicism please!)?

We are aware that if a cert has both the NetscapeRevocationURL and CRL
Distribution Point extensions, then no problem.

Your help would be greatly appreciated (and maybe you can get a job at
Baycorp!).

Very best regards

Ron

--------------
Ron Segal
Business Development Manager
Baycorp ID Services Ltd
PO Box 5052, Wellington, New Zealand

Mailto: [e-mail]
Tel:   +64 (4)  499 4231
DD:    +64 (4)  499 4261
Mob:   [phone]
Fax:   +64 (4)  499 4233
Web:   http://www.baycorpid.com


Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA07689 for <[e-mail]>; Mon, 23 Apr 2001 10:13:49 -0700 (PDT)
Received: from 157.54.1.52 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Apr 2001 12:05:03 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 19 Apr 2001 12:04:41 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 19 Apr 2001 12:04:40 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Apr 2001 12:04:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta-CRLs (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)
Date: Thu, 19 Apr 2001 12:04:21 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta-CRLs (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)
Thread-Index: AcDI8KODVvZPt6HORo+9Zb6/i68QYQAEKVLw
From: "Trevor Freeman" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 19 Apr 2001 19:04:21.0620 (UTC) FILETIME=[8ABE8340:01C0C903]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA07697

David,
You are absolutely right that this is a mater of policy on the part of
the CA operator, so why mandate this in the RFC. There is no equivalent
policy that states republish a CRL if you publish new information via
OCSP. OCSP client may well get more up-to-date information but I don't
see a mass of protests from the CRL aware clients.
We have also found that publishing a base and delta simultaneously with
the same CRL number causes problems where you have replicated
distribution points. With replicated distribution mechanisms, there is
no guarantee that both objects replicate together, which means you end
up in a race condition as to which CRL replicates to a given location.
If the base makes it to a given location first, all is well, but it the
delta wins, you get an error since the delta now points to a base which
the client cannot obtain from the same location. Unfortunately, with
bandwidth restricted networks, administers frequently allow small
updates through more frequently, preferring large update to be batched
to an off-peak hour typically resulting in a no-contest as to which CRL
replicates first.
Trevor

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]] 
Sent: Thursday, April 19, 2001 9:48 AM
To: [e-mail]
Subject: delta-CRLs (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt
comments)

Denis,

There seems to be some confusion about the way that delta-CRLs work. I
will try to clarify things with my responses in-line below.

At 05:32 PM 4/19/01 +0200, Denis Pinkas wrote:
>In the third paragraph the first sentence (still) says:
>
>    When a conforming CA issues a delta CRL, the CA MUST also issue a
CRL

I must admit that I am not a big fan of this requirement. From my point
of view, there are both advantages and disadvantages to issuing a full
CRL whenever a delta-CRL is issued. The advantage is that clients that
can not process delta-CRLs can always obtain the same status information
as those than can process delta-CRLs. The disadvantage is that it
imposes a burden of uploading full CRLs to repositories more often than
may be necessary. On the other hand, just because the CA issues the full
CRLs, this does not mean that clients must retrieve them.

In the end, though, it is mostly a policy decision. If you want to
provide the same support to clients that can not process delta-CRLs as
to those that can, you must issue a full CRL whenever you issue a
delta-CRL. I think the decision should be left to CRL issuers, but will
not complain if PKIX remains as it is.

>3) The text says:
>
>    An application can construct a CRL that is complete for a given
>    scope, at the current time, in either of the following ways:
>
>       (a) by retrieving the current delta CRL for that scope, and
>       combining it with an issued CRL that is complete for that scope
>       and that has a cRLNumber greater than or equal to the cRLNumber
of
>       the base CRL referenced in the delta CRL; or
>
>       (b) by retrieving the current delta CRL for that scope and
>       combining it with a locally constructed CRL whose cRLNumber is
>       greater than or equal to the cRLNumber of the base CRL
referenced
>       in the current delta CRL.
>
>  a) It is hard to understand in which case the base CRL may have a 
>     cRLNumber *greater than* the cRLNumber of the base CRL referenced 
>     in the delta CRL. I certainly miss something here. The equality
case
>     is easy to understand. The "greater than" case is much harder. 
>     Is it really needed ?
>
>  b) the case of a locally constructed CRL is quite stange and it is 
>     questionnable why this case is being mentioned. In the following
fix, 
>     that case has been deleted.

If you want a detailed description on this, you could read my paper on
delta-CRLs, http://csrc.nist.gov/pki/documents/sliding_window.pdf, but
I'll try to briefly explain here.

Suppose that delta-CRLs are issued once an hour. For example, suppose
that a base CRL, CRL number 5, was issued at midnight and that every
hour for the next 24 hours, delta-CRLs were issued with a BaseCRLNumber
of 5. If a relying party performs its first validation at 3:10am, it
would the full CRL issued at midnight and the delta-CRL issued at 3:00am
(CRL number 8). It would combine these to construct full CRL number 8.
In this case, the CRL number of the full CRL used in combination with
the delta-CRL would be the same as the BaseCRLNumber in that delta-CRL.

A few hours later, at 6:30am, the relying party performs another
validation. The relying party has, in its local cache, the contents of
CRL number 8 (which it constructed at 3:10am). It wants to update the
information in its local case to based on the newly available revocation
information. So, it obtains the latest delta-CRL. This delta-CRL has a
CRL number of 11 and a BaseCRLnumber of 5. Since it has a BaseCRLNumber
of 5, the delta-CRL provides status information for all certificates
whose status has changed since CRL number 5 was issued. (midnight). So,
clearly the delta-CRL provides status information for all certificates
whose status has changed since 3:00am when CRL number 8 was issued.
Thus, the relying party can combine the delta-CRL with its locally
cached version of full CRL number 8 to obtain the contents of CRL number
11. This is a case where the CRL number of the complete CRL used is
greater than the BaseCRLNumber specified in the delta-CRL.

There are other reasons why the two numbers may not match, but I will
not go into them. If you are interested, you can read my paper.

>Finally we should explain what happens at the boundaries, i.e. when a
CA
>decides to generate a (new) base CRL. Here is a text proposal:
>
>   When issuing a base CRL that supports a delta-CRL mechanism then the

>   CRL Issuer MUST at the same time issue a delta CRL that points to
that 
>   base CRL. This first delta CRL will usually be empty (or will
include 
>   last-minute additions to the base CRL).

This is not acceptable. The rule is that when a base CRL is issued a
delta-CRL must be issued that has the same cRLNumber. The base CRL
referenced by the delta must either be the previously issued base CRL or
a base CRL issued before that one. Since the new base and the delta must
have the same cRLNumber, there can be no differences as a result of
"last-minute additions to the base CRL".

>Suppose we issue a base CRL every midnight. The question is whether we
>should issue a delta and, if yes, does this delta refer to the previous
>base or to the new one ?

The delta must refer either to the previous base or a base issued before
the previous base.

>Suppose it refers to the previous one. According to the current
sentence:
>"The constructed CRL has the CRL number specified in the CRL number
>extension found in the delta CRL used in its construction.", it is
>impossible. If that was the case the delta CRL would have a CRL number
equal
>to the base CRL and it is not allowed for two CRLs to have the same CRL
>number.

I think you are confusing two different extensions. The
deltaCRLIndicator extension contains a BaseCRLNumber which is used to
determine against which base CRLs the delta-CRL can be applied. The
cRLNumber extension specifies the CRL number of the full CRL that will
be generated by applying the delta-CRL to a base CRL. The sentence above
states that the CRL number of the constructed CRL is taken from the
cRLNumber extension, not the BaseCRLNumber of the deltaCRLIndicator
extension.





Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA06292 for <[e-mail]>; Mon, 23 Apr 2001 09:52:50 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA14111 for <[e-mail]>; Mon, 23 Apr 2001 12:52:22 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Mon, 23 Apr 2001 12:50:32 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt   comments)
References: <[e-mail]> <p0510080eb70895081561@[192.168.1.13]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul,

I'll refer you to Russ' message of Jan 18 "Re: Two questions on delta-CRL":

  "I think we may be splitting hairs on the term "issue". I am not
   sure that I would consider a CRL that was generated but not
   distributed to be "issued".

The problem is not that it is too burdensome for a CA to have a cron job
that sweeps the database and signs a full CRL every time it signs a delta.
The problem is that once the full CRL is signed, it is transmitted across
the network to directory/database/repository replicas and to clients.
If you are a PKI provider (as I am), and you have to provision 3.5
million subscribers, the cost of that provisioning with full CRLs is
prohibitive, whereas the cost of provisioning with deltas is not.

If Russ (i.e. the PKIX WG) would make a clear statement that "issue"
means "sign and place in one repository", vice "sign and distribute
to all RPs", then I would have no problem with the current MUST
requirement.  But if a CRL is not deemed to be "issued" unless it is
available to all, then I strongly agree with Trevor, David Cross, and
Ambarish that the requirement to "issue" a full CRL for every delta
must be relaxed.

Dave K




Paul Hoffman / IMC wrote:
> 
> At 6:03 PM -0700 4/21/01, Ambarish Malpani wrote:
> >Russ, the problem with this is that CAs might be unwilling to issue
> >delta-CRLs because issuing a full CRL every time is too
> >burdensome.
> 
> Could you describe how it is "too burdensome"? Maybe I'm being naive,
> not being a CA, but asking a CA to sign a second document (the full
> CRL) at the time that it signs the first document (the delta-CRL)
> really doesn't seem that onerous.
> 
> I think the current requirement is fine.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA05856 for <[e-mail]>; Mon, 23 Apr 2001 09:49:28 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3NGnNd04835; Mon, 23 Apr 2001 09:49:24 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Mon, 23 Apr 2001 09:47:57 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

Santosh,

I disagree.  I remain concerned about divergence from the standard database
maintenance practice of producing a "full" and a set of "deltas".  Towards
support of non-repudiation, I would expect that most who wish to make a case
on the basis of CRLs would prefer to make their case on the basis of a full
CRL.

At issue I believe is the notion that one MUST produce a full CRL every time
a delta is produced.  I suggest that this lock-step production process does
indeed needlessly impact enterprise infrastructures as Trevor observed.

Russ, I propose as a middle ground text establishing that:

1. full CRLs are a SHALL in all cases, thus contributing to
interoperability;

2. that the periods of production of a full CRL and its corresponding deltas
MAY be identical, thus yeilding the intent of the current text; but

4. when practiced, the production of deltas SHALL at a minimum be less than
that of the period of production of the corresponding full CRL, thus
enabling systems-level tuning to achieve a locally acceptable balance
between timeliness, effective non-repudiation support, generally accepted
database maintainence principles and infrastructure overhead.

And of course, deltas are a MAY.

I'll write this up as a drop-in to the current text depending on how
consensus flows on the proposal.

Mike


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Monday, April 23, 2001 8:45 AM
To: Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt
comments)


I have been quite on this.  I am firmly in favor of NOT having the
requirement (i.e., delete the requirement): "CA post a full CRL whenever a
delta CRL is issued".
-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Monday, April 23, 2001 10:27 AM
To: [e-mail]
Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)


All:
Trevor, Ambarish, Denis, David, and others have proposed the removal of the
requirement that CAs post a full CRL whenever a delta-CRL is
posted.  Trevor's suggestion that the consequences of a CA posting a
delta-CRL without posting a full CRL could be discussed in a single
paragraph in the Security Considerations section.
Paul and Mike have suggested that the current text is fine.
A few people have contributed to the thread but not made their own position
clear.  Perhaps they are only academically interested.  Or, perhaps the
dialogue is helping them reach their own conclusion.  I do not
know.  Regardless, most people have been silent on this issue.
I would like one of the proponents  for removing the requirement to suggest
alternative text, and I would like to hear from more people about the
proposed revision.
We are in Working Group Last Call.  I would like to reach consensus on this
issue, make the necessary change (if any), and get the document to the
IESG.  Many other working groups are waiting for our document.
Russ



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA05436 for <[e-mail]>; Mon, 23 Apr 2001 09:45:58 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JPVNW4D7>; Mon, 23 Apr 2001 12:45:29 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: Santosh Chokhani <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t  comments)
Date: Mon, 23 Apr 2001 12:39:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CC14.04EFF1E0"

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_01C0CC14.04EFF1E0
Content-Type: text/plain;
	charset="iso-8859-1"

I agree with Santosh. Forcing the issuance of a full CRL each time a delta
is issued removes the primary value of issuing the delta in the first place.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Monday, April 23, 2001 11:45 AM
To: Russ Housley; [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t
comments)



I have been quite on this.  I am firmly in favor of NOT having the
requirement (i.e., delete the requirement): "CA post a full CRL whenever a
delta CRL is issued".

-----Original Message----- 
From: Russ Housley [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Monday, April 23, 2001 10:27 AM 
To: [e-mail] 
Subject: RE: delta-CRLs (was Re: Last 
Call:draft-ietf-pkix-new-part1-06.txt comments) 


All: 

Trevor, Ambarish, Denis, David, and others have proposed the removal of the 
requirement that CAs post a full CRL whenever a delta-CRL is 
posted.  Trevor's suggestion that the consequences of a CA posting a 
delta-CRL without posting a full CRL could be discussed in a single 
paragraph in the Security Considerations section. 

Paul and Mike have suggested that the current text is fine. 

A few people have contributed to the thread but not made their own position 
clear.  Perhaps they are only academically interested.  Or, perhaps the 
dialogue is helping them reach their own conclusion.  I do not 
know.  Regardless, most people have been silent on this issue. 

I would like one of the proponents  for removing the requirement to suggest 
alternative text, and I would like to hear from more people about the 
proposed revision. 

We are in Working Group Last Call.  I would like to reach consensus on this 
issue, make the necessary change (if any), and get the document to the 
IESG.  Many other working groups are waiting for our document. 

Russ 


------_=_NextPart_001_01C0CC14.04EFF1E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt comments)</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=229484416-23042001><FONT face=Arial color=#0000ff size=2>I 
agree with Santosh. Forcing the issuance of a full CRL each time a delta is 
issued removes the primary value of issuing the delta in the first 
place.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, April 23, 2001 11:45 
  AM<BR><B>To:</B> Russ Housley; [e-mail]<BR><B>Subject:</B> RE: 
  delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t 
  comments)<BR><BR></FONT></DIV>
  <P><FONT size=2>I have been quite on this.&nbsp; I am firmly in favor of NOT 
  having the requirement (i.e., delete the requirement): "CA post a full CRL 
  whenever a delta CRL is issued".</FONT></P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Russ 
  Housley [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>Sent: Monday, April 23, 2001 10:27 AM</FONT> <BR><FONT 
  size=2>To: [e-mail]</FONT> <BR><FONT size=2>Subject: RE: delta-CRLs 
  (was Re: Last</FONT> <BR><FONT size=2>Call:draft-ietf-pkix-new-part1-06.txt 
  comments)</FONT> </P><BR>
  <P><FONT size=2>All:</FONT> </P>
  <P><FONT size=2>Trevor, Ambarish, Denis, David, and others have proposed the 
  removal of the </FONT><BR><FONT size=2>requirement that CAs post a full CRL 
  whenever a delta-CRL is </FONT><BR><FONT size=2>posted.&nbsp; Trevor's 
  suggestion that the consequences of a CA posting a </FONT><BR><FONT 
  size=2>delta-CRL without posting a full CRL could be discussed in a single 
  </FONT><BR><FONT size=2>paragraph in the Security Considerations 
  section.</FONT> </P>
  <P><FONT size=2>Paul and Mike have suggested that the current text is 
  fine.</FONT> </P>
  <P><FONT size=2>A few people have contributed to the thread but not made their 
  own position </FONT><BR><FONT size=2>clear.&nbsp; Perhaps they are only 
  academically interested.&nbsp; Or, perhaps the </FONT><BR><FONT 
  size=2>dialogue is helping them reach their own conclusion.&nbsp; I do not 
  </FONT><BR><FONT size=2>know.&nbsp; Regardless, most people have been silent 
  on this issue.</FONT> </P>
  <P><FONT size=2>I would like one of the proponents&nbsp; for removing the 
  requirement to suggest </FONT><BR><FONT size=2>alternative text, and I would 
  like to hear from more people about the </FONT><BR><FONT size=2>proposed 
  revision.</FONT> </P>
  <P><FONT size=2>We are in Working Group Last Call.&nbsp; I would like to reach 
  consensus on this </FONT><BR><FONT size=2>issue, make the necessary change (if 
  any), and get the document to the </FONT><BR><FONT size=2>IESG.&nbsp; Many 
  other working groups are waiting for our document.</FONT> </P>
  <P><FONT size=2>Russ </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0CC14.04EFF1E0--


Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA05122 for <[e-mail]>; Mon, 23 Apr 2001 09:42:57 -0700 (PDT)
Received: from 157.54.9.104 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Apr 2001 09:48:03 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 20 Apr 2001 09:47:52 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 20 Apr 2001 09:47:49 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 20 Apr 2001 09:47:29 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Dedicated CRL signing keys
Date: Fri, 20 Apr 2001 09:47:29 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Dedicated CRL signing keys
Thread-Index: AcDJk6thX8qCXM1HQVisS3uy1oP/SgAJQhfg
From: "Trevor Freeman" <[e-mail]>
To: "Nada Kapidzic Cicovic" <[e-mail]>, "Bengt Ohlsson" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 20 Apr 2001 16:47:29.0989 (UTC) FILETIME=[96A4CF50:01C0C9B9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA05123

Mandating SKI and AKI changes nothing as these are just hints as to
which key signed. The client are already failing since they cannot find
the right public key that signed the CRL. As you not, it is possible to
have CA with multiple keys, so having a different AKI in the CRL may
simply indicate a problem with distribution.

-----Original Message-----
From: Nada Kapidzic Cicovic [mailto:[e-mail]] 
Sent: Friday, April 20, 2001 5:13 AM
To: Trevor Freeman; Bengt Ohlsson; Russ Housley
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys

Would it not be easier to mandate the support for Authority and Subject
key 
identifiers, than to require the CA to use different DNs when different 
keys are used for issuing certificates and CRLs. As Tim noted, this
problem 
may occur even for regular CAs (which use the same key for issuing 
certificates and CRLs) after a key pair rollover.

At 09:29 AM 4/19/01 -0700, Trevor Freeman wrote:
>Bengt,
>Theorizing what could be possible, do not change that support for these
>semantics is not mandatory under this profile, which means we are
trying
>to establish how that client fails gracefully with some kind of
>meaningful error

I agree with Bengt that key identifier extensions provide enough 
information for the client to go looking for the right cert path to
perform 
the verification of the signature on the CRL. If the client is not able
to 
locate the proper path it can fail with a meaningful error.

Nada

>Trevor
>-----Original Message-----
>From: Bengt Ohlsson [mailto:[e-mail]]
>Sent: Thursday, April 19, 2001 8:10 AM
>To: Trevor Freeman; Russ Housley
>Cc: [e-mail]
>Subject: RE: Dedicated CRL signing keys
>
>Trevor and Russ,
>
>I don't see why the clients should fail to verify the signature
>on the CRL. Assume a CA uses separate keys, same DN,
>for certificate signing and CRL signing and sets the
>AuthorityKeyIdentifier extension in both the certificates
>and the CRLs. Then PKIX compliant clients should be able
>to build the correct certificate chains for verifying both the
>certificates and the CRLs.
>
>The legislation may require the CA keys to be stored in
>hardware without any copies. If you lose a key due to HW
>failure you will probaly want to continue to issue the CRLs
>with a new key and the same DN.
>
>This requires the clients to handle the AKI extension to be
>able to verify the signature on the new CRLs. This is a
>small requirement compared to handle indirect CRLs if
>you must change the DN.
>
>Bengt
>
>-----Original Message-----
>From: Trevor Freeman [mailto:[e-mail]]
>Sent: den 19 april 2001 01:40
>To: Russ Housley
>Cc: [e-mail]
>Subject: RE: Dedicated CRL signing keys
>
>
>Hi Russ,
>That addresses my concerns. A pkix compliant client can now be
>reasonability expected to fail with a more informative error, and the
>problem should be in people's faces since the CRL contains a critical
>extension.
>Trevor
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Wednesday, April 18, 2001 2:08 PM
>To: Trevor Freeman
>Cc: [e-mail]
>Subject: Re: Dedicated CRL signing keys
>
>Trevor:
>
>I propose the following solution that builds on the Indirect CRL
>capabilities that are already available.  When a CA wants to employ
>separate private keys to sign certificates and CRLs, then that CA MUST
>delegate CRL signing to a separate authority.  That separate authority
>MUST
>have a different Distinguished Name that the CA, but it could be
>operated
>by the same organization.  In this way, the IDP CRL extension would
flag
>
>the "unusual" circumstances.  Clients that do not support Indirect CRLs
>can
>fail gracefully (unsupported optional feature), and clients that
support
>
>Indirect CRLs can happily handle the certificates and CRLs.
>
>Thoughts?
>
>Russ
>
>At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
> >There has been some discussion regarding the proposal to have CRLs
> >signed with CA keys which do not also sign certificates. Since this
>will
> >not be a mandatory to implement feature, I am concerned about the
>impact
> >on pkix compliant clients who encounter CRL signed in this way, and
how
> >we expect them to behave. What seem unacceptable with the current
> >proposal is that the signage check on the CRL will fail, and the
client
> >will have little clue as to why and if this failure is expected. The
> >information in the chain, while present, is in the CAs certificate,
is
> >difficult to find and subtle so would be easily missed by someone
> >debugging this problem. I would like to see some clearer indication
in
>a
> >critical extension in the CRL itself that would indicate what was
going
> >on. In expressing these semantics in a critical extension, we
maintain
> >the principal that if you don't understand the extension, the client
> >knows to fail due to its own inadequacies and that failure is by
>design,
> >therefore allowing the client's to return an error unsupported option
> >rather than invalid signature.
> >Trevor



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02043 for <[e-mail]>; Mon, 23 Apr 2001 08:54:53 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JPVNWTL8>; Mon, 23 Apr 2001 11:54:19 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Russ Housley <[e-mail]>, [e-mail]
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t  comments)
Date: Mon, 23 Apr 2001 11:45:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CC0C.6C644B80"

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_01C0CC0C.6C644B80
Content-Type: text/plain;
	charset="iso-8859-1"

I have been quite on this.  I am firmly in favor of NOT having the
requirement (i.e., delete the requirement): "CA post a full CRL whenever a
delta CRL is issued".

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Monday, April 23, 2001 10:27 AM
To: [e-mail]
Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)


All:

Trevor, Ambarish, Denis, David, and others have proposed the removal of the 
requirement that CAs post a full CRL whenever a delta-CRL is 
posted.  Trevor's suggestion that the consequences of a CA posting a 
delta-CRL without posting a full CRL could be discussed in a single 
paragraph in the Security Considerations section.

Paul and Mike have suggested that the current text is fine.

A few people have contributed to the thread but not made their own position 
clear.  Perhaps they are only academically interested.  Or, perhaps the 
dialogue is helping them reach their own conclusion.  I do not 
know.  Regardless, most people have been silent on this issue.

I would like one of the proponents  for removing the requirement to suggest 
alternative text, and I would like to hear from more people about the 
proposed revision.

We are in Working Group Last Call.  I would like to reach consensus on this 
issue, make the necessary change (if any), and get the document to the 
IESG.  Many other working groups are waiting for our document.

Russ 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: delta-CRLs (was Re: Last =
Call:draft-ietf-pkix-new-part1-06.txt  comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I have been quite on this.&nbsp; I am firmly in favor =
of NOT having the requirement (i.e., delete the requirement): &quot;CA =
post a full CRL whenever a delta CRL is issued&quot;.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Russ Housley [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 23, 2001 10:27 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: delta-CRLs (was Re: Last</FONT>
<BR><FONT SIZE=3D2>Call:draft-ietf-pkix-new-part1-06.txt =
comments)</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>Trevor, Ambarish, Denis, David, and others have =
proposed the removal of the </FONT>
<BR><FONT SIZE=3D2>requirement that CAs post a full CRL whenever a =
delta-CRL is </FONT>
<BR><FONT SIZE=3D2>posted.&nbsp; Trevor's suggestion that the =
consequences of a CA posting a </FONT>
<BR><FONT SIZE=3D2>delta-CRL without posting a full CRL could be =
discussed in a single </FONT>
<BR><FONT SIZE=3D2>paragraph in the Security Considerations =
section.</FONT>
</P>

<P><FONT SIZE=3D2>Paul and Mike have suggested that the current text is =
fine.</FONT>
</P>

<P><FONT SIZE=3D2>A few people have contributed to the thread but not =
made their own position </FONT>
<BR><FONT SIZE=3D2>clear.&nbsp; Perhaps they are only academically =
interested.&nbsp; Or, perhaps the </FONT>
<BR><FONT SIZE=3D2>dialogue is helping them reach their own =
conclusion.&nbsp; I do not </FONT>
<BR><FONT SIZE=3D2>know.&nbsp; Regardless, most people have been silent =
on this issue.</FONT>
</P>

<P><FONT SIZE=3D2>I would like one of the proponents&nbsp; for removing =
the requirement to suggest </FONT>
<BR><FONT SIZE=3D2>alternative text, and I would like to hear from more =
people about the </FONT>
<BR><FONT SIZE=3D2>proposed revision.</FONT>
</P>

<P><FONT SIZE=3D2>We are in Working Group Last Call.&nbsp; I would like =
to reach consensus on this </FONT>
<BR><FONT SIZE=3D2>issue, make the necessary change (if any), and get =
the document to the </FONT>
<BR><FONT SIZE=3D2>IESG.&nbsp; Many other working groups are waiting =
for our document.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C0CC0C.6C644B80--


Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA01604 for <[e-mail]>; Mon, 23 Apr 2001 08:52:00 -0700 (PDT)
Received: from checkpoint.local.aus.rsa.com by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Apr 2001 15:48:33 UT
Received: (private information removed)
Received: (private information removed)
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.4 [10.3.1.4]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HK1A3MZ6; Mon, 23 Apr 2001 11:50:54 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 23 Apr 2001 10:27:15 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
In-Reply-To: <[e-mail] .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

All:

Trevor, Ambarish, Denis, David, and others have proposed the removal of the 
requirement that CAs post a full CRL whenever a delta-CRL is 
posted.  Trevor's suggestion that the consequences of a CA posting a 
delta-CRL without posting a full CRL could be discussed in a single 
paragraph in the Security Considerations section.

Paul and Mike have suggested that the current text is fine.

A few people have contributed to the thread but not made their own position 
clear.  Perhaps they are only academically interested.  Or, perhaps the 
dialogue is helping them reach their own conclusion.  I do not 
know.  Regardless, most people have been silent on this issue.

I would like one of the proponents  for removing the requirement to suggest 
alternative text, and I would like to hear from more people about the 
proposed revision.

We are in Working Group Last Call.  I would like to reach consensus on this 
issue, make the necessary change (if any), and get the document to the 
IESG.  Many other working groups are waiting for our document.

Russ 


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA26083 for <[e-mail]>; Mon, 23 Apr 2001 08:29:27 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA13888; Mon, 23 Apr 2001 17:29:03 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA18686; Mon, 23 Apr 2001 17:28:50 +0200
Message-ID: <[e-mail]>
Date: Mon, 23 Apr 2001 17:28:56 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt   comments)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,


This is a LONG e-mail and a last e-mail to you, before leaving for a trip
that will keep me away from my e-mails during a week. So, don't think I am
giving up if you do not receive a reply soon.

> Denis,
> 
> My comments are in line.
> 
> At 06:50 PM 4/20/01 +0200, Denis Pinkas wrote:
> >[Denis] This is the case I had in mind. However I would disagree to say that
> >the locally contructed CRL is equal to the full CRL number 8, because there
> >is no need to issue such CRL (see the first comment). It is simply the
> >"freshest CRL constructed from the base CRL number 5 for 3:10 am". This
> >locally contructed CRL bears no number, or if you assign one, this is a
> >local matter and is not part of the standard. This also avoids the later
> >confusing between CRL numbers.
 
[David] This is simply not true. 

[Denis] The sentence above is technically correct: "It is simply the
freshest CRL constructed from the base CRL number 5 for 3:10 am".
 
[David] A delta-CRL can (will) contain the cRLNumber extension just as a
full CRL will. 

[Denis] The cRLNumber extension is simply an identifier that allows you to
uniquely identify it and to know whether it is earlier or later another CRL
issued by the same CRL issuer.

[David] If a full CRL and a delta-CRL are issued at the same time, the
combination of the delta-CRL and an appropriate base CRL must be equivalent
to the full CRL, and both the delta-CRL and the full CRL must have the same
cRLNumber. 

[Denis] This is where we do not agree. The delta-CRL and the full CRL MUST
NOT have the same cRLNumber because this would violate the definition of
what is a CRLnumber. RFC 2459 says: 

5.2.3  CRL Number

   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for each CRL issued by a CA.
   This extension allows users to easily determine when a particular CRL
   supersedes another CRL.  CAs conforming to this profile MUST include
   this extension in all CRLs.

Maybe you are making some confusion with the deltaCRLindicator. 

The construction you mention is not acceptable and is no even part of the
ISO X509 document.

[David] If a delta-CRL is issued, and no corresponding full CRL issued, then
the combination of the delta-CRL and an appropriate base CRL should be
equivalent to the full CRL that would have been issued at that time, if a
full CRL had been issued. 

[Denis] Here is the problem ! Let us take an example: A base CRL
is issued at midnight. thisUpdate is set to midnight while nextUpdate is
midnight for the next day. This means that there is no guarantee at all that
any other base/full CRL will necessarily be seen within the next 24 hours.
Certainly a base can be issued before, but once again there is no guarantee
that it will ever be seen. If someone is now using the CRL as a proof to be
presented later on that the certificate was not revoked, a relying party 
is perfectly right to use the base from midnight (if allowed by the
validation policy) or the base plus a delta (if mandated by the validation
policy).    

Now if you issue a full CRL (I did not say a base CRL) every hour at the
same time you issue a delta, the problem becomes worse because at 11:30 p.m.
you have now 23 full CRLs, and you cannot know which one is the right one to
use (if someone purposely is blocking the transmission of the latest full
CRLs), unless precisely you introduce he statement that is the cause of all
this trouble:

   When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
   that is complete for the given scope.  

Now understand better the problem: this is a stone fundation of the whole
edifice. If we take it away, the whole edifice collapses.

Anyway, the intention has never been that relying parties will necessarilly
get the same level of information when using only base CRLs and when using
base CRLs plus deltas.

The question which arises now is what are the implications if a full CRL is
issued at the same time a delta is issued and when we apply the modified
sentence:

   When a conforming CA issues a delta CRL, the CA MAY also issue a full CRL
   that is complete for the given scope.  

In this case the relying pary is using the delta (*in the way I have
described it*), i.e. testing thisUpdate and nextUpdate from the delta CRL,
it will get a GUARANTEE to obtain either the freshest revocation
information or it will know that the freshest revocation information is not
available.

In the case the relying pary is using not using the delta, he will have no
GUARANTEE that the information he got is the freshest.

[David] The delta-CRL should have the same cRLNumber as would have been
assigned to a full CRL issued at the same time.

[Denis] Once again, I disagree, since this would violate the definition of
CRL Number given in section 5.2.3. 
 
[David] A delta-CRL is nearly the same as a full CRL. It has a thisUpdate,
nextUpdate, cRLNumber, etc. just as a full CRL. It just has an incomplete
list of revoked certificates.

[Denis] Yes, but you have to explain detail how a relying party will use
thisUpdate, nextUpdate for a base CRL and thisUpdate, nextUpdate for a delta
to make sure that in both cases he got the freshest information.

Remember that RFC 2459 says:

   The behavior of clients processing CRLs which
   omit nextUpdate is not specified by this profile.

So, in order to be PKIX compliant, you cannot escape a sentence which tells
what use is made of that field.

> > > A few hours later, at 6:30am, the relying party performs another validation. The relying party has, in its local cache, the contents of CRL number 8 (which it constructed at 3:10am). It wants to update the information in its local case to based on the newly available revocation information. So, it obtains the latest delta-CRL. This delta-CRL has a CRL number of 11 and a BaseCRLnumber of 5. Since it has a BaseCRLNumber of 5, the delta-CRL provides status information for all certificates whose status has changed since CRL number 5 was issued. (midnight). So, clearly the delta-CRL provides status information for all certificates whose status has changed since 3:00am when CRL number 8 was issued. Thus, the relying party can combine the delta-CRL with its locally cached version of full CRL number 8 to obtain the contents of CRL number 11. This is a case where the CRL number of the complete CRL used is greater than the BaseCRLNumber specified in the delta-CRL.

> >[Denis] This is a local matter and I would not mandate this in the document
> >since there is another and simpler way to do it: you keep in the cache the
> >base CRL (instead of the previously recontructed full CRL). This has the
> >same end result, except that the method your recommend is not optimum: it
> >will include many duplicates and deleting the duplicates is more painfull
> >than making a simple addition.
 
[David]  I'm not sure what you are saying is a local matter. The contents of
the delta-CRL is not a local matter and must be mandated in the certificate
and CRL profile. If you prefer to always apply the delta-CRLs to the
referenced base CRL instead of to a locally generated, more recent CRL, that
is your choice. The document states that the delta-CRL may be combined with
the referenced base CRL or a more recently issued full CRL.

[Denis] 

As said later, your paper provides the right answer (on page 1): " A
delta-CRL is a CRL that only provides information about certificates who
statuses have changed since the issuance of a specific, previously issued
CRL". The text says " *a* specific, previously issued CRL", it does NOT say
"or any, more recently, issued CRL". Now I understand that you may get the
same final result (in a less efficient way), if such a CRL has been issued
and if it could have been seen by the relying party. I would propose that we
describe in the text, the basic rule. I would have no problem to mention in
a note that the same result COULD also be obtained, IF a full CRL were
issued
after the base.

> >The basic algorithm is to take the base CRL and to add the delta. This is
> >the standard. As soon as you get the same end result this is fine. This is
> >the approach we have taken for path validation. Other ways do not need to be
> >mentionned.
> >
> > > There are other reasons why the two numbers may not match, but I will not go into them. If you are interested, you can read my paper.
> >
> >[Denis] I read it (and skipped the mathematical formulas)
> >
> >This paper is proposing a method for over-issuing the CRLs. It omits to take
> >into consideration that in PKIX-1 we mandate the CRL number extension
> >(section 5.2.3) so we need to advertise the nextUpdate. If you issue a CRL
> >before the next update you have no more way to know which base CRL is the
> >freshest CRL. I believe this is a major security weakness and for that
> >reason this mechanism should be deprecated.

[David]  The paper does discuss over-issuing of CRLs, but there is plenty of
information about using delta-CRLs efficiently without over-issuing. Bear in
mind, however, that the nextUpdate field only specifies the time by which a
new CRL will be issued. Many people intend to issue a new CRL whenever a
revocation occurs (or a revocation for key compromise) without waiting until
the regularly scheduled time.

[Denis] As said earlier, without any guarantee that the fullCRL issued
before nextUpdate will be seen until the validation time has passed
nextUpdate. 

> >BTW, the same security problem would occur as soon as a base would be used
> >for every delta. Hence another good reason to delete the sentence which
> >originally triggered all this discussion.
> 
> I don't understand this at all.
> 
> >BTW, I noticed that you have precisely deleted from my previous e-mail all
> >the text dealing with this nextUpdate. :-(
> >
> >So I am still insisting on the major text change to make to that section:
> >
> >    An application can construct a CRL that is the most current for
> >    a given scope, at the current time, by retrieving the current
> >    base CRL for that scope, and combining it with a delta-CRL which
> >    contains a Delta CRL Indicator equal to the cRLNumber of the base
> >    CRL and where the current date from that delta-CRL is between
> >    thisUpdate and nextUpdate;
> >
> >It is important to notice that the algorithm does NOT use the individual CRL
> >numbers assigned to the delta-CRLs, but uses instead thisUpdate and
> >nextUpdate. This is *very* important.
 
[David]  I thought I did respond to this. First, one should expect that
delta-CRLs will always be at least as recent as base CRLs. So the first step
should be to obtain the current delta-CRL. Next, one obtains a base CRL that
can be used in combination with that delta-CRL. You may choose to only use
the full CRL whose cRLNumber is equal to the BaseCRLNumber specified in the
delta-CRL, however, any full CRL with a cRLNumber greater than or equal to
the BaseCRLNumber is acceptable. 

[Denis] Your algorithm is looking at the CRL Numbers only. My algorithm is
looking at thisUpdate and nextUpdate only. This is a major difference. In
particular you do not say how "to obtain the current delta-CRL".

[David] Since the cRLNumber of the base can be greater than the specified
BaseCRLNumber, the document should say so. 

[Denis] This can be mentionned in a note (see earlier).  

[David] There is no need to state that the current time must be after the
thisUpdate time in the delta-CRL as this will always be true by
construction. 

[Denis] There is definitively a need to state this because the end result of
the two algorithms will not be identical as soon as someone will block some
of the information coming from the repository where the full/base CRLs are
stored or where the delta CRLs are stored.

[David]  Finally, since a CRL issuer may issue "emergency" delta-CRLs, there
is no guarantee that any delta-CRL whose nextUpdate time is later than the
current time is the most current delta-CRL.

[Denis] If you issue such "emergency" delta-CRLs then once again there is no
guarantee that they will ever be seen. The "most recent delta-CRL" is any
delta CRL which satisfies the following condition :

" A delta-CRL which contains a Delta CRL Indicator equal to the cRLNumber of
the base CRL and where the validation date (which may be the current time)
is between thisUpdate and nextUpdate from that delta-CRL;"
 
> > > >Finally we should explain what happens at the boundaries, i.e. when a CA
> > > >decides to generate a (new) base CRL. Here is a text proposal:
> > > >
> > > >   When issuing a base CRL that supports a delta-CRL mechanism then the
> > > >   CRL Issuer MUST at the same time issue a delta CRL that points to that
> > > >   base CRL. This first delta CRL will usually be empty (or will include
> > > >   last-minute additions to the base CRL).

> > > This is not acceptable. The rule is that when a base CRL is issued a delta-CRL must be issued that has the same cRLNumber. The base CRL referenced by the delta must either be the previously issued base CRL or a base CRL issued before that one. Since the new base and the delta must have the same cRLNumber, there can be no differences as a result of "last-minute additions to the base CRL".

> >[Denis] This does not work. Let me explain it differently. Suppose that
> >during the week you do not generate delta-CRLs but for the week-end you
> >decide to do it (e.g. more risk, more transactions done by citizens). So you
> >issue a CRL with the freshest CRLindicator. You say that the delta points to
> >the previous base CRL. The one from yesterday or the one from last week ?
> >In either case this simply does not work.
 
[David]  Why? A delta-CRL must include a BaseCRLNumber that corresponds to a
CRL that was issued at some time in the past.

[Denis]  A delta-CRL must include a BaseCRLNumber that corresponds to a CRL
that was issued at some time in the past *or to the current time*. The above
example demonstrates that the rule does not work the first time you use it
since there is no such past base CRL or an ambiguity about which one is the
right one. Since it is not possible to answer the question I raised (i.e.
does the first delta points to one from yesterday or the one from last 
week ?) this is one way to demonstrate that there is a problem.

> >The rule you mention, i.e. "The rule is that when a base CRL is issued a
> >delta-CRL must be issued that has the same cRLNumber" is also wrong. The
> >notion of a base CRL that would have the same number as a delta does not
> >exist.

> > > >Suppose we issue a base CRL every midnight. The question is whether we
> > > >should issue a delta and, if yes, does this delta refer to the previous
> > > >base or to the new one ?

> > > The delta must refer either to the previous base or a base issued before the previous base.

> >[Denis] Certainly not. Your paper however provides the right answer
> >(on page 1): " A delta-CRL is a CRL that only provides information about
> >certificates who statuses have changed since the issuance of a specific,
> >previously issued CRL".
 
[David] Where is the difference? A CRL that is referenced in the
BaseCRLNumber of a delta-CRL is by definition a base CRL.

[Denis] The difference lies in the fact that the sentence is using the
wording "*a* specific, previously issued CRL". If it is *a* (i.e. one)
specific CRL, it cannot be more than one.
 
> > > >Suppose it refers to the previous one. According to the current sentence:
> > > >"The constructed CRL has the CRL number specified in the CRL number
> > > >extension found in the delta CRL used in its construction.", it is
> > > >impossible. If that was the case the delta CRL would have a CRL number equal
> > > >to the base CRL and it is not allowed for two CRLs to have the same CRL
> > > >number.
> >
> > > I think you are confusing two different extensions. The deltaCRLIndicator extension contains a BaseCRLNumber which is used to determine against which base CRLs the delta-CRL can be applied. The cRLNumber extension specifies the CRL number of the full CRL that will be generated by applying the delta-CRL to a base CRL. The sentence above states that the CRL number of the constructed CRL is taken from the cRLNumber extension, not the BaseCRLNumber of the deltaCRLIndicator extension.
> >
> >[Denis] I do not think I make a confusion. The confusion comes from the
> >numbering you introduce (see my earlier comment).
> >
> >Let me conclude:
> >
> >1) I do not have the time to spend hours of discussions on that topic.
> >However the current text needs to be corrected and I have provided text
> >for this. Please take again a look at it in the light of the following.
> >
> >2) In your paper you advertise the "traditional delta-CRLs". Let us stay in
> >the tradition and let us mandate the implementation of the "tradition" if
> >someone wans to support the delta-CRL mechanism.
> >
> >Any other method would first need to be proven to be secure (over-issuing
> >CRLs and sliding window delta-CRLs have security problems) and should
> >*anyway* fall in the MAY category, so that noone needs to implement to claim
> >conformance with the delta CRL mechanism. Standard track documents need to
> >make choices among multiple methods, otherwise two different implementations
> >will never interoperate.
 
[David] you say that you want to stick with "traditional" delta-CRLs,
however you are proposing changes to the text that would not result in
"traditional" delta-CRLs but would result in broken implementations. 

[Denis] You have provided no evidence of what you say just above. Tell me
precisely what is wrong in the text I propose that would not allow the
support of the "traditional" delta-CRLs. If something is wrong, we can fix
it.

[David] We do not prevent people from implementing "traditional" delta-CRLs,
but we should not force them to either. 

[Denis] We disagree here. Standards are there to support at least one
(simple) method that all implementations have to support( if they support
delta). In addition, implementations may support additional methods and it
will be up to the final customer to decide which one to use. We MAY describe
these additional methods, but MUST clearly indicate the difference.
 
[David] There are no security problems with sliding window delta-CRLs and
they do not add any complexity for those who choose not to
implement them.

[Denis] There ARE security problems with sliding window delta-CRLs. I have
descibed at length what the problems are. However, this does not mean that
this technique cannot be supported as an OPTIO and IF we indicate in the
text what are their security problems. The current text places the two
techniques at the same level. The traditional way offers a guarantee while
the other does not. There is indedd added complexity for building the
software from the relying party. 

[David]  I want to be sure that the delta-CRL text is correct just as you
do, 

[Denis]  At least one point on which we both agree. :-)

[David] ... but I still feel that many of your comments are based on a
misunderstanding and are not based on actual problems in the text.

[Denis] I do hope that after this response you will think differently.

Regards,

Denis

> Dave


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA13830 for <[e-mail]>; Mon, 23 Apr 2001 06:06:30 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA16908; Mon, 23 Apr 2001 15:06:07 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA06038; Mon, 23 Apr 2001 15:05:50 +0200
Message-ID: <[e-mail]>
Date: Mon, 23 Apr 2001 15:05:58 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

> > > However, I object to adding support for limits on trust anchors to
> > > section 6.1. The algorithm in section 6.1 is the "basic" algorithm that
> > > everyone MUST implement. Section 6.2 describes various ways to extend
> > > that algorithm. Multiple trust anchors is one. Limits on trust anchors
> > > is a second. PEM compatible processing is a third. If one argues that
> > > limits on trust anchors should be described in section 6.1, one could
> > > equally argue that PEM compatible processing should be described in
> > > section 6.1.
> >
> > I agree with the intent, but this is NOT what the text says. :-(
> >
> > In particular section 6.1 only says " This text describes an algorithm for
> > X.509 path processing". It does not qualifies it as basic nor says that it
> > is a set of minimum conditions.
> 
> Section 6 (third paragraph) says "In section 6.1, the text describes
> basic path validation." 

OK. One point for you for the use of the word "basic", but ...

one point for me because the text does not say that it is a set of minimum
conditions. :-)

> A few paragraphs later, it says "Section 6.2
> describes methods for using the path validation algorithm in specific
> implementations. Two specific cases are discussed: the case where paths
> may begin with one of several trusted CAs; and where compatibility with
> the PEM architecture is required."
 
> Section 6.1 (first paragraph) says "A conformant implementation MUST
> include an X.509 path processing procedure that is functionally
> equivalent to the external behavior of this algorithm." And section 6.1
> is titled "Basic Path Validation", while section 6.2 is titled "Using
> the Path Validation Algorithm".
 
> That's why I said that section 6.1 is the "basic" algorithm that
> everyone MUST implement and section 6.2 describes various ways to extend
> that algorithm.

 .. but the text does not say that it is a set of minimum conditions.
 
> > Section 6.2 says " The path validation algorithm describes the process of
> > validating a single certification path".

.. but the text frpom section 6.1. does not say that other constraints may
be applied even when there is a single trust anchor.

> > "An implementation that supports multiple trust anchors may augment the
> > algorithm presented in section 6.1 to further limit the set of valid paths
> > which begin with a particular trust anchor."
 
> This is one of several variations included in section 6.2. PEM
> compatible processing is also included in section 6.2. Section 6.2 is
> clearly not limited to variations which employ multiple trust anchors.

The only other case is PEM:

   It is also possible to specify an extended version of the above
   certification path processing procedure which results in default
   behavior identical to the rules of PEM [RFC 1422]. 

> > You are proposing that the text from section 6.1 describes the "basic"
> > algorithm, while the text from section 6.2. describes enhancements to the
> > basic algorihm. I would not be opposed to your proposal, ... but many text
> > changes would be required.
 
> I don't think so. I think the text at the start of section 6 is clear.
> Perhaps an introductory paragraph at the start of section 6.2 would make
> it even clearer, but I don't see any other changes that would be
> required.

The case of a single anchor with additional constraints is still not covered
by the current text.

Regards,

Denis
 
> -Steve


Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id TAA20904 for <[e-mail]>; Sun, 22 Apr 2001 19:40:58 -0700 (PDT)
Received: from 157.54.7.67 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 22 Apr 2001 19:35:00 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 22 Apr 2001 19:34:15 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 22 Apr 2001 19:34:10 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Sun, 22 Apr 2001 19:33:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx	t  comments)
Date: Sun, 22 Apr 2001 19:33:41 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx	t  comments)
Thread-Index: AcDLlCEFtrXlwHfOTlOu9OL6OSn78QACINIg
From: "Trevor Freeman" <[e-mail]>
To: "EKR" <[e-mail]>, "Ambarish Malpani" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 23 Apr 2001 02:33:44.0037 (UTC) FILETIME=[D0D61950:01C0CB9D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id TAA20905

It is not the cost associated with generating the base CRL but the over
all system cost which is in question, e.g. the cost associated with the
distribution of the CRL with replicated distribution mechanisms. If you
publish a CRL to a directory, and that directory has multiple replicas,
then there is a knock on effect when one instance of the directory is
updated. The update is then replicated to all other instances. If you
are not using a replicated directory, you may be using a replicated web
server, which will have the same problem. Then there are bandwidth
implications. Even in this day and age, bandwidth may be limited, and
downloading a full CRL has a cost associated with it.


-----Original Message-----
From: Eric Rescorla [mailto:[e-mail]] 
Sent: Sunday, April 22, 2001 6:20 PM
To: Ambarish Malpani
Cc: 'Housley, Russ'; [e-mail]
Subject: Re: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.tx t comments)

Ambarish Malpani <[e-mail]> writes:

> Russ, the problem with this is that CAs might be unwilling to issue
> delta-CRLs because issuing a full CRL every time is too
> burdensome.
Ambarish, could you explain why the cost of issuing a full
CRL is too burdensome? Surely it's not the cost of the signature
itself you're concerned with.

-Ekr



Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id TAA20845 for <[e-mail]>; Sun, 22 Apr 2001 19:40:49 -0700 (PDT)
Received: from 157.54.7.67 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 22 Apr 2001 19:35:00 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 22 Apr 2001 19:34:15 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 22 Apr 2001 19:34:11 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Sun, 22 Apr 2001 19:33:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Sun, 22 Apr 2001 19:33:43 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Thread-Index: AcDLk3DHBs5oUjStQQaDeFEru0nH6AACOqjg
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Housley, Russ" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 23 Apr 2001 02:33:44.0256 (UTC) FILETIME=[D0F78400:01C0CB9D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id TAA20846

Yes,
If a CA has not updated its CRL, the OCSP client may be aware of a
revocation that the CRL client is not - which h is the reason put
forward by Russ for publishing base and delta at the same time.
Trevor

-----Original Message-----
From: Michael Myers [mailto:[e-mail]] 
Sent: Sunday, April 22, 2001 6:18 PM
To: Trevor Freeman; Housley, Russ; [e-mail]
Subject: RE: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)

Trevor,

Is your differentiator timeliness?

Mike


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Sunday, April 22, 2001 5:28 PM
>
> . . .
> An OCSP aware client may have a different answer to CRL
> aware clients to the revocation status of a certificate.
> . . . 




Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA19750; Sun, 22 Apr 2001 19:11:56 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3N2Bxd09502; Sun, 22 Apr 2001 19:11:59 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "David Cross" <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Sun, 22 Apr 2001 19:10:32 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

Dave,

Recognizing broader enterprise issues, somwhere there's nonetheless a middle
ground where the mandatory practice of a full CRL complements the optional
practice of issuing deltas.  The period of the former MAY, perhaps SHOULD,
be longer than the latter in the presence of the delta practice.  Your
thoughts?

Mike



> -----Original Message-----
> From: David Cross [mailto:[e-mail]]
> Sent: Sunday, April 22, 2001 5:58 PM
> To: Paul Hoffman / IMC; [e-mail]
> Subject: RE: delta-CRLs (was Re:
> LastCall:draft-ietf-pkix-new-part1-06.txt comments)
>
>
> It may not be a burden to a CA, but it very well likely may be burden
> for the underlying replication and distribution architecture to push a
> full CRL every time a delta-CRL is issued.  It is the bigger picture of
> the issue outside of the CA and PKI aspects.
>
>
> David B. Cross
>
>
>
>
> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Sunday, April 22, 2001 7:06 AM
> To: [e-mail]
> Subject: RE: delta-CRLs (was Re:
> LastCall:draft-ietf-pkix-new-part1-06.txt comments)
>
>
> At 6:03 PM -0700 4/21/01, Ambarish Malpani wrote:
> >Russ, the problem with this is that CAs might be unwilling to issue
> >delta-CRLs because issuing a full CRL every time is too burdensome.
>
> Could you describe how it is "too burdensome"? Maybe I'm being naive,
> not being a CA, but asking a CA to sign a second document (the full
> CRL) at the time that it signs the first document (the delta-CRL)
> really doesn't seem that onerous.
>
> I think the current requirement is fine.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA18949 for <[e-mail]>; Sun, 22 Apr 2001 18:37:42 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Sun, 22 Apr 2001 18:37:53 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Sun, 22 Apr 2001 18:37:52 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26PT66>; Sun, 22 Apr 2001 18:36:36 -0700
Content-return: allowed
Date: Sun, 22 Apr 2001 18:36:29 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx	t comments)
To: "'EKR'" <[e-mail]>, Ambarish Malpani <[e-mail]>
Cc: "'Housley, Russ'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Hi Eric,
    I don't have any problems with issuing new CRLs every few
seconds - unfortunately, some of the CA vendors do :-)

Anyway, the problem people have with issuing full CRLs at every
revocation is the amount of extra processing they do with the
CRL - e.g. back it up in their database, create some kind of
audit trail, lookup all the revoked certificates in their
database, etc.

I have heard more than 1 CA vendor balk at the idea of issuing a
new CRL for every revocation event, so I must believe that this is
a pretty expensive operation.

Regards,
Ambarish


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


> -----Original Message-----
> From: Eric Rescorla [mailto:[e-mail]]
> Sent: Sunday, April 22, 2001 6:20 PM
> To: Ambarish Malpani
> Cc: 'Housley, Russ'; [e-mail]
> Subject: Re: delta-CRLs (was Re: Last
> Call:draft-ietf-pkix-new-part1-06.tx t comments)
> 
> 
> Ambarish Malpani <[e-mail]> writes:
> 
> > Russ, the problem with this is that CAs might be unwilling to issue
> > delta-CRLs because issuing a full CRL every time is too
> > burdensome.
> Ambarish, could you explain why the cost of issuing a full
> CRL is too burdensome? Surely it's not the cost of the signature
> itself you're concerned with.
> 
> -Ekr
> 


Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id SAA17625 for <[e-mail]>; Sun, 22 Apr 2001 18:21:43 -0700 (PDT)
Received: from 157.54.9.104 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 22 Apr 2001 18:06:25 -0700 (Pacific Daylight Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 22 Apr 2001 18:06:22 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Sun, 22 Apr 2001 17:57:51 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt  comments)
Thread-Index: AcDLjnhPZVtrDFXoQZyGbX+yOEWT3AAAbJFQ
From: "David Cross" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 23 Apr 2001 01:06:22.0268 (UTC) FILETIME=[9C7F9FC0:01C0CB91]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id SAA17627

It may not be a burden to a CA, but it very well likely may be burden
for the underlying replication and distribution architecture to push a
full CRL every time a delta-CRL is issued.  It is the bigger picture of
the issue outside of the CA and PKI aspects.

 
David B. Cross
 



-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]] 
Sent: Sunday, April 22, 2001 7:06 AM
To: [e-mail]
Subject: RE: delta-CRLs (was Re:
LastCall:draft-ietf-pkix-new-part1-06.txt comments)


At 6:03 PM -0700 4/21/01, Ambarish Malpani wrote:
>Russ, the problem with this is that CAs might be unwilling to issue 
>delta-CRLs because issuing a full CRL every time is too burdensome.

Could you describe how it is "too burdensome"? Maybe I'm being naive, 
not being a CA, but asking a CA to sign a second document (the full 
CRL) at the time that it signs the first document (the delta-CRL) 
really doesn't seem that onerous.

I think the current requirement is fine.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA17292 for <[e-mail]>; Sun, 22 Apr 2001 18:19:39 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3N1Jed07872; Sun, 22 Apr 2001 18:19:40 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "Housley, Russ" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Sun, 22 Apr 2001 18:18:14 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

Trevor,

Is your differentiator timeliness?

Mike


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Sunday, April 22, 2001 5:28 PM
>
> . . .
> An OCSP aware client may have a different answer to CRL
> aware clients to the revocation status of a certificate.
> . . . 




Received: from romeo.rtfm.com ([198.144.203.242]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA16362 for <[e-mail]>; Sun, 22 Apr 2001 18:14:50 -0700 (PDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id SAA11280; Sun, 22 Apr 2001 18:20:12 -0700 (PDT)
Sender: [e-mail]
To: Ambarish Malpani <[e-mail]>
Cc: "'Housley, Russ'" <[e-mail]>, [e-mail]
Subject: Re: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx	t  comments)
References: <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 22 Apr 2001 18:20:12 -0700
In-Reply-To: Ambarish Malpani's message of "Sat, 21 Apr 2001 18:03:06 -0700"
Message-ID: <[e-mail]>
Lines: 11
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"

Ambarish Malpani <[e-mail]> writes:

> Russ, the problem with this is that CAs might be unwilling to issue
> delta-CRLs because issuing a full CRL every time is too
> burdensome.
Ambarish, could you explain why the cost of issuing a full
CRL is too burdensome? Surely it's not the cost of the signature
itself you're concerned with.

-Ekr



Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA16360; Sun, 22 Apr 2001 18:14:50 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3N1Erd07710; Sun, 22 Apr 2001 18:14:53 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Sun, 22 Apr 2001 18:13:27 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <p0510080eb70895081561@[192.168.1.13]>
Importance: Normal

Ambarish, Paul:

I must second Paul's concern.

If you work through what it takes for to implement both "full" and "delta"
CRL capabilities (i.e. CRON-driven sweeps across a database, formatting the
relevant info into 2459-compliant syntax, signing the result and pushing it
out to wherever or whomever) the software-level requirements to produce a
delta are pretty close to identical to those for a full.  Basically, it's
just another crontab entry with perhaps a different period.

But another thing bothers me in this dialog.  The notion of a full
backup/baseline in conjunction with (perhaps) more frequent deltas is a very
well known and highly advised practice, for an obvious set of reasons.  We
should be thinking more about how this general principle applies in this
instance.  PKI is not so unique in its nature that this standard database
maintenance practice does not apply.

Mike

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Sunday, April 22, 2001 7:06 AM
> To: [e-mail]
> Subject: RE: delta-CRLs (was Re: Last
> Call:draft-ietf-pkix-new-part1-06.txt comments)
>
>
> At 6:03 PM -0700 4/21/01, Ambarish Malpani wrote:
> >Russ, the problem with this is that CAs might be unwilling to issue
> >delta-CRLs because issuing a full CRL every time is too
> >burdensome.
>
> Could you describe how it is "too burdensome"? Maybe I'm being naive,
> not being a CA, but asking a CA to sign a second document (the full
> CRL) at the time that it signs the first document (the delta-CRL)
> really doesn't seem that onerous.
>
> I think the current requirement is fine.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>



Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA13818 for <[e-mail]>; Sun, 22 Apr 2001 17:42:57 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p0510080eb70895081561@[192.168.1.13]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Sun, 22 Apr 2001 07:06:07 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 6:03 PM -0700 4/21/01, Ambarish Malpani wrote:
>Russ, the problem with this is that CAs might be unwilling to issue
>delta-CRLs because issuing a full CRL every time is too
>burdensome.

Could you describe how it is "too burdensome"? Maybe I'm being naive, 
not being a CA, but asking a CA to sign a second document (the full 
CRL) at the time that it signs the first document (the delta-CRL) 
really doesn't seem that onerous.

I think the current requirement is fine.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id RAA13407 for <[e-mail]>; Sun, 22 Apr 2001 17:38:17 -0700 (PDT)
Received: from 157.54.7.67 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 22 Apr 2001 17:29:56 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 22 Apr 2001 17:28:52 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 22 Apr 2001 17:28:48 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Sun, 22 Apr 2001 17:28:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Sun, 22 Apr 2001 17:28:05 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Thread-Index: AcDKq8B8myafCq05SxKHo1RrqERPlwA3290g
From: "Trevor Freeman" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 23 Apr 2001 00:28:21.0903 (UTC) FILETIME=[4D4B89F0:01C0CB8C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id RAA13408

Russ,
This level of concern for simple vs. complex was never raised when OCSP
was discussed. An OCSP aware client may have a different answer to CRL
aware clients to the revocation status of a certificate. Having
established a precedent like that, it's too late to put the cat back in
the bag now. What you have expressed is a policy, which is better left
to the security consideration section rather than a must clause in the
standard.
It also ignores the reason why delta CRLS are viewed as attractive. A CA
can today publish a full CRL whenever it likes. The reality is that
publication of CRLs comes at a cost to the infrastructure, and many
organisations are not prepared to pay that cost for full CRL
publication, but would be prepared to publish smaller delta CRLs more
frequently.
Trevor

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]] 
Sent: Friday, April 20, 2001 1:26 PM
To: [e-mail]
Subject: Re: delta-CRLs (was Re: Last
Call:draft-ietf-pkix-new-part1-06.txt comments)


> >In the third paragraph the first sentence (still) says:
> >
> > >    When a conforming CA issues a delta CRL, the CA MUST also issue
a CRL


Originally, this sentence was placed in RFC 2459 to ensure that simple 
clients are able to get the best possible revocation information.  We
did 
not want to require CAs or clients to support delta-CRLs, but if a CA
chose 
to support delta-CRLs, we did not want to penalize clients.

I do not see that either of these desires has changed.

Russ




Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA02875 for <[e-mail]>; Sun, 22 Apr 2001 14:51:06 -0700 (PDT)
Received: from 157.54.9.104 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 21 Apr 2001 16:07:46 -0700 (Pacific Daylight Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sat, 21 Apr 2001 16:07:07 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Date: Sat, 21 Apr 2001 16:07:07 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Thread-Index: AcDKq8td/2vWwmoTRKmmIAi2MrNVqQAC7a0g
From: "David Cross" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 21 Apr 2001 23:07:07.0308 (UTC) FILETIME=[C9659EC0:01C0CAB7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA02876

Understood - however, you may be penalizing the CA and the supporting
infrastructure to replicate a full base CRL versus a smaller delta-CRL
only.  That is why so many people would like it to be a MAY.

 
David B. Cross
 

> >In the third paragraph the first sentence (still) says:
> >
> > >    When a conforming CA issues a delta CRL, the CA MUST also issue

> > > a CRL


Originally, this sentence was placed in RFC 2459 to ensure that simple 
clients are able to get the best possible revocation information.  We
did 
not want to require CAs or clients to support delta-CRLs, but if a CA
chose 
to support delta-CRLs, we did not want to penalize clients.

I do not see that either of these desires has changed.

Russ




Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA24973 for <[e-mail]>; Sun, 22 Apr 2001 12:54:20 -0700 (PDT)
Received: by balinese.baltimore.ie; id UAA08628; Sun, 22 Apr 2001 20:25:13 +0100 (GMT/IST)
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma015979; Sat, 21 Apr 01 21:07:50 +0100
Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Sat, 21 Apr 2001 21:06:23 +0100
Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id VAA25778; Sat, 21 Apr 2001 21:11:02 +0100
Message-ID: <[e-mail]>
Date: Sat, 21 Apr 2001 21:07:33 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: Russ Housley <[e-mail]>, [e-mail]
Subject: Re: Dedicated CRL signing keys
References: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Trevor,

I'm sympathetic and would also like to see a nice solution that'd 
ease graceful failure for clients. However, if the proposal breaks
existing CAs then its not a solution (as Tim pointed out for a
different reason).

Stephen.

Trevor Freeman wrote:
> 
> Stephen,
> The route problem is that this is an optional feature, and the net
> result with the current proposal of profile compliant clients who
> encounter a CA operating with this option will simply be a signature
> failure. This presents a fairly high bar to anyone trying to establish
> why the revocation check is failing. The rational behind using a
> critical extension in the CRL is that now the conformant client knows
> that failure is by design without understanding what the problem is
> since it does not understand the extension and can return a more
> informative error like option not supported.
> Trevor
> 
> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Thursday, April 19, 2001 7:07 AM
> To: Russ Housley
> Cc: Trevor Freeman; [e-mail]
> Subject: Re: Dedicated CRL signing keys
> 
> Russ,
> 
> That'd be a bad resolution since it would break deployed CAs who
> use the same name and different cert and CRL signing keys (and
> those do exist and are operating).
> 
> Any other ideas or should we just require clients to understand
> what's going on based on key usage?
> 
> Stephen.
> 
> Russ Housley wrote:
> >
> > Trevor:
> >
> > I propose the following solution that builds on the Indirect CRL
> > capabilities that are already available.  When a CA wants to employ
> > separate private keys to sign certificates and CRLs, then that CA MUST
> > delegate CRL signing to a separate authority.  That separate authority
> MUST
> > have a different Distinguished Name that the CA, but it could be
> operated
> > by the same organization.  In this way, the IDP CRL extension would
> flag
> > the "unusual" circumstances.  Clients that do not support Indirect
> CRLs can
> > fail gracefully (unsupported optional feature), and clients that
> support
> > Indirect CRLs can happily handle the certificates and CRLs.
> >
> > Thoughts?
> >
> > Russ
> >
> > At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
> > >There has been some discussion regarding the proposal to have CRLs
> > >signed with CA keys which do not also sign certificates. Since this
> will
> > >not be a mandatory to implement feature, I am concerned about the
> impact
> > >on pkix compliant clients who encounter CRL signed in this way, and
> how
> > >we expect them to behave. What seem unacceptable with the current
> > >proposal is that the signage check on the CRL will fail, and the
> client
> > >will have little clue as to why and if this failure is expected. The
> > >information in the chain, while present, is in the CAs certificate,
> is
> > >difficult to find and subtle so would be easily missed by someone
> > >debugging this problem. I would like to see some clearer indication
> in a
> > >critical extension in the CRL itself that would indicate what was
> going
> > >on. In expressing these semantics in a critical extension, we
> maintain
> > >the principal that if you don't understand the extension, the client
> > >knows to fail due to its own inadequacies and that failure is by
> design,
> > >therefore allowing the client's to return an error unsupported option
> > >rather than invalid signature.
> > >Trevor
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA00417 for <[e-mail]>; Sat, 21 Apr 2001 18:04:15 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Sat, 21 Apr 2001 18:04:20 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Sat, 21 Apr 2001 18:04:20 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26PSSX>; Sat, 21 Apr 2001 18:03:06 -0700
Content-return: allowed
Date: Sat, 21 Apr 2001 18:03:06 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx	t comments)
To: "'Housley, Russ'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Russ, the problem with this is that CAs might be unwilling to issue
delta-CRLs because issuing a full CRL every time is too
burdensome.

The net result is that *nobody* has access to the latest
revocation information - not even the smart clients who can
understand delta CRLs.

I would prefer that we drop that requirement that a full CRL
be published whenever a new delta CRL is published.

Regards,
Ambarish

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


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Friday, April 20, 2001 1:26 PM
> To: [e-mail]
> Subject: Re: delta-CRLs (was Re: Last
> Call:draft-ietf-pkix-new-part1-06.txt comments)
> 
> 
> 
> > >In the third paragraph the first sentence (still) says:
> > >
> > > >    When a conforming CA issues a delta CRL, the CA MUST 
> also issue a CRL
> 
> 
> Originally, this sentence was placed in RFC 2459 to ensure 
> that simple 
> clients are able to get the best possible revocation 
> information.  We did 
> not want to require CAs or clients to support delta-CRLs, but 
> if a CA chose 
> to support delta-CRLs, we did not want to penalize clients.
> 
> I do not see that either of these desires has changed.
> 
> Russ
> 
> 


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA18205 for <[e-mail]>; Sat, 21 Apr 2001 14:33:47 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Apr 2001 21:33:51 UT
Received: from exno01.securitydynamics.com (exno01.securitydynamics.com [10.129.1.41]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA28703 for <[e-mail]>; Sat, 21 Apr 2001 17:33:49 -0400 (EDT)
Received: by exno01.dynas.se with Internet Mail Service (5.5.2650.21) id <2YZRT0CK>; Sat, 21 Apr 2001 23:33:49 +0200
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HK1A3DGC; Sat, 21 Apr 2001 17:33:40 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 20 Apr 2001 16:25:57 -0400
Subject: Re: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

> >In the third paragraph the first sentence (still) says:
> >
> > >    When a conforming CA issues a delta CRL, the CA MUST also issue a CRL


Originally, this sentence was placed in RFC 2459 to ensure that simple 
clients are able to get the best possible revocation information.  We did 
not want to require CAs or clients to support delta-CRLs, but if a CA chose 
to support delta-CRLs, we did not want to penalize clients.

I do not see that either of these desires has changed.

Russ




Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA26436 for <[e-mail]>; Fri, 20 Apr 2001 18:36:53 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 20 Apr 2001 18:37:03 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 20 Apr 2001 18:37:03 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26PR2N>; Fri, 20 Apr 2001 18:35:51 -0700
Content-return: allowed
Date: Fri, 20 Apr 2001 18:35:51 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Meaning of Non-repudiation
To: "'Tom Gindin'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_SfLmk2uDh9TAn0Z2MPBRvw)"

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_SfLmk2uDh9TAn0Z2MPBRvw)
Content-type: text/plain; charset="iso-8859-1"

 <http://www.itsec.gov.uk/docs/pdfs/sectarg/EntAuth51.pdf>
http://www.itsec.gov.uk/docs/pdfs/sectarg/EntAuth51.pdf
 <http://www.itsec.gov.uk/docs/pdfs/certreps/crp153.pdf>
http://www.itsec.gov.uk/docs/pdfs/certreps/crp153.pdf

Further to my memo earlier today, I inspected the
security target for Entrust/RA and Entrust/Authority for which the UK
Certification
Body recently issued certification report P.153.

The target claims
 

9.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office"
/>
Q.QRIGIN
FCO_NRO.2
This requirement ensures that the TOE generates

 
 
 
evidence of origin fortransmitted public key

 
The TOE must generate evidence of
 
certificates:

 
origin for transmitted public key
 
 

 
certificates.
 
FCO_NRO.2 ensures that evidence of origin is

 
 
 
generated for certificates, CRLs, and ARLs so the

 
 
 
identity of the originator can be related to the

 
 
 
information.

10.
Q.RECEIPT
FCO_NRR.2
This requirement ensures that the TOE generates

 
 
 
evidence of receipt for transmitted public key

 
The TOE must generate evidence of
 
certificates:

 
receipt fortransmitted public key
 
 

 
certificates.
 
FCO_NRR.2 ensures that evidence of receipt is

 
 
 
generated automatically for public key certificates

 
 
 
received via SEP or PKIX-CMP.
 
The certification report indicates that Entrust/RA provides both SFRs:
FCO_NRO(2) and
SFR_NRR(2) (Section O).
 
This implies, given the criteria, that 'the sub-protocol in PKIX-CMP for
returning the
necessary evidence of receipt of a public-key certificate' is "correct". 
 
This implies that, should any "user data" be attached to the message that
delivers the certificate via PKIX-CMP, and the automatic receipt is
generated, then there is now, a citable method for NR for arbitrary data.
Any protocol using receipt-evidentary methods compatible with PKIX-CMP can 
now realistically get certified as doing "proof of receipt with
non-repudiation."

It would be fascinating to know if the PKIX-CMP certificates involved have
the
NR bit set, in practice. Perhaps the Entrust ITSEC engineers will tell us.

Set or not set, there are interesting implications of the certification
report due to the design of PKIX-CMP "receipt-oriented" security services.
 
The CC do say, in informational annexes that: 
 
"The PP/ST author must specify the conditions that must be met to be able to
verify
the validity of the evidence. An example of a condition which could be
specified is
where the verification of evidence must occur within 24 hours. These
conditions,
therefore, allow the tailoring of the non-repudiation to legal requirements,
such as
being able to provide evidence for several years."
 
I have not found the words in the Entrust ST which satisfy this requirement,
yet. When we do, we can see some of the legal implications.
 
We seem to be making some concrete progress on NR, both technical
and legal, thanks to the world of public disclosure of STs.
 
Peter.
 
 
 
-----Original Message-----
From: Peter Williams [  <mailto:[e-mail]>
mailto:[e-mail]]
Sent: Friday, April 20, 2001 12:06 PM
To: 'Tom Gindin'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


When NIST?NSA folk evaluate a US network product/system, formally,
they must, traditionally, use the following conceptions of NR.
(Steve's notions of subject intent, and presumptions of signature
binding, are not relevant to a formal evaluation of a product/system
claiming to provide NR.)

It would be useful for some of our friends from NCSC/NIST
to perhaps find an actual evaluation/certification report
that certified an actual network product/system as meeting the
evaluation criteria for NR. This would provide us
with an example protocol under the Red Book
that was deemed "correct", as required by the criteria.

 

--Boundary_(ID_SfLmk2uDh9TAn0Z2MPBRvw)
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">
<TITLE></TITLE>

<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR></HEAD>
<BODY>
<DIV><A target=3D_blank=20
href=3D"http://www.itsec.gov.uk/docs/pdfs/sectarg/EntAuth51.pdf"><FONT =
face=3DArial=20
color=3D#000000>http://www.itsec.gov.uk/docs/pdfs/sectarg/EntAuth51.pdf<=
/FONT></A><BR><A=20
target=3D_blank =
href=3D"http://www.itsec.gov.uk/docs/pdfs/certreps/crp153.pdf"><FONT=20
face=3DArial=20
color=3D#000000>http://www.itsec.gov.uk/docs/pdfs/certreps/crp153.pdf</F=
ONT></A><BR><BR><FONT=20
face=3DArial>Further to my memo earlier today, I inspected =
the<BR>security target=20
for Entrust/RA and Entrust/Authority for which the UK =
Certification<BR>Body=20
recently issued certification report P.153.<BR></FONT></DIV>
<DIV><FONT face=3DArial>The target claims</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV>
<TABLE=20
style=3D"BORDER-RIGHT: medium none; BORDER-TOP: medium none; =
BORDER-LEFT: medium none; BORDER-BOTTOM: medium none; BORDER-COLLAPSE: =
collapse; mso-border-alt: solid windowtext .5pt; mso-padding-alt: 0in =
5.4pt 0in 5.4pt"=20
cellSpacing=3D0 cellPadding=3D0 border=3D1>
  <TBODY>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: windowtext 0.5pt solid; PADDING-LEFT: 5.4pt; =
PADDING-BOTTOM: 0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: =
0in; BORDER-BOTTOM: windowtext 0.5pt solid"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>9.<?xml:namespace prefix =3D o ns =3D=20
      "urn:schemas-microsoft-com:office:office"=20
      /><o:p></o:p></FONT></FONT></SPAN></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: windowtext 0.5pt solid; PADDING-LEFT: 5.4pt; =
PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-left-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly"><B=20
      style=3D"mso-bidi-font-weight: normal"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>Q.QRIGIN<o:p></o:p></FONT></FONT></SPAN></B></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: windowtext 0.5pt solid; PADDING-LEFT: 5.4pt; =
PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-left-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>FCO_NRO.2<o:p></o:p></FONT></FONT></SPAN></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: windowtext 0.5pt solid; PADDING-LEFT: 5.4pt; =
PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-left-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>This requirement ensures that the TOE=20
      generates<o:p></o:p></FONT></FONT></SPAN></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>evidence of origin fortransmitted public=20
      key<o:p></o:p></FONT></FONT></SPAN></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>The TOE must generate evidence=20
      of<o:p></o:p></FONT></FONT></SPAN></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      =
size=3D2>certificates:<o:p></o:p></FONT></FONT></SPAN></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>origin for transmitted public=20
      key<o:p></o:p></FONT></FONT></SPAN></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>certificates.<o:p></o:p></FONT></FONT></SPAN></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2><B style=3D"mso-bidi-font-weight: =
normal"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt">FCO_NRO.2=20
      </SPAN></B><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt">ensures that =
evidence=20
      of origin is<o:p></o:p></SPAN></FONT></FONT></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>generated for certificates, CRLs, and ARLs so=20
      the<o:p></o:p></FONT></FONT></SPAN></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>identity of the originator can be related to=20
      the<o:p></o:p></FONT></FONT></SPAN></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      =
size=3D2>information.<o:p></o:p></FONT></FONT></SPAN></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>10.<o:p></o:p></FONT></FONT></SPAN></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly"><B=20
      style=3D"mso-bidi-font-weight: normal"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>Q.RECEIPT<o:p></o:p></FONT></FONT></SPAN></B></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>FCO_NRR.2<o:p></o:p></FONT></FONT></SPAN></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>This requirement ensures that the TOE=20
      generates<o:p></o:p></FONT></FONT></SPAN></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>evidence of receipt for transmitted public=20
      key<o:p></o:p></FONT></FONT></SPAN></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>The TOE must generate evidence=20
      of<o:p></o:p></FONT></FONT></SPAN></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      =
size=3D2>certificates:<o:p></o:p></FONT></FONT></SPAN></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>receipt fortransmitted public=20
      key<o:p></o:p></FONT></FONT></SPAN></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>certificates.<o:p></o:p></FONT></FONT></SPAN></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2><B style=3D"mso-bidi-font-weight: =
normal"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt">FCO_NRR.2=20
      </SPAN></B><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt">ensures that =
evidence=20
      of receipt is<o:p></o:p></SPAN></FONT></FONT></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>generated automatically for public key=20
      certificates<o:p></o:p></FONT></FONT></SPAN></DIV></TD></TR>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: windowtext 0.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: windowtext 0.5pt solid; mso-border-top-alt: solid =
windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: exactly; =
tab-stops: decimal 78.5pt"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><FONT=20
      face=3DArial><FONT size=3D2>&nbsp;<SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: =
12.0pt"><o:p></o:p></SPAN></FONT></FONT></DIV></TD>
    <TD=20
    style=3D"BORDER-RIGHT: windowtext 0.5pt solid; PADDING-RIGHT: =
5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: =
0in; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: =
windowtext 0.5pt solid; mso-border-left-alt: solid windowtext .5pt; =
mso-border-top-alt: solid windowtext .5pt"=20
    vAlign=3Dtop>
      <DIV class=3Dt4=20
      style=3D"LINE-HEIGHT: 11.05pt; mso-line-height-rule: =
exactly"><SPAN=20
      style=3D"FONT-SIZE: 9pt; mso-bidi-font-size: 12.0pt"><FONT =
face=3DArial><FONT=20
      size=3D2>received via SEP or=20
    =
PKIX-CMP.<o:p></o:p></FONT></FONT></SPAN></DIV></TD></TR></TBODY></TABLE=
></DIV>
<DIV><FONT size=3D2><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3>The certification report indicates =
that Entrust/RA=20
provides both SFRs: FCO_NRO(2) and</FONT></DIV>
<DIV><FONT face=3DArial size=3D3>SFR_NRR(2) (Section O).</FONT></DIV>
<DIV><FONT face=3DArial size=3D3></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3>This implies, given the criteria, that =
'the=20
sub-protocol in PKIX-CMP for returning the</FONT></DIV>
<DIV><FONT size=3D3><FONT face=3DArial>necessary </FONT><FONT =
face=3DArial>evidence of=20
receipt&nbsp;of a public-key&nbsp;certificate' is "correct".=20
</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D3></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3>This implies that, should any "user =
data" be=20
attached to the message that</FONT></DIV>
<DIV><FONT face=3DArial size=3D3>delivers the certificate via PKIX-CMP, =
and the=20
automatic receipt is</FONT></DIV>
<DIV><FONT size=3D3><FONT face=3DArial>generated, then there is now, a =
citable=20
method for NR for arbitrary data.</FONT></FONT></DIV>
<DIV><FONT size=3D3><FONT face=3DArial>Any protocol using =
receipt-evidentary methods=20
compatible with PKIX-CMP can </FONT></FONT></DIV>
<DIV><FONT size=3D3><FONT face=3DArial>now realistically get =
</FONT></FONT><FONT=20
size=3D3><FONT face=3DArial>certified as doing "proof of receipt with=20
non-repudiation."</FONT><BR></DIV></FONT>
<DIV><FONT face=3DArial size=3D3>It would be fascinating to know if the =
PKIX-CMP=20
certificates involved&nbsp;have the</FONT></DIV>
<DIV><FONT color=3D#0000ff><FONT face=3DArial color=3D#000000 =
size=3D3>NR bit set, in=20
practice. Perhaps the Entrust ITSEC engineers will tell=20
us.</FONT><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D3>Set or not set, there are interesting =
implications=20
of the certification</FONT></DIV>
<DIV><FONT face=3DArial size=3D3>report due to the design of =
</FONT><FONT=20
color=3D#0000ff><FONT color=3D#000000><FONT face=3DArial =
size=3D3>PKIX-CMP=20
"receipt-oriented" security services.</FONT></FONT></FONT></DIV>
<DIV><FONT color=3D#0000ff><FONT color=3D#000000><FONT face=3DArial =
size=3D3><FONT=20
face=3D"Times New Roman" =
size=3D3></FONT></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3>The CC do say, in informational =
annexes that:=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D3></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3>"The PP/ST author must specify the =
conditions that=20
must be met to be able to verify</FONT></DIV>
<DIV><FONT face=3DArial size=3D3>the validity of the evidence. An =
example of a=20
condition which could be specified is</FONT></DIV>
<DIV><FONT face=3DArial size=3D3>where the verification of evidence =
must occur=20
within 24 hours. These conditions,</FONT></DIV>
<DIV><FONT face=3DArial size=3D3>therefore, allow the tailoring of the=20
non-repudiation to legal requirements, such as</FONT></DIV>
<DIV><FONT face=3DArial size=3D3>being able to provide evidence for =
several=20
years."</FONT></DIV>
<DIV><FONT face=3DArial size=3D3></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3>I have not found the words in the =
Entrust ST which=20
satisfy this requirement,</FONT></DIV>
<DIV><FONT face=3DArial size=3D3>yet.&nbsp;When we do, we can see some =
of the legal=20
implications.</FONT></DIV>
<DIV><FONT face=3DArial size=3D3></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3>We seem to be making some concrete =
progress on NR,=20
both technical</FONT></DIV>
<DIV><FONT face=3DArial size=3D3>and legal, thanks to the world of =
public disclosure=20
of STs.</FONT></DIV>
<DIV><FONT face=3DArial size=3D3></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3>Peter.</FONT></DIV>
<DIV><FONT face=3DArial size=3D3></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff>-----Original =
Message-----<BR>From: Peter=20
Williams [</FONT><A href=3D"mailto:[e-mail]"><FONT=20
face=3DArial>mailto:[e-mail]</FONT></A><FONT face=3DArial=20
color=3D#0000ff>]<BR>Sent: Friday, April 20, 2001 12:06 PM<BR>To: 'Tom=20
Gindin'<BR>Cc: [e-mail]<BR>Subject: RE: Meaning of=20
Non-repudiation<BR><BR><BR>When NIST?NSA folk evaluate a US network=20
product/system, formally,<BR>they must, traditionally, use the =
following=20
conceptions of NR.<BR>(Steve's notions of subject intent, and =
presumptions of=20
signature<BR>binding, are not relevant to a formal evaluation of a=20
product/system<BR>claiming to provide NR.)<BR><BR>It would be useful =
for some of=20
our friends from NCSC/NIST<BR>to perhaps find an actual =
evaluation/certification=20
report<BR>that certified an actual network product/system as meeting=20
the<BR>evaluation criteria for NR. This would provide us<BR>with an =
example=20
protocol under the Red Book<BR>that was deemed "correct", as required =
by the=20
criteria.<BR><BR>&nbsp;</FONT><FONT face=3DArial=20
color=3D#0000ff></DIV></FONT></FONT></BODY></HTML>

--Boundary_(ID_SfLmk2uDh9TAn0Z2MPBRvw)--


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA14893 for <[e-mail]>; Fri, 20 Apr 2001 15:22:29 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id SAA03884; Fri, 20 Apr 2001 18:22:27 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 20 Apr 2001 18:22:22 -0400
To: Denis Pinkas <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Denis,

My comments are in line.

At 06:50 PM 4/20/01 +0200, Denis Pinkas wrote:
>[Denis] This is the case I had in mind. However I would disagree to say that
>the locally contructed CRL is equal to the full CRL number 8, because there
>is no need to issue such CRL (see the first comment). It is simply the
>"freshest CRL constructed from the base CRL number 5 for 3:10 am". This
>locally contructed CRL bears no number, or if you assign one, this is a
>local matter and is not part of the standard. This also avoids the later
>confusing between CRL numbers.

This is simply not true. A delta-CRL can (will) contain the cRLNumber extension just as a full CRL will. If a full CRL and a delta-CRL are issued at the same time, the combination of the delta-CRL and an appropriate base CRL must be equivalent to the full CRL, and both the delta-CRL and the full CRL must have the same cRLNumber. If a delta-CRL is issued, and no corresponding full CRL issued, then the combination of the delta-CRL and an appropriate base CRL should be equivalent to the full CRL that would have been issued at that time, if a full CRL had been issued. The delta-CRL should have the same cRLNumber as would have been assigned to a full CRL issued at the same time.

A delta-CRL is nearly the same as a full CRL. It has a thisUpdate, nextUpdate, cRLNumber, etc. just as a full CRL. It just has an incomplete list of revoked certificates.

> > A few hours later, at 6:30am, the relying party performs another validation. The relying party has, in its local cache, the contents of CRL number 8 (which it constructed at 3:10am). It wants to update the information in its local case to based on the newly available revocation information. So, it obtains the latest delta-CRL. This delta-CRL has a CRL number of 11 and a BaseCRLnumber of 5. Since it has a BaseCRLNumber of 5, the delta-CRL provides status information for all certificates whose status has changed since CRL number 5 was issued. (midnight). So, clearly the delta-CRL provides status information for all certificates whose status has changed since 3:00am when CRL number 8 was issued. Thus, the relying party can combine the delta-CRL with its locally cached version of full CRL number 8 to obtain the contents of CRL number 11. This is a case where the CRL number of the complete CRL used is greater than the BaseCRLNumber specified in the delta-CRL.
>
>[Denis] This is a local matter and I would not mandate this in the document
>since there is another and simpler way to do it: you keep in the cache the
>base CRL (instead of the previously recontructed full CRL). This has the
>same end result, except that the method your recommend is not optimum: it
>will include many duplicates and deleting the duplicates is more painfull
>than making a simple addition.

I'm not sure what you are saying is a local matter. The contents of the delta-CRL is not a local matter and must be mandated in the certificate and CRL profile. If you prefer to always apply the delta-CRLs to the referenced base CRL instead of to a locally generated, more recent CRL, that is your choice. The document states that the delta-CRL may be combined with the referenced base CRL or a more recently issued full CRL.

>The basic algorithm is to take the base CRL and to add the delta. This is
>the standard. As soon as you get the same end result this is fine. This is
>the approach we have taken for path validation. Other ways do not need to be
>mentionned.
>
> > There are other reasons why the two numbers may not match, but I will not go into them. If you are interested, you can read my paper.
>
>[Denis] I read it (and skipped the mathematical formulas)
>
>This paper is proposing a method for over-issuing the CRLs. It omits to take
>into consideration that in PKIX-1 we mandate the CRL number extension
>(section 5.2.3) so we need to advertise the nextUpdate. If you issue a CRL
>before the next update you have no more way to know which base CRL is the
>freshest CRL. I believe this is a major security weakness and for that
>reason this mechanism should be deprecated.

The paper does discuss over-issuing of CRLs, but there is plenty of information about using delta-CRLs efficiently without over-issuing. Bear in mind, however, that the nextUpdate field only specifies the time by which a new CRL will be issued. Many people intend to issue a new CRL whenever a revocation occurs (or a revocation for key compromise) without waiting until the regularly scheduled time.

>BTW, the same security problem would occur as soon as a base would be used
>for every delta. Hence another good reason to delete the sentence which
>originally triggered all this discussion.

I don't understand this at all.

>BTW, I noticed that you have precisely deleted from my previous e-mail all
>the text dealing with this nextUpdate. :-( 
>
>So I am still insisting on the major text change to make to that section:
>
>    An application can construct a CRL that is the most current for 
>    a given scope, at the current time, by retrieving the current 
>    base CRL for that scope, and combining it with a delta-CRL which 
>    contains a Delta CRL Indicator equal to the cRLNumber of the base 
>    CRL and where the current date from that delta-CRL is between 
>    thisUpdate and nextUpdate;
>
>It is important to notice that the algorithm does NOT use the individual CRL
>numbers assigned to the delta-CRLs, but uses instead thisUpdate and
>nextUpdate. This is *very* important.

I thought I did respond to this. First, one should expect that delta-CRLs will always be at least as recent as base CRLs. So the first step should be to obtain the current delta-CRL. Next, one obtains a base CRL that can be used in combination with that delta-CRL. You may choose to only use the full CRL whose cRLNumber is equal to the BaseCRLNumber specified in the delta-CRL, however, any full CRL with a cRLNumber greater than or equal to the BaseCRLNumber is acceptable. Since the cRLNumber of the base can be greater than the specified BaseCRLNumber, the document should say so. There is no need to state that the current time must be after the thisUpdate time in the delta-CRL as this will always be true by construction. Finally, since a CRL issuer may issue "emergency" delta-CRLs, there is no guarantee that any delta-CRL whose nextUpdate time is later than the current time is the most current delta-CRL.

> > >Finally we should explain what happens at the boundaries, i.e. when a CA
> > >decides to generate a (new) base CRL. Here is a text proposal:
> > >
> > >   When issuing a base CRL that supports a delta-CRL mechanism then the
> > >   CRL Issuer MUST at the same time issue a delta CRL that points to that
> > >   base CRL. This first delta CRL will usually be empty (or will include
> > >   last-minute additions to the base CRL).
> > 
> > This is not acceptable. The rule is that when a base CRL is issued a delta-CRL must be issued that has the same cRLNumber. The base CRL referenced by the delta must either be the previously issued base CRL or a base CRL issued before that one. Since the new base and the delta must have the same cRLNumber, there can be no differences as a result of "last-minute additions to the base CRL".
>
>[Denis] This does not work. Let me explain it differently. Suppose that
>during the week you do not generate delta-CRLs but for the week-end you
>decide to do it (e.g. more risk, more transactions done by citizens). So you
>issue a CRL with the freshest CRLindicator. You say that the delta points to
>the previous base CRL. The one from yesterday or the one from last week ? 
>In either case this simply does not work.

Why? A delta-CRL must include a BaseCRLNumber that corresponds to a CRL that was issued at some time in the past.

>The rule you mention, i.e. "The rule is that when a base CRL is issued a
>delta-CRL must be issued that has the same cRLNumber" is also wrong. The
>notion of a base CRL that would have the same number as a delta does not
>exist.
>
> > >Suppose we issue a base CRL every midnight. The question is whether we
> > >should issue a delta and, if yes, does this delta refer to the previous
> > >base or to the new one ?
> > 
> > The delta must refer either to the previous base or a base issued before the previous base.
>
>[Denis] Certainly not. Your paper however provides the right answer
>(on page 1): " A delta-CRL is a CRL that only provides information about
>certificates who statuses have changed since the issuance of a specific,
>previously issued CRL".

Where is the difference? A CRL that is referenced in the BaseCRLNumber of a delta-CRL is by definition a base CRL.

> > >Suppose it refers to the previous one. According to the current sentence:
> > >"The constructed CRL has the CRL number specified in the CRL number
> > >extension found in the delta CRL used in its construction.", it is
> > >impossible. If that was the case the delta CRL would have a CRL number equal
> > >to the base CRL and it is not allowed for two CRLs to have the same CRL
> > >number.
>  
> > I think you are confusing two different extensions. The deltaCRLIndicator extension contains a BaseCRLNumber which is used to determine against which base CRLs the delta-CRL can be applied. The cRLNumber extension specifies the CRL number of the full CRL that will be generated by applying the delta-CRL to a base CRL. The sentence above states that the CRL number of the constructed CRL is taken from the cRLNumber extension, not the BaseCRLNumber of the deltaCRLIndicator extension.
>
>[Denis] I do not think I make a confusion. The confusion comes from the
>numbering you introduce (see my earlier comment).
>
>Let me conclude:
>
>1) I do not have the time to spend hours of discussions on that topic.
>However the current text needs to be corrected and I have provided text
>for this. Please take again a look at it in the light of the following.
>
>2) In your paper you advertise the "traditional delta-CRLs". Let us stay in
>the tradition and let us mandate the implementation of the "tradition" if
>someone wans to support the delta-CRL mechanism.
>
>Any other method would first need to be proven to be secure (over-issuing
>CRLs and sliding window delta-CRLs have security problems) and should
>*anyway* fall in the MAY category, so that noone needs to implement to claim
>conformance with the delta CRL mechanism. Standard track documents need to
>make choices among multiple methods, otherwise two different implementations
>will never interoperate.

you say that you want to stick with "traditional" delta-CRLs, however you are proposing changes to the text that would not result in "tradtional" delta-CRLs but would result in broken implementations. We do not prevent people from implementing "traditional" delta-CRLs, but we should not force them to either. There are no security problems with sliding window delta-CRLs and they do not add any complexity for those who choose not to implement them.

I want to be sure that the delta-CRL text is correct just as you do, but I still feel that many of your comments are based on a misunderstanding and are not based on actual problems in the text.

Dave



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA12055 for <[e-mail]>; Fri, 20 Apr 2001 14:32:17 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JJPVT1HQ>; Fri, 20 Apr 2001 17:31:49 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Frank Balluffi'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Use of PKIMessages
Date: Fri, 20 Apr 2001 17:26:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9E0.8C8BE6D0"

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_01C0C9E0.8C8BE6D0
Content-Type: text/plain

Hi Frank,

Yes, Section 5.4 of RFC 2510 and Appendix G of rfc2510bis-03 are used to
carry a single PKIMessage at a time.

Carlisle.


> ----------
> From: 	Frank Balluffi[SMTP:[e-mail]]
> Sent: 	Wednesday, April 18, 2001 1:05 PM
> To: 	'[e-mail]'; '[e-mail]'
> Subject: 	CMP: Use of PKIMessages
> 
> Carlisle and Stephen,
> 
> draft-ietf-pkix-rfc2510bis-03.txt defines PKIMessages as:
> 
> PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
> 
> whereas RFC 2510 uses PKIMessages within its text, but does not define the
> type.
> 
> Am I correct in assuming that section 5.4 of RFC 2510 and Appendix G of
> draft-ietf-pkix-rfc2510bis-03.txt describe methods for transporting
> PKIMessage, not PKIMessages. Thanks.
> 
> Frank
> 

------_=_NextPart_001_01C0C9E0.8C8BE6D0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

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

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Frank,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Yes, =
Section 5.4 of RFC 2510 and Appendix G of rfc2510bis-03 are used to =
carry a single PKIMessage at a time.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Frank =
Balluffi[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Wednesday, April 18, 2001 1:05 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">'[e-mail]'; '[e-mail]'</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">CMP: Use of PKIMessages</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carlisle and Stephen,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">draft-ietf-pkix-rfc2510bis-03.txt =
defines PKIMessages as:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">PKIMessages ::=3D SEQUENCE SIZE =
(1..MAX) OF PKIMessage</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">whereas RFC 2510 uses PKIMessages =
within its text, but does not define the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">type.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Am I correct in assuming that section =
5.4 of RFC 2510 and Appendix G of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">draft-ietf-pkix-rfc2510bis-03.txt =
describe methods for transporting</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PKIMessage, not PKIMessages. =
Thanks.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Frank</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C0C9E0.8C8BE6D0--


Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA07281 for <[e-mail]>; Fri, 20 Apr 2001 13:34:34 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010420203201.ZPPP26961.femail3.sdc1.sfba.home.com@revelation>; Fri, 20 Apr 2001 13:32:01 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, <[e-mail]>
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)
Date: Fri, 20 Apr 2001 13:37:19 -0700
Message-ID: <002601c0c9d9$b2979a60$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C0C99F.0638C260"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0027_01C0C99F.0638C260
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n
ew-part1-06.txt comments)Sharon,

I actually completely agree with the basic point here.  Once I (a CA) have
issued a certificate to an entity, I cannot control anything about how they
will use it.  All I can do is try and put hints in for relying parties to
catch it when that entity is doing "un-approved" things.

Just to verify the basic answer.  X.509 has a set of extensions that the
PKIX group did not adopt for dealing with attribute certificates.   PKI
certs use basicContraints, AC certs use basicAttConstraints to control the
"a think that the entity ought to..." type statements.  This means that the
arguement here, in the PKIX group, does not have a similar arguement in the
X.509 group.

jim
  -----Original Message-----
  From: Sharon Boeyen [mailto:[e-mail]]
  Sent: Friday, April 20, 2001 12:57 PM
  To: '[e-mail]'; [e-mail]
  Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n
ew-part1-06.txt comments)


  Jim, I forgot one point that might help understand my view on the
basicConstraints extension. I don't believe that any CA can actually prevent
another entity from issuing certificates purely through technical tools such
as cert extensions. However, a CA can prevent relying parties from trusting
certificates issued by such entities specifically through the business
controls extensions defined in the standards.

  Cheers,
  Sharon

   -----Original Message-----
  From: Sharon Boeyen [mailto:[e-mail]]
  Sent: Friday, April 20, 2001 3:05 PM
  To: '[e-mail]'; Sharon Boeyen; [e-mail]
  Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n
ew-part1-06.txt comments)


    The point that I think is a bit different is the use of the CA bit in
basic constraints. This is one of many 'business controls' that a CA can put
into a certificate that it issues to another CA to restrict the set of paths
(including that certificate) that can be successfully validated. In my mind
this extension exists so that a relying party can know whether the
certificate they are processing is one that certifies a key that can be used
to verify the signature of the next cert in the path. Full stop. It isn't an
'authorization' of any entity to issue certificates but a signal to the
relying party that the certified key can be used for verifying the next
signature. The pathLengthConstraint component of that extension, along with
all the other business control extensions (policy stuff, name constraints
etc) further retrict a relying party with respect to the certification paths
(and contained certificates) that can be successfully validated using the
certificate that contains the extensions. Each issuer has the ability to
place such restrictions and the complete validation of the path depends, in
part on those constraints.

    When we look at the two basic trust models (hierarchical and
distributed), then this does get muddled somewhat, because in a hierarchy
there is sort of a sense of 'authorization' of subordinate CAs. The same is
not true in a distributed trust model. A CA is any entity that issues
public-key certificates regardless of whether some other CA happens to have
issued it a certificate containing the basic constraints extension with the
CA bit set to true. The extension really only matters when one tries to
validate a certification path and needs to be sure that the issuer of a
particular certificate 'trusts' certificates signed with the key
corresponding to that certified in the current certificate.

    Consider the above 2 paragraphs my personal opinion on basicConstraints.

    As for attribute certificates and attribute authorities, in some
environments there is absolutely no need to tie the PMI to the PKI. The
verifiers may import one or more trust anchors for SOAs, similar to how they
do today for PKI trust anchors. However, in other environments, there was a
requirement to have a single trust anchor and be able to validate both
public key and attribute certificates. For this reason, X.509 added the
sOAIdentifier extension. Its syntax is NULL. Its only purpose in life is to
support this requirement of binding a PMI to a PKI.  As for the attribute
certificate 'equivalent' of a certification path, this is a delegation path.
There are completely different extensions defined to ensure that a
delegationPath is valid (although you will recognize similarities).
basicAttConstraints inidicates whether or not the assigned privilege can be
further delegated by the subject of the containing certificate. 'Business
controls' extensions include delegatedNameConstraints,
acceptableCertPolicies, authorityAttributeIdentifier (to ensure that the
delegating authority actually holds sufficicient privilege to delegate it)
etc). Don't try to shoehorn the PKI extensions into the PMI model. The only
real overlap is that we reused the basic CRL structure.

    Hope that helps and doesn't confuse the issues further :-)

    Sharon

     -----Original Message-----
    From: Jim Schaad [mailto:[e-mail]]
    Sent: Friday, April 20, 2001 2:08 PM
    To: 'Sharon Boeyen'; [e-mail]
    Subject: RE: cA flag and CRL issuers (was Re: Last Call:
draft-ietf-pkix-n ew-part1-06.txt comments)


      Sharon,

      Much of this question arose from how to deal with AC "authorities".  I
don't have access at the moment to the X. version of the AC draft (yes I
know I can now get it), but do you believe that AC issuers and "revokers"
need to be authorities in that the CA bit should be set for them?

      jim
        -----Original Message-----
        From: Sharon Boeyen [mailto:[e-mail]]
        Sent: Friday, April 20, 2001 9:57 AM
        To: 'David A. Cooper'; [e-mail]
        Subject: RE: cA flag and CRL issuers (was Re: Last Call:
draft-ietf-pkix-n ew-part1-06.txt comments)


        Just to be clear, lets not confuse what I may happen to want as
        an individual contributor to PKIX or any other list, with what
        I state as 509 editor (they're not necessarily always the same :-)

        My comments were purely from the editor's perspective and yes,
        the current 509 text is quite clear that the CA that issues a
        certificate is responsible for stating whether or not that
certificate
        can be revoked, and if so, what mechanism is used to inform
        relying parties. If that mechanism is CRLs, these are issued by
        the certificate issuer or by another authority delegated that
        task by the certificate issuer (that doesn't necessarily mean that
        509 requires a cert to be issued to that authority, nor that the
cert
        contain the basic constraints extension though, that is the job of
        profile groups to determine and incidentally I don't believe they'll
        all adopt the same solution so I would want 509 to remain flexible).

        My own personal view is that industry has moved to a point where
there
        probably isn't any real requirement for a CRL issuer to also be a
cert
        issuer as long as that CRL issuer is delegated that responsibility
        by the cert issuer and there is a cryptographic way to ensure that
        binding for relying parties. To achieve that, I believe some changes
        are required in 509.

        On the separate keys for cert and CRL signing (by the same
authority), my
        personal opinion is that anything you read into 509 text on that
specific
        topic would be accidental as I don't recall any specific discussion
on it.
        However, since that is a real world requirement, I would want to be
sure
        that 509 did not prohibit it.

        Hope that clarifies where my comments are coming from :-)


        > -----Original Message-----
        > From: David A. Cooper [mailto:[e-mail]]
        > Sent: Friday, April 20, 2001 11:44 AM
        > To: [e-mail]
        > Subject: RE: cA flag and CRL issuers (was Re: Last Call:
        > draft-ietf-pkix-n ew-part1-06.txt comments)
        >
        >
        > Sharon,
        >
        > Are you suggesting that in order for an entity to issue CRLs
        > on behalf of a certificate issuer, that CRL issuer would need
        > to issue certificates as well (so that it can qualify as an
        > authority)?  I don't think there should be such a
        > requirement, but even if there were it wouldn't settle the issue.
        >
        > Even if only authorities can issue CRLs, there is nothing to
        > prevent that authority from using different keys to sign
        > certificates and CRLs.  X.509 states that "[t]he cA component
        > indicates if the certified public key may be used to verify
        > certificate signatures."  So, the proper value of the cA bit
        > is determined by the allowable uses of the subject public
        > key, not by the type of entity the subject is.  So, even if
        > the certificate subject is a CA, and issues certificates
        > under some key, the cA bit should not be set unless the
        > particular subject public key in the certificate can be used
        > to verify certificate signatures. If an authority is the
        > subject of a certificate and the particular public key of
        > that authority that is being certified is only to be used to
        > verify signatures on CRLs, then the cA bit should not be set.
        >
        > Dave
        >
        > At 10:48 AM 4/20/01 -0400, Sharon Boeyen wrote:
        >
        > >David, sorry but I disagree with your assertions about X.509's
        > >position on this issue. Either by design or by accident,
        > X.509 requires that if CRLs are being issued, they are issued
        > by an 'authority'. Remember that the definition of
        > "authority" is "An entity responsible
        > >
        > >for the issuance of certificates". Much of the text in X.509
        > predates OCSP or the concept of a validation authority, but I
        > do know that the quotes below are new text added within the
        > past couple of years with the intent of clarifying the role
        > of CAs with respect to CRLs.
        > >
        > >Clause 7.3 says:
        > >
        > >"An authority that issues certificates is required to state,
        > possibly through a published statement of their practices,
        > through the certificates themselves, or through some other
        > identified means, whether:
        > >
        > >-       The certificates cannot be revoked; or
        > >-       The certificates may be revoked by the same
        > certificate-issuing authority directly; or
        > >-       The certificate-issuing authority authorizes a
        > different authority to perform revocation."
        > >
        > >further down in the same clause is the text:
        > >
        > >"
        > >An authority that issues and subsequently revokes certificates:
        > >a)      may be required to maintain an audit record of its
        > revocation events for all certificate types issued by that
        > authority (e.g. public-key certificates, attribute
        > certificates issued to end-entities as well as other authorities);
        > >
        > >b)      shall provide revocation status information to
        > relying parties using CRLs, on-line certificate status
        > protocol or some other mechanism for the publication of
        > revocation status information;
        > >
        > >c)      if using CRLs, shall maintain and publish CRLs even
        > if the lists of revoked certificates are empty."
        > >
        > >The quotes that you included in your message tie in with
        > this base text, since the authority that issued the
        > certificates has these responsibilities around revocation,
        > there was no need for X.509 to state anything specific to CRL
        > issuance. In the indirect CRL case, this was envisioned to be
        > another CA or AA, that combined revocation notices from
        > several CAs/AAs.
        > >
        > >Having said that (with my X.509 editor's hat on), if there
        > is a requirement to have entities that are not CAs or AAs be
        > authorized to issue CRLs on behalf of the certificate issuer
        > (because remember that a CRL is an indication that a
        > certificate is no longer considered valid "by its
        > issuer")changes to X.509 would be needed. I'm not necessarily
        > opposed to such changes, I'm just clarifying, in this
        > message, that they would be needed in order for such
        > implementations to be conformant. This, as usual could be
        > done through the enhancements work or could be proposed
        > through the defect process. One way to enable that kind of
        > change might be to redefine authority and to talk about 3
        > types rather than two. However, it would take some careful
        > review to ensure that the set of changes was thorough and
complete.
        > >
        > >Sharon
        > >
        > > > -----Original Message-----
        > > > From: David A. Cooper
        > [<mailto:[e-mail]>mailto:[e-mail]]
        > > > Sent: Thursday, April 19, 2001 5:08 PM
        > > > To: [e-mail]
        > > > Subject: cA flag and CRL issuers (was Re: Last Call:
        > > > draft-ietf-pkix-new-part1-06.txt comments)
        > > >
        > > >
        > > > At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:
        > > > >Dave Cooper,
        > > > >
        > > > >>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:
        > > > >>I see no basis in X.509 for setting the cA flag in
        > > > basicConstraints for certificate subjects that can issue CRLs
        > > > but not certificates. The current discussion about how to
        > > > deal with CRLs for attribute certificates vs. public key
        > > > certificates just further goes to show that it was a mistake
        > > > to suddenly change the rules at the last IETF meeting.
        > > > >
        > > > >We disagree on this point. Nowhere in X.509 or in previous
        > > > PKIX documents has there ever been text to suggest that other
        > > > than a CA can sign a CRL for a public key certificate. So,
        > > > the rules were not changed at the last meeting, they were
        > > > reasserted and clarified.
        > > >
        > > > Steve,
        > > >
        > > > You may say that X.509 and PKIX do not suggest that entities
        > > > other than CAs can sign CRLs. However, I think we all agree
        > > > that both X.509 and PKIX allow for a CRL to be signed with a
        > > > different key than the key used to sign the certificates that
        > > > are covered by that CRL. This may be a result of the CA that
        > > > issued the certificates signing the corresponding CRLs with a
        > > > different key or the CA that issued the certificates
        > > > delegating the CRL issuing to another entity (via the
        > > > distribution points extension). There is no requirement that
        > > > the key used to sign the CRL also be used to sign
        > > > certificates. So, I think we agree that there will be times
        > > > where we will be issuing certificates to entities (whether
        > > > those entities are CAs or not) where the intent is to specify
        > > > that the public keys in the certificates may be used to
        > > > verify signatures on CRLs but not on certificates.
        > > >
        > > > The only place we seem to disagree is on the contents of the
        > > > certificates issued in such circumstances. In particular,
        > > > should the certificates contain a basicConstraints extension
        > > > with the cA bit set? On this point, both X.509 and the
        > > > previous PKIX documents are quite clear that the cA bit
        > > > should not be set. Why? Because a CA is defined as an entity
        > > > that issues public-key certificates and both documents
        > > > similarly state that the cA bit is used to specify whether
        > > > the certificate subject can issue certificates. There is no
        > > > similar connection made between being a CA and issuing CRLs.
        > > >
        > > >
        > > > The following are some quotes from X.509 and
pkix-new-part1-05:
        > > >
        > > > In X.509 a CA is defined as "[a]n authority trusted by one or
        > > > more users to create and assign public-key certificates."
        > > >
        > > > Section 7 of X.509 states that "[a] CA-certificate is a
        > > > certificate issued by a CA to a subject that is itself a CA
        > > > and therefore is capable of issuing public-key certificates."
        > > >
        > > >
        > > > The description of basic constraints in X.509 further
        > > > supports the idea that the cA bit is used to specify
        > > > certificate issuing, not certificate and/or CRL issuing:
        > > >
        > > > "This field indicates if the subject may act as a CA, with
        > > > the certified public key being used to verify certificate
        > > > signatures. ... The cA component indicates if the certified
        > > > public key may be used to verify certificate signatures. ...
if
        > > > the value of cA is not set to true then the certified public
        > > > key shall not be used to verify a certificate signature"
        > > >
        > > >
        > > > pkix-new-part1-05 states something similar:
        > > >
        > > > "The cA bit indicates if the certified public key may be used
        > > > to verify signatures on other certificates. If the cA bit is
        > > > asserted, then the keyCertSign bit in the key usage extension
        > > > (see 4.2.1.3) MUST also be asserted. If the cA bit is not
        > > > asserted, then the keyCertSign bit in the key usage extension
        > > > MUST NOT be asserted."
        > > >
        > > >
        > > > The description of the key usage bits are consistent with
        > > > this as well.
        > > >
        > > > X.509:
        > > > "The bit keyCertSign is for use in CA-certificates only. If
        > > > KeyUsage is set to keyCertSign and the basic constraints
        > > > extension is present in the same certificate, the value of
        > > > the cA component of that extension shall be set to TRUE."
        > > >
        > > > pkix-new-part1-05:
        > > > "The keyCertSign bit is asserted when the subject public key
        > > > is used for verifying a signature on certificates.  This bit
        > > > may only be asserted in CA certificates.  If the keyCertSign
        > > > bit is asserted, then the cA bit in the basic constraints
        > > > extension (see 4.2.1.10) MUST also be asserted. If the
        > > > keyCertSign bit is not asserted, then the cA bit in the basic
        > > > constraints extension MUST NOT be asserted.
        > > >
        > > > The cRLSign bit is asserted when the subject public key is
        > > > used for verifying a signature on revocation information
        > > > (e.g., a CRL)."
        > > >
        > > >
        > > >
        > > > So, both X.509 and pkix-new-part1-05 go to great lengths to
        > > > clearly state that only CAs can issue certificates and that
        > > > basicConstraints with the cA bit set to true must be present
        > > > in the certificates where the public key is to be used to
        > > > verify signatures on certificates. There are no similar
        > > > statements about CRLs. In fact, both documents are quite
        > > > clear that the cA bit must not be set when the subject public
        > > > key can not be used to verify certificates. So, if the
        > > > subject public key can be used to verify CRLs, but not
        > > > certificates, the cA bit must not be set.
        > > >
        > > > X.509 is also careful not to preclude the public keys of
        > > > non-CAs from being used to verify signatures on CRLs. For
        > > > instance, an end entity is defined as "[a] certificate
        > > > subject that uses its private key for purposes other than
        > > > signing certificates or an entity that is a relying party."
        > > > This leaves room for an end entity to use its private key to
        > > > sign CRLs.
        > > >
        > > >
        > > > So, if PKIX wants to require that the cA bit be set whenever
        > > > the subject public key can be used to verify CRLs and also
        > > > wants to maintain consistency with X.509, PKIX would have to
        > > > require that any certificate authorizing the use of a public
        > > > key for verifying CRL signatures also authorize the use of
        > > > that public key for verifying certificate signatures. Since
        > > > we are in agreement that we do not want to impose such a
        > > > restriction and that we do want to maintain consistency with
        > > > X.509, we can not require that the cA bit be set when the
        > > > subject public key can only be used to verify CRL signatures.
        > > >
        > > > Dave
        > > >
        > > >
        >
        >


------=_NextPart_000_0027_01C0C99F.0638C260
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">
<TITLE>RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n =
ew-part1-06.txt comments)</TITLE>

<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D681373220-20042001>Sharon,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D681373220-20042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D681373220-20042001>I=20
actually completely agree with the basic point here.&nbsp; Once I (a CA) =
have=20
issued a certificate to an entity, I cannot control anything about how =
they will=20
use it.&nbsp; All I can do is try and put hints in for relying parties =
to catch=20
it when that entity is doing "un-approved" things.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D681373220-20042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D681373220-20042001>Just=20
to verify the basic answer.&nbsp; X.509 has a set of extensions that the =
PKIX=20
group did not adopt for dealing with attribute certificates.&nbsp;&nbsp; =
PKI=20
certs use basicContraints, AC certs use basicAttConstraints to control =
the "a=20
think that the entity ought to..." type statements.&nbsp; This means =
that the=20
arguement here, in the PKIX group, does not have a similar arguement in =
the=20
X.509 group.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D681373220-20042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D681373220-20042001>jim</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 20, =
2001=20
  12:57 PM<BR><B>To:</B> '[e-mail]';=20
  [e-mail]<BR><B>Subject:</B> RE: cA flag and CRL issuers (was =
Re: Last=20
  Call: draft-ietf-pkix-n ew-part1-06.txt comments)<BR><BR></DIV></FONT>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D176595919-20042001>Jim,=20
  I forgot one point that might help understand my view on the =
basicConstraints=20
  extension. I don't believe that any CA can actually prevent another =
entity=20
  from issuing certificates purely through technical tools such as cert=20
  extensions. However, a CA can prevent relying parties from trusting=20
  certificates issued by such entities specifically through the business =

  controls extensions defined in the standards. </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D176595919-20042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D176595919-20042001>Cheers,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D176595919-20042001>Sharon</SPAN></FONT></DIV>
  <DIV><SPAN class=3D176595919-20042001></SPAN><FONT face=3DTahoma><FONT =

  size=3D2><SPAN class=3D176595919-20042001><FONT color=3D#0000ff=20
  face=3DArial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
  class=3D176595919-20042001>&nbsp;</SPAN>-----Original=20
  Message-----<BR><B>From:</B> Sharon Boeyen=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 20, =
2001 3:05=20
  PM<BR><B>To:</B> '[e-mail]'; Sharon Boeyen;=20
  [e-mail]<BR><B>Subject:</B> RE: cA flag and CRL issuers (was =
Re: Last=20
  Call: draft-ietf-pkix-n ew-part1-06.txt =
comments)<BR><BR></DIV></FONT></FONT>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV><SPAN class=3D934173718-20042001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>The point that I think is a bit different is the use of the =
CA bit in=20
    basic constraints. This is one of many 'business controls' that a CA =
can put=20
    into a certificate that it issues to another CA to restrict the set =
of paths=20
    (including that certificate) that can be successfully validated. In =
my mind=20
    this extension exists so that a relying party can know whether the=20
    certificate they are processing is one that certifies a key that can =
be used=20
    to verify the signature of the next cert in the path. Full stop. It =
isn't an=20
    'authorization' of any entity to issue certificates but a signal to =
the=20
    relying party that the certified key can be used for verifying the =
next=20
    signature. The pathLengthConstraint component of that extension, =
along with=20
    all the other business control extensions (policy stuff, name =
constraints=20
    etc) further retrict a relying party with respect to the =
certification paths=20
    (and contained certificates) that can be successfully validated =
using the=20
    certificate that contains the extensions. Each issuer has the =
ability to=20
    place such restrictions and the complete validation of the path =
depends, in=20
    part on those constraints.&nbsp;&nbsp;</FONT></SPAN></DIV>
    <DIV><SPAN class=3D934173718-20042001></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D934173718-20042001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>When we look at the two basic trust models (hierarchical =
and=20
    distributed), then this does get muddled somewhat, because in a =
hierarchy=20
    there is sort of a sense of 'authorization' of subordinate CAs. The =
same is=20
    not true in a distributed trust model. A CA is&nbsp;any entity that =
issues=20
    public-key certificates regardless of whether some other CA happens =
to have=20
    issued it a certificate containing the basic constraints extension =
with the=20
    CA bit set to true. The extension really only matters when one tries =
to=20
    validate a certification path and needs to be sure that the issuer =
of a=20
    particular certificate 'trusts' certificates signed with the key=20
    corresponding to that certified in the current certificate.=20
    </FONT></SPAN></DIV>
    <DIV><SPAN class=3D934173718-20042001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D934173718-20042001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>Consider the above 2 paragraphs my personal opinion on=20
    basicConstraints. </FONT></SPAN></DIV>
    <DIV><SPAN class=3D934173718-20042001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D934173718-20042001><FONT color=3D#0000ff =
face=3DArial size=3D2>As=20
    for attribute certificates and attribute authorities, in some =
environments=20
    there is absolutely no need to tie the PMI to the PKI. The verifiers =
may=20
    import one or more trust anchors for SOAs, similar to how they do =
today for=20
    PKI trust anchors. However, in other environments, there was a =
requirement=20
    to have a single trust anchor and be able to validate both public =
key and=20
    attribute certificates. For this reason, X.509 added the=20
    sOAIdentifier&nbsp;extension. Its syntax is NULL. Its only purpose =
in life=20
    is to support this requirement of binding a PMI to a PKI.&nbsp; As =
for the=20
    attribute certificate 'equivalent' of a certification path, this is =
a=20
    delegation path. There are completely different extensions defined =
to ensure=20
    that a delegationPath is valid (although you will recognize =
similarities).=20
    basicAttConstraints inidicates whether or not the assigned privilege =
can be=20
    further delegated by the subject of the containing certificate. =
'Business=20
    controls' extensions include delegatedNameConstraints,=20
    acceptableCertPolicies, authorityAttributeIdentifier (to ensure that =
the=20
    delegating authority actually holds sufficicient privilege to =
delegate it)=20
    etc). Don't try to shoehorn the PKI extensions into the PMI model. =
The only=20
    real overlap is that we reused the basic CRL structure. =
</FONT></SPAN></DIV>
    <DIV><SPAN class=3D934173718-20042001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D934173718-20042001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>Hope that helps and doesn't confuse the issues further=20
    :-)</FONT></SPAN></DIV>
    <DIV><SPAN class=3D934173718-20042001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D934173718-20042001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>Sharon</FONT></SPAN></DIV>
    <DIV><SPAN class=3D934173718-20042001></SPAN><FONT =
face=3DTahoma><FONT=20
    size=3D2><SPAN class=3D934173718-20042001><FONT color=3D#0000ff=20
    face=3DArial></FONT></SPAN></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
    class=3D934173718-20042001>&nbsp;</SPAN>-----Original=20
    Message-----<BR><B>From:</B> Jim Schaad=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 20, 2001 =
2:08=20
    PM<BR><B>To:</B> 'Sharon Boeyen'; =
[e-mail]<BR><B>Subject:</B> RE:=20
    cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n=20
    ew-part1-06.txt comments)<BR><BR></DIV></FONT></FONT>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
      <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
      class=3D128290618-20042001>Sharon,</SPAN></FONT></DIV>
      <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
      class=3D128290618-20042001></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
      class=3D128290618-20042001>Much of this question arose from how to =
deal with=20
      AC "authorities".&nbsp; I don't have access at the moment to the =
X.=20
      version of the AC draft (yes I know I can now get it), but do you =
believe=20
      that AC issuers and "revokers" need to be authorities in that the =
CA bit=20
      should be set for them?</SPAN></FONT></DIV>
      <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
      class=3D128290618-20042001></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
      class=3D128290618-20042001>jim</SPAN></FONT></DIV>
      <BLOCKQUOTE=20
      style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
        <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
        size=3D2>-----Original Message-----<BR><B>From:</B> Sharon =
Boeyen=20
        [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April =
20,=20
        2001 9:57 AM<BR><B>To:</B> 'David A. Cooper';=20
        [e-mail]<BR><B>Subject:</B> RE: cA flag and CRL issuers =
(was=20
        Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt=20
        comments)<BR><BR></DIV></FONT>
        <P><FONT size=3D2>Just to be clear, lets not confuse what I may =
happen to=20
        want as </FONT><BR><FONT size=3D2>an individual contributor to =
PKIX or any=20
        other list, with what </FONT><BR><FONT size=3D2>I state as 509 =
editor=20
        (they're not necessarily always the same :-)</FONT> </P>
        <P><FONT size=3D2>My comments were purely from the editor's =
perspective=20
        and yes, </FONT><BR><FONT size=3D2>the current 509 text is quite =
clear=20
        that the CA that issues a </FONT><BR><FONT size=3D2>certificate =
is=20
        responsible for stating whether or not that certificate</FONT> =
<BR><FONT=20
        size=3D2>can be revoked, and if so, what mechanism is used to =
inform=20
        </FONT><BR><FONT size=3D2>relying parties. If that mechanism is =
CRLs,=20
        these are issued by </FONT><BR><FONT size=3D2>the certificate =
issuer or by=20
        another authority delegated that </FONT><BR><FONT size=3D2>task =
by the=20
        certificate issuer (that doesn't necessarily mean that =
</FONT><BR><FONT=20
        size=3D2>509 requires a cert to be issued to that authority, nor =
that the=20
        cert </FONT><BR><FONT size=3D2>contain the basic constraints =
extension=20
        though, that is the job of </FONT><BR><FONT size=3D2>profile =
groups to=20
        determine and incidentally I don't believe they'll =
</FONT><BR><FONT=20
        size=3D2>all adopt the same solution so I would want 509 to =
remain=20
        flexible). </FONT></P>
        <P><FONT size=3D2>My own personal view is that industry has =
moved to a=20
        point where there </FONT><BR><FONT size=3D2>probably isn't any =
real=20
        requirement for a CRL issuer to also be a cert</FONT> <BR><FONT=20
        size=3D2>issuer as long as that CRL issuer is delegated that=20
        responsibility </FONT><BR><FONT size=3D2>by the cert issuer and =
there is a=20
        cryptographic way to ensure that </FONT><BR><FONT =
size=3D2>binding for=20
        relying parties. To achieve that, I believe some changes=20
        </FONT><BR><FONT size=3D2>are required in 509. </FONT></P>
        <P><FONT size=3D2>On the separate keys for cert and CRL signing =
(by the=20
        same authority), my </FONT><BR><FONT size=3D2>personal opinion =
is that=20
        anything you read into 509 text on that specific =
</FONT><BR><FONT=20
        size=3D2>topic would be accidental as I don't recall any =
specific=20
        discussion on it. </FONT><BR><FONT size=3D2>However, since that =
is a real=20
        world requirement, I would want to be sure </FONT><BR><FONT =
size=3D2>that=20
        509 did not prohibit it.</FONT> </P>
        <P><FONT size=3D2>Hope that clarifies where my comments are =
coming from=20
        :-) </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; </FONT></P>
        <P><FONT size=3D2>&gt; -----Original Message-----</FONT> =
<BR><FONT=20
        size=3D2>&gt; From: David A. Cooper [<A=20
        =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</=
FONT>=20
        <BR><FONT size=3D2>&gt; Sent: Friday, April 20, 2001 11:44 =
AM</FONT>=20
        <BR><FONT size=3D2>&gt; To: [e-mail]</FONT> <BR><FONT =
size=3D2>&gt;=20
        Subject: RE: cA flag and CRL issuers (was Re: Last Call:</FONT>=20
        <BR><FONT size=3D2>&gt; draft-ietf-pkix-n ew-part1-06.txt =
comments)</FONT>=20
        <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
        size=3D2>&gt; Sharon,</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
        size=3D2>&gt; Are you suggesting that in order for an entity to =
issue CRLs=20
        </FONT><BR><FONT size=3D2>&gt; on behalf of a certificate =
issuer, that CRL=20
        issuer would need </FONT><BR><FONT size=3D2>&gt; to issue =
certificates as=20
        well (so that it can qualify as an </FONT><BR><FONT =
size=3D2>&gt;=20
        authority)?&nbsp; I don't think there should be such a =
</FONT><BR><FONT=20
        size=3D2>&gt; requirement, but even if there were it wouldn't =
settle the=20
        issue.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; Even if=20
        only authorities can issue CRLs, there is nothing to =
</FONT><BR><FONT=20
        size=3D2>&gt; prevent that authority from using different keys =
to sign=20
        </FONT><BR><FONT size=3D2>&gt; certificates and CRLs.&nbsp; =
X.509 states=20
        that "[t]he cA component </FONT><BR><FONT size=3D2>&gt; =
indicates if the=20
        certified public key may be used to verify </FONT><BR><FONT =
size=3D2>&gt;=20
        certificate signatures."&nbsp; So, the proper value of the cA =
bit=20
        </FONT><BR><FONT size=3D2>&gt; is determined by the allowable =
uses of the=20
        subject public </FONT><BR><FONT size=3D2>&gt; key, not by the =
type of=20
        entity the subject is.&nbsp; So, even if </FONT><BR><FONT =
size=3D2>&gt;=20
        the certificate subject is a CA, and issues certificates=20
        </FONT><BR><FONT size=3D2>&gt; under some key, the cA bit should =
not be=20
        set unless the </FONT><BR><FONT size=3D2>&gt; particular subject =
public=20
        key in the certificate can be used </FONT><BR><FONT =
size=3D2>&gt; to=20
        verify certificate signatures. If an authority is the =
</FONT><BR><FONT=20
        size=3D2>&gt; subject of a certificate and the particular public =
key of=20
        </FONT><BR><FONT size=3D2>&gt; that authority that is being =
certified is=20
        only to be used to </FONT><BR><FONT size=3D2>&gt; verify =
signatures on=20
        CRLs, then the cA bit should not be set.</FONT> <BR><FONT =
size=3D2>&gt;=20
        </FONT><BR><FONT size=3D2>&gt; Dave</FONT> <BR><FONT =
size=3D2>&gt;=20
        </FONT><BR><FONT size=3D2>&gt; At 10:48 AM 4/20/01 -0400, Sharon =
Boeyen=20
        wrote:</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
        &gt;David, sorry but I disagree with your assertions about =
X.509's=20
        </FONT><BR><FONT size=3D2>&gt; &gt;position on this issue. =
Either by=20
        design or by accident, </FONT><BR><FONT size=3D2>&gt; X.509 =
requires that=20
        if CRLs are being issued, they are issued </FONT><BR><FONT =
size=3D2>&gt;=20
        by an 'authority'. Remember that the definition of =
</FONT><BR><FONT=20
        size=3D2>&gt; "authority" is "An entity responsible =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;for the =
issuance of=20
        certificates". Much of the text in X.509 </FONT><BR><FONT =
size=3D2>&gt;=20
        predates OCSP or the concept of a validation authority, but I=20
        </FONT><BR><FONT size=3D2>&gt; do know that the quotes below are =
new text=20
        added within the </FONT><BR><FONT size=3D2>&gt; past couple of =
years with=20
        the intent of clarifying the role </FONT><BR><FONT size=3D2>&gt; =
of CAs=20
        with respect to CRLs.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
        size=3D2>&gt; &gt;Clause 7.3 says:&nbsp; </FONT><BR><FONT =
size=3D2>&gt;=20
        &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;"An authority that =
issues=20
        certificates is required to state, </FONT><BR><FONT =
size=3D2>&gt; possibly=20
        through a published statement of their practices, =
</FONT><BR><FONT=20
        size=3D2>&gt; through the certificates themselves, or through =
some other=20
        </FONT><BR><FONT size=3D2>&gt; identified means, whether:</FONT> =
<BR><FONT=20
        size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt;=20
        &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificates =
cannot be=20
        revoked; or </FONT><BR><FONT size=3D2>&gt;=20
        &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificates may =
be=20
        revoked by the same </FONT><BR><FONT size=3D2>&gt; =
certificate-issuing=20
        authority directly; or </FONT><BR><FONT size=3D2>&gt;=20
        &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
certificate-issuing=20
        authority authorizes a </FONT><BR><FONT size=3D2>&gt; different =
authority=20
        to perform revocation." </FONT><BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
        <BR><FONT size=3D2>&gt; &gt;further down in the same clause is =
the text:=20
        </FONT><BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt; &gt;"=20
        </FONT><BR><FONT size=3D2>&gt; &gt;An authority that issues and=20
        subsequently revokes certificates: </FONT><BR><FONT =
size=3D2>&gt;=20
        &gt;a)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may be required to maintain =
an=20
        audit record of its </FONT><BR><FONT size=3D2>&gt; revocation =
events for=20
        all certificate types issued by that </FONT><BR><FONT =
size=3D2>&gt;=20
        authority (e.g. public-key certificates, attribute =
</FONT><BR><FONT=20
        size=3D2>&gt; certificates issued to end-entities as well as =
other=20
        authorities);</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
        size=3D2>&gt; &gt;b)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shall provide =

        revocation status information to </FONT><BR><FONT size=3D2>&gt; =
relying=20
        parties using CRLs, on-line certificate status </FONT><BR><FONT=20
        size=3D2>&gt; protocol or some other mechanism for the =
publication of=20
        </FONT><BR><FONT size=3D2>&gt; revocation status =
information;</FONT>=20
        <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt;=20
        &gt;c)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if using CRLs, shall =
maintain and=20
        publish CRLs even </FONT><BR><FONT size=3D2>&gt; if the lists of =
revoked=20
        certificates are empty." </FONT><BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
        <BR><FONT size=3D2>&gt; &gt;The quotes that you included in your =
message=20
        tie in with </FONT><BR><FONT size=3D2>&gt; this base text, since =
the=20
        authority that issued the </FONT><BR><FONT size=3D2>&gt; =
certificates has=20
        these responsibilities around revocation, </FONT><BR><FONT =
size=3D2>&gt;=20
        there was no need for X.509 to state anything specific to CRL=20
        </FONT><BR><FONT size=3D2>&gt; issuance. In the indirect CRL =
case, this=20
        was envisioned to be </FONT><BR><FONT size=3D2>&gt; another CA =
or AA, that=20
        combined revocation notices from </FONT><BR><FONT size=3D2>&gt; =
several=20
        CAs/AAs. </FONT><BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
        &gt;Having said that (with my X.509 editor's hat on), if there=20
        </FONT><BR><FONT size=3D2>&gt; is a requirement to have entities =
that are=20
        not CAs or AAs be </FONT><BR><FONT size=3D2>&gt; authorized to =
issue CRLs=20
        on behalf of the certificate issuer </FONT><BR><FONT =
size=3D2>&gt;=20
        (because remember that a CRL is an indication that a =
</FONT><BR><FONT=20
        size=3D2>&gt; certificate is no longer considered valid "by its=20
        </FONT><BR><FONT size=3D2>&gt; issuer")changes to X.509 would be =
needed.=20
        I'm not necessarily </FONT><BR><FONT size=3D2>&gt; opposed to =
such=20
        changes, I'm just clarifying, in this </FONT><BR><FONT =
size=3D2>&gt;=20
        message, that they would be needed in order for such =
</FONT><BR><FONT=20
        size=3D2>&gt; implementations to be conformant. This, as usual =
could be=20
        </FONT><BR><FONT size=3D2>&gt; done through the enhancements =
work or could=20
        be proposed </FONT><BR><FONT size=3D2>&gt; through the defect =
process. One=20
        way to enable that kind of </FONT><BR><FONT size=3D2>&gt; change =
might be=20
        to redefine authority and to talk about 3 </FONT><BR><FONT =
size=3D2>&gt;=20
        types rather than two. However, it would take some careful=20
        </FONT><BR><FONT size=3D2>&gt; review to ensure that the set of =
changes=20
        was thorough and complete.</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
        <BR><FONT size=3D2>&gt; &gt;Sharon </FONT><BR><FONT =
size=3D2>&gt;=20
        &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; -----Original =
Message-----=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; From: David A. Cooper=20
        </FONT><BR><FONT size=3D2>&gt; [&lt;<A=20
        =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>&gt=
;<A=20
        =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; Sent: Thursday, April =
19, 2001=20
        5:08 PM </FONT><BR><FONT size=3D2>&gt; &gt; &gt; To: =
[e-mail]=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; Subject: cA flag and =
CRL issuers=20
        (was Re: Last Call: </FONT><BR><FONT size=3D2>&gt; &gt; &gt;=20
        draft-ietf-pkix-new-part1-06.txt comments) </FONT><BR><FONT =
size=3D2>&gt;=20
        &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; At 07:17 PM 4/18/01 -0400, Stephen Kent =
wrote:=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; &gt;Dave Cooper, =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;=20
        &gt;&gt;At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; &gt;&gt;I see no basis =
in X.509=20
        for setting the cA flag in </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;=20
        basicConstraints for certificate subjects that can issue CRLs=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; but not certificates. =
The current=20
        discussion about how to </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
deal with=20
        CRLs for attribute certificates vs. public key </FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; certificates just further goes to show =
that it was=20
        a mistake </FONT><BR><FONT size=3D2>&gt; &gt; &gt; to suddenly =
change the=20
        rules at the last IETF meeting. </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; &gt;We disagree on =
this=20
        point. Nowhere in X.509 or in previous </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
        &gt; PKIX documents has there ever been text to suggest that =
other=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; than a CA can sign a =
CRL for a=20
        public key certificate. So, </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; the=20
        rules were not changed at the last meeting, they were =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; reasserted and clarified. =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
Steve,=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
        &gt; You may say that X.509 and PKIX do not suggest that =
entities=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; other than CAs can sign =
CRLs.=20
        However, I think we all agree </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        that both X.509 and PKIX allow for a CRL to be signed with a=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; different key than the =
key used=20
        to sign the certificates that </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt; are=20
        covered by that CRL. This may be a result of the CA that=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; issued the certificates =
signing=20
        the corresponding CRLs with a </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        different key or the CA that issued the certificates =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; delegating the CRL issuing to another =
entity (via=20
        the </FONT><BR><FONT size=3D2>&gt; &gt; &gt; distribution points =

        extension). There is no requirement that </FONT><BR><FONT =
size=3D2>&gt;=20
        &gt; &gt; the key used to sign the CRL also be used to sign=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; certificates. So, I =
think we=20
        agree that there will be times </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        where we will be issuing certificates to entities (whether=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; those entities are CAs =
or not)=20
        where the intent is to specify </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        that the public keys in the certificates may be used to =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; verify signatures on CRLs but not on =
certificates.=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
        &gt; The only place we seem to disagree is on the contents of =
the=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; certificates issued in =
such=20
        circumstances. In particular, </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        should the certificates contain a basicConstraints extension=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; with the cA bit set? On =
this=20
        point, both X.509 and the </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;=20
        previous PKIX documents are quite clear that the cA bit =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; should not be set. Why? Because a CA is =
defined as=20
        an entity </FONT><BR><FONT size=3D2>&gt; &gt; &gt; that issues =
public-key=20
        certificates and both documents </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        similarly state that the cA bit is used to specify whether=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; the certificate subject =
can issue=20
        certificates. There is no </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; similar=20
        connection made between being a CA and issuing CRLs. =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =

        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; The following are some =
quotes=20
        from X.509 and pkix-new-part1-05: </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; In X.509 a CA is =
defined as "[a]n=20
        authority trusted by one or </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; more=20
        users to create and assign public-key certificates." =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
Section 7=20
        of X.509 states that "[a] CA-certificate is a </FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; certificate issued by a CA to a subject =
that is=20
        itself a CA </FONT><BR><FONT size=3D2>&gt; &gt; &gt; and =
therefore is=20
        capable of issuing public-key certificates." </FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =

        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; The description of =
basic=20
        constraints in X.509 further </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;=20
        supports the idea that the cA bit is used to specify =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; certificate issuing, not certificate =
and/or CRL=20
        issuing: </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; "This field indicates if the subject may =
act as a=20
        CA, with </FONT><BR><FONT size=3D2>&gt; &gt; &gt; the certified =
public key=20
        being used to verify certificate </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        signatures. ... The cA component indicates if the certified=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; public key may be used =
to verify=20
        certificate signatures. ... if </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        the value of cA is not set to true then the certified public=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; key shall not be used =
to verify a=20
        certificate signature" </FONT><BR><FONT size=3D2>&gt; &gt; &gt;=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
        &gt; pkix-new-part1-05 states something similar: =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
"The cA bit=20
        indicates if the certified public key may be used =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; to verify signatures on other =
certificates. If the=20
        cA bit is </FONT><BR><FONT size=3D2>&gt; &gt; &gt; asserted, =
then the=20
        keyCertSign bit in the key usage extension </FONT><BR><FONT =
size=3D2>&gt;=20
        &gt; &gt; (see 4.2.1.3) MUST also be asserted. If the cA bit is =
not=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; asserted, then the =
keyCertSign=20
        bit in the key usage extension </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        MUST NOT be asserted." </FONT><BR><FONT size=3D2>&gt; &gt; &gt;=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
        &gt; The description of the key usage bits are consistent with=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; this as well. =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
X.509:=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; "The bit keyCertSign is =
for use=20
        in CA-certificates only. If </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;=20
        KeyUsage is set to keyCertSign and the basic constraints=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; extension is present in =
the same=20
        certificate, the value of </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; the cA=20
        component of that extension shall be set to TRUE." =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =

        pkix-new-part1-05: </FONT><BR><FONT size=3D2>&gt; &gt; &gt; "The =

        keyCertSign bit is asserted when the subject public key =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; is used for verifying a signature on=20
        certificates.&nbsp; This bit </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; may=20
        only be asserted in CA certificates.&nbsp; If the keyCertSign=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; bit is asserted, then =
the cA bit=20
        in the basic constraints </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;=20
        extension (see 4.2.1.10) MUST also be asserted. If the =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; keyCertSign bit is not asserted, then =
the cA bit=20
        in the basic </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
constraints=20
        extension MUST NOT be asserted. </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; The cRLSign bit is =
asserted when=20
        the subject public key is </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; used=20
        for verifying a signature on revocation information =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; (e.g., a CRL)." </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
        &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt;=20
        &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; So, both =
X.509 and=20
        pkix-new-part1-05 go to great lengths to </FONT><BR><FONT =
size=3D2>&gt;=20
        &gt; &gt; clearly state that only CAs can issue certificates and =
that=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; basicConstraints with =
the cA bit=20
        set to true must be present </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; in=20
        the certificates where the public key is to be used to =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; verify signatures on certificates. There =
are no=20
        similar </FONT><BR><FONT size=3D2>&gt; &gt; &gt; statements =
about CRLs. In=20
        fact, both documents are quite </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
        clear that the cA bit must not be set when the subject public=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; key can not be used to =
verify=20
        certificates. So, if the </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; subject=20
        public key can be used to verify CRLs, but not </FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; certificates, the cA bit must not be =
set.=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
        &gt; X.509 is also careful not to preclude the public keys of=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; non-CAs from being used =
to verify=20
        signatures on CRLs. For </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
instance,=20
        an end entity is defined as "[a] certificate </FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; subject that uses its private key for =
purposes=20
        other than </FONT><BR><FONT size=3D2>&gt; &gt; &gt; signing =
certificates=20
        or an entity that is a relying party." </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
        &gt; This leaves room for an end entity to use its private key =
to=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; sign CRLs. =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =

        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; So, if PKIX wants to =
require that=20
        the cA bit be set whenever </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; the=20
        subject public key can be used to verify CRLs and also =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; wants to maintain consistency with =
X.509, PKIX=20
        would have to </FONT><BR><FONT size=3D2>&gt; &gt; &gt; require =
that any=20
        certificate authorizing the use of a public </FONT><BR><FONT =
size=3D2>&gt;=20
        &gt; &gt; key for verifying CRL signatures also authorize the =
use of=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; that public key for =
verifying=20
        certificate signatures. Since </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt; we=20
        are in agreement that we do not want to impose such a =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; restriction and that we do want to =
maintain=20
        consistency with </FONT><BR><FONT size=3D2>&gt; &gt; &gt; X.509, =
we can=20
        not require that the cA bit be set when the </FONT><BR><FONT =
size=3D2>&gt;=20
        &gt; &gt; subject public key can only be used to verify CRL =
signatures.=20
        </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
        &gt; Dave </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
</FONT><BR><FONT=20
        size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
        size=3D2>&gt;=20
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></H=
TML>

------=_NextPart_000_0027_01C0C99F.0638C260--



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA05031 for <[e-mail]>; Fri, 20 Apr 2001 13:02:56 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JJPVTDA2>; Fri, 20 Apr 2001 16:02:27 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)
Date: Fri, 20 Apr 2001 15:57:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9D4.0FD1C7B0"

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_01C0C9D4.0FD1C7B0
Content-Type: text/plain;
	charset="iso-8859-1"

Jim, I forgot one point that might help understand my view on the
basicConstraints extension. I don't believe that any CA can actually prevent
another entity from issuing certificates purely through technical tools such
as cert extensions. However, a CA can prevent relying parties from trusting
certificates issued by such entities specifically through the business
controls extensions defined in the standards. 
 
Cheers,
Sharon
 
 -----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]]
Sent: Friday, April 20, 2001 3:05 PM
To: '[e-mail]'; Sharon Boeyen; [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n
ew-part1-06.txt comments)



The point that I think is a bit different is the use of the CA bit in basic
constraints. This is one of many 'business controls' that a CA can put into
a certificate that it issues to another CA to restrict the set of paths
(including that certificate) that can be successfully validated. In my mind
this extension exists so that a relying party can know whether the
certificate they are processing is one that certifies a key that can be used
to verify the signature of the next cert in the path. Full stop. It isn't an
'authorization' of any entity to issue certificates but a signal to the
relying party that the certified key can be used for verifying the next
signature. The pathLengthConstraint component of that extension, along with
all the other business control extensions (policy stuff, name constraints
etc) further retrict a relying party with respect to the certification paths
(and contained certificates) that can be successfully validated using the
certificate that contains the extensions. Each issuer has the ability to
place such restrictions and the complete validation of the path depends, in
part on those constraints.  
 
When we look at the two basic trust models (hierarchical and distributed),
then this does get muddled somewhat, because in a hierarchy there is sort of
a sense of 'authorization' of subordinate CAs. The same is not true in a
distributed trust model. A CA is any entity that issues public-key
certificates regardless of whether some other CA happens to have issued it a
certificate containing the basic constraints extension with the CA bit set
to true. The extension really only matters when one tries to validate a
certification path and needs to be sure that the issuer of a particular
certificate 'trusts' certificates signed with the key corresponding to that
certified in the current certificate. 
 
Consider the above 2 paragraphs my personal opinion on basicConstraints. 
 
As for attribute certificates and attribute authorities, in some
environments there is absolutely no need to tie the PMI to the PKI. The
verifiers may import one or more trust anchors for SOAs, similar to how they
do today for PKI trust anchors. However, in other environments, there was a
requirement to have a single trust anchor and be able to validate both
public key and attribute certificates. For this reason, X.509 added the
sOAIdentifier extension. Its syntax is NULL. Its only purpose in life is to
support this requirement of binding a PMI to a PKI.  As for the attribute
certificate 'equivalent' of a certification path, this is a delegation path.
There are completely different extensions defined to ensure that a
delegationPath is valid (although you will recognize similarities).
basicAttConstraints inidicates whether or not the assigned privilege can be
further delegated by the subject of the containing certificate. 'Business
controls' extensions include delegatedNameConstraints,
acceptableCertPolicies, authorityAttributeIdentifier (to ensure that the
delegating authority actually holds sufficicient privilege to delegate it)
etc). Don't try to shoehorn the PKI extensions into the PMI model. The only
real overlap is that we reused the basic CRL structure. 
 
Hope that helps and doesn't confuse the issues further :-)
 
Sharon
 
 -----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, April 20, 2001 2:08 PM
To: 'Sharon Boeyen'; [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n
ew-part1-06.txt comments)



Sharon,
 
Much of this question arose from how to deal with AC "authorities".  I don't
have access at the moment to the X. version of the AC draft (yes I know I
can now get it), but do you believe that AC issuers and "revokers" need to
be authorities in that the CA bit should be set for them?
 
jim

-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]]
Sent: Friday, April 20, 2001 9:57 AM
To: 'David A. Cooper'; [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n
ew-part1-06.txt comments)



Just to be clear, lets not confuse what I may happen to want as 
an individual contributor to PKIX or any other list, with what 
I state as 509 editor (they're not necessarily always the same :-) 

My comments were purely from the editor's perspective and yes, 
the current 509 text is quite clear that the CA that issues a 
certificate is responsible for stating whether or not that certificate 
can be revoked, and if so, what mechanism is used to inform 
relying parties. If that mechanism is CRLs, these are issued by 
the certificate issuer or by another authority delegated that 
task by the certificate issuer (that doesn't necessarily mean that 
509 requires a cert to be issued to that authority, nor that the cert 
contain the basic constraints extension though, that is the job of 
profile groups to determine and incidentally I don't believe they'll 
all adopt the same solution so I would want 509 to remain flexible). 

My own personal view is that industry has moved to a point where there 
probably isn't any real requirement for a CRL issuer to also be a cert 
issuer as long as that CRL issuer is delegated that responsibility 
by the cert issuer and there is a cryptographic way to ensure that 
binding for relying parties. To achieve that, I believe some changes 
are required in 509. 

On the separate keys for cert and CRL signing (by the same authority), my 
personal opinion is that anything you read into 509 text on that specific 
topic would be accidental as I don't recall any specific discussion on it. 
However, since that is a real world requirement, I would want to be sure 
that 509 did not prohibit it. 

Hope that clarifies where my comments are coming from :-) 
    

> -----Original Message----- 
> From: David A. Cooper [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Friday, April 20, 2001 11:44 AM 
> To: [e-mail] 
> Subject: RE: cA flag and CRL issuers (was Re: Last Call: 
> draft-ietf-pkix-n ew-part1-06.txt comments) 
> 
> 
> Sharon, 
> 
> Are you suggesting that in order for an entity to issue CRLs 
> on behalf of a certificate issuer, that CRL issuer would need 
> to issue certificates as well (so that it can qualify as an 
> authority)?  I don't think there should be such a 
> requirement, but even if there were it wouldn't settle the issue. 
> 
> Even if only authorities can issue CRLs, there is nothing to 
> prevent that authority from using different keys to sign 
> certificates and CRLs.  X.509 states that "[t]he cA component 
> indicates if the certified public key may be used to verify 
> certificate signatures."  So, the proper value of the cA bit 
> is determined by the allowable uses of the subject public 
> key, not by the type of entity the subject is.  So, even if 
> the certificate subject is a CA, and issues certificates 
> under some key, the cA bit should not be set unless the 
> particular subject public key in the certificate can be used 
> to verify certificate signatures. If an authority is the 
> subject of a certificate and the particular public key of 
> that authority that is being certified is only to be used to 
> verify signatures on CRLs, then the cA bit should not be set. 
> 
> Dave 
> 
> At 10:48 AM 4/20/01 -0400, Sharon Boeyen wrote: 
> 
> >David, sorry but I disagree with your assertions about X.509's 
> >position on this issue. Either by design or by accident, 
> X.509 requires that if CRLs are being issued, they are issued 
> by an 'authority'. Remember that the definition of 
> "authority" is "An entity responsible 
> > 
> >for the issuance of certificates". Much of the text in X.509 
> predates OCSP or the concept of a validation authority, but I 
> do know that the quotes below are new text added within the 
> past couple of years with the intent of clarifying the role 
> of CAs with respect to CRLs. 
> > 
> >Clause 7.3 says:  
> > 
> >"An authority that issues certificates is required to state, 
> possibly through a published statement of their practices, 
> through the certificates themselves, or through some other 
> identified means, whether: 
> > 
> >-       The certificates cannot be revoked; or 
> >-       The certificates may be revoked by the same 
> certificate-issuing authority directly; or 
> >-       The certificate-issuing authority authorizes a 
> different authority to perform revocation." 
> > 
> >further down in the same clause is the text: 
> > 
> >" 
> >An authority that issues and subsequently revokes certificates: 
> >a)      may be required to maintain an audit record of its 
> revocation events for all certificate types issued by that 
> authority (e.g. public-key certificates, attribute 
> certificates issued to end-entities as well as other authorities); 
> > 
> >b)      shall provide revocation status information to 
> relying parties using CRLs, on-line certificate status 
> protocol or some other mechanism for the publication of 
> revocation status information; 
> > 
> >c)      if using CRLs, shall maintain and publish CRLs even 
> if the lists of revoked certificates are empty." 
> > 
> >The quotes that you included in your message tie in with 
> this base text, since the authority that issued the 
> certificates has these responsibilities around revocation, 
> there was no need for X.509 to state anything specific to CRL 
> issuance. In the indirect CRL case, this was envisioned to be 
> another CA or AA, that combined revocation notices from 
> several CAs/AAs. 
> > 
> >Having said that (with my X.509 editor's hat on), if there 
> is a requirement to have entities that are not CAs or AAs be 
> authorized to issue CRLs on behalf of the certificate issuer 
> (because remember that a CRL is an indication that a 
> certificate is no longer considered valid "by its 
> issuer")changes to X.509 would be needed. I'm not necessarily 
> opposed to such changes, I'm just clarifying, in this 
> message, that they would be needed in order for such 
> implementations to be conformant. This, as usual could be 
> done through the enhancements work or could be proposed 
> through the defect process. One way to enable that kind of 
> change might be to redefine authority and to talk about 3 
> types rather than two. However, it would take some careful 
> review to ensure that the set of changes was thorough and complete. 
> > 
> >Sharon 
> > 
> > > -----Original Message----- 
> > > From: David A. Cooper 
> [< mailto:[e-mail] <mailto:[e-mail]> >
mailto:[e-mail] <mailto:[e-mail]> ] 
> > > Sent: Thursday, April 19, 2001 5:08 PM 
> > > To: [e-mail] 
> > > Subject: cA flag and CRL issuers (was Re: Last Call: 
> > > draft-ietf-pkix-new-part1-06.txt comments) 
> > > 
> > > 
> > > At 07:17 PM 4/18/01 -0400, Stephen Kent wrote: 
> > > >Dave Cooper, 
> > > > 
> > > >>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote: 
> > > >>I see no basis in X.509 for setting the cA flag in 
> > > basicConstraints for certificate subjects that can issue CRLs 
> > > but not certificates. The current discussion about how to 
> > > deal with CRLs for attribute certificates vs. public key 
> > > certificates just further goes to show that it was a mistake 
> > > to suddenly change the rules at the last IETF meeting. 
> > > > 
> > > >We disagree on this point. Nowhere in X.509 or in previous 
> > > PKIX documents has there ever been text to suggest that other 
> > > than a CA can sign a CRL for a public key certificate. So, 
> > > the rules were not changed at the last meeting, they were 
> > > reasserted and clarified. 
> > > 
> > > Steve, 
> > > 
> > > You may say that X.509 and PKIX do not suggest that entities 
> > > other than CAs can sign CRLs. However, I think we all agree 
> > > that both X.509 and PKIX allow for a CRL to be signed with a 
> > > different key than the key used to sign the certificates that 
> > > are covered by that CRL. This may be a result of the CA that 
> > > issued the certificates signing the corresponding CRLs with a 
> > > different key or the CA that issued the certificates 
> > > delegating the CRL issuing to another entity (via the 
> > > distribution points extension). There is no requirement that 
> > > the key used to sign the CRL also be used to sign 
> > > certificates. So, I think we agree that there will be times 
> > > where we will be issuing certificates to entities (whether 
> > > those entities are CAs or not) where the intent is to specify 
> > > that the public keys in the certificates may be used to 
> > > verify signatures on CRLs but not on certificates. 
> > > 
> > > The only place we seem to disagree is on the contents of the 
> > > certificates issued in such circumstances. In particular, 
> > > should the certificates contain a basicConstraints extension 
> > > with the cA bit set? On this point, both X.509 and the 
> > > previous PKIX documents are quite clear that the cA bit 
> > > should not be set. Why? Because a CA is defined as an entity 
> > > that issues public-key certificates and both documents 
> > > similarly state that the cA bit is used to specify whether 
> > > the certificate subject can issue certificates. There is no 
> > > similar connection made between being a CA and issuing CRLs. 
> > > 
> > > 
> > > The following are some quotes from X.509 and pkix-new-part1-05: 
> > > 
> > > In X.509 a CA is defined as "[a]n authority trusted by one or 
> > > more users to create and assign public-key certificates." 
> > > 
> > > Section 7 of X.509 states that "[a] CA-certificate is a 
> > > certificate issued by a CA to a subject that is itself a CA 
> > > and therefore is capable of issuing public-key certificates." 
> > > 
> > > 
> > > The description of basic constraints in X.509 further 
> > > supports the idea that the cA bit is used to specify 
> > > certificate issuing, not certificate and/or CRL issuing: 
> > > 
> > > "This field indicates if the subject may act as a CA, with 
> > > the certified public key being used to verify certificate 
> > > signatures. ... The cA component indicates if the certified 
> > > public key may be used to verify certificate signatures. ... if 
> > > the value of cA is not set to true then the certified public 
> > > key shall not be used to verify a certificate signature" 
> > > 
> > > 
> > > pkix-new-part1-05 states something similar: 
> > > 
> > > "The cA bit indicates if the certified public key may be used 
> > > to verify signatures on other certificates. If the cA bit is 
> > > asserted, then the keyCertSign bit in the key usage extension 
> > > (see 4.2.1.3) MUST also be asserted. If the cA bit is not 
> > > asserted, then the keyCertSign bit in the key usage extension 
> > > MUST NOT be asserted." 
> > > 
> > > 
> > > The description of the key usage bits are consistent with 
> > > this as well. 
> > > 
> > > X.509: 
> > > "The bit keyCertSign is for use in CA-certificates only. If 
> > > KeyUsage is set to keyCertSign and the basic constraints 
> > > extension is present in the same certificate, the value of 
> > > the cA component of that extension shall be set to TRUE." 
> > > 
> > > pkix-new-part1-05: 
> > > "The keyCertSign bit is asserted when the subject public key 
> > > is used for verifying a signature on certificates.  This bit 
> > > may only be asserted in CA certificates.  If the keyCertSign 
> > > bit is asserted, then the cA bit in the basic constraints 
> > > extension (see 4.2.1.10) MUST also be asserted. If the 
> > > keyCertSign bit is not asserted, then the cA bit in the basic 
> > > constraints extension MUST NOT be asserted. 
> > > 
> > > The cRLSign bit is asserted when the subject public key is 
> > > used for verifying a signature on revocation information 
> > > (e.g., a CRL)." 
> > > 
> > > 
> > > 
> > > So, both X.509 and pkix-new-part1-05 go to great lengths to 
> > > clearly state that only CAs can issue certificates and that 
> > > basicConstraints with the cA bit set to true must be present 
> > > in the certificates where the public key is to be used to 
> > > verify signatures on certificates. There are no similar 
> > > statements about CRLs. In fact, both documents are quite 
> > > clear that the cA bit must not be set when the subject public 
> > > key can not be used to verify certificates. So, if the 
> > > subject public key can be used to verify CRLs, but not 
> > > certificates, the cA bit must not be set. 
> > > 
> > > X.509 is also careful not to preclude the public keys of 
> > > non-CAs from being used to verify signatures on CRLs. For 
> > > instance, an end entity is defined as "[a] certificate 
> > > subject that uses its private key for purposes other than 
> > > signing certificates or an entity that is a relying party." 
> > > This leaves room for an end entity to use its private key to 
> > > sign CRLs. 
> > > 
> > > 
> > > So, if PKIX wants to require that the cA bit be set whenever 
> > > the subject public key can be used to verify CRLs and also 
> > > wants to maintain consistency with X.509, PKIX would have to 
> > > require that any certificate authorizing the use of a public 
> > > key for verifying CRL signatures also authorize the use of 
> > > that public key for verifying certificate signatures. Since 
> > > we are in agreement that we do not want to impose such a 
> > > restriction and that we do want to maintain consistency with 
> > > X.509, we can not require that the cA bit be set when the 
> > > subject public key can only be used to verify CRL signatures. 
> > > 
> > > Dave 
> > > 
> > > 
> 
> 


------_=_NextPart_001_01C0C9D4.0FD1C7B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=176595919-20042001>Jim, I 
forgot one point that might help understand my view on the basicConstraints 
extension. I don't believe that any CA can actually prevent another entity from 
issuing certificates purely through technical tools such as cert extensions. 
However, a CA can prevent relying parties from trusting certificates issued by 
such entities specifically through the business controls extensions defined in 
the standards. </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=176595919-20042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=176595919-20042001>Cheers,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=176595919-20042001>Sharon</SPAN></FONT></DIV>
<DIV><SPAN class=176595919-20042001></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=176595919-20042001><FONT face=Arial 
color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=176595919-20042001>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Sharon Boeyen [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 
20, 2001 3:05 PM<BR><B>To:</B> '[e-mail]'; Sharon Boeyen; 
[e-mail]<BR><B>Subject:</B> RE: cA flag and CRL issuers (was Re: Last 
Call: draft-ietf-pkix-n ew-part1-06.txt comments)<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff size=2>The 
  point that I think is a bit different is the use of the CA bit in basic 
  constraints. This is one of many 'business controls' that a CA can put into a 
  certificate that it issues to another CA to restrict the set of paths 
  (including that certificate) that can be successfully validated. In my mind 
  this extension exists so that a relying party can know whether the certificate 
  they are processing is one that certifies a key that can be used to verify the 
  signature of the next cert in the path. Full stop. It isn't an 'authorization' 
  of any entity to issue certificates but a signal to the relying party that the 
  certified key can be used for verifying the next signature. The 
  pathLengthConstraint component of that extension, along with all the other 
  business control extensions (policy stuff, name constraints etc) further 
  retrict a relying party with respect to the certification paths (and contained 
  certificates) that can be successfully validated using the certificate that 
  contains the extensions. Each issuer has the ability to place such 
  restrictions and the complete validation of the path depends, in part on those 
  constraints.&nbsp;&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=934173718-20042001></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff size=2>When 
  we look at the two basic trust models (hierarchical and distributed), then 
  this does get muddled somewhat, because in a hierarchy there is sort of a 
  sense of 'authorization' of subordinate CAs. The same is not true in a 
  distributed trust model. A CA is&nbsp;any entity that issues public-key 
  certificates regardless of whether some other CA happens to have issued it a 
  certificate containing the basic constraints extension with the CA bit set to 
  true. The extension really only matters when one tries to validate a 
  certification path and needs to be sure that the issuer of a particular 
  certificate 'trusts' certificates signed with the key corresponding to that 
  certified in the current certificate. </FONT></SPAN></DIV>
  <DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
  size=2>Consider the above 2 paragraphs my personal opinion on 
  basicConstraints. </FONT></SPAN></DIV>
  <DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff size=2>As 
  for attribute certificates and attribute authorities, in some environments 
  there is absolutely no need to tie the PMI to the PKI. The verifiers may 
  import one or more trust anchors for SOAs, similar to how they do today for 
  PKI trust anchors. However, in other environments, there was a requirement to 
  have a single trust anchor and be able to validate both public key and 
  attribute certificates. For this reason, X.509 added the 
  sOAIdentifier&nbsp;extension. Its syntax is NULL. Its only purpose in life is 
  to support this requirement of binding a PMI to a PKI.&nbsp; As for the 
  attribute certificate 'equivalent' of a certification path, this is a 
  delegation path. There are completely different extensions defined to ensure 
  that a delegationPath is valid (although you will recognize similarities). 
  basicAttConstraints inidicates whether or not the assigned privilege can be 
  further delegated by the subject of the containing certificate. 'Business 
  controls' extensions include delegatedNameConstraints, acceptableCertPolicies, 
  authorityAttributeIdentifier (to ensure that the delegating authority actually 
  holds sufficicient privilege to delegate it) etc). Don't try to shoehorn the 
  PKI extensions into the PMI model. The only real overlap is that we reused the 
  basic CRL structure. </FONT></SPAN></DIV>
  <DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff size=2>Hope 
  that helps and doesn't confuse the issues further :-)</FONT></SPAN></DIV>
  <DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
  size=2>Sharon</FONT></SPAN></DIV>
  <DIV><SPAN class=934173718-20042001></SPAN><FONT face=Tahoma><FONT 
  size=2><SPAN class=934173718-20042001><FONT face=Arial 
  color=#0000ff></FONT></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma><FONT size=2><SPAN 
  class=934173718-20042001>&nbsp;</SPAN>-----Original 
  Message-----<BR><B>From:</B> Jim Schaad 
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 20, 2001 2:08 
  PM<BR><B>To:</B> 'Sharon Boeyen'; [e-mail]<BR><B>Subject:</B> RE: cA 
  flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt 
  comments)<BR><BR></DIV></FONT></FONT>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=128290618-20042001>Sharon,</SPAN></FONT></DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=128290618-20042001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=128290618-20042001>Much of this question arose from how to deal with 
    AC "authorities".&nbsp; I don't have access at the moment to the X. version 
    of the AC draft (yes I know I can now get it), but do you believe that AC 
    issuers and "revokers" need to be authorities in that the CA bit should be 
    set for them?</SPAN></FONT></DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=128290618-20042001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=128290618-20042001>jim</SPAN></FONT></DIV>
    <BLOCKQUOTE 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen 
      [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 20, 2001 
      9:57 AM<BR><B>To:</B> 'David A. Cooper'; 
      [e-mail]<BR><B>Subject:</B> RE: cA flag and CRL issuers (was Re: 
      Last Call: draft-ietf-pkix-n ew-part1-06.txt 
comments)<BR><BR></DIV></FONT>
      <P><FONT size=2>Just to be clear, lets not confuse what I may happen to 
      want as </FONT><BR><FONT size=2>an individual contributor to PKIX or any 
      other list, with what </FONT><BR><FONT size=2>I state as 509 editor 
      (they're not necessarily always the same :-)</FONT> </P>
      <P><FONT size=2>My comments were purely from the editor's perspective and 
      yes, </FONT><BR><FONT size=2>the current 509 text is quite clear that the 
      CA that issues a </FONT><BR><FONT size=2>certificate is responsible for 
      stating whether or not that certificate</FONT> <BR><FONT size=2>can be 
      revoked, and if so, what mechanism is used to inform </FONT><BR><FONT 
      size=2>relying parties. If that mechanism is CRLs, these are issued by 
      </FONT><BR><FONT size=2>the certificate issuer or by another authority 
      delegated that </FONT><BR><FONT size=2>task by the certificate issuer 
      (that doesn't necessarily mean that </FONT><BR><FONT size=2>509 requires a 
      cert to be issued to that authority, nor that the cert </FONT><BR><FONT 
      size=2>contain the basic constraints extension though, that is the job of 
      </FONT><BR><FONT size=2>profile groups to determine and incidentally I 
      don't believe they'll </FONT><BR><FONT size=2>all adopt the same solution 
      so I would want 509 to remain flexible). </FONT></P>
      <P><FONT size=2>My own personal view is that industry has moved to a point 
      where there </FONT><BR><FONT size=2>probably isn't any real requirement 
      for a CRL issuer to also be a cert</FONT> <BR><FONT size=2>issuer as long 
      as that CRL issuer is delegated that responsibility </FONT><BR><FONT 
      size=2>by the cert issuer and there is a cryptographic way to ensure that 
      </FONT><BR><FONT size=2>binding for relying parties. To achieve that, I 
      believe some changes </FONT><BR><FONT size=2>are required in 509. 
      </FONT></P>
      <P><FONT size=2>On the separate keys for cert and CRL signing (by the same 
      authority), my </FONT><BR><FONT size=2>personal opinion is that anything 
      you read into 509 text on that specific </FONT><BR><FONT size=2>topic 
      would be accidental as I don't recall any specific discussion on it. 
      </FONT><BR><FONT size=2>However, since that is a real world requirement, I 
      would want to be sure </FONT><BR><FONT size=2>that 509 did not prohibit 
      it.</FONT> </P>
      <P><FONT size=2>Hope that clarifies where my comments are coming from :-) 
      </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; </FONT></P>
      <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
      size=2>&gt; From: David A. Cooper [<A 
      href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
      <BR><FONT size=2>&gt; Sent: Friday, April 20, 2001 11:44 AM</FONT> 
      <BR><FONT size=2>&gt; To: [e-mail]</FONT> <BR><FONT size=2>&gt; 
      Subject: RE: cA flag and CRL issuers (was Re: Last Call:</FONT> <BR><FONT 
      size=2>&gt; draft-ietf-pkix-n ew-part1-06.txt comments)</FONT> <BR><FONT 
      size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
      Sharon,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Are you 
      suggesting that in order for an entity to issue CRLs </FONT><BR><FONT 
      size=2>&gt; on behalf of a certificate issuer, that CRL issuer would need 
      </FONT><BR><FONT size=2>&gt; to issue certificates as well (so that it can 
      qualify as an </FONT><BR><FONT size=2>&gt; authority)?&nbsp; I don't think 
      there should be such a </FONT><BR><FONT size=2>&gt; requirement, but even 
      if there were it wouldn't settle the issue.</FONT> <BR><FONT size=2>&gt; 
      </FONT><BR><FONT size=2>&gt; Even if only authorities can issue CRLs, 
      there is nothing to </FONT><BR><FONT size=2>&gt; prevent that authority 
      from using different keys to sign </FONT><BR><FONT size=2>&gt; 
      certificates and CRLs.&nbsp; X.509 states that "[t]he cA component 
      </FONT><BR><FONT size=2>&gt; indicates if the certified public key may be 
      used to verify </FONT><BR><FONT size=2>&gt; certificate signatures."&nbsp; 
      So, the proper value of the cA bit </FONT><BR><FONT size=2>&gt; is 
      determined by the allowable uses of the subject public </FONT><BR><FONT 
      size=2>&gt; key, not by the type of entity the subject is.&nbsp; So, even 
      if </FONT><BR><FONT size=2>&gt; the certificate subject is a CA, and 
      issues certificates </FONT><BR><FONT size=2>&gt; under some key, the cA 
      bit should not be set unless the </FONT><BR><FONT size=2>&gt; particular 
      subject public key in the certificate can be used </FONT><BR><FONT 
      size=2>&gt; to verify certificate signatures. If an authority is the 
      </FONT><BR><FONT size=2>&gt; subject of a certificate and the particular 
      public key of </FONT><BR><FONT size=2>&gt; that authority that is being 
      certified is only to be used to </FONT><BR><FONT size=2>&gt; verify 
      signatures on CRLs, then the cA bit should not be set.</FONT> <BR><FONT 
      size=2>&gt; </FONT><BR><FONT size=2>&gt; Dave</FONT> <BR><FONT size=2>&gt; 
      </FONT><BR><FONT size=2>&gt; At 10:48 AM 4/20/01 -0400, Sharon Boeyen 
      wrote:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
      &gt;David, sorry but I disagree with your assertions about X.509's 
      </FONT><BR><FONT size=2>&gt; &gt;position on this issue. Either by design 
      or by accident, </FONT><BR><FONT size=2>&gt; X.509 requires that if CRLs 
      are being issued, they are issued </FONT><BR><FONT size=2>&gt; by an 
      'authority'. Remember that the definition of </FONT><BR><FONT size=2>&gt; 
      "authority" is "An entity responsible </FONT><BR><FONT size=2>&gt; 
      &gt;</FONT> <BR><FONT size=2>&gt; &gt;for the issuance of certificates". 
      Much of the text in X.509 </FONT><BR><FONT size=2>&gt; predates OCSP or 
      the concept of a validation authority, but I </FONT><BR><FONT size=2>&gt; 
      do know that the quotes below are new text added within the 
      </FONT><BR><FONT size=2>&gt; past couple of years with the intent of 
      clarifying the role </FONT><BR><FONT size=2>&gt; of CAs with respect to 
      CRLs.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
      &gt;Clause 7.3 says:&nbsp; </FONT><BR><FONT size=2>&gt; &gt;</FONT> 
      <BR><FONT size=2>&gt; &gt;"An authority that issues certificates is 
      required to state, </FONT><BR><FONT size=2>&gt; possibly through a 
      published statement of their practices, </FONT><BR><FONT size=2>&gt; 
      through the certificates themselves, or through some other 
      </FONT><BR><FONT size=2>&gt; identified means, whether:</FONT> <BR><FONT 
      size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
      &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificates cannot be 
      revoked; or </FONT><BR><FONT size=2>&gt; 
      &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificates may be revoked 
      by the same </FONT><BR><FONT size=2>&gt; certificate-issuing authority 
      directly; or </FONT><BR><FONT size=2>&gt; 
      &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificate-issuing 
      authority authorizes a </FONT><BR><FONT size=2>&gt; different authority to 
      perform revocation." </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
      size=2>&gt; &gt;further down in the same clause is the text: 
      </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;" 
      </FONT><BR><FONT size=2>&gt; &gt;An authority that issues and subsequently 
      revokes certificates: </FONT><BR><FONT size=2>&gt; 
      &gt;a)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may be required to maintain an audit 
      record of its </FONT><BR><FONT size=2>&gt; revocation events for all 
      certificate types issued by that </FONT><BR><FONT size=2>&gt; authority 
      (e.g. public-key certificates, attribute </FONT><BR><FONT size=2>&gt; 
      certificates issued to end-entities as well as other authorities);</FONT> 
      <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
      &gt;b)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shall provide revocation status 
      information to </FONT><BR><FONT size=2>&gt; relying parties using CRLs, 
      on-line certificate status </FONT><BR><FONT size=2>&gt; protocol or some 
      other mechanism for the publication of </FONT><BR><FONT size=2>&gt; 
      revocation status information;</FONT> <BR><FONT size=2>&gt; &gt;</FONT> 
      <BR><FONT size=2>&gt; &gt;c)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if using CRLs, 
      shall maintain and publish CRLs even </FONT><BR><FONT size=2>&gt; if the 
      lists of revoked certificates are empty." </FONT><BR><FONT size=2>&gt; 
      &gt;</FONT> <BR><FONT size=2>&gt; &gt;The quotes that you included in your 
      message tie in with </FONT><BR><FONT size=2>&gt; this base text, since the 
      authority that issued the </FONT><BR><FONT size=2>&gt; certificates has 
      these responsibilities around revocation, </FONT><BR><FONT size=2>&gt; 
      there was no need for X.509 to state anything specific to CRL 
      </FONT><BR><FONT size=2>&gt; issuance. In the indirect CRL case, this was 
      envisioned to be </FONT><BR><FONT size=2>&gt; another CA or AA, that 
      combined revocation notices from </FONT><BR><FONT size=2>&gt; several 
      CAs/AAs. </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
      &gt;Having said that (with my X.509 editor's hat on), if there 
      </FONT><BR><FONT size=2>&gt; is a requirement to have entities that are 
      not CAs or AAs be </FONT><BR><FONT size=2>&gt; authorized to issue CRLs on 
      behalf of the certificate issuer </FONT><BR><FONT size=2>&gt; (because 
      remember that a CRL is an indication that a </FONT><BR><FONT size=2>&gt; 
      certificate is no longer considered valid "by its </FONT><BR><FONT 
      size=2>&gt; issuer")changes to X.509 would be needed. I'm not necessarily 
      </FONT><BR><FONT size=2>&gt; opposed to such changes, I'm just clarifying, 
      in this </FONT><BR><FONT size=2>&gt; message, that they would be needed in 
      order for such </FONT><BR><FONT size=2>&gt; implementations to be 
      conformant. This, as usual could be </FONT><BR><FONT size=2>&gt; done 
      through the enhancements work or could be proposed </FONT><BR><FONT 
      size=2>&gt; through the defect process. One way to enable that kind of 
      </FONT><BR><FONT size=2>&gt; change might be to redefine authority and to 
      talk about 3 </FONT><BR><FONT size=2>&gt; types rather than two. However, 
      it would take some careful </FONT><BR><FONT size=2>&gt; review to ensure 
      that the set of changes was thorough and complete.</FONT> <BR><FONT 
      size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;Sharon </FONT><BR><FONT 
      size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; -----Original 
      Message----- </FONT><BR><FONT size=2>&gt; &gt; &gt; From: David A. Cooper 
      </FONT><BR><FONT size=2>&gt; [&lt;<A 
      href="mailto:[e-mail]">mailto:[e-mail]</A>&gt;<A 
      href="mailto:[e-mail]">mailto:[e-mail]</A>] 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; Sent: Thursday, April 19, 2001 5:08 
      PM </FONT><BR><FONT size=2>&gt; &gt; &gt; To: [e-mail] 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; Subject: cA flag and CRL issuers 
      (was Re: Last Call: </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      draft-ietf-pkix-new-part1-06.txt comments) </FONT><BR><FONT size=2>&gt; 
      &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; At 07:17 PM 4/18/01 -0400, Stephen Kent wrote: 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt;Dave Cooper, </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      &gt;&gt;At 01:40 PM 4/18/01 -0400, David A. Cooper wrote: </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; &gt;&gt;I see no basis in X.509 for setting the cA 
      flag in </FONT><BR><FONT size=2>&gt; &gt; &gt; basicConstraints for 
      certificate subjects that can issue CRLs </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; but not certificates. The current discussion about how to 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; deal with CRLs for attribute 
      certificates vs. public key </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      certificates just further goes to show that it was a mistake 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; to suddenly change the rules at the 
      last IETF meeting. </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt;We disagree on this point. 
      Nowhere in X.509 or in previous </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      PKIX documents has there ever been text to suggest that other 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; than a CA can sign a CRL for a 
      public key certificate. So, </FONT><BR><FONT size=2>&gt; &gt; &gt; the 
      rules were not changed at the last meeting, they were </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; reasserted and clarified. </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; Steve, 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; You may say that X.509 and PKIX do not suggest that entities 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; other than CAs can sign CRLs. 
      However, I think we all agree </FONT><BR><FONT size=2>&gt; &gt; &gt; that 
      both X.509 and PKIX allow for a CRL to be signed with a </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; different key than the key used to sign the 
      certificates that </FONT><BR><FONT size=2>&gt; &gt; &gt; are covered by 
      that CRL. This may be a result of the CA that </FONT><BR><FONT size=2>&gt; 
      &gt; &gt; issued the certificates signing the corresponding CRLs with a 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; different key or the CA that issued 
      the certificates </FONT><BR><FONT size=2>&gt; &gt; &gt; delegating the CRL 
      issuing to another entity (via the </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      distribution points extension). There is no requirement that 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; the key used to sign the CRL also 
      be used to sign </FONT><BR><FONT size=2>&gt; &gt; &gt; certificates. So, I 
      think we agree that there will be times </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; where we will be issuing certificates to entities (whether 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; those entities are CAs or not) 
      where the intent is to specify </FONT><BR><FONT size=2>&gt; &gt; &gt; that 
      the public keys in the certificates may be used to </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; verify signatures on CRLs but not on certificates. 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; The only place we seem to disagree is on the contents of the 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; certificates issued in such 
      circumstances. In particular, </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      should the certificates contain a basicConstraints extension 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; with the cA bit set? On this point, 
      both X.509 and the </FONT><BR><FONT size=2>&gt; &gt; &gt; previous PKIX 
      documents are quite clear that the cA bit </FONT><BR><FONT size=2>&gt; 
      &gt; &gt; should not be set. Why? Because a CA is defined as an entity 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; that issues public-key certificates 
      and both documents </FONT><BR><FONT size=2>&gt; &gt; &gt; similarly state 
      that the cA bit is used to specify whether </FONT><BR><FONT size=2>&gt; 
      &gt; &gt; the certificate subject can issue certificates. There is no 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; similar connection made between 
      being a CA and issuing CRLs. </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; The following are some quotes from X.509 and pkix-new-part1-05: 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; In X.509 a CA is defined as "[a]n authority trusted by one or 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; more users to create and assign 
      public-key certificates." </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; Section 7 of X.509 states that "[a] 
      CA-certificate is a </FONT><BR><FONT size=2>&gt; &gt; &gt; certificate 
      issued by a CA to a subject that is itself a CA </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; and therefore is capable of issuing public-key 
      certificates." </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; The 
      description of basic constraints in X.509 further </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; supports the idea that the cA bit is used to specify 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; certificate issuing, not 
      certificate and/or CRL issuing: </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; "This field indicates if the 
      subject may act as a CA, with </FONT><BR><FONT size=2>&gt; &gt; &gt; the 
      certified public key being used to verify certificate </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; signatures. ... The cA component indicates if the 
      certified </FONT><BR><FONT size=2>&gt; &gt; &gt; public key may be used to 
      verify certificate signatures. ... if </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; the value of cA is not set to true then the certified public 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; key shall not be used to verify a 
      certificate signature" </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; pkix-new-part1-05 states something similar: </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; "The cA bit 
      indicates if the certified public key may be used </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; to verify signatures on other certificates. If the 
      cA bit is </FONT><BR><FONT size=2>&gt; &gt; &gt; asserted, then the 
      keyCertSign bit in the key usage extension </FONT><BR><FONT size=2>&gt; 
      &gt; &gt; (see 4.2.1.3) MUST also be asserted. If the cA bit is not 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; asserted, then the keyCertSign bit 
      in the key usage extension </FONT><BR><FONT size=2>&gt; &gt; &gt; MUST NOT 
      be asserted." </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; The 
      description of the key usage bits are consistent with </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; this as well. </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; X.509: </FONT><BR><FONT size=2>&gt; 
      &gt; &gt; "The bit keyCertSign is for use in CA-certificates only. If 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; KeyUsage is set to keyCertSign and 
      the basic constraints </FONT><BR><FONT size=2>&gt; &gt; &gt; extension is 
      present in the same certificate, the value of </FONT><BR><FONT size=2>&gt; 
      &gt; &gt; the cA component of that extension shall be set to TRUE." 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; pkix-new-part1-05: </FONT><BR><FONT size=2>&gt; &gt; &gt; "The 
      keyCertSign bit is asserted when the subject public key </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; is used for verifying a signature on 
      certificates.&nbsp; This bit </FONT><BR><FONT size=2>&gt; &gt; &gt; may 
      only be asserted in CA certificates.&nbsp; If the keyCertSign 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; bit is asserted, then the cA bit in 
      the basic constraints </FONT><BR><FONT size=2>&gt; &gt; &gt; extension 
      (see 4.2.1.10) MUST also be asserted. If the </FONT><BR><FONT size=2>&gt; 
      &gt; &gt; keyCertSign bit is not asserted, then the cA bit in the basic 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; constraints extension MUST NOT be 
      asserted. </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; The cRLSign bit is asserted when the subject public 
      key is </FONT><BR><FONT size=2>&gt; &gt; &gt; used for verifying a 
      signature on revocation information </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      (e.g., a CRL)." </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; So, both X.509 and 
      pkix-new-part1-05 go to great lengths to </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; clearly state that only CAs can issue certificates and that 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; basicConstraints with the cA bit 
      set to true must be present </FONT><BR><FONT size=2>&gt; &gt; &gt; in the 
      certificates where the public key is to be used to </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; verify signatures on certificates. There are no 
      similar </FONT><BR><FONT size=2>&gt; &gt; &gt; statements about CRLs. In 
      fact, both documents are quite </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      clear that the cA bit must not be set when the subject public 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; key can not be used to verify 
      certificates. So, if the </FONT><BR><FONT size=2>&gt; &gt; &gt; subject 
      public key can be used to verify CRLs, but not </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; certificates, the cA bit must not be set. 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; X.509 is also careful not to preclude the public keys of 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; non-CAs from being used to verify 
      signatures on CRLs. For </FONT><BR><FONT size=2>&gt; &gt; &gt; instance, 
      an end entity is defined as "[a] certificate </FONT><BR><FONT size=2>&gt; 
      &gt; &gt; subject that uses its private key for purposes other than 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; signing certificates or an entity 
      that is a relying party." </FONT><BR><FONT size=2>&gt; &gt; &gt; This 
      leaves room for an end entity to use its private key to </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; sign CRLs. </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; So, if PKIX wants to require that the cA bit be set whenever 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; the subject public key can be used 
      to verify CRLs and also </FONT><BR><FONT size=2>&gt; &gt; &gt; wants to 
      maintain consistency with X.509, PKIX would have to </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; require that any certificate authorizing the use of 
      a public </FONT><BR><FONT size=2>&gt; &gt; &gt; key for verifying CRL 
      signatures also authorize the use of </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; that public key for verifying certificate signatures. Since 
      </FONT><BR><FONT size=2>&gt; &gt; &gt; we are in agreement that we do not 
      want to impose such a </FONT><BR><FONT size=2>&gt; &gt; &gt; restriction 
      and that we do want to maintain consistency with </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; X.509, we can not require that the cA bit be set 
      when the </FONT><BR><FONT size=2>&gt; &gt; &gt; subject public key can 
      only be used to verify CRL signatures. </FONT><BR><FONT size=2>&gt; &gt; 
      &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; Dave </FONT><BR><FONT 
      size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
      </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0C9D4.0FD1C7B0--


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA02637 for <[e-mail]>; Fri, 20 Apr 2001 12:11:07 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <2VH1APQA>; Fri, 20 Apr 2001 15:10:33 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Sharon Boeyen <[e-mail]>, [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)
Date: Fri, 20 Apr 2001 15:05:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9CC.D034B380"

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_01C0C9CC.D034B380
Content-Type: text/plain;
	charset="iso-8859-1"

The point that I think is a bit different is the use of the CA bit in basic
constraints. This is one of many 'business controls' that a CA can put into
a certificate that it issues to another CA to restrict the set of paths
(including that certificate) that can be successfully validated. In my mind
this extension exists so that a relying party can know whether the
certificate they are processing is one that certifies a key that can be used
to verify the signature of the next cert in the path. Full stop. It isn't an
'authorization' of any entity to issue certificates but a signal to the
relying party that the certified key can be used for verifying the next
signature. The pathLengthConstraint component of that extension, along with
all the other business control extensions (policy stuff, name constraints
etc) further retrict a relying party with respect to the certification paths
(and contained certificates) that can be successfully validated using the
certificate that contains the extensions. Each issuer has the ability to
place such restrictions and the complete validation of the path depends, in
part on those constraints.  
 
When we look at the two basic trust models (hierarchical and distributed),
then this does get muddled somewhat, because in a hierarchy there is sort of
a sense of 'authorization' of subordinate CAs. The same is not true in a
distributed trust model. A CA is any entity that issues public-key
certificates regardless of whether some other CA happens to have issued it a
certificate containing the basic constraints extension with the CA bit set
to true. The extension really only matters when one tries to validate a
certification path and needs to be sure that the issuer of a particular
certificate 'trusts' certificates signed with the key corresponding to that
certified in the current certificate. 
 
Consider the above 2 paragraphs my personal opinion on basicConstraints. 
 
As for attribute certificates and attribute authorities, in some
environments there is absolutely no need to tie the PMI to the PKI. The
verifiers may import one or more trust anchors for SOAs, similar to how they
do today for PKI trust anchors. However, in other environments, there was a
requirement to have a single trust anchor and be able to validate both
public key and attribute certificates. For this reason, X.509 added the
sOAIdentifier extension. Its syntax is NULL. Its only purpose in life is to
support this requirement of binding a PMI to a PKI.  As for the attribute
certificate 'equivalent' of a certification path, this is a delegation path.
There are completely different extensions defined to ensure that a
delegationPath is valid (although you will recognize similarities).
basicAttConstraints inidicates whether or not the assigned privilege can be
further delegated by the subject of the containing certificate. 'Business
controls' extensions include delegatedNameConstraints,
acceptableCertPolicies, authorityAttributeIdentifier (to ensure that the
delegating authority actually holds sufficicient privilege to delegate it)
etc). Don't try to shoehorn the PKI extensions into the PMI model. The only
real overlap is that we reused the basic CRL structure. 
 
Hope that helps and doesn't confuse the issues further :-)
 
Sharon
 
 -----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, April 20, 2001 2:08 PM
To: 'Sharon Boeyen'; [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n
ew-part1-06.txt comments)



Sharon,
 
Much of this question arose from how to deal with AC "authorities".  I don't
have access at the moment to the X. version of the AC draft (yes I know I
can now get it), but do you believe that AC issuers and "revokers" need to
be authorities in that the CA bit should be set for them?
 
jim

-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]]
Sent: Friday, April 20, 2001 9:57 AM
To: 'David A. Cooper'; [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n
ew-part1-06.txt comments)



Just to be clear, lets not confuse what I may happen to want as 
an individual contributor to PKIX or any other list, with what 
I state as 509 editor (they're not necessarily always the same :-) 

My comments were purely from the editor's perspective and yes, 
the current 509 text is quite clear that the CA that issues a 
certificate is responsible for stating whether or not that certificate 
can be revoked, and if so, what mechanism is used to inform 
relying parties. If that mechanism is CRLs, these are issued by 
the certificate issuer or by another authority delegated that 
task by the certificate issuer (that doesn't necessarily mean that 
509 requires a cert to be issued to that authority, nor that the cert 
contain the basic constraints extension though, that is the job of 
profile groups to determine and incidentally I don't believe they'll 
all adopt the same solution so I would want 509 to remain flexible). 

My own personal view is that industry has moved to a point where there 
probably isn't any real requirement for a CRL issuer to also be a cert 
issuer as long as that CRL issuer is delegated that responsibility 
by the cert issuer and there is a cryptographic way to ensure that 
binding for relying parties. To achieve that, I believe some changes 
are required in 509. 

On the separate keys for cert and CRL signing (by the same authority), my 
personal opinion is that anything you read into 509 text on that specific 
topic would be accidental as I don't recall any specific discussion on it. 
However, since that is a real world requirement, I would want to be sure 
that 509 did not prohibit it. 

Hope that clarifies where my comments are coming from :-) 
    

> -----Original Message----- 
> From: David A. Cooper [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Friday, April 20, 2001 11:44 AM 
> To: [e-mail] 
> Subject: RE: cA flag and CRL issuers (was Re: Last Call: 
> draft-ietf-pkix-n ew-part1-06.txt comments) 
> 
> 
> Sharon, 
> 
> Are you suggesting that in order for an entity to issue CRLs 
> on behalf of a certificate issuer, that CRL issuer would need 
> to issue certificates as well (so that it can qualify as an 
> authority)?  I don't think there should be such a 
> requirement, but even if there were it wouldn't settle the issue. 
> 
> Even if only authorities can issue CRLs, there is nothing to 
> prevent that authority from using different keys to sign 
> certificates and CRLs.  X.509 states that "[t]he cA component 
> indicates if the certified public key may be used to verify 
> certificate signatures."  So, the proper value of the cA bit 
> is determined by the allowable uses of the subject public 
> key, not by the type of entity the subject is.  So, even if 
> the certificate subject is a CA, and issues certificates 
> under some key, the cA bit should not be set unless the 
> particular subject public key in the certificate can be used 
> to verify certificate signatures. If an authority is the 
> subject of a certificate and the particular public key of 
> that authority that is being certified is only to be used to 
> verify signatures on CRLs, then the cA bit should not be set. 
> 
> Dave 
> 
> At 10:48 AM 4/20/01 -0400, Sharon Boeyen wrote: 
> 
> >David, sorry but I disagree with your assertions about X.509's 
> >position on this issue. Either by design or by accident, 
> X.509 requires that if CRLs are being issued, they are issued 
> by an 'authority'. Remember that the definition of 
> "authority" is "An entity responsible 
> > 
> >for the issuance of certificates". Much of the text in X.509 
> predates OCSP or the concept of a validation authority, but I 
> do know that the quotes below are new text added within the 
> past couple of years with the intent of clarifying the role 
> of CAs with respect to CRLs. 
> > 
> >Clause 7.3 says:  
> > 
> >"An authority that issues certificates is required to state, 
> possibly through a published statement of their practices, 
> through the certificates themselves, or through some other 
> identified means, whether: 
> > 
> >-       The certificates cannot be revoked; or 
> >-       The certificates may be revoked by the same 
> certificate-issuing authority directly; or 
> >-       The certificate-issuing authority authorizes a 
> different authority to perform revocation." 
> > 
> >further down in the same clause is the text: 
> > 
> >" 
> >An authority that issues and subsequently revokes certificates: 
> >a)      may be required to maintain an audit record of its 
> revocation events for all certificate types issued by that 
> authority (e.g. public-key certificates, attribute 
> certificates issued to end-entities as well as other authorities); 
> > 
> >b)      shall provide revocation status information to 
> relying parties using CRLs, on-line certificate status 
> protocol or some other mechanism for the publication of 
> revocation status information; 
> > 
> >c)      if using CRLs, shall maintain and publish CRLs even 
> if the lists of revoked certificates are empty." 
> > 
> >The quotes that you included in your message tie in with 
> this base text, since the authority that issued the 
> certificates has these responsibilities around revocation, 
> there was no need for X.509 to state anything specific to CRL 
> issuance. In the indirect CRL case, this was envisioned to be 
> another CA or AA, that combined revocation notices from 
> several CAs/AAs. 
> > 
> >Having said that (with my X.509 editor's hat on), if there 
> is a requirement to have entities that are not CAs or AAs be 
> authorized to issue CRLs on behalf of the certificate issuer 
> (because remember that a CRL is an indication that a 
> certificate is no longer considered valid "by its 
> issuer")changes to X.509 would be needed. I'm not necessarily 
> opposed to such changes, I'm just clarifying, in this 
> message, that they would be needed in order for such 
> implementations to be conformant. This, as usual could be 
> done through the enhancements work or could be proposed 
> through the defect process. One way to enable that kind of 
> change might be to redefine authority and to talk about 3 
> types rather than two. However, it would take some careful 
> review to ensure that the set of changes was thorough and complete. 
> > 
> >Sharon 
> > 
> > > -----Original Message----- 
> > > From: David A. Cooper 
> [< mailto:[e-mail] <mailto:[e-mail]> >
mailto:[e-mail] <mailto:[e-mail]> ] 
> > > Sent: Thursday, April 19, 2001 5:08 PM 
> > > To: [e-mail] 
> > > Subject: cA flag and CRL issuers (was Re: Last Call: 
> > > draft-ietf-pkix-new-part1-06.txt comments) 
> > > 
> > > 
> > > At 07:17 PM 4/18/01 -0400, Stephen Kent wrote: 
> > > >Dave Cooper, 
> > > > 
> > > >>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote: 
> > > >>I see no basis in X.509 for setting the cA flag in 
> > > basicConstraints for certificate subjects that can issue CRLs 
> > > but not certificates. The current discussion about how to 
> > > deal with CRLs for attribute certificates vs. public key 
> > > certificates just further goes to show that it was a mistake 
> > > to suddenly change the rules at the last IETF meeting. 
> > > > 
> > > >We disagree on this point. Nowhere in X.509 or in previous 
> > > PKIX documents has there ever been text to suggest that other 
> > > than a CA can sign a CRL for a public key certificate. So, 
> > > the rules were not changed at the last meeting, they were 
> > > reasserted and clarified. 
> > > 
> > > Steve, 
> > > 
> > > You may say that X.509 and PKIX do not suggest that entities 
> > > other than CAs can sign CRLs. However, I think we all agree 
> > > that both X.509 and PKIX allow for a CRL to be signed with a 
> > > different key than the key used to sign the certificates that 
> > > are covered by that CRL. This may be a result of the CA that 
> > > issued the certificates signing the corresponding CRLs with a 
> > > different key or the CA that issued the certificates 
> > > delegating the CRL issuing to another entity (via the 
> > > distribution points extension). There is no requirement that 
> > > the key used to sign the CRL also be used to sign 
> > > certificates. So, I think we agree that there will be times 
> > > where we will be issuing certificates to entities (whether 
> > > those entities are CAs or not) where the intent is to specify 
> > > that the public keys in the certificates may be used to 
> > > verify signatures on CRLs but not on certificates. 
> > > 
> > > The only place we seem to disagree is on the contents of the 
> > > certificates issued in such circumstances. In particular, 
> > > should the certificates contain a basicConstraints extension 
> > > with the cA bit set? On this point, both X.509 and the 
> > > previous PKIX documents are quite clear that the cA bit 
> > > should not be set. Why? Because a CA is defined as an entity 
> > > that issues public-key certificates and both documents 
> > > similarly state that the cA bit is used to specify whether 
> > > the certificate subject can issue certificates. There is no 
> > > similar connection made between being a CA and issuing CRLs. 
> > > 
> > > 
> > > The following are some quotes from X.509 and pkix-new-part1-05: 
> > > 
> > > In X.509 a CA is defined as "[a]n authority trusted by one or 
> > > more users to create and assign public-key certificates." 
> > > 
> > > Section 7 of X.509 states that "[a] CA-certificate is a 
> > > certificate issued by a CA to a subject that is itself a CA 
> > > and therefore is capable of issuing public-key certificates." 
> > > 
> > > 
> > > The description of basic constraints in X.509 further 
> > > supports the idea that the cA bit is used to specify 
> > > certificate issuing, not certificate and/or CRL issuing: 
> > > 
> > > "This field indicates if the subject may act as a CA, with 
> > > the certified public key being used to verify certificate 
> > > signatures. ... The cA component indicates if the certified 
> > > public key may be used to verify certificate signatures. ... if 
> > > the value of cA is not set to true then the certified public 
> > > key shall not be used to verify a certificate signature" 
> > > 
> > > 
> > > pkix-new-part1-05 states something similar: 
> > > 
> > > "The cA bit indicates if the certified public key may be used 
> > > to verify signatures on other certificates. If the cA bit is 
> > > asserted, then the keyCertSign bit in the key usage extension 
> > > (see 4.2.1.3) MUST also be asserted. If the cA bit is not 
> > > asserted, then the keyCertSign bit in the key usage extension 
> > > MUST NOT be asserted." 
> > > 
> > > 
> > > The description of the key usage bits are consistent with 
> > > this as well. 
> > > 
> > > X.509: 
> > > "The bit keyCertSign is for use in CA-certificates only. If 
> > > KeyUsage is set to keyCertSign and the basic constraints 
> > > extension is present in the same certificate, the value of 
> > > the cA component of that extension shall be set to TRUE." 
> > > 
> > > pkix-new-part1-05: 
> > > "The keyCertSign bit is asserted when the subject public key 
> > > is used for verifying a signature on certificates.  This bit 
> > > may only be asserted in CA certificates.  If the keyCertSign 
> > > bit is asserted, then the cA bit in the basic constraints 
> > > extension (see 4.2.1.10) MUST also be asserted. If the 
> > > keyCertSign bit is not asserted, then the cA bit in the basic 
> > > constraints extension MUST NOT be asserted. 
> > > 
> > > The cRLSign bit is asserted when the subject public key is 
> > > used for verifying a signature on revocation information 
> > > (e.g., a CRL)." 
> > > 
> > > 
> > > 
> > > So, both X.509 and pkix-new-part1-05 go to great lengths to 
> > > clearly state that only CAs can issue certificates and that 
> > > basicConstraints with the cA bit set to true must be present 
> > > in the certificates where the public key is to be used to 
> > > verify signatures on certificates. There are no similar 
> > > statements about CRLs. In fact, both documents are quite 
> > > clear that the cA bit must not be set when the subject public 
> > > key can not be used to verify certificates. So, if the 
> > > subject public key can be used to verify CRLs, but not 
> > > certificates, the cA bit must not be set. 
> > > 
> > > X.509 is also careful not to preclude the public keys of 
> > > non-CAs from being used to verify signatures on CRLs. For 
> > > instance, an end entity is defined as "[a] certificate 
> > > subject that uses its private key for purposes other than 
> > > signing certificates or an entity that is a relying party." 
> > > This leaves room for an end entity to use its private key to 
> > > sign CRLs. 
> > > 
> > > 
> > > So, if PKIX wants to require that the cA bit be set whenever 
> > > the subject public key can be used to verify CRLs and also 
> > > wants to maintain consistency with X.509, PKIX would have to 
> > > require that any certificate authorizing the use of a public 
> > > key for verifying CRL signatures also authorize the use of 
> > > that public key for verifying certificate signatures. Since 
> > > we are in agreement that we do not want to impose such a 
> > > restriction and that we do want to maintain consistency with 
> > > X.509, we can not require that the cA bit be set when the 
> > > subject public key can only be used to verify CRL signatures. 
> > > 
> > > Dave 
> > > 
> > > 
> 
> 


------_=_NextPart_001_01C0C9CC.D034B380
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff size=2>The 
point that I think is a bit different is the use of the CA bit in basic 
constraints. This is one of many 'business controls' that a CA can put into a 
certificate that it issues to another CA to restrict the set of paths (including 
that certificate) that can be successfully validated. In my mind this extension 
exists so that a relying party can know whether the certificate they are 
processing is one that certifies a key that can be used to verify the signature 
of the next cert in the path. Full stop. It isn't an 'authorization' of any 
entity to issue certificates but a signal to the relying party that the 
certified key can be used for verifying the next signature. The 
pathLengthConstraint component of that extension, along with all the other 
business control extensions (policy stuff, name constraints etc) further retrict 
a relying party with respect to the certification paths (and contained 
certificates) that can be successfully validated using the certificate that 
contains the extensions. Each issuer has the ability to place such restrictions 
and the complete validation of the path depends, in part on those 
constraints.&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=934173718-20042001></SPAN>&nbsp;</DIV>
<DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff size=2>When 
we look at the two basic trust models (hierarchical and distributed), then this 
does get muddled somewhat, because in a hierarchy there is sort of a sense of 
'authorization' of subordinate CAs. The same is not true in a distributed trust 
model. A CA is&nbsp;any entity that issues public-key certificates regardless of 
whether some other CA happens to have issued it a certificate containing the 
basic constraints extension with the CA bit set to true. The extension really 
only matters when one tries to validate a certification path and needs to be 
sure that the issuer of a particular certificate 'trusts' certificates signed 
with the key corresponding to that certified in the current certificate. 
</FONT></SPAN></DIV>
<DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
size=2>Consider the above 2 paragraphs my personal opinion on basicConstraints. 
</FONT></SPAN></DIV>
<DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff size=2>As for 
attribute certificates and attribute authorities, in some environments there is 
absolutely no need to tie the PMI to the PKI. The verifiers may import one or 
more trust anchors for SOAs, similar to how they do today for PKI trust anchors. 
However, in other environments, there was a requirement to have a single trust 
anchor and be able to validate both public key and attribute certificates. For 
this reason, X.509 added the sOAIdentifier&nbsp;extension. Its syntax is NULL. 
Its only purpose in life is to support this requirement of binding a PMI to a 
PKI.&nbsp; As for the attribute certificate 'equivalent' of a certification 
path, this is a delegation path. There are completely different extensions 
defined to ensure that a delegationPath is valid (although you will recognize 
similarities). basicAttConstraints inidicates whether or not the assigned 
privilege can be further delegated by the subject of the containing certificate. 
'Business controls' extensions include delegatedNameConstraints, 
acceptableCertPolicies, authorityAttributeIdentifier (to ensure that the 
delegating authority actually holds sufficicient privilege to delegate it) etc). 
Don't try to shoehorn the PKI extensions into the PMI model. The only real 
overlap is that we reused the basic CRL structure. </FONT></SPAN></DIV>
<DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff size=2>Hope 
that helps and doesn't confuse the issues further :-)</FONT></SPAN></DIV>
<DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=934173718-20042001><FONT face=Arial color=#0000ff 
size=2>Sharon</FONT></SPAN></DIV>
<DIV><SPAN class=934173718-20042001></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=934173718-20042001><FONT face=Arial 
color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=934173718-20042001>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Jim Schaad [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 20, 2001 2:08 
PM<BR><B>To:</B> 'Sharon Boeyen'; [e-mail]<BR><B>Subject:</B> RE: cA 
flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt 
comments)<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=128290618-20042001>Sharon,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=128290618-20042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=128290618-20042001>Much 
  of this question arose from how to deal with AC "authorities".&nbsp; I don't 
  have access at the moment to the X. version of the AC draft (yes I know I can 
  now get it), but do you believe that AC issuers and "revokers" need to be 
  authorities in that the CA bit should be set for them?</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=128290618-20042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=128290618-20042001>jim</SPAN></FONT></DIV>
  <BLOCKQUOTE 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen 
    [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 20, 2001 
    9:57 AM<BR><B>To:</B> 'David A. Cooper'; 
    [e-mail]<BR><B>Subject:</B> RE: cA flag and CRL issuers (was Re: 
    Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)<BR><BR></DIV></FONT>
    <P><FONT size=2>Just to be clear, lets not confuse what I may happen to want 
    as </FONT><BR><FONT size=2>an individual contributor to PKIX or any other 
    list, with what </FONT><BR><FONT size=2>I state as 509 editor (they're not 
    necessarily always the same :-)</FONT> </P>
    <P><FONT size=2>My comments were purely from the editor's perspective and 
    yes, </FONT><BR><FONT size=2>the current 509 text is quite clear that the CA 
    that issues a </FONT><BR><FONT size=2>certificate is responsible for stating 
    whether or not that certificate</FONT> <BR><FONT size=2>can be revoked, and 
    if so, what mechanism is used to inform </FONT><BR><FONT size=2>relying 
    parties. If that mechanism is CRLs, these are issued by </FONT><BR><FONT 
    size=2>the certificate issuer or by another authority delegated that 
    </FONT><BR><FONT size=2>task by the certificate issuer (that doesn't 
    necessarily mean that </FONT><BR><FONT size=2>509 requires a cert to be 
    issued to that authority, nor that the cert </FONT><BR><FONT size=2>contain 
    the basic constraints extension though, that is the job of </FONT><BR><FONT 
    size=2>profile groups to determine and incidentally I don't believe they'll 
    </FONT><BR><FONT size=2>all adopt the same solution so I would want 509 to 
    remain flexible). </FONT></P>
    <P><FONT size=2>My own personal view is that industry has moved to a point 
    where there </FONT><BR><FONT size=2>probably isn't any real requirement for 
    a CRL issuer to also be a cert</FONT> <BR><FONT size=2>issuer as long as 
    that CRL issuer is delegated that responsibility </FONT><BR><FONT size=2>by 
    the cert issuer and there is a cryptographic way to ensure that 
    </FONT><BR><FONT size=2>binding for relying parties. To achieve that, I 
    believe some changes </FONT><BR><FONT size=2>are required in 509. 
</FONT></P>
    <P><FONT size=2>On the separate keys for cert and CRL signing (by the same 
    authority), my </FONT><BR><FONT size=2>personal opinion is that anything you 
    read into 509 text on that specific </FONT><BR><FONT size=2>topic would be 
    accidental as I don't recall any specific discussion on it. </FONT><BR><FONT 
    size=2>However, since that is a real world requirement, I would want to be 
    sure </FONT><BR><FONT size=2>that 509 did not prohibit it.</FONT> </P>
    <P><FONT size=2>Hope that clarifies where my comments are coming from :-) 
    </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; </FONT></P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: David A. Cooper [<A 
    href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: Friday, April 20, 2001 11:44 AM</FONT> <BR><FONT 
    size=2>&gt; To: [e-mail]</FONT> <BR><FONT size=2>&gt; Subject: RE: 
    cA flag and CRL issuers (was Re: Last Call:</FONT> <BR><FONT size=2>&gt; 
    draft-ietf-pkix-n ew-part1-06.txt comments)</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Sharon,</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Are you suggesting that 
    in order for an entity to issue CRLs </FONT><BR><FONT size=2>&gt; on behalf 
    of a certificate issuer, that CRL issuer would need </FONT><BR><FONT 
    size=2>&gt; to issue certificates as well (so that it can qualify as an 
    </FONT><BR><FONT size=2>&gt; authority)?&nbsp; I don't think there should be 
    such a </FONT><BR><FONT size=2>&gt; requirement, but even if there were it 
    wouldn't settle the issue.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; Even if only authorities can issue CRLs, there is nothing to 
    </FONT><BR><FONT size=2>&gt; prevent that authority from using different 
    keys to sign </FONT><BR><FONT size=2>&gt; certificates and CRLs.&nbsp; X.509 
    states that "[t]he cA component </FONT><BR><FONT size=2>&gt; indicates if 
    the certified public key may be used to verify </FONT><BR><FONT size=2>&gt; 
    certificate signatures."&nbsp; So, the proper value of the cA bit 
    </FONT><BR><FONT size=2>&gt; is determined by the allowable uses of the 
    subject public </FONT><BR><FONT size=2>&gt; key, not by the type of entity 
    the subject is.&nbsp; So, even if </FONT><BR><FONT size=2>&gt; the 
    certificate subject is a CA, and issues certificates </FONT><BR><FONT 
    size=2>&gt; under some key, the cA bit should not be set unless the 
    </FONT><BR><FONT size=2>&gt; particular subject public key in the 
    certificate can be used </FONT><BR><FONT size=2>&gt; to verify certificate 
    signatures. If an authority is the </FONT><BR><FONT size=2>&gt; subject of a 
    certificate and the particular public key of </FONT><BR><FONT size=2>&gt; 
    that authority that is being certified is only to be used to 
    </FONT><BR><FONT size=2>&gt; verify signatures on CRLs, then the cA bit 
    should not be set.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    Dave</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; At 10:48 AM 
    4/20/01 -0400, Sharon Boeyen wrote:</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; &gt;David, sorry but I disagree with your 
    assertions about X.509's </FONT><BR><FONT size=2>&gt; &gt;position on this 
    issue. Either by design or by accident, </FONT><BR><FONT size=2>&gt; X.509 
    requires that if CRLs are being issued, they are issued </FONT><BR><FONT 
    size=2>&gt; by an 'authority'. Remember that the definition of 
    </FONT><BR><FONT size=2>&gt; "authority" is "An entity responsible 
    </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;for the 
    issuance of certificates". Much of the text in X.509 </FONT><BR><FONT 
    size=2>&gt; predates OCSP or the concept of a validation authority, but I 
    </FONT><BR><FONT size=2>&gt; do know that the quotes below are new text 
    added within the </FONT><BR><FONT size=2>&gt; past couple of years with the 
    intent of clarifying the role </FONT><BR><FONT size=2>&gt; of CAs with 
    respect to CRLs.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
    size=2>&gt; &gt;Clause 7.3 says:&nbsp; </FONT><BR><FONT size=2>&gt; 
    &gt;</FONT> <BR><FONT size=2>&gt; &gt;"An authority that issues certificates 
    is required to state, </FONT><BR><FONT size=2>&gt; possibly through a 
    published statement of their practices, </FONT><BR><FONT size=2>&gt; through 
    the certificates themselves, or through some other </FONT><BR><FONT 
    size=2>&gt; identified means, whether:</FONT> <BR><FONT size=2>&gt; 
    &gt;</FONT> <BR><FONT size=2>&gt; &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    The certificates cannot be revoked; or </FONT><BR><FONT size=2>&gt; 
    &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificates may be revoked by 
    the same </FONT><BR><FONT size=2>&gt; certificate-issuing authority 
    directly; or </FONT><BR><FONT size=2>&gt; 
    &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificate-issuing authority 
    authorizes a </FONT><BR><FONT size=2>&gt; different authority to perform 
    revocation." </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
    &gt;further down in the same clause is the text: </FONT><BR><FONT 
    size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;" </FONT><BR><FONT 
    size=2>&gt; &gt;An authority that issues and subsequently revokes 
    certificates: </FONT><BR><FONT size=2>&gt; 
    &gt;a)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may be required to maintain an audit 
    record of its </FONT><BR><FONT size=2>&gt; revocation events for all 
    certificate types issued by that </FONT><BR><FONT size=2>&gt; authority 
    (e.g. public-key certificates, attribute </FONT><BR><FONT size=2>&gt; 
    certificates issued to end-entities as well as other authorities);</FONT> 
    <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
    &gt;b)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shall provide revocation status 
    information to </FONT><BR><FONT size=2>&gt; relying parties using CRLs, 
    on-line certificate status </FONT><BR><FONT size=2>&gt; protocol or some 
    other mechanism for the publication of </FONT><BR><FONT size=2>&gt; 
    revocation status information;</FONT> <BR><FONT size=2>&gt; &gt;</FONT> 
    <BR><FONT size=2>&gt; &gt;c)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if using CRLs, 
    shall maintain and publish CRLs even </FONT><BR><FONT size=2>&gt; if the 
    lists of revoked certificates are empty." </FONT><BR><FONT size=2>&gt; 
    &gt;</FONT> <BR><FONT size=2>&gt; &gt;The quotes that you included in your 
    message tie in with </FONT><BR><FONT size=2>&gt; this base text, since the 
    authority that issued the </FONT><BR><FONT size=2>&gt; certificates has 
    these responsibilities around revocation, </FONT><BR><FONT size=2>&gt; there 
    was no need for X.509 to state anything specific to CRL </FONT><BR><FONT 
    size=2>&gt; issuance. In the indirect CRL case, this was envisioned to be 
    </FONT><BR><FONT size=2>&gt; another CA or AA, that combined revocation 
    notices from </FONT><BR><FONT size=2>&gt; several CAs/AAs. </FONT><BR><FONT 
    size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;Having said that (with my 
    X.509 editor's hat on), if there </FONT><BR><FONT size=2>&gt; is a 
    requirement to have entities that are not CAs or AAs be </FONT><BR><FONT 
    size=2>&gt; authorized to issue CRLs on behalf of the certificate issuer 
    </FONT><BR><FONT size=2>&gt; (because remember that a CRL is an indication 
    that a </FONT><BR><FONT size=2>&gt; certificate is no longer considered 
    valid "by its </FONT><BR><FONT size=2>&gt; issuer")changes to X.509 would be 
    needed. I'm not necessarily </FONT><BR><FONT size=2>&gt; opposed to such 
    changes, I'm just clarifying, in this </FONT><BR><FONT size=2>&gt; message, 
    that they would be needed in order for such </FONT><BR><FONT size=2>&gt; 
    implementations to be conformant. This, as usual could be </FONT><BR><FONT 
    size=2>&gt; done through the enhancements work or could be proposed 
    </FONT><BR><FONT size=2>&gt; through the defect process. One way to enable 
    that kind of </FONT><BR><FONT size=2>&gt; change might be to redefine 
    authority and to talk about 3 </FONT><BR><FONT size=2>&gt; types rather than 
    two. However, it would take some careful </FONT><BR><FONT size=2>&gt; review 
    to ensure that the set of changes was thorough and complete.</FONT> 
    <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;Sharon 
    </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
    -----Original Message----- </FONT><BR><FONT size=2>&gt; &gt; &gt; From: 
    David A. Cooper </FONT><BR><FONT size=2>&gt; [&lt;<A 
    href="mailto:[e-mail]">mailto:[e-mail]</A>&gt;<A 
    href="mailto:[e-mail]">mailto:[e-mail]</A>] 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; Sent: Thursday, April 19, 2001 5:08 
    PM </FONT><BR><FONT size=2>&gt; &gt; &gt; To: [e-mail] 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; Subject: cA flag and CRL issuers (was 
    Re: Last Call: </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    draft-ietf-pkix-new-part1-06.txt comments) </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
    &gt; &gt; At 07:17 PM 4/18/01 -0400, Stephen Kent wrote: </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; &gt;Dave Cooper, </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt;&gt;At 01:40 PM 4/18/01 
    -0400, David A. Cooper wrote: </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    &gt;&gt;I see no basis in X.509 for setting the cA flag in </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; basicConstraints for certificate subjects that can 
    issue CRLs </FONT><BR><FONT size=2>&gt; &gt; &gt; but not certificates. The 
    current discussion about how to </FONT><BR><FONT size=2>&gt; &gt; &gt; deal 
    with CRLs for attribute certificates vs. public key </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; certificates just further goes to show that it was a 
    mistake </FONT><BR><FONT size=2>&gt; &gt; &gt; to suddenly change the rules 
    at the last IETF meeting. </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt;We disagree on this point. 
    Nowhere in X.509 or in previous </FONT><BR><FONT size=2>&gt; &gt; &gt; PKIX 
    documents has there ever been text to suggest that other </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; than a CA can sign a CRL for a public key certificate. 
    So, </FONT><BR><FONT size=2>&gt; &gt; &gt; the rules were not changed at the 
    last meeting, they were </FONT><BR><FONT size=2>&gt; &gt; &gt; reasserted 
    and clarified. </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; Steve, </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; You may say that X.509 and PKIX do 
    not suggest that entities </FONT><BR><FONT size=2>&gt; &gt; &gt; other than 
    CAs can sign CRLs. However, I think we all agree </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; that both X.509 and PKIX allow for a CRL to be signed 
    with a </FONT><BR><FONT size=2>&gt; &gt; &gt; different key than the key 
    used to sign the certificates that </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    are covered by that CRL. This may be a result of the CA that 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; issued the certificates signing the 
    corresponding CRLs with a </FONT><BR><FONT size=2>&gt; &gt; &gt; different 
    key or the CA that issued the certificates </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; delegating the CRL issuing to another entity (via the </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; distribution points extension). There is no 
    requirement that </FONT><BR><FONT size=2>&gt; &gt; &gt; the key used to sign 
    the CRL also be used to sign </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    certificates. So, I think we agree that there will be times </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; where we will be issuing certificates to entities 
    (whether </FONT><BR><FONT size=2>&gt; &gt; &gt; those entities are CAs or 
    not) where the intent is to specify </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    that the public keys in the certificates may be used to </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; verify signatures on CRLs but not on certificates. 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; The only place we seem to disagree is on the contents of the 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; certificates issued in such 
    circumstances. In particular, </FONT><BR><FONT size=2>&gt; &gt; &gt; should 
    the certificates contain a basicConstraints extension </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; with the cA bit set? On this point, both X.509 and the 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; previous PKIX documents are quite 
    clear that the cA bit </FONT><BR><FONT size=2>&gt; &gt; &gt; should not be 
    set. Why? Because a CA is defined as an entity </FONT><BR><FONT size=2>&gt; 
    &gt; &gt; that issues public-key certificates and both documents 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; similarly state that the cA bit is 
    used to specify whether </FONT><BR><FONT size=2>&gt; &gt; &gt; the 
    certificate subject can issue certificates. There is no </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; similar connection made between being a CA and issuing 
    CRLs. </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
    &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; The following are some 
    quotes from X.509 and pkix-new-part1-05: </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; In X.509 a CA is defined as 
    "[a]n authority trusted by one or </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    more users to create and assign public-key certificates." </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; Section 7 of 
    X.509 states that "[a] CA-certificate is a </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; certificate issued by a CA to a subject that is itself a CA 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; and therefore is capable of issuing 
    public-key certificates." </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; The description of basic constraints in X.509 further </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; supports the idea that the cA bit is used to specify 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; certificate issuing, not certificate 
    and/or CRL issuing: </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; "This field indicates if the subject may act as a CA, 
    with </FONT><BR><FONT size=2>&gt; &gt; &gt; the certified public key being 
    used to verify certificate </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    signatures. ... The cA component indicates if the certified </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; public key may be used to verify certificate 
    signatures. ... if </FONT><BR><FONT size=2>&gt; &gt; &gt; the value of cA is 
    not set to true then the certified public </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; key shall not be used to verify a certificate signature" 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; pkix-new-part1-05 states 
    something similar: </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; "The cA bit indicates if the certified public key may 
    be used </FONT><BR><FONT size=2>&gt; &gt; &gt; to verify signatures on other 
    certificates. If the cA bit is </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    asserted, then the keyCertSign bit in the key usage extension 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; (see 4.2.1.3) MUST also be asserted. 
    If the cA bit is not </FONT><BR><FONT size=2>&gt; &gt; &gt; asserted, then 
    the keyCertSign bit in the key usage extension </FONT><BR><FONT size=2>&gt; 
    &gt; &gt; MUST NOT be asserted." </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; The description of the key usage bits are consistent with 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; this as well. </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; X.509: 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; "The bit keyCertSign is for use in 
    CA-certificates only. If </FONT><BR><FONT size=2>&gt; &gt; &gt; KeyUsage is 
    set to keyCertSign and the basic constraints </FONT><BR><FONT size=2>&gt; 
    &gt; &gt; extension is present in the same certificate, the value of 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; the cA component of that extension 
    shall be set to TRUE." </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; pkix-new-part1-05: </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; "The keyCertSign bit is asserted when the subject 
    public key </FONT><BR><FONT size=2>&gt; &gt; &gt; is used for verifying a 
    signature on certificates.&nbsp; This bit </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; may only be asserted in CA certificates.&nbsp; If the keyCertSign 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; bit is asserted, then the cA bit in 
    the basic constraints </FONT><BR><FONT size=2>&gt; &gt; &gt; extension (see 
    4.2.1.10) MUST also be asserted. If the </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; keyCertSign bit is not asserted, then the cA bit in the basic 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; constraints extension MUST NOT be 
    asserted. </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; The cRLSign bit is asserted when the subject public 
    key is </FONT><BR><FONT size=2>&gt; &gt; &gt; used for verifying a signature 
    on revocation information </FONT><BR><FONT size=2>&gt; &gt; &gt; (e.g., a 
    CRL)." </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
    &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; So, both X.509 and pkix-new-part1-05 go to great 
    lengths to </FONT><BR><FONT size=2>&gt; &gt; &gt; clearly state that only 
    CAs can issue certificates and that </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    basicConstraints with the cA bit set to true must be present 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; in the certificates where the public 
    key is to be used to </FONT><BR><FONT size=2>&gt; &gt; &gt; verify 
    signatures on certificates. There are no similar </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; statements about CRLs. In fact, both documents are 
    quite </FONT><BR><FONT size=2>&gt; &gt; &gt; clear that the cA bit must not 
    be set when the subject public </FONT><BR><FONT size=2>&gt; &gt; &gt; key 
    can not be used to verify certificates. So, if the </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; subject public key can be used to verify CRLs, but not 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; certificates, the cA bit must not be 
    set. </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
    &gt; &gt; X.509 is also careful not to preclude the public keys of 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; non-CAs from being used to verify 
    signatures on CRLs. For </FONT><BR><FONT size=2>&gt; &gt; &gt; instance, an 
    end entity is defined as "[a] certificate </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; subject that uses its private key for purposes other than 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; signing certificates or an entity 
    that is a relying party." </FONT><BR><FONT size=2>&gt; &gt; &gt; This leaves 
    room for an end entity to use its private key to </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; sign CRLs. </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; So, if PKIX wants to require that the cA bit be set whenever 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; the subject public key can be used to 
    verify CRLs and also </FONT><BR><FONT size=2>&gt; &gt; &gt; wants to 
    maintain consistency with X.509, PKIX would have to </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; require that any certificate authorizing the use of a 
    public </FONT><BR><FONT size=2>&gt; &gt; &gt; key for verifying CRL 
    signatures also authorize the use of </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    that public key for verifying certificate signatures. Since </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; we are in agreement that we do not want to impose such 
    a </FONT><BR><FONT size=2>&gt; &gt; &gt; restriction and that we do want to 
    maintain consistency with </FONT><BR><FONT size=2>&gt; &gt; &gt; X.509, we 
    can not require that the cA bit be set when the </FONT><BR><FONT size=2>&gt; 
    &gt; &gt; subject public key can only be used to verify CRL signatures. 
    </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
    &gt; Dave </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
    size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0C9CC.D034B380--


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA02340 for <[e-mail]>; Fri, 20 Apr 2001 12:06:38 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 20 Apr 2001 12:06:46 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 20 Apr 2001 12:06:46 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26PPWB>; Fri, 20 Apr 2001 12:05:35 -0700
Content-return: allowed
Date: Fri, 20 Apr 2001 12:05:30 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Meaning of Non-repudiation
To: "'Tom Gindin'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

When NIST?NSA folk evaluate a US network product/system, formally, 
they must, traditionally, use the following conceptions of NR. 
(Steve's notions of subject intent, and presumptions of signature
binding, are not relevant to a formal evaluation of a product/system
claiming to provide NR.)

It would be useful for some of our friends from NCSC/NIST
to perhaps find an actual evaluation/certification report
that certified an actual network product/system as meeting the
evaluation criteria for NR. This would provide us
with an example protocol under the Red Book
that was deemed "correct", as required by the criteria. 

Nothing in this NCSC criteria require (X.509) certs be used, or
particular bits be present in said certs.

Modern form of the criteria (CC 2.1) do not differ
in the criteria definition, though they remove the
material about digital signatures in favor of
requirements on evidence. They make no statements
about certificates. 
http://csrc.nist.gov/cc/ccv20/ccv2list.htm#ISO

Neither NCSC nor CC criteria deviate from NR being
(a) a network-based service that is semantically
tied to assertions of sending/receving messages,
and (b) an assurance of identity during an exchange
process, versus intent upon using a key. 

"4 Class FCO: Communication


137 This class provides two families specifically concerned with assuring
the identity
of a party participating in a data exchange. These families are related to
assuring the
identity of the originator of transmitted information (proof of origin) and
assuring
the identity of the recipient of transmitted information (proof of receipt).
These
families ensure that an originator cannot deny having sent the message, nor
can the
recipient deny having received it."


Peter.


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


http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-005.pdf

9.1.3. Non-repudiation
_ _ _ ___ ___________

+ Functionality
_____________

Non-repudiation service provides unforgeable proof of
shipment and/or receipt of data.

This service prevents the sender from disavowing a leg-itimate
message or the recipient from denying receipt. The
network may provide either or both of the following two
forms:

1. The recipient of data is provided with proof of
origin of data that will protect against any
attempt by the sender to falsely deny sending the
data or its contents.

2. The sender is provided with proof of delivery of
data such that the recipient cannot later deny
receiving the data or its contents.

Basis for Rating: Presence or absence of each of the
two forms.

Evaluation Range: None or present.

Discussion: Digital signatures are available techniques
that may be applied to non-repudiation mechanisms. Digital
signature mechanisms define two procedures:

1. Signing a data unit
2. Verifying a signed data unit

The signing process typically employs either an enci-pherment
of the data unit or the production of a crypto-graphic
checkfunction of the data unit, using the signer's private information 
as a private key.

The verification process involves using the public pro-cedure
and information to determine whether the signature
was produced with the signer's private key.

It is essential that the signature mechanism be
unforgeable and adjudicable. This means that the signature
can only be produced using the signer's private information,
and in case the signer should disavow signing the message,
it must be possible for a judge or arbitrator to resolve a
dispute arising between the signer and the recipient of the
message.

Digital signature schemes are usually classified into
one of two categories: true signatures or arbitrated signa-tures.

In a true signature scheme, signed messages produced
by the sender are transmitted directly to the receiver who
verifies their validity and authenticity. In an arbitrated
signature scheme, all signed messages are transmitted from
the sender to the receiver via an arbitrator who serves as a
notary public. In the latter case, a notarization mechanism
is needed.

Both public-key and conventional private-key cryptosys-tems
can be utilized to generate digital signatures. When a
message M is to be signed by a private-key cryptosystem, the
signature is a computed quantity catenated to M and sent
along with it. In a public-key implementation, when a mes-sage
M is to be signed, a transformation using the secret
key is applied to M before transmitting it. Thus, the signa-ture
is presented by the resulting transformed message.

+ Strength of Mechanism
________ __ _________

Basis for Rating: The strength and trustworthiness
given to non-repudiation service is bounded by the trust in
the underlying cryptography implementing digital signature
mechanism, the correctness of the protocol logic, and the
adequacy of protocol implementation. Additional information
may be found in the separate sections addressing these sub-jects.

Evaluation Range: None to good.

+ Assurance
_________

Basis for Rating: Assurance is concerned with guaran-teeing
or providing confidence that features to provide
non-repudiation service have been implemented correctly and
that the control objectives of each feature have been actu-
ally and accurately achieved.

This assurance is addressed by analysis of the logic of
the protocols and the implementation of the digital signa-ture
mechanisms to show correctness and effectiveness by
formal methods where possible (i.e., where tools exist) and
informal ones otherwise.

The information in the General Assurance, Encryption
Mechanisms, and Protocols sections also applies.

Evaluation Range: None to good.

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Wednesday, April 11, 2001 3:51 PM
To: Stephen Kent
Cc: David P. Kemp; [e-mail]
Subject: Re: Meaning of Non-repudiation



     IMHO, if X.509 had not been calling the bit in KeyUsage
"non-repudiation" for some years, I would prefer to put "Persistent Data
Authentication" into KeyUsage and define several different flavors of
non-repudiation in ExtendedKeyUsage, profiling non-repudiation services in
parallel with those ExtendedKeyUsage values.  This would also allow us to
define different levels of NR and put them into certificates in a natural
way.  However, they have been calling the bit "non-repudiation", and I'm
not sure we can change its meaning on the installed base of certificates
and on the X.509 group without an unusual level of unanimity and
near-certainty that it won't break anything.

          Tom Gindin



Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA00313 for <[e-mail]>; Fri, 20 Apr 2001 11:05:30 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010420180253.ZFGV26961.femail3.sdc1.sfba.home.com@revelation>; Fri, 20 Apr 2001 11:02:53 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, <[e-mail]>
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)
Date: Fri, 20 Apr 2001 11:08:10 -0700
Message-ID: <001701c0c9c4$dd846bf0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C0C98A.313376A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0018_01C0C98A.313376A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n
ew-part1-06.txt comments)Sharon,

Much of this question arose from how to deal with AC "authorities".  I don't
have access at the moment to the X. version of the AC draft (yes I know I
can now get it), but do you believe that AC issuers and "revokers" need to
be authorities in that the CA bit should be set for them?

jim
  -----Original Message-----
  From: Sharon Boeyen [mailto:[e-mail]]
  Sent: Friday, April 20, 2001 9:57 AM
  To: 'David A. Cooper'; [e-mail]
  Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n
ew-part1-06.txt comments)


  Just to be clear, lets not confuse what I may happen to want as
  an individual contributor to PKIX or any other list, with what
  I state as 509 editor (they're not necessarily always the same :-)

  My comments were purely from the editor's perspective and yes,
  the current 509 text is quite clear that the CA that issues a
  certificate is responsible for stating whether or not that certificate
  can be revoked, and if so, what mechanism is used to inform
  relying parties. If that mechanism is CRLs, these are issued by
  the certificate issuer or by another authority delegated that
  task by the certificate issuer (that doesn't necessarily mean that
  509 requires a cert to be issued to that authority, nor that the cert
  contain the basic constraints extension though, that is the job of
  profile groups to determine and incidentally I don't believe they'll
  all adopt the same solution so I would want 509 to remain flexible).

  My own personal view is that industry has moved to a point where there
  probably isn't any real requirement for a CRL issuer to also be a cert
  issuer as long as that CRL issuer is delegated that responsibility
  by the cert issuer and there is a cryptographic way to ensure that
  binding for relying parties. To achieve that, I believe some changes
  are required in 509.

  On the separate keys for cert and CRL signing (by the same authority), my
  personal opinion is that anything you read into 509 text on that specific
  topic would be accidental as I don't recall any specific discussion on it.
  However, since that is a real world requirement, I would want to be sure
  that 509 did not prohibit it.

  Hope that clarifies where my comments are coming from :-)


  > -----Original Message-----
  > From: David A. Cooper [mailto:[e-mail]]
  > Sent: Friday, April 20, 2001 11:44 AM
  > To: [e-mail]
  > Subject: RE: cA flag and CRL issuers (was Re: Last Call:
  > draft-ietf-pkix-n ew-part1-06.txt comments)
  >
  >
  > Sharon,
  >
  > Are you suggesting that in order for an entity to issue CRLs
  > on behalf of a certificate issuer, that CRL issuer would need
  > to issue certificates as well (so that it can qualify as an
  > authority)?  I don't think there should be such a
  > requirement, but even if there were it wouldn't settle the issue.
  >
  > Even if only authorities can issue CRLs, there is nothing to
  > prevent that authority from using different keys to sign
  > certificates and CRLs.  X.509 states that "[t]he cA component
  > indicates if the certified public key may be used to verify
  > certificate signatures."  So, the proper value of the cA bit
  > is determined by the allowable uses of the subject public
  > key, not by the type of entity the subject is.  So, even if
  > the certificate subject is a CA, and issues certificates
  > under some key, the cA bit should not be set unless the
  > particular subject public key in the certificate can be used
  > to verify certificate signatures. If an authority is the
  > subject of a certificate and the particular public key of
  > that authority that is being certified is only to be used to
  > verify signatures on CRLs, then the cA bit should not be set.
  >
  > Dave
  >
  > At 10:48 AM 4/20/01 -0400, Sharon Boeyen wrote:
  >
  > >David, sorry but I disagree with your assertions about X.509's
  > >position on this issue. Either by design or by accident,
  > X.509 requires that if CRLs are being issued, they are issued
  > by an 'authority'. Remember that the definition of
  > "authority" is "An entity responsible
  > >
  > >for the issuance of certificates". Much of the text in X.509
  > predates OCSP or the concept of a validation authority, but I
  > do know that the quotes below are new text added within the
  > past couple of years with the intent of clarifying the role
  > of CAs with respect to CRLs.
  > >
  > >Clause 7.3 says:
  > >
  > >"An authority that issues certificates is required to state,
  > possibly through a published statement of their practices,
  > through the certificates themselves, or through some other
  > identified means, whether:
  > >
  > >-       The certificates cannot be revoked; or
  > >-       The certificates may be revoked by the same
  > certificate-issuing authority directly; or
  > >-       The certificate-issuing authority authorizes a
  > different authority to perform revocation."
  > >
  > >further down in the same clause is the text:
  > >
  > >"
  > >An authority that issues and subsequently revokes certificates:
  > >a)      may be required to maintain an audit record of its
  > revocation events for all certificate types issued by that
  > authority (e.g. public-key certificates, attribute
  > certificates issued to end-entities as well as other authorities);
  > >
  > >b)      shall provide revocation status information to
  > relying parties using CRLs, on-line certificate status
  > protocol or some other mechanism for the publication of
  > revocation status information;
  > >
  > >c)      if using CRLs, shall maintain and publish CRLs even
  > if the lists of revoked certificates are empty."
  > >
  > >The quotes that you included in your message tie in with
  > this base text, since the authority that issued the
  > certificates has these responsibilities around revocation,
  > there was no need for X.509 to state anything specific to CRL
  > issuance. In the indirect CRL case, this was envisioned to be
  > another CA or AA, that combined revocation notices from
  > several CAs/AAs.
  > >
  > >Having said that (with my X.509 editor's hat on), if there
  > is a requirement to have entities that are not CAs or AAs be
  > authorized to issue CRLs on behalf of the certificate issuer
  > (because remember that a CRL is an indication that a
  > certificate is no longer considered valid "by its
  > issuer")changes to X.509 would be needed. I'm not necessarily
  > opposed to such changes, I'm just clarifying, in this
  > message, that they would be needed in order for such
  > implementations to be conformant. This, as usual could be
  > done through the enhancements work or could be proposed
  > through the defect process. One way to enable that kind of
  > change might be to redefine authority and to talk about 3
  > types rather than two. However, it would take some careful
  > review to ensure that the set of changes was thorough and complete.
  > >
  > >Sharon
  > >
  > > > -----Original Message-----
  > > > From: David A. Cooper
  > [<mailto:[e-mail]>mailto:[e-mail]]
  > > > Sent: Thursday, April 19, 2001 5:08 PM
  > > > To: [e-mail]
  > > > Subject: cA flag and CRL issuers (was Re: Last Call:
  > > > draft-ietf-pkix-new-part1-06.txt comments)
  > > >
  > > >
  > > > At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:
  > > > >Dave Cooper,
  > > > >
  > > > >>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:
  > > > >>I see no basis in X.509 for setting the cA flag in
  > > > basicConstraints for certificate subjects that can issue CRLs
  > > > but not certificates. The current discussion about how to
  > > > deal with CRLs for attribute certificates vs. public key
  > > > certificates just further goes to show that it was a mistake
  > > > to suddenly change the rules at the last IETF meeting.
  > > > >
  > > > >We disagree on this point. Nowhere in X.509 or in previous
  > > > PKIX documents has there ever been text to suggest that other
  > > > than a CA can sign a CRL for a public key certificate. So,
  > > > the rules were not changed at the last meeting, they were
  > > > reasserted and clarified.
  > > >
  > > > Steve,
  > > >
  > > > You may say that X.509 and PKIX do not suggest that entities
  > > > other than CAs can sign CRLs. However, I think we all agree
  > > > that both X.509 and PKIX allow for a CRL to be signed with a
  > > > different key than the key used to sign the certificates that
  > > > are covered by that CRL. This may be a result of the CA that
  > > > issued the certificates signing the corresponding CRLs with a
  > > > different key or the CA that issued the certificates
  > > > delegating the CRL issuing to another entity (via the
  > > > distribution points extension). There is no requirement that
  > > > the key used to sign the CRL also be used to sign
  > > > certificates. So, I think we agree that there will be times
  > > > where we will be issuing certificates to entities (whether
  > > > those entities are CAs or not) where the intent is to specify
  > > > that the public keys in the certificates may be used to
  > > > verify signatures on CRLs but not on certificates.
  > > >
  > > > The only place we seem to disagree is on the contents of the
  > > > certificates issued in such circumstances. In particular,
  > > > should the certificates contain a basicConstraints extension
  > > > with the cA bit set? On this point, both X.509 and the
  > > > previous PKIX documents are quite clear that the cA bit
  > > > should not be set. Why? Because a CA is defined as an entity
  > > > that issues public-key certificates and both documents
  > > > similarly state that the cA bit is used to specify whether
  > > > the certificate subject can issue certificates. There is no
  > > > similar connection made between being a CA and issuing CRLs.
  > > >
  > > >
  > > > The following are some quotes from X.509 and pkix-new-part1-05:
  > > >
  > > > In X.509 a CA is defined as "[a]n authority trusted by one or
  > > > more users to create and assign public-key certificates."
  > > >
  > > > Section 7 of X.509 states that "[a] CA-certificate is a
  > > > certificate issued by a CA to a subject that is itself a CA
  > > > and therefore is capable of issuing public-key certificates."
  > > >
  > > >
  > > > The description of basic constraints in X.509 further
  > > > supports the idea that the cA bit is used to specify
  > > > certificate issuing, not certificate and/or CRL issuing:
  > > >
  > > > "This field indicates if the subject may act as a CA, with
  > > > the certified public key being used to verify certificate
  > > > signatures. ... The cA component indicates if the certified
  > > > public key may be used to verify certificate signatures. ... if
  > > > the value of cA is not set to true then the certified public
  > > > key shall not be used to verify a certificate signature"
  > > >
  > > >
  > > > pkix-new-part1-05 states something similar:
  > > >
  > > > "The cA bit indicates if the certified public key may be used
  > > > to verify signatures on other certificates. If the cA bit is
  > > > asserted, then the keyCertSign bit in the key usage extension
  > > > (see 4.2.1.3) MUST also be asserted. If the cA bit is not
  > > > asserted, then the keyCertSign bit in the key usage extension
  > > > MUST NOT be asserted."
  > > >
  > > >
  > > > The description of the key usage bits are consistent with
  > > > this as well.
  > > >
  > > > X.509:
  > > > "The bit keyCertSign is for use in CA-certificates only. If
  > > > KeyUsage is set to keyCertSign and the basic constraints
  > > > extension is present in the same certificate, the value of
  > > > the cA component of that extension shall be set to TRUE."
  > > >
  > > > pkix-new-part1-05:
  > > > "The keyCertSign bit is asserted when the subject public key
  > > > is used for verifying a signature on certificates.  This bit
  > > > may only be asserted in CA certificates.  If the keyCertSign
  > > > bit is asserted, then the cA bit in the basic constraints
  > > > extension (see 4.2.1.10) MUST also be asserted. If the
  > > > keyCertSign bit is not asserted, then the cA bit in the basic
  > > > constraints extension MUST NOT be asserted.
  > > >
  > > > The cRLSign bit is asserted when the subject public key is
  > > > used for verifying a signature on revocation information
  > > > (e.g., a CRL)."
  > > >
  > > >
  > > >
  > > > So, both X.509 and pkix-new-part1-05 go to great lengths to
  > > > clearly state that only CAs can issue certificates and that
  > > > basicConstraints with the cA bit set to true must be present
  > > > in the certificates where the public key is to be used to
  > > > verify signatures on certificates. There are no similar
  > > > statements about CRLs. In fact, both documents are quite
  > > > clear that the cA bit must not be set when the subject public
  > > > key can not be used to verify certificates. So, if the
  > > > subject public key can be used to verify CRLs, but not
  > > > certificates, the cA bit must not be set.
  > > >
  > > > X.509 is also careful not to preclude the public keys of
  > > > non-CAs from being used to verify signatures on CRLs. For
  > > > instance, an end entity is defined as "[a] certificate
  > > > subject that uses its private key for purposes other than
  > > > signing certificates or an entity that is a relying party."
  > > > This leaves room for an end entity to use its private key to
  > > > sign CRLs.
  > > >
  > > >
  > > > So, if PKIX wants to require that the cA bit be set whenever
  > > > the subject public key can be used to verify CRLs and also
  > > > wants to maintain consistency with X.509, PKIX would have to
  > > > require that any certificate authorizing the use of a public
  > > > key for verifying CRL signatures also authorize the use of
  > > > that public key for verifying certificate signatures. Since
  > > > we are in agreement that we do not want to impose such a
  > > > restriction and that we do want to maintain consistency with
  > > > X.509, we can not require that the cA bit be set when the
  > > > subject public key can only be used to verify CRL signatures.
  > > >
  > > > Dave
  > > >
  > > >
  >
  >


------=_NextPart_000_0018_01C0C98A.313376A0
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">
<TITLE>RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n =
ew-part1-06.txt comments)</TITLE>

<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D128290618-20042001>Sharon,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D128290618-20042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D128290618-20042001>Much=20
of this question arose from how to deal with AC "authorities".&nbsp; I =
don't=20
have access at the moment to the X. version of the AC draft (yes I know =
I can=20
now get it), but do you believe that AC issuers and "revokers" need to =
be=20
authorities in that the CA bit should be set for =
them?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D128290618-20042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D128290618-20042001>jim</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 20, =
2001 9:57=20
  AM<BR><B>To:</B> 'David A. Cooper'; =
[e-mail]<BR><B>Subject:</B> RE:=20
  cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n =
ew-part1-06.txt=20
  comments)<BR><BR></DIV></FONT>
  <P><FONT size=3D2>Just to be clear, lets not confuse what I may happen =
to want=20
  as </FONT><BR><FONT size=3D2>an individual contributor to PKIX or any =
other=20
  list, with what </FONT><BR><FONT size=3D2>I state as 509 editor =
(they're not=20
  necessarily always the same :-)</FONT> </P>
  <P><FONT size=3D2>My comments were purely from the editor's =
perspective and yes,=20
  </FONT><BR><FONT size=3D2>the current 509 text is quite clear that the =
CA that=20
  issues a </FONT><BR><FONT size=3D2>certificate is responsible for =
stating=20
  whether or not that certificate</FONT> <BR><FONT size=3D2>can be =
revoked, and if=20
  so, what mechanism is used to inform </FONT><BR><FONT size=3D2>relying =
parties.=20
  If that mechanism is CRLs, these are issued by </FONT><BR><FONT =
size=3D2>the=20
  certificate issuer or by another authority delegated that =
</FONT><BR><FONT=20
  size=3D2>task by the certificate issuer (that doesn't necessarily mean =
that=20
  </FONT><BR><FONT size=3D2>509 requires a cert to be issued to that =
authority,=20
  nor that the cert </FONT><BR><FONT size=3D2>contain the basic =
constraints=20
  extension though, that is the job of </FONT><BR><FONT size=3D2>profile =
groups to=20
  determine and incidentally I don't believe they'll </FONT><BR><FONT =
size=3D2>all=20
  adopt the same solution so I would want 509 to remain flexible). =
</FONT></P>
  <P><FONT size=3D2>My own personal view is that industry has moved to a =
point=20
  where there </FONT><BR><FONT size=3D2>probably isn't any real =
requirement for a=20
  CRL issuer to also be a cert</FONT> <BR><FONT size=3D2>issuer as long =
as that=20
  CRL issuer is delegated that responsibility </FONT><BR><FONT =
size=3D2>by the=20
  cert issuer and there is a cryptographic way to ensure that =
</FONT><BR><FONT=20
  size=3D2>binding for relying parties. To achieve that, I believe some =
changes=20
  </FONT><BR><FONT size=3D2>are required in 509. </FONT></P>
  <P><FONT size=3D2>On the separate keys for cert and CRL signing (by =
the same=20
  authority), my </FONT><BR><FONT size=3D2>personal opinion is that =
anything you=20
  read into 509 text on that specific </FONT><BR><FONT size=3D2>topic =
would be=20
  accidental as I don't recall any specific discussion on it. =
</FONT><BR><FONT=20
  size=3D2>However, since that is a real world requirement, I would want =
to be=20
  sure </FONT><BR><FONT size=3D2>that 509 did not prohibit it.</FONT> =
</P>
  <P><FONT size=3D2>Hope that clarifies where my comments are coming =
from :-)=20
  </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; </FONT></P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: David A. Cooper [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</=
FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Friday, April 20, 2001 11:44 AM</FONT> =
<BR><FONT=20
  size=3D2>&gt; To: [e-mail]</FONT> <BR><FONT size=3D2>&gt; =
Subject: RE: cA=20
  flag and CRL issuers (was Re: Last Call:</FONT> <BR><FONT =
size=3D2>&gt;=20
  draft-ietf-pkix-n ew-part1-06.txt comments)</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
Sharon,</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Are you =
suggesting that in=20
  order for an entity to issue CRLs </FONT><BR><FONT size=3D2>&gt; on =
behalf of a=20
  certificate issuer, that CRL issuer would need </FONT><BR><FONT =
size=3D2>&gt; to=20
  issue certificates as well (so that it can qualify as an =
</FONT><BR><FONT=20
  size=3D2>&gt; authority)?&nbsp; I don't think there should be such a=20
  </FONT><BR><FONT size=3D2>&gt; requirement, but even if there were it =
wouldn't=20
  settle the issue.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  Even if only authorities can issue CRLs, there is nothing to =
</FONT><BR><FONT=20
  size=3D2>&gt; prevent that authority from using different keys to sign =

  </FONT><BR><FONT size=3D2>&gt; certificates and CRLs.&nbsp; X.509 =
states that=20
  "[t]he cA component </FONT><BR><FONT size=3D2>&gt; indicates if the =
certified=20
  public key may be used to verify </FONT><BR><FONT size=3D2>&gt; =
certificate=20
  signatures."&nbsp; So, the proper value of the cA bit </FONT><BR><FONT =

  size=3D2>&gt; is determined by the allowable uses of the subject =
public=20
  </FONT><BR><FONT size=3D2>&gt; key, not by the type of entity the =
subject=20
  is.&nbsp; So, even if </FONT><BR><FONT size=3D2>&gt; the certificate =
subject is=20
  a CA, and issues certificates </FONT><BR><FONT size=3D2>&gt; under =
some key, the=20
  cA bit should not be set unless the </FONT><BR><FONT size=3D2>&gt; =
particular=20
  subject public key in the certificate can be used </FONT><BR><FONT =
size=3D2>&gt;=20
  to verify certificate signatures. If an authority is the =
</FONT><BR><FONT=20
  size=3D2>&gt; subject of a certificate and the particular public key =
of=20
  </FONT><BR><FONT size=3D2>&gt; that authority that is being certified =
is only to=20
  be used to </FONT><BR><FONT size=3D2>&gt; verify signatures on CRLs, =
then the cA=20
  bit should not be set.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =

  size=3D2>&gt; Dave</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; At=20
  10:48 AM 4/20/01 -0400, Sharon Boeyen wrote:</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt;David, sorry but I disagree with =
your=20
  assertions about X.509's </FONT><BR><FONT size=3D2>&gt; &gt;position =
on this=20
  issue. Either by design or by accident, </FONT><BR><FONT size=3D2>&gt; =
X.509=20
  requires that if CRLs are being issued, they are issued =
</FONT><BR><FONT=20
  size=3D2>&gt; by an 'authority'. Remember that the definition of=20
  </FONT><BR><FONT size=3D2>&gt; "authority" is "An entity responsible=20
  </FONT><BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;for the=20
  issuance of certificates". Much of the text in X.509 </FONT><BR><FONT=20
  size=3D2>&gt; predates OCSP or the concept of a validation authority, =
but I=20
  </FONT><BR><FONT size=3D2>&gt; do know that the quotes below are new =
text added=20
  within the </FONT><BR><FONT size=3D2>&gt; past couple of years with =
the intent=20
  of clarifying the role </FONT><BR><FONT size=3D2>&gt; of CAs with =
respect to=20
  CRLs.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;Clause 7.3 says:&nbsp; </FONT><BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;"An authority that issues certificates is required =
to state,=20
  </FONT><BR><FONT size=3D2>&gt; possibly through a published statement =
of their=20
  practices, </FONT><BR><FONT size=3D2>&gt; through the certificates =
themselves,=20
  or through some other </FONT><BR><FONT size=3D2>&gt; identified means, =

  whether:</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificates cannot be =
revoked;=20
  or </FONT><BR><FONT size=3D2>&gt; =
&gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The=20
  certificates may be revoked by the same </FONT><BR><FONT size=3D2>&gt; =

  certificate-issuing authority directly; or </FONT><BR><FONT =
size=3D2>&gt;=20
  &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificate-issuing =
authority=20
  authorizes a </FONT><BR><FONT size=3D2>&gt; different authority to =
perform=20
  revocation." </FONT><BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;further down in the same clause is the text: </FONT><BR><FONT =
size=3D2>&gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;" </FONT><BR><FONT =
size=3D2>&gt; &gt;An=20
  authority that issues and subsequently revokes certificates: =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt;a)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may be required to =
maintain=20
  an audit record of its </FONT><BR><FONT size=3D2>&gt; revocation =
events for all=20
  certificate types issued by that </FONT><BR><FONT size=3D2>&gt; =
authority (e.g.=20
  public-key certificates, attribute </FONT><BR><FONT size=3D2>&gt; =
certificates=20
  issued to end-entities as well as other authorities);</FONT> <BR><FONT =

  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt;=20
  &gt;b)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shall provide revocation status=20
  information to </FONT><BR><FONT size=3D2>&gt; relying parties using =
CRLs,=20
  on-line certificate status </FONT><BR><FONT size=3D2>&gt; protocol or =
some other=20
  mechanism for the publication of </FONT><BR><FONT size=3D2>&gt; =
revocation=20
  status information;</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;c)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if using CRLs, =
shall maintain=20
  and publish CRLs even </FONT><BR><FONT size=3D2>&gt; if the lists of =
revoked=20
  certificates are empty." </FONT><BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;The quotes that you included in your message tie in =
with=20
  </FONT><BR><FONT size=3D2>&gt; this base text, since the authority =
that issued=20
  the </FONT><BR><FONT size=3D2>&gt; certificates has these =
responsibilities=20
  around revocation, </FONT><BR><FONT size=3D2>&gt; there was no need =
for X.509 to=20
  state anything specific to CRL </FONT><BR><FONT size=3D2>&gt; =
issuance. In the=20
  indirect CRL case, this was envisioned to be </FONT><BR><FONT =
size=3D2>&gt;=20
  another CA or AA, that combined revocation notices from =
</FONT><BR><FONT=20
  size=3D2>&gt; several CAs/AAs. </FONT><BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;Having said that (with my X.509 editor's =
hat on), if=20
  there </FONT><BR><FONT size=3D2>&gt; is a requirement to have entities =
that are=20
  not CAs or AAs be </FONT><BR><FONT size=3D2>&gt; authorized to issue =
CRLs on=20
  behalf of the certificate issuer </FONT><BR><FONT size=3D2>&gt; =
(because=20
  remember that a CRL is an indication that a </FONT><BR><FONT =
size=3D2>&gt;=20
  certificate is no longer considered valid "by its </FONT><BR><FONT =
size=3D2>&gt;=20
  issuer")changes to X.509 would be needed. I'm not necessarily =
</FONT><BR><FONT=20
  size=3D2>&gt; opposed to such changes, I'm just clarifying, in this=20
  </FONT><BR><FONT size=3D2>&gt; message, that they would be needed in =
order for=20
  such </FONT><BR><FONT size=3D2>&gt; implementations to be conformant. =
This, as=20
  usual could be </FONT><BR><FONT size=3D2>&gt; done through the =
enhancements work=20
  or could be proposed </FONT><BR><FONT size=3D2>&gt; through the defect =
process.=20
  One way to enable that kind of </FONT><BR><FONT size=3D2>&gt; change =
might be to=20
  redefine authority and to talk about 3 </FONT><BR><FONT size=3D2>&gt; =
types=20
  rather than two. However, it would take some careful </FONT><BR><FONT=20
  size=3D2>&gt; review to ensure that the set of changes was thorough =
and=20
  complete.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;Sharon </FONT><BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; -----Original Message----- </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; From:=20
  David A. Cooper </FONT><BR><FONT size=3D2>&gt; [&lt;<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>&gt=
;<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; Sent: Thursday, April 19, =
2001 5:08 PM=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; To: [e-mail] =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; Subject: cA flag and CRL issuers (was Re: Last =
Call:=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
draft-ietf-pkix-new-part1-06.txt=20
  comments) </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; At 07:17 PM 4/18/01 =
-0400,=20
  Stephen Kent wrote: </FONT><BR><FONT size=3D2>&gt; &gt; &gt; &gt;Dave =
Cooper,=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; &gt;&gt;At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; &gt;&gt;I see no basis in =
X.509 for=20
  setting the cA flag in </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
basicConstraints=20
  for certificate subjects that can issue CRLs </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; but not certificates. The current discussion about how to=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; deal with CRLs for attribute=20
  certificates vs. public key </FONT><BR><FONT size=3D2>&gt; &gt; &gt;=20
  certificates just further goes to show that it was a mistake =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; to suddenly change the rules at the last IETF =
meeting.=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; &gt;We disagree on this point. Nowhere in X.509 or in previous=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; PKIX documents has there ever =
been text=20
  to suggest that other </FONT><BR><FONT size=3D2>&gt; &gt; &gt; than a =
CA can=20
  sign a CRL for a public key certificate. So, </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; the rules were not changed at the last meeting, they were=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; reasserted and clarified.=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt; &gt;=20
  Steve, </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; You may say that X.509 and PKIX do not suggest that entities =

  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; other than CAs can sign CRLs. =
However,=20
  I think we all agree </FONT><BR><FONT size=3D2>&gt; &gt; &gt; that =
both X.509=20
  and PKIX allow for a CRL to be signed with a </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; different key than the key used to sign the certificates that=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; are covered by that CRL. This =
may be a=20
  result of the CA that </FONT><BR><FONT size=3D2>&gt; &gt; &gt; issued =
the=20
  certificates signing the corresponding CRLs with a </FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; different key or the CA that issued the =
certificates=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; delegating the CRL issuing to =
another=20
  entity (via the </FONT><BR><FONT size=3D2>&gt; &gt; &gt; distribution =
points=20
  extension). There is no requirement that </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; the key used to sign the CRL also be used to sign =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; certificates. So, I think we agree that there =
will be=20
  times </FONT><BR><FONT size=3D2>&gt; &gt; &gt; where we will be =
issuing=20
  certificates to entities (whether </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; those=20
  entities are CAs or not) where the intent is to specify =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; that the public keys in the certificates may =
be used to=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; verify signatures on CRLs but =
not on=20
  certificates. </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; The only place we seem to disagree is on the =
contents of=20
  the </FONT><BR><FONT size=3D2>&gt; &gt; &gt; certificates issued in =
such=20
  circumstances. In particular, </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
should=20
  the certificates contain a basicConstraints extension </FONT><BR><FONT =

  size=3D2>&gt; &gt; &gt; with the cA bit set? On this point, both X.509 =
and the=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; previous PKIX documents are =
quite clear=20
  that the cA bit </FONT><BR><FONT size=3D2>&gt; &gt; &gt; should not be =
set. Why?=20
  Because a CA is defined as an entity </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
  that issues public-key certificates and both documents =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; similarly state that the cA bit is used to =
specify=20
  whether </FONT><BR><FONT size=3D2>&gt; &gt; &gt; the certificate =
subject can=20
  issue certificates. There is no </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; similar=20
  connection made between being a CA and issuing CRLs. </FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; The following are some quotes from X.509 and=20
  pkix-new-part1-05: </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; In X.509 a CA is defined as "[a]n authority =
trusted by=20
  one or </FONT><BR><FONT size=3D2>&gt; &gt; &gt; more users to create =
and assign=20
  public-key certificates." </FONT><BR><FONT size=3D2>&gt; &gt; &gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; Section 7 of X.509 states =
that "[a]=20
  CA-certificate is a </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
certificate issued=20
  by a CA to a subject that is itself a CA </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; and therefore is capable of issuing public-key certificates."=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt; &gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; The description of basic =
constraints in=20
  X.509 further </FONT><BR><FONT size=3D2>&gt; &gt; &gt; supports the =
idea that=20
  the cA bit is used to specify </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =

  certificate issuing, not certificate and/or CRL issuing: =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; "This =
field=20
  indicates if the subject may act as a CA, with </FONT><BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; the certified public key being used to verify certificate=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; signatures. ... The cA =
component=20
  indicates if the certified </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
public key=20
  may be used to verify certificate signatures. ... if </FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; the value of cA is not set to true then the =
certified=20
  public </FONT><BR><FONT size=3D2>&gt; &gt; &gt; key shall not be used =
to verify=20
  a certificate signature" </FONT><BR><FONT size=3D2>&gt; &gt; &gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt; &gt;=20
  pkix-new-part1-05 states something similar: </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; "The cA bit indicates if =
the=20
  certified public key may be used </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; to=20
  verify signatures on other certificates. If the cA bit is =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; asserted, then the keyCertSign bit in the key =
usage=20
  extension </FONT><BR><FONT size=3D2>&gt; &gt; &gt; (see 4.2.1.3) MUST =
also be=20
  asserted. If the cA bit is not </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;=20
  asserted, then the keyCertSign bit in the key usage extension =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; MUST NOT be asserted." </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; The description of the key usage bits are consistent with=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; this as well. =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
X.509:=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; "The bit keyCertSign is for =
use in=20
  CA-certificates only. If </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
KeyUsage is=20
  set to keyCertSign and the basic constraints </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; extension is present in the same certificate, the value of=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; the cA component of that =
extension=20
  shall be set to TRUE." </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; pkix-new-part1-05: </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; "The keyCertSign bit is asserted when the subject public key=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; is used for verifying a =
signature on=20
  certificates.&nbsp; This bit </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
may only=20
  be asserted in CA certificates.&nbsp; If the keyCertSign =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; bit is asserted, then the cA bit in the basic=20
  constraints </FONT><BR><FONT size=3D2>&gt; &gt; &gt; extension (see =
4.2.1.10)=20
  MUST also be asserted. If the </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =

  keyCertSign bit is not asserted, then the cA bit in the basic =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; constraints extension MUST NOT be asserted.=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt; &gt;=20
  The cRLSign bit is asserted when the subject public key is =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; used for verifying a signature on revocation =
information=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; (e.g., a CRL)." =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; So, =
both X.509=20
  and pkix-new-part1-05 go to great lengths to </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; clearly state that only CAs can issue certificates and that=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; basicConstraints with the cA =
bit set to=20
  true must be present </FONT><BR><FONT size=3D2>&gt; &gt; &gt; in the=20
  certificates where the public key is to be used to </FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; verify signatures on certificates. There are =
no similar=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; statements about CRLs. In =
fact, both=20
  documents are quite </FONT><BR><FONT size=3D2>&gt; &gt; &gt; clear =
that the cA=20
  bit must not be set when the subject public </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; key can not be used to verify certificates. So, if the =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; subject public key can be used to verify CRLs, =
but not=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; certificates, the cA bit must =
not be=20
  set. </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; X.509 is also careful not to preclude the public keys of =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; non-CAs from being used to verify signatures =
on CRLs.=20
  For </FONT><BR><FONT size=3D2>&gt; &gt; &gt; instance, an end entity =
is defined=20
  as "[a] certificate </FONT><BR><FONT size=3D2>&gt; &gt; &gt; subject =
that uses=20
  its private key for purposes other than </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
  signing certificates or an entity that is a relying party." =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; This leaves room for an end entity to use its =
private=20
  key to </FONT><BR><FONT size=3D2>&gt; &gt; &gt; sign CRLs. =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; So, if PKIX wants to require that the cA bit =
be set=20
  whenever </FONT><BR><FONT size=3D2>&gt; &gt; &gt; the subject public =
key can be=20
  used to verify CRLs and also </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
wants to=20
  maintain consistency with X.509, PKIX would have to </FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt; require that any certificate authorizing the =
use of a=20
  public </FONT><BR><FONT size=3D2>&gt; &gt; &gt; key for verifying CRL =
signatures=20
  also authorize the use of </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
that public=20
  key for verifying certificate signatures. Since </FONT><BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; we are in agreement that we do not want to impose such a=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; restriction and that we do =
want to=20
  maintain consistency with </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
X.509, we can=20
  not require that the cA bit be set when the </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; subject public key can only be used to verify CRL signatures.=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt; &gt;=20
  Dave </FONT><BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0018_01C0C98A.313376A0--



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA28541 for <[e-mail]>; Fri, 20 Apr 2001 10:39:00 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2LAW53F4; Fri, 20 Apr 2001 10:34:20 -0700
From: "Carlin Covey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Sharon Boeyen" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: cA flag and CRL issuers (was Re: Last Call:  draft-ietf-pkix-new-part1-06.txt comments)
Date: Fri, 20 Apr 2001 10:37:58 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>

Denis said:

"In an open architecture where clients do not know where to fetch the
revocation information unless using "out-of-bands" means, if a CA wants to
revoke the authorities in charge of revocation status information (i.e. CRL
Issuers or OCSP responders) they is no other way than using directly the
issuing CA key."

[Carlin]: I agree.  But now that the CRL Issuer's or OCSP responder's
certificate has been revoked, what do the Relying Parties do?  It seems
that they should now look for a CRL issued by the CA, but I haven't found
any document that mandates this behavior on the part of the Relying Parties.


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA27745 for <[e-mail]>; Fri, 20 Apr 2001 10:29:01 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA19911; Fri, 20 Apr 2001 13:28:44 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010410b7051d55d9b1@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 20 Apr 2001 13:31:19 -0400
To: "David A. Cooper" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:   draft-ietf-pkix-new-part1-06.txt comments)
Cc: [e-mail]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA27746

At 5:08 PM -0400 4/19/01, David A. Cooper wrote:
>At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:
>>Dave Cooper,
>>
>>>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:
>>>I see no basis in X.509 for setting the cA flag in 
>>>basicConstraints for certificate subjects that can issue CRLs but 
>>>not certificates. The current discussion about how to deal with 
>>>CRLs for attribute certificates vs. public key certificates just 
>>>further goes to show that it was a mistake to suddenly change the 
>>>rules at the last IETF meeting.
>>
>>We disagree on this point. Nowhere in X.509 or in previous PKIX 
>>documents has there ever been text to suggest that other than a CA 
>>can sign a CRL for a public key certificate. So, the rules were not 
>>changed at the last meeting, they were reasserted and clarified.
>
>Steve,
>
>You may say that X.509 and PKIX do not suggest that entities other 
>than CAs can sign CRLs.

Sharon has explained what X.509 stated re this topic and it is clear, 
although the wording might be improved. PKIX had the same notion, but 
was too concise and a bit oblique in its wording.

>However, I think we all agree that both X.509 and PKIX allow for a 
>CRL to be signed with a different key than the key used to sign the 
>certificates that are covered by that CRL.

yes.

>This may be a result of the CA that issued the certificates signing 
>the corresponding CRLs with a different key or the CA that issued 
>the certificates delegating the CRL issuing to another entity (via 
>the distribution points extension).

yes.

>There is no requirement that the key used to sign the CRL also be 
>used to sign certificates. So, I think we agree that there will be 
>times where we will be issuing certificates to entities (whether 
>those entities are CAs or not) where the intent is to specify that 
>the public keys in the certificates may be used to verify signatures 
>on CRLs but not on certificates.

yes.

>The only place we seem to disagree is on the contents of the 
>certificates issued in such circumstances. In particular, should the 
>certificates contain a basicConstraints extension with the cA bit 
>set? On this point, both X.509 and the previous PKIX documents are 
>quite clear that the cA bit should not be set. Why? Because a CA is 
>defined as an entity that issues public-key certificates and both 
>documents similarly state that the cA bit is used to specify whether 
>the certificate subject can issue certificates. There is no similar 
>connection made between being a CA and issuing CRLs.

We disagree here.

>The following are some quotes from X.509 and pkix-new-part1-05:
>
>In X.509 a CA is defined as "[a]n authority trusted by one or more 
>users to create and assign public-key certificates."
>
>Section 7 of X.509 states that "[a] CA-certificate is a certificate 
>issued by a CA to a subject that is itself a CA and therefore is 
>capable of issuing public-key certificates."

These definitions address the cert issuing aspect of a CA, but the 
fact that they don't address the revocation responsibilities of a CA 
does not mean that other than a CA issues CRLs. Prior to the 
introduction of CRL DPs and indirect CRLs, there was no way for other 
than a CA to issue a CRL. I have seen no text introduced along with 
v3 certs and v2 CRLs to suggest the existence of a non-CA entity that 
signs CRLs, and that suggests that CRL signing is still the province 
of CAs, not of some other class of as yet unnamed entities.

>The description of basic constraints in X.509 further supports the 
>idea that the cA bit is used to specify certificate issuing, not 
>certificate and/or CRL issuing:
>
>"This field indicates if the subject may act as a CA, with the 
>certified public key being used to verify certificate signatures. … 
>The cA component indicates if the certified public key may be used 
>to verify certificate signatures. … if the value of cA is not set to 
>true then the certified public key shall not be used to verify a 
>certificate signature"
>
>
>pkix-new-part1-05 states something similar:
>
>"The cA bit indicates if the certified public key may be used to 
>verify signatures on other certificates. If the cA bit is asserted, 
>then the keyCertSign bit in the key usage extension (see 4.2.1.3) 
>MUST also be asserted. If the cA bit is not asserted, then the 
>keyCertSign bit in the key usage extension MUST NOT be asserted."

again, this supports the notion that a CA signs certs, but it says 
nothing about whether a CA or some other entity signs CRLs. We have 
uncovered a number of instances where less than perfect wording has 
lead to confusion and our recent dialogue suggests that some of the 
quotes you cite are examples of this.

>The description of the key usage bits are consistent with this as well.
>
>X.509:
>"The bit keyCertSign is for use in CA-certificates only. If KeyUsage 
>is set to keyCertSign and the basic constraints extension is present 
>in the same certificate, the value of the cA component of that 
>extension shall be set to TRUE."
>
>pkix-new-part1-05:
>"The keyCertSign bit is asserted when the subject public key is used 
>for verifying a signature on certificates.  This bit may only be 
>asserted in CA certificates.  If the keyCertSign bit is asserted, 
>then the cA bit in the basic constraints extension (see 4.2.1.10) 
>MUST also be asserted. If the keyCertSign bit is not asserted, then 
>the cA bit in the basic constraints extension MUST NOT be asserted.
>
>The cRLSign bit is asserted when the subject public key is used for 
>verifying a signature on revocation information (e.g., a CRL)."

You have conveniently omitted the various parts of the  2459 and 2459 
bis text that refer to what a CA must do to comply with the RFC when 
it signs CRLs, quotes that have been distributed on this list earlier 
but which do not support your position.

>So, both X.509 and pkix-new-part1-05 go to great lengths to clearly 
>state that only CAs can issue certificates and that basicConstraints 
>with the cA bit set to true must be present in the certificates 
>where the public key is to be used to verify signatures on 
>certificates. There are no similar statements about CRLs. In fact, 
>both documents are quite clear that the cA bit must not be set when 
>the subject public key can not be used to verify certificates. So, 
>if the subject public key can be used to verify CRLs, but not 
>certificates, the cA bit must not be set.

The text was inconsistent in this regard and we are fixing it.

>X.509 is also careful not to preclude the public keys of non-CAs 
>from being used to verify signatures on CRLs. For instance, an end 
>entity is defined as "[a] certificate subject that uses its private 
>key for purposes other than signing certificates or an entity that 
>is a relying party." This leaves room for an end entity to use its 
>private key to sign CRLs.

True, the quoted text does not prohibit an EE from signing a CRL, but 
that is far from supporting the notion that other than CAs do sign 
CRLs. The fact that CRL signing is in no way mentioned here 
undermines the argument I think you are trying to make.

>So, if PKIX wants to require that the cA bit be set whenever the 
>subject public key can be used to verify CRLs and also wants to 
>maintain consistency with X.509, PKIX would have to require that any 
>certificate authorizing the use of a public key for verifying CRL 
>signatures also authorize the use of that public key for verifying 
>certificate signatures. Since we are in agreement that we do not 
>want to impose such a restriction and that we do want to maintain 
>consistency with X.509, we can not require that the cA bit be set 
>when the subject public key can only be used to verify CRL 
>signatures.

Dave, as Sharon pointed out, this is NOT just a PKIX issue; it would 
require changes to X.509 as well.

Like Sharon, I am not opposed to making such changes, if folks want 
to delay 2459 bis for this, and if there is a consensus, but there is 
ample evidence that neither X.509 nor PKIX has ever envisioned EEs 
signing CRLs. You've heard this from both editors in previous 
messages.

Steve


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA27053 for <[e-mail]>; Fri, 20 Apr 2001 10:20:25 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA28374; Fri, 20 Apr 2001 19:20:04 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id TAA16586; Fri, 20 Apr 2001 19:19:51 +0200
Message-ID: <[e-mail]>
Date: Fri, 20 Apr 2001 19:19:55 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: [e-mail]
Subject: Re: cA flag and CRL issuers (was Re: Last Call:  draft-ietf-pkix-new-part1-06.txt comments)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sharon,

> Just to be clear, lets not confuse what I may happen to want as
> an individual contributor to PKIX or any other list, with what
> I state as 509 editor (they're not necessarily always the same :-)

:-)

> My comments were purely from the editor's perspective and yes,
> the current 509 text is quite clear that the CA that issues a
> certificate is responsible for stating whether or not that certificate
> can be revoked, and if so, what mechanism is used to inform
> relying parties. If that mechanism is CRLs, these are issued by
> the certificate issuer or by another authority delegated that
> task by the certificate issuer (that doesn't necessarily mean that
> 509 requires a cert to be issued to that authority, nor that the cert
> contain the basic constraints extension though, that is the job of
> profile groups to determine and incidentally I don't believe they'll
> all adopt the same solution so I would want 509 to remain flexible).
> 
> My own personal view is that industry has moved to a point where there
> probably isn't any real requirement for a CRL issuer to also be a cert
> issuer as long as that CRL issuer is delegated that responsibility
> by the cert issuer and there is a cryptographic way to ensure that
> binding for relying parties. To achieve that, I believe some changes
> are required in 509.

Since I now understand that "CRL" is the generic term to designate any type
of CRL and would like to moderate your statement.

As I have explained yesterday while replying to Russ (I know that you cannot
look at every message), I would make an exception for ARLs. 

By ARLs I mean an Authority Revocation List where the authorities are not
only CAs but more important CRL Issuers and OCSP responders.

In an open architecture where clients do not know where to fetch the
revocation information unless using "out-of-bands" means, if a CA wants to
revoke the authorities in charge of revocation status information (i.e. CRL
Issuers or OCSP responders) they is no other way than using directly the
issuing CA key.

I would like to make sure that the text from "son-of-RFC2459" takes care of
that aspect.

Now, if X509 can also take care of this aspect, this would be nice as well.

:-)

Regards,

Denis
 
> On the separate keys for cert and CRL signing (by the same authority), my
> personal opinion is that anything you read into 509 text on that specific
> topic would be accidental as I don't recall any specific discussion on it.
> 
> However, since that is a real world requirement, I would want to be sure
> that 509 did not prohibit it.
> 
> Hope that clarifies where my comments are coming from :-)
> 
> 
> > -----Original Message-----
> > From: David A. Cooper [mailto:[e-mail]]
> > Sent: Friday, April 20, 2001 11:44 AM
> > To: [e-mail]
> > Subject: RE: cA flag and CRL issuers (was Re: Last Call:
> > draft-ietf-pkix-n ew-part1-06.txt comments)
> >
> >
> > Sharon,
> >
> > Are you suggesting that in order for an entity to issue CRLs
> > on behalf of a certificate issuer, that CRL issuer would need
> > to issue certificates as well (so that it can qualify as an
> > authority)?  I don't think there should be such a
> > requirement, but even if there were it wouldn't settle the issue.
> >
> > Even if only authorities can issue CRLs, there is nothing to
> > prevent that authority from using different keys to sign
> > certificates and CRLs.  X.509 states that "[t]he cA component
> > indicates if the certified public key may be used to verify
> > certificate signatures."  So, the proper value of the cA bit
> > is determined by the allowable uses of the subject public
> > key, not by the type of entity the subject is.  So, even if
> > the certificate subject is a CA, and issues certificates
> > under some key, the cA bit should not be set unless the
> > particular subject public key in the certificate can be used
> > to verify certificate signatures. If an authority is the
> > subject of a certificate and the particular public key of
> > that authority that is being certified is only to be used to
> > verify signatures on CRLs, then the cA bit should not be set.
> >
> > Dave
> >
> > At 10:48 AM 4/20/01 -0400, Sharon Boeyen wrote:
> >
> > >David, sorry but I disagree with your assertions about X.509's
> > >position on this issue. Either by design or by accident,
> > X.509 requires that if CRLs are being issued, they are issued
> > by an 'authority'. Remember that the definition of
> > "authority" is "An entity responsible
> > >
> > >for the issuance of certificates". Much of the text in X.509
> > predates OCSP or the concept of a validation authority, but I
> > do know that the quotes below are new text added within the
> > past couple of years with the intent of clarifying the role
> > of CAs with respect to CRLs.
> > >
> > >Clause 7.3 says:
> > >
> > >"An authority that issues certificates is required to state,
> > possibly through a published statement of their practices,
> > through the certificates themselves, or through some other
> > identified means, whether:
> > >
> > >-       The certificates cannot be revoked; or
> > >-       The certificates may be revoked by the same
> > certificate-issuing authority directly; or
> > >-       The certificate-issuing authority authorizes a
> > different authority to perform revocation."
> > >
> > >further down in the same clause is the text:
> > >
> > >"
> > >An authority that issues and subsequently revokes certificates:
> > >a)      may be required to maintain an audit record of its
> > revocation events for all certificate types issued by that
> > authority (e.g. public-key certificates, attribute
> > certificates issued to end-entities as well as other authorities);
> > >
> > >b)      shall provide revocation status information to
> > relying parties using CRLs, on-line certificate status
> > protocol or some other mechanism for the publication of
> > revocation status information;
> > >
> > >c)      if using CRLs, shall maintain and publish CRLs even
> > if the lists of revoked certificates are empty."
> > >
> > >The quotes that you included in your message tie in with
> > this base text, since the authority that issued the
> > certificates has these responsibilities around revocation,
> > there was no need for X.509 to state anything specific to CRL
> > issuance. In the indirect CRL case, this was envisioned to be
> > another CA or AA, that combined revocation notices from
> > several CAs/AAs.
> > >
> > >Having said that (with my X.509 editor's hat on), if there
> > is a requirement to have entities that are not CAs or AAs be
> > authorized to issue CRLs on behalf of the certificate issuer
> > (because remember that a CRL is an indication that a
> > certificate is no longer considered valid "by its
> > issuer")changes to X.509 would be needed. I'm not necessarily
> > opposed to such changes, I'm just clarifying, in this
> > message, that they would be needed in order for such
> > implementations to be conformant. This, as usual could be
> > done through the enhancements work or could be proposed
> > through the defect process. One way to enable that kind of
> > change might be to redefine authority and to talk about 3
> > types rather than two. However, it would take some careful
> > review to ensure that the set of changes was thorough and complete.
> > >
> > >Sharon
> > >
> > > > -----Original Message-----
> > > > From: David A. Cooper
> > [<mailto:[e-mail]>mailto:[e-mail]]
> > > > Sent: Thursday, April 19, 2001 5:08 PM
> > > > To: [e-mail]
> > > > Subject: cA flag and CRL issuers (was Re: Last Call:
> > > > draft-ietf-pkix-new-part1-06.txt comments)
> > > >
> > > >
> > > > At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:
> > > > >Dave Cooper,
> > > > >
> > > > >>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:
> > > > >>I see no basis in X.509 for setting the cA flag in
> > > > basicConstraints for certificate subjects that can issue CRLs
> > > > but not certificates. The current discussion about how to
> > > > deal with CRLs for attribute certificates vs. public key
> > > > certificates just further goes to show that it was a mistake
> > > > to suddenly change the rules at the last IETF meeting.
> > > > >
> > > > >We disagree on this point. Nowhere in X.509 or in previous
> > > > PKIX documents has there ever been text to suggest that other
> > > > than a CA can sign a CRL for a public key certificate. So,
> > > > the rules were not changed at the last meeting, they were
> > > > reasserted and clarified.
> > > >
> > > > Steve,
> > > >
> > > > You may say that X.509 and PKIX do not suggest that entities
> > > > other than CAs can sign CRLs. However, I think we all agree
> > > > that both X.509 and PKIX allow for a CRL to be signed with a
> > > > different key than the key used to sign the certificates that
> > > > are covered by that CRL. This may be a result of the CA that
> > > > issued the certificates signing the corresponding CRLs with a
> > > > different key or the CA that issued the certificates
> > > > delegating the CRL issuing to another entity (via the
> > > > distribution points extension). There is no requirement that
> > > > the key used to sign the CRL also be used to sign
> > > > certificates. So, I think we agree that there will be times
> > > > where we will be issuing certificates to entities (whether
> > > > those entities are CAs or not) where the intent is to specify
> > > > that the public keys in the certificates may be used to
> > > > verify signatures on CRLs but not on certificates.
> > > >
> > > > The only place we seem to disagree is on the contents of the
> > > > certificates issued in such circumstances. In particular,
> > > > should the certificates contain a basicConstraints extension
> > > > with the cA bit set? On this point, both X.509 and the
> > > > previous PKIX documents are quite clear that the cA bit
> > > > should not be set. Why? Because a CA is defined as an entity
> > > > that issues public-key certificates and both documents
> > > > similarly state that the cA bit is used to specify whether
> > > > the certificate subject can issue certificates. There is no
> > > > similar connection made between being a CA and issuing CRLs.
> > > >
> > > >
> > > > The following are some quotes from X.509 and pkix-new-part1-05:
> > > >
> > > > In X.509 a CA is defined as "[a]n authority trusted by one or
> > > > more users to create and assign public-key certificates."
> > > >
> > > > Section 7 of X.509 states that "[a] CA-certificate is a
> > > > certificate issued by a CA to a subject that is itself a CA
> > > > and therefore is capable of issuing public-key certificates."
> > > >
> > > >
> > > > The description of basic constraints in X.509 further
> > > > supports the idea that the cA bit is used to specify
> > > > certificate issuing, not certificate and/or CRL issuing:
> > > >
> > > > "This field indicates if the subject may act as a CA, with
> > > > the certified public key being used to verify certificate
> > > > signatures. ... The cA component indicates if the certified
> > > > public key may be used to verify certificate signatures. ... if
> > > > the value of cA is not set to true then the certified public
> > > > key shall not be used to verify a certificate signature"
> > > >
> > > >
> > > > pkix-new-part1-05 states something similar:
> > > >
> > > > "The cA bit indicates if the certified public key may be used
> > > > to verify signatures on other certificates. If the cA bit is
> > > > asserted, then the keyCertSign bit in the key usage extension
> > > > (see 4.2.1.3) MUST also be asserted. If the cA bit is not
> > > > asserted, then the keyCertSign bit in the key usage extension
> > > > MUST NOT be asserted."
> > > >
> > > >
> > > > The description of the key usage bits are consistent with
> > > > this as well.
> > > >
> > > > X.509:
> > > > "The bit keyCertSign is for use in CA-certificates only. If
> > > > KeyUsage is set to keyCertSign and the basic constraints
> > > > extension is present in the same certificate, the value of
> > > > the cA component of that extension shall be set to TRUE."
> > > >
> > > > pkix-new-part1-05:
> > > > "The keyCertSign bit is asserted when the subject public key
> > > > is used for verifying a signature on certificates.  This bit
> > > > may only be asserted in CA certificates.  If the keyCertSign
> > > > bit is asserted, then the cA bit in the basic constraints
> > > > extension (see 4.2.1.10) MUST also be asserted. If the
> > > > keyCertSign bit is not asserted, then the cA bit in the basic
> > > > constraints extension MUST NOT be asserted.
> > > >
> > > > The cRLSign bit is asserted when the subject public key is
> > > > used for verifying a signature on revocation information
> > > > (e.g., a CRL)."
> > > >
> > > >
> > > >
> > > > So, both X.509 and pkix-new-part1-05 go to great lengths to
> > > > clearly state that only CAs can issue certificates and that
> > > > basicConstraints with the cA bit set to true must be present
> > > > in the certificates where the public key is to be used to
> > > > verify signatures on certificates. There are no similar
> > > > statements about CRLs. In fact, both documents are quite
> > > > clear that the cA bit must not be set when the subject public
> > > > key can not be used to verify certificates. So, if the
> > > > subject public key can be used to verify CRLs, but not
> > > > certificates, the cA bit must not be set.
> > > >
> > > > X.509 is also careful not to preclude the public keys of
> > > > non-CAs from being used to verify signatures on CRLs. For
> > > > instance, an end entity is defined as "[a] certificate
> > > > subject that uses its private key for purposes other than
> > > > signing certificates or an entity that is a relying party."
> > > > This leaves room for an end entity to use its private key to
> > > > sign CRLs.
> > > >
> > > >
> > > > So, if PKIX wants to require that the cA bit be set whenever
> > > > the subject public key can be used to verify CRLs and also
> > > > wants to maintain consistency with X.509, PKIX would have to
> > > > require that any certificate authorizing the use of a public
> > > > key for verifying CRL signatures also authorize the use of
> > > > that public key for verifying certificate signatures. Since
> > > > we are in agreement that we do not want to impose such a
> > > > restriction and that we do want to maintain consistency with
> > > > X.509, we can not require that the cA bit be set when the
> > > > subject public key can only be used to verify CRL signatures.
> > > >
> > > > Dave
> > > >
> > > >
> >
> >


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA25662 for <[e-mail]>; Fri, 20 Apr 2001 10:03:11 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JJPVS08P>; Fri, 20 Apr 2001 13:02:39 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David A. Cooper'" <[e-mail]>, [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)
Date: Fri, 20 Apr 2001 12:57:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9BA.F27185C0"

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_01C0C9BA.F27185C0
Content-Type: text/plain

Just to be clear, lets not confuse what I may happen to want as 
an individual contributor to PKIX or any other list, with what 
I state as 509 editor (they're not necessarily always the same :-)

My comments were purely from the editor's perspective and yes, 
the current 509 text is quite clear that the CA that issues a 
certificate is responsible for stating whether or not that certificate
can be revoked, and if so, what mechanism is used to inform 
relying parties. If that mechanism is CRLs, these are issued by 
the certificate issuer or by another authority delegated that 
task by the certificate issuer (that doesn't necessarily mean that 
509 requires a cert to be issued to that authority, nor that the cert 
contain the basic constraints extension though, that is the job of 
profile groups to determine and incidentally I don't believe they'll 
all adopt the same solution so I would want 509 to remain flexible). 

My own personal view is that industry has moved to a point where there 
probably isn't any real requirement for a CRL issuer to also be a cert
issuer as long as that CRL issuer is delegated that responsibility 
by the cert issuer and there is a cryptographic way to ensure that 
binding for relying parties. To achieve that, I believe some changes 
are required in 509. 

On the separate keys for cert and CRL signing (by the same authority), my 
personal opinion is that anything you read into 509 text on that specific 
topic would be accidental as I don't recall any specific discussion on it. 
However, since that is a real world requirement, I would want to be sure 
that 509 did not prohibit it.

Hope that clarifies where my comments are coming from :-) 
    

> -----Original Message-----
> From: David A. Cooper [mailto:[e-mail]]
> Sent: Friday, April 20, 2001 11:44 AM
> To: [e-mail]
> Subject: RE: cA flag and CRL issuers (was Re: Last Call:
> draft-ietf-pkix-n ew-part1-06.txt comments)
> 
> 
> Sharon,
> 
> Are you suggesting that in order for an entity to issue CRLs 
> on behalf of a certificate issuer, that CRL issuer would need 
> to issue certificates as well (so that it can qualify as an 
> authority)?  I don't think there should be such a 
> requirement, but even if there were it wouldn't settle the issue.
> 
> Even if only authorities can issue CRLs, there is nothing to 
> prevent that authority from using different keys to sign 
> certificates and CRLs.  X.509 states that "[t]he cA component 
> indicates if the certified public key may be used to verify 
> certificate signatures."  So, the proper value of the cA bit 
> is determined by the allowable uses of the subject public 
> key, not by the type of entity the subject is.  So, even if 
> the certificate subject is a CA, and issues certificates 
> under some key, the cA bit should not be set unless the 
> particular subject public key in the certificate can be used 
> to verify certificate signatures. If an authority is the 
> subject of a certificate and the particular public key of 
> that authority that is being certified is only to be used to 
> verify signatures on CRLs, then the cA bit should not be set.
> 
> Dave
> 
> At 10:48 AM 4/20/01 -0400, Sharon Boeyen wrote:
> 
> >David, sorry but I disagree with your assertions about X.509's 
> >position on this issue. Either by design or by accident, 
> X.509 requires that if CRLs are being issued, they are issued 
> by an 'authority'. Remember that the definition of 
> "authority" is "An entity responsible 
> >
> >for the issuance of certificates". Much of the text in X.509 
> predates OCSP or the concept of a validation authority, but I 
> do know that the quotes below are new text added within the 
> past couple of years with the intent of clarifying the role 
> of CAs with respect to CRLs.
> >
> >Clause 7.3 says:  
> >
> >"An authority that issues certificates is required to state, 
> possibly through a published statement of their practices, 
> through the certificates themselves, or through some other 
> identified means, whether:
> >
> >-       The certificates cannot be revoked; or 
> >-       The certificates may be revoked by the same 
> certificate-issuing authority directly; or 
> >-       The certificate-issuing authority authorizes a 
> different authority to perform revocation." 
> >
> >further down in the same clause is the text: 
> >
> >" 
> >An authority that issues and subsequently revokes certificates: 
> >a)      may be required to maintain an audit record of its 
> revocation events for all certificate types issued by that 
> authority (e.g. public-key certificates, attribute 
> certificates issued to end-entities as well as other authorities);
> >
> >b)      shall provide revocation status information to 
> relying parties using CRLs, on-line certificate status 
> protocol or some other mechanism for the publication of 
> revocation status information;
> >
> >c)      if using CRLs, shall maintain and publish CRLs even 
> if the lists of revoked certificates are empty." 
> >
> >The quotes that you included in your message tie in with 
> this base text, since the authority that issued the 
> certificates has these responsibilities around revocation, 
> there was no need for X.509 to state anything specific to CRL 
> issuance. In the indirect CRL case, this was envisioned to be 
> another CA or AA, that combined revocation notices from 
> several CAs/AAs. 
> >
> >Having said that (with my X.509 editor's hat on), if there 
> is a requirement to have entities that are not CAs or AAs be 
> authorized to issue CRLs on behalf of the certificate issuer 
> (because remember that a CRL is an indication that a 
> certificate is no longer considered valid "by its 
> issuer")changes to X.509 would be needed. I'm not necessarily 
> opposed to such changes, I'm just clarifying, in this 
> message, that they would be needed in order for such 
> implementations to be conformant. This, as usual could be 
> done through the enhancements work or could be proposed 
> through the defect process. One way to enable that kind of 
> change might be to redefine authority and to talk about 3 
> types rather than two. However, it would take some careful 
> review to ensure that the set of changes was thorough and complete.
> >
> >Sharon 
> >
> > > -----Original Message----- 
> > > From: David A. Cooper 
> [<mailto:[e-mail]>mailto:[e-mail]] 
> > > Sent: Thursday, April 19, 2001 5:08 PM 
> > > To: [e-mail] 
> > > Subject: cA flag and CRL issuers (was Re: Last Call: 
> > > draft-ietf-pkix-new-part1-06.txt comments) 
> > > 
> > > 
> > > At 07:17 PM 4/18/01 -0400, Stephen Kent wrote: 
> > > >Dave Cooper, 
> > > > 
> > > >>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote: 
> > > >>I see no basis in X.509 for setting the cA flag in 
> > > basicConstraints for certificate subjects that can issue CRLs 
> > > but not certificates. The current discussion about how to 
> > > deal with CRLs for attribute certificates vs. public key 
> > > certificates just further goes to show that it was a mistake 
> > > to suddenly change the rules at the last IETF meeting. 
> > > > 
> > > >We disagree on this point. Nowhere in X.509 or in previous 
> > > PKIX documents has there ever been text to suggest that other 
> > > than a CA can sign a CRL for a public key certificate. So, 
> > > the rules were not changed at the last meeting, they were 
> > > reasserted and clarified. 
> > > 
> > > Steve, 
> > > 
> > > You may say that X.509 and PKIX do not suggest that entities 
> > > other than CAs can sign CRLs. However, I think we all agree 
> > > that both X.509 and PKIX allow for a CRL to be signed with a 
> > > different key than the key used to sign the certificates that 
> > > are covered by that CRL. This may be a result of the CA that 
> > > issued the certificates signing the corresponding CRLs with a 
> > > different key or the CA that issued the certificates 
> > > delegating the CRL issuing to another entity (via the 
> > > distribution points extension). There is no requirement that 
> > > the key used to sign the CRL also be used to sign 
> > > certificates. So, I think we agree that there will be times 
> > > where we will be issuing certificates to entities (whether 
> > > those entities are CAs or not) where the intent is to specify 
> > > that the public keys in the certificates may be used to 
> > > verify signatures on CRLs but not on certificates. 
> > > 
> > > The only place we seem to disagree is on the contents of the 
> > > certificates issued in such circumstances. In particular, 
> > > should the certificates contain a basicConstraints extension 
> > > with the cA bit set? On this point, both X.509 and the 
> > > previous PKIX documents are quite clear that the cA bit 
> > > should not be set. Why? Because a CA is defined as an entity 
> > > that issues public-key certificates and both documents 
> > > similarly state that the cA bit is used to specify whether 
> > > the certificate subject can issue certificates. There is no 
> > > similar connection made between being a CA and issuing CRLs. 
> > > 
> > > 
> > > The following are some quotes from X.509 and pkix-new-part1-05: 
> > > 
> > > In X.509 a CA is defined as "[a]n authority trusted by one or 
> > > more users to create and assign public-key certificates." 
> > > 
> > > Section 7 of X.509 states that "[a] CA-certificate is a 
> > > certificate issued by a CA to a subject that is itself a CA 
> > > and therefore is capable of issuing public-key certificates." 
> > > 
> > > 
> > > The description of basic constraints in X.509 further 
> > > supports the idea that the cA bit is used to specify 
> > > certificate issuing, not certificate and/or CRL issuing: 
> > > 
> > > "This field indicates if the subject may act as a CA, with 
> > > the certified public key being used to verify certificate 
> > > signatures. ... The cA component indicates if the certified 
> > > public key may be used to verify certificate signatures. ... if 
> > > the value of cA is not set to true then the certified public 
> > > key shall not be used to verify a certificate signature" 
> > > 
> > > 
> > > pkix-new-part1-05 states something similar: 
> > > 
> > > "The cA bit indicates if the certified public key may be used 
> > > to verify signatures on other certificates. If the cA bit is 
> > > asserted, then the keyCertSign bit in the key usage extension 
> > > (see 4.2.1.3) MUST also be asserted. If the cA bit is not 
> > > asserted, then the keyCertSign bit in the key usage extension 
> > > MUST NOT be asserted." 
> > > 
> > > 
> > > The description of the key usage bits are consistent with 
> > > this as well. 
> > > 
> > > X.509: 
> > > "The bit keyCertSign is for use in CA-certificates only. If 
> > > KeyUsage is set to keyCertSign and the basic constraints 
> > > extension is present in the same certificate, the value of 
> > > the cA component of that extension shall be set to TRUE." 
> > > 
> > > pkix-new-part1-05: 
> > > "The keyCertSign bit is asserted when the subject public key 
> > > is used for verifying a signature on certificates.  This bit 
> > > may only be asserted in CA certificates.  If the keyCertSign 
> > > bit is asserted, then the cA bit in the basic constraints 
> > > extension (see 4.2.1.10) MUST also be asserted. If the 
> > > keyCertSign bit is not asserted, then the cA bit in the basic 
> > > constraints extension MUST NOT be asserted. 
> > > 
> > > The cRLSign bit is asserted when the subject public key is 
> > > used for verifying a signature on revocation information 
> > > (e.g., a CRL)." 
> > > 
> > > 
> > > 
> > > So, both X.509 and pkix-new-part1-05 go to great lengths to 
> > > clearly state that only CAs can issue certificates and that 
> > > basicConstraints with the cA bit set to true must be present 
> > > in the certificates where the public key is to be used to 
> > > verify signatures on certificates. There are no similar 
> > > statements about CRLs. In fact, both documents are quite 
> > > clear that the cA bit must not be set when the subject public 
> > > key can not be used to verify certificates. So, if the 
> > > subject public key can be used to verify CRLs, but not 
> > > certificates, the cA bit must not be set. 
> > > 
> > > X.509 is also careful not to preclude the public keys of 
> > > non-CAs from being used to verify signatures on CRLs. For 
> > > instance, an end entity is defined as "[a] certificate 
> > > subject that uses its private key for purposes other than 
> > > signing certificates or an entity that is a relying party." 
> > > This leaves room for an end entity to use its private key to 
> > > sign CRLs. 
> > > 
> > > 
> > > So, if PKIX wants to require that the cA bit be set whenever 
> > > the subject public key can be used to verify CRLs and also 
> > > wants to maintain consistency with X.509, PKIX would have to 
> > > require that any certificate authorizing the use of a public 
> > > key for verifying CRL signatures also authorize the use of 
> > > that public key for verifying certificate signatures. Since 
> > > we are in agreement that we do not want to impose such a 
> > > restriction and that we do want to maintain consistency with 
> > > X.509, we can not require that the cA bit be set when the 
> > > subject public key can only be used to verify CRL signatures. 
> > > 
> > > Dave 
> > > 
> > > 
> 
> 

------_=_NextPart_001_01C0C9BA.F27185C0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Just to be clear, lets not confuse what I may happen to want as </FONT>
<BR><FONT SIZE=2>an individual contributor to PKIX or any other list, with what </FONT>
<BR><FONT SIZE=2>I state as 509 editor (they're not necessarily always the same :-)</FONT>
</P>

<P><FONT SIZE=2>My comments were purely from the editor's perspective and yes, </FONT>
<BR><FONT SIZE=2>the current 509 text is quite clear that the CA that issues a </FONT>
<BR><FONT SIZE=2>certificate is responsible for stating whether or not that certificate</FONT>
<BR><FONT SIZE=2>can be revoked, and if so, what mechanism is used to inform </FONT>
<BR><FONT SIZE=2>relying parties. If that mechanism is CRLs, these are issued by </FONT>
<BR><FONT SIZE=2>the certificate issuer or by another authority delegated that </FONT>
<BR><FONT SIZE=2>task by the certificate issuer (that doesn't necessarily mean that </FONT>
<BR><FONT SIZE=2>509 requires a cert to be issued to that authority, nor that the cert </FONT>
<BR><FONT SIZE=2>contain the basic constraints extension though, that is the job of </FONT>
<BR><FONT SIZE=2>profile groups to determine and incidentally I don't believe they'll </FONT>
<BR><FONT SIZE=2>all adopt the same solution so I would want 509 to remain flexible). </FONT>
</P>

<P><FONT SIZE=2>My own personal view is that industry has moved to a point where there </FONT>
<BR><FONT SIZE=2>probably isn't any real requirement for a CRL issuer to also be a cert</FONT>
<BR><FONT SIZE=2>issuer as long as that CRL issuer is delegated that responsibility </FONT>
<BR><FONT SIZE=2>by the cert issuer and there is a cryptographic way to ensure that </FONT>
<BR><FONT SIZE=2>binding for relying parties. To achieve that, I believe some changes </FONT>
<BR><FONT SIZE=2>are required in 509. </FONT>
</P>

<P><FONT SIZE=2>On the separate keys for cert and CRL signing (by the same authority), my </FONT>
<BR><FONT SIZE=2>personal opinion is that anything you read into 509 text on that specific </FONT>
<BR><FONT SIZE=2>topic would be accidental as I don't recall any specific discussion on it. </FONT>
<BR><FONT SIZE=2>However, since that is a real world requirement, I would want to be sure </FONT>
<BR><FONT SIZE=2>that 509 did not prohibit it.</FONT>
</P>

<P><FONT SIZE=2>Hope that clarifies where my comments are coming from :-) </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; </FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: David A. Cooper [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, April 20, 2001 11:44 AM</FONT>
<BR><FONT SIZE=2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: cA flag and CRL issuers (was Re: Last Call:</FONT>
<BR><FONT SIZE=2>&gt; draft-ietf-pkix-n ew-part1-06.txt comments)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sharon,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Are you suggesting that in order for an entity to issue CRLs </FONT>
<BR><FONT SIZE=2>&gt; on behalf of a certificate issuer, that CRL issuer would need </FONT>
<BR><FONT SIZE=2>&gt; to issue certificates as well (so that it can qualify as an </FONT>
<BR><FONT SIZE=2>&gt; authority)?&nbsp; I don't think there should be such a </FONT>
<BR><FONT SIZE=2>&gt; requirement, but even if there were it wouldn't settle the issue.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Even if only authorities can issue CRLs, there is nothing to </FONT>
<BR><FONT SIZE=2>&gt; prevent that authority from using different keys to sign </FONT>
<BR><FONT SIZE=2>&gt; certificates and CRLs.&nbsp; X.509 states that &quot;[t]he cA component </FONT>
<BR><FONT SIZE=2>&gt; indicates if the certified public key may be used to verify </FONT>
<BR><FONT SIZE=2>&gt; certificate signatures.&quot;&nbsp; So, the proper value of the cA bit </FONT>
<BR><FONT SIZE=2>&gt; is determined by the allowable uses of the subject public </FONT>
<BR><FONT SIZE=2>&gt; key, not by the type of entity the subject is.&nbsp; So, even if </FONT>
<BR><FONT SIZE=2>&gt; the certificate subject is a CA, and issues certificates </FONT>
<BR><FONT SIZE=2>&gt; under some key, the cA bit should not be set unless the </FONT>
<BR><FONT SIZE=2>&gt; particular subject public key in the certificate can be used </FONT>
<BR><FONT SIZE=2>&gt; to verify certificate signatures. If an authority is the </FONT>
<BR><FONT SIZE=2>&gt; subject of a certificate and the particular public key of </FONT>
<BR><FONT SIZE=2>&gt; that authority that is being certified is only to be used to </FONT>
<BR><FONT SIZE=2>&gt; verify signatures on CRLs, then the cA bit should not be set.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dave</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At 10:48 AM 4/20/01 -0400, Sharon Boeyen wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;David, sorry but I disagree with your assertions about X.509's </FONT>
<BR><FONT SIZE=2>&gt; &gt;position on this issue. Either by design or by accident, </FONT>
<BR><FONT SIZE=2>&gt; X.509 requires that if CRLs are being issued, they are issued </FONT>
<BR><FONT SIZE=2>&gt; by an 'authority'. Remember that the definition of </FONT>
<BR><FONT SIZE=2>&gt; &quot;authority&quot; is &quot;An entity responsible </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;for the issuance of certificates&quot;. Much of the text in X.509 </FONT>
<BR><FONT SIZE=2>&gt; predates OCSP or the concept of a validation authority, but I </FONT>
<BR><FONT SIZE=2>&gt; do know that the quotes below are new text added within the </FONT>
<BR><FONT SIZE=2>&gt; past couple of years with the intent of clarifying the role </FONT>
<BR><FONT SIZE=2>&gt; of CAs with respect to CRLs.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Clause 7.3 says:&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&quot;An authority that issues certificates is required to state, </FONT>
<BR><FONT SIZE=2>&gt; possibly through a published statement of their practices, </FONT>
<BR><FONT SIZE=2>&gt; through the certificates themselves, or through some other </FONT>
<BR><FONT SIZE=2>&gt; identified means, whether:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificates cannot be revoked; or </FONT>
<BR><FONT SIZE=2>&gt; &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificates may be revoked by the same </FONT>
<BR><FONT SIZE=2>&gt; certificate-issuing authority directly; or </FONT>
<BR><FONT SIZE=2>&gt; &gt;-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The certificate-issuing authority authorizes a </FONT>
<BR><FONT SIZE=2>&gt; different authority to perform revocation.&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;further down in the same clause is the text: </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt;An authority that issues and subsequently revokes certificates: </FONT>
<BR><FONT SIZE=2>&gt; &gt;a)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may be required to maintain an audit record of its </FONT>
<BR><FONT SIZE=2>&gt; revocation events for all certificate types issued by that </FONT>
<BR><FONT SIZE=2>&gt; authority (e.g. public-key certificates, attribute </FONT>
<BR><FONT SIZE=2>&gt; certificates issued to end-entities as well as other authorities);</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;b)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shall provide revocation status information to </FONT>
<BR><FONT SIZE=2>&gt; relying parties using CRLs, on-line certificate status </FONT>
<BR><FONT SIZE=2>&gt; protocol or some other mechanism for the publication of </FONT>
<BR><FONT SIZE=2>&gt; revocation status information;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;c)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if using CRLs, shall maintain and publish CRLs even </FONT>
<BR><FONT SIZE=2>&gt; if the lists of revoked certificates are empty.&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;The quotes that you included in your message tie in with </FONT>
<BR><FONT SIZE=2>&gt; this base text, since the authority that issued the </FONT>
<BR><FONT SIZE=2>&gt; certificates has these responsibilities around revocation, </FONT>
<BR><FONT SIZE=2>&gt; there was no need for X.509 to state anything specific to CRL </FONT>
<BR><FONT SIZE=2>&gt; issuance. In the indirect CRL case, this was envisioned to be </FONT>
<BR><FONT SIZE=2>&gt; another CA or AA, that combined revocation notices from </FONT>
<BR><FONT SIZE=2>&gt; several CAs/AAs. </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Having said that (with my X.509 editor's hat on), if there </FONT>
<BR><FONT SIZE=2>&gt; is a requirement to have entities that are not CAs or AAs be </FONT>
<BR><FONT SIZE=2>&gt; authorized to issue CRLs on behalf of the certificate issuer </FONT>
<BR><FONT SIZE=2>&gt; (because remember that a CRL is an indication that a </FONT>
<BR><FONT SIZE=2>&gt; certificate is no longer considered valid &quot;by its </FONT>
<BR><FONT SIZE=2>&gt; issuer&quot;)changes to X.509 would be needed. I'm not necessarily </FONT>
<BR><FONT SIZE=2>&gt; opposed to such changes, I'm just clarifying, in this </FONT>
<BR><FONT SIZE=2>&gt; message, that they would be needed in order for such </FONT>
<BR><FONT SIZE=2>&gt; implementations to be conformant. This, as usual could be </FONT>
<BR><FONT SIZE=2>&gt; done through the enhancements work or could be proposed </FONT>
<BR><FONT SIZE=2>&gt; through the defect process. One way to enable that kind of </FONT>
<BR><FONT SIZE=2>&gt; change might be to redefine authority and to talk about 3 </FONT>
<BR><FONT SIZE=2>&gt; types rather than two. However, it would take some careful </FONT>
<BR><FONT SIZE=2>&gt; review to ensure that the set of changes was thorough and complete.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Sharon </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; -----Original Message----- </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; From: David A. Cooper </FONT>
<BR><FONT SIZE=2>&gt; [&lt;<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>&gt;<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>] </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Sent: Thursday, April 19, 2001 5:08 PM </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; To: [e-mail] </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Subject: cA flag and CRL issuers (was Re: Last Call: </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; draft-ietf-pkix-new-part1-06.txt comments) </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; At 07:17 PM 4/18/01 -0400, Stephen Kent wrote: </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;Dave Cooper, </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&gt;At 01:40 PM 4/18/01 -0400, David A. Cooper wrote: </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&gt;I see no basis in X.509 for setting the cA flag in </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; basicConstraints for certificate subjects that can issue CRLs </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; but not certificates. The current discussion about how to </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; deal with CRLs for attribute certificates vs. public key </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; certificates just further goes to show that it was a mistake </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; to suddenly change the rules at the last IETF meeting. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;We disagree on this point. Nowhere in X.509 or in previous </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; PKIX documents has there ever been text to suggest that other </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; than a CA can sign a CRL for a public key certificate. So, </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; the rules were not changed at the last meeting, they were </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; reasserted and clarified. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Steve, </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; You may say that X.509 and PKIX do not suggest that entities </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; other than CAs can sign CRLs. However, I think we all agree </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; that both X.509 and PKIX allow for a CRL to be signed with a </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; different key than the key used to sign the certificates that </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; are covered by that CRL. This may be a result of the CA that </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; issued the certificates signing the corresponding CRLs with a </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; different key or the CA that issued the certificates </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; delegating the CRL issuing to another entity (via the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; distribution points extension). There is no requirement that </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; the key used to sign the CRL also be used to sign </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; certificates. So, I think we agree that there will be times </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; where we will be issuing certificates to entities (whether </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; those entities are CAs or not) where the intent is to specify </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; that the public keys in the certificates may be used to </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; verify signatures on CRLs but not on certificates. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; The only place we seem to disagree is on the contents of the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; certificates issued in such circumstances. In particular, </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; should the certificates contain a basicConstraints extension </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; with the cA bit set? On this point, both X.509 and the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; previous PKIX documents are quite clear that the cA bit </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; should not be set. Why? Because a CA is defined as an entity </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; that issues public-key certificates and both documents </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; similarly state that the cA bit is used to specify whether </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; the certificate subject can issue certificates. There is no </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; similar connection made between being a CA and issuing CRLs. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; The following are some quotes from X.509 and pkix-new-part1-05: </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; In X.509 a CA is defined as &quot;[a]n authority trusted by one or </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; more users to create and assign public-key certificates.&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Section 7 of X.509 states that &quot;[a] CA-certificate is a </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; certificate issued by a CA to a subject that is itself a CA </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; and therefore is capable of issuing public-key certificates.&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; The description of basic constraints in X.509 further </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; supports the idea that the cA bit is used to specify </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; certificate issuing, not certificate and/or CRL issuing: </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &quot;This field indicates if the subject may act as a CA, with </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; the certified public key being used to verify certificate </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; signatures. ... The cA component indicates if the certified </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; public key may be used to verify certificate signatures. ... if </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; the value of cA is not set to true then the certified public </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; key shall not be used to verify a certificate signature&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; pkix-new-part1-05 states something similar: </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &quot;The cA bit indicates if the certified public key may be used </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; to verify signatures on other certificates. If the cA bit is </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; asserted, then the keyCertSign bit in the key usage extension </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; (see 4.2.1.3) MUST also be asserted. If the cA bit is not </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; asserted, then the keyCertSign bit in the key usage extension </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; MUST NOT be asserted.&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; The description of the key usage bits are consistent with </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; this as well. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; X.509: </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &quot;The bit keyCertSign is for use in CA-certificates only. If </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; KeyUsage is set to keyCertSign and the basic constraints </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; extension is present in the same certificate, the value of </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; the cA component of that extension shall be set to TRUE.&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; pkix-new-part1-05: </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &quot;The keyCertSign bit is asserted when the subject public key </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; is used for verifying a signature on certificates.&nbsp; This bit </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; may only be asserted in CA certificates.&nbsp; If the keyCertSign </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; bit is asserted, then the cA bit in the basic constraints </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; extension (see 4.2.1.10) MUST also be asserted. If the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; keyCertSign bit is not asserted, then the cA bit in the basic </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; constraints extension MUST NOT be asserted. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; The cRLSign bit is asserted when the subject public key is </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; used for verifying a signature on revocation information </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; (e.g., a CRL).&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; So, both X.509 and pkix-new-part1-05 go to great lengths to </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; clearly state that only CAs can issue certificates and that </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; basicConstraints with the cA bit set to true must be present </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; in the certificates where the public key is to be used to </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; verify signatures on certificates. There are no similar </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; statements about CRLs. In fact, both documents are quite </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; clear that the cA bit must not be set when the subject public </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; key can not be used to verify certificates. So, if the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; subject public key can be used to verify CRLs, but not </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; certificates, the cA bit must not be set. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; X.509 is also careful not to preclude the public keys of </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; non-CAs from being used to verify signatures on CRLs. For </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; instance, an end entity is defined as &quot;[a] certificate </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; subject that uses its private key for purposes other than </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; signing certificates or an entity that is a relying party.&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; This leaves room for an end entity to use its private key to </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; sign CRLs. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; So, if PKIX wants to require that the cA bit be set whenever </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; the subject public key can be used to verify CRLs and also </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; wants to maintain consistency with X.509, PKIX would have to </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; require that any certificate authorizing the use of a public </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; key for verifying CRL signatures also authorize the use of </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; that public key for verifying certificate signatures. Since </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; we are in agreement that we do not want to impose such a </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; restriction and that we do want to maintain consistency with </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; X.509, we can not require that the cA bit be set when the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; subject public key can only be used to verify CRL signatures. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Dave </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C9BA.F27185C0--


Received: from 164.105.201.155 (cnrf1000.cnrf.nola.navy.mil [164.105.201.155]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA25165 for <[e-mail]>; Fri, 20 Apr 2001 09:56:04 -0700 (PDT)
Received: from CNRFHQ-Message_Server by 164.105.201.155 with Novell_GroupWise; Fri, 20 Apr 2001 11:56:31 -0500
Message-Id: <sae023ef.065@164.105.201.155>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 20 Apr 2001 11:56:00 -0500
From: "Ms Linda Goodwin" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA25167

unsubscribe



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA24458 for <[e-mail]>; Fri, 20 Apr 2001 09:50:35 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA31938; Fri, 20 Apr 2001 18:50:14 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA15768; Fri, 20 Apr 2001 18:50:01 +0200
Message-ID: <[e-mail]>
Date: Fri, 20 Apr 2001 18:50:06 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.txt  comments)
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Denis,
> 
> There seems to be some confusion about the way that delta-CRLs work. I will try to clarify things with my responses in-line below.
> 
> At 05:32 PM 4/19/01 +0200, Denis Pinkas wrote:
> >In the third paragraph the first sentence (still) says:
> >
> >    When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
> 
> I must admit that I am not a big fan of this requirement. From my point of view, there are both advantages and disadvantages to issuing a full CRL whenever a delta-CRL is issued. The advantage is that clients that can not process delta-CRLs can always obtain the same status information as those than can process delta-CRLs. The disadvantage is that it imposes a burden of uploading full CRLs to repositories more often than may be necessary. On the other hand, just because the CA issues the full CRLs, this does not mean that clients must retrieve them.

[Denis] Since you are "not a big fan of this requirement" and no other fan
has been found up to now, let us suppress that sentence.

> In the end, though, it is mostly a policy decision. If you want to provide the same support to clients that can not process delta-CRLs as to those that can, you must issue a full CRL whenever you issue a delta-CRL. I think the decision should be left to CRL issuers, but will not complain if PKIX remains as it is.

> >3) The text says:
> >
> >    An application can construct a CRL that is complete for a given
> >    scope, at the current time, in either of the following ways:
> >
> >       (a) by retrieving the current delta CRL for that scope, and
> >       combining it with an issued CRL that is complete for that scope
> >       and that has a cRLNumber greater than or equal to the cRLNumber of
> >       the base CRL referenced in the delta CRL; or
> >
> >       (b) by retrieving the current delta CRL for that scope and
> >       combining it with a locally constructed CRL whose cRLNumber is
> >       greater than or equal to the cRLNumber of the base CRL referenced
> >       in the current delta CRL.
> >
> >  a) It is hard to understand in which case the base CRL may have a
> >     cRLNumber *greater than* the cRLNumber of the base CRL referenced
> >     in the delta CRL. I certainly miss something here. The equality case
> >     is easy to understand. The "greater than" case is much harder.
> >     Is it really needed ?
> >
> >  b) the case of a locally constructed CRL is quite stange and it is
> >     questionnable why this case is being mentioned. In the following fix,
> >     that case has been deleted.
> 
> If you want a detailed description on this, you could read my paper on delta-CRLs, http://csrc.nist.gov/pki/documents/sliding_window.pdf, but I'll try to briefly explain here.
 
> Suppose that delta-CRLs are issued once an hour. For example, suppose that a base CRL, CRL number 5, was issued at midnight and that every hour for the next 24 hours, delta-CRLs were issued with a BaseCRLNumber of 5. If a relying party performs its first validation at 3:10am, it would the full CRL issued at midnight and the delta-CRL issued at 3:00am (CRL number 8). It would combine these to construct full CRL number 8. In this case, the CRL number of the full CRL used in combination with the delta-CRL would be the same as the BaseCRLNumber in that delta-CRL.

[Denis] This is the case I had in mind. However I would disagree to say that
the locally contructed CRL is equal to the full CRL number 8, because there
is no need to issue such CRL (see the first comment). It is simply the
"freshest CRL constructed from the base CRL number 5 for 3:10 am". This
locally contructed CRL bears no number, or if you assign one, this is a
local matter and is not part of the standard. This also avoids the later
confusing between CRL numbers.

> A few hours later, at 6:30am, the relying party performs another validation. The relying party has, in its local cache, the contents of CRL number 8 (which it constructed at 3:10am). It wants to update the information in its local case to based on the newly available revocation information. So, it obtains the latest delta-CRL. This delta-CRL has a CRL number of 11 and a BaseCRLnumber of 5. Since it has a BaseCRLNumber of 5, the delta-CRL provides status information for all certificates whose status has changed since CRL number 5 was issued. (midnight). So, clearly the delta-CRL provides status information for all certificates whose status has changed since 3:00am when CRL number 8 was issued. Thus, the relying party can combine the delta-CRL with its locally cached version of full CRL number 8 to obtain the contents of CRL number 11. This is a case where the CRL number of the complete CRL used is greater than the BaseCRLNumber specified in the delta-CRL.

[Denis] This is a local matter and I would not mandate this in the document
since there is another and simpler way to do it: you keep in the cache the
base CRL (instead of the previously recontructed full CRL). This has the
same end result, except that the method your recommend is not optimum: it
will include many duplicates and deleting the duplicates is more painfull
than making a simple addition.

The basic algorithm is to take the base CRL and to add the delta. This is
the standard. As soon as you get the same end result this is fine. This is
the approach we have taken for path validation. Other ways do not need to be
mentionned.

> There are other reasons why the two numbers may not match, but I will not go into them. If you are interested, you can read my paper.

[Denis] I read it (and skipped the mathematical formulas)

This paper is proposing a method for over-issuing the CRLs. It omits to take
into consideration that in PKIX-1 we mandate the CRL number extension
(section 5.2.3) so we need to advertise the nextUpdate. If you issue a CRL
before the next update you have no more way to know which base CRL is the
freshest CRL. I believe this is a major security weakness and for that
reason this mechanism should be deprecated.

BTW, the same security problem would occur as soon as a base would be used
for every delta. Hence another good reason to delete the sentence which
originally triggered all this discussion.

BTW, I noticed that you have precisely deleted from my previous e-mail all
the text dealing with this nextUpdate. :-( 

So I am still insisting on the major text change to make to that section:

   An application can construct a CRL that is the most current for 
   a given scope, at the current time, by retrieving the current 
   base CRL for that scope, and combining it with a delta-CRL which 
   contains a Delta CRL Indicator equal to the cRLNumber of the base 
   CRL and where the current date from that delta-CRL is between 
   thisUpdate and nextUpdate;

It is important to notice that the algorithm does NOT use the individual CRL
numbers assigned to the delta-CRLs, but uses instead thisUpdate and
nextUpdate. This is *very* important.


> >Finally we should explain what happens at the boundaries, i.e. when a CA
> >decides to generate a (new) base CRL. Here is a text proposal:
> >
> >   When issuing a base CRL that supports a delta-CRL mechanism then the
> >   CRL Issuer MUST at the same time issue a delta CRL that points to that
> >   base CRL. This first delta CRL will usually be empty (or will include
> >   last-minute additions to the base CRL).
> 
> This is not acceptable. The rule is that when a base CRL is issued a delta-CRL must be issued that has the same cRLNumber. The base CRL referenced by the delta must either be the previously issued base CRL or a base CRL issued before that one. Since the new base and the delta must have the same cRLNumber, there can be no differences as a result of "last-minute additions to the base CRL".

[Denis] This does not work. Let me explain it differently. Suppose that
during the week you do not generate delta-CRLs but for the week-end you
decide to do it (e.g. more risk, more transactions done by citizens). So you
issue a CRL with the freshest CRLindicator. You say that the delta points to
the previous base CRL. The one from yesterday or the one from last week ? 
In either case this simply does not work.

The rule you mention, i.e. "The rule is that when a base CRL is issued a
delta-CRL must be issued that has the same cRLNumber" is also wrong. The
notion of a base CRL that would have the same number as a delta does not
exist.

> >Suppose we issue a base CRL every midnight. The question is whether we
> >should issue a delta and, if yes, does this delta refer to the previous
> >base or to the new one ?
> 
> The delta must refer either to the previous base or a base issued before the previous base.

[Denis] Certainly not. Your paper however provides the right answer
(on page 1): " A delta-CRL is a CRL that only provides information about
certificates who statuses have changed since the issuance of a specific,
previously issued CRL".

> >Suppose it refers to the previous one. According to the current sentence:
> >"The constructed CRL has the CRL number specified in the CRL number
> >extension found in the delta CRL used in its construction.", it is
> >impossible. If that was the case the delta CRL would have a CRL number equal
> >to the base CRL and it is not allowed for two CRLs to have the same CRL
> >number.
 
> I think you are confusing two different extensions. The deltaCRLIndicator extension contains a BaseCRLNumber which is used to determine against which base CRLs the delta-CRL can be applied. The cRLNumber extension specifies the CRL number of the full CRL that will be generated by applying the delta-CRL to a base CRL. The sentence above states that the CRL number of the constructed CRL is taken from the cRLNumber extension, not the BaseCRLNumber of the deltaCRLIndicator extension.

[Denis] I do not think I make a confusion. The confusion comes from the
numbering you introduce (see my earlier comment).

Let me conclude:

1) I do not have the time to spend hours of discussions on that topic.
However the current text needs to be corrected and I have provided text
for this. Please take again a look at it in the light of the following.

2) In your paper you advertise the "traditional delta-CRLs". Let us stay in
the tradition and let us mandate the implementation of the "tradition" if
someone wans to support the delta-CRL mechanism.

Any other method would first need to be proven to be secure (over-issuing
CRLs and sliding window delta-CRLs have security problems) and should
*anyway* fall in the MAY category, so that noone needs to implement to claim
conformance with the delta CRL mechanism. Standard track documents need to
make choices among multiple methods, otherwise two different implementations
will never interoperate.

Regards,

Denis


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA18581 for <[e-mail]>; Fri, 20 Apr 2001 08:44:13 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id LAA18794 for <[e-mail]>; Fri, 20 Apr 2001 11:44:13 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 20 Apr 2001 11:43:53 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Sharon,

Are you suggesting that in order for an entity to issue CRLs on behalf of a certificate issuer, that CRL issuer would need to issue certificates as well (so that it can qualify as an authority)?  I don't think there should be such a requirement, but even if there were it wouldn't settle the issue.

Even if only authorities can issue CRLs, there is nothing to prevent that authority from using different keys to sign certificates and CRLs.  X.509 states that "[t]he cA component indicates if the certified public key may be used to verify certificate signatures."  So, the proper value of the cA bit is determined by the allowable uses of the subject public key, not by the type of entity the subject is.  So, even if the certificate subject is a CA, and issues certificates under some key, the cA bit should not be set unless the particular subject public key in the certificate can be used to verify certificate signatures. If an authority is the subject of a certificate and the particular public key of that authority that is being certified is only to be used to verify signatures on CRLs, then the cA bit should not be set.

Dave

At 10:48 AM 4/20/01 -0400, Sharon Boeyen wrote:

>David, sorry but I disagree with your assertions about X.509's 
>position on this issue. Either by design or by accident, X.509 requires that if CRLs are being issued, they are issued by an 'authority'. Remember that the definition of "authority" is "An entity responsible 
>
>for the issuance of certificates". Much of the text in X.509 predates OCSP or the concept of a validation authority, but I do know that the quotes below are new text added within the past couple of years with the intent of clarifying the role of CAs with respect to CRLs.
>
>Clause 7.3 says:  
>
>"An authority that issues certificates is required to state, possibly through a published statement of their practices, through the certificates themselves, or through some other identified means, whether:
>
>-       The certificates cannot be revoked; or 
>-       The certificates may be revoked by the same certificate-issuing authority directly; or 
>-       The certificate-issuing authority authorizes a different authority to perform revocation." 
>
>further down in the same clause is the text: 
>
>" 
>An authority that issues and subsequently revokes certificates: 
>a)      may be required to maintain an audit record of its revocation events for all certificate types issued by that authority (e.g. public-key certificates, attribute certificates issued to end-entities as well as other authorities);
>
>b)      shall provide revocation status information to relying parties using CRLs, on-line certificate status protocol or some other mechanism for the publication of revocation status information;
>
>c)      if using CRLs, shall maintain and publish CRLs even if the lists of revoked certificates are empty." 
>
>The quotes that you included in your message tie in with this base text, since the authority that issued the certificates has these responsibilities around revocation, there was no need for X.509 to state anything specific to CRL issuance. In the indirect CRL case, this was envisioned to be another CA or AA, that combined revocation notices from several CAs/AAs. 
>
>Having said that (with my X.509 editor's hat on), if there is a requirement to have entities that are not CAs or AAs be authorized to issue CRLs on behalf of the certificate issuer (because remember that a CRL is an indication that a certificate is no longer considered valid "by its issuer")changes to X.509 would be needed. I'm not necessarily opposed to such changes, I'm just clarifying, in this message, that they would be needed in order for such implementations to be conformant. This, as usual could be done through the enhancements work or could be proposed through the defect process. One way to enable that kind of change might be to redefine authority and to talk about 3 types rather than two. However, it would take some careful review to ensure that the set of changes was thorough and complete.
>
>Sharon 
>
> > -----Original Message----- 
> > From: David A. Cooper [<mailto:[e-mail]>mailto:[e-mail]] 
> > Sent: Thursday, April 19, 2001 5:08 PM 
> > To: [e-mail] 
> > Subject: cA flag and CRL issuers (was Re: Last Call: 
> > draft-ietf-pkix-new-part1-06.txt comments) 
> > 
> > 
> > At 07:17 PM 4/18/01 -0400, Stephen Kent wrote: 
> > >Dave Cooper, 
> > > 
> > >>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote: 
> > >>I see no basis in X.509 for setting the cA flag in 
> > basicConstraints for certificate subjects that can issue CRLs 
> > but not certificates. The current discussion about how to 
> > deal with CRLs for attribute certificates vs. public key 
> > certificates just further goes to show that it was a mistake 
> > to suddenly change the rules at the last IETF meeting. 
> > > 
> > >We disagree on this point. Nowhere in X.509 or in previous 
> > PKIX documents has there ever been text to suggest that other 
> > than a CA can sign a CRL for a public key certificate. So, 
> > the rules were not changed at the last meeting, they were 
> > reasserted and clarified. 
> > 
> > Steve, 
> > 
> > You may say that X.509 and PKIX do not suggest that entities 
> > other than CAs can sign CRLs. However, I think we all agree 
> > that both X.509 and PKIX allow for a CRL to be signed with a 
> > different key than the key used to sign the certificates that 
> > are covered by that CRL. This may be a result of the CA that 
> > issued the certificates signing the corresponding CRLs with a 
> > different key or the CA that issued the certificates 
> > delegating the CRL issuing to another entity (via the 
> > distribution points extension). There is no requirement that 
> > the key used to sign the CRL also be used to sign 
> > certificates. So, I think we agree that there will be times 
> > where we will be issuing certificates to entities (whether 
> > those entities are CAs or not) where the intent is to specify 
> > that the public keys in the certificates may be used to 
> > verify signatures on CRLs but not on certificates. 
> > 
> > The only place we seem to disagree is on the contents of the 
> > certificates issued in such circumstances. In particular, 
> > should the certificates contain a basicConstraints extension 
> > with the cA bit set? On this point, both X.509 and the 
> > previous PKIX documents are quite clear that the cA bit 
> > should not be set. Why? Because a CA is defined as an entity 
> > that issues public-key certificates and both documents 
> > similarly state that the cA bit is used to specify whether 
> > the certificate subject can issue certificates. There is no 
> > similar connection made between being a CA and issuing CRLs. 
> > 
> > 
> > The following are some quotes from X.509 and pkix-new-part1-05: 
> > 
> > In X.509 a CA is defined as "[a]n authority trusted by one or 
> > more users to create and assign public-key certificates." 
> > 
> > Section 7 of X.509 states that "[a] CA-certificate is a 
> > certificate issued by a CA to a subject that is itself a CA 
> > and therefore is capable of issuing public-key certificates." 
> > 
> > 
> > The description of basic constraints in X.509 further 
> > supports the idea that the cA bit is used to specify 
> > certificate issuing, not certificate and/or CRL issuing: 
> > 
> > "This field indicates if the subject may act as a CA, with 
> > the certified public key being used to verify certificate 
> > signatures. ... The cA component indicates if the certified 
> > public key may be used to verify certificate signatures. ... if 
> > the value of cA is not set to true then the certified public 
> > key shall not be used to verify a certificate signature" 
> > 
> > 
> > pkix-new-part1-05 states something similar: 
> > 
> > "The cA bit indicates if the certified public key may be used 
> > to verify signatures on other certificates. If the cA bit is 
> > asserted, then the keyCertSign bit in the key usage extension 
> > (see 4.2.1.3) MUST also be asserted. If the cA bit is not 
> > asserted, then the keyCertSign bit in the key usage extension 
> > MUST NOT be asserted." 
> > 
> > 
> > The description of the key usage bits are consistent with 
> > this as well. 
> > 
> > X.509: 
> > "The bit keyCertSign is for use in CA-certificates only. If 
> > KeyUsage is set to keyCertSign and the basic constraints 
> > extension is present in the same certificate, the value of 
> > the cA component of that extension shall be set to TRUE." 
> > 
> > pkix-new-part1-05: 
> > "The keyCertSign bit is asserted when the subject public key 
> > is used for verifying a signature on certificates.  This bit 
> > may only be asserted in CA certificates.  If the keyCertSign 
> > bit is asserted, then the cA bit in the basic constraints 
> > extension (see 4.2.1.10) MUST also be asserted. If the 
> > keyCertSign bit is not asserted, then the cA bit in the basic 
> > constraints extension MUST NOT be asserted. 
> > 
> > The cRLSign bit is asserted when the subject public key is 
> > used for verifying a signature on revocation information 
> > (e.g., a CRL)." 
> > 
> > 
> > 
> > So, both X.509 and pkix-new-part1-05 go to great lengths to 
> > clearly state that only CAs can issue certificates and that 
> > basicConstraints with the cA bit set to true must be present 
> > in the certificates where the public key is to be used to 
> > verify signatures on certificates. There are no similar 
> > statements about CRLs. In fact, both documents are quite 
> > clear that the cA bit must not be set when the subject public 
> > key can not be used to verify certificates. So, if the 
> > subject public key can be used to verify CRLs, but not 
> > certificates, the cA bit must not be set. 
> > 
> > X.509 is also careful not to preclude the public keys of 
> > non-CAs from being used to verify signatures on CRLs. For 
> > instance, an end entity is defined as "[a] certificate 
> > subject that uses its private key for purposes other than 
> > signing certificates or an entity that is a relying party." 
> > This leaves room for an end entity to use its private key to 
> > sign CRLs. 
> > 
> > 
> > So, if PKIX wants to require that the cA bit be set whenever 
> > the subject public key can be used to verify CRLs and also 
> > wants to maintain consistency with X.509, PKIX would have to 
> > require that any certificate authorizing the use of a public 
> > key for verifying CRL signatures also authorize the use of 
> > that public key for verifying certificate signatures. Since 
> > we are in agreement that we do not want to impose such a 
> > restriction and that we do want to maintain consistency with 
> > X.509, we can not require that the cA bit be set when the 
> > subject public key can only be used to verify CRL signatures. 
> > 
> > Dave 
> > 
> > 




Received: from blue01.identrus.com ([216.213.93.123]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA16253 for <[e-mail]>; Fri, 20 Apr 2001 08:34:54 -0700 (PDT)
Received: by BLUE01 with Internet Mail Service (5.5.2653.19) id <G6T1Y2WK>; Fri, 20 Apr 2001 11:32:56 -0400
Message-ID: <2B55DABB95C4D4119C1300508BD953F114429A@BLUE01>
From: Dave Oshman <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "David A. Cooper" <[e-mail]>, [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)
Date: Fri, 20 Apr 2001 11:32:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9AF.25ABA6C0"

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_01C0C9AF.25ABA6C0
Content-Type: text/plain;
	charset="iso-8859-1"

I am also in agreement with this.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, April 19, 2001 5:10 PM
To: David A. Cooper; [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n
ew-part1-06.txt comments)



I agree with David.  It should acceptable to have a cRLSign bit on and
basicConstraints absent. 

-----Original Message----- 
From: David A. Cooper [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Thursday, April 19, 2001 5:08 PM 
To: [e-mail] 
Subject: cA flag and CRL issuers (was Re: Last Call: 
draft-ietf-pkix-new-part1-06.txt comments) 


At 07:17 PM 4/18/01 -0400, Stephen Kent wrote: 
>Dave Cooper, 
> 
>>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote: 
>>I see no basis in X.509 for setting the cA flag in basicConstraints for
certificate subjects that can issue CRLs but not certificates. The current
discussion about how to deal with CRLs for attribute certificates vs. public
key certificates just further goes to show that it was a mistake to suddenly
change the rules at the last IETF meeting.

> 
>We disagree on this point. Nowhere in X.509 or in previous PKIX documents
has there ever been text to suggest that other than a CA can sign a CRL for
a public key certificate. So, the rules were not changed at the last
meeting, they were reasserted and clarified.

Steve, 

You may say that X.509 and PKIX do not suggest that entities other than CAs
can sign CRLs. However, I think we all agree that both X.509 and PKIX allow
for a CRL to be signed with a different key than the key used to sign the
certificates that are covered by that CRL. This may be a result of the CA
that issued the certificates signing the corresponding CRLs with a different
key or the CA that issued the certificates delegating the CRL issuing to
another entity (via the distribution points extension). There is no
requirement that the key used to sign the CRL also be used to sign
certificates. So, I think we agree that there will be times where we will be
issuing certificates to entities (whether those entities are CAs or not)
where the intent is to specify that the public keys in the certificates may
be used to verify signatures on CRLs but not on certificates.

The only place we seem to disagree is on the contents of the certificates
issued in such circumstances. In particular, should the certificates contain
a basicConstraints extension with the cA bit set? On this point, both X.509
and the previous PKIX documents are quite clear that the cA bit should not
be set. Why? Because a CA is defined as an entity that issues public-key
certificates and both documents similarly state that the cA bit is used to
specify whether the certificate subject can issue certificates. There is no
similar connection made between being a CA and issuing CRLs.


The following are some quotes from X.509 and pkix-new-part1-05: 

In X.509 a CA is defined as "[a]n authority trusted by one or more users to
create and assign public-key certificates." 

Section 7 of X.509 states that "[a] CA-certificate is a certificate issued
by a CA to a subject that is itself a CA and therefore is capable of issuing
public-key certificates."


The description of basic constraints in X.509 further supports the idea that
the cA bit is used to specify certificate issuing, not certificate and/or
CRL issuing:

"This field indicates if the subject may act as a CA, with the certified
public key being used to verify certificate signatures. ... The cA component
indicates if the certified public key may be used to verify certificate
signatures. ... if the value of cA is not set to true then the certified
public key shall not be used to verify a certificate signature"


pkix-new-part1-05 states something similar: 

"The cA bit indicates if the certified public key may be used to verify
signatures on other certificates. If the cA bit is asserted, then the
keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also be
asserted. If the cA bit is not asserted, then the keyCertSign bit in the key
usage extension MUST NOT be asserted."


The description of the key usage bits are consistent with this as well. 

X.509: 
"The bit keyCertSign is for use in CA-certificates only. If KeyUsage is set
to keyCertSign and the basic constraints extension is present in the same
certificate, the value of the cA component of that extension shall be set to
TRUE."

pkix-new-part1-05: 
"The keyCertSign bit is asserted when the subject public key is used for
verifying a signature on certificates.  This bit may only be asserted in CA
certificates.  If the keyCertSign bit is asserted, then the cA bit in the
basic constraints extension (see 4.2.1.10) MUST also be asserted. If the
keyCertSign bit is not asserted, then the cA bit in the basic constraints
extension MUST NOT be asserted.

The cRLSign bit is asserted when the subject public key is used for
verifying a signature on revocation information (e.g., a CRL)."



So, both X.509 and pkix-new-part1-05 go to great lengths to clearly state
that only CAs can issue certificates and that basicConstraints with the cA
bit set to true must be present in the certificates where the public key is
to be used to verify signatures on certificates. There are no similar
statements about CRLs. In fact, both documents are quite clear that the cA
bit must not be set when the subject public key can not be used to verify
certificates. So, if the subject public key can be used to verify CRLs, but
not certificates, the cA bit must not be set.

X.509 is also careful not to preclude the public keys of non-CAs from being
used to verify signatures on CRLs. For instance, an end entity is defined as
"[a] certificate subject that uses its private key for purposes other than
signing certificates or an entity that is a relying party." This leaves room
for an end entity to use its private key to sign CRLs.


So, if PKIX wants to require that the cA bit be set whenever the subject
public key can be used to verify CRLs and also wants to maintain consistency
with X.509, PKIX would have to require that any certificate authorizing the
use of a public key for verifying CRL signatures also authorize the use of
that public key for verifying certificate signatures. Since we are in
agreement that we do not want to impose such a restriction and that we do
want to maintain consistency with X.509, we can not require that the cA bit
be set when the subject public key can only be used to verify CRL
signatures.

Dave 


------_=_NextPart_001_01C0C9AF.25ABA6C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)</TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=380253115-20042001><FONT face=Arial color=#0000ff size=2>I am 
also in agreement with this.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 19, 2001 5:10 
  PM<BR><B>To:</B> David A. Cooper; [e-mail]<BR><B>Subject:</B> RE: cA 
  flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt 
  comments)<BR><BR></FONT></DIV>
  <P><FONT size=2>I agree with David.&nbsp; It should acceptable to have a 
  cRLSign bit on and basicConstraints absent.</FONT> </P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: David 
  A. Cooper [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>Sent: Thursday, April 19, 2001 5:08 PM</FONT> <BR><FONT 
  size=2>To: [e-mail]</FONT> <BR><FONT size=2>Subject: cA flag and CRL 
  issuers (was Re: Last Call:</FONT> <BR><FONT 
  size=2>draft-ietf-pkix-new-part1-06.txt comments)</FONT> </P><BR>
  <P><FONT size=2>At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:</FONT> 
  <BR><FONT size=2>&gt;Dave Cooper,</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt;&gt;At 01:40 PM 4/18/01 -0400, David A. Cooper 
  wrote:</FONT> <BR><FONT size=2>&gt;&gt;I see no basis in X.509 for setting the 
  cA flag in basicConstraints for certificate subjects that can issue CRLs but 
  not certificates. The current discussion about how to deal with CRLs for 
  attribute certificates vs. public key certificates just further goes to show 
  that it was a mistake to suddenly change the rules at the last IETF 
  meeting.</FONT></P>
  <P><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;We disagree on this point. 
  Nowhere in X.509 or in previous PKIX documents has there ever been text to 
  suggest that other than a CA can sign a CRL for a public key certificate. So, 
  the rules were not changed at the last meeting, they were reasserted and 
  clarified.</FONT></P>
  <P><FONT size=2>Steve,</FONT> </P>
  <P><FONT size=2>You may say that X.509 and PKIX do not suggest that entities 
  other than CAs can sign CRLs. However, I think we all agree that both X.509 
  and PKIX allow for a CRL to be signed with a different key than the key used 
  to sign the certificates that are covered by that CRL. This may be a result of 
  the CA that issued the certificates signing the corresponding CRLs with a 
  different key or the CA that issued the certificates delegating the CRL 
  issuing to another entity (via the distribution points extension). There is no 
  requirement that the key used to sign the CRL also be used to sign 
  certificates. So, I think we agree that there will be times where we will be 
  issuing certificates to entities (whether those entities are CAs or not) where 
  the intent is to specify that the public keys in the certificates may be used 
  to verify signatures on CRLs but not on certificates.</FONT></P>
  <P><FONT size=2>The only place we seem to disagree is on the contents of the 
  certificates issued in such circumstances. In particular, should the 
  certificates contain a basicConstraints extension with the cA bit set? On this 
  point, both X.509 and the previous PKIX documents are quite clear that the cA 
  bit should not be set. Why? Because a CA is defined as an entity that issues 
  public-key certificates and both documents similarly state that the cA bit is 
  used to specify whether the certificate subject can issue certificates. There 
  is no similar connection made between being a CA and issuing 
  CRLs.</FONT></P><BR>
  <P><FONT size=2>The following are some quotes from X.509 and 
  pkix-new-part1-05:</FONT> </P>
  <P><FONT size=2>In X.509 a CA is defined as "[a]n authority trusted by one or 
  more users to create and assign public-key certificates."</FONT> </P>
  <P><FONT size=2>Section 7 of X.509 states that "[a] CA-certificate is a 
  certificate issued by a CA to a subject that is itself a CA and therefore is 
  capable of issuing public-key certificates."</FONT></P><BR>
  <P><FONT size=2>The description of basic constraints in X.509 further supports 
  the idea that the cA bit is used to specify certificate issuing, not 
  certificate and/or CRL issuing:</FONT></P>
  <P><FONT size=2>"This field indicates if the subject may act as a CA, with the 
  certified public key being used to verify certificate signatures. ... The cA 
  component indicates if the certified public key may be used to verify 
  certificate signatures. ... if the value of cA is not set to true then the 
  certified public key shall not be used to verify a certificate 
  signature"</FONT></P><BR>
  <P><FONT size=2>pkix-new-part1-05 states something similar:</FONT> </P>
  <P><FONT size=2>"The cA bit indicates if the certified public key may be used 
  to verify signatures on other certificates. If the cA bit is asserted, then 
  the keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also be 
  asserted. If the cA bit is not asserted, then the keyCertSign bit in the key 
  usage extension MUST NOT be asserted."</FONT></P><BR>
  <P><FONT size=2>The description of the key usage bits are consistent with this 
  as well.</FONT> </P>
  <P><FONT size=2>X.509:</FONT> <BR><FONT size=2>"The bit keyCertSign is for use 
  in CA-certificates only. If KeyUsage is set to keyCertSign and the basic 
  constraints extension is present in the same certificate, the value of the cA 
  component of that extension shall be set to TRUE."</FONT></P>
  <P><FONT size=2>pkix-new-part1-05:</FONT> <BR><FONT size=2>"The keyCertSign 
  bit is asserted when the subject public key is used for verifying a signature 
  on certificates.&nbsp; This bit may only be asserted in CA certificates.&nbsp; 
  If the keyCertSign bit is asserted, then the cA bit in the basic constraints 
  extension (see 4.2.1.10) MUST also be asserted. If the keyCertSign bit is not 
  asserted, then the cA bit in the basic constraints extension MUST NOT be 
  asserted.</FONT></P>
  <P><FONT size=2>The cRLSign bit is asserted when the subject public key is 
  used for verifying a signature on revocation information (e.g., a 
  CRL)."</FONT></P><BR><BR>
  <P><FONT size=2>So, both X.509 and pkix-new-part1-05 go to great lengths to 
  clearly state that only CAs can issue certificates and that basicConstraints 
  with the cA bit set to true must be present in the certificates where the 
  public key is to be used to verify signatures on certificates. There are no 
  similar statements about CRLs. In fact, both documents are quite clear that 
  the cA bit must not be set when the subject public key can not be used to 
  verify certificates. So, if the subject public key can be used to verify CRLs, 
  but not certificates, the cA bit must not be set.</FONT></P>
  <P><FONT size=2>X.509 is also careful not to preclude the public keys of 
  non-CAs from being used to verify signatures on CRLs. For instance, an end 
  entity is defined as "[a] certificate subject that uses its private key for 
  purposes other than signing certificates or an entity that is a relying 
  party." This leaves room for an end entity to use its private key to sign 
  CRLs.</FONT></P><BR>
  <P><FONT size=2>So, if PKIX wants to require that the cA bit be set whenever 
  the subject public key can be used to verify CRLs and also wants to maintain 
  consistency with X.509, PKIX would have to require that any certificate 
  authorizing the use of a public key for verifying CRL signatures also 
  authorize the use of that public key for verifying certificate signatures. 
  Since we are in agreement that we do not want to impose such a restriction and 
  that we do want to maintain consistency with X.509, we can not require that 
  the cA bit be set when the subject public key can only be used to verify CRL 
  signatures.</FONT></P>
  <P><FONT size=2>Dave</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0C9AF.25ABA6C0--


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA11094 for <[e-mail]>; Fri, 20 Apr 2001 07:54:34 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <2VH1A3WX>; Fri, 20 Apr 2001 10:54:02 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David A. Cooper'" <[e-mail]>, [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)
Date: Fri, 20 Apr 2001 10:48:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9A8.FBACABE0"

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_01C0C9A8.FBACABE0
Content-Type: text/plain;
	charset="iso-8859-1"

David, sorry but I disagree with your assertions about X.509's 
position on this issue. Either by design or by accident, X.509 requires that
if CRLs are being issued, they are issued by an 'authority'. Remember that
the definition of "authority" is "An entity responsible 
for the issuance of certificates". Much of the text in X.509 predates OCSP
or the concept of a validation authority, but I do know that the quotes
below are new text added within the past couple of years with the intent of
clarifying the role of CAs with respect to CRLs.

Clause 7.3 says:  

"An authority that issues certificates is required to state, possibly
through a published statement of their practices, through the certificates
themselves, or through some other identified means, whether:
-	The certificates cannot be revoked; or
-	The certificates may be revoked by the same certificate-issuing
authority directly; or
-	The certificate-issuing authority authorizes a different authority
to perform revocation."

further down in the same clause is the text:

"
An authority that issues and subsequently revokes certificates:
a) 	may be required to maintain an audit record of its revocation events
for all certificate types issued by that authority (e.g. public-key
certificates, attribute certificates issued to end-entities as well as other
authorities);
b)  	shall provide revocation status information to relying parties using
CRLs, on-line certificate status protocol or some other mechanism for the
publication of revocation status information;
c)	if using CRLs, shall maintain and publish CRLs even if the lists of
revoked certificates are empty."

The quotes that you included in your message tie in with this base text,
since the authority that issued the certificates has these responsibilities
around revocation, there was no need for X.509 to state anything specific to
CRL issuance. In the indirect CRL case, this was envisioned to be another CA
or AA, that combined revocation notices from several CAs/AAs. 

Having said that (with my X.509 editor's hat on), if there is a requirement
to have entities that are not CAs or AAs be authorized to issue CRLs on
behalf of the certificate issuer (because remember that a CRL is an
indication that a certificate is no longer considered valid "by its
issuer")changes to X.509 would be needed. I'm not necessarily opposed to
such changes, I'm just clarifying, in this message, that they would be
needed in order for such implementations to be conformant. This, as usual
could be done through the enhancements work or could be proposed through the
defect process. One way to enable that kind of change might be to redefine
authority and to talk about 3 types rather than two. However, it would take
some careful review to ensure that the set of changes was thorough and
complete.

Sharon

> -----Original Message-----
> From: David A. Cooper [mailto:[e-mail]]
> Sent: Thursday, April 19, 2001 5:08 PM
> To: [e-mail]
> Subject: cA flag and CRL issuers (was Re: Last Call:
> draft-ietf-pkix-new-part1-06.txt comments)
> 
> 
> At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:
> >Dave Cooper,
> >
> >>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:
> >>I see no basis in X.509 for setting the cA flag in 
> basicConstraints for certificate subjects that can issue CRLs 
> but not certificates. The current discussion about how to 
> deal with CRLs for attribute certificates vs. public key 
> certificates just further goes to show that it was a mistake 
> to suddenly change the rules at the last IETF meeting.
> >
> >We disagree on this point. Nowhere in X.509 or in previous 
> PKIX documents has there ever been text to suggest that other 
> than a CA can sign a CRL for a public key certificate. So, 
> the rules were not changed at the last meeting, they were 
> reasserted and clarified.
> 
> Steve,
> 
> You may say that X.509 and PKIX do not suggest that entities 
> other than CAs can sign CRLs. However, I think we all agree 
> that both X.509 and PKIX allow for a CRL to be signed with a 
> different key than the key used to sign the certificates that 
> are covered by that CRL. This may be a result of the CA that 
> issued the certificates signing the corresponding CRLs with a 
> different key or the CA that issued the certificates 
> delegating the CRL issuing to another entity (via the 
> distribution points extension). There is no requirement that 
> the key used to sign the CRL also be used to sign 
> certificates. So, I think we agree that there will be times 
> where we will be issuing certificates to entities (whether 
> those entities are CAs or not) where the intent is to specify 
> that the public keys in the certificates may be used to 
> verify signatures on CRLs but not on certificates.
> 
> The only place we seem to disagree is on the contents of the 
> certificates issued in such circumstances. In particular, 
> should the certificates contain a basicConstraints extension 
> with the cA bit set? On this point, both X.509 and the 
> previous PKIX documents are quite clear that the cA bit 
> should not be set. Why? Because a CA is defined as an entity 
> that issues public-key certificates and both documents 
> similarly state that the cA bit is used to specify whether 
> the certificate subject can issue certificates. There is no 
> similar connection made between being a CA and issuing CRLs.
> 
> 
> The following are some quotes from X.509 and pkix-new-part1-05:
> 
> In X.509 a CA is defined as "[a]n authority trusted by one or 
> more users to create and assign public-key certificates."
> 
> Section 7 of X.509 states that "[a] CA-certificate is a 
> certificate issued by a CA to a subject that is itself a CA 
> and therefore is capable of issuing public-key certificates."
> 
> 
> The description of basic constraints in X.509 further 
> supports the idea that the cA bit is used to specify 
> certificate issuing, not certificate and/or CRL issuing:
> 
> "This field indicates if the subject may act as a CA, with 
> the certified public key being used to verify certificate 
> signatures. ... The cA component indicates if the certified 
> public key may be used to verify certificate signatures. ... if 
> the value of cA is not set to true then the certified public 
> key shall not be used to verify a certificate signature"
> 
> 
> pkix-new-part1-05 states something similar:
> 
> "The cA bit indicates if the certified public key may be used 
> to verify signatures on other certificates. If the cA bit is 
> asserted, then the keyCertSign bit in the key usage extension 
> (see 4.2.1.3) MUST also be asserted. If the cA bit is not 
> asserted, then the keyCertSign bit in the key usage extension 
> MUST NOT be asserted."
> 
> 
> The description of the key usage bits are consistent with 
> this as well.
> 
> X.509:
> "The bit keyCertSign is for use in CA-certificates only. If 
> KeyUsage is set to keyCertSign and the basic constraints 
> extension is present in the same certificate, the value of 
> the cA component of that extension shall be set to TRUE."
> 
> pkix-new-part1-05:
> "The keyCertSign bit is asserted when the subject public key 
> is used for verifying a signature on certificates.  This bit 
> may only be asserted in CA certificates.  If the keyCertSign 
> bit is asserted, then the cA bit in the basic constraints 
> extension (see 4.2.1.10) MUST also be asserted. If the 
> keyCertSign bit is not asserted, then the cA bit in the basic 
> constraints extension MUST NOT be asserted.
> 
> The cRLSign bit is asserted when the subject public key is 
> used for verifying a signature on revocation information 
> (e.g., a CRL)."
> 
> 
> 
> So, both X.509 and pkix-new-part1-05 go to great lengths to 
> clearly state that only CAs can issue certificates and that 
> basicConstraints with the cA bit set to true must be present 
> in the certificates where the public key is to be used to 
> verify signatures on certificates. There are no similar 
> statements about CRLs. In fact, both documents are quite 
> clear that the cA bit must not be set when the subject public 
> key can not be used to verify certificates. So, if the 
> subject public key can be used to verify CRLs, but not 
> certificates, the cA bit must not be set.
> 
> X.509 is also careful not to preclude the public keys of 
> non-CAs from being used to verify signatures on CRLs. For 
> instance, an end entity is defined as "[a] certificate 
> subject that uses its private key for purposes other than 
> signing certificates or an entity that is a relying party." 
> This leaves room for an end entity to use its private key to 
> sign CRLs.
> 
> 
> So, if PKIX wants to require that the cA bit be set whenever 
> the subject public key can be used to verify CRLs and also 
> wants to maintain consistency with X.509, PKIX would have to 
> require that any certificate authorizing the use of a public 
> key for verifying CRL signatures also authorize the use of 
> that public key for verifying certificate signatures. Since 
> we are in agreement that we do not want to impose such a 
> restriction and that we do want to maintain consistency with 
> X.509, we can not require that the cA bit be set when the 
> subject public key can only be used to verify CRL signatures.
> 
> Dave
> 
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: cA flag and CRL issuers (was Re: Last Call: =
draft-ietf-pkix-new-part1-06.txt comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>David, sorry but I disagree with your assertions =
about X.509's </FONT>
<BR><FONT SIZE=3D2>position on this issue. Either by design or by =
accident, X.509 requires that if CRLs are being issued, they are issued =
by an 'authority'. Remember that the definition of =
&quot;authority&quot; is &quot;An entity responsible </FONT></P>

<P><FONT SIZE=3D2>for the issuance of certificates&quot;. Much of the =
text in X.509 predates OCSP or the concept of a validation authority, =
but I do know that the quotes below are new text added within the past =
couple of years with the intent of clarifying the role of CAs with =
respect to CRLs.</FONT></P>

<P><FONT SIZE=3D2>Clause 7.3 says:&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>&quot;An authority that issues certificates is =
required to state, possibly through a published statement of their =
practices, through the certificates themselves, or through some other =
identified means, whether:</FONT></P>

<P><FONT SIZE=3D2>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
certificates cannot be revoked; or</FONT>
<BR><FONT SIZE=3D2>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
certificates may be revoked by the same certificate-issuing authority =
directly; or</FONT>
<BR><FONT SIZE=3D2>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
certificate-issuing authority authorizes a different authority to =
perform revocation.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>further down in the same clause is the text:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;</FONT>
<BR><FONT SIZE=3D2>An authority that issues and subsequently revokes =
certificates:</FONT>
<BR><FONT SIZE=3D2>a) &nbsp;&nbsp;&nbsp;&nbsp; may be required to =
maintain an audit record of its revocation events for all certificate =
types issued by that authority (e.g. public-key certificates, attribute =
certificates issued to end-entities as well as other =
authorities);</FONT></P>

<P><FONT SIZE=3D2>b)&nbsp; &nbsp;&nbsp;&nbsp; shall provide revocation =
status information to relying parties using CRLs, on-line certificate =
status protocol or some other mechanism for the publication of =
revocation status information;</FONT></P>

<P><FONT SIZE=3D2>c)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if using CRLs, shall =
maintain and publish CRLs even if the lists of revoked certificates are =
empty.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>The quotes that you included in your message tie in =
with this base text, since the authority that issued the certificates =
has these responsibilities around revocation, there was no need for =
X.509 to state anything specific to CRL issuance. In the indirect CRL =
case, this was envisioned to be another CA or AA, that combined =
revocation notices from several CAs/AAs. </FONT></P>

<P><FONT SIZE=3D2>Having said that (with my X.509 editor's hat on), if =
there is a requirement to have entities that are not CAs or AAs be =
authorized to issue CRLs on behalf of the certificate issuer (because =
remember that a CRL is an indication that a certificate is no longer =
considered valid &quot;by its issuer&quot;)changes to X.509 would be =
needed. I'm not necessarily opposed to such changes, I'm just =
clarifying, in this message, that they would be needed in order for =
such implementations to be conformant. This, as usual could be done =
through the enhancements work or could be proposed through the defect =
process. One way to enable that kind of change might be to redefine =
authority and to talk about 3 types rather than two. However, it would =
take some careful review to ensure that the set of changes was thorough =
and complete.</FONT></P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David A. Cooper [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, April 19, 2001 5:08 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: cA flag and CRL issuers (was Re: Last =
Call:</FONT>
<BR><FONT SIZE=3D2>&gt; draft-ietf-pkix-new-part1-06.txt =
comments)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 07:17 PM 4/18/01 -0400, Stephen Kent =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Dave Cooper,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;At 01:40 PM 4/18/01 -0400, David A. =
Cooper wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;I see no basis in X.509 for setting the =
cA flag in </FONT>
<BR><FONT SIZE=3D2>&gt; basicConstraints for certificate subjects that =
can issue CRLs </FONT>
<BR><FONT SIZE=3D2>&gt; but not certificates. The current discussion =
about how to </FONT>
<BR><FONT SIZE=3D2>&gt; deal with CRLs for attribute certificates vs. =
public key </FONT>
<BR><FONT SIZE=3D2>&gt; certificates just further goes to show that it =
was a mistake </FONT>
<BR><FONT SIZE=3D2>&gt; to suddenly change the rules at the last IETF =
meeting.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;We disagree on this point. Nowhere in X.509 =
or in previous </FONT>
<BR><FONT SIZE=3D2>&gt; PKIX documents has there ever been text to =
suggest that other </FONT>
<BR><FONT SIZE=3D2>&gt; than a CA can sign a CRL for a public key =
certificate. So, </FONT>
<BR><FONT SIZE=3D2>&gt; the rules were not changed at the last meeting, =
they were </FONT>
<BR><FONT SIZE=3D2>&gt; reasserted and clarified.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Steve,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You may say that X.509 and PKIX do not suggest =
that entities </FONT>
<BR><FONT SIZE=3D2>&gt; other than CAs can sign CRLs. However, I think =
we all agree </FONT>
<BR><FONT SIZE=3D2>&gt; that both X.509 and PKIX allow for a CRL to be =
signed with a </FONT>
<BR><FONT SIZE=3D2>&gt; different key than the key used to sign the =
certificates that </FONT>
<BR><FONT SIZE=3D2>&gt; are covered by that CRL. This may be a result =
of the CA that </FONT>
<BR><FONT SIZE=3D2>&gt; issued the certificates signing the =
corresponding CRLs with a </FONT>
<BR><FONT SIZE=3D2>&gt; different key or the CA that issued the =
certificates </FONT>
<BR><FONT SIZE=3D2>&gt; delegating the CRL issuing to another entity =
(via the </FONT>
<BR><FONT SIZE=3D2>&gt; distribution points extension). There is no =
requirement that </FONT>
<BR><FONT SIZE=3D2>&gt; the key used to sign the CRL also be used to =
sign </FONT>
<BR><FONT SIZE=3D2>&gt; certificates. So, I think we agree that there =
will be times </FONT>
<BR><FONT SIZE=3D2>&gt; where we will be issuing certificates to =
entities (whether </FONT>
<BR><FONT SIZE=3D2>&gt; those entities are CAs or not) where the intent =
is to specify </FONT>
<BR><FONT SIZE=3D2>&gt; that the public keys in the certificates may be =
used to </FONT>
<BR><FONT SIZE=3D2>&gt; verify signatures on CRLs but not on =
certificates.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The only place we seem to disagree is on the =
contents of the </FONT>
<BR><FONT SIZE=3D2>&gt; certificates issued in such circumstances. In =
particular, </FONT>
<BR><FONT SIZE=3D2>&gt; should the certificates contain a =
basicConstraints extension </FONT>
<BR><FONT SIZE=3D2>&gt; with the cA bit set? On this point, both X.509 =
and the </FONT>
<BR><FONT SIZE=3D2>&gt; previous PKIX documents are quite clear that =
the cA bit </FONT>
<BR><FONT SIZE=3D2>&gt; should not be set. Why? Because a CA is defined =
as an entity </FONT>
<BR><FONT SIZE=3D2>&gt; that issues public-key certificates and both =
documents </FONT>
<BR><FONT SIZE=3D2>&gt; similarly state that the cA bit is used to =
specify whether </FONT>
<BR><FONT SIZE=3D2>&gt; the certificate subject can issue certificates. =
There is no </FONT>
<BR><FONT SIZE=3D2>&gt; similar connection made between being a CA and =
issuing CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The following are some quotes from X.509 and =
pkix-new-part1-05:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In X.509 a CA is defined as &quot;[a]n =
authority trusted by one or </FONT>
<BR><FONT SIZE=3D2>&gt; more users to create and assign public-key =
certificates.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Section 7 of X.509 states that &quot;[a] =
CA-certificate is a </FONT>
<BR><FONT SIZE=3D2>&gt; certificate issued by a CA to a subject that is =
itself a CA </FONT>
<BR><FONT SIZE=3D2>&gt; and therefore is capable of issuing public-key =
certificates.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The description of basic constraints in X.509 =
further </FONT>
<BR><FONT SIZE=3D2>&gt; supports the idea that the cA bit is used to =
specify </FONT>
<BR><FONT SIZE=3D2>&gt; certificate issuing, not certificate and/or CRL =
issuing:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;This field indicates if the subject may =
act as a CA, with </FONT>
<BR><FONT SIZE=3D2>&gt; the certified public key being used to verify =
certificate </FONT>
<BR><FONT SIZE=3D2>&gt; signatures. ... The cA component indicates if =
the certified </FONT>
<BR><FONT SIZE=3D2>&gt; public key may be used to verify certificate =
signatures. ... if </FONT>
<BR><FONT SIZE=3D2>&gt; the value of cA is not set to true then the =
certified public </FONT>
<BR><FONT SIZE=3D2>&gt; key shall not be used to verify a certificate =
signature&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; pkix-new-part1-05 states something =
similar:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;The cA bit indicates if the certified =
public key may be used </FONT>
<BR><FONT SIZE=3D2>&gt; to verify signatures on other certificates. If =
the cA bit is </FONT>
<BR><FONT SIZE=3D2>&gt; asserted, then the keyCertSign bit in the key =
usage extension </FONT>
<BR><FONT SIZE=3D2>&gt; (see 4.2.1.3) MUST also be asserted. If the cA =
bit is not </FONT>
<BR><FONT SIZE=3D2>&gt; asserted, then the keyCertSign bit in the key =
usage extension </FONT>
<BR><FONT SIZE=3D2>&gt; MUST NOT be asserted.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The description of the key usage bits are =
consistent with </FONT>
<BR><FONT SIZE=3D2>&gt; this as well.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; X.509:</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;The bit keyCertSign is for use in =
CA-certificates only. If </FONT>
<BR><FONT SIZE=3D2>&gt; KeyUsage is set to keyCertSign and the basic =
constraints </FONT>
<BR><FONT SIZE=3D2>&gt; extension is present in the same certificate, =
the value of </FONT>
<BR><FONT SIZE=3D2>&gt; the cA component of that extension shall be set =
to TRUE.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; pkix-new-part1-05:</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;The keyCertSign bit is asserted when the =
subject public key </FONT>
<BR><FONT SIZE=3D2>&gt; is used for verifying a signature on =
certificates.&nbsp; This bit </FONT>
<BR><FONT SIZE=3D2>&gt; may only be asserted in CA certificates.&nbsp; =
If the keyCertSign </FONT>
<BR><FONT SIZE=3D2>&gt; bit is asserted, then the cA bit in the basic =
constraints </FONT>
<BR><FONT SIZE=3D2>&gt; extension (see 4.2.1.10) MUST also be asserted. =
If the </FONT>
<BR><FONT SIZE=3D2>&gt; keyCertSign bit is not asserted, then the cA =
bit in the basic </FONT>
<BR><FONT SIZE=3D2>&gt; constraints extension MUST NOT be =
asserted.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The cRLSign bit is asserted when the subject =
public key is </FONT>
<BR><FONT SIZE=3D2>&gt; used for verifying a signature on revocation =
information </FONT>
<BR><FONT SIZE=3D2>&gt; (e.g., a CRL).&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, both X.509 and pkix-new-part1-05 go to =
great lengths to </FONT>
<BR><FONT SIZE=3D2>&gt; clearly state that only CAs can issue =
certificates and that </FONT>
<BR><FONT SIZE=3D2>&gt; basicConstraints with the cA bit set to true =
must be present </FONT>
<BR><FONT SIZE=3D2>&gt; in the certificates where the public key is to =
be used to </FONT>
<BR><FONT SIZE=3D2>&gt; verify signatures on certificates. There are no =
similar </FONT>
<BR><FONT SIZE=3D2>&gt; statements about CRLs. In fact, both documents =
are quite </FONT>
<BR><FONT SIZE=3D2>&gt; clear that the cA bit must not be set when the =
subject public </FONT>
<BR><FONT SIZE=3D2>&gt; key can not be used to verify certificates. So, =
if the </FONT>
<BR><FONT SIZE=3D2>&gt; subject public key can be used to verify CRLs, =
but not </FONT>
<BR><FONT SIZE=3D2>&gt; certificates, the cA bit must not be =
set.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; X.509 is also careful not to preclude the =
public keys of </FONT>
<BR><FONT SIZE=3D2>&gt; non-CAs from being used to verify signatures on =
CRLs. For </FONT>
<BR><FONT SIZE=3D2>&gt; instance, an end entity is defined as &quot;[a] =
certificate </FONT>
<BR><FONT SIZE=3D2>&gt; subject that uses its private key for purposes =
other than </FONT>
<BR><FONT SIZE=3D2>&gt; signing certificates or an entity that is a =
relying party.&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; This leaves room for an end entity to use its =
private key to </FONT>
<BR><FONT SIZE=3D2>&gt; sign CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, if PKIX wants to require that the cA bit be =
set whenever </FONT>
<BR><FONT SIZE=3D2>&gt; the subject public key can be used to verify =
CRLs and also </FONT>
<BR><FONT SIZE=3D2>&gt; wants to maintain consistency with X.509, PKIX =
would have to </FONT>
<BR><FONT SIZE=3D2>&gt; require that any certificate authorizing the =
use of a public </FONT>
<BR><FONT SIZE=3D2>&gt; key for verifying CRL signatures also authorize =
the use of </FONT>
<BR><FONT SIZE=3D2>&gt; that public key for verifying certificate =
signatures. Since </FONT>
<BR><FONT SIZE=3D2>&gt; we are in agreement that we do not want to =
impose such a </FONT>
<BR><FONT SIZE=3D2>&gt; restriction and that we do want to maintain =
consistency with </FONT>
<BR><FONT SIZE=3D2>&gt; X.509, we can not require that the cA bit be =
set when the </FONT>
<BR><FONT SIZE=3D2>&gt; subject public key can only be used to verify =
CRL signatures.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C9A8.FBACABE0--


Received: from protactinium (protactinium.btinternet.com [194.73.73.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA07550 for <[e-mail]>; Fri, 20 Apr 2001 06:42:32 -0700 (PDT)
Received: from [213.122.10.72] (helo=vaio) by protactinium with smtp (Exim 3.03 #83) id 14qbB5-00037r-00; Fri, 20 Apr 2001 14:42:28 +0100
Message-ID: <002501c0c9a0$48cfc460$851efea9@vaio>
Reply-To: "Liaquat Khan" <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: <[e-mail]>, "David A. Cooper" <[e-mail]>
References: <[e-mail]> <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: cA flag and CRL issuers (was Re: Last Call:  draft-ietf-pkix-new-part1-06.txt comments)
Date: Fri, 20 Apr 2001 14:46:20 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C0C9A8.A976D580"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

This is a multi-part message in MIME format.

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

Yes, I agree with this too.

The actual value of the cA flag over and above what is already provided =
through the keyCertSign and cRLSign seems limited. =20

Liaquat =20
  ----- Original Message -----=20
  From: David A. Cooper=20
  To: [e-mail]=20
  Sent: Thursday, April 19, 2001 10:08 PM
  Subject: cA flag and CRL issuers (was Re: Last Call: =
draft-ietf-pkix-new-part1-06.txt comments)


  At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:
  >Dave Cooper,
  >
  >>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:
  >>I see no basis in X.509 for setting the cA flag in basicConstraints =
for certificate subjects that can issue CRLs but not certificates. The =
current discussion about how to deal with CRLs for attribute =
certificates vs. public key certificates just further goes to show that =
it was a mistake to suddenly change the rules at the last IETF meeting.
  >
  >We disagree on this point. Nowhere in X.509 or in previous PKIX =
documents has there ever been text to suggest that other than a CA can =
sign a CRL for a public key certificate. So, the rules were not changed =
at the last meeting, they were reasserted and clarified.

  Steve,

  You may say that X.509 and PKIX do not suggest that entities other =
than CAs can sign CRLs. However, I think we all agree that both X.509 =
and PKIX allow for a CRL to be signed with a different key than the key =
used to sign the certificates that are covered by that CRL. This may be =
a result of the CA that issued the certificates signing the =
corresponding CRLs with a different key or the CA that issued the =
certificates delegating the CRL issuing to another entity (via the =
distribution points extension). There is no requirement that the key =
used to sign the CRL also be used to sign certificates. So, I think we =
agree that there will be times where we will be issuing certificates to =
entities (whether those entities are CAs or not) where the intent is to =
specify that the public keys in the certificates may be used to verify =
signatures on CRLs but not on certificates.

  The only place we seem to disagree is on the contents of the =
certificates issued in such circumstances. In particular, should the =
certificates contain a basicConstraints extension with the cA bit set? =
On this point, both X.509 and the previous PKIX documents are quite =
clear that the cA bit should not be set. Why? Because a CA is defined as =
an entity that issues public-key certificates and both documents =
similarly state that the cA bit is used to specify whether the =
certificate subject can issue certificates. There is no similar =
connection made between being a CA and issuing CRLs.


  The following are some quotes from X.509 and pkix-new-part1-05:

  In X.509 a CA is defined as "[a]n authority trusted by one or more =
users to create and assign public-key certificates."

  Section 7 of X.509 states that "[a] CA-certificate is a certificate =
issued by a CA to a subject that is itself a CA and therefore is capable =
of issuing public-key certificates."


  The description of basic constraints in X.509 further supports the =
idea that the cA bit is used to specify certificate issuing, not =
certificate and/or CRL issuing:

  "This field indicates if the subject may act as a CA, with the =
certified public key being used to verify certificate signatures. . The =
cA component indicates if the certified public key may be used to verify =
certificate signatures. . if the value of cA is not set to true then the =
certified public key shall not be used to verify a certificate =
signature"


  pkix-new-part1-05 states something similar:

  "The cA bit indicates if the certified public key may be used to =
verify signatures on other certificates. If the cA bit is asserted, then =
the keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also =
be asserted. If the cA bit is not asserted, then the keyCertSign bit in =
the key usage extension MUST NOT be asserted."


  The description of the key usage bits are consistent with this as =
well.

  X.509:
  "The bit keyCertSign is for use in CA-certificates only. If KeyUsage =
is set to keyCertSign and the basic constraints extension is present in =
the same certificate, the value of the cA component of that extension =
shall be set to TRUE."

  pkix-new-part1-05:
  "The keyCertSign bit is asserted when the subject public key is used =
for verifying a signature on certificates.  This bit may only be =
asserted in CA certificates.  If the keyCertSign bit is asserted, then =
the cA bit in the basic constraints extension (see 4.2.1.10) MUST also =
be asserted. If the keyCertSign bit is not asserted, then the cA bit in =
the basic constraints extension MUST NOT be asserted.

  The cRLSign bit is asserted when the subject public key is used for =
verifying a signature on revocation information (e.g., a CRL)."



  So, both X.509 and pkix-new-part1-05 go to great lengths to clearly =
state that only CAs can issue certificates and that basicConstraints =
with the cA bit set to true must be present in the certificates where =
the public key is to be used to verify signatures on certificates. There =
are no similar statements about CRLs. In fact, both documents are quite =
clear that the cA bit must not be set when the subject public key can =
not be used to verify certificates. So, if the subject public key can be =
used to verify CRLs, but not certificates, the cA bit must not be set.

  X.509 is also careful not to preclude the public keys of non-CAs from =
being used to verify signatures on CRLs. For instance, an end entity is =
defined as "[a] certificate subject that uses its private key for =
purposes other than signing certificates or an entity that is a relying =
party." This leaves room for an end entity to use its private key to =
sign CRLs.


  So, if PKIX wants to require that the cA bit be set whenever the =
subject public key can be used to verify CRLs and also wants to maintain =
consistency with X.509, PKIX would have to require that any certificate =
authorizing the use of a public key for verifying CRL signatures also =
authorize the use of that public key for verifying certificate =
signatures. Since we are in agreement that we do not want to impose such =
a restriction and that we do want to maintain consistency with X.509, we =
can not require that the cA bit be set when the subject public key can =
only be used to verify CRL signatures.

  Dave




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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Yes, I agree with this =
too.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The actual value of the cA flag over =
and above what=20
is already provided through the <FONT face=3D"Times New Roman" =
size=3D3>keyCertSign=20
<FONT face=3DArial size=3D2>and cRLSign </FONT></FONT>seems =
limited.&nbsp;=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Liaquat&nbsp;&nbsp;</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">David A.=20
  Cooper</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, April 19, 2001 =
10:08=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> cA flag and CRL =
issuers (was Re:=20
  Last Call: draft-ietf-pkix-new-part1-06.txt comments)</DIV>
  <DIV><BR></DIV>At 07:17 PM 4/18/01 -0400, Stephen Kent =
wrote:<BR>&gt;Dave=20
  Cooper,<BR>&gt;<BR>&gt;&gt;At 01:40 PM 4/18/01 -0400, David A. Cooper=20
  wrote:<BR>&gt;&gt;I see no basis in X.509 for setting the cA flag in=20
  basicConstraints for certificate subjects that can issue CRLs but not=20
  certificates. The current discussion about how to deal with CRLs for =
attribute=20
  certificates vs. public key certificates just further goes to show =
that it was=20
  a mistake to suddenly change the rules at the last IETF=20
  meeting.<BR>&gt;<BR>&gt;We disagree on this point. Nowhere in X.509 or =
in=20
  previous PKIX documents has there ever been text to suggest that other =
than a=20
  CA can sign a CRL for a public key certificate. So, the rules were not =
changed=20
  at the last meeting, they were reasserted and=20
  clarified.<BR><BR>Steve,<BR><BR>You may say that X.509 and PKIX do not =
suggest=20
  that entities other than CAs can sign CRLs. However, I think we all =
agree that=20
  both X.509 and PKIX allow for a CRL to be signed with a different key =
than the=20
  key used to sign the certificates that are covered by that CRL. This =
may be a=20
  result of the CA that issued the certificates signing the =
corresponding CRLs=20
  with a different key or the CA that issued the certificates delegating =
the CRL=20
  issuing to another entity (via the distribution points extension). =
There is no=20
  requirement that the key used to sign the CRL also be used to sign=20
  certificates. So, I think we agree that there will be times where we =
will be=20
  issuing certificates to entities (whether those entities are CAs or =
not) where=20
  the intent is to specify that the public keys in the certificates may =
be used=20
  to verify signatures on CRLs but not on certificates.<BR><BR>The only =
place we=20
  seem to disagree is on the contents of the certificates issued in such =

  circumstances. In particular, should the certificates contain a=20
  basicConstraints extension with the cA bit set? On this point, both =
X.509 and=20
  the previous PKIX documents are quite clear that the cA bit should not =
be set.=20
  Why? Because a CA is defined as an entity that issues public-key =
certificates=20
  and both documents similarly state that the cA bit is used to specify =
whether=20
  the certificate subject can issue certificates. There is no similar =
connection=20
  made between being a CA and issuing CRLs.<BR><BR><BR>The following are =
some=20
  quotes from X.509 and pkix-new-part1-05:<BR><BR>In X.509 a CA is =
defined as=20
  "[a]n authority trusted by one or more users to create and assign =
public-key=20
  certificates."<BR><BR>Section 7 of X.509 states that "[a] =
CA-certificate is a=20
  certificate issued by a CA to a subject that is itself a CA and =
therefore is=20
  capable of issuing public-key certificates."<BR><BR><BR>The =
description of=20
  basic constraints in X.509 further supports the idea that the cA bit =
is used=20
  to specify certificate issuing, not certificate and/or CRL=20
  issuing:<BR><BR>"This field indicates if the subject may act as a CA, =
with the=20
  certified public key being used to verify certificate signatures. . =
The cA=20
  component indicates if the certified public key may be used to verify=20
  certificate signatures. . if the value of cA is not set to true then =
the=20
  certified public key shall not be used to verify a certificate=20
  signature"<BR><BR><BR>pkix-new-part1-05 states something =
similar:<BR><BR>"The=20
  cA bit indicates if the certified public key may be used to verify =
signatures=20
  on other certificates. If the cA bit is asserted, then the keyCertSign =
bit in=20
  the key usage extension (see 4.2.1.3) MUST also be asserted. If the cA =
bit is=20
  not asserted, then the keyCertSign bit in the key usage extension MUST =
NOT be=20
  asserted."<BR><BR><BR>The description of the key usage bits are =
consistent=20
  with this as well.<BR><BR>X.509:<BR>"The bit keyCertSign is for use in =

  CA-certificates only. If KeyUsage is set to keyCertSign and the basic=20
  constraints extension is present in the same certificate, the value of =
the cA=20
  component of that extension shall be set to=20
  TRUE."<BR><BR>pkix-new-part1-05:<BR>"The keyCertSign bit is asserted =
when the=20
  subject public key is used for verifying a signature on =
certificates.&nbsp;=20
  This bit may only be asserted in CA certificates.&nbsp; If the =
keyCertSign bit=20
  is asserted, then the cA bit in the basic constraints extension (see =
4.2.1.10)=20
  MUST also be asserted. If the keyCertSign bit is not asserted, then =
the cA bit=20
  in the basic constraints extension MUST NOT be asserted.<BR><BR>The =
cRLSign=20
  bit is asserted when the subject public key is used for verifying a =
signature=20
  on revocation information (e.g., a CRL)."<BR><BR><BR><BR>So, both =
X.509 and=20
  pkix-new-part1-05 go to great lengths to clearly state that only CAs =
can issue=20
  certificates and that basicConstraints with the cA bit set to true =
must be=20
  present in the certificates where the public key is to be used to =
verify=20
  signatures on certificates. There are no similar statements about =
CRLs. In=20
  fact, both documents are quite clear that the cA bit must not be set =
when the=20
  subject public key can not be used to verify certificates. So, if the =
subject=20
  public key can be used to verify CRLs, but not certificates, the cA =
bit must=20
  not be set.<BR><BR>X.509 is also careful not to preclude the public =
keys of=20
  non-CAs from being used to verify signatures on CRLs. For instance, an =
end=20
  entity is defined as "[a] certificate subject that uses its private =
key for=20
  purposes other than signing certificates or an entity that is a =
relying=20
  party." This leaves room for an end entity to use its private key to =
sign=20
  CRLs.<BR><BR><BR>So, if PKIX wants to require that the cA bit be set =
whenever=20
  the subject public key can be used to verify CRLs and also wants to =
maintain=20
  consistency with X.509, PKIX would have to require that any =
certificate=20
  authorizing the use of a public key for verifying CRL signatures also=20
  authorize the use of that public key for verifying certificate =
signatures.=20
  Since we are in agreement that we do not want to impose such a =
restriction and=20
  that we do want to maintain consistency with X.509, we can not require =
that=20
  the cA bit be set when the subject public key can only be used to =
verify CRL=20
  signatures.<BR><BR>Dave<BR><BR><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0022_01C0C9A8.A976D580--



Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA01477 for <[e-mail]>; Fri, 20 Apr 2001 05:16:44 -0700 (PDT)
Received: from cooper.entegrity.com (dave.entegrity.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GFR1B38M; Fri, 20 Apr 2001 05:16:56 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 20 Apr 2001 14:12:59 +0200
To: "Trevor Freeman" <[e-mail]>, "Bengt Ohlsson" <[e-mail]>, "Russ Housley" <[e-mail]>
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: RE: Dedicated CRL signing keys
Cc: [e-mail]
In-Reply-To: <[e-mail] .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Would it not be easier to mandate the support for Authority and Subject key 
identifiers, than to require the CA to use different DNs when different 
keys are used for issuing certificates and CRLs. As Tim noted, this problem 
may occur even for regular CAs (which use the same key for issuing 
certificates and CRLs) after a key pair rollover.

At 09:29 AM 4/19/01 -0700, Trevor Freeman wrote:
>Bengt,
>Theorizing what could be possible, do not change that support for these
>semantics is not mandatory under this profile, which means we are trying
>to establish how that client fails gracefully with some kind of
>meaningful error

I agree with Bengt that key identifier extensions provide enough 
information for the client to go looking for the right cert path to perform 
the verification of the signature on the CRL. If the client is not able to 
locate the proper path it can fail with a meaningful error.

Nada

>Trevor
>-----Original Message-----
>From: Bengt Ohlsson [mailto:[e-mail]]
>Sent: Thursday, April 19, 2001 8:10 AM
>To: Trevor Freeman; Russ Housley
>Cc: [e-mail]
>Subject: RE: Dedicated CRL signing keys
>
>Trevor and Russ,
>
>I don't see why the clients should fail to verify the signature
>on the CRL. Assume a CA uses separate keys, same DN,
>for certificate signing and CRL signing and sets the
>AuthorityKeyIdentifier extension in both the certificates
>and the CRLs. Then PKIX compliant clients should be able
>to build the correct certificate chains for verifying both the
>certificates and the CRLs.
>
>The legislation may require the CA keys to be stored in
>hardware without any copies. If you lose a key due to HW
>failure you will probaly want to continue to issue the CRLs
>with a new key and the same DN.
>
>This requires the clients to handle the AKI extension to be
>able to verify the signature on the new CRLs. This is a
>small requirement compared to handle indirect CRLs if
>you must change the DN.
>
>Bengt
>
>-----Original Message-----
>From: Trevor Freeman [mailto:[e-mail]]
>Sent: den 19 april 2001 01:40
>To: Russ Housley
>Cc: [e-mail]
>Subject: RE: Dedicated CRL signing keys
>
>
>Hi Russ,
>That addresses my concerns. A pkix compliant client can now be
>reasonability expected to fail with a more informative error, and the
>problem should be in people's faces since the CRL contains a critical
>extension.
>Trevor
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Wednesday, April 18, 2001 2:08 PM
>To: Trevor Freeman
>Cc: [e-mail]
>Subject: Re: Dedicated CRL signing keys
>
>Trevor:
>
>I propose the following solution that builds on the Indirect CRL
>capabilities that are already available.  When a CA wants to employ
>separate private keys to sign certificates and CRLs, then that CA MUST
>delegate CRL signing to a separate authority.  That separate authority
>MUST
>have a different Distinguished Name that the CA, but it could be
>operated
>by the same organization.  In this way, the IDP CRL extension would flag
>
>the "unusual" circumstances.  Clients that do not support Indirect CRLs
>can
>fail gracefully (unsupported optional feature), and clients that support
>
>Indirect CRLs can happily handle the certificates and CRLs.
>
>Thoughts?
>
>Russ
>
>At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
> >There has been some discussion regarding the proposal to have CRLs
> >signed with CA keys which do not also sign certificates. Since this
>will
> >not be a mandatory to implement feature, I am concerned about the
>impact
> >on pkix compliant clients who encounter CRL signed in this way, and how
> >we expect them to behave. What seem unacceptable with the current
> >proposal is that the signage check on the CRL will fail, and the client
> >will have little clue as to why and if this failure is expected. The
> >information in the chain, while present, is in the CAs certificate, is
> >difficult to find and subtle so would be easily missed by someone
> >debugging this problem. I would like to see some clearer indication in
>a
> >critical extension in the CRL itself that would indicate what was going
> >on. In expressing these semantics in a critical extension, we maintain
> >the principal that if you don't understand the extension, the client
> >knows to fail due to its own inadequacies and that failure is by
>design,
> >therefore allowing the client's to return an error unsupported option
> >rather than invalid signature.
> >Trevor



Received: from ent250-1.ic.lu (124.imprimerie-centrale.lu [194.154.217.124]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA15209; Fri, 20 Apr 2001 01:58:39 -0700 (PDT)
Received: from fwgw-2.ic.lu ([192.168.6.1]) by ent250-1.ic.lu (8.9.3/8.9.0) with SMTP id KAA21434; Fri, 20 Apr 2001 10:58:21 +0200 (MET DST)
Message-ID: <00e801c0c978$cc087a20$[e-mail]>
From: "David Sweigert" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: subscribe
Date: Fri, 20 Apr 2001 11:03:41 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E5_01C0C989.8F3D36B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

This is a multi-part message in MIME format.

------=_NextPart_000_00E5_01C0C989.8F3D36B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

subscribe


David G. Sweigert
Managing Director

Contact information:
Direct in dial (DID):             352+ 262-072-30
United States Cellular:        (443)-413-4820
Luxembourg fax machine:  352+ 262-072-31
http://www.trusttheweb.com


------=_NextPart_000_00E5_01C0C989.8F3D36B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>subscribe</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>David G. Sweigert<BR>Managing =
Director</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Contact information:<BR>Direct in dial=20
(DID):&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
352+ 262-072-30<BR>United States=20
Cellular:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(443)-413-4820<BR>Luxembourg=20
fax machine:&nbsp; 352+ 262-072-31<BR><A=20
href=3D"http://www.trusttheweb.com">http://www.trusttheweb.com</A><BR></F=
ONT></DIV></BODY></HTML>

------=_NextPart_000_00E5_01C0C989.8F3D36B0--



Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.9.3/8.9.3) with SMTP id RAA11737 for <[e-mail]>; Thu, 19 Apr 2001 17:36:59 -0700 (PDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Apr 2001 09:40:20 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 19 Apr 2001 09:40:00 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 19 Apr 2001 09:39:59 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Apr 2001 09:39:40 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Dedicated CRL signing keys
Date: Thu, 19 Apr 2001 09:39:40 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Dedicated CRL signing keys
Thread-Index: AcDI5IlYhLahcvQ0QHqMVTQq5vIiRgACYv/w
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 19 Apr 2001 16:39:40.0712 (UTC) FILETIME=[54851280:01C0C8EF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id RAA11738

Stephen,
The route problem is that this is an optional feature, and the net
result with the current proposal of profile compliant clients who
encounter a CA operating with this option will simply be a signature
failure. This presents a fairly high bar to anyone trying to establish
why the revocation check is failing. The rational behind using a
critical extension in the CRL is that now the conformant client knows
that failure is by design without understanding what the problem is
since it does not understand the extension and can return a more
informative error like option not supported.
Trevor

-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]] 
Sent: Thursday, April 19, 2001 7:07 AM
To: Russ Housley
Cc: Trevor Freeman; [e-mail]
Subject: Re: Dedicated CRL signing keys


Russ,

That'd be a bad resolution since it would break deployed CAs who
use the same name and different cert and CRL signing keys (and
those do exist and are operating).

Any other ideas or should we just require clients to understand
what's going on based on key usage?

Stephen.

Russ Housley wrote:
> 
> Trevor:
> 
> I propose the following solution that builds on the Indirect CRL
> capabilities that are already available.  When a CA wants to employ
> separate private keys to sign certificates and CRLs, then that CA MUST
> delegate CRL signing to a separate authority.  That separate authority
MUST
> have a different Distinguished Name that the CA, but it could be
operated
> by the same organization.  In this way, the IDP CRL extension would
flag
> the "unusual" circumstances.  Clients that do not support Indirect
CRLs can
> fail gracefully (unsupported optional feature), and clients that
support
> Indirect CRLs can happily handle the certificates and CRLs.
> 
> Thoughts?
> 
> Russ
> 
> At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
> >There has been some discussion regarding the proposal to have CRLs
> >signed with CA keys which do not also sign certificates. Since this
will
> >not be a mandatory to implement feature, I am concerned about the
impact
> >on pkix compliant clients who encounter CRL signed in this way, and
how
> >we expect them to behave. What seem unacceptable with the current
> >proposal is that the signage check on the CRL will fail, and the
client
> >will have little clue as to why and if this failure is expected. The
> >information in the chain, while present, is in the CAs certificate,
is
> >difficult to find and subtle so would be easily missed by someone
> >debugging this problem. I would like to see some clearer indication
in a
> >critical extension in the CRL itself that would indicate what was
going
> >on. In expressing these semantics in a critical extension, we
maintain
> >the principal that if you don't understand the extension, the client
> >knows to fail due to its own inadequacies and that failure is by
design,
> >therefore allowing the client's to return an error unsupported option
> >rather than invalid signature.
> >Trevor

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA02729 for <[e-mail]>; Thu, 19 Apr 2001 14:49:09 -0700 (PDT)
Received: by balinese.baltimore.ie; id WAA29177; Thu, 19 Apr 2001 22:49:09 +0100 (GMT/IST)
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma022116; Thu, 19 Apr 01 15:07:18 +0100
Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Thu, 19 Apr 2001 15:05:38 +0100
Received: from baltimore.ie (cis-flcat1.ie.baltimore.com [10.153.24.220]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA10843; Thu, 19 Apr 2001 15:10:08 +0100
Message-ID: <[e-mail]>
Date: Thu, 19 Apr 2001 15:06:49 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Trevor Freeman <[e-mail]>, [e-mail]
Subject: Re: Dedicated CRL signing keys
References: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Russ,

That'd be a bad resolution since it would break deployed CAs who
use the same name and different cert and CRL signing keys (and
those do exist and are operating).

Any other ideas or should we just require clients to understand
what's going on based on key usage?

Stephen.

Russ Housley wrote:
> 
> Trevor:
> 
> I propose the following solution that builds on the Indirect CRL
> capabilities that are already available.  When a CA wants to employ
> separate private keys to sign certificates and CRLs, then that CA MUST
> delegate CRL signing to a separate authority.  That separate authority MUST
> have a different Distinguished Name that the CA, but it could be operated
> by the same organization.  In this way, the IDP CRL extension would flag
> the "unusual" circumstances.  Clients that do not support Indirect CRLs can
> fail gracefully (unsupported optional feature), and clients that support
> Indirect CRLs can happily handle the certificates and CRLs.
> 
> Thoughts?
> 
> Russ
> 
> At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
> >There has been some discussion regarding the proposal to have CRLs
> >signed with CA keys which do not also sign certificates. Since this will
> >not be a mandatory to implement feature, I am concerned about the impact
> >on pkix compliant clients who encounter CRL signed in this way, and how
> >we expect them to behave. What seem unacceptable with the current
> >proposal is that the signage check on the CRL will fail, and the client
> >will have little clue as to why and if this failure is expected. The
> >information in the chain, while present, is in the CAs certificate, is
> >difficult to find and subtle so would be easily missed by someone
> >debugging this problem. I would like to see some clearer indication in a
> >critical extension in the CRL itself that would indicate what was going
> >on. In expressing these semantics in a critical extension, we maintain
> >the principal that if you don't understand the extension, the client
> >knows to fail due to its own inadequacies and that failure is by design,
> >therefore allowing the client's to return an error unsupported option
> >rather than invalid signature.
> >Trevor

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from netlink.co.nz (mako.netlink.co.nz [202.20.93.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA01289 for <[e-mail]>; Thu, 19 Apr 2001 14:28:43 -0700 (PDT)
Received: from ronsnotebook (128i-cl128.netlink.net.nz [203.97.144.128]) by netlink.co.nz (8.9.3/8.9.3) with SMTP id JAA02912; Fri, 20 Apr 2001 09:28:42 +1200 (NZST)
From: "Ron Segal" <[e-mail]>
To: "David Cross" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Help Sought on Netscape Revocation URL causing MS Programs to hang
Date: Fri, 20 Apr 2001 09:32:06 +1200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0148_01C0C97C.C3E31220"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>

This is a multi-part message in MIME format.

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

Hi David

Thanks for your offer to checkout the certificate chain.

Actually a clear explanation has now been offered by free Microsoft
support(unexpectedly rapid and knowedgable service I might add, particularly
as it was a free web query).

It seems that if the revocation check itself is to a secure server (https)
and the server certificate itself has a Nescape revocation extension a
recursive revocation process can occur.  Microsoft are providing a partial
fix for this in their new version of Office (XP) by detecting the recursion
and halting the process.  If this happens the revocation check will fail to
provide revocation status. The optimum solution is to remove the Netscape
revocation extension from the server certificate.

I'm copying this to the list so that others will see that the problem has
been 'solved', and the solution (please note server cert providers!).

Hope that I did not miss any messages and personally thanked everybody who
responded, at least that was the intention.

Very best regards

Ron


--------------
Ron Segal
Business Development Manager
Baycorp ID Services Ltd
PO Box 5052, Wellington, New Zealand

Mailto: [e-mail]
Tel:   +64 (9)  356 5801
DD:    +64 (4)  499 4261
Mob:   [phone]
Fax:   +64 (9)  356 5818
Web:   http://www.baycorpid.com


If you received a warning on reading this email, please go to
<http://www.baycorpid.com/settings/email.asp> to update your settings


-----Original Message-----
From: David Cross [mailto:[e-mail]]
Sent: Friday, 20 April 2001 1:39 a.m.
To: Ron Segal; [e-mail]
Subject: RE: Help Sought on Netscape Revocation URL causing MS Programs
to hang


I will pass on the job offer, but have you verified that the URLs are
valid that are listed in the certificate?  If the URLs are no longer
valid or cannot be reached, that might explain the behaviour.  If you
want to send me the certificate chain (privately), we can take a look at
it.

David B. Cross






-----Original Message-----
From: Ron Segal [mailto:[e-mail]]
Sent: Wednesday, April 18, 2001 6:59 PM
To: [e-mail]
Subject: Help Sought on Netscape Revocation URL causing MS Programs to
hang


Hi Folks

If an X.509 v3 certificate contains a proprietary NetscapeRevocationURL
extension and a Microsoft program (eg email or browser) is configured to
do automatic CRL Distribution Point Checking, then the Microsoft program
will hang and timeout after about 5 minutes.

Does anybody know of a fix for this problem, e.g. a registry
configuration (no cynicism please!)?

We are aware that if a cert has both the NetscapeRevocationURL and CRL
Distribution Point extensions, then no problem.

Your help would be greatly appreciated (and maybe you can get a job at
Baycorp!).

Very best regards

Ron

--------------
Ron Segal
Business Development Manager
Baycorp ID Services Ltd
PO Box 5052, Wellington, New Zealand

Mailto: [e-mail]
Tel:   +64 (4)  499 4231
DD:    +64 (4)  499 4261
Mob:   [phone]
Fax:   +64 (4)  499 4233
Web:   http://www.baycorpid.com

------=_NextPart_000_0148_01C0C97C.C3E31220
Content-Type: text/x-vcard;
	name="Ron Segal.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Ron Segal.vcf"

BEGIN:VCARD
VERSION:2.1
N:Segal;Ron
FN:Ron Segal
ORG:Baycorp ID Services
TITLE:Business Development Manager
TEL;WORK;VOICE:[phone]
TEL;CELL;VOICE:[phone]
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Level 1=3D0D=3D0ALandcorp =
House=3D0D=3D0A101 Lambton Quay=3D0D=3D0APO Box 5052;Welling=3D
ton;;;New Zealand
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Level 1=3D0D=3D0ALandcorp =
House=3D0D=3D0A101 Lambton Quay=3D0D=3D0APO Box 5052=3D0D=3D0AWell=3D
ington=3D0D=3D0ANew Zealand
URL:
URL:http://www.baycorpid.com
KEY;X509;ENCODING=3DBASE64:
    =
MIIGdzCCBV+gAwIBAgIEOhwthjANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJOWjEgMB4G
    =
A1UEChMXQmF5Y29ycCBJRCBTZXJ2aWNlcyBMdGQxGTAXBgNVBAsTEEJheWNvcnAgUGFzc3Bv
    =
cnQxLzAtBgNVBAMTJkJheWNvcnAgUGFzc3BvcnQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4X
    =
DTAwMTEyMjIwMzMxMFoXDTAxMTEyNzIwMzMxMFowfDELMAkGA1UEBhMCTloxCjAIBgNVBAgT
    =
AS0xEzARBgNVBAcTCldlbGxpbmd0b24xEDAOBgNVBAoTB0JheWNvcnAxEjAQBgNVBAMTCVJv
    =
biBTZWdhbDEmMCQGCSqGSIb3DQEJARYXcm9uLnNlZ2FsQGJheWNvcnBpZC5jb20wgZ8wDQYJ
    =
KoZIhvcNAQEBBQADgY0AMIGJAoGBANRQxdVFIMgxT5W45/I5HSGKPCCKfijydisE8fhqc/uh
    =
Vqn9wE+CwCMJKKgUM5pH3g+ZyTbBKjctkSDOcmuN2aNGm1EPZq1xORI6byWmd6S9jb5/I2vt
    =
IeqhWQC3MuVhrBFFuOsu1JBiGLmxaHg71ti/b97q50zA/hIOgDAuixtfAgMBAAGjggOEMIID
    =
gDAiBgkrBgEEAZtYAAEEFRYTUm9uYWxkIFNhbXVlbCBTZWdhbDAOBgNVHQ8BAf8EBAMCA/gw
    =
UQYDVR0lBEowSAYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwUGCCsG
    =
AQUFBwMGBggrBgEFBQcDBwYKKwYBBAGCNwoDBDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8v
    =
d3d3LmJheWNvcnBpZC5jb20vY3JsL3Bhc3Nwb3J0LmNybDAZBgNVHQkEEjAQMA4GA1UEBDEH
    =
EwVTZWdhbDAiBgNVHREEGzAZgRdyb24uc2VnYWxAYmF5Y29ycGlkLmNvbTCCAfIGA1UdIASC
    =
AekwggHlMIIB4QYMKwYBBAGbWAIBAgECMIIBzzCCAZoGCCsGAQUFBwICMIIBjBqCAYhUaGUg
    =
cmlnaHRzLCBvYmxpZ2F0aW9ucyBhbmQgbGlhYmlsaXRpZXMgb2YgdGhlIFN1YmplY3QsIEJh
    =
eWNvcnAgSUQgU2VydmljZXMgYW5kIGFueSByZWx5aW5nIHBhcnR5IGFyZSBzcGVjaWZpZWQg
    =
aW4gdGhlIEJheWNvcnAgUGFzc3BvcnQgQ2VydGlmaWNhdGlvbiBQcmFjdGlzZSBTdGF0ZW1l
    =
bnQuIFlvdSBtdXN0IGVuc3VyZSB0aGF0IHRoaXMgY2VydGlmaWNhdGUgaXMgbm90IHN1c3Bl
    =
bmRlZCBvciByZXZva2VkOyBjb21wbHkgd2l0aCB0aGUgc3BlY2lmaWNhdGlvbnMgaW4gaXRz
    =
IEtleSBVc2FnZSBmaWVsZDsgYWRoZXJlIHRvIEJheWNvcnAgSUQgU2VydmljZXMnIFByaXZh
    =
Y3kgUG9saWN5LiBGdXJ0aGVyIGRldGFpbCBpcyBhdmFpbGFibGUgZnJvbSBCYXljb3JwIElE
    =
IFNlcnZpY2VzOjAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5iYXljb3JwaWQuY29tL3JlcG9z
    =
aXRvcnkwOwYIKwYBBQUHAQEELzAtMCsGCCsGAQUFBzABhh9odHRwOi8vY2VydHN0YXR1cy5i
    =
YXljb3JwaWQuY29tMB8GA1UdIwQYMBaAFHlNfEwOah9O+VNsNHtQxa6cxvR+MB0GA1UdDgQW
    =
BBSQs4oU5iFIMqGm5FFzDKWqV0NDlzAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQCM
    =
mcZU4Svrle0oqf8/r080V7/KW/7aaoYk//s161jKoWUs7WfmZzbyOgUQPeIuzk3bqfD9xN2E
    =
kfDkaMiPDg5xZ8O/WKnzV2CLYDZrgyoFZ/o0ol+g1akXdAsgp3U73wk8kc7PfcpttSAQy7Mc
    =
78Ej+kaU1TUcyaqsJU6+cryb0EfixPosZpUgx8SZcx+KuRej5ZGHk0zCCsVWNS91noMlkN95
    =
ZP5fkzReeX2xrFmVfqTNawYBywrrvY4ULADRAVFrbqU4h2152KZKsALEpSFZqntLZlR8izqA
    dz/8d+u0KwTLkSPRJiWemL2iyFkU5H6qQoOLuLEQCQiRNxiblLlI


EMAIL;PREF;INTERNET:[e-mail]
REV:20010130T034848Z
END:VCARD

------=_NextPart_000_0148_01C0C97C.C3E31220--



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA00268 for <[e-mail]>; Thu, 19 Apr 2001 14:19:37 -0700 (PDT)
Received: by balinese.baltimore.ie; id VAA20847; Thu, 19 Apr 2001 21:53:26 +0100 (GMT/IST)
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma006880; Thu, 19 Apr 01 19:36:32 +0100
Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 19 Apr 2001 19:35:21 +0100
Received: from baltimore.ie (cis-flcat1.ie.baltimore.com [10.153.24.220]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id TAA21736 for <[e-mail]>; Thu, 19 Apr 2001 19:39:53 +0100
Message-ID: <[e-mail]>
Date: Thu, 19 Apr 2001 19:36:31 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: [Re-Tx: Dedicated CRL signing keys]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Seems like the list is acting funny today. Here's a re-send.

Stephen Farrell wrote:
> 
> Russ,
> 
> That'd be a bad resolution since it would break deployed CAs who
> use the same name and different cert and CRL signing keys (and
> those do exist and are operating).
> 
> Any other ideas or should we just require clients to understand
> what's going on based on key usage?
> 
> Stephen.
> 
> Russ Housley wrote:
> >
> > Trevor:
> >
> > I propose the following solution that builds on the Indirect CRL
> > capabilities that are already available.  When a CA wants to employ
> > separate private keys to sign certificates and CRLs, then that CA MUST
> > delegate CRL signing to a separate authority.  That separate authority MUST
> > have a different Distinguished Name that the CA, but it could be operated
> > by the same organization.  In this way, the IDP CRL extension would flag
> > the "unusual" circumstances.  Clients that do not support Indirect CRLs can
> > fail gracefully (unsupported optional feature), and clients that support
> > Indirect CRLs can happily handle the certificates and CRLs.
> >
> > Thoughts?
> >
> > Russ
> >
> > At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
> > >There has been some discussion regarding the proposal to have CRLs
> > >signed with CA keys which do not also sign certificates. Since this will
> > >not be a mandatory to implement feature, I am concerned about the impact
> > >on pkix compliant clients who encounter CRL signed in this way, and how
> > >we expect them to behave. What seem unacceptable with the current
> > >proposal is that the signage check on the CRL will fail, and the client
> > >will have little clue as to why and if this failure is expected. The
> > >information in the chain, while present, is in the CAs certificate, is
> > >difficult to find and subtle so would be easily missed by someone
> > >debugging this problem. I would like to see some clearer indication in a
> > >critical extension in the CRL itself that would indicate what was going
> > >on. In expressing these semantics in a critical extension, we maintain
> > >the principal that if you don't understand the extension, the client
> > >knows to fail due to its own inadequacies and that failure is by design,
> > >therefore allowing the client's to return an error unsupported option
> > >rather than invalid signature.
> > >Trevor
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA00215 for <[e-mail]>; Thu, 19 Apr 2001 14:19:16 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JHNYDB7H>; Thu, 19 Apr 2001 17:18:48 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "David A. Cooper" <[e-mail]>, [e-mail]
Subject: RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)
Date: Thu, 19 Apr 2001 17:10:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C915.1A9D0C50"

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_01C0C915.1A9D0C50
Content-Type: text/plain;
	charset="iso-8859-1"

I agree with David.  It should acceptable to have a cRLSign bit on and
basicConstraints absent.

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Thursday, April 19, 2001 5:08 PM
To: [e-mail]
Subject: cA flag and CRL issuers (was Re: Last Call:
draft-ietf-pkix-new-part1-06.txt comments)


At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:
>Dave Cooper,
>
>>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:
>>I see no basis in X.509 for setting the cA flag in basicConstraints for
certificate subjects that can issue CRLs but not certificates. The current
discussion about how to deal with CRLs for attribute certificates vs. public
key certificates just further goes to show that it was a mistake to suddenly
change the rules at the last IETF meeting.
>
>We disagree on this point. Nowhere in X.509 or in previous PKIX documents
has there ever been text to suggest that other than a CA can sign a CRL for
a public key certificate. So, the rules were not changed at the last
meeting, they were reasserted and clarified.

Steve,

You may say that X.509 and PKIX do not suggest that entities other than CAs
can sign CRLs. However, I think we all agree that both X.509 and PKIX allow
for a CRL to be signed with a different key than the key used to sign the
certificates that are covered by that CRL. This may be a result of the CA
that issued the certificates signing the corresponding CRLs with a different
key or the CA that issued the certificates delegating the CRL issuing to
another entity (via the distribution points extension). There is no
requirement that the key used to sign the CRL also be used to sign
certificates. So, I think we agree that there will be times where we will be
issuing certificates to entities (whether those entities are CAs or not)
where the intent is to specify that the public keys in the certificates may
be used to verify signatures on CRLs but not on certificates.

The only place we seem to disagree is on the contents of the certificates
issued in such circumstances. In particular, should the certificates contain
a basicConstraints extension with the cA bit set? On this point, both X.509
and the previous PKIX documents are quite clear that the cA bit should not
be set. Why? Because a CA is defined as an entity that issues public-key
certificates and both documents similarly state that the cA bit is used to
specify whether the certificate subject can issue certificates. There is no
similar connection made between being a CA and issuing CRLs.


The following are some quotes from X.509 and pkix-new-part1-05:

In X.509 a CA is defined as "[a]n authority trusted by one or more users to
create and assign public-key certificates."

Section 7 of X.509 states that "[a] CA-certificate is a certificate issued
by a CA to a subject that is itself a CA and therefore is capable of issuing
public-key certificates."


The description of basic constraints in X.509 further supports the idea that
the cA bit is used to specify certificate issuing, not certificate and/or
CRL issuing:

"This field indicates if the subject may act as a CA, with the certified
public key being used to verify certificate signatures. ... The cA component
indicates if the certified public key may be used to verify certificate
signatures. ... if the value of cA is not set to true then the certified
public key shall not be used to verify a certificate signature"


pkix-new-part1-05 states something similar:

"The cA bit indicates if the certified public key may be used to verify
signatures on other certificates. If the cA bit is asserted, then the
keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also be
asserted. If the cA bit is not asserted, then the keyCertSign bit in the key
usage extension MUST NOT be asserted."


The description of the key usage bits are consistent with this as well.

X.509:
"The bit keyCertSign is for use in CA-certificates only. If KeyUsage is set
to keyCertSign and the basic constraints extension is present in the same
certificate, the value of the cA component of that extension shall be set to
TRUE."

pkix-new-part1-05:
"The keyCertSign bit is asserted when the subject public key is used for
verifying a signature on certificates.  This bit may only be asserted in CA
certificates.  If the keyCertSign bit is asserted, then the cA bit in the
basic constraints extension (see 4.2.1.10) MUST also be asserted. If the
keyCertSign bit is not asserted, then the cA bit in the basic constraints
extension MUST NOT be asserted.

The cRLSign bit is asserted when the subject public key is used for
verifying a signature on revocation information (e.g., a CRL)."



So, both X.509 and pkix-new-part1-05 go to great lengths to clearly state
that only CAs can issue certificates and that basicConstraints with the cA
bit set to true must be present in the certificates where the public key is
to be used to verify signatures on certificates. There are no similar
statements about CRLs. In fact, both documents are quite clear that the cA
bit must not be set when the subject public key can not be used to verify
certificates. So, if the subject public key can be used to verify CRLs, but
not certificates, the cA bit must not be set.

X.509 is also careful not to preclude the public keys of non-CAs from being
used to verify signatures on CRLs. For instance, an end entity is defined as
"[a] certificate subject that uses its private key for purposes other than
signing certificates or an entity that is a relying party." This leaves room
for an end entity to use its private key to sign CRLs.


So, if PKIX wants to require that the cA bit be set whenever the subject
public key can be used to verify CRLs and also wants to maintain consistency
with X.509, PKIX would have to require that any certificate authorizing the
use of a public key for verifying CRL signatures also authorize the use of
that public key for verifying certificate signatures. Since we are in
agreement that we do not want to impose such a restriction and that we do
want to maintain consistency with X.509, we can not require that the cA bit
be set when the subject public key can only be used to verify CRL
signatures.

Dave


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: cA flag and CRL issuers (was Re: Last Call: =
draft-ietf-pkix-new-part1-06.txt comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with David.&nbsp; It should acceptable to =
have a cRLSign bit on and basicConstraints absent.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David A. Cooper [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, April 19, 2001 5:08 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: cA flag and CRL issuers (was Re: Last =
Call:</FONT>
<BR><FONT SIZE=3D2>draft-ietf-pkix-new-part1-06.txt comments)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Dave Cooper,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;At 01:40 PM 4/18/01 -0400, David A. Cooper =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;I see no basis in X.509 for setting the cA =
flag in basicConstraints for certificate subjects that can issue CRLs =
but not certificates. The current discussion about how to deal with =
CRLs for attribute certificates vs. public key certificates just =
further goes to show that it was a mistake to suddenly change the rules =
at the last IETF meeting.</FONT></P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;We disagree on this point. Nowhere in X.509 or =
in previous PKIX documents has there ever been text to suggest that =
other than a CA can sign a CRL for a public key certificate. So, the =
rules were not changed at the last meeting, they were reasserted and =
clarified.</FONT></P>

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

<P><FONT SIZE=3D2>You may say that X.509 and PKIX do not suggest that =
entities other than CAs can sign CRLs. However, I think we all agree =
that both X.509 and PKIX allow for a CRL to be signed with a different =
key than the key used to sign the certificates that are covered by that =
CRL. This may be a result of the CA that issued the certificates =
signing the corresponding CRLs with a different key or the CA that =
issued the certificates delegating the CRL issuing to another entity =
(via the distribution points extension). There is no requirement that =
the key used to sign the CRL also be used to sign certificates. So, I =
think we agree that there will be times where we will be issuing =
certificates to entities (whether those entities are CAs or not) where =
the intent is to specify that the public keys in the certificates may =
be used to verify signatures on CRLs but not on =
certificates.</FONT></P>

<P><FONT SIZE=3D2>The only place we seem to disagree is on the contents =
of the certificates issued in such circumstances. In particular, should =
the certificates contain a basicConstraints extension with the cA bit =
set? On this point, both X.509 and the previous PKIX documents are =
quite clear that the cA bit should not be set. Why? Because a CA is =
defined as an entity that issues public-key certificates and both =
documents similarly state that the cA bit is used to specify whether =
the certificate subject can issue certificates. There is no similar =
connection made between being a CA and issuing CRLs.</FONT></P>
<BR>

<P><FONT SIZE=3D2>The following are some quotes from X.509 and =
pkix-new-part1-05:</FONT>
</P>

<P><FONT SIZE=3D2>In X.509 a CA is defined as &quot;[a]n authority =
trusted by one or more users to create and assign public-key =
certificates.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Section 7 of X.509 states that &quot;[a] =
CA-certificate is a certificate issued by a CA to a subject that is =
itself a CA and therefore is capable of issuing public-key =
certificates.&quot;</FONT></P>
<BR>

<P><FONT SIZE=3D2>The description of basic constraints in X.509 further =
supports the idea that the cA bit is used to specify certificate =
issuing, not certificate and/or CRL issuing:</FONT></P>

<P><FONT SIZE=3D2>&quot;This field indicates if the subject may act as =
a CA, with the certified public key being used to verify certificate =
signatures. ... The cA component indicates if the certified public key =
may be used to verify certificate signatures. ... if the value of cA is =
not set to true then the certified public key shall not be used to =
verify a certificate signature&quot;</FONT></P>
<BR>

<P><FONT SIZE=3D2>pkix-new-part1-05 states something similar:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;The cA bit indicates if the certified public =
key may be used to verify signatures on other certificates. If the cA =
bit is asserted, then the keyCertSign bit in the key usage extension =
(see 4.2.1.3) MUST also be asserted. If the cA bit is not asserted, =
then the keyCertSign bit in the key usage extension MUST NOT be =
asserted.&quot;</FONT></P>
<BR>

<P><FONT SIZE=3D2>The description of the key usage bits are consistent =
with this as well.</FONT>
</P>

<P><FONT SIZE=3D2>X.509:</FONT>
<BR><FONT SIZE=3D2>&quot;The bit keyCertSign is for use in =
CA-certificates only. If KeyUsage is set to keyCertSign and the basic =
constraints extension is present in the same certificate, the value of =
the cA component of that extension shall be set to =
TRUE.&quot;</FONT></P>

<P><FONT SIZE=3D2>pkix-new-part1-05:</FONT>
<BR><FONT SIZE=3D2>&quot;The keyCertSign bit is asserted when the =
subject public key is used for verifying a signature on =
certificates.&nbsp; This bit may only be asserted in CA =
certificates.&nbsp; If the keyCertSign bit is asserted, then the cA bit =
in the basic constraints extension (see 4.2.1.10) MUST also be =
asserted. If the keyCertSign bit is not asserted, then the cA bit in =
the basic constraints extension MUST NOT be asserted.</FONT></P>

<P><FONT SIZE=3D2>The cRLSign bit is asserted when the subject public =
key is used for verifying a signature on revocation information (e.g., =
a CRL).&quot;</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>So, both X.509 and pkix-new-part1-05 go to great =
lengths to clearly state that only CAs can issue certificates and that =
basicConstraints with the cA bit set to true must be present in the =
certificates where the public key is to be used to verify signatures on =
certificates. There are no similar statements about CRLs. In fact, both =
documents are quite clear that the cA bit must not be set when the =
subject public key can not be used to verify certificates. So, if the =
subject public key can be used to verify CRLs, but not certificates, =
the cA bit must not be set.</FONT></P>

<P><FONT SIZE=3D2>X.509 is also careful not to preclude the public keys =
of non-CAs from being used to verify signatures on CRLs. For instance, =
an end entity is defined as &quot;[a] certificate subject that uses its =
private key for purposes other than signing certificates or an entity =
that is a relying party.&quot; This leaves room for an end entity to =
use its private key to sign CRLs.</FONT></P>
<BR>

<P><FONT SIZE=3D2>So, if PKIX wants to require that the cA bit be set =
whenever the subject public key can be used to verify CRLs and also =
wants to maintain consistency with X.509, PKIX would have to require =
that any certificate authorizing the use of a public key for verifying =
CRL signatures also authorize the use of that public key for verifying =
certificate signatures. Since we are in agreement that we do not want =
to impose such a restriction and that we do want to maintain =
consistency with X.509, we can not require that the cA bit be set when =
the subject public key can only be used to verify CRL =
signatures.</FONT></P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C0C915.1A9D0C50--


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29196 for <[e-mail]>; Thu, 19 Apr 2001 14:08:14 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA00403 for <[e-mail]>; Thu, 19 Apr 2001 17:08:16 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 19 Apr 2001 17:08:07 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)
In-Reply-To: <p05010405b703d0078a43@[128.33.4.39]>
References: <[e-mail]> <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA29197

At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:
>Dave Cooper,
>
>>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:
>>I see no basis in X.509 for setting the cA flag in basicConstraints for certificate subjects that can issue CRLs but not certificates. The current discussion about how to deal with CRLs for attribute certificates vs. public key certificates just further goes to show that it was a mistake to suddenly change the rules at the last IETF meeting.
>
>We disagree on this point. Nowhere in X.509 or in previous PKIX documents has there ever been text to suggest that other than a CA can sign a CRL for a public key certificate. So, the rules were not changed at the last meeting, they were reasserted and clarified.

Steve,

You may say that X.509 and PKIX do not suggest that entities other than CAs can sign CRLs. However, I think we all agree that both X.509 and PKIX allow for a CRL to be signed with a different key than the key used to sign the certificates that are covered by that CRL. This may be a result of the CA that issued the certificates signing the corresponding CRLs with a different key or the CA that issued the certificates delegating the CRL issuing to another entity (via the distribution points extension). There is no requirement that the key used to sign the CRL also be used to sign certificates. So, I think we agree that there will be times where we will be issuing certificates to entities (whether those entities are CAs or not) where the intent is to specify that the public keys in the certificates may be used to verify signatures on CRLs but not on certificates.

The only place we seem to disagree is on the contents of the certificates issued in such circumstances. In particular, should the certificates contain a basicConstraints extension with the cA bit set? On this point, both X.509 and the previous PKIX documents are quite clear that the cA bit should not be set. Why? Because a CA is defined as an entity that issues public-key certificates and both documents similarly state that the cA bit is used to specify whether the certificate subject can issue certificates. There is no similar connection made between being a CA and issuing CRLs.


The following are some quotes from X.509 and pkix-new-part1-05:

In X.509 a CA is defined as "[a]n authority trusted by one or more users to create and assign public-key certificates."

Section 7 of X.509 states that "[a] CA-certificate is a certificate issued by a CA to a subject that is itself a CA and therefore is capable of issuing public-key certificates."


The description of basic constraints in X.509 further supports the idea that the cA bit is used to specify certificate issuing, not certificate and/or CRL issuing:

"This field indicates if the subject may act as a CA, with the certified public key being used to verify certificate signatures. … The cA component indicates if the certified public key may be used to verify certificate signatures. … if the value of cA is not set to true then the certified public key shall not be used to verify a certificate signature"


pkix-new-part1-05 states something similar:

"The cA bit indicates if the certified public key may be used to verify signatures on other certificates. If the cA bit is asserted, then the keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also be asserted. If the cA bit is not asserted, then the keyCertSign bit in the key usage extension MUST NOT be asserted."


The description of the key usage bits are consistent with this as well.

X.509:
"The bit keyCertSign is for use in CA-certificates only. If KeyUsage is set to keyCertSign and the basic constraints extension is present in the same certificate, the value of the cA component of that extension shall be set to TRUE."

pkix-new-part1-05:
"The keyCertSign bit is asserted when the subject public key is used for verifying a signature on certificates.  This bit may only be asserted in CA certificates.  If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (see 4.2.1.10) MUST also be asserted. If the keyCertSign bit is not asserted, then the cA bit in the basic constraints extension MUST NOT be asserted.

The cRLSign bit is asserted when the subject public key is used for verifying a signature on revocation information (e.g., a CRL)."



So, both X.509 and pkix-new-part1-05 go to great lengths to clearly state that only CAs can issue certificates and that basicConstraints with the cA bit set to true must be present in the certificates where the public key is to be used to verify signatures on certificates. There are no similar statements about CRLs. In fact, both documents are quite clear that the cA bit must not be set when the subject public key can not be used to verify certificates. So, if the subject public key can be used to verify CRLs, but not certificates, the cA bit must not be set.

X.509 is also careful not to preclude the public keys of non-CAs from being used to verify signatures on CRLs. For instance, an end entity is defined as "[a] certificate subject that uses its private key for purposes other than signing certificates or an entity that is a relying party." This leaves room for an end entity to use its private key to sign CRLs.


So, if PKIX wants to require that the cA bit be set whenever the subject public key can be used to verify CRLs and also wants to maintain consistency with X.509, PKIX would have to require that any certificate authorizing the use of a public key for verifying CRL signatures also authorize the use of that public key for verifying certificate signatures. Since we are in agreement that we do not want to impose such a restriction and that we do want to maintain consistency with X.509, we can not require that the cA bit be set when the subject public key can only be used to verify CRL signatures.

Dave




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA20016 for <[e-mail]>; Thu, 19 Apr 2001 11:08:29 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA27361; Thu, 19 Apr 2001 14:08:19 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040cb704d8f3c8bd@[128.33.4.39]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 19 Apr 2001 14:04:39 -0400
To: Sharon Boeyen <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Cc: "David P. Kemp" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 1:36 PM -0400 4/19/01, Sharon Boeyen wrote:
>I have no strong view on this, but did want to clarify that CRL is the
>generic term that covers all the others (see 3.3.11 of 509) "A signed
>list indicating a set of certificates that are no longer considered 
>valid by the
>certificate issuer. In addition to the generic term CRL, some specific CRL
>types are defined for CRLs that cover particular scopes". The definitions
>for those are also in subclauses of 3.3.

Thanks, that matched my informal notion, but I was not certain. 
Thanks for the clarification.  So, under that definition, "e.g." 
could be misleading and we need to clarify the text, however it works 
out.

Steve


Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA18554 for <[e-mail]>; Thu, 19 Apr 2001 10:55:33 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04311; Thu, 19 Apr 2001 10:55:35 -0700 (PDT)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14931; Thu, 19 Apr 2001 13:55:33 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 19 Apr 2001 13:51:28 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:
> > However, I object to adding support for limits on trust anchors to
> > section 6.1. The algorithm in section 6.1 is the "basic" algorithm that
> > everyone MUST implement. Section 6.2 describes various ways to extend
> > that algorithm. Multiple trust anchors is one. Limits on trust anchors
> > is a second. PEM compatible processing is a third. If one argues that
> > limits on trust anchors should be described in section 6.1, one could
> > equally argue that PEM compatible processing should be described in
> > section 6.1.
> 
> I agree with the intent, but this is NOT what the text says. :-(
> 
> In particular section 6.1 only says " This text describes an algorithm for
> X.509 path processing". It does not qualifies it as basic nor says that it
> is a set of minimum conditions.

Section 6 (third paragraph) says "In section 6.1, the text describes
basic path validation." A few paragraphs later, it says "Section 6.2
describes methods for using the path validation algorithm in specific
implementations. Two specific cases are discussed: the case where paths
may begin with one of several trusted CAs; and where compatibility with
the PEM architecture is required."

Section 6.1 (first paragraph) says "A conformant implementation MUST
include an X.509 path processing procedure that is functionally
equivalent to the external behavior of this algorithm." And section 6.1
is titled "Basic Path Validation", while section 6.2 is titled "Using
the Path Validation Algorithm".

That's why I said that section 6.1 is the "basic" algorithm that
everyone MUST implement and section 6.2 describes various ways to extend
that algorithm.

> Section 6.2 says " The path validation algorithm describes the process of
> validating a single certification path".

> "An implementation that supports multiple trust anchors may augment the
> algorithm presented in section 6.1 to further limit the set of valid paths
> which begin with a particular trust anchor."

This is one of several variations included in section 6.2. PEM
compatible processing is also included in section 6.2. Section 6.2 is
clearly not limited to variations which employ multiple trust anchors.

> You are proposing that the text from section 6.1 describes the "basic"
> algorithm, while the text from section 6.2. describes enhancements to the
> basic algorihm. I would not be opposed to your proposal, ... but many text
> changes would be required.

I don't think so. I think the text at the start of section 6 is clear.
Perhaps an introductory paragraph at the start of section 6.2 would make
it even clearer, but I don't see any other changes that would be
required.

-Steve


Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA17388 for <[e-mail]>; Thu, 19 Apr 2001 10:42:16 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <2VH1AMZW>; Thu, 19 Apr 2001 13:41:45 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Thu, 19 Apr 2001 13:36:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C8F7.40D2AD80"

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_01C0C8F7.40D2AD80
Content-Type: text/plain

I have no strong view on this, but did want to clarify that CRL is the 
generic term that covers all the others (see 3.3.11 of 509) "A signed 
list indicating a set of certificates that are no longer considered valid by
the 
certificate issuer. In addition to the generic term CRL, some specific CRL
types are defined for CRLs that cover particular scopes". The definitions
for those are also in subclauses of 3.3.

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Thursday, April 19, 2001 1:18 PM
> To: David P. Kemp
> Cc: [e-mail]
> Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
> 
> 
> At 11:05 AM -0400 4/19/01, David P. Kemp wrote:
> >Steve,
> >
> >I have no preference whether in the phrase "CertificateList 
> (e.g., CRL)"
> >the "e.g.," stays or goes.  Note that some people use CRL to refer
> >to every instance of a CertificateList, whereas others use CRL, ARL,
> >ACRL, ICRL, DCRL, etc. to distinguish lists used for different
> >purposes.  Thus CRL may be either an example of, or a synonym for,
> >CertificateList.
> >
> >I agree that the state of the cRLSign bit is not relevant to OCSP
> >responses and that CertificateList is the only data structure
> >which requires this bit.
> >
> >Dave K
> 
> Good points. If one considers ARLs and the other examples above, then 
> I have to admit that "e.g.," is appropriate, though it would be 
> better to include other instances here to make the distinction 
> clearer.
> 
> Steve
> 

------_=_NextPart_001_01C0C8F7.40D2AD80
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I have no strong view on this, but did want to clarify that CRL is the </FONT>
<BR><FONT SIZE=2>generic term that covers all the others (see 3.3.11 of 509) &quot;A signed </FONT>
<BR><FONT SIZE=2>list indicating a set of certificates that are no longer considered valid by the </FONT>
<BR><FONT SIZE=2>certificate issuer. In addition to the generic term CRL, some specific CRL</FONT>
<BR><FONT SIZE=2>types are defined for CRLs that cover particular scopes&quot;. The definitions</FONT>
<BR><FONT SIZE=2>for those are also in subclauses of 3.3.</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Stephen Kent [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, April 19, 2001 1:18 PM</FONT>
<BR><FONT SIZE=2>&gt; To: David P. Kemp</FONT>
<BR><FONT SIZE=2>&gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At 11:05 AM -0400 4/19/01, David P. Kemp wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;Steve,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;I have no preference whether in the phrase &quot;CertificateList </FONT>
<BR><FONT SIZE=2>&gt; (e.g., CRL)&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt;the &quot;e.g.,&quot; stays or goes.&nbsp; Note that some people use CRL to refer</FONT>
<BR><FONT SIZE=2>&gt; &gt;to every instance of a CertificateList, whereas others use CRL, ARL,</FONT>
<BR><FONT SIZE=2>&gt; &gt;ACRL, ICRL, DCRL, etc. to distinguish lists used for different</FONT>
<BR><FONT SIZE=2>&gt; &gt;purposes.&nbsp; Thus CRL may be either an example of, or a synonym for,</FONT>
<BR><FONT SIZE=2>&gt; &gt;CertificateList.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;I agree that the state of the cRLSign bit is not relevant to OCSP</FONT>
<BR><FONT SIZE=2>&gt; &gt;responses and that CertificateList is the only data structure</FONT>
<BR><FONT SIZE=2>&gt; &gt;which requires this bit.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Dave K</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Good points. If one considers ARLs and the other examples above, then </FONT>
<BR><FONT SIZE=2>&gt; I have to admit that &quot;e.g.,&quot; is appropriate, though it would be </FONT>
<BR><FONT SIZE=2>&gt; better to include other instances here to make the distinction </FONT>
<BR><FONT SIZE=2>&gt; clearer.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Steve</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C8F7.40D2AD80--


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA15748 for <[e-mail]>; Thu, 19 Apr 2001 10:18:21 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA20210; Thu, 19 Apr 2001 13:18:17 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010408b704cdf733dd@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <000801c0c6a7$60e9d870$[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]> <p05010405b703d0078a43@[128.33.4.39]> <[e-mail]>
Date: Thu, 19 Apr 2001 13:18:06 -0400
To: "David P. Kemp" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 11:05 AM -0400 4/19/01, David P. Kemp wrote:
>Steve,
>
>I have no preference whether in the phrase "CertificateList (e.g., CRL)"
>the "e.g.," stays or goes.  Note that some people use CRL to refer
>to every instance of a CertificateList, whereas others use CRL, ARL,
>ACRL, ICRL, DCRL, etc. to distinguish lists used for different
>purposes.  Thus CRL may be either an example of, or a synonym for,
>CertificateList.
>
>I agree that the state of the cRLSign bit is not relevant to OCSP
>responses and that CertificateList is the only data structure
>which requires this bit.
>
>Dave K

Good points. If one considers ARLs and the other examples above, then 
I have to admit that "e.g.," is appropriate, though it would be 
better to include other instances here to make the distinction 
clearer.

Steve


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA14730 for <[e-mail]>; Thu, 19 Apr 2001 10:03:42 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA16970; Thu, 19 Apr 2001 19:03:21 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id TAA17032; Thu, 19 Apr 2001 19:03:09 +0200
Message-ID: <[e-mail]>
Date: Thu, 19 Apr 2001 19:03:03 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,
 
> It is certainly true that specifying name constraints for trust anchors
> will work when a single trust anchor is used. Perhaps the sentence in
> section 6.2 should be changed to say "Implementations may also augment
> the algorithm presented in section 6.1 to further limit the set of valid
> paths which begin with a particular trust anchor."
> 
> However, I object to adding support for limits on trust anchors to
> section 6.1. The algorithm in section 6.1 is the "basic" algorithm that
> everyone MUST implement. Section 6.2 describes various ways to extend
> that algorithm. Multiple trust anchors is one. Limits on trust anchors
> is a second. PEM compatible processing is a third. If one argues that
> limits on trust anchors should be described in section 6.1, one could
> equally argue that PEM compatible processing should be described in
> section 6.1.

I agree with the intent, but this is NOT what the text says. :-(

In particular section 6.1 only says " This text describes an algorithm for
X.509 path processing". It does not qualifies it as basic nor says that it
is a set of minimum conditions.  

Section 6.2 says " The path validation algorithm describes the process of
validating a single certification path".

Currently, the text for section 6.1. is for a single anchor while the text
for section 6.2 is for more than one anchor.

"An implementation that supports multiple trust anchors may augment the
algorithm presented in section 6.1 to further limit the set of valid paths
which begin with a particular trust anchor."

You are proposing that the text from section 6.1 describes the "basic"
algorithm, while the text from section 6.2. describes enhancements to the
basic algorihm. I would not be opposed to your proposal, ... but many text
changes would be required. 

Denis 

> -Steve
> 
> Denis Pinkas wrote:
> >
> > One topic per message: This one about applying constraints to the path
> > validation algorithm.
> >
> > In section 6.2 we now have:
> >
> >    The path validation algorithm describes the process of validating a
> >    single certification path.  While each path begins with a specific
> >    trust anchor, there is no requirement that all paths validated by a
> >    particular system share a single trust anchor.  An implementation
> >    that supports multiple trust anchors may augment the algorithm
> >    prresented in section 6.1 to further limit the set of valid paths
> >
> > ...Please a single r for prresented.
> >
> >    which begin with a particular trust anchor.  For example, an
> >    implementation may specify name constraints that apply to a specific
> >    trust anchor.
> >
> > While the sentence is true in the case of multiple trust anchors it is as
> > well valid for a single one. So a similar sentence is needed in section 6.1.
> >
> > In section 6.1 the text says:
> >
> >    A particular certification path may not, however, be appropriate for
> >    all applications.  The path validation process also determines the
> >    set of certificate policies that are valid for this path, based on
> >    the certificate policies extension, policy mapping extension, policy
> >    constraints extension, and inhibit any-policy extension.
> >
> > The text should rather say:
> >
> >    An application may augment the algorithm presented in section 6.1
> >    to further limit the set of valid paths. For example, an
> >    implementation may specify additional constraints like name
> >    constraints or specific extensions that apply to the application.
> >    Therefor the conditions which are described in this section are
> >    minimum conditions. The path validation process described in this
> >    section determines the minimum conditions that are to be fulfilled
> >    by the certification path for the set of certificate policies
> >    that are valid for this path, based on the certificate policies
> >    extension, policy mapping extension, policy constraints extension,
> >    and inhibit any-policy extension, as well as for the name
> >    constraints, if any.
> >
> > The main difference between 6.1 and 6.2 is that the additional contraints
> > (policy or name constraints) apply globally to the path validation algorithm
> > when there is one trust anchor (6.1), but may apply on every trust anchor
> > where there are multiple trust anchors (6.2).
> >
> > Denis


Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA14095 for <[e-mail]>; Thu, 19 Apr 2001 09:56:47 -0700 (PDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Apr 2001 08:50:38 -0700 (Pacific Daylight Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 19 Apr 2001 08:49:01 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Thu, 19 Apr 2001 08:49:01 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Thread-Index: AcDI5oDpM+T+bk61T96eHN71ZMdeLwAAZ7Jg
From: "David Cross" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 19 Apr 2001 15:49:01.0962 (UTC) FILETIME=[41489EA0:01C0C8E8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA14096

Denis said:

-->1) There has been a thread on the mailing list where I understand
that 
   the conclusion was that a "MUST" was not appropriate and should
either 
   be replaced by a "SHOULD" or even the whole sentence should been
deleted.

I concur.  This should be changed or hopefully eliminated.

David B. Cross


 


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13379 for <[e-mail]>; Thu, 19 Apr 2001 09:49:37 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA30686; Thu, 19 Apr 2001 18:49:15 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA16990; Thu, 19 Apr 2001 18:49:04 +0200
Message-ID: <[e-mail]>
Date: Thu, 19 Apr 2001 18:48:58 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

> Tim Polk and I just got off the phone.  After a lengthy discussion, we
> propose a revision to the cRLSign discussion:

1) The only problem is that I concur with Stephen Farrel: I thought the text
was clearer first time! 

Since you do no provide any rational for having that change, only the two of
you can understand the rational. :-(

I prefer the first text unless you can explain to everybody the rational for
the change and then change the text to make that rational a little bit more
understandable. :-)

Maybe the answer to this point is in a subsequent message, but there has
been so many messages on that topic that I have not yet found the time to
look at each of them.


2) I am also sensible to the vocabulary problem raised by David Kemp when he
says: some people use CRL to refer to every instance of a CertificateList,
whereas others use CRL, ARL, ACRL, ICRL, DCRL, etc. to distinguish lists
used for different purposes.  Thus CRL may be either an example of, or a
synonym for, CertificateList.

Which convention do we use in PKIX-1 or plan to use ?

3) One last remark that is likely to impact the wording, but before we would
need to make a distinction between an ARL and a CRL for leaf certificates:
it makes sense from a security point of view, to distinguish between an ARL
and a CRL for leaf certificates.

The key for signing CRLs containing only leaf certificates (do we have an
acronym to designate this ?) SHOULD be different from the CA issuing key. If
the key used for signing such CRLs is compromised then the CA may then
revoke the CRL Issuer using an ARL and the CA issuing key does NOT need to
be changed.

There is no advantage to have a different key for signing ARLs since if the
key used for signing ARLs is compromised then the CA issuing key MUST be
changed. So using the CA issuing key for signing ARLs is not a higher risk
and should certainly be allowed. 

Denis


>        The cRLSign bit is asserted when the subject public key is used
>        for verifying a signature on revocation information (e.g., a CRL).
>        This bit MUST be asserted in CA certificates that are used to
>        verify signatures on CRLs.  If the cRLSign bit is asserted in a CA
>        certificate, then the cA bit in the basic constraints extension
>        (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
>        asserted in a non-CA certificate, then the cA bit in the basic
>        constraints extension MUST NOT be asserted.  Such non-CA
>        certificates MUST NOT be used to verify signatures on CRLs
>        containing revocation information for public key certificates;
>        however, these non-CA certificates MAY be used to verify
>        signatures on CRLs containing revocation information concerning
>        other types of certificates (e.g., attribute certificates).  If
>        neither the cRLSign bit nor the keyCertSign bit are asserted, then
>        the cA bit in the basic constraints extension MUST NOT be
>        asserted.
> 
> Hey, this section was only one sentence in RFC 2459...
> 
> Please let us know if anyone has any remaining concerns.
> 
> Russ
> 
> At 09:25 AM 4/18/2001 -0400, Russ Housley wrote:
> >Based on this discussion, I think that the working group wants the
> >keyCertSign and cRLSign key usage text to read as follows:
> >
> >       The keyCertSign bit is asserted when the subject public key is
> >       used for verifying a signature on public key certificates.  This
> >       bit MUST only be asserted in CA certificates.  If the keyCertSign
> >       bit is asserted, then the cA bit in the basic constraints
> >       extension (see 4.2.1.10) MUST also be asserted.  If neither the
> >       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> >       The cRLSign bit is asserted when the subject public key is used
> >       for verifying a signature on certificate revocation lists (CRLs).
> >       This bit MUST only be asserted in CA certificates and Attribute
> >       Authority (AA) certificates.  If the cRLSign bit is asserted in a
> >       CA certificate, then the cA bit in the basic constraints extension
> >       (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
> >       asserted in an AA certificate, then the cA bit in the basic
> >       constraints extension MUST NOT be asserted.  If neither the
> >       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> >Let me know if you disagree.
> >
> >Russ
> >
> >At 02:31 PM 4/17/2001 +0100, Stephen Farrell wrote:
> >
> >>I'd also go along with Jim here - that an AA be allowed to
> >>have cRLSign set without having cA set in basicConstraints,
> >>i.e. that AA's be an exception to the general rule for EE's
> >>and that this be explicitly called out in son-of-2459. I'm
> >>assuming that keyCertSign is therefore not set for AA's too
> >>(and the text for keyCertSign shouldn't say "certificates",
> >>but "public key certificates").
> >>
> >>Stephen.
> >>
> >>Jim Schaad wrote:
> >> >
> >> > Russ,
> >> >
> >> > > -----Original Message-----
> >> > > From: Russ Housley [mailto:[e-mail]]
> >> > > Sent: Monday, April 16, 2001 10:33 AM
> >> > > To: [e-mail]
> >> > > Cc: [e-mail]
> >> > > Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
> >> > >
> >> > >
> >> > > Jim:
> >> > >
> >> > > >1. As currently written in section 4.2.1.3, it is not
> >> > > possible for a non-CA
> >> > > >CRL issuer to be created for attribute certificates.  Was
> >> > > this the final
> >> > > >resolution of this issue?  This seems to me to be
> >> > > problematic as it means as
> >> > > >an end-user one can issue an attribute certificate, but one
> >> > > must always use
> >> > > >a different agent, which is a CA, to issue the CRLs.  This
> >> > > means that all
> >> > > >attribute CRL issuers are indirect.
> >> > >
> >> > > I do not recall a consensus on this point.  Should an AA that
> >> > > supports CRLs
> >> > > have the cRLSign bit set in its public key certificate?  If
> >> > > so, this text
> >> > > must change.
> >> >
> >> > I don't recall anything except private discussions on this issue.  It is
> >> > here for the mailing list to comment on.
> >> >
> >> > It is my option that an AA that supports CRLs SHOULD have the cRLSign bit
> >> > set.  Either that or we ask X509 to create AACertSign and AACrlSign
> >> bits and
> >> > keep this current text as is.
> >> >
> >> > >
> >> > > >2. Section 4.2.1.3, paragraph last:  Current Text: "set in
> >> > > An instantiation"
> >> > > >modify to "set in an instantiation".
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >3. Section 6.2 paragraph 2: change "prresented" to "presented"
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >4. Section 6.2 paragraph 2:  The text "For example, an
> >> > > implementation may
> >> > > >specify name constraints that apply to a specific trust
> >> > > anchor." is diffcult
> >> > > >for me given that the validation algorithm explicitly states
> >> > > that name
> >> > > >constraints are not applied to self signed certificates. Suggest "For
> >> > > >example, an implemenation may modify the algorithm to apply
> >> > > name constaints
> >> > > >during the initialization phase."
> >> > >
> >> > > Self-signed certificates are a common mechanism for
> >> > > distributing public
> >> > > keys for trust anchors, but they are not a mandated
> >> > > mechanism.  That said,
> >> > > I think that your text it an improvement.   How about a hybrid:
> >> > >
> >> > >     For example, an implementation MAY modify the algorithm
> >> > >     to apply name constraints to a specific trust anchor
> >> > >     during the initialization phase.
> >> >
> >> > I have no problems with this new text.
> >> >
> >> > >
> >> > > >5. ASN module:
> >> > > >part1a.asn(352) : warning XXXXX: The imported symbol 'id-ad' is never
> >> > > >referenced
> >> > >
> >> > > Agree. I removed it.
> >> > >
> >> > > Russ
> >> > >
> >> > >
> >> >
> >> > jim
> >>
> >>--
> >>____________________________________________________________
> >>Stephen Farrell
> >>Baltimore Technologies,   tel: (direct line) [phone]
> >>39 Parkgate Street,                     fax: [phone]
> >>Dublin 8.                mailto:[e-mail]
> >>Ireland                             http://www.baltimore.com


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13044 for <[e-mail]>; Thu, 19 Apr 2001 09:47:34 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id MAA12146 for <[e-mail]>; Thu, 19 Apr 2001 12:47:35 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 19 Apr 2001 12:47:31 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: delta-CRLs (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Denis,

There seems to be some confusion about the way that delta-CRLs work. I will try to clarify things with my responses in-line below.

At 05:32 PM 4/19/01 +0200, Denis Pinkas wrote:
>In the third paragraph the first sentence (still) says:
>
>    When a conforming CA issues a delta CRL, the CA MUST also issue a CRL

I must admit that I am not a big fan of this requirement. From my point of view, there are both advantages and disadvantages to issuing a full CRL whenever a delta-CRL is issued. The advantage is that clients that can not process delta-CRLs can always obtain the same status information as those than can process delta-CRLs. The disadvantage is that it imposes a burden of uploading full CRLs to repositories more often than may be necessary. On the other hand, just because the CA issues the full CRLs, this does not mean that clients must retrieve them.

In the end, though, it is mostly a policy decision. If you want to provide the same support to clients that can not process delta-CRLs as to those that can, you must issue a full CRL whenever you issue a delta-CRL. I think the decision should be left to CRL issuers, but will not complain if PKIX remains as it is.

>3) The text says:
>
>    An application can construct a CRL that is complete for a given
>    scope, at the current time, in either of the following ways:
>
>       (a) by retrieving the current delta CRL for that scope, and
>       combining it with an issued CRL that is complete for that scope
>       and that has a cRLNumber greater than or equal to the cRLNumber of
>       the base CRL referenced in the delta CRL; or
>
>       (b) by retrieving the current delta CRL for that scope and
>       combining it with a locally constructed CRL whose cRLNumber is
>       greater than or equal to the cRLNumber of the base CRL referenced
>       in the current delta CRL.
>
>  a) It is hard to understand in which case the base CRL may have a 
>     cRLNumber *greater than* the cRLNumber of the base CRL referenced 
>     in the delta CRL. I certainly miss something here. The equality case
>     is easy to understand. The "greater than" case is much harder. 
>     Is it really needed ?
>
>  b) the case of a locally constructed CRL is quite stange and it is 
>     questionnable why this case is being mentioned. In the following fix, 
>     that case has been deleted.

If you want a detailed description on this, you could read my paper on delta-CRLs, http://csrc.nist.gov/pki/documents/sliding_window.pdf, but I'll try to briefly explain here.

Suppose that delta-CRLs are issued once an hour. For example, suppose that a base CRL, CRL number 5, was issued at midnight and that every hour for the next 24 hours, delta-CRLs were issued with a BaseCRLNumber of 5. If a relying party performs its first validation at 3:10am, it would the full CRL issued at midnight and the delta-CRL issued at 3:00am (CRL number 8). It would combine these to construct full CRL number 8. In this case, the CRL number of the full CRL used in combination with the delta-CRL would be the same as the BaseCRLNumber in that delta-CRL.

A few hours later, at 6:30am, the relying party performs another validation. The relying party has, in its local cache, the contents of CRL number 8 (which it constructed at 3:10am). It wants to update the information in its local case to based on the newly available revocation information. So, it obtains the latest delta-CRL. This delta-CRL has a CRL number of 11 and a BaseCRLnumber of 5. Since it has a BaseCRLNumber of 5, the delta-CRL provides status information for all certificates whose status has changed since CRL number 5 was issued. (midnight). So, clearly the delta-CRL provides status information for all certificates whose status has changed since 3:00am when CRL number 8 was issued. Thus, the relying party can combine the delta-CRL with its locally cached version of full CRL number 8 to obtain the contents of CRL number 11. This is a case where the CRL number of the complete CRL used is greater than the BaseCRLNumber specified in the delta-CRL.

There are other reasons why the two numbers may not match, but I will not go into them. If you are interested, you can read my paper.

>Finally we should explain what happens at the boundaries, i.e. when a CA
>decides to generate a (new) base CRL. Here is a text proposal:
>
>   When issuing a base CRL that supports a delta-CRL mechanism then the 
>   CRL Issuer MUST at the same time issue a delta CRL that points to that 
>   base CRL. This first delta CRL will usually be empty (or will include 
>   last-minute additions to the base CRL).

This is not acceptable. The rule is that when a base CRL is issued a delta-CRL must be issued that has the same cRLNumber. The base CRL referenced by the delta must either be the previously issued base CRL or a base CRL issued before that one. Since the new base and the delta must have the same cRLNumber, there can be no differences as a result of "last-minute additions to the base CRL".

>Suppose we issue a base CRL every midnight. The question is whether we
>should issue a delta and, if yes, does this delta refer to the previous
>base or to the new one ?

The delta must refer either to the previous base or a base issued before the previous base.

>Suppose it refers to the previous one. According to the current sentence:
>"The constructed CRL has the CRL number specified in the CRL number
>extension found in the delta CRL used in its construction.", it is
>impossible. If that was the case the delta CRL would have a CRL number equal
>to the base CRL and it is not allowed for two CRLs to have the same CRL
>number.

I think you are confusing two different extensions. The deltaCRLIndicator extension contains a BaseCRLNumber which is used to determine against which base CRLs the delta-CRL can be applied. The cRLNumber extension specifies the CRL number of the full CRL that will be generated by applying the delta-CRL to a base CRL. The sentence above states that the CRL number of the constructed CRL is taken from the cRLNumber extension, not the BaseCRLNumber of the deltaCRLIndicator extension.





Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA12203 for <[e-mail]>; Thu, 19 Apr 2001 09:37:12 -0700 (PDT)
Received: from 157.54.9.108 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Apr 2001 09:30:16 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 19 Apr 2001 09:30:09 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 19 Apr 2001 09:30:09 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Apr 2001 09:29:50 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Dedicated CRL signing keys
Date: Thu, 19 Apr 2001 09:29:49 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Dedicated CRL signing keys
Thread-Index: AcDI4xGqYvA/uF2bR/WOkoeOod7CHgACUOEw
From: "Trevor Freeman" <[e-mail]>
To: "Bengt Ohlsson" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 19 Apr 2001 16:29:50.0302 (UTC) FILETIME=[F49BA7E0:01C0C8ED]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA12205

Bengt,
Theorizing what could be possible, do not change that support for these
semantics is not mandatory under this profile, which means we are trying
to establish how that client fails gracefully with some kind of
meaningful error
Trevor
-----Original Message-----
From: Bengt Ohlsson [mailto:[e-mail]] 
Sent: Thursday, April 19, 2001 8:10 AM
To: Trevor Freeman; Russ Housley
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys

Trevor and Russ,

I don't see why the clients should fail to verify the signature
on the CRL. Assume a CA uses separate keys, same DN,
for certificate signing and CRL signing and sets the
AuthorityKeyIdentifier extension in both the certificates
and the CRLs. Then PKIX compliant clients should be able
to build the correct certificate chains for verifying both the
certificates and the CRLs.

The legislation may require the CA keys to be stored in
hardware without any copies. If you lose a key due to HW
failure you will probaly want to continue to issue the CRLs
with a new key and the same DN.

This requires the clients to handle the AKI extension to be
able to verify the signature on the new CRLs. This is a
small requirement compared to handle indirect CRLs if
you must change the DN.

Bengt

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: den 19 april 2001 01:40
To: Russ Housley
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys


Hi Russ,
That addresses my concerns. A pkix compliant client can now be
reasonability expected to fail with a more informative error, and the
problem should be in people's faces since the CRL contains a critical
extension.
Trevor

-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Wednesday, April 18, 2001 2:08 PM
To: Trevor Freeman
Cc: [e-mail]
Subject: Re: Dedicated CRL signing keys

Trevor:

I propose the following solution that builds on the Indirect CRL 
capabilities that are already available.  When a CA wants to employ 
separate private keys to sign certificates and CRLs, then that CA MUST 
delegate CRL signing to a separate authority.  That separate authority
MUST 
have a different Distinguished Name that the CA, but it could be
operated 
by the same organization.  In this way, the IDP CRL extension would flag

the "unusual" circumstances.  Clients that do not support Indirect CRLs
can 
fail gracefully (unsupported optional feature), and clients that support

Indirect CRLs can happily handle the certificates and CRLs.

Thoughts?

Russ

At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
>There has been some discussion regarding the proposal to have CRLs
>signed with CA keys which do not also sign certificates. Since this
will
>not be a mandatory to implement feature, I am concerned about the
impact
>on pkix compliant clients who encounter CRL signed in this way, and how
>we expect them to behave. What seem unacceptable with the current
>proposal is that the signage check on the CRL will fail, and the client
>will have little clue as to why and if this failure is expected. The
>information in the chain, while present, is in the CAs certificate, is
>difficult to find and subtle so would be easily missed by someone
>debugging this problem. I would like to see some clearer indication in
a
>critical extension in the CRL itself that would indicate what was going
>on. In expressing these semantics in a critical extension, we maintain
>the principal that if you don't understand the extension, the client
>knows to fail due to its own inadequacies and that failure is by
design,
>therefore allowing the client's to return an error unsupported option
>rather than invalid signature.
>Trevor


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA11614 for <[e-mail]>; Thu, 19 Apr 2001 09:31:05 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA13727 for <[e-mail]>; Thu, 19 Apr 2001 12:30:37 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Thu, 19 Apr 2001 12:28:55 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:
> 
>  b) the case of a locally constructed CRL is quite stange and it is
>     questionnable why this case is being mentioned. In the following fix,
>     that case has been deleted.


Denis,

The case of a locally-constructed CRL is necessary, and must not be
forbidden.  If you assume:

 1) certificates are valid for two years
 2) delta CRLs are issued every hour
 3) delta CRLs are based on the most recently issued full CRL
 4) relying parties download every full CRL

and calculate revocation bandwidth as a function of full CRL issuance
period, you will find that the minimum bandwidth occurs at some very long
interval (greater than 30 days).  This is because full CRLs are much
larger than deltas, and as the interval goes up, the bytes per day of
full CRLs goes down and the bytes per day for deltas goes up, until they
are balanced.

If you discard assumption 4 and allow relying parties to construct a
running revocation state database exclusively from delta CRLs, the
minimum bandwidth occurs at a much shorter interval (one hour in the limit,
but 24 hours may be acceptably close to the minimum).  Depending on
CRL population and revocation rate, the bandwidth difference between
delta+full and delta-only can be several orders of magnitude.

Relying parties must be permitted to maintain revocation state using
only delta CRLs and (very) infrequent full CRLs.

Dave


Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA11400 for <[e-mail]>; Thu, 19 Apr 2001 09:30:10 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06952; Thu, 19 Apr 2001 09:30:11 -0700 (PDT)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09796; Thu, 19 Apr 2001 12:30:09 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 19 Apr 2001 12:26:03 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It is certainly true that specifying name constraints for trust anchors
will work when a single trust anchor is used. Perhaps the sentence in
section 6.2 should be changed to say "Implementations may also augment
the algorithm presented in section 6.1 to further limit the set of valid
paths which begin with a particular trust anchor."

However, I object to adding support for limits on trust anchors to
section 6.1. The algorithm in section 6.1 is the "basic" algorithm that
everyone MUST implement. Section 6.2 describes various ways to extend
that algorithm. Multiple trust anchors is one. Limits on trust anchors
is a second. PEM compatible processing is a third. If one argues that
limits on trust anchors should be described in section 6.1, one could
equally argue that PEM compatible processing should be described in
section 6.1.

-Steve

Denis Pinkas wrote:
> 
> One topic per message: This one about applying constraints to the path
> validation algorithm.
> 
> In section 6.2 we now have:
> 
>    The path validation algorithm describes the process of validating a
>    single certification path.  While each path begins with a specific
>    trust anchor, there is no requirement that all paths validated by a
>    particular system share a single trust anchor.  An implementation
>    that supports multiple trust anchors may augment the algorithm
>    prresented in section 6.1 to further limit the set of valid paths
> 
> ...Please a single r for prresented.
> 
>    which begin with a particular trust anchor.  For example, an
>    implementation may specify name constraints that apply to a specific
>    trust anchor.
> 
> While the sentence is true in the case of multiple trust anchors it is as
> well valid for a single one. So a similar sentence is needed in section 6.1.
> 
> In section 6.1 the text says:
> 
>    A particular certification path may not, however, be appropriate for
>    all applications.  The path validation process also determines the
>    set of certificate policies that are valid for this path, based on
>    the certificate policies extension, policy mapping extension, policy
>    constraints extension, and inhibit any-policy extension.
> 
> The text should rather say:
> 
>    An application may augment the algorithm presented in section 6.1
>    to further limit the set of valid paths. For example, an
>    implementation may specify additional constraints like name
>    constraints or specific extensions that apply to the application.
>    Therefor the conditions which are described in this section are
>    minimum conditions. The path validation process described in this
>    section determines the minimum conditions that are to be fulfilled
>    by the certification path for the set of certificate policies
>    that are valid for this path, based on the certificate policies
>    extension, policy mapping extension, policy constraints extension,
>    and inhibit any-policy extension, as well as for the name
>    constraints, if any.
> 
> The main difference between 6.1 and 6.2 is that the additional contraints
> (policy or name constraints) apply globally to the path validation algorithm
> when there is one trust anchor (6.1), but may apply on every trust anchor
> where there are multiple trust anchors (6.2).
> 
> Denis


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA09804 for <[e-mail]>; Thu, 19 Apr 2001 09:10:10 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2LAW5J94; Thu, 19 Apr 2001 09:05:32 -0700
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Cc: "Tim Polk" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Dedicated CRL signing keys
Date: Thu, 19 Apr 2001 09:10:31 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>

Tim, Russ and Juergen,

I agree that CRL signature checks following CA key changeover
need to work properly.  This could be done via the same
"new-with-old" certificate that extends the RP's trust to the
new CA keypair.  But why can't it also be done via an IDP extension
in a CRL signed with the soon-to-be-retired CA private key?  I echo
Juergen's question.  Russ, why must the DN be different?


Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation



-----Original Message-----
From: Tim Polk [mailto:[e-mail]]
Sent: Thursday, April 19, 2001 8:41 AM
To: [e-mail]
Cc: Russ Housley; Trevor Freeman
Subject: Re: Dedicated CRL signing keys


Folks,

When we discussed this solution offline yesterday, I was enthusiastic.  It
appeared to resolve a problem using the tools we already have available.

However, upon further reflection, this proposal creates as many problems as
it resolves.

Consider a CA that issues certificates and CRLs under using key pair "A"
for three years, then switches to key pair "B" for the next three
years.  In this case, the CA does not maintain private key "A" after the
rollover certificates are issued.

Under the proposed solution, the CA would have to change its name, since it
was going to issue CRLs under a different key pair than the certificates
were issued under.  Even worse, there would be no way to insert the CDP
with the new name in the old certificates.

I think our solution ... isn't.  Sigh.

Tim Polk

At 05:07 PM 4/18/01 -0400, Russ Housley wrote:
>Trevor:
>
>I propose the following solution that builds on the Indirect CRL
>capabilities that are already available.  When a CA wants to employ
>separate private keys to sign certificates and CRLs, then that CA MUST
>delegate CRL signing to a separate authority.  That separate authority
>MUST have a different Distinguished Name that the CA, but it could be
>operated by the same organization.  In this way, the IDP CRL extension
>would flag the "unusual" circumstances.  Clients that do not support
>Indirect CRLs can fail gracefully (unsupported optional feature), and
>clients that support Indirect CRLs can happily handle the certificates and
>CRLs.
>
>Thoughts?
>
>Russ
>
>At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
>>There has been some discussion regarding the proposal to have CRLs
>>signed with CA keys which do not also sign certificates. Since this will
>>not be a mandatory to implement feature, I am concerned about the impact
>>on pkix compliant clients who encounter CRL signed in this way, and how
>>we expect them to behave. What seem unacceptable with the current
>>proposal is that the signage check on the CRL will fail, and the client
>>will have little clue as to why and if this failure is expected. The
>>information in the chain, while present, is in the CAs certificate, is
>>difficult to find and subtle so would be easily missed by someone
>>debugging this problem. I would like to see some clearer indication in a
>>critical extension in the CRL itself that would indicate what was going
>>on. In expressing these semantics in a critical extension, we maintain
>>the principal that if you don't understand the extension, the client
>>knows to fail due to its own inadequacies and that failure is by design,
>>therefore allowing the client's to return an error unsupported option
>>rather than invalid signature.
>>Trevor
>



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA08114 for <[e-mail]>; Thu, 19 Apr 2001 08:46:32 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA38934 for <[e-mail]>; Thu, 19 Apr 2001 17:46:10 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA12168 for <[e-mail]>; Thu, 19 Apr 2001 17:45:59 +0200
Message-ID: <[e-mail]>
Date: Thu, 19 Apr 2001 17:45:55 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

One topic per message: This one about applying constraints to the path
validation algorithm.

In section 6.2 we now have:

   The path validation algorithm describes the process of validating a
   single certification path.  While each path begins with a specific
   trust anchor, there is no requirement that all paths validated by a
   particular system share a single trust anchor.  An implementation
   that supports multiple trust anchors may augment the algorithm
   prresented in section 6.1 to further limit the set of valid paths

...Please a single r for prresented.

   which begin with a particular trust anchor.  For example, an
   implementation may specify name constraints that apply to a specific
   trust anchor.


While the sentence is true in the case of multiple trust anchors it is as
well valid for a single one. So a similar sentence is needed in section 6.1.

In section 6.1 the text says:

   A particular certification path may not, however, be appropriate for
   all applications.  The path validation process also determines the
   set of certificate policies that are valid for this path, based on
   the certificate policies extension, policy mapping extension, policy
   constraints extension, and inhibit any-policy extension. 

The text should rather say:

   An application may augment the algorithm presented in section 6.1
   to further limit the set of valid paths. For example, an
   implementation may specify additional constraints like name 
   constraints or specific extensions that apply to the application. 
   Therefor the conditions which are described in this section are 
   minimum conditions. The path validation process described in this 
   section determines the minimum conditions that are to be fulfilled 
   by the certification path for the set of certificate policies 
   that are valid for this path, based on the certificate policies 
   extension, policy mapping extension, policy constraints extension, 
   and inhibit any-policy extension, as well as for the name 
   constraints, if any. 

The main difference between 6.1 and 6.2 is that the additional contraints
(policy or name constraints) apply globally to the path validation algorithm
when there is one trust anchor (6.1), but may apply on every trust anchor
where there are multiple trust anchors (6.2).

Denis


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA07619 for <[e-mail]>; Thu, 19 Apr 2001 08:42:38 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id LAA21887; Thu, 19 Apr 2001 11:42:39 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 19 Apr 2001 11:40:47 -0400
To: <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: Dedicated CRL signing keys
Cc: Russ Housley <[e-mail]>, "Trevor Freeman" <[e-mail]>
In-Reply-To: <[e-mail]. com>
References: <[e-mail] .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,

When we discussed this solution offline yesterday, I was enthusiastic.  It 
appeared to resolve a problem using the tools we already have available.

However, upon further reflection, this proposal creates as many problems as 
it resolves.

Consider a CA that issues certificates and CRLs under using key pair "A" 
for three years, then switches to key pair "B" for the next three 
years.  In this case, the CA does not maintain private key "A" after the 
rollover certificates are issued.

Under the proposed solution, the CA would have to change its name, since it 
was going to issue CRLs under a different key pair than the certificates 
were issued under.  Even worse, there would be no way to insert the CDP 
with the new name in the old certificates.

I think our solution ... isn't.  Sigh.

Tim Polk

At 05:07 PM 4/18/01 -0400, Russ Housley wrote:
>Trevor:
>
>I propose the following solution that builds on the Indirect CRL 
>capabilities that are already available.  When a CA wants to employ 
>separate private keys to sign certificates and CRLs, then that CA MUST 
>delegate CRL signing to a separate authority.  That separate authority 
>MUST have a different Distinguished Name that the CA, but it could be 
>operated by the same organization.  In this way, the IDP CRL extension 
>would flag the "unusual" circumstances.  Clients that do not support 
>Indirect CRLs can fail gracefully (unsupported optional feature), and 
>clients that support Indirect CRLs can happily handle the certificates and 
>CRLs.
>
>Thoughts?
>
>Russ
>
>At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
>>There has been some discussion regarding the proposal to have CRLs
>>signed with CA keys which do not also sign certificates. Since this will
>>not be a mandatory to implement feature, I am concerned about the impact
>>on pkix compliant clients who encounter CRL signed in this way, and how
>>we expect them to behave. What seem unacceptable with the current
>>proposal is that the signage check on the CRL will fail, and the client
>>will have little clue as to why and if this failure is expected. The
>>information in the chain, while present, is in the CAs certificate, is
>>difficult to find and subtle so would be easily missed by someone
>>debugging this problem. I would like to see some clearer indication in a
>>critical extension in the CRL itself that would indicate what was going
>>on. In expressing these semantics in a critical extension, we maintain
>>the principal that if you don't understand the extension, the client
>>knows to fail due to its own inadequacies and that failure is by design,
>>therefore allowing the client's to return an error unsupported option
>>rather than invalid signature.
>>Trevor
>



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA06770 for <[e-mail]>; Thu, 19 Apr 2001 08:33:12 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA35798 for <[e-mail]>; Thu, 19 Apr 2001 17:32:49 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA06082 for <[e-mail]>; Thu, 19 Apr 2001 17:32:38 +0200
Message-ID: <[e-mail]>
Date: Thu, 19 Apr 2001 17:32:35 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id IAA06771

One topic per message: This one about delta-CRLs (section 5.2.4).

In the third paragraph the first sentence (still) says:

   When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
   that is complete for the given scope.  

1) There has been a thread on the mailing list where I understand that 
   the conclusion was that a "MUST" was not appropriate and should either 
   be replaced by a "SHOULD" or even the whole sentence should been deleted.

2) The text is also misleading while speaking of "the" delta-CRL since at
   one time there will be many delta-CRLs in a repository and the basic 
   question is to know which one to use. The document offers no guidance on 
   that topic, but it should.

3) The text says:

   An application can construct a CRL that is complete for a given
   scope, at the current time, in either of the following ways:

      (a) by retrieving the current delta CRL for that scope, and
      combining it with an issued CRL that is complete for that scope
      and that has a cRLNumber greater than or equal to the cRLNumber of
      the base CRL referenced in the delta CRL; or

      (b) by retrieving the current delta CRL for that scope and
      combining it with a locally constructed CRL whose cRLNumber is
      greater than or equal to the cRLNumber of the base CRL referenced
      in the current delta CRL.

 a) It is hard to understand in which case the base CRL may have a 
    cRLNumber *greater than* the cRLNumber of the base CRL referenced 
    in the delta CRL. I certainly miss something here. The equality case
    is easy to understand. The "greater than" case is much harder. 
    Is it really needed ?

 b) the case of a locally constructed CRL is quite stange and it is 
    questionnable why this case is being mentioned. In the following fix, 
    that case has been deleted.


4) The FreshestRL extension is described without sufficient explanations
   to understand the use of that extension. So I propose the following 
   for section 5.2.6. Add : 

   "This extension MUST be present when a delta CRL mechanism is
    supported for that CRL."

To solve the first three concerns I propose to replace the third and fourth
paragraphs of section 5.2.4. by :

   The Delta CRL Indicator in a delta CRL and the CRL number from 
   a complete CRL MUST contain the same value so that they can be 
   associated. When a delta CRL is issued, it MUST cover the same
   set of reasons and the same set of certificates that were covered 
   by the base CRL it references.
 
   An application can construct a CRL that is the most current for 
   a given scope, at the current time, by retrieving the current 
   base CRL for that scope, and combining it with a delta-CRL which 
   contains a Delta CRL Indicator equal to the cRLNumber of the base 
   CRL and where the current date from that delta-CRL is between 
   thisUpdate and nextUpdate; or

... then the text continues with:

   The constructed CRL has the CRL number specified in the CRL number
   extension found in the delta CRL used in its construction.

Finally we should explain what happens at the boundaries, i.e. when a CA
decides to generate a (new) base CRL. Here is a text proposal:

  When issuing a base CRL that supports a delta-CRL mechanism then the 
  CRL Issuer MUST at the same time issue a delta CRL that points to that 
  base CRL. This first delta CRL will usually be empty (or will include 
  last-minute additions to the base CRL).


Since I have had private exchanges with both Tim Polk and David Cooper
from NIST, on that topic the following explanations are primarily for them:

Suppose we issue a base CRL every midnight. The question is whether we
should issue a delta and, if yes, does this delta refer to the previous
base or to the new one ?

Suppose it refers to the previous one. According to the current sentence:
"The constructed CRL has the CRL number specified in the CRL number
extension found in the delta CRL used in its construction.", it is
impossible. If that was the case the delta CRL would have a CRL number equal
to the base CRL and it is not allowed for two CRLs to have the same CRL
number. So only the other case remains: when a base CRL is issued an usually 
empty delta CRL must also be issued. At a first glance this does not seem to 
be optimum, but it is ! The algorithm remains unchanged whatever the time of
the day may be. When a base CRL contains the freshest CRLextension this
means that a delta mechanism is supported. If the application is wishing to
take advantage of the freshest information, then it MUST find a CRL where
both the delta refers to that CRL number and where the current date is
between thisUpdate and nextUpdate.

An alternative would be to support another extension saying "by the way, do
not look for any delta during the next hour". This is a solution that we 
should not promote for three good reasons:

1° this is yet-another-extension;
2° this changes the basic algorithm;
3° the optimization would be for the first delta only. If a delta is issued 
   every hour and a base once a day, then the optimization is only for one 
   hour (e.g. between midnight and one o'clock) and not for the remaining 
   23 hours.


Regards,

Denis


Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA05745 for <[e-mail]>; Thu, 19 Apr 2001 08:24:13 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA354458; Thu, 19 Apr 2001 11:22:13 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id LAA10058; Thu, 19 Apr 2001 11:18:34 -0400
Importance: Normal
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
To: Stephen Kent <[e-mail]>
Cc: "Michael Myers" <[e-mail]>, <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 19 Apr 2001 11:23:30 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 04/19/2001 11:23:38 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     Are there Key Purpose ID's defined for AA's and for OCSP responders
anywhere other than new-part1, where they don't exist?  If not, shouldn't
there be, and shouldn't we recommend that the PKC's for such entities
SHOULD contain them?  I think it's probably a little late for MUST.
     We also might want a separate Key Purpose ID for signing CRL's for
AA's only.

          Tom Gindin


Stephen Kent <[e-mail]> on 04/19/2001 10:40:37 AM

To:   "Michael Myers" <[e-mail]>
cc:   <[e-mail]>
Subject:  RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments



At 9:34 PM -0700 4/18/01, Michael Myers wrote:
>Steve,
>
>>  -----Original Message-----
>>  From: Stephen Kent [mailto:[e-mail]]
>>  Sent: Wednesday, April 18, 2001 4:18 PM
>>
>>  . . .
>>  . . .  Nowhere in X.509 or in previous PKIX
>>  documents has there ever been text to suggest
>>  that other than a CA can sign a CRL for a
>>  public key certificate.
>
>I take it you mean CA as an entity vs. CA as the key the signed the
>certificate.

yes.

>
>>  Also, in responde to other messages I've just been reading, I want to
>>  pont out that OCSP responses are not CRLs . . .
>
>But one could (in fact it is being done) use OCSP to functionally replace
>CRLs.

yes, one could, but the name for the bit is specific to CRLs, not to
any revocation status mechanism that exists or might exist in the
future.

Steve





Received: from internet.across ([213.212.5.232]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA03498 for <[e-mail]>; Thu, 19 Apr 2001 08:11:32 -0700 (PDT)
Received: FROM acrossw02.acrosswireless.com BY internet.across ; Thu Apr 19 17:16:12 2001 +0200
Received: by acrossw02.acrosswireless.com with Internet Mail Service (5.5.2650.21) id <2LFZB4YG>; Thu, 19 Apr 2001 17:10:30 +0200
Message-ID: <[e-mail]>
From: Bengt Ohlsson <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys
Date: Thu, 19 Apr 2001 17:10:25 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Trevor and Russ,

I don't see why the clients should fail to verify the signature
on the CRL. Assume a CA uses separate keys, same DN,
for certificate signing and CRL signing and sets the
AuthorityKeyIdentifier extension in both the certificates
and the CRLs. Then PKIX compliant clients should be able
to build the correct certificate chains for verifying both the
certificates and the CRLs.

The legislation may require the CA keys to be stored in
hardware without any copies. If you lose a key due to HW
failure you will probaly want to continue to issue the CRLs
with a new key and the same DN.

This requires the clients to handle the AKI extension to be
able to verify the signature on the new CRLs. This is a
small requirement compared to handle indirect CRLs if
you must change the DN.

Bengt

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: den 19 april 2001 01:40
To: Russ Housley
Cc: [e-mail]
Subject: RE: Dedicated CRL signing keys


Hi Russ,
That addresses my concerns. A pkix compliant client can now be
reasonability expected to fail with a more informative error, and the
problem should be in people's faces since the CRL contains a critical
extension.
Trevor

-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Wednesday, April 18, 2001 2:08 PM
To: Trevor Freeman
Cc: [e-mail]
Subject: Re: Dedicated CRL signing keys

Trevor:

I propose the following solution that builds on the Indirect CRL 
capabilities that are already available.  When a CA wants to employ 
separate private keys to sign certificates and CRLs, then that CA MUST 
delegate CRL signing to a separate authority.  That separate authority
MUST 
have a different Distinguished Name that the CA, but it could be
operated 
by the same organization.  In this way, the IDP CRL extension would flag

the "unusual" circumstances.  Clients that do not support Indirect CRLs
can 
fail gracefully (unsupported optional feature), and clients that support

Indirect CRLs can happily handle the certificates and CRLs.

Thoughts?

Russ

At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
>There has been some discussion regarding the proposal to have CRLs
>signed with CA keys which do not also sign certificates. Since this
will
>not be a mandatory to implement feature, I am concerned about the
impact
>on pkix compliant clients who encounter CRL signed in this way, and how
>we expect them to behave. What seem unacceptable with the current
>proposal is that the signage check on the CRL will fail, and the client
>will have little clue as to why and if this failure is expected. The
>information in the chain, while present, is in the CAs certificate, is
>difficult to find and subtle so would be easily missed by someone
>debugging this problem. I would like to see some clearer indication in
a
>critical extension in the CRL itself that would indicate what was going
>on. In expressing these semantics in a critical extension, we maintain
>the principal that if you don't understand the extension, the client
>knows to fail due to its own inadequacies and that failure is by
design,
>therefore allowing the client's to return an error unsupported option
>rather than invalid signature.
>Trevor


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02625 for <[e-mail]>; Thu, 19 Apr 2001 08:07:13 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA10535 for <[e-mail]>; Thu, 19 Apr 2001 11:06:45 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Thu, 19 Apr 2001 11:05:03 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p05010405b703d0078a43@[128.33.4.39]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

I have no preference whether in the phrase "CertificateList (e.g., CRL)"
the "e.g.," stays or goes.  Note that some people use CRL to refer
to every instance of a CertificateList, whereas others use CRL, ARL,
ACRL, ICRL, DCRL, etc. to distinguish lists used for different
purposes.  Thus CRL may be either an example of, or a synonym for,
CertificateList.

I agree that the state of the cRLSign bit is not relevant to OCSP
responses and that CertificateList is the only data structure
which requires this bit.

Dave K
 

Stephen Kent wrote:
> 
> Also, in responde to other messages I've just been reading, I want to
> pont out that OCSP responses are not CRLs, so the value of the
> cRLSign bit should not be an issue for an OCSP responder. This
> suggests that the Lation abbreviation "e.g.," is inappropriately used
> when referring to revocation status info verified using a cert with
> the cRLSign bit enabled. CRLs are the only data structures the
> validation of which is relevant to this bit.  They are not an example.
> 
> Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA01293 for <[e-mail]>; Thu, 19 Apr 2001 07:38:55 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA28004; Thu, 19 Apr 2001 10:38:40 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010400b704a8df7cbb@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 19 Apr 2001 10:40:37 -0400
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 9:34 PM -0700 4/18/01, Michael Myers wrote:
>Steve,
>
>>  -----Original Message-----
>>  From: Stephen Kent [mailto:[e-mail]]
>>  Sent: Wednesday, April 18, 2001 4:18 PM
>>
>>  . . .
>>  . . .  Nowhere in X.509 or in previous PKIX
>>  documents has there ever been text to suggest
>>  that other than a CA can sign a CRL for a
>>  public key certificate.
>
>I take it you mean CA as an entity vs. CA as the key the signed the
>certificate.

yes.

>
>>  Also, in responde to other messages I've just been reading, I want to
>>  pont out that OCSP responses are not CRLs . . .
>
>But one could (in fact it is being done) use OCSP to functionally replace
>CRLs.

yes, one could, but the name for the bit is specific to CRLs, not to 
any revocation status mechanism that exists or might exist in the 
future.

Steve


Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by above.proper.com (8.9.3/8.9.3) with SMTP id XAA21542 for <[e-mail]>; Wed, 18 Apr 2001 23:53:36 -0700 (PDT)
Received: by mystic1.trustcenter.de; id IAA04142; Thu, 19 Apr 2001 08:50:13 +0200
Received: from nodnsquery(192.168.200.233) by mystic1.trustcenter.de via smap (V5.0) id xma004138; Thu, 19 Apr 01 08:49:45 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id f3J6qYI04798; Thu, 19 Apr 2001 08:52:34 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 19 Apr 2001 08:52:34 +0200
From: Juergen Brauckmann <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: Dedicated CRL signing keys
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ Housley wrote:
> I propose the following solution that builds on the Indirect CRL
> capabilities that are already available.  When a CA wants to employ
> separate private keys to sign certificates and CRLs, then that CA MUST
> delegate CRL signing to a separate authority.  That separate authority MUST
> have a different Distinguished Name that the CA, 

Why must it have a different DN?

Regards,
   Juergen


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA09178 for <[e-mail]>; Wed, 18 Apr 2001 21:36:31 -0700 (PDT)
Received: from HEATHERDALE (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f3J4Zid26765; Wed, 18 Apr 2001 21:35:44 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "David A. Cooper" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Wed, 18 Apr 2001 21:34:20 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <p05010405b703d0078a43@[128.33.4.39]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Steve,

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Wednesday, April 18, 2001 4:18 PM
>
> . . .
> . . .  Nowhere in X.509 or in previous PKIX
> documents has there ever been text to suggest
> that other than a CA can sign a CRL for a
> public key certificate.

I take it you mean CA as an entity vs. CA as the key the signed the
certificate.

> Also, in responde to other messages I've just been reading, I want to
> pont out that OCSP responses are not CRLs . . .

But one could (in fact it is being done) use OCSP to functionally replace
CRLs.

Mike



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA08377 for <[e-mail]>; Wed, 18 Apr 2001 21:05:04 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 18 Apr 2001 21:05:15 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 18 Apr 2001 21:05:15 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26PHTD>; Wed, 18 Apr 2001 21:04:08 -0700
Content-return: allowed
Date: Wed, 18 Apr 2001 21:04:00 -0700
From: Ryan Hurst <[e-mail]>
Subject: RE: Help Sought on Netscape Revocation URL causing MS Programs to	hang
To: "'Ron Segal'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Ron, Microsoft implements its revocation checking logic in a library called
cryptnet.dll, in this DLL there is an implementation of a function called
CryptVerifyRevocation. When the cryptnet.dll function is registered as a
provider to CryptVerifyRevocation it will be called when a revocation check
is requested. This DLL has had several updates and may or may not have this
behavior in all versions (What version of the OS and service pack are you
running?)

Regardless, there are several ways to work with this issue:

1. Disable revocation checking (which can be done by removing the
problematic CertVerifyRevocation provider in the registry, or at the
application level by telling the application not to check for revocation) --
Not much of a solution I know; but 5 min delay for attempting to retrieve
the CRL is insane.
2. ValiCert has a "Desktop Validator" solution that has an implementation of
the CryptVerifyRevocation call that supports OCSP, SCVP and CRLs. If you
install this plug-in you can configure it to supercede all other revocation
providers. In this configuration you would not be exposed to this problem.
However the shipping version of this product does not support automatically
retrieving CRLs based off of certificate extensions (aka CRLdp and
NetscapeRevocationURL). Instead you must configure either a default
OCSP/SCVP responder or specify a CA specify responder or CRL location. If
you would like to use OCSP we at ValiCert have a responder and the good
folks over at OpenSSL have been working on a implementation as-well.

Hope this helps,

Ryan M. Hurst

-----Original Message-----
From: Ron Segal [mailto:[e-mail]]
Sent: Wednesday, April 18, 2001 6:59 PM
To: [e-mail]
Subject: Help Sought on Netscape Revocation URL causing MS Programs to
hang


Hi Folks

If an X.509 v3 certificate contains a proprietary NetscapeRevocationURL
extension and a Microsoft program (eg
email or browser) is configured to do automatic CRL Distribution Point
Checking, then the Microsoft program will hang and timeout after about 5
minutes.

Does anybody know of a fix for this problem, e.g. a registry configuration
(no cynicism please!)?

We are aware that if a cert has both the NetscapeRevocationURL and CRL
Distribution Point
extensions, then no problem.

Your help would be greatly appreciated (and maybe you can get a job at
Baycorp!).

Very best regards

Ron

--------------
Ron Segal
Business Development Manager
Baycorp ID Services Ltd
PO Box 5052, Wellington, New Zealand

Mailto: [e-mail]
Tel:   +64 (4)  499 4231
DD:    +64 (4)  499 4261
Mob:   [phone]
Fax:   +64 (4)  499 4233
Web:   http://www.baycorpid.com



Received: from netlink.co.nz (mako.netlink.co.nz [202.20.93.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA03854 for <[e-mail]>; Wed, 18 Apr 2001 18:55:49 -0700 (PDT)
Received: from ronsnotebook (128i-cl128.netlink.net.nz [203.97.144.128]) by netlink.co.nz (8.9.3/8.9.3) with SMTP id NAA08605 for <[e-mail]>; Thu, 19 Apr 2001 13:55:51 +1200 (NZST)
From: "Ron Segal" <[e-mail]>
To: <[e-mail]>
Subject: Help Sought on Netscape Revocation URL causing MS Programs to hang
Date: Thu, 19 Apr 2001 13:59:13 +1200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0113_01C0C8D8.EA361D40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

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

Hi Folks

If an X.509 v3 certificate contains a proprietary NetscapeRevocationURL
extension and a Microsoft program (eg
email or browser) is configured to do automatic CRL Distribution Point
Checking, then the Microsoft program will hang and timeout after about 5
minutes.

Does anybody know of a fix for this problem, e.g. a registry configuration
(no cynicism please!)?

We are aware that if a cert has both the NetscapeRevocationURL and CRL
Distribution Point
extensions, then no problem.

Your help would be greatly appreciated (and maybe you can get a job at
Baycorp!).

Very best regards

Ron

--------------
Ron Segal
Business Development Manager
Baycorp ID Services Ltd
PO Box 5052, Wellington, New Zealand

Mailto: [e-mail]
Tel:   +64 (4)  499 4231
DD:    +64 (4)  499 4261
Mob:   [phone]
Fax:   +64 (4)  499 4233
Web:   http://www.baycorpid.com


------=_NextPart_000_0113_01C0C8D8.EA361D40
Content-Type: text/x-vcard;
	name="Ron Segal.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Ron Segal.vcf"

BEGIN:VCARD
VERSION:2.1
N:Segal;Ron
FN:Ron Segal
ORG:Baycorp ID Services
TITLE:Business Development Manager
TEL;WORK;VOICE:[phone]
TEL;CELL;VOICE:[phone]
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Level 1=3D0D=3D0ALandcorp =
House=3D0D=3D0A101 Lambton Quay=3D0D=3D0APO Box 5052;Welling=3D
ton;;;New Zealand
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Level 1=3D0D=3D0ALandcorp =
House=3D0D=3D0A101 Lambton Quay=3D0D=3D0APO Box 5052=3D0D=3D0AWell=3D
ington=3D0D=3D0ANew Zealand
URL:
URL:http://www.baycorpid.com
KEY;X509;ENCODING=3DBASE64:
    =
MIIGdzCCBV+gAwIBAgIEOhwthjANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJOWjEgMB4G
    =
A1UEChMXQmF5Y29ycCBJRCBTZXJ2aWNlcyBMdGQxGTAXBgNVBAsTEEJheWNvcnAgUGFzc3Bv
    =
cnQxLzAtBgNVBAMTJkJheWNvcnAgUGFzc3BvcnQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4X
    =
DTAwMTEyMjIwMzMxMFoXDTAxMTEyNzIwMzMxMFowfDELMAkGA1UEBhMCTloxCjAIBgNVBAgT
    =
AS0xEzARBgNVBAcTCldlbGxpbmd0b24xEDAOBgNVBAoTB0JheWNvcnAxEjAQBgNVBAMTCVJv
    =
biBTZWdhbDEmMCQGCSqGSIb3DQEJARYXcm9uLnNlZ2FsQGJheWNvcnBpZC5jb20wgZ8wDQYJ
    =
KoZIhvcNAQEBBQADgY0AMIGJAoGBANRQxdVFIMgxT5W45/I5HSGKPCCKfijydisE8fhqc/uh
    =
Vqn9wE+CwCMJKKgUM5pH3g+ZyTbBKjctkSDOcmuN2aNGm1EPZq1xORI6byWmd6S9jb5/I2vt
    =
IeqhWQC3MuVhrBFFuOsu1JBiGLmxaHg71ti/b97q50zA/hIOgDAuixtfAgMBAAGjggOEMIID
    =
gDAiBgkrBgEEAZtYAAEEFRYTUm9uYWxkIFNhbXVlbCBTZWdhbDAOBgNVHQ8BAf8EBAMCA/gw
    =
UQYDVR0lBEowSAYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwUGCCsG
    =
AQUFBwMGBggrBgEFBQcDBwYKKwYBBAGCNwoDBDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8v
    =
d3d3LmJheWNvcnBpZC5jb20vY3JsL3Bhc3Nwb3J0LmNybDAZBgNVHQkEEjAQMA4GA1UEBDEH
    =
EwVTZWdhbDAiBgNVHREEGzAZgRdyb24uc2VnYWxAYmF5Y29ycGlkLmNvbTCCAfIGA1UdIASC
    =
AekwggHlMIIB4QYMKwYBBAGbWAIBAgECMIIBzzCCAZoGCCsGAQUFBwICMIIBjBqCAYhUaGUg
    =
cmlnaHRzLCBvYmxpZ2F0aW9ucyBhbmQgbGlhYmlsaXRpZXMgb2YgdGhlIFN1YmplY3QsIEJh
    =
eWNvcnAgSUQgU2VydmljZXMgYW5kIGFueSByZWx5aW5nIHBhcnR5IGFyZSBzcGVjaWZpZWQg
    =
aW4gdGhlIEJheWNvcnAgUGFzc3BvcnQgQ2VydGlmaWNhdGlvbiBQcmFjdGlzZSBTdGF0ZW1l
    =
bnQuIFlvdSBtdXN0IGVuc3VyZSB0aGF0IHRoaXMgY2VydGlmaWNhdGUgaXMgbm90IHN1c3Bl
    =
bmRlZCBvciByZXZva2VkOyBjb21wbHkgd2l0aCB0aGUgc3BlY2lmaWNhdGlvbnMgaW4gaXRz
    =
IEtleSBVc2FnZSBmaWVsZDsgYWRoZXJlIHRvIEJheWNvcnAgSUQgU2VydmljZXMnIFByaXZh
    =
Y3kgUG9saWN5LiBGdXJ0aGVyIGRldGFpbCBpcyBhdmFpbGFibGUgZnJvbSBCYXljb3JwIElE
    =
IFNlcnZpY2VzOjAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5iYXljb3JwaWQuY29tL3JlcG9z
    =
aXRvcnkwOwYIKwYBBQUHAQEELzAtMCsGCCsGAQUFBzABhh9odHRwOi8vY2VydHN0YXR1cy5i
    =
YXljb3JwaWQuY29tMB8GA1UdIwQYMBaAFHlNfEwOah9O+VNsNHtQxa6cxvR+MB0GA1UdDgQW
    =
BBSQs4oU5iFIMqGm5FFzDKWqV0NDlzAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQCM
    =
mcZU4Svrle0oqf8/r080V7/KW/7aaoYk//s161jKoWUs7WfmZzbyOgUQPeIuzk3bqfD9xN2E
    =
kfDkaMiPDg5xZ8O/WKnzV2CLYDZrgyoFZ/o0ol+g1akXdAsgp3U73wk8kc7PfcpttSAQy7Mc
    =
78Ej+kaU1TUcyaqsJU6+cryb0EfixPosZpUgx8SZcx+KuRej5ZGHk0zCCsVWNS91noMlkN95
    =
ZP5fkzReeX2xrFmVfqTNawYBywrrvY4ULADRAVFrbqU4h2152KZKsALEpSFZqntLZlR8izqA
    dz/8d+u0KwTLkSPRJiWemL2iyFkU5H6qQoOLuLEQCQiRNxiblLlI


EMAIL;PREF;INTERNET:[e-mail]
REV:20010130T034848Z
END:VCARD

------=_NextPart_000_0113_01C0C8D8.EA361D40--



Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA26211 for <[e-mail]>; Wed, 18 Apr 2001 16:41:53 -0700 (PDT)
Received: from 157.54.9.104 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 18 Apr 2001 16:38:58 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 18 Apr 2001 16:40:40 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 18 Apr 2001 16:40:39 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 18 Apr 2001 16:40:20 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Dedicated CRL signing keys
Date: Wed, 18 Apr 2001 16:40:20 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Dedicated CRL signing keys
Thread-Index: AcDITFqRcQruJeOXRvCgnBY//iVDgQAEyltA
From: "Trevor Freeman" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 18 Apr 2001 23:40:20.0743 (UTC) FILETIME=[EE566970:01C0C860]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id QAA26212

Hi Russ,
That addresses my concerns. A pkix compliant client can now be
reasonability expected to fail with a more informative error, and the
problem should be in people's faces since the CRL contains a critical
extension.
Trevor

-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Wednesday, April 18, 2001 2:08 PM
To: Trevor Freeman
Cc: [e-mail]
Subject: Re: Dedicated CRL signing keys

Trevor:

I propose the following solution that builds on the Indirect CRL 
capabilities that are already available.  When a CA wants to employ 
separate private keys to sign certificates and CRLs, then that CA MUST 
delegate CRL signing to a separate authority.  That separate authority
MUST 
have a different Distinguished Name that the CA, but it could be
operated 
by the same organization.  In this way, the IDP CRL extension would flag

the "unusual" circumstances.  Clients that do not support Indirect CRLs
can 
fail gracefully (unsupported optional feature), and clients that support

Indirect CRLs can happily handle the certificates and CRLs.

Thoughts?

Russ

At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
>There has been some discussion regarding the proposal to have CRLs
>signed with CA keys which do not also sign certificates. Since this
will
>not be a mandatory to implement feature, I am concerned about the
impact
>on pkix compliant clients who encounter CRL signed in this way, and how
>we expect them to behave. What seem unacceptable with the current
>proposal is that the signage check on the CRL will fail, and the client
>will have little clue as to why and if this failure is expected. The
>information in the chain, while present, is in the CAs certificate, is
>difficult to find and subtle so would be easily missed by someone
>debugging this problem. I would like to see some clearer indication in
a
>critical extension in the CRL itself that would indicate what was going
>on. In expressing these semantics in a critical extension, we maintain
>the principal that if you don't understand the extension, the client
>knows to fail due to its own inadequacies and that failure is by
design,
>therefore allowing the client's to return an error unsupported option
>rather than invalid signature.
>Trevor



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA24415 for <[e-mail]>; Wed, 18 Apr 2001 16:16:48 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA00232; Wed, 18 Apr 2001 19:16:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010405b703d0078a43@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 18 Apr 2001 19:17:35 -0400
To: "David A. Cooper" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Dave Cooper,

>Dave,
>
>I agree with you. I see no basis in X.509 for setting the cA flag in 
>basicConstraints for certificate subjects that can issue CRLs but 
>not certificates. The current discussion about how to deal with CRLs 
>for attribute certificates vs. public key certificates just further 
>goes to show that it was a mistake to suddenly change the rules at 
>the last IETF meeting.

We disagree on this point. Nowhere in X.509 or in previous PKIX 
documents has there ever been text to suggest that other than a CA 
can sign a CRL for a public key certificate. So, the rules were not 
changed at the last meeting, they were reasserted and clarified.

Also, in responde to other messages I've just been reading, I want to 
pont out that OCSP responses are not CRLs, so the value of the 
cRLSign bit should not be an issue for an OCSP responder. This 
suggests that the Lation abbreviation "e.g.," is inappropriately used 
when referring to revocation status info verified using a cert with 
the cRLSign bit enabled. CRLs are the only data structures the 
validation of which is relevant to this bit.  They are not an example.

Steve


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA15816 for <[e-mail]>; Wed, 18 Apr 2001 14:12:37 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Apr 2001 21:09:59 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA09500; Wed, 18 Apr 2001 17:12:37 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 18 Apr 2001 17:07:37 -0400
To: "Trevor Freeman" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Dedicated CRL signing keys
Cc: <[e-mail]>
In-Reply-To: <[e-mail] .windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Trevor:

I propose the following solution that builds on the Indirect CRL 
capabilities that are already available.  When a CA wants to employ 
separate private keys to sign certificates and CRLs, then that CA MUST 
delegate CRL signing to a separate authority.  That separate authority MUST 
have a different Distinguished Name that the CA, but it could be operated 
by the same organization.  In this way, the IDP CRL extension would flag 
the "unusual" circumstances.  Clients that do not support Indirect CRLs can 
fail gracefully (unsupported optional feature), and clients that support 
Indirect CRLs can happily handle the certificates and CRLs.

Thoughts?

Russ

At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
>There has been some discussion regarding the proposal to have CRLs
>signed with CA keys which do not also sign certificates. Since this will
>not be a mandatory to implement feature, I am concerned about the impact
>on pkix compliant clients who encounter CRL signed in this way, and how
>we expect them to behave. What seem unacceptable with the current
>proposal is that the signage check on the CRL will fail, and the client
>will have little clue as to why and if this failure is expected. The
>information in the chain, while present, is in the CAs certificate, is
>difficult to find and subtle so would be easily missed by someone
>debugging this problem. I would like to see some clearer indication in a
>critical extension in the CRL itself that would indicate what was going
>on. In expressing these semantics in a critical extension, we maintain
>the principal that if you don't understand the extension, the client
>knows to fail due to its own inadequacies and that failure is by design,
>therefore allowing the client's to return an error unsupported option
>rather than invalid signature.
>Trevor



Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA12208 for <[e-mail]>; Wed, 18 Apr 2001 13:41:56 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Apr 2001 20:39:18 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA06977; Wed, 18 Apr 2001 16:41:53 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 18 Apr 2001 16:41:05 -0400
To: Sharon Boeyen <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Cc: [e-mail], "Hoyt Kesterson (E-mail)" <[e-mail]>
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
Sharon:<br>
<br>
<blockquote type=cite class=cite cite><font size=2>Russ, when I reviewed
your text, only one point came to mind. There are <br>
cases where a single authority will act as both a CA for public-key
certificates</font> <br>
<font size=2>and an AA for attribute certificates. As such, it would
issue CRLs for the <br>
public-key certs and CRLs for the attribute certs. If I'm interpreting
your <br>
text correctly, you would not permit the same certificate to indicate
both?</font> </blockquote><br>
The PKIX AC Profile explicitly forbids one entity from acting as both a
CA and an AA.&nbsp; This restriction has been in the document from the
very first draft.<br>
<br>
Russ<br>
<br>
</html>



Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA11337 for <[e-mail]>; Wed, 18 Apr 2001 13:34:06 -0700 (PDT)
Received: from 157.54.1.52 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 18 Apr 2001 13:33:29 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 18 Apr 2001 13:32:59 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 18 Apr 2001 13:32:59 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 18 Apr 2001 13:32:39 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Dedicated CRL signing keys
Date: Wed, 18 Apr 2001 13:32:39 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Dedicated CRL signing keys
Thread-Index: AcDIRsKidLRcSnAYSVedloWGQiCqFQ==
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 18 Apr 2001 20:32:39.0728 (UTC) FILETIME=[B63FE300:01C0C846]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id NAA11338

There has been some discussion regarding the proposal to have CRLs
signed with CA keys which do not also sign certificates. Since this will
not be a mandatory to implement feature, I am concerned about the impact
on pkix compliant clients who encounter CRL signed in this way, and how
we expect them to behave. What seem unacceptable with the current
proposal is that the signage check on the CRL will fail, and the client
will have little clue as to why and if this failure is expected. The
information in the chain, while present, is in the CAs certificate, is
difficult to find and subtle so would be easily missed by someone
debugging this problem. I would like to see some clearer indication in a
critical extension in the CRL itself that would indicate what was going
on. In expressing these semantics in a critical extension, we maintain
the principal that if you don't understand the extension, the client
knows to fail due to its own inadequacies and that failure is by design,
therefore allowing the client's to return an error unsupported option
rather than invalid signature.
Trevor 


Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA11209 for <[e-mail]>; Wed, 18 Apr 2001 13:32:27 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010418202957.PXOW26961.femail3.sdc1.sfba.home.com@revelation>; Wed, 18 Apr 2001 13:29:57 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Wed, 18 Apr 2001 13:35:16 -0700
Message-ID: <001201c0c847$144ae620$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C0C80C.67EC0E20"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C0C80C.67EC0E20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In that case I am happy with the originally proposed text.  The change to
the basicConstraints text is fine with me also.

jim
  -----Original Message-----
  From: Russ Housley [mailto:[e-mail]]
  Sent: Wednesday, April 18, 2001 1:00 PM
  To: [e-mail]
  Cc: [e-mail]
  Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments


  Jim:

  RFC 2459 permits OCSP responders to have the cRLSign bit set.  That is why
the most recently proposed text says "revocation information" not "CRL."

  Russ


  At 12:08 PM 4/18/2001 -0400, Santosh Chokhani wrote:

    Russ,

    Two items:

    1.  You also need to change the text on the basic constraints extension.
    2.  This text implies to me that the cRLSign bit must be set for an OCSP
    responder (it does revocation information) is that what you want?

    jim

------=_NextPart_000_0013_01C0C80C.67EC0E20
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">


<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D093483420-18042001>In=20
that case I am happy with the originally proposed text.&nbsp; The change =
to the=20
basicConstraints text is fine with me also.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D093483420-18042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D093483420-18042001>jim</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Russ Housley=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, April 18, =
2001=20
  1:00 PM<BR><B>To:</B> [e-mail]<BR><B>Cc:</B>=20
  [e-mail]<BR><B>Subject:</B> RE: Last Call:=20
  draft-ietf-pkix-new-part1-06.txt =
comments<BR><BR></DIV></FONT>Jim:<BR><BR>RFC=20
  2459 permits OCSP responders to have the cRLSign bit set.&nbsp; That =
is why=20
  the most recently proposed text says "revocation information" not=20
  "CRL."<BR><BR>Russ<BR><BR><BR>At 12:08 PM 4/18/2001 -0400, Santosh =
Chokhani=20
  wrote:<BR>
  <BLOCKQUOTE class=3Dcite cite type=3D"cite"><FONT =
size=3D2>Russ,</FONT>=20
    <BR><BR><FONT size=3D2>Two items:</FONT> <BR><BR><FONT =
size=3D2>1.&nbsp; You=20
    also need to change the text on the basic constraints =
extension.</FONT>=20
    <BR><FONT size=3D2>2.&nbsp; This text implies to me that the cRLSign =
bit must=20
    be set for an OCSP</FONT> <BR><FONT size=3D2>responder (it does =
revocation=20
    information) is that what you want?</FONT> <BR><BR><FONT =
size=3D2>jim</FONT>=20
  </BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0013_01C0C80C.67EC0E20--



Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA09218 for <[e-mail]>; Wed, 18 Apr 2001 13:05:20 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Apr 2001 20:02:42 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA04203; Wed, 18 Apr 2001 16:05:11 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 18 Apr 2001 16:00:19 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Cc: [e-mail]
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
Jim:<br>
<br>
RFC 2459 permits OCSP responders to have the cRLSign bit set.&nbsp; That
is why the most recently proposed text says &quot;revocation
information&quot; not &quot;CRL.&quot;<br>
<br>
Russ<br>
<br>
<br>
At 12:08 PM 4/18/2001 -0400, Santosh Chokhani wrote:<br>
<blockquote type=cite class=cite cite><font size=2>Russ,</font> <br>
<br>
<font size=2>Two items:</font> <br>
<br>
<font size=2>1.&nbsp; You also need to change the text on the basic
constraints extension.</font> <br>
<font size=2>2.&nbsp; This text implies to me that the cRLSign bit must
be set for an OCSP</font> <br>
<font size=2>responder (it does revocation information) is that what you
want?</font> <br>
<br>
<font size=2>jim</font> </blockquote></html>



Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA09142 for <[e-mail]>; Wed, 18 Apr 2001 13:05:13 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Apr 2001 20:02:35 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA04207; Wed, 18 Apr 2001 16:05:12 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 18 Apr 2001 16:05:07 -0400
To: <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Cc: <[e-mail]>
In-Reply-To: <000001c0c822$dbbffe90$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Jim:

>You also need to change the text on the basic constraints extension.

You are correct.  I propose:

    The cA bit indicates whether the certified public key may be used to
    verify signatures on other certificates.  If the cA bit is asserted,
    then either the keyCertSign bit or the cRLSign bit in the key usage
    extension (see 4.2.1.3) MUST also be asserted.  If the cA bit is not
    asserted, then the keyCertSign bit in the key usage extension MUST
    NOT be asserted.

Russ





Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA08048 for <[e-mail]>; Wed, 18 Apr 2001 12:55:17 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010418195248.PUPP26961.femail3.sdc1.sfba.home.com@revelation>; Wed, 18 Apr 2001 12:52:48 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>, <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Wed, 18 Apr 2001 12:58:06 -0700
Message-ID: <000b01c0c841$e3804e40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Other than changing "(e.g. CRL)" to "(CRL)" I like this below text better.
It was the "e.g." combined with the text that made me thing of non CRL ways
of doing revocation information.

jim

> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Wednesday, April 18, 2001 11:41 AM
> To: 'David P. Kemp'; [e-mail]
> Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
>
>
>
> I like this.
>
> Part of what I like about this also, is the fact that it doesn't
> prevent a non-CA from issuing indirect CRLs. I like the symmetry
> between CRL issuance and OCSP response issuance.
>
> A
>
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
>
> > -----Original Message-----
> > From: David P. Kemp [mailto:[e-mail]]
> > Sent: Wednesday, April 18, 2001 10:08 AM
> > To: [e-mail]
> > Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
> >
> >
> > P.S., my preference is to not use the cA bit to make a distinction
> > between types of CRL signers, in which case the text is
> much simpler:
> >
> >       The cRLSign bit MUST be asserted when the subject
> public key is
> >       used for verifying a signature on a CertificateList
> > (e.g., a CRL).
> >
> >       If the keyCertSign bit is asserted, then the cA bit in the
> >       basic constraints extension (see 4.2.1.10) MUST be asserted.
> >       If the keyCertSign bit is not asserted, then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> > Dave
> >
> >
>



Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA04334 for <[e-mail]>; Wed, 18 Apr 2001 11:47:54 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <2VH1AKTV>; Wed, 18 Apr 2001 14:47:25 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David A. Cooper'" <[e-mail]>, [e-mail]
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Wed, 18 Apr 2001 14:42:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C837.44EB4640"

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_01C0C837.44EB4640
Content-Type: text/plain

Hi Dave, you would use the SOAIdentifier extension (see 509 clause
15.3.2.1). 
This extension can ONLY be present in a public-key certificate issued to an
SOA. 
If an SOA wants to DELEGATE the authority to another AA to allow it to issue
attribute certs, that would be done in an attribute cert that contained the 
basicAttConstraints extension (see clause 15.5.2.1).

Sharon 

> -----Original Message-----
> From: David A. Cooper [mailto:[e-mail]]
> Sent: Wednesday, April 18, 2001 1:40 PM
> To: [e-mail]
> Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
> 
> 
> Dave,
> 
> I agree with you. I see no basis in X.509 for setting the cA 
> flag in basicConstraints for certificate subjects that can 
> issue CRLs but not certificates. The current discussion about 
> how to deal with CRLs for attribute certificates vs. public 
> key certificates just further goes to show that it was a 
> mistake to suddenly change the rules at the last IETF meeting.
> 
> I must say, though, that I am still confused about what is 
> the correct thing to do when dealing with attribute 
> certificates. If the subject of a public key certificate can 
> issue attribute certificates but not public key certificates, 
> what bits in the key usage extension should be set? My 
> understanding is that the keyCertSign bit should not be set, 
> but this seems to leave digitalSignature as the next best option.
> 
> 
> At 01:08 PM 4/18/01 -0400, David P. Kemp wrote:
> >P.S., my preference is to not use the cA bit to make a distinction
> >between types of CRL signers, in which case the text is much simpler:
> >
> >       The cRLSign bit MUST be asserted when the subject 
> public key is
> >       used for verifying a signature on a CertificateList 
> (e.g., a CRL).
> >       
> >       If the keyCertSign bit is asserted, then the cA bit in the 
> >       basic constraints extension (see 4.2.1.10) MUST be asserted.
> >       If the keyCertSign bit is not asserted, then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> >Dave
> >
> >
> >
> >"David P. Kemp" wrote:
> > > 
> > > The 9:25 AM version was clearer.  This version adds a 
> restriction on
> > > which type of authority may sign which type of revocation 
> list.  Neither
> > > version defines "CA certificate"; my impression was that
> > > 
> > >   If the cA bit is set, then the certificate *is* a CA 
> certificate,
> > > 
> > > not the backwards-sounding
> > > 
> > >   If the cRLSign bit is asserted in a CA certificate, 
> then the cA bit
> > >   MUST be asserted.
> > > 
> > > How about the following:
> > > 
> > >       The cRLSign bit is asserted when the subject public 
> key is used
> > >       for verifying a signature on a CertificateList 
> (e.g., a CRL).
> > >       If the cA bit in the basic constraints extension 
> (see 4.2.1.10)
> > >       is not asserted, then the public key MUST NOT be 
> used to verify
> > >       signatures on CRLs containing revocation 
> information for public
> > >       key certificates, however it may be used to verify 
> signatures
> > >       on CRLs containing revocation information for other types of
> > >       certificates (e.g., attribute certificates).
> > >    *  If the cA bit is asserted, then the public key MUST 
> NOT be used
> > >    *  to verify signatures on CRLs containing revocation 
> information
> > >    *  for certificates other than public key certificates.
> > > 
> > >       If the keyCertSign bit is asserted, then the cA bit 
> in the basic
> > >       constraints extension MUST be asserted.  If neither 
> the cRLSign
> > >       bit nor the keyCertSign bit are asserted, then the 
> cA bit in the
> > >       basic constraints extension MUST NOT be asserted.
> > > 
> > > The third sentence (marked ***) is new; I don't know if 
> you intended
> > > the asymmetry of allowing CAs to revoke ACs but 
> forbidding AAs from
> > > revoking PKCs.  If neither CAs nor AAs can revoke the 
> other's certs,
> > > then the third sentence is needed.
> > > 
> > > Dave
> 
> 

------_=_NextPart_001_01C0C837.44EB4640
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Dave, you would use the SOAIdentifier extension (see 509 clause 15.3.2.1). </FONT>
<BR><FONT SIZE=2>This extension can ONLY be present in a public-key certificate issued to an SOA. </FONT>
<BR><FONT SIZE=2>If an SOA wants to DELEGATE the authority to another AA to allow it to issue</FONT>
<BR><FONT SIZE=2>attribute certs, that would be done in an attribute cert that contained the </FONT>
<BR><FONT SIZE=2>basicAttConstraints extension (see clause 15.5.2.1).</FONT>
</P>

<P><FONT SIZE=2>Sharon </FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: David A. Cooper [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, April 18, 2001 1:40 PM</FONT>
<BR><FONT SIZE=2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dave,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I agree with you. I see no basis in X.509 for setting the cA </FONT>
<BR><FONT SIZE=2>&gt; flag in basicConstraints for certificate subjects that can </FONT>
<BR><FONT SIZE=2>&gt; issue CRLs but not certificates. The current discussion about </FONT>
<BR><FONT SIZE=2>&gt; how to deal with CRLs for attribute certificates vs. public </FONT>
<BR><FONT SIZE=2>&gt; key certificates just further goes to show that it was a </FONT>
<BR><FONT SIZE=2>&gt; mistake to suddenly change the rules at the last IETF meeting.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I must say, though, that I am still confused about what is </FONT>
<BR><FONT SIZE=2>&gt; the correct thing to do when dealing with attribute </FONT>
<BR><FONT SIZE=2>&gt; certificates. If the subject of a public key certificate can </FONT>
<BR><FONT SIZE=2>&gt; issue attribute certificates but not public key certificates, </FONT>
<BR><FONT SIZE=2>&gt; what bits in the key usage extension should be set? My </FONT>
<BR><FONT SIZE=2>&gt; understanding is that the keyCertSign bit should not be set, </FONT>
<BR><FONT SIZE=2>&gt; but this seems to leave digitalSignature as the next best option.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At 01:08 PM 4/18/01 -0400, David P. Kemp wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;P.S., my preference is to not use the cA bit to make a distinction</FONT>
<BR><FONT SIZE=2>&gt; &gt;between types of CRL signers, in which case the text is much simpler:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign bit MUST be asserted when the subject </FONT>
<BR><FONT SIZE=2>&gt; public key is</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for verifying a signature on a CertificateList </FONT>
<BR><FONT SIZE=2>&gt; (e.g., a CRL).</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the keyCertSign bit is asserted, then the cA bit in the </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; basic constraints extension (see 4.2.1.10) MUST be asserted.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the keyCertSign bit is not asserted, then the cA bit</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic constraints extension MUST NOT be asserted.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Dave</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&quot;David P. Kemp&quot; wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; The 9:25 AM version was clearer.&nbsp; This version adds a </FONT>
<BR><FONT SIZE=2>&gt; restriction on</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; which type of authority may sign which type of revocation </FONT>
<BR><FONT SIZE=2>&gt; list.&nbsp; Neither</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; version defines &quot;CA certificate&quot;; my impression was that</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp; If the cA bit is set, then the certificate *is* a CA </FONT>
<BR><FONT SIZE=2>&gt; certificate,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; not the backwards-sounding</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp; If the cRLSign bit is asserted in a CA certificate, </FONT>
<BR><FONT SIZE=2>&gt; then the cA bit</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp; MUST be asserted.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; How about the following:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign bit is asserted when the subject public </FONT>
<BR><FONT SIZE=2>&gt; key is used</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for verifying a signature on a CertificateList </FONT>
<BR><FONT SIZE=2>&gt; (e.g., a CRL).</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the cA bit in the basic constraints extension </FONT>
<BR><FONT SIZE=2>&gt; (see 4.2.1.10)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is not asserted, then the public key MUST NOT be </FONT>
<BR><FONT SIZE=2>&gt; used to verify</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signatures on CRLs containing revocation </FONT>
<BR><FONT SIZE=2>&gt; information for public</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; key certificates, however it may be used to verify </FONT>
<BR><FONT SIZE=2>&gt; signatures</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on CRLs containing revocation information for other types of</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificates (e.g., attribute certificates).</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; *&nbsp; If the cA bit is asserted, then the public key MUST </FONT>
<BR><FONT SIZE=2>&gt; NOT be used</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; *&nbsp; to verify signatures on CRLs containing revocation </FONT>
<BR><FONT SIZE=2>&gt; information</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; *&nbsp; for certificates other than public key certificates.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the keyCertSign bit is asserted, then the cA bit </FONT>
<BR><FONT SIZE=2>&gt; in the basic</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; constraints extension MUST be asserted.&nbsp; If neither </FONT>
<BR><FONT SIZE=2>&gt; the cRLSign</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit nor the keyCertSign bit are asserted, then the </FONT>
<BR><FONT SIZE=2>&gt; cA bit in the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; basic constraints extension MUST NOT be asserted.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; The third sentence (marked ***) is new; I don't know if </FONT>
<BR><FONT SIZE=2>&gt; you intended</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; the asymmetry of allowing CAs to revoke ACs but </FONT>
<BR><FONT SIZE=2>&gt; forbidding AAs from</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; revoking PKCs.&nbsp; If neither CAs nor AAs can revoke the </FONT>
<BR><FONT SIZE=2>&gt; other's certs,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; then the third sentence is needed.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Dave</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C837.44EB4640--


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA03896 for <[e-mail]>; Wed, 18 Apr 2001 11:41:32 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 18 Apr 2001 11:41:40 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 18 Apr 2001 11:41:40 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26P10P>; Wed, 18 Apr 2001 11:40:34 -0700
Content-return: allowed
Date: Wed, 18 Apr 2001 11:40:33 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

I like this.

Part of what I like about this also, is the fact that it doesn't
prevent a non-CA from issuing indirect CRLs. I like the symmetry
between CRL issuance and OCSP response issuance. 

A


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


> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Wednesday, April 18, 2001 10:08 AM
> To: [e-mail]
> Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
> 
> 
> P.S., my preference is to not use the cA bit to make a distinction
> between types of CRL signers, in which case the text is much simpler:
> 
>       The cRLSign bit MUST be asserted when the subject public key is
>       used for verifying a signature on a CertificateList 
> (e.g., a CRL).
>       
>       If the keyCertSign bit is asserted, then the cA bit in the 
>       basic constraints extension (see 4.2.1.10) MUST be asserted.
>       If the keyCertSign bit is not asserted, then the cA bit
>       in the basic constraints extension MUST NOT be asserted.
> 
> Dave
> 
> 


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00999 for <[e-mail]>; Wed, 18 Apr 2001 10:40:10 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id NAA22463 for <[e-mail]>; Wed, 18 Apr 2001 13:40:10 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 18 Apr 2001 13:40:08 -0400
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
In-Reply-To: <[e-mail]>
References: <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Dave,

I agree with you. I see no basis in X.509 for setting the cA flag in basicConstraints for certificate subjects that can issue CRLs but not certificates. The current discussion about how to deal with CRLs for attribute certificates vs. public key certificates just further goes to show that it was a mistake to suddenly change the rules at the last IETF meeting.

I must say, though, that I am still confused about what is the correct thing to do when dealing with attribute certificates. If the subject of a public key certificate can issue attribute certificates but not public key certificates, what bits in the key usage extension should be set? My understanding is that the keyCertSign bit should not be set, but this seems to leave digitalSignature as the next best option.


At 01:08 PM 4/18/01 -0400, David P. Kemp wrote:
>P.S., my preference is to not use the cA bit to make a distinction
>between types of CRL signers, in which case the text is much simpler:
>
>       The cRLSign bit MUST be asserted when the subject public key is
>       used for verifying a signature on a CertificateList (e.g., a CRL).
>       
>       If the keyCertSign bit is asserted, then the cA bit in the 
>       basic constraints extension (see 4.2.1.10) MUST be asserted.
>       If the keyCertSign bit is not asserted, then the cA bit
>       in the basic constraints extension MUST NOT be asserted.
>
>Dave
>
>
>
>"David P. Kemp" wrote:
> > 
> > The 9:25 AM version was clearer.  This version adds a restriction on
> > which type of authority may sign which type of revocation list.  Neither
> > version defines "CA certificate"; my impression was that
> > 
> >   If the cA bit is set, then the certificate *is* a CA certificate,
> > 
> > not the backwards-sounding
> > 
> >   If the cRLSign bit is asserted in a CA certificate, then the cA bit
> >   MUST be asserted.
> > 
> > How about the following:
> > 
> >       The cRLSign bit is asserted when the subject public key is used
> >       for verifying a signature on a CertificateList (e.g., a CRL).
> >       If the cA bit in the basic constraints extension (see 4.2.1.10)
> >       is not asserted, then the public key MUST NOT be used to verify
> >       signatures on CRLs containing revocation information for public
> >       key certificates, however it may be used to verify signatures
> >       on CRLs containing revocation information for other types of
> >       certificates (e.g., attribute certificates).
> >    *  If the cA bit is asserted, then the public key MUST NOT be used
> >    *  to verify signatures on CRLs containing revocation information
> >    *  for certificates other than public key certificates.
> > 
> >       If the keyCertSign bit is asserted, then the cA bit in the basic
> >       constraints extension MUST be asserted.  If neither the cRLSign
> >       bit nor the keyCertSign bit are asserted, then the cA bit in the
> >       basic constraints extension MUST NOT be asserted.
> > 
> > The third sentence (marked ***) is new; I don't know if you intended
> > the asymmetry of allowing CAs to revoke ACs but forbidding AAs from
> > revoking PKCs.  If neither CAs nor AAs can revoke the other's certs,
> > then the third sentence is needed.
> > 
> > Dave




Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00574 for <[e-mail]>; Wed, 18 Apr 2001 10:36:03 -0700 (PDT)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <2VH1AKL3>; Wed, 18 Apr 2001 13:35:34 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail]
Cc: "Hoyt Kesterson (E-mail)" <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Wed, 18 Apr 2001 13:30:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C82D.39742390"

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_01C0C82D.39742390
Content-Type: text/plain

The cRLSign bit should be restricted to verifying signatures on 
CRLs (not on other types of revocation status information) regardless
of who issues the CRLs.

On that topic, the 509 intent was that either the issuer of a certificate
or an entity authorized (to issue indirect CRLs) by the issuer of the
certificate would issue the 
relevant CRL(s) for that certificate. That intent applies to both public-key
and attribute certificates. 

Russ, when I reviewed your text, only one point came to mind. There are 
cases where a single authority will act as both a CA for public-key
certificates
and an AA for attribute certificates. As such, it would issue CRLs for the 
public-key certs and CRLs for the attribute certs. If I'm interpreting your 
text correctly, you would not permit the same certificate to indicate both?

Incidentally I just noticed another editorial correction that will need to 
be made to 509 to correctly indicate that both CAs and AAs can sign CRLs. In
the text for 
the cRLSign bit in the keyUsage extension (clause 8.2.2.3),
"for verifying a CA's signature" should read "for verifying an authority's
signature", in 
line with the editorial changes I made throughout 509 as mentioned in an
earlier message. 
This one was missed. 

Sharon  

> -----Original Message-----
> From: Marc Branchaud [mailto:[e-mail]]
> Sent: Wednesday, April 18, 2001 12:36 PM
> To: [e-mail]
> Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
> 
> 
> 
> Jim Schaad wrote:
> > 
> > 2.  This text implies to me that the cRLSign bit must be 
> set for an OCSP
> > responder (it does revocation information) is that what you want?
> > 
> 
> The way I read it, the bit can only be set for OCSP 
> responders that serve
> status for non-public-key certs.  In other words, the cRLSign 
> bit MUST NOT be
> asserted in all deployed OCSP responder certs.  (AFAIK, there 
> are no OCSP
> responders currently serving status on attribute certs, 
> though it certainly
> would be easy for them to do so.)  OTOH, the CRLSign bit MAY 
> be asserted for
> OCSP responders that _only_ serve status for non-public-key 
> certificates.  If
> an OCSP responder serves status for both types of 
> certificate, then I guess
> the bit would stay off...
> 
> Either way, the situation WRT OCSP responders is vague.  I 
> suggest that the
> first sentence be changed as follows:
> 
>    The cRLSign bit is asserted when the subject public key is 
> used for BOTH
>    verifying a signature on a certificate and for verifying a 
> signature on
>    revocation information (e.g., a CRL).
> 
> I think this aligns most closely with the intended use of the 
> bit, i.e. that
> it should only apply to entities that issue certificates.  
> Thus, a plain OCSP
> responder would not have the bit asserted in its cert.  But 
> if a CA or AA key
> is used to sign OCSP responses, then the bit SHOULD (MUST?) 
> be asserted in
> the CA/AA's cert.  To emphasize that, I recommend changing the second
> sentence to:
> 
>    This bit MUST be asserted in CA certificates that are used 
> to verify
>    signatures on CRLs and/or OCSP responses.
> 
> 		Marc
> 

------_=_NextPart_001_01C0C82D.39742390
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>The cRLSign bit should be restricted to verifying signatures on </FONT>
<BR><FONT SIZE=2>CRLs (not on other types of revocation status information) regardless</FONT>
<BR><FONT SIZE=2>of who issues the CRLs.</FONT>
</P>

<P><FONT SIZE=2>On that topic, the 509 intent was that either the issuer of a certificate</FONT>
<BR><FONT SIZE=2>or an entity authorized (to issue indirect CRLs) by the issuer of the certificate would issue the </FONT>
<BR><FONT SIZE=2>relevant CRL(s) for that certificate. That intent applies to both public-key</FONT>
<BR><FONT SIZE=2>and attribute certificates. </FONT>
</P>

<P><FONT SIZE=2>Russ, when I reviewed your text, only one point came to mind. There are </FONT>
<BR><FONT SIZE=2>cases where a single authority will act as both a CA for public-key certificates</FONT>
<BR><FONT SIZE=2>and an AA for attribute certificates. As such, it would issue CRLs for the </FONT>
<BR><FONT SIZE=2>public-key certs and CRLs for the attribute certs. If I'm interpreting your </FONT>
<BR><FONT SIZE=2>text correctly, you would not permit the same certificate to indicate both?</FONT>
</P>

<P><FONT SIZE=2>Incidentally I just noticed another editorial correction that will need to </FONT>
<BR><FONT SIZE=2>be made to 509 to correctly indicate that both CAs and AAs can sign CRLs. In the text for </FONT>
<BR><FONT SIZE=2>the cRLSign bit in the keyUsage extension (clause 8.2.2.3),</FONT>
<BR><FONT SIZE=2>&quot;for verifying a CA's signature&quot; should read &quot;for verifying an authority's signature&quot;, in </FONT>
<BR><FONT SIZE=2>line with the editorial changes I made throughout 509 as mentioned in an earlier message. </FONT>
<BR><FONT SIZE=2>This one was missed. </FONT>
</P>

<P><FONT SIZE=2>Sharon&nbsp; </FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Marc Branchaud [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, April 18, 2001 12:36 PM</FONT>
<BR><FONT SIZE=2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Jim Schaad wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 2.&nbsp; This text implies to me that the cRLSign bit must be </FONT>
<BR><FONT SIZE=2>&gt; set for an OCSP</FONT>
<BR><FONT SIZE=2>&gt; &gt; responder (it does revocation information) is that what you want?</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The way I read it, the bit can only be set for OCSP </FONT>
<BR><FONT SIZE=2>&gt; responders that serve</FONT>
<BR><FONT SIZE=2>&gt; status for non-public-key certs.&nbsp; In other words, the cRLSign </FONT>
<BR><FONT SIZE=2>&gt; bit MUST NOT be</FONT>
<BR><FONT SIZE=2>&gt; asserted in all deployed OCSP responder certs.&nbsp; (AFAIK, there </FONT>
<BR><FONT SIZE=2>&gt; are no OCSP</FONT>
<BR><FONT SIZE=2>&gt; responders currently serving status on attribute certs, </FONT>
<BR><FONT SIZE=2>&gt; though it certainly</FONT>
<BR><FONT SIZE=2>&gt; would be easy for them to do so.)&nbsp; OTOH, the CRLSign bit MAY </FONT>
<BR><FONT SIZE=2>&gt; be asserted for</FONT>
<BR><FONT SIZE=2>&gt; OCSP responders that _only_ serve status for non-public-key </FONT>
<BR><FONT SIZE=2>&gt; certificates.&nbsp; If</FONT>
<BR><FONT SIZE=2>&gt; an OCSP responder serves status for both types of </FONT>
<BR><FONT SIZE=2>&gt; certificate, then I guess</FONT>
<BR><FONT SIZE=2>&gt; the bit would stay off...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Either way, the situation WRT OCSP responders is vague.&nbsp; I </FONT>
<BR><FONT SIZE=2>&gt; suggest that the</FONT>
<BR><FONT SIZE=2>&gt; first sentence be changed as follows:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; The cRLSign bit is asserted when the subject public key is </FONT>
<BR><FONT SIZE=2>&gt; used for BOTH</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; verifying a signature on a certificate and for verifying a </FONT>
<BR><FONT SIZE=2>&gt; signature on</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; revocation information (e.g., a CRL).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think this aligns most closely with the intended use of the </FONT>
<BR><FONT SIZE=2>&gt; bit, i.e. that</FONT>
<BR><FONT SIZE=2>&gt; it should only apply to entities that issue certificates.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Thus, a plain OCSP</FONT>
<BR><FONT SIZE=2>&gt; responder would not have the bit asserted in its cert.&nbsp; But </FONT>
<BR><FONT SIZE=2>&gt; if a CA or AA key</FONT>
<BR><FONT SIZE=2>&gt; is used to sign OCSP responses, then the bit SHOULD (MUST?) </FONT>
<BR><FONT SIZE=2>&gt; be asserted in</FONT>
<BR><FONT SIZE=2>&gt; the CA/AA's cert.&nbsp; To emphasize that, I recommend changing the second</FONT>
<BR><FONT SIZE=2>&gt; sentence to:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; This bit MUST be asserted in CA certificates that are used </FONT>
<BR><FONT SIZE=2>&gt; to verify</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; signatures on CRLs and/or OCSP responses.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Marc</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C82D.39742390--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA29413 for <[e-mail]>; Wed, 18 Apr 2001 10:22:12 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JFQR8AKK>; Wed, 18 Apr 2001 13:21:40 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Wed, 18 Apr 2001 13:12:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C82A.D09792F0"

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_01C0C82A.D09792F0
Content-Type: text/plain;
	charset="iso-8859-1"

Dave:

This text is clearer than your previous text and is also acceptable to me.
This accommodates OCSP responders nicely.

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Wednesday, April 18, 2001 1:08 PM
To: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments


P.S., my preference is to not use the cA bit to make a distinction
between types of CRL signers, in which case the text is much simpler:

      The cRLSign bit MUST be asserted when the subject public key is
      used for verifying a signature on a CertificateList (e.g., a CRL).
      
      If the keyCertSign bit is asserted, then the cA bit in the 
      basic constraints extension (see 4.2.1.10) MUST be asserted.
      If the keyCertSign bit is not asserted, then the cA bit
      in the basic constraints extension MUST NOT be asserted.

Dave



"David P. Kemp" wrote:
> 
> The 9:25 AM version was clearer.  This version adds a restriction on
> which type of authority may sign which type of revocation list.  Neither
> version defines "CA certificate"; my impression was that
> 
>   If the cA bit is set, then the certificate *is* a CA certificate,
> 
> not the backwards-sounding
> 
>   If the cRLSign bit is asserted in a CA certificate, then the cA bit
>   MUST be asserted.
> 
> How about the following:
> 
>       The cRLSign bit is asserted when the subject public key is used
>       for verifying a signature on a CertificateList (e.g., a CRL).
>       If the cA bit in the basic constraints extension (see 4.2.1.10)
>       is not asserted, then the public key MUST NOT be used to verify
>       signatures on CRLs containing revocation information for public
>       key certificates, however it may be used to verify signatures
>       on CRLs containing revocation information for other types of
>       certificates (e.g., attribute certificates).
>    *  If the cA bit is asserted, then the public key MUST NOT be used
>    *  to verify signatures on CRLs containing revocation information
>    *  for certificates other than public key certificates.
> 
>       If the keyCertSign bit is asserted, then the cA bit in the basic
>       constraints extension MUST be asserted.  If neither the cRLSign
>       bit nor the keyCertSign bit are asserted, then the cA bit in the
>       basic constraints extension MUST NOT be asserted.
> 
> The third sentence (marked ***) is new; I don't know if you intended
> the asymmetry of allowing CAs to revoke ACs but forbidding AAs from
> revoking PKCs.  If neither CAs nor AAs can revoke the other's certs,
> then the third sentence is needed.
> 
> Dave

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>This text is clearer than your previous text and is =
also acceptable to me.&nbsp; This accommodates OCSP responders =
nicely.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David P. Kemp [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, April 18, 2001 1:08 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Last Call: =
draft-ietf-pkix-new-part1-06.txt comments</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>P.S., my preference is to not use the cA bit to make =
a distinction</FONT>
<BR><FONT SIZE=3D2>between types of CRL signers, in which case the text =
is much simpler:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign bit MUST =
be asserted when the subject public key is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for verifying a =
signature on a CertificateList (e.g., a CRL).</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the keyCertSign =
bit is asserted, then the cA bit in the </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; basic constraints =
extension (see 4.2.1.10) MUST be asserted.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the keyCertSign =
bit is not asserted, then the cA bit</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the basic =
constraints extension MUST NOT be asserted.</FONT>
</P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;David P. Kemp&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The 9:25 AM version was clearer.&nbsp; This =
version adds a restriction on</FONT>
<BR><FONT SIZE=3D2>&gt; which type of authority may sign which type of =
revocation list.&nbsp; Neither</FONT>
<BR><FONT SIZE=3D2>&gt; version defines &quot;CA certificate&quot;; my =
impression was that</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; If the cA bit is set, then the =
certificate *is* a CA certificate,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; not the backwards-sounding</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; If the cRLSign bit is asserted in a =
CA certificate, then the cA bit</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; MUST be asserted.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; How about the following:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cRLSign =
bit is asserted when the subject public key is used</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for =
verifying a signature on a CertificateList (e.g., a CRL).</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the cA =
bit in the basic constraints extension (see 4.2.1.10)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is not =
asserted, then the public key MUST NOT be used to verify</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signatures =
on CRLs containing revocation information for public</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; key =
certificates, however it may be used to verify signatures</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on CRLs =
containing revocation information for other types of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
certificates (e.g., attribute certificates).</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; *&nbsp; If the cA bit is =
asserted, then the public key MUST NOT be used</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; *&nbsp; to verify signatures =
on CRLs containing revocation information</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; *&nbsp; for certificates =
other than public key certificates.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the =
keyCertSign bit is asserted, then the cA bit in the basic</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; constraints =
extension MUST be asserted.&nbsp; If neither the cRLSign</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit nor the =
keyCertSign bit are asserted, then the cA bit in the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; basic =
constraints extension MUST NOT be asserted.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The third sentence (marked ***) is new; I don't =
know if you intended</FONT>
<BR><FONT SIZE=3D2>&gt; the asymmetry of allowing CAs to revoke ACs but =
forbidding AAs from</FONT>
<BR><FONT SIZE=3D2>&gt; revoking PKCs.&nbsp; If neither CAs nor AAs can =
revoke the other's certs,</FONT>
<BR><FONT SIZE=3D2>&gt; then the third sentence is needed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C82A.D09792F0--


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA28301 for <[e-mail]>; Wed, 18 Apr 2001 10:10:21 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA09902 for <[e-mail]>; Wed, 18 Apr 2001 13:09:53 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Wed, 18 Apr 2001 13:08:09 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

P.S., my preference is to not use the cA bit to make a distinction
between types of CRL signers, in which case the text is much simpler:

      The cRLSign bit MUST be asserted when the subject public key is
      used for verifying a signature on a CertificateList (e.g., a CRL).
      
      If the keyCertSign bit is asserted, then the cA bit in the 
      basic constraints extension (see 4.2.1.10) MUST be asserted.
      If the keyCertSign bit is not asserted, then the cA bit
      in the basic constraints extension MUST NOT be asserted.

Dave



"David P. Kemp" wrote:
> 
> The 9:25 AM version was clearer.  This version adds a restriction on
> which type of authority may sign which type of revocation list.  Neither
> version defines "CA certificate"; my impression was that
> 
>   If the cA bit is set, then the certificate *is* a CA certificate,
> 
> not the backwards-sounding
> 
>   If the cRLSign bit is asserted in a CA certificate, then the cA bit
>   MUST be asserted.
> 
> How about the following:
> 
>       The cRLSign bit is asserted when the subject public key is used
>       for verifying a signature on a CertificateList (e.g., a CRL).
>       If the cA bit in the basic constraints extension (see 4.2.1.10)
>       is not asserted, then the public key MUST NOT be used to verify
>       signatures on CRLs containing revocation information for public
>       key certificates, however it may be used to verify signatures
>       on CRLs containing revocation information for other types of
>       certificates (e.g., attribute certificates).
>    *  If the cA bit is asserted, then the public key MUST NOT be used
>    *  to verify signatures on CRLs containing revocation information
>    *  for certificates other than public key certificates.
> 
>       If the keyCertSign bit is asserted, then the cA bit in the basic
>       constraints extension MUST be asserted.  If neither the cRLSign
>       bit nor the keyCertSign bit are asserted, then the cA bit in the
>       basic constraints extension MUST NOT be asserted.
> 
> The third sentence (marked ***) is new; I don't know if you intended
> the asymmetry of allowing CAs to revoke ACs but forbidding AAs from
> revoking PKCs.  If neither CAs nor AAs can revoke the other's certs,
> then the third sentence is needed.
> 
> Dave


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA28266 for <[e-mail]>; Wed, 18 Apr 2001 10:10:16 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 18 Apr 2001 10:10:24 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 18 Apr 2001 10:10:24 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26P1H0>; Wed, 18 Apr 2001 10:09:18 -0700
Content-return: allowed
Date: Wed, 18 Apr 2001 10:09:17 -0700
From: Frank Balluffi <[e-mail]>
Subject: CMP: Use of PKIMessages
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Carlisle and Stephen,

draft-ietf-pkix-rfc2510bis-03.txt defines PKIMessages as:

PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage

whereas RFC 2510 uses PKIMessages within its text, but does not define the
type.

Am I correct in assuming that section 5.4 of RFC 2510 and Appendix G of
draft-ietf-pkix-rfc2510bis-03.txt describe methods for transporting
PKIMessage (singular), not PKIMessages (plural). Thanks.

Frank


Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA27236 for <[e-mail]>; Wed, 18 Apr 2001 09:58:06 -0700 (PDT)
Received: from 157.54.9.100 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 18 Apr 2001 09:21:07 -0700 (Pacific Daylight Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 18 Apr 2001 09:21:04 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Wed, 18 Apr 2001 09:21:04 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Thread-Index: AcDII0NIXSzq4bh2R0yu7BV/1gqwgQAAMnUw
From: "David Cross" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 18 Apr 2001 16:21:05.0009 (UTC) FILETIME=[91188E10:01C0C823]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA27237

I concur with Santosh.
 
David B. Cross


	-----Original Message-----
	From: Santosh Chokhani [mailto:[e-mail]] 
	Sent: Wednesday, April 18, 2001 9:08 AM
	To: [e-mail]; 'Russ Housley'; [e-mail]
	Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt
comments
	
	

	Russ: 

	More importantly, is the RFC saying that OCSP responder is a CA
or AA.  I think  it is neither. 



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA27020 for <[e-mail]>; Wed, 18 Apr 2001 09:56:27 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA09270 for <[e-mail]>; Wed, 18 Apr 2001 12:55:59 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Wed, 18 Apr 2001 12:54:12 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The 9:25 AM version was clearer.  This version adds a restriction on
which type of authority may sign which type of revocation list.  Neither
version defines "CA certificate"; my impression was that

  If the cA bit is set, then the certificate *is* a CA certificate,

not the backwards-sounding

  If the cRLSign bit is asserted in a CA certificate, then the cA bit
  MUST be asserted.


How about the following:

      The cRLSign bit is asserted when the subject public key is used
      for verifying a signature on a CertificateList (e.g., a CRL).
      If the cA bit in the basic constraints extension (see 4.2.1.10)
      is not asserted, then the public key MUST NOT be used to verify
      signatures on CRLs containing revocation information for public
      key certificates, however it may be used to verify signatures
      on CRLs containing revocation information for other types of
      certificates (e.g., attribute certificates).
   *  If the cA bit is asserted, then the public key MUST NOT be used
   *  to verify signatures on CRLs containing revocation information
   *  for certificates other than public key certificates.

      If the keyCertSign bit is asserted, then the cA bit in the basic
      constraints extension MUST be asserted.  If neither the cRLSign
      bit nor the keyCertSign bit are asserted, then the cA bit in the
      basic constraints extension MUST NOT be asserted.


The third sentence (marked ***) is new; I don't know if you intended
the asymmetry of allowing CAs to revoke ACs but forbidding AAs from
revoking PKCs.  If neither CAs nor AAs can revoke the other's certs,
then the third sentence is needed.

Dave



Stephen Farrell wrote:
> 
> I thought it was clearer first time! But its still ok.
> 
> Stephen.
> 
> Russ Housley wrote:
> >
> > Tim Polk and I just got off the phone.  After a lengthy discussion, we
> > propose a revision to the cRLSign discussion:
> >
> >        The cRLSign bit is asserted when the subject public key is used
> >        for verifying a signature on revocation information (e.g., a CRL).
> >        This bit MUST be asserted in CA certificates that are used to
> >        verify signatures on CRLs.  If the cRLSign bit is asserted in a CA
> >        certificate, then the cA bit in the basic constraints extension
> >        (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
> >        asserted in a non-CA certificate, then the cA bit in the basic
> >        constraints extension MUST NOT be asserted.  Such non-CA
> >        certificates MUST NOT be used to verify signatures on CRLs
> >        containing revocation information for public key certificates;
> >        however, these non-CA certificates MAY be used to verify
> >        signatures on CRLs containing revocation information concerning
> >        other types of certificates (e.g., attribute certificates).  If
> >        neither the cRLSign bit nor the keyCertSign bit are asserted, then
> >        the cA bit in the basic constraints extension MUST NOT be
> >        asserted.
> >
> > Hey, this section was only one sentence in RFC 2459...
> >
> > Please let us know if anyone has any remaining concerns.
> >
> > Russ


Received: from home.x509.com (home.x509.com [199.175.150.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA25702 for <[e-mail]>; Wed, 18 Apr 2001 09:37:45 -0700 (PDT)
Received: from rsasecurity.com (eskarina.eng.x509.com [10.7.33.45]) by home.x509.com (8.11.2/XCERT) with ESMTP id f3IGbHQ88236 for <[e-mail]>; Wed, 18 Apr 2001 09:37:17 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 18 Apr 2001 09:35:50 -0700
From: Marc Branchaud <[e-mail]>
Organization: RSA Security
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <000001c0c822$dbbffe90$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim Schaad wrote:
> 
> 2.  This text implies to me that the cRLSign bit must be set for an OCSP
> responder (it does revocation information) is that what you want?
> 

The way I read it, the bit can only be set for OCSP responders that serve
status for non-public-key certs.  In other words, the cRLSign bit MUST NOT be
asserted in all deployed OCSP responder certs.  (AFAIK, there are no OCSP
responders currently serving status on attribute certs, though it certainly
would be easy for them to do so.)  OTOH, the CRLSign bit MAY be asserted for
OCSP responders that _only_ serve status for non-public-key certificates.  If
an OCSP responder serves status for both types of certificate, then I guess
the bit would stay off...

Either way, the situation WRT OCSP responders is vague.  I suggest that the
first sentence be changed as follows:

   The cRLSign bit is asserted when the subject public key is used for BOTH
   verifying a signature on a certificate and for verifying a signature on
   revocation information (e.g., a CRL).

I think this aligns most closely with the intended use of the bit, i.e. that
it should only apply to entities that issue certificates.  Thus, a plain OCSP
responder would not have the bit asserted in its cert.  But if a CA or AA key
is used to sign OCSP responses, then the bit SHOULD (MUST?) be asserted in
the CA/AA's cert.  To emphasize that, I recommend changing the second
sentence to:

   This bit MUST be asserted in CA certificates that are used to verify
   signatures on CRLs and/or OCSP responses.

		Marc


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA24177 for <[e-mail]>; Wed, 18 Apr 2001 09:17:27 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JFQR70CF>; Wed, 18 Apr 2001 12:16:57 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: [e-mail], "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Wed, 18 Apr 2001 12:08:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C821.C5D63640"

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_01C0C821.C5D63640
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:

More importantly, is the RFC saying that OCSP responder is a CA or AA.  I
think  it is neither.

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Wednesday, April 18, 2001 12:16 PM
To: 'Russ Housley'; [e-mail]
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments


Russ,

Two items:

1.  You also need to change the text on the basic constraints extension.
2.  This text implies to me that the cRLSign bit must be set for an OCSP
responder (it does revocation information) is that what you want?

jim

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Wednesday, April 18, 2001 8:07 AM
> To: [e-mail]
> Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
>
>
> Tim Polk and I just got off the phone.  After a lengthy
> discussion, we
> propose a revision to the cRLSign discussion:
>
>        The cRLSign bit is asserted when the subject public key is used
>        for verifying a signature on revocation information
> (e.g., a CRL).
>        This bit MUST be asserted in CA certificates that are used to
>        verify signatures on CRLs.  If the cRLSign bit is
> asserted in a CA
>        certificate, then the cA bit in the basic constraints extension
>        (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
>        asserted in a non-CA certificate, then the cA bit in the basic
>        constraints extension MUST NOT be asserted.  Such non-CA
>        certificates MUST NOT be used to verify signatures on CRLs
>        containing revocation information for public key certificates;
>        however, these non-CA certificates MAY be used to verify
>        signatures on CRLs containing revocation information concerning
>        other types of certificates (e.g., attribute certificates).  If
>        neither the cRLSign bit nor the keyCertSign bit are
> asserted, then
>        the cA bit in the basic constraints extension MUST NOT be
>        asserted.
>
> Hey, this section was only one sentence in RFC 2459...
>
> Please let us know if anyone has any remaining concerns.
>
> Russ
>
>
> At 09:25 AM 4/18/2001 -0400, Russ Housley wrote:
> >Based on this discussion, I think that the working group wants the
> >keyCertSign and cRLSign key usage text to read as follows:
> >
> >       The keyCertSign bit is asserted when the subject public key is
> >       used for verifying a signature on public key
> certificates.  This
> >       bit MUST only be asserted in CA certificates.  If the
> keyCertSign
> >       bit is asserted, then the cA bit in the basic constraints
> >       extension (see 4.2.1.10) MUST also be asserted.  If
> neither the
> >       cRLSign bit nor the keyCertSign bit are asserted,
> then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> >       The cRLSign bit is asserted when the subject public
> key is used
> >       for verifying a signature on certificate revocation
> lists (CRLs).
> >       This bit MUST only be asserted in CA certificates and
> Attribute
> >       Authority (AA) certificates.  If the cRLSign bit is
> asserted in a
> >       CA certificate, then the cA bit in the basic
> constraints extension
> >       (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
> >       asserted in an AA certificate, then the cA bit in the basic
> >       constraints extension MUST NOT be asserted.  If neither the
> >       cRLSign bit nor the keyCertSign bit are asserted,
> then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> >Let me know if you disagree.
> >
> >Russ
> >
> >At 02:31 PM 4/17/2001 +0100, Stephen Farrell wrote:
> >
> >>I'd also go along with Jim here - that an AA be allowed to
> >>have cRLSign set without having cA set in basicConstraints,
> >>i.e. that AA's be an exception to the general rule for EE's
> >>and that this be explicitly called out in son-of-2459. I'm
> >>assuming that keyCertSign is therefore not set for AA's too
> >>(and the text for keyCertSign shouldn't say "certificates",
> >>but "public key certificates").
> >>
> >>Stephen.
> >>
> >>Jim Schaad wrote:
> >> >
> >> > Russ,
> >> >
> >> > > -----Original Message-----
> >> > > From: Russ Housley [mailto:[e-mail]]
> >> > > Sent: Monday, April 16, 2001 10:33 AM
> >> > > To: [e-mail]
> >> > > Cc: [e-mail]
> >> > > Subject: Re: Last Call:
> draft-ietf-pkix-new-part1-06.txt comments
> >> > >
> >> > >
> >> > > Jim:
> >> > >
> >> > > >1. As currently written in section 4.2.1.3, it is not
> >> > > possible for a non-CA
> >> > > >CRL issuer to be created for attribute certificates.  Was
> >> > > this the final
> >> > > >resolution of this issue?  This seems to me to be
> >> > > problematic as it means as
> >> > > >an end-user one can issue an attribute certificate, but one
> >> > > must always use
> >> > > >a different agent, which is a CA, to issue the CRLs.  This
> >> > > means that all
> >> > > >attribute CRL issuers are indirect.
> >> > >
> >> > > I do not recall a consensus on this point.  Should an AA that
> >> > > supports CRLs
> >> > > have the cRLSign bit set in its public key certificate?  If
> >> > > so, this text
> >> > > must change.
> >> >
> >> > I don't recall anything except private discussions on
> this issue.  It is
> >> > here for the mailing list to comment on.
> >> >
> >> > It is my option that an AA that supports CRLs SHOULD
> have the cRLSign bit
> >> > set.  Either that or we ask X509 to create AACertSign
> and AACrlSign
> >> bits and
> >> > keep this current text as is.
> >> >
> >> > >
> >> > > >2. Section 4.2.1.3, paragraph last:  Current Text: "set in
> >> > > An instantiation"
> >> > > >modify to "set in an instantiation".
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >3. Section 6.2 paragraph 2: change "prresented" to "presented"
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >4. Section 6.2 paragraph 2:  The text "For example, an
> >> > > implementation may
> >> > > >specify name constraints that apply to a specific trust
> >> > > anchor." is diffcult
> >> > > >for me given that the validation algorithm explicitly states
> >> > > that name
> >> > > >constraints are not applied to self signed
> certificates. Suggest "For
> >> > > >example, an implemenation may modify the algorithm to apply
> >> > > name constaints
> >> > > >during the initialization phase."
> >> > >
> >> > > Self-signed certificates are a common mechanism for
> >> > > distributing public
> >> > > keys for trust anchors, but they are not a mandated
> >> > > mechanism.  That said,
> >> > > I think that your text it an improvement.   How about a hybrid:
> >> > >
> >> > >     For example, an implementation MAY modify the algorithm
> >> > >     to apply name constraints to a specific trust anchor
> >> > >     during the initialization phase.
> >> >
> >> > I have no problems with this new text.
> >> >
> >> > >
> >> > > >5. ASN module:
> >> > > >part1a.asn(352) : warning XXXXX: The imported symbol
> 'id-ad' is never
> >> > > >referenced
> >> > >
> >> > > Agree. I removed it.
> >> > >
> >> > > Russ
> >> > >
> >> > >
> >> >
> >> > jim
> >>
> >>--
> >>____________________________________________________________
> >>Stephen Farrell
> >>Baltimore Technologies,   tel: (direct line) [phone]
> >>39 Parkgate Street,                     fax: [phone]
> >>Dublin 8.                mailto:[e-mail]
> >>Ireland                             http://www.baltimore.com
>
>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>More importantly, is the RFC saying that OCSP =
responder is a CA or AA.&nbsp; I think&nbsp; it is neither.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jim Schaad [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, April 18, 2001 12:16 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Russ Housley'; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Last Call: =
draft-ietf-pkix-new-part1-06.txt comments</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>Two items:</FONT>
</P>

<P><FONT SIZE=3D2>1.&nbsp; You also need to change the text on the =
basic constraints extension.</FONT>
<BR><FONT SIZE=3D2>2.&nbsp; This text implies to me that the cRLSign =
bit must be set for an OCSP</FONT>
<BR><FONT SIZE=3D2>responder (it does revocation information) is that =
what you want?</FONT>
</P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Russ Housley [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, April 18, 2001 8:07 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Last Call: =
draft-ietf-pkix-new-part1-06.txt comments</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Tim Polk and I just got off the phone.&nbsp; =
After a lengthy</FONT>
<BR><FONT SIZE=3D2>&gt; discussion, we</FONT>
<BR><FONT SIZE=3D2>&gt; propose a revision to the cRLSign =
discussion:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
cRLSign bit is asserted when the subject public key is used</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for =
verifying a signature on revocation information</FONT>
<BR><FONT SIZE=3D2>&gt; (e.g., a CRL).</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This =
bit MUST be asserted in CA certificates that are used to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
verify signatures on CRLs.&nbsp; If the cRLSign bit is</FONT>
<BR><FONT SIZE=3D2>&gt; asserted in a CA</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
certificate, then the cA bit in the basic constraints extension</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (see =
4.2.1.10) MUST also be asserted.&nbsp; If the cRLSign bit is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
asserted in a non-CA certificate, then the cA bit in the basic</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
constraints extension MUST NOT be asserted.&nbsp; Such non-CA</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
certificates MUST NOT be used to verify signatures on CRLs</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
containing revocation information for public key certificates;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
however, these non-CA certificates MAY be used to verify</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
signatures on CRLs containing revocation information concerning</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; other =
types of certificates (e.g., attribute certificates).&nbsp; If</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
neither the cRLSign bit nor the keyCertSign bit are</FONT>
<BR><FONT SIZE=3D2>&gt; asserted, then</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
cA bit in the basic constraints extension MUST NOT be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
asserted.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Hey, this section was only one sentence in RFC =
2459...</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Please let us know if anyone has any remaining =
concerns.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; At 09:25 AM 4/18/2001 -0400, Russ Housley =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Based on this discussion, I think that the =
working group wants the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;keyCertSign and cRLSign key usage text to =
read as follows:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
keyCertSign bit is asserted when the subject public key is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used =
for verifying a signature on public key</FONT>
<BR><FONT SIZE=3D2>&gt; certificates.&nbsp; This</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit =
MUST only be asserted in CA certificates.&nbsp; If the</FONT>
<BR><FONT SIZE=3D2>&gt; keyCertSign</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bit is =
asserted, then the cA bit in the basic constraints</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
extension (see 4.2.1.10) MUST also be asserted.&nbsp; If</FONT>
<BR><FONT SIZE=3D2>&gt; neither the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
cRLSign bit nor the keyCertSign bit are asserted,</FONT>
<BR><FONT SIZE=3D2>&gt; then the cA bit</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the =
basic constraints extension MUST NOT be asserted.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
cRLSign bit is asserted when the subject public</FONT>
<BR><FONT SIZE=3D2>&gt; key is used</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for =
verifying a signature on certificate revocation</FONT>
<BR><FONT SIZE=3D2>&gt; lists (CRLs).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This =
bit MUST only be asserted in CA certificates and</FONT>
<BR><FONT SIZE=3D2>&gt; Attribute</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Authority (AA) certificates.&nbsp; If the cRLSign bit is</FONT>
<BR><FONT SIZE=3D2>&gt; asserted in a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CA =
certificate, then the cA bit in the basic</FONT>
<BR><FONT SIZE=3D2>&gt; constraints extension</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (see =
4.2.1.10) MUST also be asserted.&nbsp; If the cRLSign bit is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
asserted in an AA certificate, then the cA bit in the basic</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
constraints extension MUST NOT be asserted.&nbsp; If neither the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
cRLSign bit nor the keyCertSign bit are asserted,</FONT>
<BR><FONT SIZE=3D2>&gt; then the cA bit</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the =
basic constraints extension MUST NOT be asserted.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Let me know if you disagree.</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;At 02:31 PM 4/17/2001 +0100, Stephen =
Farrell wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;I'd also go along with Jim here - that =
an AA be allowed to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;have cRLSign set without having cA set =
in basicConstraints,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;i.e. that AA's be an exception to the =
general rule for EE's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;and that this be explicitly called out =
in son-of-2459. I'm</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;assuming that keyCertSign is therefore =
not set for AA's too</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;(and the text for keyCertSign shouldn't =
say &quot;certificates&quot;,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;but &quot;public key =
certificates&quot;).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;Stephen.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;Jim Schaad wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; Russ,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; From: Russ Housley [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; Sent: Monday, April 16, 2001 =
10:33 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; Subject: Re: Last =
Call:</FONT>
<BR><FONT SIZE=3D2>&gt; draft-ietf-pkix-new-part1-06.txt =
comments</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; Jim:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;1. As currently written =
in section 4.2.1.3, it is not</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; possible for a non-CA</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;CRL issuer to be created =
for attribute certificates.&nbsp; Was</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; this the final</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;resolution of this =
issue?&nbsp; This seems to me to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; problematic as it means =
as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;an end-user one can =
issue an attribute certificate, but one</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; must always use</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;a different agent, which =
is a CA, to issue the CRLs.&nbsp; This</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; means that all</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;attribute CRL issuers =
are indirect.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; I do not recall a consensus =
on this point.&nbsp; Should an AA that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; supports CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; have the cRLSign bit set in =
its public key certificate?&nbsp; If</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; so, this text</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; must change.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; I don't recall anything except =
private discussions on</FONT>
<BR><FONT SIZE=3D2>&gt; this issue.&nbsp; It is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; here for the mailing list to =
comment on.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; It is my option that an AA that =
supports CRLs SHOULD</FONT>
<BR><FONT SIZE=3D2>&gt; have the cRLSign bit</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; set.&nbsp; Either that or we ask =
X509 to create AACertSign</FONT>
<BR><FONT SIZE=3D2>&gt; and AACrlSign</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; bits and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; keep this current text as =
is.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;2. Section 4.2.1.3, =
paragraph last:&nbsp; Current Text: &quot;set in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; An =
instantiation&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;modify to &quot;set in =
an instantiation&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; Fixed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;3. Section 6.2 paragraph =
2: change &quot;prresented&quot; to &quot;presented&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; Fixed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;4. Section 6.2 paragraph =
2:&nbsp; The text &quot;For example, an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; implementation may</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;specify name constraints =
that apply to a specific trust</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; anchor.&quot; is =
diffcult</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;for me given that the =
validation algorithm explicitly states</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; that name</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;constraints are not =
applied to self signed</FONT>
<BR><FONT SIZE=3D2>&gt; certificates. Suggest &quot;For</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;example, an =
implemenation may modify the algorithm to apply</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; name constaints</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;during the =
initialization phase.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; Self-signed certificates are =
a common mechanism for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; distributing public</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; keys for trust anchors, but =
they are not a mandated</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; mechanism.&nbsp; That =
said,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; I think that your text it an =
improvement.&nbsp;&nbsp; How about a hybrid:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; For =
example, an implementation MAY modify the algorithm</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; to =
apply name constraints to a specific trust anchor</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
during the initialization phase.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; I have no problems with this new =
text.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;5. ASN module:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;part1a.asn(352) : =
warning XXXXX: The imported symbol</FONT>
<BR><FONT SIZE=3D2>&gt; 'id-ad' is never</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; &gt;referenced</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; Agree. I removed it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt; jim</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;--</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&gt;____________________________________________________________</FO=
NT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;Stephen Farrell</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;Baltimore Technologies,&nbsp;&nbsp; =
tel: (direct line) [phone]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;39 Parkgate =
Street,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax: [phone] =
7000</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;Dublin =
8.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"mailto:[e-mail]">mailto:stephen.farrell@balt=
imore.ie</A></FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&gt;Ireland&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; <A =
HREF=3D"http://www.baltimore.com" =
TARGET=3D"_blank">http://www.baltimore.com</A></FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C821.C5D63640--


Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA23769 for <[e-mail]>; Wed, 18 Apr 2001 09:13:11 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010418161041.PALC26961.femail3.sdc1.sfba.home.com@revelation>; Wed, 18 Apr 2001 09:10:41 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Wed, 18 Apr 2001 09:15:58 -0700
Message-ID: <000001c0c822$dbbffe90$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Russ,

Two items:

1.  You also need to change the text on the basic constraints extension.
2.  This text implies to me that the cRLSign bit must be set for an OCSP
responder (it does revocation information) is that what you want?

jim

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Wednesday, April 18, 2001 8:07 AM
> To: [e-mail]
> Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
>
>
> Tim Polk and I just got off the phone.  After a lengthy
> discussion, we
> propose a revision to the cRLSign discussion:
>
>        The cRLSign bit is asserted when the subject public key is used
>        for verifying a signature on revocation information
> (e.g., a CRL).
>        This bit MUST be asserted in CA certificates that are used to
>        verify signatures on CRLs.  If the cRLSign bit is
> asserted in a CA
>        certificate, then the cA bit in the basic constraints extension
>        (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
>        asserted in a non-CA certificate, then the cA bit in the basic
>        constraints extension MUST NOT be asserted.  Such non-CA
>        certificates MUST NOT be used to verify signatures on CRLs
>        containing revocation information for public key certificates;
>        however, these non-CA certificates MAY be used to verify
>        signatures on CRLs containing revocation information concerning
>        other types of certificates (e.g., attribute certificates).  If
>        neither the cRLSign bit nor the keyCertSign bit are
> asserted, then
>        the cA bit in the basic constraints extension MUST NOT be
>        asserted.
>
> Hey, this section was only one sentence in RFC 2459...
>
> Please let us know if anyone has any remaining concerns.
>
> Russ
>
>
> At 09:25 AM 4/18/2001 -0400, Russ Housley wrote:
> >Based on this discussion, I think that the working group wants the
> >keyCertSign and cRLSign key usage text to read as follows:
> >
> >       The keyCertSign bit is asserted when the subject public key is
> >       used for verifying a signature on public key
> certificates.  This
> >       bit MUST only be asserted in CA certificates.  If the
> keyCertSign
> >       bit is asserted, then the cA bit in the basic constraints
> >       extension (see 4.2.1.10) MUST also be asserted.  If
> neither the
> >       cRLSign bit nor the keyCertSign bit are asserted,
> then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> >       The cRLSign bit is asserted when the subject public
> key is used
> >       for verifying a signature on certificate revocation
> lists (CRLs).
> >       This bit MUST only be asserted in CA certificates and
> Attribute
> >       Authority (AA) certificates.  If the cRLSign bit is
> asserted in a
> >       CA certificate, then the cA bit in the basic
> constraints extension
> >       (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
> >       asserted in an AA certificate, then the cA bit in the basic
> >       constraints extension MUST NOT be asserted.  If neither the
> >       cRLSign bit nor the keyCertSign bit are asserted,
> then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> >Let me know if you disagree.
> >
> >Russ
> >
> >At 02:31 PM 4/17/2001 +0100, Stephen Farrell wrote:
> >
> >>I'd also go along with Jim here - that an AA be allowed to
> >>have cRLSign set without having cA set in basicConstraints,
> >>i.e. that AA's be an exception to the general rule for EE's
> >>and that this be explicitly called out in son-of-2459. I'm
> >>assuming that keyCertSign is therefore not set for AA's too
> >>(and the text for keyCertSign shouldn't say "certificates",
> >>but "public key certificates").
> >>
> >>Stephen.
> >>
> >>Jim Schaad wrote:
> >> >
> >> > Russ,
> >> >
> >> > > -----Original Message-----
> >> > > From: Russ Housley [mailto:[e-mail]]
> >> > > Sent: Monday, April 16, 2001 10:33 AM
> >> > > To: [e-mail]
> >> > > Cc: [e-mail]
> >> > > Subject: Re: Last Call:
> draft-ietf-pkix-new-part1-06.txt comments
> >> > >
> >> > >
> >> > > Jim:
> >> > >
> >> > > >1. As currently written in section 4.2.1.3, it is not
> >> > > possible for a non-CA
> >> > > >CRL issuer to be created for attribute certificates.  Was
> >> > > this the final
> >> > > >resolution of this issue?  This seems to me to be
> >> > > problematic as it means as
> >> > > >an end-user one can issue an attribute certificate, but one
> >> > > must always use
> >> > > >a different agent, which is a CA, to issue the CRLs.  This
> >> > > means that all
> >> > > >attribute CRL issuers are indirect.
> >> > >
> >> > > I do not recall a consensus on this point.  Should an AA that
> >> > > supports CRLs
> >> > > have the cRLSign bit set in its public key certificate?  If
> >> > > so, this text
> >> > > must change.
> >> >
> >> > I don't recall anything except private discussions on
> this issue.  It is
> >> > here for the mailing list to comment on.
> >> >
> >> > It is my option that an AA that supports CRLs SHOULD
> have the cRLSign bit
> >> > set.  Either that or we ask X509 to create AACertSign
> and AACrlSign
> >> bits and
> >> > keep this current text as is.
> >> >
> >> > >
> >> > > >2. Section 4.2.1.3, paragraph last:  Current Text: "set in
> >> > > An instantiation"
> >> > > >modify to "set in an instantiation".
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >3. Section 6.2 paragraph 2: change "prresented" to "presented"
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >4. Section 6.2 paragraph 2:  The text "For example, an
> >> > > implementation may
> >> > > >specify name constraints that apply to a specific trust
> >> > > anchor." is diffcult
> >> > > >for me given that the validation algorithm explicitly states
> >> > > that name
> >> > > >constraints are not applied to self signed
> certificates. Suggest "For
> >> > > >example, an implemenation may modify the algorithm to apply
> >> > > name constaints
> >> > > >during the initialization phase."
> >> > >
> >> > > Self-signed certificates are a common mechanism for
> >> > > distributing public
> >> > > keys for trust anchors, but they are not a mandated
> >> > > mechanism.  That said,
> >> > > I think that your text it an improvement.   How about a hybrid:
> >> > >
> >> > >     For example, an implementation MAY modify the algorithm
> >> > >     to apply name constraints to a specific trust anchor
> >> > >     during the initialization phase.
> >> >
> >> > I have no problems with this new text.
> >> >
> >> > >
> >> > > >5. ASN module:
> >> > > >part1a.asn(352) : warning XXXXX: The imported symbol
> 'id-ad' is never
> >> > > >referenced
> >> > >
> >> > > Agree. I removed it.
> >> > >
> >> > > Russ
> >> > >
> >> > >
> >> >
> >> > jim
> >>
> >>--
> >>____________________________________________________________
> >>Stephen Farrell
> >>Baltimore Technologies,   tel: (direct line) [phone]
> >>39 Parkgate Street,                     fax: [phone]
> >>Dublin 8.                mailto:[e-mail]
> >>Ireland                             http://www.baltimore.com
>
>



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA15849 for <[e-mail]>; Wed, 18 Apr 2001 08:23:23 -0700 (PDT)
Received: by balinese.baltimore.ie; id QAA18337; Wed, 18 Apr 2001 16:23:22 +0100 (GMT/IST)
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma017923; Wed, 18 Apr 01 16:22:37 +0100
Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Wed, 18 Apr 2001 16:21:27 +0100
Received: from baltimore.ie (cis-flcat1.ie.baltimore.com [10.153.24.220]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA14643; Wed, 18 Apr 2001 16:25:52 +0100
Message-ID: <[e-mail]>
Date: Wed, 18 Apr 2001 16:22:36 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

I thought it was clearer first time! But its still ok.

Stephen.

Russ Housley wrote:
> 
> Tim Polk and I just got off the phone.  After a lengthy discussion, we
> propose a revision to the cRLSign discussion:
> 
>        The cRLSign bit is asserted when the subject public key is used
>        for verifying a signature on revocation information (e.g., a CRL).
>        This bit MUST be asserted in CA certificates that are used to
>        verify signatures on CRLs.  If the cRLSign bit is asserted in a CA
>        certificate, then the cA bit in the basic constraints extension
>        (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
>        asserted in a non-CA certificate, then the cA bit in the basic
>        constraints extension MUST NOT be asserted.  Such non-CA
>        certificates MUST NOT be used to verify signatures on CRLs
>        containing revocation information for public key certificates;
>        however, these non-CA certificates MAY be used to verify
>        signatures on CRLs containing revocation information concerning
>        other types of certificates (e.g., attribute certificates).  If
>        neither the cRLSign bit nor the keyCertSign bit are asserted, then
>        the cA bit in the basic constraints extension MUST NOT be
>        asserted.
> 
> Hey, this section was only one sentence in RFC 2459...
> 
> Please let us know if anyone has any remaining concerns.
> 
> Russ
> 
> At 09:25 AM 4/18/2001 -0400, Russ Housley wrote:
> >Based on this discussion, I think that the working group wants the
> >keyCertSign and cRLSign key usage text to read as follows:
> >
> >       The keyCertSign bit is asserted when the subject public key is
> >       used for verifying a signature on public key certificates.  This
> >       bit MUST only be asserted in CA certificates.  If the keyCertSign
> >       bit is asserted, then the cA bit in the basic constraints
> >       extension (see 4.2.1.10) MUST also be asserted.  If neither the
> >       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> >       The cRLSign bit is asserted when the subject public key is used
> >       for verifying a signature on certificate revocation lists (CRLs).
> >       This bit MUST only be asserted in CA certificates and Attribute
> >       Authority (AA) certificates.  If the cRLSign bit is asserted in a
> >       CA certificate, then the cA bit in the basic constraints extension
> >       (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
> >       asserted in an AA certificate, then the cA bit in the basic
> >       constraints extension MUST NOT be asserted.  If neither the
> >       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> >Let me know if you disagree.
> >
> >Russ
> >
> >At 02:31 PM 4/17/2001 +0100, Stephen Farrell wrote:
> >
> >>I'd also go along with Jim here - that an AA be allowed to
> >>have cRLSign set without having cA set in basicConstraints,
> >>i.e. that AA's be an exception to the general rule for EE's
> >>and that this be explicitly called out in son-of-2459. I'm
> >>assuming that keyCertSign is therefore not set for AA's too
> >>(and the text for keyCertSign shouldn't say "certificates",
> >>but "public key certificates").
> >>
> >>Stephen.
> >>
> >>Jim Schaad wrote:
> >> >
> >> > Russ,
> >> >
> >> > > -----Original Message-----
> >> > > From: Russ Housley [mailto:[e-mail]]
> >> > > Sent: Monday, April 16, 2001 10:33 AM
> >> > > To: [e-mail]
> >> > > Cc: [e-mail]
> >> > > Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
> >> > >
> >> > >
> >> > > Jim:
> >> > >
> >> > > >1. As currently written in section 4.2.1.3, it is not
> >> > > possible for a non-CA
> >> > > >CRL issuer to be created for attribute certificates.  Was
> >> > > this the final
> >> > > >resolution of this issue?  This seems to me to be
> >> > > problematic as it means as
> >> > > >an end-user one can issue an attribute certificate, but one
> >> > > must always use
> >> > > >a different agent, which is a CA, to issue the CRLs.  This
> >> > > means that all
> >> > > >attribute CRL issuers are indirect.
> >> > >
> >> > > I do not recall a consensus on this point.  Should an AA that
> >> > > supports CRLs
> >> > > have the cRLSign bit set in its public key certificate?  If
> >> > > so, this text
> >> > > must change.
> >> >
> >> > I don't recall anything except private discussions on this issue.  It is
> >> > here for the mailing list to comment on.
> >> >
> >> > It is my option that an AA that supports CRLs SHOULD have the cRLSign bit
> >> > set.  Either that or we ask X509 to create AACertSign and AACrlSign
> >> bits and
> >> > keep this current text as is.
> >> >
> >> > >
> >> > > >2. Section 4.2.1.3, paragraph last:  Current Text: "set in
> >> > > An instantiation"
> >> > > >modify to "set in an instantiation".
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >3. Section 6.2 paragraph 2: change "prresented" to "presented"
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >4. Section 6.2 paragraph 2:  The text "For example, an
> >> > > implementation may
> >> > > >specify name constraints that apply to a specific trust
> >> > > anchor." is diffcult
> >> > > >for me given that the validation algorithm explicitly states
> >> > > that name
> >> > > >constraints are not applied to self signed certificates. Suggest "For
> >> > > >example, an implemenation may modify the algorithm to apply
> >> > > name constaints
> >> > > >during the initialization phase."
> >> > >
> >> > > Self-signed certificates are a common mechanism for
> >> > > distributing public
> >> > > keys for trust anchors, but they are not a mandated
> >> > > mechanism.  That said,
> >> > > I think that your text it an improvement.   How about a hybrid:
> >> > >
> >> > >     For example, an implementation MAY modify the algorithm
> >> > >     to apply name constraints to a specific trust anchor
> >> > >     during the initialization phase.
> >> >
> >> > I have no problems with this new text.
> >> >
> >> > >
> >> > > >5. ASN module:
> >> > > >part1a.asn(352) : warning XXXXX: The imported symbol 'id-ad' is never
> >> > > >referenced
> >> > >
> >> > > Agree. I removed it.
> >> > >
> >> > > Russ
> >> > >
> >> > >
> >> >
> >> > jim
> >>
> >>--
> >>____________________________________________________________
> >>Stephen Farrell
> >>Baltimore Technologies,   tel: (direct line) [phone]
> >>39 Parkgate Street,                     fax: [phone]
> >>Dublin 8.                mailto:[e-mail]
> >>Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA13363 for <[e-mail]>; Wed, 18 Apr 2001 08:08:04 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Apr 2001 15:05:25 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA11714 for <[e-mail]>; Wed, 18 Apr 2001 11:08:02 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 18 Apr 2001 11:06:32 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
In-Reply-To: <[e-mail]. com>
References: <[e-mail]> <000801c0c6a7$60e9d870$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Tim Polk and I just got off the phone.  After a lengthy discussion, we 
propose a revision to the cRLSign discussion:

       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on revocation information (e.g., a CRL).
       This bit MUST be asserted in CA certificates that are used to
       verify signatures on CRLs.  If the cRLSign bit is asserted in a CA
       certificate, then the cA bit in the basic constraints extension
       (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
       asserted in a non-CA certificate, then the cA bit in the basic
       constraints extension MUST NOT be asserted.  Such non-CA
       certificates MUST NOT be used to verify signatures on CRLs
       containing revocation information for public key certificates;
       however, these non-CA certificates MAY be used to verify
       signatures on CRLs containing revocation information concerning
       other types of certificates (e.g., attribute certificates).  If
       neither the cRLSign bit nor the keyCertSign bit are asserted, then
       the cA bit in the basic constraints extension MUST NOT be
       asserted.

Hey, this section was only one sentence in RFC 2459...

Please let us know if anyone has any remaining concerns.

Russ


At 09:25 AM 4/18/2001 -0400, Russ Housley wrote:
>Based on this discussion, I think that the working group wants the 
>keyCertSign and cRLSign key usage text to read as follows:
>
>       The keyCertSign bit is asserted when the subject public key is
>       used for verifying a signature on public key certificates.  This
>       bit MUST only be asserted in CA certificates.  If the keyCertSign
>       bit is asserted, then the cA bit in the basic constraints
>       extension (see 4.2.1.10) MUST also be asserted.  If neither the
>       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
>       in the basic constraints extension MUST NOT be asserted.
>
>       The cRLSign bit is asserted when the subject public key is used
>       for verifying a signature on certificate revocation lists (CRLs).
>       This bit MUST only be asserted in CA certificates and Attribute
>       Authority (AA) certificates.  If the cRLSign bit is asserted in a
>       CA certificate, then the cA bit in the basic constraints extension
>       (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
>       asserted in an AA certificate, then the cA bit in the basic
>       constraints extension MUST NOT be asserted.  If neither the
>       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
>       in the basic constraints extension MUST NOT be asserted.
>
>Let me know if you disagree.
>
>Russ
>
>At 02:31 PM 4/17/2001 +0100, Stephen Farrell wrote:
>
>>I'd also go along with Jim here - that an AA be allowed to
>>have cRLSign set without having cA set in basicConstraints,
>>i.e. that AA's be an exception to the general rule for EE's
>>and that this be explicitly called out in son-of-2459. I'm
>>assuming that keyCertSign is therefore not set for AA's too
>>(and the text for keyCertSign shouldn't say "certificates",
>>but "public key certificates").
>>
>>Stephen.
>>
>>Jim Schaad wrote:
>> >
>> > Russ,
>> >
>> > > -----Original Message-----
>> > > From: Russ Housley [mailto:[e-mail]]
>> > > Sent: Monday, April 16, 2001 10:33 AM
>> > > To: [e-mail]
>> > > Cc: [e-mail]
>> > > Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
>> > >
>> > >
>> > > Jim:
>> > >
>> > > >1. As currently written in section 4.2.1.3, it is not
>> > > possible for a non-CA
>> > > >CRL issuer to be created for attribute certificates.  Was
>> > > this the final
>> > > >resolution of this issue?  This seems to me to be
>> > > problematic as it means as
>> > > >an end-user one can issue an attribute certificate, but one
>> > > must always use
>> > > >a different agent, which is a CA, to issue the CRLs.  This
>> > > means that all
>> > > >attribute CRL issuers are indirect.
>> > >
>> > > I do not recall a consensus on this point.  Should an AA that
>> > > supports CRLs
>> > > have the cRLSign bit set in its public key certificate?  If
>> > > so, this text
>> > > must change.
>> >
>> > I don't recall anything except private discussions on this issue.  It is
>> > here for the mailing list to comment on.
>> >
>> > It is my option that an AA that supports CRLs SHOULD have the cRLSign bit
>> > set.  Either that or we ask X509 to create AACertSign and AACrlSign 
>> bits and
>> > keep this current text as is.
>> >
>> > >
>> > > >2. Section 4.2.1.3, paragraph last:  Current Text: "set in
>> > > An instantiation"
>> > > >modify to "set in an instantiation".
>> > >
>> > > Fixed.
>> > >
>> > > >3. Section 6.2 paragraph 2: change "prresented" to "presented"
>> > >
>> > > Fixed.
>> > >
>> > > >4. Section 6.2 paragraph 2:  The text "For example, an
>> > > implementation may
>> > > >specify name constraints that apply to a specific trust
>> > > anchor." is diffcult
>> > > >for me given that the validation algorithm explicitly states
>> > > that name
>> > > >constraints are not applied to self signed certificates. Suggest "For
>> > > >example, an implemenation may modify the algorithm to apply
>> > > name constaints
>> > > >during the initialization phase."
>> > >
>> > > Self-signed certificates are a common mechanism for
>> > > distributing public
>> > > keys for trust anchors, but they are not a mandated
>> > > mechanism.  That said,
>> > > I think that your text it an improvement.   How about a hybrid:
>> > >
>> > >     For example, an implementation MAY modify the algorithm
>> > >     to apply name constraints to a specific trust anchor
>> > >     during the initialization phase.
>> >
>> > I have no problems with this new text.
>> >
>> > >
>> > > >5. ASN module:
>> > > >part1a.asn(352) : warning XXXXX: The imported symbol 'id-ad' is never
>> > > >referenced
>> > >
>> > > Agree. I removed it.
>> > >
>> > > Russ
>> > >
>> > >
>> >
>> > jim
>>
>>--
>>____________________________________________________________
>>Stephen Farrell
>>Baltimore Technologies,   tel: (direct line) [phone]
>>39 Parkgate Street,                     fax: [phone]
>>Dublin 8.                mailto:[e-mail]
>>Ireland                             http://www.baltimore.com



Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA07226 for <[e-mail]>; Wed, 18 Apr 2001 06:25:08 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Apr 2001 13:22:29 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA02350 for <[e-mail]>; Wed, 18 Apr 2001 09:25:08 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 18 Apr 2001 09:25:01 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
In-Reply-To: <[e-mail]>
References: <000801c0c6a7$60e9d870$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Based on this discussion, I think that the working group wants the 
keyCertSign and cRLSign key usage text to read as follows:

       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on public key certificates.  This
       bit MUST only be asserted in CA certificates.  If the keyCertSign
       bit is asserted, then the cA bit in the basic constraints
       extension (see 4.2.1.10) MUST also be asserted.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.

       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on certificate revocation lists (CRLs).
       This bit MUST only be asserted in CA certificates and Attribute
       Authority (AA) certificates.  If the cRLSign bit is asserted in a
       CA certificate, then the cA bit in the basic constraints extension
       (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
       asserted in an AA certificate, then the cA bit in the basic
       constraints extension MUST NOT be asserted.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.

Let me know if you disagree.

Russ

At 02:31 PM 4/17/2001 +0100, Stephen Farrell wrote:

>I'd also go along with Jim here - that an AA be allowed to
>have cRLSign set without having cA set in basicConstraints,
>i.e. that AA's be an exception to the general rule for EE's
>and that this be explicitly called out in son-of-2459. I'm
>assuming that keyCertSign is therefore not set for AA's too
>(and the text for keyCertSign shouldn't say "certificates",
>but "public key certificates").
>
>Stephen.
>
>Jim Schaad wrote:
> >
> > Russ,
> >
> > > -----Original Message-----
> > > From: Russ Housley [mailto:[e-mail]]
> > > Sent: Monday, April 16, 2001 10:33 AM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
> > >
> > >
> > > Jim:
> > >
> > > >1. As currently written in section 4.2.1.3, it is not
> > > possible for a non-CA
> > > >CRL issuer to be created for attribute certificates.  Was
> > > this the final
> > > >resolution of this issue?  This seems to me to be
> > > problematic as it means as
> > > >an end-user one can issue an attribute certificate, but one
> > > must always use
> > > >a different agent, which is a CA, to issue the CRLs.  This
> > > means that all
> > > >attribute CRL issuers are indirect.
> > >
> > > I do not recall a consensus on this point.  Should an AA that
> > > supports CRLs
> > > have the cRLSign bit set in its public key certificate?  If
> > > so, this text
> > > must change.
> >
> > I don't recall anything except private discussions on this issue.  It is
> > here for the mailing list to comment on.
> >
> > It is my option that an AA that supports CRLs SHOULD have the cRLSign bit
> > set.  Either that or we ask X509 to create AACertSign and AACrlSign 
> bits and
> > keep this current text as is.
> >
> > >
> > > >2. Section 4.2.1.3, paragraph last:  Current Text: "set in
> > > An instantiation"
> > > >modify to "set in an instantiation".
> > >
> > > Fixed.
> > >
> > > >3. Section 6.2 paragraph 2: change "prresented" to "presented"
> > >
> > > Fixed.
> > >
> > > >4. Section 6.2 paragraph 2:  The text "For example, an
> > > implementation may
> > > >specify name constraints that apply to a specific trust
> > > anchor." is diffcult
> > > >for me given that the validation algorithm explicitly states
> > > that name
> > > >constraints are not applied to self signed certificates. Suggest "For
> > > >example, an implemenation may modify the algorithm to apply
> > > name constaints
> > > >during the initialization phase."
> > >
> > > Self-signed certificates are a common mechanism for
> > > distributing public
> > > keys for trust anchors, but they are not a mandated
> > > mechanism.  That said,
> > > I think that your text it an improvement.   How about a hybrid:
> > >
> > >     For example, an implementation MAY modify the algorithm
> > >     to apply name constraints to a specific trust anchor
> > >     during the initialization phase.
> >
> > I have no problems with this new text.
> >
> > >
> > > >5. ASN module:
> > > >part1a.asn(352) : warning XXXXX: The imported symbol 'id-ad' is never
> > > >referenced
> > >
> > > Agree. I removed it.
> > >
> > > Russ
> > >
> > >
> >
> > jim
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>39 Parkgate Street,                     fax: [phone]
>Dublin 8.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com



Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA15257 for <[e-mail]>; Tue, 17 Apr 2001 13:18:06 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Apr 2001 20:15:29 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA23010; Tue, 17 Apr 2001 16:18:06 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 17 Apr 2001 12:10:24 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Comments to PKIX AC profile
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Steve:

I think that it is very important to align with the version 2 AC syntax in 
X.509-2000.

Since we mandate the implementation of version 2 AC and the X.509-2000 
version 1 AC syntax is not backward compatible with the original X.509-1997 
AC syntax, I suggest that  we drop the version 1 syntax from our document 
altogether.

Does this approach raise concerns?

Russ

At 02:13 PM 4/17/2001 +0100, Stephen Farrell wrote:

>Hi John,
>
>You're right about the EXPLICIT, but can't I just change the current
>module to (the 509-2000 compatible) IMPLICIT tagging rather than add a
>whole new module? (Maybe that's what you meant.)
>
>Same thing for clearance: I'll make the change you suggest.
>
>BTW: both of these break code, so anyone with code compliant to the
>-06 I-D, who has a reason not to make the change should yell about
>this now.
>
>Regards,
>Stephen (who just hates sneaky tagging:-)
>
>
>"Pawling, John" wrote:
> >
> > All,
> >
> > In a separate message, Stephen Henson reported an incompatibility between
> > the Attribute Certificate (AC) ASN.1 syntaxes defined in the PKIX AC 
> Profile
> > for Authorization <draft-ietf-pkix-ac509prof-06.txt> and draft 2000 X.509
> > Recommendation (4th Edition, Draft V7, 23 Feb 2001).
> > The PKIX AC Profile, Appendix B, ASN.1 module includes "DEFINITIONS 
> EXPLICIT
> > TAGS ::=", but the 2000 X.509 Recommendation ASN.1 module defining the AC
> > syntax includes "DEFINITIONS IMPLICIT TAGS ::=".  Recommend that the 
> PKIX AC
> > Profile should be changed so that the AC ASN.1 syntax is equivalent (i.e.
> > produces the identical ASN.1 hex encoding) to that defined in the draft 
> 2000
> > X.509 Recommendation.  This could be accomplished by moving the AC syntax
> > definition (and component syntax definitions) from the existing Appendix B
> > module to a new ASN.1 module that includes "DEFINITIONS IMPLICIT TAGS ::=".
> > That is the strategy used in the draft 2000 X.509 Recommendation.
> >
> > Also, recommend that ac509prof-06 file should be changed so that the
> > Clearance attribute ASN.1 syntax defined in Appendix B is equivalent to 
> that
> > defined in X.501.  X.501 defines the Clearance attribute syntax using
> > AUTOMATIC TAGS.  The Clearance attribute syntax in the PKIX AC profile
> > should be changed as follows to be consistent with X.501:
> >
> > Clearance ::= SEQUENCE
> >   {
> >       policyId
> >           [0] OBJECT IDENTIFIER,
> >       classList
> >           [1] ClassList DEFAULT {unclassified},
> >       securityCategories
> >           [2] SET OF SecurityCategory OPTIONAL
> >   }
> >
> > ===========================================
> > John Pawling, [e-mail]
> > Getronics Government Solutions, LLC
> > ===========================================
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>39 Parkgate Street,                     fax: [phone]
>Dublin 8.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA09636 for <[e-mail]>; Tue, 17 Apr 2001 12:19:23 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JDJ8PVW4>; Tue, 17 Apr 2001 15:18:53 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "500 list (E-mail)" <[e-mail]>
Cc: "pkix (E-mail)" <[e-mail]>
Subject: New Defect Report on X.509
Date: Tue, 17 Apr 2001 15:13:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C772.82519E00"

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_01C0C772.82519E00
Content-Type: text/plain;
	charset="iso-8859-1"

Based on a requirement from the IETF PKIX WG and their profile of X.509
public-key certificates, I've raised a new defect report on X.509 (DR 278).
The DR proposes modifying the text of clause 8.4.2.6 (4th edition) to lift
the restriction that the freshestCRL extension be ONLY a certificate
extension. This change aligns with the PKIX use of freshestCRL as a CRL
extension. The full DR can be obtained at:

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andR
elated/DR_278.pdf


Sharon

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>New Defect Report on X.509</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Based on a requirement from the IETF PKIX WG and =
their profile of X.509 public-key certificates, I've raised a new =
defect report on X.509 (DR 278). The DR proposes modifying the text of =
clause 8.4.2.6 (4th edition) to lift the restriction that the =
freshestCRL extension be ONLY a certificate extension. This change =
aligns with the PKIX use of freshestCRL as a CRL extension. The full DR =
can be obtained at:</FONT></P>

<P><FONT SIZE=3D2><A =
HREF=3D"ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectRepor=
ts/X.509andRelated/DR_278.pdf" =
TARGET=3D"_blank">ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/D=
efectReports/X.509andRelated/DR_278.pdf</A></FONT>
</P>
<BR>

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

</BODY>
</HTML>
------_=_NextPart_001_01C0C772.82519E00--


Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA19298 for <[e-mail]>; Tue, 17 Apr 2001 07:14:54 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FYW1D>; Tue, 17 Apr 2001 10:16:12 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "ietf-pkix@imc. org (E-mail)" <[e-mail]>
Subject: RE: Comments to PKIX AC profile
Date: Tue, 17 Apr 2001 10:16:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Stephen,

Thank you for your response.  I agree that you can just change "DEFINITIONS
EXPLICIT TAGS" to "DEFINITIONS IMPLICIT TAGS" in the current module.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]]
Sent: Tuesday, April 17, 2001 9:13 AM
To: Pawling, John
Cc: ietf-pkix@imc. org (E-mail)
Subject: Re: Comments to PKIX AC profile



Hi John,

You're right about the EXPLICIT, but can't I just change the current 
module to (the 509-2000 compatible) IMPLICIT tagging rather than add a 
whole new module? (Maybe that's what you meant.)

Same thing for clearance: I'll make the change you suggest.

BTW: both of these break code, so anyone with code compliant to the 
-06 I-D, who has a reason not to make the change should yell about 
this now.

Regards,
Stephen (who just hates sneaky tagging:-)


"Pawling, John" wrote:
> 
> All,
> 
> In a separate message, Stephen Henson reported an incompatibility between
> the Attribute Certificate (AC) ASN.1 syntaxes defined in the PKIX AC
Profile
> for Authorization <draft-ietf-pkix-ac509prof-06.txt> and draft 2000 X.509
> Recommendation (4th Edition, Draft V7, 23 Feb 2001).
> The PKIX AC Profile, Appendix B, ASN.1 module includes "DEFINITIONS
EXPLICIT
> TAGS ::=", but the 2000 X.509 Recommendation ASN.1 module defining the AC
> syntax includes "DEFINITIONS IMPLICIT TAGS ::=".  Recommend that the PKIX
AC
> Profile should be changed so that the AC ASN.1 syntax is equivalent (i.e.
> produces the identical ASN.1 hex encoding) to that defined in the draft
2000
> X.509 Recommendation.  This could be accomplished by moving the AC syntax
> definition (and component syntax definitions) from the existing Appendix B
> module to a new ASN.1 module that includes "DEFINITIONS IMPLICIT TAGS
::=".
> That is the strategy used in the draft 2000 X.509 Recommendation.
> 
> Also, recommend that ac509prof-06 file should be changed so that the
> Clearance attribute ASN.1 syntax defined in Appendix B is equivalent to
that
> defined in X.501.  X.501 defines the Clearance attribute syntax using
> AUTOMATIC TAGS.  The Clearance attribute syntax in the PKIX AC profile
> should be changed as follows to be consistent with X.501:
> 
> Clearance ::= SEQUENCE
>   {
>       policyId
>           [0] OBJECT IDENTIFIER,
>       classList
>           [1] ClassList DEFAULT {unclassified},
>       securityCategories
>           [2] SET OF SecurityCategory OPTIONAL
>   }
> 
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA15751 for <[e-mail]>; Tue, 17 Apr 2001 06:32:17 -0700 (PDT)
Received: by balinese.baltimore.ie; id OAA28713; Tue, 17 Apr 2001 14:32:17 +0100 (GMT/IST)
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma028283; Tue, 17 Apr 01 14:31:20 +0100
Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Tue, 17 Apr 2001 14:30:10 +0100
Received: from baltimore.ie (cis-flcat1.ie.baltimore.com [10.153.24.220]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA28743; Tue, 17 Apr 2001 14:34:29 +0100
Message-ID: <[e-mail]>
Date: Tue, 17 Apr 2001 14:31:18 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
References: <000801c0c6a7$60e9d870$[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

I'd also go along with Jim here - that an AA be allowed to 
have cRLSign set without having cA set in basicConstraints,
i.e. that AA's be an exception to the general rule for EE's
and that this be explicitly called out in son-of-2459. I'm
assuming that keyCertSign is therefore not set for AA's too
(and the text for keyCertSign shouldn't say "certificates",
but "public key certificates").

Stephen.

Jim Schaad wrote:
> 
> Russ,
> 
> > -----Original Message-----
> > From: Russ Housley [mailto:[e-mail]]
> > Sent: Monday, April 16, 2001 10:33 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
> >
> >
> > Jim:
> >
> > >1. As currently written in section 4.2.1.3, it is not
> > possible for a non-CA
> > >CRL issuer to be created for attribute certificates.  Was
> > this the final
> > >resolution of this issue?  This seems to me to be
> > problematic as it means as
> > >an end-user one can issue an attribute certificate, but one
> > must always use
> > >a different agent, which is a CA, to issue the CRLs.  This
> > means that all
> > >attribute CRL issuers are indirect.
> >
> > I do not recall a consensus on this point.  Should an AA that
> > supports CRLs
> > have the cRLSign bit set in its public key certificate?  If
> > so, this text
> > must change.
> 
> I don't recall anything except private discussions on this issue.  It is
> here for the mailing list to comment on.
> 
> It is my option that an AA that supports CRLs SHOULD have the cRLSign bit
> set.  Either that or we ask X509 to create AACertSign and AACrlSign bits and
> keep this current text as is.
> 
> >
> > >2. Section 4.2.1.3, paragraph last:  Current Text: "set in
> > An instantiation"
> > >modify to "set in an instantiation".
> >
> > Fixed.
> >
> > >3. Section 6.2 paragraph 2: change "prresented" to "presented"
> >
> > Fixed.
> >
> > >4. Section 6.2 paragraph 2:  The text "For example, an
> > implementation may
> > >specify name constraints that apply to a specific trust
> > anchor." is diffcult
> > >for me given that the validation algorithm explicitly states
> > that name
> > >constraints are not applied to self signed certificates. Suggest "For
> > >example, an implemenation may modify the algorithm to apply
> > name constaints
> > >during the initialization phase."
> >
> > Self-signed certificates are a common mechanism for
> > distributing public
> > keys for trust anchors, but they are not a mandated
> > mechanism.  That said,
> > I think that your text it an improvement.   How about a hybrid:
> >
> >     For example, an implementation MAY modify the algorithm
> >     to apply name constraints to a specific trust anchor
> >     during the initialization phase.
> 
> I have no problems with this new text.
> 
> >
> > >5. ASN module:
> > >part1a.asn(352) : warning XXXXX: The imported symbol 'id-ad' is never
> > >referenced
> >
> > Agree. I removed it.
> >
> > Russ
> >
> >
> 
> jim

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA13297 for <[e-mail]>; Tue, 17 Apr 2001 06:14:17 -0700 (PDT)
Received: by balinese.baltimore.ie; id OAA23693; Tue, 17 Apr 2001 14:14:16 +0100 (GMT/IST)
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma023458; Tue, 17 Apr 01 14:13:18 +0100
Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Tue, 17 Apr 2001 14:11:52 +0100
Received: from baltimore.ie (cis-flcat1.ie.baltimore.com [10.153.24.220]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA27985; Tue, 17 Apr 2001 14:16:10 +0100
Message-ID: <[e-mail]>
Date: Tue, 17 Apr 2001 14:13:00 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Pawling, John" <[e-mail]>
CC: "ietf-pkix@imc. org (E-mail)" <[e-mail]>
Subject: Re: Comments to PKIX AC profile
References: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi John,

You're right about the EXPLICIT, but can't I just change the current 
module to (the 509-2000 compatible) IMPLICIT tagging rather than add a 
whole new module? (Maybe that's what you meant.)

Same thing for clearance: I'll make the change you suggest.

BTW: both of these break code, so anyone with code compliant to the 
-06 I-D, who has a reason not to make the change should yell about 
this now.

Regards,
Stephen (who just hates sneaky tagging:-)


"Pawling, John" wrote:
> 
> All,
> 
> In a separate message, Stephen Henson reported an incompatibility between
> the Attribute Certificate (AC) ASN.1 syntaxes defined in the PKIX AC Profile
> for Authorization <draft-ietf-pkix-ac509prof-06.txt> and draft 2000 X.509
> Recommendation (4th Edition, Draft V7, 23 Feb 2001).
> The PKIX AC Profile, Appendix B, ASN.1 module includes "DEFINITIONS EXPLICIT
> TAGS ::=", but the 2000 X.509 Recommendation ASN.1 module defining the AC
> syntax includes "DEFINITIONS IMPLICIT TAGS ::=".  Recommend that the PKIX AC
> Profile should be changed so that the AC ASN.1 syntax is equivalent (i.e.
> produces the identical ASN.1 hex encoding) to that defined in the draft 2000
> X.509 Recommendation.  This could be accomplished by moving the AC syntax
> definition (and component syntax definitions) from the existing Appendix B
> module to a new ASN.1 module that includes "DEFINITIONS IMPLICIT TAGS ::=".
> That is the strategy used in the draft 2000 X.509 Recommendation.
> 
> Also, recommend that ac509prof-06 file should be changed so that the
> Clearance attribute ASN.1 syntax defined in Appendix B is equivalent to that
> defined in X.501.  X.501 defines the Clearance attribute syntax using
> AUTOMATIC TAGS.  The Clearance attribute syntax in the PKIX AC profile
> should be changed as follows to be consistent with X.501:
> 
> Clearance ::= SEQUENCE
>   {
>       policyId
>           [0] OBJECT IDENTIFIER,
>       classList
>           [1] ClassList DEFAULT {unclassified},
>       securityCategories
>           [2] SET OF SecurityCategory OPTIONAL
>   }
> 
> ===========================================
> John Pawling, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA12621 for <[e-mail]>; Tue, 17 Apr 2001 06:05:17 -0700 (PDT)
Received: by balinese.baltimore.ie; id OAA21739; Tue, 17 Apr 2001 14:05:17 +0100 (GMT/IST)
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma021628; Tue, 17 Apr 01 14:04:39 +0100
Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Tue, 17 Apr 2001 14:03:29 +0100
Received: from baltimore.ie (cis-flcat1.ie.baltimore.com [10.153.24.220]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA27620; Tue, 17 Apr 2001 14:07:47 +0100
Message-ID: <[e-mail]>
Date: Tue, 17 Apr 2001 14:04:37 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Hideyuki Odahara <[e-mail]>
CC: [e-mail]
Subject: Re: attributes in AC
References: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Slightly late response, but here it is...

Syntactically, the access identity attribute can't have the authInfo 
field present. This basically means that you should use the access
identity field if the relying party is willing to believe a straight
assertion from the AA about the holder's identity. In theory that 
should be enough, but it turns out that there are many applications
which still require a username & password to identify/authenticate
a user, so the service auth info attribute allows support for such
applications.

As an example of where this might apply, say you inegrate the AC
relying party code into a web server, with a set of web applications
being called from the web server. Now some of those applications
will simply accept a user identity passed from the web server, using
say the ssl client or holder field for identity, others will have their 
own concept of usernames (so you can use the access identity for those),
but still others will have their own username/password handling (so 
you can use service auth info and not bother the user with entry of
additional passwords).

Hope this makes it clearer,
Stephen.

Hideyuki Odahara wrote:
> 
> Please teach me the difference of the use of
> "Service Authentication Infomation" and "Access Identity"
> in Attribute Certificate, and how to use the "Access Identity"
> attribute if you have any concrete example.
> 
> It is described that "this is a different use to that intended
> for the svceAuthInfo attribute discribed in 4.4.1 above." at the
> page 19 in the internet-draft(draft-ietf-pkix-ac509prof).
> But there is no example what situation does it suit.
> 
> thanks
> 
> ----------
>   Hideyuki Odahara $B!'(B [e-mail]

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA06911 for <[e-mail]>; Mon, 16 Apr 2001 15:39:13 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA12218; Mon, 16 Apr 2001 18:39:04 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010403b70123bcc46f@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 16 Apr 2001 18:36:43 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 7:33 PM +0200 4/11/01, Peter Sylvester wrote:
>Effective only at time of generation seems somewhat difficult;
>it always happens later.
>
>What is the essential difference between some authentication
>handshake 'on line' or some exchange using S/MIME.
>
>Consider for example just signature on domain boundaries,
>
>Or between a user and and ISP relay in order to allow
>relaying from authorized users etc.

Non repudiation is largely an application layer issue, if one 
believes that a person is making a binding commitment when NR is 
mentioned. So, a signed authentication handshake might prove that 
someone accessed a site, but it does not say what the person did 
while accessing the site. Also, most authentication handshakes do not 
make provision for third party time stamping, an essential element of 
most non-repudiation schemes.  So, no, I don't view those sorts of 
signed transactions as being the same as an S/MIME message.

Steve


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA22858 for <[e-mail]>; Mon, 16 Apr 2001 12:11:54 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 16 Apr 2001 12:11:47 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 16 Apr 2001 12:11:46 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR2635JM>; Mon, 16 Apr 2001 12:10:46 -0700
Content-return: allowed
Date: Mon, 16 Apr 2001 12:10:45 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Extension name divergence between PKIX profile and X.509 4th Edition
To: "'Sharon Boeyen'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_FP5+iAhSY28L90bOh9gU2A)"

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_FP5+iAhSY28L90bOh9gU2A)
Content-type: text/plain; charset="iso-8859-1"

Sharon
 
Might aswell ensure that the pointer class can be used in any type
of certificate, any type of CRL, and any other type of "security token"
contemplated by X.509.
 
The signed XML work (outside IETF) is completing nicely, with
application to cert management, biometric data, inter-domain messaging 
and authorization. 
 
Signed XML objects can benefit from the generalized standardization of 
references to RevocationLists in X.509.
 
 -----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]]
Sent: Monday, April 16, 2001 11:34 AM
To: 'Russ Housley'; Sharon Boeyen
Cc: [e-mail]
Subject: RE: Extension name divergence between PKIX profile and X.509 4th
Edition



I'll raise a defect on the 509 list proposing this. I suspect it won't be
controversial.
 
Sharon

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Friday, April 13, 2001 2:26 PM
To: Sharon Boeyen
Cc: [e-mail]
Subject: RE: Extension name divergence between PKIX profile and X.509 4th
Edition


Sharon:

The inclusion of freshestCRL in either a certificate or CRL has been in the
document for quite some time. I think that it is very attractive for the
"pointer" within a certificate or CRL to have the same syntax and semantics.

If X.509 can accommodate this approach, I think it would be very helpful.  I
know that at least one implementation is using this approach.

Russ


At 07:33 PM 4/11/2001 -0400, Sharon Boeyen wrote:


David, I think this is a problem because X.509 states that the 
freshest CRL extension SHALL only be used as a certificate extension. 
The extension is identified by its OID and any other use of that OID 
is non conformant with its definition. X.509 currently has the delta info
extension to point 
from a CRL to related delta CRLs. If the syntax of that extension is 
insufficient, then one of the following should happen: 
- a new extension is defined that meets the need 
- syntax of delta info extension is extended or modified to satisfy the need

- text for freshest CRL extension is modified to allow it to be a
certificate 
as well as a CRL extension. 

The 3rd one sounds the simplest and least destructive. Since we are about to
send the current set of 
defects out for final ballot, this is timely. I don't recall specific
discussion 
that drove the freshest CRL to be a certificate only extension, but I think
the text was 
basically modelled after CRL DP extension. 

Is there firm agreement in PKIX that this is required? If so, we should
propose 
the change to the 509 list - This could either be done as part of the
current enhancements 
work (similar to the change that will allow subjectDirectoryAttributes to be
set as a critical 
extension) or it might be suitable for the defect process. 

Cheers, 
Sharon 


--Boundary_(ID_FP5+iAhSY28L90bOh9gU2A)
Content-type: text/html; charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=875055118-16042001>Sharon</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=875055118-16042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=875055118-16042001>Might 
aswell ensure that the pointer class can be used in any type</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=875055118-16042001>of 
certificate, any type of CRL,&nbsp;and any other type of "security 
token"</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=875055118-16042001>contemplated by&nbsp;</SPAN></FONT><FONT color=#0000ff 
face=Arial size=2><SPAN class=875055118-16042001>X.509.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=875055118-16042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=875055118-16042001>The 
signed XML work (outside IETF) is completing nicely, with</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=875055118-16042001>application to cert management, biometric data, 
inter-domain messaging </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=875055118-16042001>and 
authorization. </SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=875055118-16042001>Signed 
XML objects</SPAN></FONT><FONT face=Arial><FONT color=#0000ff size=2><SPAN 
class=875055118-16042001> can benefit from</SPAN></FONT><FONT color=#0000ff 
size=2><SPAN class=875055118-16042001> the generalized standardization of 
</SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff size=2><SPAN 
class=875055118-16042001>references to 
RevocationLists&nbsp;</SPAN></FONT></FONT><FONT face=Arial><FONT color=#0000ff 
size=2><SPAN class=875055118-16042001>in X.509.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff size=2><SPAN 
class=875055118-16042001></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=875055118-16042001>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Sharon Boeyen [mailto:[e-mail]]<BR><B>Sent:</B> Monday, April 
16, 2001 11:34 AM<BR><B>To:</B> 'Russ Housley'; Sharon Boeyen<BR><B>Cc:</B> 
[e-mail]<BR><B>Subject:</B> RE: Extension name divergence between PKIX 
profile and X.509 4th Edition<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"></FONT>
  <DIV><SPAN class=533013818-16042001><FONT color=#0000ff face=Arial size=2>I'll 
  raise a defect on the 509 list proposing this. I suspect it won't be 
  controversial.</FONT></SPAN></DIV>
  <DIV><SPAN class=533013818-16042001><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=533013818-16042001><FONT color=#0000ff face=Arial 
  size=2>Sharon</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Russ Housley 
    [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 13, 2001 
    2:26 PM<BR><B>To:</B> Sharon Boeyen<BR><B>Cc:</B> 
    [e-mail]<BR><B>Subject:</B> RE: Extension name divergence between 
    PKIX profile and X.509 4th Edition<BR><BR></FONT></DIV>Sharon:<BR><BR>The 
    inclusion of freshestCRL in either a certificate or CRL has been in the 
    document for quite some time. I think that it is very attractive for the 
    "pointer" within a certificate or CRL to have the same syntax and 
    semantics.<BR><BR>If X.509 can accommodate this approach, I think it would 
    be very helpful.&nbsp; I know that at least one implementation is using this 
    approach.<BR><BR>Russ<BR><BR><BR>At 07:33 PM 4/11/2001 -0400, Sharon Boeyen 
    wrote:<BR>
    <BLOCKQUOTE class=cite type="cite" cite><FONT size=2>David, I think this 
      is a problem because X.509 states that the <BR>freshest CRL extension 
      SHALL only be used as a certificate extension. <BR>The extension is 
      identified by its OID and any other use of that OID</FONT> <BR><FONT 
      size=2>is non conformant with its definition. X.509 currently has the 
      delta info extension to point</FONT> <BR><FONT size=2>from a CRL to 
      related delta CRLs. If the syntax of that extension is <BR>insufficient, 
      then one of the following should happen:</FONT> <BR><FONT size=2>- a new 
      extension is defined that meets the need</FONT> <BR><FONT size=2>- syntax 
      of delta info extension is extended or modified to satisfy the need</FONT> 
      <BR><FONT size=2>- text for freshest CRL extension is modified to allow it 
      to be a certificate <BR>as well as a CRL extension.</FONT> <BR><BR><FONT 
      size=2>The 3rd one sounds the simplest and least destructive. Since we are 
      about to send the current set of <BR>defects out for final ballot, this is 
      timely. I don't recall specific discussion <BR>that drove the freshest CRL 
      to be a certificate only extension, but I think the text was</FONT> 
      <BR><FONT size=2>basically modelled after CRL DP extension. <BR><BR>Is 
      there firm agreement in PKIX that this is required? If so, we should 
      propose <BR>the change to the 509 list - This could either be done as part 
      of the current enhancements <BR>work (similar to the change that will 
      allow subjectDirectoryAttributes to be set as a critical</FONT> <BR><FONT 
      size=2>extension) or it might be suitable for the defect process.</FONT> 
      <BR><BR><FONT size=2>Cheers,</FONT> <BR><FONT size=2>Sharon</FONT> 
    </BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_FP5+iAhSY28L90bOh9gU2A)--


Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA22265 for <[e-mail]>; Mon, 16 Apr 2001 11:56:50 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010416185421.CJAW26961.femail3.sdc1.sfba.home.com@revelation>; Mon, 16 Apr 2001 11:54:21 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Mon, 16 Apr 2001 11:59:33 -0700
Message-ID: <000801c0c6a7$60e9d870$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>

Russ,

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Monday, April 16, 2001 10:33 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
>
>
> Jim:
>
> >1. As currently written in section 4.2.1.3, it is not
> possible for a non-CA
> >CRL issuer to be created for attribute certificates.  Was
> this the final
> >resolution of this issue?  This seems to me to be
> problematic as it means as
> >an end-user one can issue an attribute certificate, but one
> must always use
> >a different agent, which is a CA, to issue the CRLs.  This
> means that all
> >attribute CRL issuers are indirect.
>
> I do not recall a consensus on this point.  Should an AA that
> supports CRLs
> have the cRLSign bit set in its public key certificate?  If
> so, this text
> must change.

I don't recall anything except private discussions on this issue.  It is
here for the mailing list to comment on.


It is my option that an AA that supports CRLs SHOULD have the cRLSign bit
set.  Either that or we ask X509 to create AACertSign and AACrlSign bits and
keep this current text as is.

>
> >2. Section 4.2.1.3, paragraph last:  Current Text: "set in
> An instantiation"
> >modify to "set in an instantiation".
>
> Fixed.
>
> >3. Section 6.2 paragraph 2: change "prresented" to "presented"
>
> Fixed.
>
> >4. Section 6.2 paragraph 2:  The text "For example, an
> implementation may
> >specify name constraints that apply to a specific trust
> anchor." is diffcult
> >for me given that the validation algorithm explicitly states
> that name
> >constraints are not applied to self signed certificates. Suggest "For
> >example, an implemenation may modify the algorithm to apply
> name constaints
> >during the initialization phase."
>
> Self-signed certificates are a common mechanism for
> distributing public
> keys for trust anchors, but they are not a mandated
> mechanism.  That said,
> I think that your text it an improvement.   How about a hybrid:
>
>     For example, an implementation MAY modify the algorithm
>     to apply name constraints to a specific trust anchor
>     during the initialization phase.

I have no problems with this new text.

>
> >5. ASN module:
> >part1a.asn(352) : warning XXXXX: The imported symbol 'id-ad' is never
> >referenced
>
> Agree. I removed it.
>
> Russ
>
>

jim



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA21547 for <[e-mail]>; Mon, 16 Apr 2001 11:39:25 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <JB2AFC7P>; Mon, 16 Apr 2001 14:38:57 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: [e-mail]
Subject: RE: Extension name divergence between PKIX profile and X.509 4th  Edition
Date: Mon, 16 Apr 2001 14:33:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C6A3.C550CE30"

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_01C0C6A3.C550CE30
Content-Type: text/plain

I'll raise a defect on the 509 list proposing this. I suspect it won't be
controversial.
 
Sharon

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Friday, April 13, 2001 2:26 PM
To: Sharon Boeyen
Cc: [e-mail]
Subject: RE: Extension name divergence between PKIX profile and X.509 4th
Edition


Sharon:

The inclusion of freshestCRL in either a certificate or CRL has been in the
document for quite some time. I think that it is very attractive for the
"pointer" within a certificate or CRL to have the same syntax and semantics.

If X.509 can accommodate this approach, I think it would be very helpful.  I
know that at least one implementation is using this approach.

Russ


At 07:33 PM 4/11/2001 -0400, Sharon Boeyen wrote:


David, I think this is a problem because X.509 states that the 
freshest CRL extension SHALL only be used as a certificate extension. 
The extension is identified by its OID and any other use of that OID 
is non conformant with its definition. X.509 currently has the delta info
extension to point 
from a CRL to related delta CRLs. If the syntax of that extension is 
insufficient, then one of the following should happen: 
- a new extension is defined that meets the need 
- syntax of delta info extension is extended or modified to satisfy the need

- text for freshest CRL extension is modified to allow it to be a
certificate 
as well as a CRL extension. 

The 3rd one sounds the simplest and least destructive. Since we are about to
send the current set of 
defects out for final ballot, this is timely. I don't recall specific
discussion 
that drove the freshest CRL to be a certificate only extension, but I think
the text was 
basically modelled after CRL DP extension. 

Is there firm agreement in PKIX that this is required? If so, we should
propose 
the change to the 509 list - This could either be done as part of the
current enhancements 
work (similar to the change that will allow subjectDirectoryAttributes to be
set as a critical 
extension) or it might be suitable for the defect process. 

Cheers, 
Sharon 


------_=_NextPart_001_01C0C6A3.C550CE30
Content-Type: text/html

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


<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=533013818-16042001><FONT face=Arial color=#0000ff size=2>I'll 
raise a defect on the 509 list proposing this. I suspect it won't be 
controversial.</FONT></SPAN></DIV>
<DIV><SPAN class=533013818-16042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=533013818-16042001><FONT face=Arial color=#0000ff 
size=2>Sharon</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Russ Housley 
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 13, 2001 2:26 
  PM<BR><B>To:</B> Sharon Boeyen<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> RE: Extension name divergence between 
  PKIX profile and X.509 4th Edition<BR><BR></FONT></DIV>Sharon:<BR><BR>The 
  inclusion of freshestCRL in either a certificate or CRL has been in the 
  document for quite some time. I think that it is very attractive for the 
  "pointer" within a certificate or CRL to have the same syntax and 
  semantics.<BR><BR>If X.509 can accommodate this approach, I think it would be 
  very helpful.&nbsp; I know that at least one implementation is using this 
  approach.<BR><BR>Russ<BR><BR><BR>At 07:33 PM 4/11/2001 -0400, Sharon Boeyen 
  wrote:<BR>
  <BLOCKQUOTE class=cite cite type="cite"><FONT size=2>David, I think this is 
    a problem because X.509 states that the <BR>freshest CRL extension SHALL 
    only be used as a certificate extension. <BR>The extension is identified by 
    its OID and any other use of that OID</FONT> <BR><FONT size=2>is non 
    conformant with its definition. X.509 currently has the delta info extension 
    to point</FONT> <BR><FONT size=2>from a CRL to related delta CRLs. If the 
    syntax of that extension is <BR>insufficient, then one of the following 
    should happen:</FONT> <BR><FONT size=2>- a new extension is defined that 
    meets the need</FONT> <BR><FONT size=2>- syntax of delta info extension is 
    extended or modified to satisfy the need</FONT> <BR><FONT size=2>- text for 
    freshest CRL extension is modified to allow it to be a certificate <BR>as 
    well as a CRL extension.</FONT> <BR><BR><FONT size=2>The 3rd one sounds the 
    simplest and least destructive. Since we are about to send the current set 
    of <BR>defects out for final ballot, this is timely. I don't recall specific 
    discussion <BR>that drove the freshest CRL to be a certificate only 
    extension, but I think the text was</FONT> <BR><FONT size=2>basically 
    modelled after CRL DP extension. <BR><BR>Is there firm agreement in PKIX 
    that this is required? If so, we should propose <BR>the change to the 509 
    list - This could either be done as part of the current enhancements 
    <BR>work (similar to the change that will allow subjectDirectoryAttributes 
    to be set as a critical</FONT> <BR><FONT size=2>extension) or it might be 
    suitable for the defect process.</FONT> <BR><BR><FONT size=2>Cheers,</FONT> 
    <BR><FONT size=2>Sharon</FONT> </BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0C6A3.C550CE30--


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA20864 for <[e-mail]>; Mon, 16 Apr 2001 11:26:37 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Apr 2001 18:24:01 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA02628; Mon, 16 Apr 2001 14:26:24 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 16 Apr 2001 13:32:49 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Cc: [e-mail]
In-Reply-To: <001701c0c472$b141a8c0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Jim:

>1. As currently written in section 4.2.1.3, it is not possible for a non-CA
>CRL issuer to be created for attribute certificates.  Was this the final
>resolution of this issue?  This seems to me to be problematic as it means as
>an end-user one can issue an attribute certificate, but one must always use
>a different agent, which is a CA, to issue the CRLs.  This means that all
>attribute CRL issuers are indirect.

I do not recall a consensus on this point.  Should an AA that supports CRLs 
have the cRLSign bit set in its public key certificate?  If so, this text 
must change.

>2. Section 4.2.1.3, paragraph last:  Current Text: "set in An instantiation"
>modify to "set in an instantiation".

Fixed.

>3. Section 6.2 paragraph 2: change "prresented" to "presented"

Fixed.

>4. Section 6.2 paragraph 2:  The text "For example, an implementation may
>specify name constraints that apply to a specific trust anchor." is diffcult
>for me given that the validation algorithm explicitly states that name
>constraints are not applied to self signed certificates. Suggest "For
>example, an implemenation may modify the algorithm to apply name constaints
>during the initialization phase."

Self-signed certificates are a common mechanism for distributing public 
keys for trust anchors, but they are not a mandated mechanism.  That said, 
I think that your text it an improvement.   How about a hybrid:

    For example, an implementation MAY modify the algorithm
    to apply name constraints to a specific trust anchor
    during the initialization phase.

>5. ASN module:
>part1a.asn(352) : warning XXXXX: The imported symbol 'id-ad' is never
>referenced

Agree. I removed it.

Russ



Received: from KVRA ([211.217.77.46]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA14071; Sat, 14 Apr 2001 08:39:40 -0700 (PDT)
From: [e-mail]
Message-ID: <000079eb7bf9$0000089b$[e-mail]>
To: <[e-mail]>
Subject: Customer Care Center                          22227
Date: Fri, 13 Apr 2001 06:05:59 -0800
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High

<HTML>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD>=
<TITLE>Take Control Of Your Conference Calls</TITLE><META http-equiv=3DCon=
tent-Type content=3D"text/html; charset=3Dwindows-1252"><META content=3D"M=
SHTML 5.50.4134.100" name=3DGENERATOR></HEAD><BODY vLink=3D#c0c0c0 link=3D=
#c0c0c0 bgColor=3D#000000 leftMargin=3D0><PRE><FONT face=3Darial,helvetica=
><HEAD><META content=3DFrontPage.Editor.Document name=3DProgId><DIV align=3D=
center><CENTER><TABLE height=3D789 cellSpacing=3D0 cellPadding=3D0 width=3D=
602 border=3D0><TBODY><TR vAlign=3Dtop><TD width=3D602 height=3D452><DIV a=
lign=3Dcenter><TABLE width=3D470 border=3D0><TBODY><TR><TD><P align=3Dcent=
er><FONT color=3D#0000ff size=3D7><B><FONT color=3D999999 size=3D6>Why Pay=
 More For Your </FONT></B></FONT><FONT color=3D#999999 size=3D6><B>Confere=
nce Calls?</B></FONT></P></TD></TR></TBODY></TABLE><TABLE width=3D352 bord=
er=3D0><TBODY><TR><TD><P align=3Dcenter><FONT color=3D#ff0000 size=3D5>Onl=
y <U><B>.18 Cents </B></U>per minute (Including long distance!)</FONT></P>=
</TD></TR></TBODY></TABLE></DIV><UL><UL><UL><UL><UL><LI><DIV align=3Dleft>=
<FONT color=3D999999 size=3D3><B>No setup fees</B></FONT></DIV><LI><DIV al=
ign=3Dleft><FONT color=3D999999 size=3D3><B>No contracts or monthly fees</=
B></FONT></DIV><LI><DIV align=3Dleft><FONT color=3D999999 size=3D3><B>Call=
 anytime, from anywhere, to anywhere</B></FONT></DIV><LI><DIV align=3Dleft=
><FONT color=3D999999 size=3D3><B>International Dial In 18 cents per minut=
e</B></FONT></DIV><LI><DIV align=3Dleft><FONT color=3D999999 size=3D3><B>C=
onnects up to 100 participants</B></FONT></DIV><LI><DIV align=3Dleft><FONT=
 color=3D999999 size=3D3><B>Operator Help available 24/7</B></FONT></DIV><=
/LI></UL></UL></UL></UL></UL><DIV align=3Dcenter><TABLE width=3D424 border=
=3D0><TBODY><TR><TD><DIV align=3Dcenter><FONT color=3D#ff0000 size=3D6><B>=
<FONT size=3D5>Get the best quality, the easiest to use,</FONT></B></FONT>=
 <FONT color=3D#ff0000 size=3D5><B>and lowest rate in the industry.</B></F=
ONT></DIV></TD></TR></TBODY></TABLE><TABLE width=3D300 border=3D0><TBODY><=
TR><TD height=3D73><DIV align=3Dcenter><P align=3Dcenter><FONT color=3D#99=
9999 size=3D4>If you like saving money, fill out the form below and one of=
 our consultants will contact you.</FONT></P></DIV></TD></TR></TBODY></TAB=
LE></DIV></BLOCKQUOTE></BLOCKQUOTE><DIV align=3Dcenter><P align=3Dcenter><=
FONT color=3D#ff0000 size=3D2>Required Input Field</FONT><FONT color=3D#ff=
0000 size=3D2>*</FONT></P><TABLE cellSpacing=3D0 borderColorDark=3D#333300=
 cellPadding=3D3 width=3D600 borderColorLight=3D#ffffcc><TBODY><TR><TD><FO=
RM action=3D"mailto:[e-mail]?subject=3DConference_Inquiry" meth=
od=3Dpost encType=3Dtext/plain><DIV align=3Dcenter><TABLE width=3D"100%"><=
TBODY><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvet=
ica, sans-serif" color=3D#ff0000 size=3D2>Name*</FONT></DIV></TD><TD width=
=3D"51%"><FONT color=3D#ff0000><INPUT name=3DNAME> </FONT></TD></TR><TR><T=
D width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetica, sans-se=
rif" color=3D#ff0000 size=3D2>Web Address*</FONT></DIV></TD><TD width=3D"5=
1%"><FONT color=3D#ff0000><INPUT value=3Dhttp:// name=3DURL> </FONT></TD><=
/TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetic=
a, sans-serif" color=3D#ff0000 size=3D2>Company Name*</FONT></DIV></TD><TD=
 width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DCOMPANY_NAME> </FONT></=
TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helv=
etica, sans-serif" color=3D#ff0000 size=3D2>State</FONT></DIV></TD><TD wid=
th=3D"51%"><FONT color=3D#ff0000><INPUT size=3D2 name=3DSTATE> </FONT></TD=
></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvet=
ica, sans-serif" color=3D#ff0000 size=3D2>Business Phone*</FONT></DIV></TD=
><TD width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DBUS_PHONE> </FONT><=
/TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Hel=
vetica, sans-serif" color=3D#ff0000 size=3D2>Home Phone</FONT></DIV></TD><=
TD width=3D"51%"><FONT color=3D#ff0000><INPUT name=3DHOME_PHONE> </FONT></=
TD></TR><TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helv=
etica, sans-serif" color=3D#ff0000 size=3D2>E-mail*</FONT></DIV></TD><TD w=
idth=3D"51%"><FONT color=3D#ff0000><INPUT name=3DEMAIL> </FONT></TD></TR><=
TR><TD width=3D"49%"><DIV align=3Dright><FONT face=3D"Arial, Helvetica, sa=
ns-serif" color=3D#ff0000 size=3D2>Type of Business</FONT></DIV></TD><TD w=
idth=3D"51%"><FONT color=3D#ff0000><INPUT name=3DTYPE_OF_BUSINESS> </FONT>=
</TD></TR></TBODY></TABLE><P><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;<DIV align=3Dcenter><INPUT type=3Dsubmit value=3D"Submit In=
formation" name=3Dsubmit><P align=3Dcenter></BR><B></BR><FONT color=3D9999=
99 face=3D"Arial, Helvetica, sans-serif" size=3D5><P align=3Dcenter>This c=
ould be your ad!</FONT></B><FONT face=3D"Arial, Helvetica, sans-serif" siz=
e=3D2><BR><A href=3D"mailto:[e-mail]?subject=3DDirect Marketin=
g"><FONT color=3Dff0000>Click here to e-mail us your contact info</A>.</FO=
NT></P><P align=3Dcenter><FONT face=3D"Arial, Helvetica, sans-serif" color=
=3D#999999 size=3D1>This email is to those persons that have contacted Con=
ference Calls for Less regarding available services or product information=
.  If this email is reaching you in error and you feel that you have not c=
ontacted us, <A href=3D"mailto:[e-mail]?subject=3DRemove_Confere=
nce">click here</A>. We apologize and will gladly remove you from our mail=
ing list.</FONT></P></DIV></DIV></BODY>

</BODY>
</HTML>





Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id SAA06948 for <[e-mail]>; Fri, 13 Apr 2001 18:36:10 -0700 (PDT)
Received: from 157.54.7.67 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Apr 2001 18:35:44 -0700 (Pacific Daylight Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 13 Apr 2001 18:34:27 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Updates to CMC draft.
Date: Fri, 13 Apr 2001 18:34:28 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Updates to CMC draft.
Thread-Index: AcCv+qI5R4X2WouPQ8eLA4qIXQ3nNwUiA3yQ
From: "David Cross" <[e-mail]>
To: <[e-mail]>, "IETF-PKIX (E-mail)" <[e-mail]>
X-OriginalArrivalTime: 14 Apr 2001 01:34:27.0682 (UTC) FILETIME=[0B5DA420:01C0C483]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id SAA06949

Jim:

One item - 

5.6  Transaction Management Control Attributes

   The transactionId attribute identifies a given transaction.  It is
   used between client and server to manage the state of an operation.
   Clients MAY include a transactionID attribute in request messages.
   If the original request contains a transactionID attribute, all
   subsequent request and response messages MUST include the same
   transactionID attribute.  A server MUST use only transactionIds in
   the outermost PKIdata object. TransactionIds on inner PKIdata objects
   are for intermediate entities.


I think some clarification is in order for what the server SHOULD do.
It is implied because the client MAY include the transactionID, but does
cause some confusion for those reading for compliance.

 
David B. Cross




-----Original Message-----
From: Jim Schaad [mailto:[e-mail]] 
Sent: Sunday, March 18, 2001 2:27 PM
To: IETF-PKIX (E-mail)
Subject: Updates to CMC draft.


I have released a new CMC draft to the mailing list. This message
details the main changes in the draft from the RFC.

1.  A new success/failure status structure has been defined to allow for
secondary protocols to add new failure codes.  This was found
necessary/desirable when creating the Symmetric Key Distribution draft
in the S/MIME working group.

2.  A number of typos, edits and some unclear language was updated based
on the mail messages that I have received.

jim



Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA00541 for <[e-mail]>; Fri, 13 Apr 2001 16:34:38 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010413233211.FKSN13920.femail3.sdc1.sfba.home.com@revelation>; Fri, 13 Apr 2001 16:32:11 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "IETF-PKIX \(E-mail\)" <[e-mail]>
Cc: "Russ Housley \(E-mail\)" <[e-mail]>, "Tim Polk \(E-mail\)" <[e-mail]>
Subject: Last Call: draft-ietf-pkix-new-part1-06.txt comments
Date: Fri, 13 Apr 2001 16:37:23 -0700
Message-ID: <001701c0c472$b141a8c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

1. As currently written in section 4.2.1.3, it is not possible for a non-CA
CRL issuer to be created for attribute certificates.  Was this the final
resolution of this issue?  This seems to me to be problematic as it means as
an end-user one can issue an attribute certificate, but one must always use
a different agent, which is a CA, to issue the CRLs.  This means that all
attribute CRL issuers are indirect.

2. Section 4.2.1.3, paragraph last:  Current Text: "set in An instantiation"
modify to "set in an instantiation".

3. Section 6.2 paragraph 2: change "prresented" to "presented"

4. Section 6.2 paragraph 2:  The text "For example, an implementation may
specify name constraints that apply to a specific trust anchor." is diffcult
for me given that the validation algorithm explicitly states that name
constraints are not applied to self signed certificates. Suggest "For
example, an implemenation may modify the algorithm to apply name constaints
during the initialization phase."

5. ASN module:
part1a.asn(352) : warning XXXXX: The imported symbol 'id-ad' is never
referenced


jim



Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA13203 for <[e-mail]>; Fri, 13 Apr 2001 12:36:47 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Apr 2001 19:34:15 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA22548; Fri, 13 Apr 2001 15:36:31 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 13 Apr 2001 14:26:16 -0400
To: Sharon Boeyen <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Extension name divergence between PKIX profile and X.509 4th  Edition
Cc: [e-mail]
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
Sharon:<br>
<br>
The inclusion of freshestCRL in either a certificate or CRL has been in
the document for quite some time. I think that it is very attractive for
the &quot;pointer&quot; within a certificate or CRL to have the same
syntax and semantics.<br>
<br>
If X.509 can accommodate this approach, I think it would be very
helpful.&nbsp; I know that at least one implementation is using this
approach.<br>
<br>
Russ<br>
<br>
<br>
At 07:33 PM 4/11/2001 -0400, Sharon Boeyen wrote:<br>
<blockquote type=cite class=cite cite><font size=2>David, I think this is
a problem because X.509 states that the <br>
freshest CRL extension SHALL only be used as a certificate extension.
<br>
The extension is identified by its OID and any other use of that
OID</font> <br>
<font size=2>is non conformant with its definition. X.509 currently has
the delta info extension to point</font> <br>
<font size=2>from a CRL to related delta CRLs. If the syntax of that
extension is <br>
insufficient, then one of the following should happen:</font> <br>
<font size=2>- a new extension is defined that meets the need</font>
<br>
<font size=2>- syntax of delta info extension is extended or modified to satisfy the need</font> <br>
<font size=2>- text for freshest CRL extension is modified to allow it to be a certificate <br>
as well as a CRL extension.</font> <br>
<br>
<font size=2>The 3rd one sounds the simplest and least destructive. Since we are about to send the current set of <br>
defects out for final ballot, this is timely. I don't recall specific discussion <br>
that drove the freshest CRL to be a certificate only extension, but I think the text was</font> <br>
<font size=2>basically modelled after CRL DP extension. <br>
<br>
Is there firm agreement in PKIX that this is required? If so, we should propose <br>
the change to the 509 list - This could either be done as part of the current enhancements <br>
work (similar to the change that will allow subjectDirectoryAttributes to be set as a critical</font> <br>
<font size=2>extension) or it might be suitable for the defect process.</font> <br>
<br>
<font size=2>Cheers,</font> <br>
<font size=2>Sharon</font> </blockquote></html>



Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA07849 for <[e-mail]>; Fri, 13 Apr 2001 03:42:22 -0700 (PDT)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailg.telia.com (8.11.2/8.11.0) with ESMTP id f3DAgLH08376 for <[e-mail]>; Fri, 13 Apr 2001 12:42:21 +0200 (CEST)
Received: from mega (t7o69p237.telia.com [213.65.46.237]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f3DAgKa29555 for <[e-mail]>; Fri, 13 Apr 2001 12:42:21 +0200 (CEST)
Message-ID: <003901c0c406$243a9200$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>
Subject: Solving a hard MITM-problem
Date: Fri, 13 Apr 2001 12:40:20 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id DAA07850

Hi All,
Sorry for the ramblings regarding Domain-PKI etc.

Nevertheless I wonder if you security experts could (without refraining
to the impossibility of making secure serves, or claims that the EU
will have a global employee- PKI running in September), seriously take a look
on a problem that affect systems based on domain security in conjunction
with user's with web-browsers.  To this category belong: Purple, Shibboleth, 
MSFT's Passport(!), VISA's 3D Secure, and the coming OAISIS security services
standard.

ENTITIES:

Client: browser-user associated with an Attribute Authority (AA). 
Relying Party (RP).  The RP has a trust relationship with the AA.
The client's relation to the RP is indirect (typically an AA representative).

SCENARIO: 

The client wants to logon on a RP-controlled web-server with the use of an on-the-fly
created "ticket" that an AA web-server issues to the client on demand.  The ticket
contains a redirect to an RP URL.

PROBLEM DECRIPTION:

The client (user) will (hopefully) to his/her "own" organization (AA), long-term authenticate using
client-certificates which eliminates MITM-attacks using SSL.  At least the AA is protected from fake clients.

A potential problem with MITM SSL-attacks remains with the redirected client-to-RP server connection 
as it is not terminated by client-certificates as they are replaced by "tickets" that has no
key/cert-binding to the client.  I.e. a MITM-attacker could during the redirected SSL-connect to
the RP (ticket consumer) "snatch" the ticket and get access to the client's resources at the RP.
This attack on SSL has been described by others so it exists although it normally requires user
to accept a rogue cert.

So what to do? 

"Tweaking" SSL seems highly unlikely and I haven't come up with any nice tweaks that 
would work anyway. 

But I have found one *possible* way that could be implemented if schemes like Purple,
Shibboleth and OASIS security services become mainstream: 

The AA (Attribute authority making redirected tickets) could in the redirect indicate 
that it expects the RP server-cert to be signed by a CA known/accepted by the AA through the
use of an OCSP lookup URL + certID for the OCSP signer cert which is specified by the AA and
that there must be one-to-one redirect host-name correlation or  the redirect will not be carried out.
I.e. this would be a [technically] rather simple "fix" in a browser.  Could be migrated into
browsers any day without giving unwanted side-effects or incompatibilities.

What do U think? 

Regards 
Anders Rundgren




Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA06331 for <[e-mail]>; Wed, 11 Apr 2001 19:42:05 -0700 (PDT)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id <2LAWZTX4>; Wed, 11 Apr 2001 19:37:54 -0700
Message-ID: <[e-mail]>
From: "Covey, Carlin" <[e-mail]>
To: "'Sharon Boeyen '" <[e-mail]>, "''David A. Cooper' '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>
Subject: RE: Extension name divergence between PKIX profile and X.509 4th  Edition
Date: Wed, 11 Apr 2001 19:37:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text/plain; charset="iso-8859-1"

 Sharon and David,

If X.509 is willing to accept "Freshest CRL" as both a
certificate extension and a CRL extension, I prefer that
option.  

- Carlin Covey
  Cylink Corp.

-----Original Message-----
From: Sharon Boeyen
To: 'David A. Cooper'; '[e-mail] '
Sent: 4/11/01 4:33 PM
Subject: RE: Extension name divergence between PKIX profile and X.509 4th
Edition

David, I think this is a problem because X.509 states that the 
freshest CRL extension SHALL only be used as a certificate extension. 
The extension is identified by its OID and any other use of that OID 
is non conformant with its definition. X.509 currently has the delta
info extension to point 
from a CRL to related delta CRLs. If the syntax of that extension is 
insufficient, then one of the following should happen: 
- a new extension is defined that meets the need 
- syntax of delta info extension is extended or modified to satisfy the
need 
- text for freshest CRL extension is modified to allow it to be a
certificate 
as well as a CRL extension. 

The 3rd one sounds the simplest and least destructive. Since we are
about to send the current set of 
defects out for final ballot, this is timely. I don't recall specific
discussion 
that drove the freshest CRL to be a certificate only extension, but I
think the text was 
basically modelled after CRL DP extension. 

Is there firm agreement in PKIX that this is required? If so, we should
propose 
the change to the 509 list - This could either be done as part of the
current enhancements 
work (similar to the change that will allow subjectDirectoryAttributes
to be set as a critical 
extension) or it might be suitable for the defect process. 

Cheers, 
Sharon 
> -----Original Message----- 
> From: David A. Cooper [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, April 11, 2001 5:31 PM 
> To: '[e-mail] ' 
> Subject: Re: Extension name divergence between PKIX profile and X.509 
> 4th Edition 
> 
> 
> Carlin, 
> 
> This is something that was briefly discussed on the list in 
> early March (see messages with the subject "RE: WG Last Call: 
> Son-of-2459: More about delta-CRLs" in the mail list 
> archive). I don't think there is any problem with what PKIX 
> has done. PKIX has simply chosen (1) not to include the 
> deltaInfo extension in its profile and (2) to specify a 
> private Internet extension for CRLs, freshestCRL. Granted, 
> the freshestCRL CRL extension uses the same OID as a 
> certificate-only extension defined in X.509. But, since the 
> syntax and semantics are the same and they are distinguished 
> by their location (certificate vs. CRL), I don't think this 
> should cause any confusion. 
> 
> During the earlier discussion, there seemed to be a desire by 
> some to specify whether the pointer to delta-CRLs should be 
> in the certificate or the CRL, and most seemed to prefer to 
> place this information in the CRL. If one is going to do 
> this, then there is the choice between the deltaInfo 
> extension and the freshestCRL extension. One possible 
> advantage of the freshestCRL extension over the deltaInfo 
> extension is that it is more flexible. Of course, this added 
> flexibility may mean additional implementation complexity. 
> 
> There wasn't really much of a debate in March over whether 
> delta-CRL information should be placed in certificates or 
> CRLs, and if in CRLs whether to use the PKIX freshestCRL 
> extension or the X.509 deltaInfo extension. If you have any 
> thoughts, I'd be interested in hearing them. 
> 
> Dave 
> 
> At 12:48 PM 4/11/01 -0700, Covey, Carlin wrote: 
> >There appears to be a bit of divergence between certain 
> extension names and 
> >definitions used in X.509 4th Edition 
> X.509_4thEditionDraftV6.pdf and the 
> >PKIX profile (draft-ietf-pkix-new-part1-05.txt). 
> > 
> >draft-ietf-pkix-new-part1-05.txt describes a "Freshest CRL" 
> extension (which 
> >is also called "Delta CRL Distribution Point").  The 
> extension is described 
> >in section 4.2.1.16, a subsection under 4.2 Standard 
> Certificate Extensions, 
> >and it is described again in section 5.2.6, a subsection 
> under 5.2 CRL 
> >Extensions.  So according to the PKIX profile the extension 
> appears to be 
> >usable as either a certificate extension or a CRL extension, 
> with identical 
> >syntax.  Section 8.6.2.6 of X.509 4th edition draft V6 
> describes a "Freshest 
> >CRL Extension" with the same syntax as in the PKIX profile, 
> but says it 
> >shall be used only as a certificate extension.  There is a 
> CRL extension 
> >defined in X.509 called "Delta Information extension" whose 
> usage appears to 
> >more or less match the PKIX CRL extension "Freshest CRL," 
> but whose syntax 
> >is not the same as the X.509 "Freshest CRL" certificate extension.  
> > 
> >Are my document versions out of date, or is this divergence 
> intentional, or 
> >is it time for a little mid-course correction? 
> > 
> >- Carlin Covey 
> >   Cylink Corporation 
> 
> 



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA26873 for <[e-mail]>; Wed, 11 Apr 2001 16:38:59 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <2W9NHL1Z>; Wed, 11 Apr 2001 19:38:32 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David A. Cooper'" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: Extension name divergence between PKIX profile and X.509 4th  Edition
Date: Wed, 11 Apr 2001 19:33:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C2DF.D58829A0"

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_01C0C2DF.D58829A0
Content-Type: text/plain

David, I think this is a problem because X.509 states that the 
freshest CRL extension SHALL only be used as a certificate extension. 
The extension is identified by its OID and any other use of that OID
is non conformant with its definition. X.509 currently has the delta info
extension to point
from a CRL to related delta CRLs. If the syntax of that extension is 
insufficient, then one of the following should happen:
- a new extension is defined that meets the need
- syntax of delta info extension is extended or modified to satisfy the need
- text for freshest CRL extension is modified to allow it to be a
certificate 
as well as a CRL extension.

The 3rd one sounds the simplest and least destructive. Since we are about to
send the current set of 
defects out for final ballot, this is timely. I don't recall specific
discussion 
that drove the freshest CRL to be a certificate only extension, but I think
the text was
basically modelled after CRL DP extension. 

Is there firm agreement in PKIX that this is required? If so, we should
propose 
the change to the 509 list - This could either be done as part of the
current enhancements 
work (similar to the change that will allow subjectDirectoryAttributes to be
set as a critical
extension) or it might be suitable for the defect process.

Cheers,
Sharon
> -----Original Message-----
> From: David A. Cooper [mailto:[e-mail]]
> Sent: Wednesday, April 11, 2001 5:31 PM
> To: '[e-mail] '
> Subject: Re: Extension name divergence between PKIX profile and X.509
> 4th Edition
> 
> 
> Carlin,
> 
> This is something that was briefly discussed on the list in 
> early March (see messages with the subject "RE: WG Last Call: 
> Son-of-2459: More about delta-CRLs" in the mail list 
> archive). I don't think there is any problem with what PKIX 
> has done. PKIX has simply chosen (1) not to include the 
> deltaInfo extension in its profile and (2) to specify a 
> private Internet extension for CRLs, freshestCRL. Granted, 
> the freshestCRL CRL extension uses the same OID as a 
> certificate-only extension defined in X.509. But, since the 
> syntax and semantics are the same and they are distinguished 
> by their location (certificate vs. CRL), I don't think this 
> should cause any confusion.
> 
> During the earlier discussion, there seemed to be a desire by 
> some to specify whether the pointer to delta-CRLs should be 
> in the certificate or the CRL, and most seemed to prefer to 
> place this information in the CRL. If one is going to do 
> this, then there is the choice between the deltaInfo 
> extension and the freshestCRL extension. One possible 
> advantage of the freshestCRL extension over the deltaInfo 
> extension is that it is more flexible. Of course, this added 
> flexibility may mean additional implementation complexity.
> 
> There wasn't really much of a debate in March over whether 
> delta-CRL information should be placed in certificates or 
> CRLs, and if in CRLs whether to use the PKIX freshestCRL 
> extension or the X.509 deltaInfo extension. If you have any 
> thoughts, I'd be interested in hearing them.
> 
> Dave
> 
> At 12:48 PM 4/11/01 -0700, Covey, Carlin wrote:
> >There appears to be a bit of divergence between certain 
> extension names and
> >definitions used in X.509 4th Edition 
> X.509_4thEditionDraftV6.pdf and the
> >PKIX profile (draft-ietf-pkix-new-part1-05.txt).
> >
> >draft-ietf-pkix-new-part1-05.txt describes a "Freshest CRL" 
> extension (which
> >is also called "Delta CRL Distribution Point").  The 
> extension is described
> >in section 4.2.1.16, a subsection under 4.2 Standard 
> Certificate Extensions,
> >and it is described again in section 5.2.6, a subsection 
> under 5.2 CRL
> >Extensions.  So according to the PKIX profile the extension 
> appears to be
> >usable as either a certificate extension or a CRL extension, 
> with identical
> >syntax.  Section 8.6.2.6 of X.509 4th edition draft V6 
> describes a "Freshest
> >CRL Extension" with the same syntax as in the PKIX profile, 
> but says it
> >shall be used only as a certificate extension.  There is a 
> CRL extension
> >defined in X.509 called "Delta Information extension" whose 
> usage appears to
> >more or less match the PKIX CRL extension "Freshest CRL," 
> but whose syntax
> >is not the same as the X.509 "Freshest CRL" certificate extension.  
> >
> >Are my document versions out of date, or is this divergence 
> intentional, or
> >is it time for a little mid-course correction? 
> >
> >- Carlin Covey
> >   Cylink Corporation
> 
> 

------_=_NextPart_001_01C0C2DF.D58829A0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Extension name divergence between PKIX profile and X.509 4th Edition</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>David, I think this is a problem because X.509 states that the </FONT>
<BR><FONT SIZE=2>freshest CRL extension SHALL only be used as a certificate extension. </FONT>
<BR><FONT SIZE=2>The extension is identified by its OID and any other use of that OID</FONT>
<BR><FONT SIZE=2>is non conformant with its definition. X.509 currently has the delta info extension to point</FONT>
<BR><FONT SIZE=2>from a CRL to related delta CRLs. If the syntax of that extension is </FONT>
<BR><FONT SIZE=2>insufficient, then one of the following should happen:</FONT>
<BR><FONT SIZE=2>- a new extension is defined that meets the need</FONT>
<BR><FONT SIZE=2>- syntax of delta info extension is extended or modified to satisfy the need</FONT>
<BR><FONT SIZE=2>- text for freshest CRL extension is modified to allow it to be a certificate </FONT>
<BR><FONT SIZE=2>as well as a CRL extension.</FONT>
</P>

<P><FONT SIZE=2>The 3rd one sounds the simplest and least destructive. Since we are about to send the current set of </FONT>
<BR><FONT SIZE=2>defects out for final ballot, this is timely. I don't recall specific discussion </FONT>
<BR><FONT SIZE=2>that drove the freshest CRL to be a certificate only extension, but I think the text was</FONT>
<BR><FONT SIZE=2>basically modelled after CRL DP extension. </FONT>
</P>

<P><FONT SIZE=2>Is there firm agreement in PKIX that this is required? If so, we should propose </FONT>
<BR><FONT SIZE=2>the change to the 509 list - This could either be done as part of the current enhancements </FONT>
<BR><FONT SIZE=2>work (similar to the change that will allow subjectDirectoryAttributes to be set as a critical</FONT>
<BR><FONT SIZE=2>extension) or it might be suitable for the defect process.</FONT>
</P>

<P><FONT SIZE=2>Cheers,</FONT>
<BR><FONT SIZE=2>Sharon</FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: David A. Cooper [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, April 11, 2001 5:31 PM</FONT>
<BR><FONT SIZE=2>&gt; To: '[e-mail] '</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Extension name divergence between PKIX profile and X.509</FONT>
<BR><FONT SIZE=2>&gt; 4th Edition</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Carlin,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This is something that was briefly discussed on the list in </FONT>
<BR><FONT SIZE=2>&gt; early March (see messages with the subject &quot;RE: WG Last Call: </FONT>
<BR><FONT SIZE=2>&gt; Son-of-2459: More about delta-CRLs&quot; in the mail list </FONT>
<BR><FONT SIZE=2>&gt; archive). I don't think there is any problem with what PKIX </FONT>
<BR><FONT SIZE=2>&gt; has done. PKIX has simply chosen (1) not to include the </FONT>
<BR><FONT SIZE=2>&gt; deltaInfo extension in its profile and (2) to specify a </FONT>
<BR><FONT SIZE=2>&gt; private Internet extension for CRLs, freshestCRL. Granted, </FONT>
<BR><FONT SIZE=2>&gt; the freshestCRL CRL extension uses the same OID as a </FONT>
<BR><FONT SIZE=2>&gt; certificate-only extension defined in X.509. But, since the </FONT>
<BR><FONT SIZE=2>&gt; syntax and semantics are the same and they are distinguished </FONT>
<BR><FONT SIZE=2>&gt; by their location (certificate vs. CRL), I don't think this </FONT>
<BR><FONT SIZE=2>&gt; should cause any confusion.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; During the earlier discussion, there seemed to be a desire by </FONT>
<BR><FONT SIZE=2>&gt; some to specify whether the pointer to delta-CRLs should be </FONT>
<BR><FONT SIZE=2>&gt; in the certificate or the CRL, and most seemed to prefer to </FONT>
<BR><FONT SIZE=2>&gt; place this information in the CRL. If one is going to do </FONT>
<BR><FONT SIZE=2>&gt; this, then there is the choice between the deltaInfo </FONT>
<BR><FONT SIZE=2>&gt; extension and the freshestCRL extension. One possible </FONT>
<BR><FONT SIZE=2>&gt; advantage of the freshestCRL extension over the deltaInfo </FONT>
<BR><FONT SIZE=2>&gt; extension is that it is more flexible. Of course, this added </FONT>
<BR><FONT SIZE=2>&gt; flexibility may mean additional implementation complexity.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; There wasn't really much of a debate in March over whether </FONT>
<BR><FONT SIZE=2>&gt; delta-CRL information should be placed in certificates or </FONT>
<BR><FONT SIZE=2>&gt; CRLs, and if in CRLs whether to use the PKIX freshestCRL </FONT>
<BR><FONT SIZE=2>&gt; extension or the X.509 deltaInfo extension. If you have any </FONT>
<BR><FONT SIZE=2>&gt; thoughts, I'd be interested in hearing them.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dave</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At 12:48 PM 4/11/01 -0700, Covey, Carlin wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;There appears to be a bit of divergence between certain </FONT>
<BR><FONT SIZE=2>&gt; extension names and</FONT>
<BR><FONT SIZE=2>&gt; &gt;definitions used in X.509 4th Edition </FONT>
<BR><FONT SIZE=2>&gt; X.509_4thEditionDraftV6.pdf and the</FONT>
<BR><FONT SIZE=2>&gt; &gt;PKIX profile (draft-ietf-pkix-new-part1-05.txt).</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;draft-ietf-pkix-new-part1-05.txt describes a &quot;Freshest CRL&quot; </FONT>
<BR><FONT SIZE=2>&gt; extension (which</FONT>
<BR><FONT SIZE=2>&gt; &gt;is also called &quot;Delta CRL Distribution Point&quot;).&nbsp; The </FONT>
<BR><FONT SIZE=2>&gt; extension is described</FONT>
<BR><FONT SIZE=2>&gt; &gt;in section 4.2.1.16, a subsection under 4.2 Standard </FONT>
<BR><FONT SIZE=2>&gt; Certificate Extensions,</FONT>
<BR><FONT SIZE=2>&gt; &gt;and it is described again in section 5.2.6, a subsection </FONT>
<BR><FONT SIZE=2>&gt; under 5.2 CRL</FONT>
<BR><FONT SIZE=2>&gt; &gt;Extensions.&nbsp; So according to the PKIX profile the extension </FONT>
<BR><FONT SIZE=2>&gt; appears to be</FONT>
<BR><FONT SIZE=2>&gt; &gt;usable as either a certificate extension or a CRL extension, </FONT>
<BR><FONT SIZE=2>&gt; with identical</FONT>
<BR><FONT SIZE=2>&gt; &gt;syntax.&nbsp; Section 8.6.2.6 of X.509 4th edition draft V6 </FONT>
<BR><FONT SIZE=2>&gt; describes a &quot;Freshest</FONT>
<BR><FONT SIZE=2>&gt; &gt;CRL Extension&quot; with the same syntax as in the PKIX profile, </FONT>
<BR><FONT SIZE=2>&gt; but says it</FONT>
<BR><FONT SIZE=2>&gt; &gt;shall be used only as a certificate extension.&nbsp; There is a </FONT>
<BR><FONT SIZE=2>&gt; CRL extension</FONT>
<BR><FONT SIZE=2>&gt; &gt;defined in X.509 called &quot;Delta Information extension&quot; whose </FONT>
<BR><FONT SIZE=2>&gt; usage appears to</FONT>
<BR><FONT SIZE=2>&gt; &gt;more or less match the PKIX CRL extension &quot;Freshest CRL,&quot; </FONT>
<BR><FONT SIZE=2>&gt; but whose syntax</FONT>
<BR><FONT SIZE=2>&gt; &gt;is not the same as the X.509 &quot;Freshest CRL&quot; certificate extension.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Are my document versions out of date, or is this divergence </FONT>
<BR><FONT SIZE=2>&gt; intentional, or</FONT>
<BR><FONT SIZE=2>&gt; &gt;is it time for a little mid-course correction? </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;- Carlin Covey</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; Cylink Corporation</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C2DF.D58829A0--


Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA24630 for <[e-mail]>; Wed, 11 Apr 2001 15:51:50 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA83796; Wed, 11 Apr 2001 18:49:53 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id SAA114292; Wed, 11 Apr 2001 18:46:17 -0400
Importance: Normal
Subject: Re: Meaning of Non-repudiation
To: Stephen Kent <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 11 Apr 2001 18:50:57 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.7 |March 21, 2001) at 04/11/2001 06:51:19 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     IMHO, if X.509 had not been calling the bit in KeyUsage
"non-repudiation" for some years, I would prefer to put "Persistent Data
Authentication" into KeyUsage and define several different flavors of
non-repudiation in ExtendedKeyUsage, profiling non-repudiation services in
parallel with those ExtendedKeyUsage values.  This would also allow us to
define different levels of NR and put them into certificates in a natural
way.  However, they have been calling the bit "non-repudiation", and I'm
not sure we can change its meaning on the installed base of certificates
and on the X.509 group without an unusual level of unanimity and
near-certainty that it won't break anything.

          Tom Gindin




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA19227 for <[e-mail]>; Wed, 11 Apr 2001 14:45:23 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 11 Apr 2001 15:44:52 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Wed, 11 Apr 2001 15:44:46 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA19228

Oh, indeed it does.  The OID refers to the Dewey decimal system 
number of a book on the shelf in the public library of Grand Forks,
ND, which happens to be under water right now due to a flood, 
but if you go there and read the book, it will answer all of your 
questions.

"42"

Bob

>>> <[e-mail]> 04/11/01 03:01PM >>>
Actually by adding a simple OID structure to the NR bit
this whole problem goes away. The OID represents the type
of NR the bit signifies the state


--
Regards,
Todd
> [e-mail] wrote:
> > 
> > David,
> > 
> > >...Here is the litmus test: do you agree that in
> > >order to validate a signature on an S/MIME message (any message, for
> > >any purpose, signed by any entity), the NR bit must be set?
> > 
> > I certainly don't, because of the ambiguity caused by the uncertain
> > legalisms. I note that the certificates issued by DoD and contained on
> > the
> > Common Access Card, even those issued to federal contractors, DO
> > contain the NR bit, and for that reason I would be quite reluctant
> > personally to use such a certificate.
> 
> 
> That's why, if Steve doesn't want to change the name of the bit,
> definitions are essential.  Are we talking:
> 
> 1) non-binding (ephemeral) authentication vs. binding (persistent)
>    signatures, or
> 
> 2) non-legally-binding persistent signatures vs. legally-binding
>    persistent signatures.
> 
> We haven't had any success in two years of attempting to come to grips
> with 2.  I agree with Ed Gerck that problem 2 is important, but it
> cannot be solved with one bit in a certificate.  I agree with you
> that a bit that claims to address 2 should be deprecated.
> 
> Problem 1 is easily solved with one bit, as long as the definitions
> are unambiguous.  It would be preferable to rename the bit because
> the word NR is an obstacle to common understanding and agreement.
> But if agreement and understanding can occur without changing the
> name, that's fine with me.



Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA17716 for <[e-mail]>; Wed, 11 Apr 2001 14:31:13 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA16631 for <[e-mail]>; Wed, 11 Apr 2001 17:31:14 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 11 Apr 2001 17:30:33 -0400
To: "'[e-mail] '" <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: Extension name divergence between PKIX profile and X.509 4th Edition
In-Reply-To: <[e-mail] >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Carlin,

This is something that was briefly discussed on the list in early March (see messages with the subject "RE: WG Last Call: Son-of-2459: More about delta-CRLs" in the mail list archive). I don't think there is any problem with what PKIX has done. PKIX has simply chosen (1) not to include the deltaInfo extension in its profile and (2) to specify a private Internet extension for CRLs, freshestCRL. Granted, the freshestCRL CRL extension uses the same OID as a certificate-only extension defined in X.509. But, since the syntax and semantics are the same and they are distinguished by their location (certificate vs. CRL), I don't think this should cause any confusion.

During the earlier discussion, there seemed to be a desire by some to specify whether the pointer to delta-CRLs should be in the certificate or the CRL, and most seemed to prefer to place this information in the CRL. If one is going to do this, then there is the choice between the deltaInfo extension and the freshestCRL extension. One possible advantage of the freshestCRL extension over the deltaInfo extension is that it is more flexible. Of course, this added flexibility may mean additional implementation complexity.

There wasn't really much of a debate in March over whether delta-CRL information should be placed in certificates or CRLs, and if in CRLs whether to use the PKIX freshestCRL extension or the X.509 deltaInfo extension. If you have any thoughts, I'd be interested in hearing them.

Dave

At 12:48 PM 4/11/01 -0700, Covey, Carlin wrote:
>There appears to be a bit of divergence between certain extension names and
>definitions used in X.509 4th Edition X.509_4thEditionDraftV6.pdf and the
>PKIX profile (draft-ietf-pkix-new-part1-05.txt).
>
>draft-ietf-pkix-new-part1-05.txt describes a "Freshest CRL" extension (which
>is also called "Delta CRL Distribution Point").  The extension is described
>in section 4.2.1.16, a subsection under 4.2 Standard Certificate Extensions,
>and it is described again in section 5.2.6, a subsection under 5.2 CRL
>Extensions.  So according to the PKIX profile the extension appears to be
>usable as either a certificate extension or a CRL extension, with identical
>syntax.  Section 8.6.2.6 of X.509 4th edition draft V6 describes a "Freshest
>CRL Extension" with the same syntax as in the PKIX profile, but says it
>shall be used only as a certificate extension.  There is a CRL extension
>defined in X.509 called "Delta Information extension" whose usage appears to
>more or less match the PKIX CRL extension "Freshest CRL," but whose syntax
>is not the same as the X.509 "Freshest CRL" certificate extension.  
>
>Are my document versions out of date, or is this divergence intentional, or
>is it time for a little mid-course correction? 
>
>- Carlin Covey
>   Cylink Corporation




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA15596 for <[e-mail]>; Wed, 11 Apr 2001 14:10:37 -0700 (PDT)
Received: from [128.33.238.44] (TC051.BBN.COM [128.33.238.51]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA06180; Wed, 11 Apr 2001 17:10:37 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040eb6fa50022227@[128.33.238.44]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <p0501040ab6fa32eff970@[128.33.238.44]> <[e-mail]>
Date: Wed, 11 Apr 2001 14:22:40 -0400
To: "David P. Kemp" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

David,

>Stephen Kent wrote:
>>
>>  I do not anticipate any change to the NR bit in X.509 nor in PKIX.
>
>Fair enough.  But if the name of the bit is not changed, then the
>definition must be clarified, to avoid the ambiguity evident below:
>
>>  The main purpose for the NR bit is to allow a cert to be designated
>>  as NOT being associated with signatures used in NR transactions. This
>>  is a safety feature for the EE. By using a cert with the NR bit set
>>  to FALSE, the EE is explicitly stating that the signature generated
>>  with the corresponding private key is not be be considered binding,
>>  e.g., it is for authentication but not for non-repudiation.
>
>This is the problem - some people associate the words NR and "binding"
>with "creating an obligation".
>
>I agree completely with your "not considered binding", as long as there
>is an explicit statement that binding means persistent - i.e., effective
>for some time after generation, as opposed to effective only at the
>time of generation.  Here is the litmus test: do you agree that in
>order to validate a signature on an S/MIME message (any message, for
>any purpose, signed by any entity), the NR bit must be set?

I do view NR as a form of persistent authentication and integrity, 
but not all persistent forms are NR. Using your example, S/MIME 
offers me only one means of providing data origin authentication and 
integrity (at least when using RSA), i.e., signing a hash of the 
message I send. I want to be able to send an authenticated e-mail 
that says "Yes, I'll go along with that proposal" without risking 
that this informal message might later be construed to be a binding, 
non-repudiable communication. The NR bit should allow me to do that. 
I would like to have a different certificate (with a different key 
pair) reserved for transactions where I will be very careful about 
what I sign, where I sign it (not on some random machine with 
software unknown to me), etc.

Steve


Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA15173 for <[e-mail]>; Wed, 11 Apr 2001 14:02:25 -0700 (PDT)
From: [e-mail]
Received: from webmail.worldnet.att.net ([204.127.135.29]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Wed, 11 Apr 2001 21:01:42 +0000
Received: from [161.215.27.111] by webmail.worldnet.att.net; Wed, 11 Apr 2001 21:01:42 +0000
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Meaning of Non-repudiation
Date: Wed, 11 Apr 2001 21:01:42 +0000
X-Mailer: AT&T Message Center Version 1 (Mar 27 2001)
Message-Id: <[e-mail]>

Actually by adding a simple OID structure to the NR bit
this whole problem goes away. The OID represents the type
of NR the bit signifies the state


--
Regards,
Todd
> [e-mail] wrote:
> > 
> > David,
> > 
> > >...Here is the litmus test: do you agree that in
> > >order to validate a signature on an S/MIME message (any message, for
> > >any purpose, signed by any entity), the NR bit must be set?
> > 
> > I certainly don't, because of the ambiguity caused by the uncertain
> > legalisms. I note that the certificates issued by DoD and contained on
> > the
> > Common Access Card, even those issued to federal contractors, DO
> > contain the NR bit, and for that reason I would be quite reluctant
> > personally to use such a certificate.
> 
> 
> That's why, if Steve doesn't want to change the name of the bit,
> definitions are essential.  Are we talking:
> 
> 1) non-binding (ephemeral) authentication vs. binding (persistent)
>    signatures, or
> 
> 2) non-legally-binding persistent signatures vs. legally-binding
>    persistent signatures.
> 
> We haven't had any success in two years of attempting to come to grips
> with 2.  I agree with Ed Gerck that problem 2 is important, but it
> cannot be solved with one bit in a certificate.  I agree with you
> that a bit that claims to address 2 should be deprecated.
> 
> Problem 1 is easily solved with one bit, as long as the definitions
> are unambiguous.  It would be preferable to rename the bit because
> the word NR is an obstacle to common understanding and agreement.
> But if agreement and understanding can occur without changing the
> name, that's fine with me.


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA11835 for <[e-mail]>; Wed, 11 Apr 2001 13:15:31 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA27186; Wed, 11 Apr 2001 16:15:03 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Wed, 11 Apr 2001 16:13:29 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:
> 
> David,
> 
> >...Here is the litmus test: do you agree that in
> >order to validate a signature on an S/MIME message (any message, for
> >any purpose, signed by any entity), the NR bit must be set?
> 
> I certainly don't, because of the ambiguity caused by the uncertain
> legalisms. I note that the certificates issued by DoD and contained on
> the
> Common Access Card, even those issued to federal contractors, DO
> contain the NR bit, and for that reason I would be quite reluctant
> personally to use such a certificate.


That's why, if Steve doesn't want to change the name of the bit,
definitions are essential.  Are we talking:

1) non-binding (ephemeral) authentication vs. binding (persistent)
   signatures, or

2) non-legally-binding persistent signatures vs. legally-binding
   persistent signatures.

We haven't had any success in two years of attempting to come to grips
with 2.  I agree with Ed Gerck that problem 2 is important, but it
cannot be solved with one bit in a certificate.  I agree with you
that a bit that claims to address 2 should be deprecated.

Problem 1 is easily solved with one bit, as long as the definitions
are unambiguous.  It would be preferable to rename the bit because
the word NR is an obstacle to common understanding and agreement.
But if agreement and understanding can occur without changing the
name, that's fine with me.


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA09586 for <[e-mail]>; Wed, 11 Apr 2001 12:52:46 -0700 (PDT)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id <2LAWZS4C>; Wed, 11 Apr 2001 12:48:33 -0700
Message-ID: <[e-mail]>
From: "Covey, Carlin" <[e-mail]>
To: "'[e-mail] '" <[e-mail]>
Subject: Extension name divergence between PKIX profile and X.509 4th Edit ion
Date: Wed, 11 Apr 2001 12:48:31 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text/plain; charset="iso-8859-1"

There appears to be a bit of divergence between certain extension names and
definitions used in X.509 4th Edition X.509_4thEditionDraftV6.pdf and the
PKIX profile (draft-ietf-pkix-new-part1-05.txt).

draft-ietf-pkix-new-part1-05.txt describes a "Freshest CRL" extension (which
is also called "Delta CRL Distribution Point").  The extension is described
in section 4.2.1.16, a subsection under 4.2 Standard Certificate Extensions,
and it is described again in section 5.2.6, a subsection under 5.2 CRL
Extensions.  So according to the PKIX profile the extension appears to be
usable as either a certificate extension or a CRL extension, with identical
syntax.  Section 8.6.2.6 of X.509 4th edition draft V6 describes a "Freshest
CRL Extension" with the same syntax as in the PKIX profile, but says it
shall be used only as a certificate extension.  There is a CRL extension
defined in X.509 called "Delta Information extension" whose usage appears to
more or less match the PKIX CRL extension "Freshest CRL," but whose syntax
is not the same as the X.509 "Freshest CRL" certificate extension.  

Are my document versions out of date, or is this divergence intentional, or
is it time for a little mid-course correction? 

- Carlin Covey
  Cylink Corporation

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

P.S. Here are some quotes from the documents:

>From draft-ietf-pkix-new-part1-05.txt:

4.2 Standard Certificate Extensions 
...
4.2.1.16   Freshest CRL (a.k.a. Delta CRL Distribution Point) 
The freshest CRL extension identifies how delta-CRL information is obtained.
The same syntax is used for this extension and the 
cRLDistributionPoints extension, and is described in section 4.2.1.14.

5.2 CRL Extensions 
...
5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) 
The freshest CRL extension identifies how delta-CRL information for this CRL
is obtained.
The extension MUST be non-critical. The same syntax is used for this
extension as the cRLDistributionPoints certificate extension, and is
described in section 4.2.1.14. The same conventions apply to both
extensions.


>From X.509_4thEditionDraftV6.pdf:

8.5.2.9	Delta Information extension
This CRL extension is for use in CRLs that are not dCRLs and is used to
indicate to relying parties that dCRLs are also available for the CRL
containing this extension. The extension provides the location at which the
related dCRLs can be found and optionally the time at which the next dCRL is
to be issued. 

8.6.2.6   Freshest CRL extension
The freshest CRL extension shall be used only as a certificate extension and
may be used in certificates issued to authorities as well as certificates
issued to users. This field identifies the CRL to which a certificate user
should refer to obtain the freshest revocation information (e.g.: latest
dCRL).




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA07237 for <[e-mail]>; Wed, 11 Apr 2001 12:18:27 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 11 Apr 2001 13:17:53 -0600
Mime-Version: 1.0
Date: Wed, 11 Apr 2001 13:24:00 -0600
X-Mailer: Groupwise 5.5.3.1
Subject: Re: Meaning of Non-repudiation
To: "David P. Kemp"<[e-mail]>, [e-mail]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____TJBOSMHBKHISCPLUZFFZ____"

--____TJBOSMHBKHISCPLUZFFZ____
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

David,

>...Here is the litmus test: do you agree that in
>order to validate a signature on an S/MIME message (any message, for
>any purpose, signed by any entity), the NR bit must be set?

I certainly don't, because of the ambiguity caused by the uncertain=20
legalisms. I note that the certificates issued by DoD and contained on =
the=20
Common Access Card, even those issued to federal contractors, DO=20
contain the NR bit, and for that reason I would be quite reluctant
personally to use such a certificate.  Likewise, I would be =20
concerned if I were the CIO of such a federal contractor and
someone in my organization were to use such a certificate for any=20
purpose, but most especially for anything outside of the strict=20
purview of the DoD. The DoD CP may provide some definitive=20
definition of what NR means in their context (although I haven't=20
read it, and wouldn't bet my life on it), but who is in a position to =
say=20
that the DoD CP would be binding on some other, unrelated,
relying party?

Back in the AUTODIN days, there was a sharp distinction drawn=20
between "official" traffic, which were essentially legally binding=20
military orders sent by or under the authority of the commanding=20
officer, vs. "unofficial" traffic, which could be much less formal.

Nuclear release orders, troop movements -- "take that hill or die trying",
transfer of funds from one account to another, contract signings and=20
amendments, legal or other official notices -- those are the sorts of
things that I would think might legitimately deserve something like the
NR bit within DoD.

Using a certificate containing the NR bit to sign your previous=20
message, although not wrong per se, would certainly constitute
overkill and an unnecessary risk, at least to my way of=20
thinking. =20

Personally, I would keep the private key corresponding to a public=20
key in a certificate containing the NR bit stored away in my safe, or
in some other very secure location, to be taken out with considerable=20
trepidation and perhaps a certain amount of ceremony.  I would=20
NEVER use it for this kind of casual e-mail, even though I am willing=20
to sign it to demonstrate authenticity of origin and the absence of=20
any modification.  Despite my willingness to agree that I signed the=20
message, I don't regard it as legally binding -- it isn't a contract (no =
offer
and acceptance of consideration), it isn't a legal notice, will, testament,=

or other form of obligation, it is just a letter.

(Even if I were to sign it "Love and kisses", I wouldn't expect to be
held to that commitment with respect to this audience! :-)


"I do not anticipate any change to the NR bit in X.509 nor in PKIX."
                                                             Steve Kent

"We have met the enemy, and they is us."=20
                                                              Pogo

Regards,

Bob


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

MIIMlwYJKoZIhvcNAQcCoIIMiDCCDIQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCh8w
ggUIMIID8KADAgECAhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgID2jANBgkqhkiG9w0BAQUFADAy
MRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkx
MDA5MTcyMDAwWhcNMDkxMDA5MTcyMDAwWjAyMRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0Ex
EzARBgNVBAoUCk5PVkVMTF9JTkMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFXNJ5
6dllO0vfXHFpTJKFXsPp4/ODFGguxqQOt/gRB+jEILRth9kko6r1DRMVtdJ3vYFxujArU9E1dEUL
mf12vQOHveLyiu3+2QWFoWxGMRzdeziJkB5lk8noS3yhCCBoEOh+8UZ8xbeXRiBE9Trn4e5mojH8
+ao7khHpd5tw2MbfDgEh7ngp0jg7ZvLUz/UW4ki8em35g3KC3UFdUO/q+V/n2NUqnpgUH2bkpoib
kSMjwAfVn50B1PpK/MJMGvtYGiVtTvq6VKDR+wa8WC7uVEQiPbEiH8KOKd9fFBCsZvd12fbfUeNI
FmrnNkk5Ob/p/GRKrppExWbGueulpBExAgMBAAGjggIOMIICCjAKBgNVHQ4EAwQBATAMBgNVHSME
BTADgAEBMA8GA1UdEwEBAAQFMAMBAf8wDgYDVR0PAQEABAQDAgEGMIIBywYLYIZIAYb4NwEJBAEB
AQAEggG3MIIBswQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8v
ZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAu
aHRtMIIBRKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEB
AgEKAgFpogYCARgBAf+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAw
GDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIB
AgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEU
MBUwEAIBAAIIf/////////8BAQACARSiTjBMAgECAgIA/wIBAAMNAID//////////////wMJAID/
////////MBIwEAIBAAIIf/////////8BAf8wEjAQAgEAAgh//////////wEB/zANBgkqhkiG9w0B
AQUFAAOCAQEAaiESm7ALSKkCI86jYyeRPzNazTY4f0GepqTPidwM546hDZKxkFfKjop9nhZDEg0S
xj69kL7mlqowVlU6dgoEPgqwPglP0jBO60EyzqjorrVbnpuSNUVoY+6OyymyrdNrx2DGTBTqsI/i
urILrt1V2b8ioTAWSp9lHr5LxAOxQgTeNMMI/b5B0sTlAlwBNbn2K1b11EfYdxSmkQZfsQVCmfKl
8y2xqF7X2+W45Zgdev0/JQxCXlRVoGEMbshs7V5AECg9qezn9dTyfCX1nS+YoLkJf0khv2MrcfrN
1SG2EGusV2NVDxCdXFuLhyWxwAxVLoI5LNIMLFa4P8vAinCxJTCCBQ8wggP3oAMCAQICGgIUAAAA
FDT9XvJkLiStkJp3yzwj/3ICAgTqMA0GCSqGSIb3DQEBBQUAMDIxGzAZBgNVBAsTEk5vdmVsbCBF
bXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQzAeFw05OTEwMDkxODE4MDBaFw0wMTEwMDkx
ODE4MDBaMEIxEjAQBgNVBAMTCUJKdWVuZW1hbjENMAsGA1UECxMETlNSRDEMMAoGA1UECxMDUFJW
MQ8wDQYDVQQKEwZOb3ZlbGwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3eHuGT669
GWzGuMYSIvezmPdEFF0nbdlhqv0KwebG5WHi4TiLyX7s8l6+0CQRAF9rFQhEdh7I2lti9hgrNOjo
4SZvxU0PstQcN9ad6usXMzHBa36Xj31kJUhguKEKpCaUYGmWPcq6ehLcuxTv0nuq1QvAGTIqjCT5
y/tpSwo2nXpb9UXOEpZg8CmL6OTKj44cAmHzPk6dElXxF7SjnhkNOYNvwgs/Afa+7iOX0Lv6vTYJ
eaz1eklKMSoJf5mZ/EZfJjUkf5jDRdIb5Rog2/HWMEsBvP2vgiBrV1nwVFGBkpfs1qwq0A7h3UdG
bm8NlzgFMs2lltqtONbGiZK5UMoDAgMBAAGjggIFMIICATAMBgNVHSMEBTADgAEBMCIGA1UdEQEB
AAQYMBaBFEJKVUVORU1BTkBub3ZlbGwuY29tMIIBywYLYIZIAYb4NwEJBAEBAQAEggG3MIIBswQC
AQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5v
dmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRKAaAQEA
MAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARQB
Af+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh/////
/////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIBAgICAP8CAQADDQBA
AAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEUMBUwEAIBAAIIf///
//////8BAQACARSiTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBIwEAIB
AAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUFAAOCAQEAiEId
iox84BfJlz8suOJdTEwkuJsT1AbsLBwWzEpwfBS5FRGglOyKwlj8Fq+bFmgnBX//wbW4gjutgAEu
w8fXGUaQ9d2qwUn06Ta8C8AeBr7XmxrHe1Hs4YBQfqtVpdbZDasgeOhJhKSAMmIbv7jajwI9oZ93
aS5w/ArkTGFm+hpexZsSHtTjcKFAQ977M+QwbnilmnBfPYiQk+y/uGcAeJqJRnmzbfrbmzlpsyqg
yJENC+zD4O5tq9Gn53pHpG1EnjX/ZN3+jM0HKIc/rDuQ+yQ4e3LReenrRbmAoDlD5krF2sfFXphb
P86HUMcytbnXDgBbtKYdVtH/kDDMHCMQBTGCAkAwggI8AgEBMFAwMjEbMBkGA1UECxMSTm92ZWxs
IEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DAhoCFAAAABQ0/V7yZC4krZCad8s8I/9y
AgIE6jAJBgUrDgMCGgUAoIHGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAxMDQxMTEzMjQ0MFowIwYJKoZIhvcNAQkEMRYEFDjYY51biO62d5wvqfbULJtMcOyLMGcG
CSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAoGCCqGSIb3DQMEMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMA0GCSqGSIb3DQEB
AQUABIIBACEl2ccOhxlf2O0A9zw4o7vBPi3F7hRI0ePA3tg9F3BLCnLI773sQRE6S97lfmchN5GR
/3Kvr/qwgMzyI82Ept4V6lt1qxUnxzv/9pe9PstxD5Nt+PjwthtYwAQ9l4DkdqMIynkObXS+Kl+N
v/Ebz/UEezqdRzLIxz/ZcYT5l54MUi1QhaclTkc7oD8gmhdfQL4WY5T7ZdQVv2PhFS4lLepD3/j8
OSfR1rhhmj1dsUX8+M2abg1hHqasyFtkushUDHRF6zlTGNlCmbvNEoSJobyj4k/5/txh/iF7wY+d
p5rnt/CO5qSkfp+57XXVFFn/xiW2a1L6uvhk7EYL/+UZVp8=

--____TJBOSMHBKHISCPLUZFFZ____--


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA06515 for <[e-mail]>; Wed, 11 Apr 2001 12:07:11 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA24312 for <[e-mail]>; Wed, 11 Apr 2001 15:06:43 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Wed, 11 Apr 2001 15:05:12 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Sylvester wrote:
> 
> Effective only at time of generation seems somewhat difficult;
> it always happens later.

Sometimes one sacrifices rigor for clarity.  A more precise expression
of the HAK remark might be:

   A fundamental distinction exists between a party A being able to
   convince itself at time t0+e of the validity of a digital
   signature s generated at time t0, and that party being able to
   convince others at some time t1 >= t0+e that s was valid at
   time t0.

For all practical purposes, e (read epsilon, a very small value)
could be fixed at one minute without significantly affecting
the use cases.  If you receive a signed message one second after
it was sent and know that the signature will become invalid 59 seconds
later, the lack of the NR bit will have achieved its purpose.
If the signature is not "binding" then your user agent should not
treat it as binding; it should authenticate the message and then
discard the authentication information before storing the message.

> What is the essential difference between some authentication
> handshake 'on line' or some [authentication] exchange using S/MIME.
> 
> Consider for example just signature on domain boundaries,

No difference - that's the point.  If the client signs S/MIME data
without NR and sends it to the domain gateway, the gateway bcomes
responsible for the data's integrity because the client signature
becomes invalid one hop or 59 seconds hence.  A proper gateway will
honor the keyUsage bit and strip off the now-useless client signature
exactly as it would strip off an SSL protocol layer before forwarding
the data.

If the client signs with NR, then the domain signature could optionally
be added to it rather than replacing it.


Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA01100 for <[e-mail]>; Wed, 11 Apr 2001 10:33:56 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA25199; Wed, 11 Apr 2001 19:33:57 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 11 Apr 2001 19:33:57 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA13093; Wed, 11 Apr 2001 19:33:56 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA20049; Wed, 11 Apr 2001 19:33:55 +0200 (MET DST)
Date: Wed, 11 Apr 2001 19:33:55 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Meaning of Non-repudiation

Effective only at time of generation seems somewhat difficult;
it always happens later. 

What is the essential difference between some authentication 
handshake 'on line' or some exchange using S/MIME.

Consider for example just signature on domain boundaries, 

Or between a user and and ISP relay in order to allow
relaying from authorized users etc.   


> I agree completely with your "not considered binding", as long as there
> is an explicit statement that binding means persistent - i.e., effective
> for some time after generation, as opposed to effective only at the
> time of generation.  Here is the litmus test: do you agree that in
> order to validate a signature on an S/MIME message (any message, for
> any purpose, signed by any entity), the NR bit must be set?
> 


Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00333 for <[e-mail]>; Wed, 11 Apr 2001 10:16:00 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2650.21) id <2SH8RPVC>; Wed, 11 Apr 2001 13:16:02 -0400
Message-ID: <[e-mail]>
From: "Friedrichs, Paul LCDR" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, Anders Rundgren <[e-mail]>, "Fillingham,  David W." <[e-mail]>, PKIX-List <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, [e-mail], "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, [e-mail], [e-mail], "'Steve Hanna (SUN)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>, Roger Younglove <[e-mail]>
Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
Date: Wed, 11 Apr 2001 13:15:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C2AB.12D307B0"

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_01C0C2AB.12D307B0
Content-Type: text/plain;
	charset="ISO-8859-1"

HI All,
 
Fascinating thread. I wonder whether we are confusing application and
credential architectures. I think this is how I see it. Perhaps I'm missing
something. (Or perhaps I'm totally naive): 
 
Application architectures need to address who/what must, might or must not
know the existence of whom/what, and who/what trusts whom/what for what
purpose. (Perhaps only people should be said to "trust" and so "rely on"
might be a better word, but the differences and relationship between trust
and reliance shouldn't be overlooked.) Notions of authorities, officers, and
agents must be addressed by the application architecture. Nonrepudiation and
confidentiality are very different application requirements that may require
very different application architectures (and subjects).
 
Credentials can be issued to subjects required by application architectures
(e.g., to individuals and agents/organizations). 
 
Except, perhaps, when considering nation states, the trustworthiness of
signature credentials should be able to be abstracted from the trust between
subjects. Signature credentials need to be trustworthy and of
comparable/known trustworthiness (only) across the subjects with whom
subjects wish to securely interact. Perhaps this is an excellent place for a
government service. (The US's Privacy Act is a *BIG* challenge when
statically naming private citizens.) (Another thought is that where the
existence of subjects is known only locally, locally managed signature
credentials are likely most efficient.) Signature credential architectures
wishing to support wide interoperability should be able to focus on
addressing the core challenge of the commonness of the credentials' strength
(not who trusts whom). The best mix of signature credential architecture
options will depend on what sorts of signature credential service providers
succeed in the marketplace.  
 
Because of the possibility of and frequent requirement for data recovery,
the encryption credential seems to be a very different challenge. Perhaps it
will always be best for trust domains to issue their own encryption
credentials, suggesting that a different credential architecture mix will be
required. 
 
I think the application, signature credential, and encryption credential
challenges/architectures are independent.
 
Paul
 
 

------_=_NextPart_001_01C0C2AB.12D307B0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>RE: DoD Bridge Certification Authority Phase II Demonstrations</TITLE>

<META content="MSHTML 5.50.4207.2601" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff size=2>HI 
All,</FONT></SPAN></DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2>Fascinating thread. I wonder whether we are confusing application and 
credential architectures. I think this is how I see it. Perhaps I'm missing 
something.&nbsp;(Or perhaps I'm&nbsp;totally naive): </FONT></SPAN></DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2>Application architectures need to&nbsp;address who/what must, might or 
must&nbsp;not know the existence of whom/what, and who/what trusts whom/what for 
what purpose. (Perhaps only people should be said to "trust" and so "rely on" 
might be a better word, but the differences and relationship between trust and 
reliance shouldn't be overlooked.) Notions of authorities, officers, and 
agents&nbsp;must be addressed by the application architecture. Nonrepudiation 
and confidentiality are very different application requirements that may require 
very different application architectures (and subjects).</FONT></SPAN></DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2>Credentials can be issued to subjects required by application 
architectures (e.g., to individuals and 
agents/organizations).&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2>Except, perhaps, when considering nation states, the trustworthiness 
of&nbsp;signature credentials should be able to be abstracted from the trust 
between subjects. Signature credentials need to be trustworthy and of 
comparable/known trustworthiness (only) across the subjects with 
whom&nbsp;subjects wish to securely interact. Perhaps this is an excellent place 
for a government service. (The US's Privacy Act is a *BIG* challenge when 
statically naming private citizens.)&nbsp;(Another thought is that where the 
existence of subjects&nbsp;is known only locally, locally managed&nbsp;signature 
credentials are likely most efficient.)&nbsp;Signature credential 
architectures&nbsp;wishing to support wide interoperability should be able to 
focus on addressing the core challenge of the commonness of the credentials' 
strength (not who trusts whom).&nbsp;The best mix of signature credential 
architecture options will&nbsp;depend on what&nbsp;sorts of signature credential 
service providers&nbsp;succeed in the 
marketplace.&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2>Because of the possibility of and frequent requirement for data recovery, 
the encryption credential seems to be a very different challenge. Perhaps it 
will always be best for trust domains to issue their own encryption credentials, 
suggesting that a different credential architecture mix&nbsp;will 
be&nbsp;required. </FONT></SPAN></DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff size=2>I 
think the&nbsp;application, signature&nbsp;credential, and encryption 
credential&nbsp;challenges/architectures are independent.</FONT></SPAN></DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2>Paul</FONT></SPAN></DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=646160616-11042001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C0C2AB.12D307B0--


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA29620 for <[e-mail]>; Wed, 11 Apr 2001 10:06:10 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA18988 for <[e-mail]>; Wed, 11 Apr 2001 13:05:41 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Wed, 11 Apr 2001 13:04:08 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]> <[e-mail]> <p0501040ab6fa32eff970@[128.33.238.44]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:
> 
> I do not anticipate any change to the NR bit in X.509 nor in PKIX.

Fair enough.  But if the name of the bit is not changed, then the
definition must be clarified, to avoid the ambiguity evident below:

> The main purpose for the NR bit is to allow a cert to be designated
> as NOT being associated with signatures used in NR transactions. This
> is a safety feature for the EE. By using a cert with the NR bit set
> to FALSE, the EE is explicitly stating that the signature generated
> with the corresponding private key is not be be considered binding,
> e.g., it is for authentication but not for non-repudiation.

This is the problem - some people associate the words NR and "binding"
with "creating an obligation".

I agree completely with your "not considered binding", as long as there
is an explicit statement that binding means persistent - i.e., effective
for some time after generation, as opposed to effective only at the
time of generation.  Here is the litmus test: do you agree that in
order to validate a signature on an S/MIME message (any message, for
any purpose, signed by any entity), the NR bit must be set?


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA27276 for <[e-mail]>; Wed, 11 Apr 2001 09:19:29 -0700 (PDT)
Received: from [128.33.238.44] (TC107.BBN.COM [128.33.238.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA21942 for <[e-mail]>; Wed, 11 Apr 2001 12:19:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040ab6fa32eff970@[128.33.238.44]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 11 Apr 2001 12:20:03 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

I do not anticipate any change to the NR bit in X.509 nor in PKIX. 
I've read the extended dialogue on this topic and it has a familiar 
ring.  However, many of the arguments put forth seem to be narrow, or 
miss the point entirely.

Yes, it is true that the NR bit is not sufficient for NR. It was 
never claimed to be.

Yes, if suitable, external, contractual agreement exists, the NR bit 
is not necessary for NR.

The main purpose for the NR bit is to allow a cert to be designated 
as NOT being associated with signatures used in NR transactions. This 
is a safety feature for the EE. By using a cert with the NR bit set 
to FALSE, the EE is explicitly stating that the signature generated 
with the corresponding private key is not be be considered binding, 
e.g., it is for authentication but not for non-repudiation.  Yes, if 
the user has multiple certs with the same key and the NR bit is set 
in some but not others, this utility is voided. In general we can't 
prevent users from engaging in such behavior. An RP that holds a copy 
of the cert used in a NR transaction has a defense against such a 
user, if push come to shove.

So, I suggest that we table the discussion on the labeling of the NR 
bit and leave the more detailed discussions of how to achieve 
technical NR to the relevant documents, of which 2459 (its successors 
and assigns ...) is not one.

Steve


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA20647 for <[e-mail]>; Wed, 11 Apr 2001 08:32:19 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <2W9NH1GB>; Wed, 11 Apr 2001 11:31:47 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Anders Rundgren <[e-mail]>, Santosh Chokhani <[e-mail]>, "Fillingham,  David W." <[e-mail]>, PKIX-List <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, [e-mail], "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, [e-mail], [e-mail], "'Steve Hanna (SUN)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>, Roger Younglove <[e-mail]>
Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
Date: Wed, 11 Apr 2001 11:23:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C29B.52808E10"

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_01C0C29B.52808E10
Content-Type: text/plain;
	charset="iso-8859-1"

Anders: See comments in-line.  I suggest that we take this off-line and not
waste others' time.
 
All: I am sorry for this rambling. 
 
-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Wednesday, April 11, 2001 4:00 AM
To: Santosh Chokhani; Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD PKI
TWG'; [e-mail]; 'Bridge CA Mail List'; 'BCA Integration'; 'Steve
Capps'; Wagner, Clark J.; [e-mail];
[e-mail]; 'Steve Hanna (SUN)'; 'Susan Dernik';
Roger Younglove
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations


Santosh,
I do understand this. But assume that your customers have so far not been
aware of alternatives?
To say that they cannot accept intermediaries is like saying "we do not
trust file-servers".  That's
a rather extreme position.  Many organizations live or die depending on how
their "intermediaries" work.
[Santosh Chokhani] There is a deference in availability of service and
trusting confidentiality and integrity provided by a service.
 
You did not comment on all the drawbacks of using client-end-to-end
encryption in an organization-
environment.
[Santosh Chokhani] Each option has its benefits and drawbacks and that is
why we have so many architectures and products with different approaches. 
 
If a project group involves very few people (two lawyers on the same case)
that have exclusive
rights to their information the situation may call for end-to-end
encryption.
[Santosh Chokhani] We need end-end encryption and authentication many times.

 
I.e. domain-PKI is definitely not only about security, but about who is in
control (i.e. owns and is
responsible for the information).  If DoD builds on a model where the
individual is the owner,
I think that they pretty soon will get severe problems, as lost private keys
can lead to information-
loss in a way the paper-world have never seen.  Then we are into key
backup-schemes that
if applied to individuals is a major problem.  Applied to domain-PKI it is
*almost* reasonable.
[Santosh Chokhani] Lost private keys are not a problem if key recovery is
properly implemented.  Please note that you do not need to recover signature
private keys since once they are used for signing they are not required for
verification.  Just like gravity, we tend to sign before verifying the
signature.
 
Anders

----- Original Message ----- 
From: Santosh  <mailto:[e-mail]> Chokhani 
To: Anders  <mailto:[e-mail]> Rundgren ; Santosh Chokhani
<mailto:[e-mail]>  ; Fillingham,
<mailto:[e-mail]> David W. ; PKIX-List
<mailto:[e-mail]>  ; 'KPCMWG' <mailto:[e-mail]>  ; 'DoD PKI
TWG' <mailto:[e-mail]>  ; [e-mail]
<mailto:[e-mail]>  ; 'Bridge CA Mail  <mailto:[e-mail]>
List' ; 'BCA Integration' <mailto:[e-mail]>  ; 'Steve
<mailto:[e-mail]> Capps' ; Wagner, Clark J.
<mailto:[e-mail]>  ; [e-mail]
<mailto:[e-mail]>  ; [e-mail]
<mailto:[e-mail]>  ; 'Steve Hanna
<mailto:[e-mail]> (SUN)' ; 'Susan Dernik'
<mailto:[e-mail]>  ; Roger  <mailto:[e-mail]>
Younglove 
Sent: Tuesday, April 10, 2001 23:30
Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations


Anders: 

I do not think you understand this.  My customers do not want intermediate
systems except the people working on the project to access the data.

-----Original Message----- 
From: Anders Rundgren [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Tuesday, April 10, 2001 5:26 PM 
To: Santosh Chokhani; Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD 
PKI TWG'; [e-mail] <mailto:[e-mail]> ; 'Bridge CA Mail
List'; 'BCA Integration'; 
'Steve Capps'; Wagner, Clark J.; [e-mail]
<mailto:[e-mail]> ; 
[e-mail] <mailto:[e-mail]>
; 'Steve Hanna (SUN)'; 'Susan Dernik'; 
Roger Younglove 
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations 


Santosh, 

>Having looked at the papers you sent, I think your solutions may be ok as a
B2B solution. 

I believe so. 

>But, I see end to end security requiring PKI. Even in our company's case
where 
>we run independent labs, do PKI consulting and build PKI products, some of
our lab 
>customers when they send us documents over the Internet, they want only the
lab 
>personnel assigned to the project to read it. They do it using end-end
encryption. 
>PKI concepts were designed for this distributed, client centric model. 

Even in this example you have conflicts with different interests that may
suggest that 
a domain-solution could fit as well. Assume that more than one individual is

supposed to be able to access the sent document. In that case it would be
more 
appropriate to encrypt using a domain public key and let the receiver's
local client file access 
system direct who is going to have access to the document. Otherwise it
looks 
like this document is not a part of some organization's activity and in that
case 
domain-PKI does of course not apply. In the senders end it may be in the 
organization's interests to monitor all outgoing documents. That is in
conflict 
with the client doing the encryption. 

And the very same problem is also valid for archiving of signed data from
authorities. 
Using domain-PKI you get it for free. Using client-PKI (only) you get less 
control which is bad as control probably was the reason for adding PKI in
the first place! 

And now the heat is on directories... 

An interesting side-effect of Purple-type of solutions is that [more or
less] public directories 
holding information about employees become largely superfluous as all
information required 
for a certain relation is in the tickets themselves.  I.e. purchaser
"profile" information is a 
typical item that now finally have gotten a suitable container to be
transported in. 

/anders 


------_=_NextPart_001_01C0C29B.52808E10
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: DoD Bridge Certification Authority Phase II Demonstrations</TITLE>

<META content="MSHTML 5.00.2014.210" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=268584714-11042001>Anders: See comments in-line.&nbsp; I suggest that we 
take this off-line and not waste others' time.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=268584714-11042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=268584714-11042001>All: I 
am sorry for this rambling.&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=268584714-11042001></SPAN></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Anders Rundgren 
[mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, April 11, 2001 
4:00 AM<BR><B>To:</B> Santosh Chokhani; Fillingham, David W.; PKIX-List; 
'KPCMWG'; 'DoD PKI TWG'; [e-mail]; 'Bridge CA Mail List'; 'BCA 
Integration'; 'Steve Capps'; Wagner, Clark J.; [e-mail]; 
[e-mail]; 'Steve Hanna (SUN)'; 'Susan Dernik'; Roger 
Younglove<BR><B>Subject:</B> Re: DoD Bridge Certification Authority Phase II 
Demonstrations<BR><BR></FONT></DIV>
<DIV>
<DIV><FONT face=Arial size=2>Santosh,</FONT></DIV>
<DIV><FONT face=Arial size=2>I do understand this. But assume that your 
customers have so far not been aware of alternatives?</FONT></DIV>
<DIV><FONT face=Arial size=2>To say that they cannot accept intermediaries is 
like saying&nbsp;"we do not&nbsp;trust file-servers".&nbsp; That's</FONT></DIV>
<DIV><FONT size=2><FONT face=Arial>a rather extreme position.&nbsp; Many 
organizations live or die depending on how their "intermediaries" work.<BR><FONT 
color=#0000ff><SPAN class=268584714-11042001>[Santosh 
Chokhani]&nbsp;There&nbsp;is a deference in availability of service and trusting 
confidentiality and integrity provided by a 
service.</SPAN></FONT></FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>You did not comment on all the drawbacks of using 
client-end-to-end encryption in an organization-</FONT></DIV>
<DIV><FONT size=2><FONT face=Arial>environment.<BR><FONT color=#0000ff><SPAN 
class=268584714-11042001>[Santosh Chokhani]&nbsp;Each option has its benefits 
and drawbacks and that is why we have so many architectures and products with 
different approaches.&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>If&nbsp;a project group involves very few people 
(two lawyers on the same case) that have exclusive</FONT></DIV>
<DIV><FONT size=2><FONT face=Arial>rights to their information the situation may 
call for end-to-end encryption.<BR><FONT color=#0000ff><SPAN 
class=268584714-11042001>[Santosh Chokhani]&nbsp;We need end-end encryption and 
authentication many times.&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>I.e. domain-PKI is definitely not only about 
security, but about who is in control (i.e. owns and is</FONT></DIV>
<DIV><FONT face=Arial size=2>responsible for the information).&nbsp; If DoD 
builds on a model where the individual is the owner,</FONT></DIV>
<DIV><FONT face=Arial size=2>I think that they pretty soon will get severe 
problems, as lost private keys can lead to information-</FONT></DIV>
<DIV><FONT face=Arial size=2>loss in a way the paper-world have never 
seen.&nbsp; Then we are into key backup-schemes that</FONT></DIV>
<DIV><FONT size=2><FONT face=Arial>if applied to individuals is a major 
problem.&nbsp; Applied to domain-PKI it is *almost* reasonable.<BR><FONT 
color=#0000ff><SPAN class=268584714-11042001>[Santosh Chokhani]&nbsp;Lost 
private keys are not a&nbsp;problem if key recovery is properly 
implemented.&nbsp; Please note that you do not need to recover signature private 
keys since once they are used for signing they are not required for 
verification.&nbsp; Just like gravity, we tend to sign before verifying the 
signature.</SPAN></FONT></FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Anders</FONT></DIV></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A href="mailto:[e-mail]" title=[e-mail]>Santosh 
  Chokhani</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  href="mailto:[e-mail]" title=[e-mail]>Anders 
  Rundgren</A> ; <A href="mailto:[e-mail]" 
  title=[e-mail]>Santosh Chokhani</A> ; <A 
  href="mailto:[e-mail]" title=[e-mail]>Fillingham, 
  David W.</A> ; <A href="mailto:[e-mail]" 
  title=[e-mail]>PKIX-List</A> ; <A href="mailto:[e-mail]" 
  title=[e-mail]>'KPCMWG'</A> ; <A href="mailto:[e-mail]" 
  title=[e-mail]>'DoD PKI TWG'</A> ; <A 
  href="mailto:[e-mail]" title=[e-mail]>[e-mail]</A> ; 
  <A href="mailto:[e-mail]" title=[e-mail]>'Bridge CA Mail 
  List'</A> ; <A href="mailto:[e-mail]" 
  title=[e-mail]>'BCA Integration'</A> ; <A 
  href="mailto:[e-mail]" title=[e-mail]>'Steve 
  Capps'</A> ; <A href="mailto:[e-mail]" 
  title=[e-mail]>Wagner, Clark J.</A> ; <A 
  href="mailto:[e-mail]" 
  title=[e-mail]>[e-mail]</A> ; <A 
  href="mailto:[e-mail]" 
  title=[e-mail]>[e-mail]</A> 
  ; <A href="mailto:[e-mail]" title=[e-mail]>'Steve Hanna 
  (SUN)'</A> ; <A href="mailto:[e-mail]" 
  title=[e-mail]>'Susan Dernik'</A> ; <A 
  href="mailto:[e-mail]" title=[e-mail]>Roger 
  Younglove</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, April 10, 2001 23:30</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: DoD Bridge Certification 
  Authority Phase II Demonstrations</DIV>
  <DIV><BR></DIV>
  <P><FONT size=2>Anders:</FONT> </P>
  <P><FONT size=2>I do not think you understand this.&nbsp; My customers do not 
  want intermediate systems except the people working on the project to access 
  the data.</FONT></P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
  Anders Rundgren [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>Sent: Tuesday, April 10, 2001 5:26 PM</FONT> <BR><FONT 
  size=2>To: Santosh Chokhani; Fillingham, David W.; PKIX-List; 'KPCMWG'; 
  'DoD</FONT> <BR><FONT size=2>PKI TWG'; <A 
  href="mailto:[e-mail]">[e-mail]</A>; 'Bridge CA Mail List'; 
  'BCA Integration';</FONT> <BR><FONT size=2>'Steve Capps'; Wagner, Clark J.; <A 
  href="mailto:[e-mail]">[e-mail]</A>;</FONT> 
  <BR><FONT size=2><A 
  href="mailto:[e-mail]">[e-mail]</A>; 
  'Steve Hanna (SUN)'; 'Susan Dernik';</FONT> <BR><FONT size=2>Roger 
  Younglove</FONT> <BR><FONT size=2>Subject: Re: DoD Bridge Certification 
  Authority Phase II Demonstrations</FONT> </P><BR>
  <P><FONT size=2>Santosh, </FONT></P>
  <P><FONT size=2>&gt;Having looked at the papers you sent, I think your 
  solutions may be ok as a B2B solution. </FONT></P>
  <P><FONT size=2>I believe so.</FONT> </P>
  <P><FONT size=2>&gt;But, I see end to end security requiring PKI. Even in our 
  company's case where </FONT><BR><FONT size=2>&gt;we run independent labs, do 
  PKI consulting and build PKI products, some of our lab </FONT><BR><FONT 
  size=2>&gt;customers when they send us documents over the Internet, they want 
  only the lab </FONT><BR><FONT size=2>&gt;personnel assigned to the project to 
  read it. They do it using end-end encryption. </FONT><BR><FONT size=2>&gt;PKI 
  concepts were designed for this distributed, client centric model. </FONT></P>
  <P><FONT size=2>Even in this example you have conflicts with different 
  interests that may suggest that </FONT><BR><FONT size=2>a domain-solution 
  could fit as well. Assume that more than one individual is </FONT><BR><FONT 
  size=2>supposed to be able to access the sent document. In that case it would 
  be more </FONT><BR><FONT size=2>appropriate to encrypt using a domain public 
  key and let the receiver's local client file access </FONT><BR><FONT 
  size=2>system direct who is going to have access to the document. Otherwise it 
  looks </FONT><BR><FONT size=2>like this document is not a part of some 
  organization's activity and in that case </FONT><BR><FONT size=2>domain-PKI 
  does of course not apply. In the senders end it may be in the </FONT><BR><FONT 
  size=2>organization's interests to monitor all outgoing documents. That is in 
  conflict </FONT><BR><FONT size=2>with the client doing the encryption. 
  </FONT></P>
  <P><FONT size=2>And the very same problem is also valid for archiving of 
  signed data from authorities. </FONT><BR><FONT size=2>Using domain-PKI you get 
  it for free. Using client-PKI (only) you get less </FONT><BR><FONT 
  size=2>control which is bad as control probably was the reason for adding PKI 
  in the first place! </FONT></P>
  <P><FONT size=2>And now the heat is on directories...</FONT> </P>
  <P><FONT size=2>An interesting side-effect of Purple-type of solutions is that 
  [more or less] public directories</FONT> <BR><FONT size=2>holding information 
  about employees become largely superfluous as all information required</FONT> 
  <BR><FONT size=2>for a certain relation is in the tickets themselves.&nbsp; 
  I.e. purchaser "profile" information is a</FONT> <BR><FONT size=2>typical item 
  that now finally have gotten a suitable container to be transported in.</FONT> 
  </P>
  <P><FONT size=2>/anders</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0C29B.52808E10--


Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA07322 for <[e-mail]>; Wed, 11 Apr 2001 00:07:59 -0700 (PDT)
Received: from arport ([212.181.94.147]) by mailf.telia.com (8.11.2/8.11.0) with SMTP id f3B77ix25258; Wed, 11 Apr 2001 09:07:45 +0200 (CEST)
Message-ID: <008901c0c25d$5f4fb460$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Fillingham,  David W." <[e-mail]>, "PKIX-List" <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, <[e-mail]>, "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, <[e-mail]>, <[e-mail]>, "'Steve Hanna \(SUN\)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>, "Roger Younglove" <[e-mail]>
References: <[e-mail]>
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
Date: Wed, 11 Apr 2001 09:59:39 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01C0C26E.1F962AA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

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

RE: DoD Bridge Certification Authority Phase II DemonstrationsSantosh,
I do understand this. But assume that your customers have so far not =
been aware of alternatives?
To say that they cannot accept intermediaries is like saying "we do not =
trust file-servers".  That's
a rather extreme position.  Many organizations live or die depending on =
how their "intermediaries" work.

You did not comment on all the drawbacks of using client-end-to-end =
encryption in an organization-
environment.

If a project group involves very few people (two lawyers on the same =
case) that have exclusive
rights to their information the situation may call for end-to-end =
encryption.

I.e. domain-PKI is definitely not only about security, but about who is =
in control (i.e. owns and is
responsible for the information).  If DoD builds on a model where the =
individual is the owner,
I think that they pretty soon will get severe problems, as lost private =
keys can lead to information-
loss in a way the paper-world have never seen.  Then we are into key =
backup-schemes that
if applied to individuals is a major problem.  Applied to domain-PKI it =
is *almost* reasonable.

Anders
  ----- Original Message -----=20
  From: Santosh Chokhani=20
  To: Anders Rundgren ; Santosh Chokhani ; Fillingham, David W. ; =
PKIX-List ; 'KPCMWG' ; 'DoD PKI TWG' ; [e-mail] ; 'Bridge CA =
Mail List' ; 'BCA Integration' ; 'Steve Capps' ; Wagner, Clark J. ; =
[e-mail] ; [e-mail] ; 'Steve =
Hanna (SUN)' ; 'Susan Dernik' ; Roger Younglove=20
  Sent: Tuesday, April 10, 2001 23:30
  Subject: RE: DoD Bridge Certification Authority Phase II =
Demonstrations


  Anders:=20

  I do not think you understand this.  My customers do not want =
intermediate systems except the people working on the project to access =
the data.

  -----Original Message-----=20
  From: Anders Rundgren [mailto:[e-mail]]=20
  Sent: Tuesday, April 10, 2001 5:26 PM=20
  To: Santosh Chokhani; Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD=20
  PKI TWG'; [e-mail]; 'Bridge CA Mail List'; 'BCA Integration';=20
  'Steve Capps'; Wagner, Clark J.; [e-mail];=20
  [e-mail]; 'Steve Hanna (SUN)'; 'Susan =
Dernik';=20
  Roger Younglove=20
  Subject: Re: DoD Bridge Certification Authority Phase II =
Demonstrations=20



  Santosh,=20

  >Having looked at the papers you sent, I think your solutions may be =
ok as a B2B solution.=20

  I believe so.=20

  >But, I see end to end security requiring PKI. Even in our company's =
case where=20
  >we run independent labs, do PKI consulting and build PKI products, =
some of our lab=20
  >customers when they send us documents over the Internet, they want =
only the lab=20
  >personnel assigned to the project to read it. They do it using =
end-end encryption.=20
  >PKI concepts were designed for this distributed, client centric =
model.=20

  Even in this example you have conflicts with different interests that =
may suggest that=20
  a domain-solution could fit as well. Assume that more than one =
individual is=20
  supposed to be able to access the sent document. In that case it would =
be more=20
  appropriate to encrypt using a domain public key and let the =
receiver's local client file access=20
  system direct who is going to have access to the document. Otherwise =
it looks=20
  like this document is not a part of some organization's activity and =
in that case=20
  domain-PKI does of course not apply. In the senders end it may be in =
the=20
  organization's interests to monitor all outgoing documents. That is in =
conflict=20
  with the client doing the encryption.=20

  And the very same problem is also valid for archiving of signed data =
from authorities.=20
  Using domain-PKI you get it for free. Using client-PKI (only) you get =
less=20
  control which is bad as control probably was the reason for adding PKI =
in the first place!=20

  And now the heat is on directories...=20

  An interesting side-effect of Purple-type of solutions is that [more =
or less] public directories=20
  holding information about employees become largely superfluous as all =
information required=20
  for a certain relation is in the tickets themselves.  I.e. purchaser =
"profile" information is a=20
  typical item that now finally have gotten a suitable container to be =
transported in.=20

  /anders=20


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: DoD Bridge Certification Authority Phase II =
Demonstrations</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Santosh,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I do understand this. But assume that =
your=20
customers have so far not been aware of alternatives?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To say that they cannot accept =
intermediaries is=20
like saying&nbsp;"we do not&nbsp;trust file-servers".&nbsp; =
That's</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>a rather extreme position.&nbsp; Many =
organizations=20
live or die depending on how their "intermediaries" work.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>You did not comment on all the drawbacks of using client-end-to-end =

encryption in an organization-</DIV>
<DIV>environment.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If&nbsp;a project group involves very few people (two lawyers on =
the same=20
case) that have exclusive</DIV>
<DIV>rights to their information the situation may call for end-to-end=20
encryption.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I.e. domain-PKI is definitely not only about security, but about =
who is in=20
control (i.e. owns and is</DIV>
<DIV>responsible for the information).&nbsp; If DoD builds on a model =
where the=20
individual is the owner,</DIV>
<DIV>I think that they pretty soon will get severe problems, as lost =
private=20
keys can lead to information-</DIV>
<DIV>loss in a way the paper-world have never seen.&nbsp; Then we are =
into key=20
backup-schemes that</DIV>
<DIV>if applied to individuals is a major problem.&nbsp; Applied to =
domain-PKI=20
it is *almost* reasonable.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Anders</DIV></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[e-mail]" =
title=[e-mail]>Santosh=20
  Chokhani</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:[e-mail]" =
title=[e-mail]>Anders=20
  Rundgren</A> ; <A href=3D"mailto:[e-mail]"=20
  title=[e-mail]>Santosh Chokhani</A> ; <A=20
  href=3D"mailto:[e-mail]" =
title=[e-mail]>Fillingham,=20
  David W.</A> ; <A href=3D"mailto:[e-mail]"=20
  title=[e-mail]>PKIX-List</A> ; <A =
href=3D"mailto:[e-mail]"=20
  title=[e-mail]>'KPCMWG'</A> ; <A =
href=3D"mailto:[e-mail]"=20
  title=[e-mail]>'DoD PKI TWG'</A> ; <A=20
  href=3D"mailto:[e-mail]" =
title=[e-mail]>[e-mail]</A> ;=20
  <A href=3D"mailto:[e-mail]" =
title=[e-mail]>'Bridge CA Mail=20
  List'</A> ; <A href=3D"mailto:[e-mail]"=20
  title=[e-mail]>'BCA Integration'</A> ; <A=20
  href=3D"mailto:[e-mail]" =
title=[e-mail]>'Steve=20
  Capps'</A> ; <A href=3D"mailto:[e-mail]"=20
  title=[e-mail]>Wagner, Clark J.</A> ; <A=20
  href=3D"mailto:[e-mail]"=20
  title=[e-mail]>[e-mail]</A> ; <A=20
  href=3D"mailto:[e-mail]"=20
  =
title=[e-mail]>[e-mail].g=
ov</A>=20
  ; <A href=3D"mailto:[e-mail]" =
title=[e-mail]>'Steve Hanna=20
  (SUN)'</A> ; <A href=3D"mailto:[e-mail]"=20
  title=[e-mail]>'Susan Dernik'</A> ; <A=20
  href=3D"mailto:[e-mail]" =
title=[e-mail]>Roger=20
  Younglove</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, April 10, 2001 =
23:30</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: DoD Bridge =
Certification=20
  Authority Phase II Demonstrations</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>Anders:</FONT> </P>
  <P><FONT size=3D2>I do not think you understand this.&nbsp; My =
customers do not=20
  want intermediate systems except the people working on the project to =
access=20
  the data.</FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Anders Rundgren [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]=
m</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Tuesday, April 10, 2001 5:26 PM</FONT> =
<BR><FONT=20
  size=3D2>To: Santosh Chokhani; Fillingham, David W.; PKIX-List; =
'KPCMWG';=20
  'DoD</FONT> <BR><FONT size=3D2>PKI TWG'; <A=20
  href=3D"mailto:[e-mail]">[e-mail]</A>; 'Bridge CA Mail =
List';=20
  'BCA Integration';</FONT> <BR><FONT size=3D2>'Steve Capps'; Wagner, =
Clark J.; <A=20
  =
href=3D"mailto:[e-mail]">[e-mail]</A>;</FONT>=
=20
  <BR><FONT size=3D2><A=20
  =
href=3D"mailto:[e-mail]">Michelle.Moldenhauer@do=
.treas.gov</A>;=20
  'Steve Hanna (SUN)'; 'Susan Dernik';</FONT> <BR><FONT size=3D2>Roger=20
  Younglove</FONT> <BR><FONT size=3D2>Subject: Re: DoD Bridge =
Certification=20
  Authority Phase II Demonstrations</FONT> </P><BR>
  <P><FONT size=3D2>Santosh, </FONT></P>
  <P><FONT size=3D2>&gt;Having looked at the papers you sent, I think =
your=20
  solutions may be ok as a B2B solution. </FONT></P>
  <P><FONT size=3D2>I believe so.</FONT> </P>
  <P><FONT size=3D2>&gt;But, I see end to end security requiring PKI. =
Even in our=20
  company's case where </FONT><BR><FONT size=3D2>&gt;we run independent =
labs, do=20
  PKI consulting and build PKI products, some of our lab =
</FONT><BR><FONT=20
  size=3D2>&gt;customers when they send us documents over the Internet, =
they want=20
  only the lab </FONT><BR><FONT size=3D2>&gt;personnel assigned to the =
project to=20
  read it. They do it using end-end encryption. </FONT><BR><FONT =
size=3D2>&gt;PKI=20
  concepts were designed for this distributed, client centric model. =
</FONT></P>
  <P><FONT size=3D2>Even in this example you have conflicts with =
different=20
  interests that may suggest that </FONT><BR><FONT size=3D2>a =
domain-solution=20
  could fit as well. Assume that more than one individual is =
</FONT><BR><FONT=20
  size=3D2>supposed to be able to access the sent document. In that case =
it would=20
  be more </FONT><BR><FONT size=3D2>appropriate to encrypt using a =
domain public=20
  key and let the receiver's local client file access </FONT><BR><FONT=20
  size=3D2>system direct who is going to have access to the document. =
Otherwise it=20
  looks </FONT><BR><FONT size=3D2>like this document is not a part of =
some=20
  organization's activity and in that case </FONT><BR><FONT =
size=3D2>domain-PKI=20
  does of course not apply. In the senders end it may be in the =
</FONT><BR><FONT=20
  size=3D2>organization's interests to monitor all outgoing documents. =
That is in=20
  conflict </FONT><BR><FONT size=3D2>with the client doing the =
encryption.=20
  </FONT></P>
  <P><FONT size=3D2>And the very same problem is also valid for =
archiving of=20
  signed data from authorities. </FONT><BR><FONT size=3D2>Using =
domain-PKI you get=20
  it for free. Using client-PKI (only) you get less </FONT><BR><FONT=20
  size=3D2>control which is bad as control probably was the reason for =
adding PKI=20
  in the first place! </FONT></P>
  <P><FONT size=3D2>And now the heat is on directories...</FONT> </P>
  <P><FONT size=3D2>An interesting side-effect of Purple-type of =
solutions is that=20
  [more or less] public directories</FONT> <BR><FONT size=3D2>holding =
information=20
  about employees become largely superfluous as all information =
required</FONT>=20
  <BR><FONT size=3D2>for a certain relation is in the tickets =
themselves.&nbsp;=20
  I.e. purchaser "profile" information is a</FONT> <BR><FONT =
size=3D2>typical item=20
  that now finally have gotten a suitable container to be transported =
in.</FONT>=20
  </P>
  <P><FONT size=3D2>/anders</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0084_01C0C26E.1F962AA0--



Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA16882 for <[e-mail]>; Tue, 10 Apr 2001 18:47:30 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id SAA21534; Tue, 10 Apr 2001 18:47:02 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id SAA01703; Tue, 10 Apr 2001 18:47:02 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 10 Apr 2001 18:50:29 -0700
To: Ed Gerck <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Cc: "David P. Kemp" <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:17 PM 4/10/01 -0700, Ed Gerck wrote:
>List:
>
>I think there is some agreement, on this page at least. What the current
>NR bit is signaling is that there is (somewhere, not necessarily at the
>CA) some proof of authentication.  I suggested the name POA (proof
>of authentication) at the last time we discussed this.  The POA does not
>have to be persistent, though -- it may be valid only for a short time
>(in practice we find that a short time correlates well with higher
>assurance), some time in the past.
>
>OTOH, we still have the pesky problem of denoting a service that
>prevents the denial of an act, which prevention also needs to be
>qualified.  Preventing the denial of act X cannot be derived from
>affirming act Y, usually, and thus non-repudiation is IMO a necessary
>primitive in certification procedures, in the same way (and not less)
>that authentication is.
>
>In particular, the oftentimes expressed idea that non-repudiation is a strong
>form of authentication, or a persistent form of authentication, is possibly at
>the root of this confusion.  It is neither, as we can see by re-reading (if
>we must) the NR thread in this listserv.  So, if NR is missing (as it is 
>becoming
>clearer) then we are also missing an important part of a our toolkit. Calling
>the current NR-bit the POA-bit or the PDA-bit only solves the semantic
>problem, not the technical problem. Not very useful, considering the other
>semantic problems in PKIX/X.509 that are left untouched (let's talk about
>"Distinguished Names"?).

Hi Ed!

Good call.  (I guess I need to review those archives ... :)

It would be nice to have concise definitions for PDA (Persistent Data 
Authentication) and POA (Proof of Authentication) in marginally technical 
(read: tangible) terms.  Then, consideration of NR might be more clearly 
understood in contrast.

When you say that POA need not require persistence, do you mean to imply 
that (given short-term POA,) persistence becomes a separate 
chain-of-custody issue?

Do you feel that Tom Ginden's "Technical NR" provides a basis for POA/PDA ?

Do you feel that there is anything else that a certificate could hold (and 
to which a CA would attest) that would move further in support of NR 
capability?  Or is anything beyond a POA assurance the purview of an 
entirely independent service?

Cheers!

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.15.2.33]) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA08087 for <[e-mail]>; Tue, 10 Apr 2001 16:17:16 -0700 (PDT)
Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Tue, 10 Apr 2001 18:17:05 -0500
Message-ID: <[e-mail]>
Date: Tue, 10 Apr 2001 16:17:02 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: "David P. Kemp" <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

List:

I think there is some agreement, on this page at least. What the current
NR bit is signaling is that there is (somewhere, not necessarily at the
CA) some proof of authentication.  I suggested the name POA (proof
of authentication) at the last time we discussed this.  The POA does not
have to be persistent, though -- it may be valid only for a short time
(in practice we find that a short time correlates well with higher
assurance), some time in the past.

OTOH, we still have the pesky problem of denoting a service that
prevents the denial of an act, which prevention also needs to be
qualified.  Preventing the denial of act X cannot be derived from
affirming act Y, usually, and thus non-repudiation is IMO a necessary
primitive in certification procedures, in the same way (and not less)
that authentication is.

In particular, the oftentimes expressed idea that non-repudiation is a strong
form of authentication, or a persistent form of authentication, is possibly at
the root of this confusion.  It is neither, as we can see by re-reading (if
we must) the NR thread in this listserv.  So, if NR is missing (as it is becoming
clearer) then we are also missing an important part of a our toolkit. Calling
the current NR-bit the POA-bit or the PDA-bit only solves the semantic
problem, not the technical problem. Not very useful, considering the other
semantic problems in PKIX/X.509 that are left untouched (let's talk about
"Distinguished Names"?).

Cheers,

Ed Gerck

Tony Bartoletti wrote:

> At 02:00 PM 4/9/01 -0400, David P. Kemp wrote:
> >Bob Jueneman wrote:
> > >
> > > And given that scenario, I continue to believe that the currently
> > > ill-defined bit should be officially deprecated, and some other
> > > attributes defined as necessary with a great deal more precision.
> > > If ISO X.509 and/or the PKIX group refuses to deprecate the bit,
> > > then certainly the user community should.  IMHO, of course.
> >
> >And I continue to believe you are correct.  NR should be deprecated,
> >and replaced with a new name for bit 0:  "Persistent Data
> >Authentication", which would have the property that was once
> >called "Technical NR".
>
> I have to agree.  The greatest utility of this bit, a quality over which
> the CA actually has some control, is the commitment to provide for a degree
> of data-persistence.  If such a revision would occur, these discussions
> could actually address something tangible.
>
> ___tony___
>
> Tony Bartoletti 925-422-3881 <[e-mail]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA01952 for <[e-mail]>; Tue, 10 Apr 2001 14:39:25 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <2VHDBVBJ>; Tue, 10 Apr 2001 17:38:57 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Anders Rundgren <[e-mail]>, Santosh Chokhani <[e-mail]>, "Fillingham,  David W." <[e-mail]>, PKIX-List <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, [e-mail], "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, [e-mail], [e-mail], "'Steve Hanna (SUN)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>, Roger Younglove <[e-mail]>
Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
Date: Tue, 10 Apr 2001 17:30:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C205.75010500"

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_01C0C205.75010500
Content-Type: text/plain;
	charset="iso-8859-1"

Anders:

I do not think you understand this.  My customers do not want intermediate
systems except the people working on the project to access the data.

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Tuesday, April 10, 2001 5:26 PM
To: Santosh Chokhani; Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD
PKI TWG'; [e-mail]; 'Bridge CA Mail List'; 'BCA Integration';
'Steve Capps'; Wagner, Clark J.; [e-mail];
[e-mail]; 'Steve Hanna (SUN)'; 'Susan Dernik';
Roger Younglove
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations


Santosh, 

>Having looked at the papers you sent, I think your solutions may be ok as a
B2B solution. 

I believe so.

>But, I see end to end security requiring PKI. Even in our company's case
where 
>we run independent labs, do PKI consulting and build PKI products, some of
our lab 
>customers when they send us documents over the Internet, they want only the
lab 
>personnel assigned to the project to read it. They do it using end-end
encryption. 
>PKI concepts were designed for this distributed, client centric model. 

Even in this example you have conflicts with different interests that may
suggest that 
a domain-solution could fit as well. Assume that more than one individual is

supposed to be able to access the sent document. In that case it would be
more 
appropriate to encrypt using a domain public key and let the receiver's
local client file access 
system direct who is going to have access to the document. Otherwise it
looks 
like this document is not a part of some organization's activity and in that
case 
domain-PKI does of course not apply. In the senders end it may be in the 
organization's interests to monitor all outgoing documents. That is in
conflict 
with the client doing the encryption. 

And the very same problem is also valid for archiving of signed data from
authorities. 
Using domain-PKI you get it for free. Using client-PKI (only) you get less 
control which is bad as control probably was the reason for adding PKI in
the first place! 

And now the heat is on directories...

An interesting side-effect of Purple-type of solutions is that [more or
less] public directories
holding information about employees become largely superfluous as all
information required
for a certain relation is in the tickets themselves.  I.e. purchaser
"profile" information is a
typical item that now finally have gotten a suitable container to be
transported in.

/anders


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: DoD Bridge Certification Authority Phase II =
Demonstrations</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I do not think you understand this.&nbsp; My =
customers do not want intermediate systems except the people working on =
the project to access the data.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 10, 2001 5:26 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani; Fillingham, David W.; =
PKIX-List; 'KPCMWG'; 'DoD</FONT>
<BR><FONT SIZE=3D2>PKI TWG'; [e-mail]; 'Bridge CA Mail List'; =
'BCA Integration';</FONT>
<BR><FONT SIZE=3D2>'Steve Capps'; Wagner, Clark J.; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]; 'Steve Hanna =
(SUN)'; 'Susan Dernik';</FONT>
<BR><FONT SIZE=3D2>Roger Younglove</FONT>
<BR><FONT SIZE=3D2>Subject: Re: DoD Bridge Certification Authority =
Phase II Demonstrations</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>&gt;Having looked at the papers you sent, I think =
your solutions may be ok as a B2B solution. </FONT>
</P>

<P><FONT SIZE=3D2>I believe so.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;But, I see end to end security requiring PKI. =
Even in our company's case where </FONT>
<BR><FONT SIZE=3D2>&gt;we run independent labs, do PKI consulting and =
build PKI products, some of our lab </FONT>
<BR><FONT SIZE=3D2>&gt;customers when they send us documents over the =
Internet, they want only the lab </FONT>
<BR><FONT SIZE=3D2>&gt;personnel assigned to the project to read it. =
They do it using end-end encryption. </FONT>
<BR><FONT SIZE=3D2>&gt;PKI concepts were designed for this distributed, =
client centric model. </FONT>
</P>

<P><FONT SIZE=3D2>Even in this example you have conflicts with =
different interests that may suggest that </FONT>
<BR><FONT SIZE=3D2>a domain-solution could fit as well. Assume that =
more than one individual is </FONT>
<BR><FONT SIZE=3D2>supposed to be able to access the sent document. In =
that case it would be more </FONT>
<BR><FONT SIZE=3D2>appropriate to encrypt using a domain public key and =
let the receiver's local client file access </FONT>
<BR><FONT SIZE=3D2>system direct who is going to have access to the =
document. Otherwise it looks </FONT>
<BR><FONT SIZE=3D2>like this document is not a part of some =
organization's activity and in that case </FONT>
<BR><FONT SIZE=3D2>domain-PKI does of course not apply. In the senders =
end it may be in the </FONT>
<BR><FONT SIZE=3D2>organization's interests to monitor all outgoing =
documents. That is in conflict </FONT>
<BR><FONT SIZE=3D2>with the client doing the encryption. </FONT>
</P>

<P><FONT SIZE=3D2>And the very same problem is also valid for archiving =
of signed data from authorities. </FONT>
<BR><FONT SIZE=3D2>Using domain-PKI you get it for free. Using =
client-PKI (only) you get less </FONT>
<BR><FONT SIZE=3D2>control which is bad as control probably was the =
reason for adding PKI in the first place! </FONT>
</P>

<P><FONT SIZE=3D2>And now the heat is on directories...</FONT>
</P>

<P><FONT SIZE=3D2>An interesting side-effect of Purple-type of =
solutions is that [more or less] public directories</FONT>
<BR><FONT SIZE=3D2>holding information about employees become largely =
superfluous as all information required</FONT>
<BR><FONT SIZE=3D2>for a certain relation is in the tickets =
themselves.&nbsp; I.e. purchaser &quot;profile&quot; information is =
a</FONT>
<BR><FONT SIZE=3D2>typical item that now finally have gotten a suitable =
container to be transported in.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C0C205.75010500--


Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA00938 for <[e-mail]>; Tue, 10 Apr 2001 14:28:27 -0700 (PDT)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maila.telia.com (8.9.3/8.9.3) with ESMTP id XAA10187; Tue, 10 Apr 2001 23:27:56 +0200 (CEST)
Received: from mega (t2o69p79.telia.com [62.20.144.199]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f3ALRsa01203; Tue, 10 Apr 2001 23:27:54 +0200 (CEST)
Message-ID: <003701c0c204$d4e10bb0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Fillingham,  David W." <[e-mail]>, "PKIX-List" <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, <[e-mail]>, "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, <[e-mail]>, <[e-mail]>, "'Steve Hanna \(SUN\)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>, "Roger Younglove" <[e-mail]>
References: <[e-mail]>
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
Date: Tue, 10 Apr 2001 23:25:53 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA00939

Santosh, 

>Having looked at the papers you sent, I think your solutions may be ok as a B2B solution. 

I believe so.

>But, I see end to end security requiring PKI. Even in our company's case where 
>we run independent labs, do PKI consulting and build PKI products, some of our lab 
>customers when they send us documents over the Internet, they want only the lab 
>personnel assigned to the project to read it. They do it using end-end encryption. 
>PKI concepts were designed for this distributed, client centric model. 

Even in this example you have conflicts with different interests that may suggest that 
a domain-solution could fit as well. Assume that more than one individual is 
supposed to be able to access the sent document. In that case it would be more 
appropriate to encrypt using a domain public key and let the receiver's local client file access 
system direct who is going to have access to the document. Otherwise it looks 
like this document is not a part of some organization's activity and in that case 
domain-PKI does of course not apply. In the senders end it may be in the 
organization's interests to monitor all outgoing documents. That is in conflict 
with the client doing the encryption. 

And the very same problem is also valid for archiving of signed data from authorities. 
Using domain-PKI you get it for free. Using client-PKI (only) you get less 
control which is bad as control probably was the reason for adding PKI in the first place! 

And now the heat is on directories...

An interesting side-effect of Purple-type of solutions is that [more or less] public directories
holding information about employees become largely superfluous as all information required
for a certain relation is in the tickets themselves.  I.e. purchaser "profile" information is a
typical item that now finally have gotten a suitable container to be transported in.

/anders




Received: from mclean5-mail.usae.bah.com (mclean5-mail.usae.bah.com [156.80.5.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA26202 for <[e-mail]>; Tue, 10 Apr 2001 13:33:29 -0700 (PDT)
Received: from bah.com ([134.205.161.104]) by mclean5-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id GBLFRW00.UQU; Tue, 10 Apr 2001 16:33:32 -0400 
Message-ID: <[e-mail]>
Date: Tue, 10 Apr 2001 16:33:32 -0400
From: "Frank Lawrence" <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: PKIX-List <[e-mail]>
Subject: Re: Domain-PKI. Was: DoD Bridge Certification Authority Phase II  Demonstrations
References: <[e-mail]> <[e-mail]> <014d01c0c1df$aebe0390$0500a8c0@arport> <[e-mail]> <012201c0c1f5$9f92cc00$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Embedded stuff below:

Anders Rundgren wrote:

> > The problem that I see with the Purple model is that there is a requirement for
> > explicit trust between the "partners".  Known partners are nice but does not solve
> > the broader problem of extending trust.
>
> Now you hit a weak point in PKI in general.  What do we mean by trust?  That the
> entity is the one they are claiming to be?  I do not belie (PKI is a religion?)
> that it is enough that you have a certificate from a trusted CA.  Because if you want
> to conduct business you may actually be more interested in knowing that a buyer
> is capable of paying or that the supplier delivers.  Such information can sometimes be
> obtained from TTP's specializing in such data (e.g. D & B).  By identifying the entity
> with their organization certificate you have the "perfect handle" for perfoming such
> queries.   And how much trust you have in an unkown organization is up to every
> partner to decide.  I.e. a CA <> God!
>

I agree this is the generic problem with PKI as implemented in the commercial world where there is no
control of the issuing process.  The certificate policy in use at any CA is, in general, very weak.  A
strong (and enforced) certificate policy provide better assurance.  The stronger the mechanisms (such as
hardware token vice storing keys on hard drive) the higher the assurance level.

>
> > Works fine as long as the number of partners is small, but is combinatorially
> > explosive as the number of partners becomes large.
>
> No, domain-PKI follows a linear scale as partners are autonomous.  I.e. domain-PKI
> is simply a way for an organization to sign messages using a digital version of their
> company paper.  But unlike the paper-version, the digital version is usually issued by
> a TTP and is extremely hard to forge.
>

Each organization of N must maintain n-1 relationships if the they all must have trust with each other.
If I remember my analysis of algorithms class correctly (it has been several years!), that is N^n-1
relationships,  which I do not believe is linear.

>
> >  The ability to manage that
> > large number of trust relationships becomes just as difficult as the bridge CA
> > problem.  The "unwieldy" PKI created by DoD elminates that problem, at least within
> > DoD where there are hundreds (maybe thousands?) of "partner" domains.  At least
> > within DoD there is an understanding of the level of trust involved in getting a
> > certificate.
>
> Many companies have more than 10000 suppliers, domain-PKI adds little
> to the complexity (in principal at least).  And it definitely beats current
> "state-of-the-art-solutions" using user-ID passwords on partner sites.

Agree that userid and password is not a good solution.  Its the "in principle" I am concern with.  If
all 10000 were issued by someone they all trust, then the maintenance of the relationships is
definitiely simpler.  In the commercial world, that is probably NOT realistic.  In an organization with
several thousand domains IN it (like DoD), it certainly has its advantages, especially when you allocate
the time and resources needed to have a high assurance issuance policy.

>
>
> > The current HTTPS model is a bad example of trust because there is no (valid)
> > presumption of trust between a web server and a client.  SSL encrypts the pipe but
> > there is no method for determining if the client or the server is who they claim to
> > be.  Trivial to spoof either (or both) although the pipe is secure from
> > observation.  Even IPSEC based authentication (a step above the SSL model) does not
> > provide any assurance that the claimed user is who they say they are.  Unless there
> > is a trust model that extends across the network, in a scalable manner, then the
> > relying party is left holding the bag.
>
> Client-PKI does not make you safe from impersonators, or does it?

If you trust the CA and the user maintains control of the private identity key then yes.  Who do you
trust and why is the critical issue.  Most organizations do not have the discipline to make and enforce
a high assurance certificate policy.

>
>
> > Finally, to trust a domain, you must understand how that domain issues
> > certificates.  If there is no policy which tells a relying party what the level of
> > assurance is involved in the creation of the certificate, then the level of trust
> > you place in that certificate is zero.
>
> If you refer to the Purple tickets they are no different than purchase orders (which
> BTW is sort of a certificate).  If you trust the purchase orders you ought to be able to
> trust tickets as they are created about the same way by the very same system
> run by the very same organization and staff.
>

I think a lawyer would tell you that you trust in the purchase order comes from the wet signature on the
purchgase order, not the form itself.  If taken to court, the signature will be the subject of the
discussion, not the form.  If the purple ticket is issued without any authentication required for the
person who gets the ticket, that is like setting a stack of signed blank forms at the receptionists
desk!  If I hack a local client, does the server provide appropriate credentials when I go out and order
things which are not required?  Is the company which owns the server liable for the orders placed?

>
> But the motives for domain-PKI have so many more elements that I could go on
> the whole night to describe them all but I think it is better to go through the
> references instead of just repeating myself.
>
> ====================================================
> With the exception of end-to-end authentication, domain-PKI IMO seems to
> beat client-based PKIs for B2B by a mile.  Regarding end-to-end authentication
> of Purple tickets (and Shibboleth and SAML dittos),  I have BTW a few suggestions
> that I would like to discuss with interested parties.  It looks like this indeed can be
> solved in a very convenient way (no local client configuration) but it requires an upgraded
> browser.
> ====================================================
>
> Anders



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA25468 for <[e-mail]>; Tue, 10 Apr 2001 13:21:10 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <2VHDBT6J>; Tue, 10 Apr 2001 16:20:41 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Frank Lawrence <[e-mail]>, Anders Rundgren <[e-mail]>
Cc: Santosh Chokhani <[e-mail]>, "Fillingham David W." <[e-mail]>, PKIX-List <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, [e-mail], "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, * ALL FIREBURST USERS * <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner Clark J." <[e-mail]>, [e-mail], [e-mail], "'Steve Hanna (SUN)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>, Roger Younglove <[e-mail]>
Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
Date: Tue, 10 Apr 2001 16:12:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1FA.855FB280"

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_01C0C1FA.855FB280
Content-Type: text/plain;
	charset="iso-8859-1"

Larry:

1.  Trust between two clients is required regardless of the model.  It could
be explicit (cross certification) or indirect (Bridge CA).  The effort
involved is about the same.

2.  Bridge CA does NOT have combinatorial explosion since it scales
linearly.  N folks need N agreements with the Bridge as opposed to
n*(n-1)/2.

3.  Look at the purple model.  All it is doing is letting the organization
server sign the PO etc. as opposed to Purchasing Officer.  It is not
necessarily SSL.  We could argue as to how to tighten the server
authentication process.

-----Original Message-----
From: Frank Lawrence [mailto:[e-mail]]
Sent: Tuesday, April 10, 2001 1:41 PM
To: Anders Rundgren
Cc: Santosh Chokhani; Fillingham David W.; PKIX-List; 'KPCMWG'; 'DoD PKI
TWG'; [e-mail]; 'Bridge CA Mail List'; 'BCA Integration'; * ALL
FIREBURST USERS *; 'Steve Capps'; Wagner Clark J.;
[e-mail]; [e-mail]; 'Steve Hanna
(SUN)'; 'Susan Dernik'; Roger Younglove
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations


I will take a shot of the problem with the purple model.

The problem that I see with the Purple model is that there is a requirement
for
explicit trust between the "partners".  Known partners are nice but does not
solve
the broader problem of extending trust.

Works fine as long as the number of partners is small, but is
combinatorially
explosive as the number of partners becomes large.   The ability to manage
that
large number of trust relationships becomes just as difficult as the bridge
CA
problem.  The "unwieldy" PKI created by DoD elminates that problem, at least
within
DoD where there are hundreds (maybe thousands?) of "partner" domains.  At
least
within DoD there is an understanding of the level of trust involved in
getting a
certificate.

The current HTTPS model is a bad example of trust because there is no
(valid)
presumption of trust between a web server and a client.  SSL encrypts the
pipe but
there is no method for determining if the client or the server is who they
claim to
be.  Trivial to spoof either (or both) although the pipe is secure from
observation.  Even IPSEC based authentication (a step above the SSL model)
does not
provide any assurance that the claimed user is who they say they are.
Unless there
is a trust model that extends across the network, in a scalable manner, then
the
relying party is left holding the bag.

Finally, to trust a domain, you must understand how that domain issues
certificates.  If there is no policy which tells a relying party what the
level of
assurance is involved in the creation of the certificate, then the level of
trust
you place in that certificate is zero.

Anders Rundgren wrote:

> Roger,
>
> >IMHO, when you have multiple PKIs with in any industry such as the
> >Automotive (ie. ANX) or the Government, cross certification become a
> >problem because the certificate chain of trust becomes so unwieldy and
> >revocation of a PKI is also a problem. The Bridge scenario solves this
> >problem. It is not the only solution but the simplest with a number of
> >existing PKIs.
>
> Agreed, Bridge CAs solves (some of) the problems created by
> unwieldy PKIs such as those created by DoD.
>
> Domain-PKI does not requires such solutions as it is much simpler
> to create and maintain.  100 millions users of Internet use it today
> when they address an https URL.  That's simplicity IMHO.
> Applied to B2B it gets just slightly more complicated.
>
> Anders
>
> At 05:21 AM 04/10/2001 , Anders Rundgren wrote:
> >Santosh,
> >Domain (server-based) PKI offers persistent signatures for
non-repudiation
> >at a fraction
> >of the cost (and inconvenience) that inter-organization client-based
> >signatures introduce.
> >The need for bridge-CAs using domain-PKI is IMO very limited as the
number
> >of CAs is
> >reduced by several orders of magnitude by such approaches. 5-10 CAs
> >worldwide is my guess.
> >
> >I do have read the paper by Bill Burr. Did you read about Purple? I.e. do
> >you see a problem with this model?
> >
> >BTW, I am a (currently only lurking due to high work-load) member of the
> >OASIS Security Services TC where
> >domain-based solutions are standardized. I have never ever seen such an
> >enormous committee activity so domain
> >security is indeed red-hot.
> >
> >Internet2 with their Shibboleth distributed multi-campus authentication
> >system will be based on domain-PKI.
> >
> >Personally I expect the next version of OBI (Open Buying on the Internet)
> >to be entirely based
> >on this concept by throwing out the inter-organization client-certs (that
> >never worked, so just about
> >everybody turned to user-ID/passwords in spite of not being a part of the
> >standard).
> >
> >VISA's coming 3D Secure credit-card payment system is also based on
> >domain-PKI.
> >
> >Due to this, I think that DoD (and similar organizations all over the
> >globe) should very carefully evaluate the
> >domain security alternative before they do any new investments in CA
systems.
> >
> >Regards
> >Anders
> >----- Original Message -----
> >From: Santosh Chokhani
> >To: Anders Rundgren ; Fillingham, David W. ; PKIX-List ; 'KPCMWG' ; 'DoD
> >PKI TWG' ; [e-mail] ; 'Bridge CA Mail List' ; 'BCA
> >Integration' ; * ALL FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J.
> >; [e-mail] ;
> >[e-mail] ; 'Steve Hanna (SUN)' ; 'Susan Dernik'
> >Sent: Monday, April 09, 2001 22:39
> >Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
> >
> >
> >Anders:
> >I think Bridge technology can be helpful to a vertical segment such as
> >banking, health care, automotive industry etc. in order to
> >facilitate secure e-commerce among the trading partners where persistent
> >digital signature for non-repudiation may be required.
> >Also, given how organizations manage their Web sites and we hear about
Web
> >server break-in, persistent encryption (beyond SSL
> >transport) may call for interoperable, inter-domain PKI.  Again Bridge CA
> >can help.
> >Actually, I can see the benefits of layers (strata) of Bridge CAs, e.g.,
> >Bridge CAs from various vertical segments themselves
> >connecting to a Omni-Bridge.  In that case, the Bridge CAs will be
> >Principal CAs.
> >I assume you have had a chance to review the excellent paper on the
Bridge
> >concept developed by Bill Burr.
> >-----Original Message-----
> >From: Anders Rundgren [mailto:[e-mail]]
> >Sent: Monday, April 09, 2001 2:08 PM
> >To: Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD PKI TWG';
> >[e-mail]; 'Bridge CA Mail List'; 'BCA Integration'; * ALL
> >FIREBURST USERS *; 'Steve Capps'; Wagner, Clark J.;
> >[e-mail]; [e-mail]; 'Steve Hanna
> >(SUN)'; 'Susan Dernik'
> >Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
> >
> >
> >David,
> >This is indeed an ambitious project. Unfortunately I doubt that the
Bridge
> >model has any relevance in
> >the private sector that for inter-organization communication, is more
> >likely to deploy domain-based
> >PKI-solutions, that have the major advantage of already being supported
by
> >global TTPs which makes
> >domain security solutions useful for organizations of any size. I.e.
> >VeriSign's issuance of web-server
> >certificates is "approximately" what is needed.
> >That domain security is incompatible with most current digital signature
> >laws is a pity.  Particularly for
> >the lawyers who created them.  :-)
> >Using domain security, tracing, message archiving, and user-control is
> >essentially built-in.
> >A further advantage of domain security models is that client security
> >solutions can develop in a
> >different pace at each organization.  As they have for current
> >Internet-banks that is so far the only
> >large-scale (almost) secure multi-organization transaction-environment on
> >the Internet.
> >The question that comes to my mind is: Will all Governments in the world
> >continue to adopt the
> >"All-speak-with-all-PKI" approach in spite of the fact that the private
> >sector probably have shunned it
> >due to complexity, privacy concerns, lack of control, and cost?
> >Regard
> >Anders Rundgren
> >X-OBI  read: http://www.x-obi.com/purple  run: http://buyer.x-obi.com
> >
> >
> >
> >----- Original Message -----
> >From: Fillingham, David W.
> >To: '[e-mail]' ; 'KPCMWG' ; 'DoD PKI TWG' ; '[e-mail]' ;
> >'Bridge CA Mail List' ; 'BCA Integration' ; * ALL
> >FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. ;
> >'[e-mail]' ; '[e-mail]' ; 'Steve
Hanna
> >(SUN)' ; 'Susan Dernik'
> >Sent: Friday, April 06, 2001 16:48
> >Subject: DoD Bridge Certification Authority Phase II Demonstrations
> >
> >
> >For the last few years, the National Security Agency has led the
> >development of Bridge Certification Authority (BCA) technology
> >demonstrations.  In 1999, Phase One of the Department of Defense BCA
> >Technology Demonstration showed the technical feasibility of
> >achieving signed e-mail interoperability using multi-vendor
> >cross-certification in conjunction with chained directory systems.
> >
> >Phase Two of the demonstration is now ready to be shown.  Phase Two of
the
> >DoD Bridge CA Phase II Technology Demonstration includes:
> >
> >Technologies:
> >
> >--  Certificate chain building in complex certificate graphs;
> >--  Integration of both mesh-style cross-certified PKIs and hierarchical
PKIs;
> >--  Multi-signature/hash algorithm processing in certificate chains;
> >--  Certificate acceptance/rejection based on Certificate Policy
> >processing, including policy mapping;
> >--  Transitive trust limitation using Name Constraints processing;
> >--  Access Control using X.509 compliant attribute certificates (same
> >attribute certificates used for e-mail and web based access
> >control);
> >--  E-mail access control using S/MIME V3 labeling;
> >--  E-mail encryption using public key certificates authenticated via a
> >Bridge Certification Authority;
> >--  Border Directories;
> >--  Multivendor directory interoperation via X.500 chaining; and,
> >--  Transparent sharing of certificate revocation information across
> >several  PKIs using products of multiple PKI vendors.
> >
> >Client Applications:
> >
> >--  Baltimore Technologies MailSecure enabled Microsoft Outlook
> >--  Entrust Enabled Microsoft Outlook
> >--  Getronics S/MIME Freeware Library, Certificate Management Library,
and
> >Access Control Library enabled Qualcomm Eudora
> >--  Getronics Certificate Management Library and Access Control Library
> >enabled Netscape Web Server
> >
> >Freeware Libraries:
> >
> >--  Cygnacom Certificate Path Development Library
> >      <http://www.cygnacom.com/products/index.htm>
> >--  Getronics S/MIME (Version 3) Freeware Library
> >      <http://www.getronicsgov.com/hot/sfl_home.htm>
> >--  Getronics Certificate Management Library
> >      <http://www.getronicsgov.com/hot/cml_home.htm>
> >-- Getronics Access Control Library
> >           <http://www.getronicsgov.com/hot/acl_home.htm>
> >CA vendor interoperability demonstrations:
> >
> >--  Baltimore Technologies
> >--  Entrust Technologies
> >--  Motorola
> >--  SPYRUS
> >
> >Directory Interoperability:
> >--  Entrust ICL
> >--  Entegrity Safepages Directory
> >Demonstrations will be held at the following locations and dates (note
> >that you MUST REGISTER to attend!  Registration information
> >is provided below):
> >
> >----------
> >CygnaCom
> >Suite 100 West
> >7927 Jones Branch Dr.
> >McLean, Virginia
> >
> >Directions to CygnaCom are located
> >at:  <http://www.cygnacom.com/contact/directions.htm>
> >
> >26 April 2001 - 0900
> >
> >26 April 2001 - 1300
> >
> >16 May 2001 - 0900
> >
> >16 May 2001 - 1300
> >
> >---------
> >Getronics Government Solutions
> >141 National Business Parkway, Suite 210
> >Annapolis Junction, Maryland
> >
> > From Washington DC: Take I-95 north; take MD Rt 32 east exit; take
Dorsey
> >Run exit; at stop sign turn left on Dorsey Run; at stop light turn right
on
> >Guilford Road which becomes National Business Pkwy.
> >
> > From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit;
stay
> >in right lane of the exit which runs into National Business Pkwy; make a
> >right on National Business Pkwy.
> >
> >30 April 2001 - 1300
> >
> >8 May 2001 - 0900
> >
> >8 May 2001 - 1300
> >
> >24 May 2001 - 0900
> >
> >24 May 2001 - 1300
> >
> >---------
> >
> >All showings last about half a day - with a mixture of conference room
> >briefings and laboratory demonstrations.
> >
> >We are limited by available demonstration space to an absolute maximum of
> >20 participants at each showing.
> >
> >IMPORTANT:  PLEASE REGISTER WITH LISA FAULKNER ([e-mail]
> ><mailto:[e-mail]>) AND MYSELF
> >([e-mail] <mailto:[e-mail]>) IF YOU PLAN TO
> >ATTEND.  IF YOU DO NOT REGISTER TO ATTEND, YOU WILL NOT BE
> >ADMITTED TO THE DEMONSTRATION.
> >
> >Please provide the following information to register:
> >
> >--  Name
> >--  Organization
> >--  E-mail address
> >--  Date and time of the demonstration showing you wish to attend (with
> >alternates, if possible)
> >
> >We look forward to seeing you at the demonstration!
> >
> >Dave Fillingham
> >NSA
>
> --------
> TTFN
> Roger W. Younglove, CISSP
> Distinguished Member of Consulting Staff
> Lucent Worldwide Services--Information Security
> 100 Galleria Officentre, Ste. 220
> Southfield, MI 48034-8428
> Numeric page: 888.935.6755
> E-mail page:
> [e-mail]
> eFax number: 413.425.5368
> www.lucent.com/netcare

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: DoD Bridge Certification Authority Phase II =
Demonstrations</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>1.&nbsp; Trust between two clients is required =
regardless of the model.&nbsp; It could be explicit (cross =
certification) or indirect (Bridge CA).&nbsp; The effort involved is =
about the same.</FONT></P>

<P><FONT SIZE=3D2>2.&nbsp; Bridge CA does NOT have combinatorial =
explosion since it scales linearly.&nbsp; N folks need N agreements =
with the Bridge as opposed to n*(n-1)/2.</FONT></P>

<P><FONT SIZE=3D2>3.&nbsp; Look at the purple model.&nbsp; All it is =
doing is letting the organization server sign the PO etc. as opposed to =
Purchasing Officer.&nbsp; It is not necessarily SSL.&nbsp; We could =
argue as to how to tighten the server authentication =
process.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Frank Lawrence [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 10, 2001 1:41 PM</FONT>
<BR><FONT SIZE=3D2>To: Anders Rundgren</FONT>
<BR><FONT SIZE=3D2>Cc: Santosh Chokhani; Fillingham David W.; =
PKIX-List; 'KPCMWG'; 'DoD PKI</FONT>
<BR><FONT SIZE=3D2>TWG'; [e-mail]; 'Bridge CA Mail List'; 'BCA =
Integration'; * ALL</FONT>
<BR><FONT SIZE=3D2>FIREBURST USERS *; 'Steve Capps'; Wagner Clark =
J.;</FONT>
<BR><FONT SIZE=3D2>[e-mail]; =
[e-mail]; 'Steve Hanna</FONT>
<BR><FONT SIZE=3D2>(SUN)'; 'Susan Dernik'; Roger Younglove</FONT>
<BR><FONT SIZE=3D2>Subject: Re: DoD Bridge Certification Authority =
Phase II Demonstrations</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I will take a shot of the problem with the purple =
model.</FONT>
</P>

<P><FONT SIZE=3D2>The problem that I see with the Purple model is that =
there is a requirement for</FONT>
<BR><FONT SIZE=3D2>explicit trust between the =
&quot;partners&quot;.&nbsp; Known partners are nice but does not =
solve</FONT>
<BR><FONT SIZE=3D2>the broader problem of extending trust.</FONT>
</P>

<P><FONT SIZE=3D2>Works fine as long as the number of partners is =
small, but is combinatorially</FONT>
<BR><FONT SIZE=3D2>explosive as the number of partners becomes =
large.&nbsp;&nbsp; The ability to manage that</FONT>
<BR><FONT SIZE=3D2>large number of trust relationships becomes just as =
difficult as the bridge CA</FONT>
<BR><FONT SIZE=3D2>problem.&nbsp; The &quot;unwieldy&quot; PKI created =
by DoD elminates that problem, at least within</FONT>
<BR><FONT SIZE=3D2>DoD where there are hundreds (maybe thousands?) of =
&quot;partner&quot; domains.&nbsp; At least</FONT>
<BR><FONT SIZE=3D2>within DoD there is an understanding of the level of =
trust involved in getting a</FONT>
<BR><FONT SIZE=3D2>certificate.</FONT>
</P>

<P><FONT SIZE=3D2>The current HTTPS model is a bad example of trust =
because there is no (valid)</FONT>
<BR><FONT SIZE=3D2>presumption of trust between a web server and a =
client.&nbsp; SSL encrypts the pipe but</FONT>
<BR><FONT SIZE=3D2>there is no method for determining if the client or =
the server is who they claim to</FONT>
<BR><FONT SIZE=3D2>be.&nbsp; Trivial to spoof either (or both) although =
the pipe is secure from</FONT>
<BR><FONT SIZE=3D2>observation.&nbsp; Even IPSEC based authentication =
(a step above the SSL model) does not</FONT>
<BR><FONT SIZE=3D2>provide any assurance that the claimed user is who =
they say they are.&nbsp; Unless there</FONT>
<BR><FONT SIZE=3D2>is a trust model that extends across the network, in =
a scalable manner, then the</FONT>
<BR><FONT SIZE=3D2>relying party is left holding the bag.</FONT>
</P>

<P><FONT SIZE=3D2>Finally, to trust a domain, you must understand how =
that domain issues</FONT>
<BR><FONT SIZE=3D2>certificates.&nbsp; If there is no policy which =
tells a relying party what the level of</FONT>
<BR><FONT SIZE=3D2>assurance is involved in the creation of the =
certificate, then the level of trust</FONT>
<BR><FONT SIZE=3D2>you place in that certificate is zero.</FONT>
</P>

<P><FONT SIZE=3D2>Anders Rundgren wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Roger,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;IMHO, when you have multiple PKIs with in =
any industry such as the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Automotive (ie. ANX) or the Government, =
cross certification become a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;problem because the certificate chain of =
trust becomes so unwieldy and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;revocation of a PKI is also a problem. The =
Bridge scenario solves this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;problem. It is not the only solution but =
the simplest with a number of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;existing PKIs.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Agreed, Bridge CAs solves (some of) the =
problems created by</FONT>
<BR><FONT SIZE=3D2>&gt; unwieldy PKIs such as those created by =
DoD.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Domain-PKI does not requires such solutions as =
it is much simpler</FONT>
<BR><FONT SIZE=3D2>&gt; to create and maintain.&nbsp; 100 millions =
users of Internet use it today</FONT>
<BR><FONT SIZE=3D2>&gt; when they address an https URL.&nbsp; That's =
simplicity IMHO.</FONT>
<BR><FONT SIZE=3D2>&gt; Applied to B2B it gets just slightly more =
complicated.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Anders</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; At 05:21 AM 04/10/2001 , Anders Rundgren =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Santosh,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Domain (server-based) PKI offers persistent =
signatures for non-repudiation</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;at a fraction</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;of the cost (and inconvenience) that =
inter-organization client-based</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;signatures introduce.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;The need for bridge-CAs using domain-PKI is =
IMO very limited as the number</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;of CAs is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;reduced by several orders of magnitude by =
such approaches. 5-10 CAs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;worldwide is my guess.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I do have read the paper by Bill Burr. Did =
you read about Purple? I.e. do</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;you see a problem with this model?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;BTW, I am a (currently only lurking due to =
high work-load) member of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;OASIS Security Services TC where</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;domain-based solutions are standardized. I =
have never ever seen such an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;enormous committee activity so =
domain</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;security is indeed red-hot.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Internet2 with their Shibboleth distributed =
multi-campus authentication</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;system will be based on domain-PKI.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Personally I expect the next version of OBI =
(Open Buying on the Internet)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;to be entirely based</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;on this concept by throwing out the =
inter-organization client-certs (that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;never worked, so just about</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;everybody turned to user-ID/passwords in =
spite of not being a part of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;standard).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;VISA's coming 3D Secure credit-card payment =
system is also based on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;domain-PKI.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Due to this, I think that DoD (and similar =
organizations all over the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;globe) should very carefully evaluate =
the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;domain security alternative before they do =
any new investments in CA systems.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Regards</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Anders</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;From: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;To: Anders Rundgren ; Fillingham, David W. =
; PKIX-List ; 'KPCMWG' ; 'DoD</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;PKI TWG' ; [e-mail] ; 'Bridge CA =
Mail List' ; 'BCA</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Integration' ; * ALL FIREBURST USERS * ; =
'Steve Capps' ; Wagner, Clark J.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;; [e-mail] ;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;[e-mail] ; 'Steve =
Hanna (SUN)' ; 'Susan Dernik'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Sent: Monday, April 09, 2001 22:39</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Subject: RE: DoD Bridge Certification =
Authority Phase II Demonstrations</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Anders:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I think Bridge technology can be helpful to =
a vertical segment such as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;banking, health care, automotive industry =
etc. in order to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;facilitate secure e-commerce among the =
trading partners where persistent</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;digital signature for non-repudiation may =
be required.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Also, given how organizations manage their =
Web sites and we hear about Web</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;server break-in, persistent encryption =
(beyond SSL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;transport) may call for interoperable, =
inter-domain PKI.&nbsp; Again Bridge CA</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;can help.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Actually, I can see the benefits of layers =
(strata) of Bridge CAs, e.g.,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Bridge CAs from various vertical segments =
themselves</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;connecting to a Omni-Bridge.&nbsp; In that =
case, the Bridge CAs will be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Principal CAs.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I assume you have had a chance to review =
the excellent paper on the Bridge</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;concept developed by Bill Burr.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;From: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Sent: Monday, April 09, 2001 2:08 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;To: Fillingham, David W.; PKIX-List; =
'KPCMWG'; 'DoD PKI TWG';</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;[e-mail]; 'Bridge CA Mail List'; =
'BCA Integration'; * ALL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;FIREBURST USERS *; 'Steve Capps'; Wagner, =
Clark J.;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;[e-mail]; =
[e-mail]; 'Steve Hanna</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;(SUN)'; 'Susan Dernik'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Subject: Re: DoD Bridge Certification =
Authority Phase II Demonstrations</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;David,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;This is indeed an ambitious project. =
Unfortunately I doubt that the Bridge</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;model has any relevance in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;the private sector that for =
inter-organization communication, is more</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;likely to deploy domain-based</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;PKI-solutions, that have the major =
advantage of already being supported by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;global TTPs which makes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;domain security solutions useful for =
organizations of any size. I.e.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;VeriSign's issuance of web-server</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;certificates is &quot;approximately&quot; =
what is needed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;That domain security is incompatible with =
most current digital signature</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;laws is a pity.&nbsp; Particularly =
for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;the lawyers who created them.&nbsp; =
:-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Using domain security, tracing, message =
archiving, and user-control is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;essentially built-in.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;A further advantage of domain security =
models is that client security</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;solutions can develop in a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;different pace at each organization.&nbsp; =
As they have for current</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Internet-banks that is so far the =
only</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;large-scale (almost) secure =
multi-organization transaction-environment on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;the Internet.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;The question that comes to my mind is: Will =
all Governments in the world</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;continue to adopt the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&quot;All-speak-with-all-PKI&quot; approach =
in spite of the fact that the private</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;sector probably have shunned it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;due to complexity, privacy concerns, lack =
of control, and cost?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Regard</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Anders Rundgren</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;X-OBI&nbsp; read: <A =
HREF=3D"http://www.x-obi.com/purple" =
TARGET=3D"_blank">http://www.x-obi.com/purple</A>&nbsp; run: <A =
HREF=3D"http://buyer.x-obi.com" =
TARGET=3D"_blank">http://buyer.x-obi.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;From: Fillingham, David W.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;To: '[e-mail]' ; 'KPCMWG' ; 'DoD =
PKI TWG' ; '[e-mail]' ;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;'Bridge CA Mail List' ; 'BCA Integration' ; =
* ALL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;FIREBURST USERS * ; 'Steve Capps' ; Wagner, =
Clark J. ;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;'[e-mail]' ; =
'[e-mail]' ; 'Steve Hanna</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;(SUN)' ; 'Susan Dernik'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Sent: Friday, April 06, 2001 16:48</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Subject: DoD Bridge Certification Authority =
Phase II Demonstrations</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;For the last few years, the National =
Security Agency has led the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;development of Bridge Certification =
Authority (BCA) technology</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;demonstrations.&nbsp; In 1999, Phase One of =
the Department of Defense BCA</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Technology Demonstration showed the =
technical feasibility of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;achieving signed e-mail interoperability =
using multi-vendor</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;cross-certification in conjunction with =
chained directory systems.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Phase Two of the demonstration is now ready =
to be shown.&nbsp; Phase Two of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;DoD Bridge CA Phase II Technology =
Demonstration includes:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Technologies:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Certificate chain building in =
complex certificate graphs;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Integration of both mesh-style =
cross-certified PKIs and hierarchical PKIs;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Multi-signature/hash algorithm =
processing in certificate chains;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Certificate acceptance/rejection =
based on Certificate Policy</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;processing, including policy =
mapping;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Transitive trust limitation using =
Name Constraints processing;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Access Control using X.509 =
compliant attribute certificates (same</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;attribute certificates used for e-mail and =
web based access</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;control);</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; E-mail access control using S/MIME =
V3 labeling;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; E-mail encryption using public key =
certificates authenticated via a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Bridge Certification Authority;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Border Directories;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Multivendor directory =
interoperation via X.500 chaining; and,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Transparent sharing of certificate =
revocation information across</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;several&nbsp; PKIs using products of =
multiple PKI vendors.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Client Applications:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Baltimore Technologies MailSecure =
enabled Microsoft Outlook</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Entrust Enabled Microsoft =
Outlook</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Getronics S/MIME Freeware Library, =
Certificate Management Library, and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Access Control Library enabled Qualcomm =
Eudora</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Getronics Certificate Management =
Library and Access Control Library</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;enabled Netscape Web Server</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Freeware Libraries:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Cygnacom Certificate Path =
Development Library</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.cygnacom.com/products/index.htm" =
TARGET=3D"_blank">http://www.cygnacom.com/products/index.htm</A>&gt;</FO=
NT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Getronics S/MIME (Version 3) =
Freeware Library</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/sfl_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/sfl_home.htm</A>&gt;</=
FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Getronics Certificate Management =
Library</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/cml_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/cml_home.htm</A>&gt;</=
FONT>
<BR><FONT SIZE=3D2>&gt; &gt;-- Getronics Access Control Library</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/acl_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/acl_home.htm</A>&gt;</=
FONT>
<BR><FONT SIZE=3D2>&gt; &gt;CA vendor interoperability =
demonstrations:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Baltimore Technologies</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Entrust Technologies</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Motorola</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; SPYRUS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Directory Interoperability:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Entrust ICL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Entegrity Safepages =
Directory</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Demonstrations will be held at the =
following locations and dates (note</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;that you MUST REGISTER to attend!&nbsp; =
Registration information</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;is provided below):</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;----------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;CygnaCom</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Suite 100 West</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;7927 Jones Branch Dr.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;McLean, Virginia</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Directions to CygnaCom are located</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;at:&nbsp; &lt;<A =
HREF=3D"http://www.cygnacom.com/contact/directions.htm" =
TARGET=3D"_blank">http://www.cygnacom.com/contact/directions.htm</A>&gt;=
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;26 April 2001 - 0900</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;26 April 2001 - 1300</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;16 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;16 May 2001 - 1300</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;---------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Getronics Government Solutions</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;141 National Business Parkway, Suite =
210</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Annapolis Junction, Maryland</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From Washington DC: Take I-95 north; take =
MD Rt 32 east exit; take Dorsey</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Run exit; at stop sign turn left on Dorsey =
Run; at stop light turn right on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Guilford Road which becomes National =
Business Pkwy.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From Baltimore: Take BW Parkway (295) =
south; take MD Rt 32 west exit; stay</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;in right lane of the exit which runs into =
National Business Pkwy; make a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;right on National Business Pkwy.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;30 April 2001 - 1300</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;8 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;8 May 2001 - 1300</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;24 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;24 May 2001 - 1300</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;---------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;All showings last about half a day - with a =
mixture of conference room</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;briefings and laboratory =
demonstrations.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;We are limited by available demonstration =
space to an absolute maximum of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;20 participants at each showing.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;IMPORTANT:&nbsp; PLEASE REGISTER WITH LISA =
FAULKNER ([e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
&gt;) AND MYSELF</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;([e-mail] &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
&gt;) IF YOU PLAN TO</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;ATTEND.&nbsp; IF YOU DO NOT REGISTER TO =
ATTEND, YOU WILL NOT BE</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;ADMITTED TO THE DEMONSTRATION.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Please provide the following information to =
register:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Name</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Organization</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; E-mail address</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;--&nbsp; Date and time of the demonstration =
showing you wish to attend (with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;alternates, if possible)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;We look forward to seeing you at the =
demonstration!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Dave Fillingham</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;NSA</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; --------</FONT>
<BR><FONT SIZE=3D2>&gt; TTFN</FONT>
<BR><FONT SIZE=3D2>&gt; Roger W. Younglove, CISSP</FONT>
<BR><FONT SIZE=3D2>&gt; Distinguished Member of Consulting Staff</FONT>
<BR><FONT SIZE=3D2>&gt; Lucent Worldwide Services--Information =
Security</FONT>
<BR><FONT SIZE=3D2>&gt; 100 Galleria Officentre, Ste. 220</FONT>
<BR><FONT SIZE=3D2>&gt; Southfield, MI 48034-8428</FONT>
<BR><FONT SIZE=3D2>&gt; Numeric page: 888.935.6755</FONT>
<BR><FONT SIZE=3D2>&gt; E-mail page:</FONT>
<BR><FONT SIZE=3D2>&gt; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; eFax number: 413.425.5368</FONT>
<BR><FONT SIZE=3D2>&gt; www.lucent.com/netcare</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C1FA.855FB280--


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA24969 for <[e-mail]>; Tue, 10 Apr 2001 13:16:55 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <2VHDBTYD>; Tue, 10 Apr 2001 16:16:25 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Anders Rundgren <[e-mail]>, Santosh Chokhani <[e-mail]>, "Fillingham,  David W." <[e-mail]>, PKIX-List <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, [e-mail], "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, * ALL FIREBURST USERS * <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, [e-mail], [e-mail], "'Steve Hanna (SUN)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>, Roger Younglove <[e-mail]>
Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
Date: Tue, 10 Apr 2001 16:07:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1F9.ECD51960"

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_01C0C1F9.ECD51960
Content-Type: text/plain;
	charset="iso-8859-1"

Anders:

Having looked at the papers you sent, I think your solutions may be ok as a
B2B solution.

But, I see end to end security requiring PKI.  Even in our company's case
where we run independent labs, do PKI consulting and build PKI products,
some of our lab customers when they send us documents over the Internet,
they want only the lab personnel assigned to the project to read it.  They
do it using end-end encryption.  PKI concepts were designed for this
distributed, client centric model.

In my mind, depending on the business climate, one of the following offers
more advantages over the others and is hence appropriate:

Trust anchors list
Hierarchy
Bridge
Bilateral cross certification
Purple Model

ONE SHOE DOES NOT FIT ALL

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Tuesday, April 10, 2001 1:00 PM
To: Santosh Chokhani; Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD
PKI TWG'; [e-mail]; 'Bridge CA Mail List'; 'BCA Integration'; *
ALL FIREBURST USERS *; 'Steve Capps'; Wagner, Clark J.;
[e-mail]; [e-mail]; 'Steve Hanna
(SUN)'; 'Susan Dernik'; Roger Younglove
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations


Roger,

>IMHO, when you have multiple PKIs with in any industry such as the 
>Automotive (ie. ANX) or the Government, cross certification become a 
>problem because the certificate chain of trust becomes so unwieldy and 
>revocation of a PKI is also a problem. The Bridge scenario solves this 
>problem. It is not the only solution but the simplest with a number of 
>existing PKIs.

Agreed, Bridge CAs solves (some of) the problems created by
unwieldy PKIs such as those created by DoD.

Domain-PKI does not requires such solutions as it is much simpler
to create and maintain.  100 millions users of Internet use it today
when they address an https URL.  That's simplicity IMHO.
Applied to B2B it gets just slightly more complicated.

Anders

At 05:21 AM 04/10/2001 , Anders Rundgren wrote:
>Santosh,
>Domain (server-based) PKI offers persistent signatures for non-repudiation 
>at a fraction
>of the cost (and inconvenience) that inter-organization client-based 
>signatures introduce.
>The need for bridge-CAs using domain-PKI is IMO very limited as the number 
>of CAs is
>reduced by several orders of magnitude by such approaches. 5-10 CAs 
>worldwide is my guess.
>
>I do have read the paper by Bill Burr. Did you read about Purple? I.e. do 
>you see a problem with this model?
>
>BTW, I am a (currently only lurking due to high work-load) member of the 
>OASIS Security Services TC where
>domain-based solutions are standardized. I have never ever seen such an 
>enormous committee activity so domain
>security is indeed red-hot.
>
>Internet2 with their Shibboleth distributed multi-campus authentication 
>system will be based on domain-PKI.
>
>Personally I expect the next version of OBI (Open Buying on the Internet) 
>to be entirely based
>on this concept by throwing out the inter-organization client-certs (that 
>never worked, so just about
>everybody turned to user-ID/passwords in spite of not being a part of the 
>standard).
>
>VISA's coming 3D Secure credit-card payment system is also based on 
>domain-PKI.
>
>Due to this, I think that DoD (and similar organizations all over the 
>globe) should very carefully evaluate the
>domain security alternative before they do any new investments in CA
systems.
>
>Regards
>Anders
>----- Original Message -----
>From: Santosh Chokhani
>To: Anders Rundgren ; Fillingham, David W. ; PKIX-List ; 'KPCMWG' ; 'DoD 
>PKI TWG' ; [e-mail] ; 'Bridge CA Mail List' ; 'BCA
>Integration' ; * ALL FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. 
>; [e-mail] ;
>[e-mail] ; 'Steve Hanna (SUN)' ; 'Susan Dernik'
>Sent: Monday, April 09, 2001 22:39
>Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
>
>
>Anders:
>I think Bridge technology can be helpful to a vertical segment such as 
>banking, health care, automotive industry etc. in order to
>facilitate secure e-commerce among the trading partners where persistent 
>digital signature for non-repudiation may be required.
>Also, given how organizations manage their Web sites and we hear about Web 
>server break-in, persistent encryption (beyond SSL
>transport) may call for interoperable, inter-domain PKI.  Again Bridge CA 
>can help.
>Actually, I can see the benefits of layers (strata) of Bridge CAs, e.g., 
>Bridge CAs from various vertical segments themselves
>connecting to a Omni-Bridge.  In that case, the Bridge CAs will be 
>Principal CAs.
>I assume you have had a chance to review the excellent paper on the Bridge 
>concept developed by Bill Burr.
>-----Original Message-----
>From: Anders Rundgren [mailto:[e-mail]]
>Sent: Monday, April 09, 2001 2:08 PM
>To: Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD PKI TWG';
>[e-mail]; 'Bridge CA Mail List'; 'BCA Integration'; * ALL
>FIREBURST USERS *; 'Steve Capps'; Wagner, Clark J.;
>[e-mail]; [e-mail]; 'Steve Hanna
>(SUN)'; 'Susan Dernik'
>Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
>
>
>David,
>This is indeed an ambitious project. Unfortunately I doubt that the Bridge 
>model has any relevance in
>the private sector that for inter-organization communication, is more 
>likely to deploy domain-based
>PKI-solutions, that have the major advantage of already being supported by 
>global TTPs which makes
>domain security solutions useful for organizations of any size. I.e. 
>VeriSign's issuance of web-server
>certificates is "approximately" what is needed.
>That domain security is incompatible with most current digital signature 
>laws is a pity.  Particularly for
>the lawyers who created them.  :-)
>Using domain security, tracing, message archiving, and user-control is 
>essentially built-in.
>A further advantage of domain security models is that client security 
>solutions can develop in a
>different pace at each organization.  As they have for current 
>Internet-banks that is so far the only
>large-scale (almost) secure multi-organization transaction-environment on 
>the Internet.
>The question that comes to my mind is: Will all Governments in the world 
>continue to adopt the
>"All-speak-with-all-PKI" approach in spite of the fact that the private 
>sector probably have shunned it
>due to complexity, privacy concerns, lack of control, and cost?
>Regard
>Anders Rundgren
>X-OBI  read: http://www.x-obi.com/purple  run: http://buyer.x-obi.com
>
>
>
>----- Original Message -----
>From: Fillingham, David W.
>To: '[e-mail]' ; 'KPCMWG' ; 'DoD PKI TWG' ; '[e-mail]' ; 
>'Bridge CA Mail List' ; 'BCA Integration' ; * ALL
>FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. ; 
>'[e-mail]' ; '[e-mail]' ; 'Steve
Hanna
>(SUN)' ; 'Susan Dernik'
>Sent: Friday, April 06, 2001 16:48
>Subject: DoD Bridge Certification Authority Phase II Demonstrations
>
>
>For the last few years, the National Security Agency has led the 
>development of Bridge Certification Authority (BCA) technology
>demonstrations.  In 1999, Phase One of the Department of Defense BCA 
>Technology Demonstration showed the technical feasibility of
>achieving signed e-mail interoperability using multi-vendor 
>cross-certification in conjunction with chained directory systems.
>
>Phase Two of the demonstration is now ready to be shown.  Phase Two of the 
>DoD Bridge CA Phase II Technology Demonstration includes:
>
>Technologies:
>
>--  Certificate chain building in complex certificate graphs;
>--  Integration of both mesh-style cross-certified PKIs and hierarchical
PKIs;
>--  Multi-signature/hash algorithm processing in certificate chains;
>--  Certificate acceptance/rejection based on Certificate Policy 
>processing, including policy mapping;
>--  Transitive trust limitation using Name Constraints processing;
>--  Access Control using X.509 compliant attribute certificates (same 
>attribute certificates used for e-mail and web based access
>control);
>--  E-mail access control using S/MIME V3 labeling;
>--  E-mail encryption using public key certificates authenticated via a 
>Bridge Certification Authority;
>--  Border Directories;
>--  Multivendor directory interoperation via X.500 chaining; and,
>--  Transparent sharing of certificate revocation information across 
>several  PKIs using products of multiple PKI vendors.
>
>Client Applications:
>
>--  Baltimore Technologies MailSecure enabled Microsoft Outlook
>--  Entrust Enabled Microsoft Outlook
>--  Getronics S/MIME Freeware Library, Certificate Management Library, and 
>Access Control Library enabled Qualcomm Eudora
>--  Getronics Certificate Management Library and Access Control Library 
>enabled Netscape Web Server
>
>Freeware Libraries:
>
>--  Cygnacom Certificate Path Development Library
>      <http://www.cygnacom.com/products/index.htm>
>--  Getronics S/MIME (Version 3) Freeware Library
>      <http://www.getronicsgov.com/hot/sfl_home.htm>
>--  Getronics Certificate Management Library
>      <http://www.getronicsgov.com/hot/cml_home.htm>
>-- Getronics Access Control Library
>           <http://www.getronicsgov.com/hot/acl_home.htm>
>CA vendor interoperability demonstrations:
>
>--  Baltimore Technologies
>--  Entrust Technologies
>--  Motorola
>--  SPYRUS
>
>Directory Interoperability:
>--  Entrust ICL
>--  Entegrity Safepages Directory
>Demonstrations will be held at the following locations and dates (note 
>that you MUST REGISTER to attend!  Registration information
>is provided below):
>
>----------
>CygnaCom
>Suite 100 West
>7927 Jones Branch Dr.
>McLean, Virginia
>
>Directions to CygnaCom are located 
>at:  <http://www.cygnacom.com/contact/directions.htm>
>
>26 April 2001 - 0900
>
>26 April 2001 - 1300
>
>16 May 2001 - 0900
>
>16 May 2001 - 1300
>
>---------
>Getronics Government Solutions
>141 National Business Parkway, Suite 210
>Annapolis Junction, Maryland
>
> From Washington DC: Take I-95 north; take MD Rt 32 east exit; take Dorsey
>Run exit; at stop sign turn left on Dorsey Run; at stop light turn right on
>Guilford Road which becomes National Business Pkwy.
>
> From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit; stay
>in right lane of the exit which runs into National Business Pkwy; make a
>right on National Business Pkwy.
>
>30 April 2001 - 1300
>
>8 May 2001 - 0900
>
>8 May 2001 - 1300
>
>24 May 2001 - 0900
>
>24 May 2001 - 1300
>
>---------
>
>All showings last about half a day - with a mixture of conference room 
>briefings and laboratory demonstrations.
>
>We are limited by available demonstration space to an absolute maximum of 
>20 participants at each showing.
>
>IMPORTANT:  PLEASE REGISTER WITH LISA FAULKNER ([e-mail] 
><mailto:[e-mail]>) AND MYSELF
>([e-mail] <mailto:[e-mail]>) IF YOU PLAN TO 
>ATTEND.  IF YOU DO NOT REGISTER TO ATTEND, YOU WILL NOT BE
>ADMITTED TO THE DEMONSTRATION.
>
>Please provide the following information to register:
>
>--  Name
>--  Organization
>--  E-mail address
>--  Date and time of the demonstration showing you wish to attend (with 
>alternates, if possible)
>
>We look forward to seeing you at the demonstration!
>
>Dave Fillingham
>NSA

--------
TTFN
Roger W. Younglove, CISSP
Distinguished Member of Consulting Staff
Lucent Worldwide Services--Information Security
100 Galleria Officentre, Ste. 220
Southfield, MI 48034-8428
Numeric page: 888.935.6755
E-mail page:
[e-mail]
eFax number: 413.425.5368
www.lucent.com/netcare


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: DoD Bridge Certification Authority Phase II =
Demonstrations</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>Having looked at the papers you sent, I think your =
solutions may be ok as a B2B solution.</FONT>
</P>

<P><FONT SIZE=3D2>But, I see end to end security requiring PKI.&nbsp; =
Even in our company's case where we run independent labs, do PKI =
consulting and build PKI products, some of our lab customers when they =
send us documents over the Internet, they want only the lab personnel =
assigned to the project to read it.&nbsp; They do it using end-end =
encryption.&nbsp; PKI concepts were designed for this distributed, =
client centric model.</FONT></P>

<P><FONT SIZE=3D2>In my mind, depending on the business climate, one of =
the following offers more advantages over the others and is hence =
appropriate:</FONT></P>

<P><FONT SIZE=3D2>Trust anchors list</FONT>
<BR><FONT SIZE=3D2>Hierarchy</FONT>
<BR><FONT SIZE=3D2>Bridge</FONT>
<BR><FONT SIZE=3D2>Bilateral cross certification</FONT>
<BR><FONT SIZE=3D2>Purple Model</FONT>
</P>

<P><FONT SIZE=3D2>ONE SHOE DOES NOT FIT ALL</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 10, 2001 1:00 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani; Fillingham, David W.; =
PKIX-List; 'KPCMWG'; 'DoD</FONT>
<BR><FONT SIZE=3D2>PKI TWG'; [e-mail]; 'Bridge CA Mail List'; =
'BCA Integration'; *</FONT>
<BR><FONT SIZE=3D2>ALL FIREBURST USERS *; 'Steve Capps'; Wagner, Clark =
J.;</FONT>
<BR><FONT SIZE=3D2>[e-mail]; =
[e-mail]; 'Steve Hanna</FONT>
<BR><FONT SIZE=3D2>(SUN)'; 'Susan Dernik'; Roger Younglove</FONT>
<BR><FONT SIZE=3D2>Subject: Re: DoD Bridge Certification Authority =
Phase II Demonstrations</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>&gt;IMHO, when you have multiple PKIs with in any =
industry such as the </FONT>
<BR><FONT SIZE=3D2>&gt;Automotive (ie. ANX) or the Government, cross =
certification become a </FONT>
<BR><FONT SIZE=3D2>&gt;problem because the certificate chain of trust =
becomes so unwieldy and </FONT>
<BR><FONT SIZE=3D2>&gt;revocation of a PKI is also a problem. The =
Bridge scenario solves this </FONT>
<BR><FONT SIZE=3D2>&gt;problem. It is not the only solution but the =
simplest with a number of </FONT>
<BR><FONT SIZE=3D2>&gt;existing PKIs.</FONT>
</P>

<P><FONT SIZE=3D2>Agreed, Bridge CAs solves (some of) the problems =
created by</FONT>
<BR><FONT SIZE=3D2>unwieldy PKIs such as those created by DoD.</FONT>
</P>

<P><FONT SIZE=3D2>Domain-PKI does not requires such solutions as it is =
much simpler</FONT>
<BR><FONT SIZE=3D2>to create and maintain.&nbsp; 100 millions users of =
Internet use it today</FONT>
<BR><FONT SIZE=3D2>when they address an https URL.&nbsp; That's =
simplicity IMHO.</FONT>
<BR><FONT SIZE=3D2>Applied to B2B it gets just slightly more =
complicated.</FONT>
</P>

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

<P><FONT SIZE=3D2>At 05:21 AM 04/10/2001 , Anders Rundgren =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Santosh,</FONT>
<BR><FONT SIZE=3D2>&gt;Domain (server-based) PKI offers persistent =
signatures for non-repudiation </FONT>
<BR><FONT SIZE=3D2>&gt;at a fraction</FONT>
<BR><FONT SIZE=3D2>&gt;of the cost (and inconvenience) that =
inter-organization client-based </FONT>
<BR><FONT SIZE=3D2>&gt;signatures introduce.</FONT>
<BR><FONT SIZE=3D2>&gt;The need for bridge-CAs using domain-PKI is IMO =
very limited as the number </FONT>
<BR><FONT SIZE=3D2>&gt;of CAs is</FONT>
<BR><FONT SIZE=3D2>&gt;reduced by several orders of magnitude by such =
approaches. 5-10 CAs </FONT>
<BR><FONT SIZE=3D2>&gt;worldwide is my guess.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I do have read the paper by Bill Burr. Did you =
read about Purple? I.e. do </FONT>
<BR><FONT SIZE=3D2>&gt;you see a problem with this model?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;BTW, I am a (currently only lurking due to high =
work-load) member of the </FONT>
<BR><FONT SIZE=3D2>&gt;OASIS Security Services TC where</FONT>
<BR><FONT SIZE=3D2>&gt;domain-based solutions are standardized. I have =
never ever seen such an </FONT>
<BR><FONT SIZE=3D2>&gt;enormous committee activity so domain</FONT>
<BR><FONT SIZE=3D2>&gt;security is indeed red-hot.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Internet2 with their Shibboleth distributed =
multi-campus authentication </FONT>
<BR><FONT SIZE=3D2>&gt;system will be based on domain-PKI.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Personally I expect the next version of OBI =
(Open Buying on the Internet) </FONT>
<BR><FONT SIZE=3D2>&gt;to be entirely based</FONT>
<BR><FONT SIZE=3D2>&gt;on this concept by throwing out the =
inter-organization client-certs (that </FONT>
<BR><FONT SIZE=3D2>&gt;never worked, so just about</FONT>
<BR><FONT SIZE=3D2>&gt;everybody turned to user-ID/passwords in spite =
of not being a part of the </FONT>
<BR><FONT SIZE=3D2>&gt;standard).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;VISA's coming 3D Secure credit-card payment =
system is also based on </FONT>
<BR><FONT SIZE=3D2>&gt;domain-PKI.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Due to this, I think that DoD (and similar =
organizations all over the </FONT>
<BR><FONT SIZE=3D2>&gt;globe) should very carefully evaluate the</FONT>
<BR><FONT SIZE=3D2>&gt;domain security alternative before they do any =
new investments in CA systems.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Regards</FONT>
<BR><FONT SIZE=3D2>&gt;Anders</FONT>
<BR><FONT SIZE=3D2>&gt;----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt;To: Anders Rundgren ; Fillingham, David W. ; =
PKIX-List ; 'KPCMWG' ; 'DoD </FONT>
<BR><FONT SIZE=3D2>&gt;PKI TWG' ; [e-mail] ; 'Bridge CA Mail =
List' ; 'BCA</FONT>
<BR><FONT SIZE=3D2>&gt;Integration' ; * ALL FIREBURST USERS * ; 'Steve =
Capps' ; Wagner, Clark J. </FONT>
<BR><FONT SIZE=3D2>&gt;; [e-mail] ;</FONT>
<BR><FONT SIZE=3D2>&gt;[e-mail] ; 'Steve Hanna =
(SUN)' ; 'Susan Dernik'</FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Monday, April 09, 2001 22:39</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE: DoD Bridge Certification Authority =
Phase II Demonstrations</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Anders:</FONT>
<BR><FONT SIZE=3D2>&gt;I think Bridge technology can be helpful to a =
vertical segment such as </FONT>
<BR><FONT SIZE=3D2>&gt;banking, health care, automotive industry etc. =
in order to</FONT>
<BR><FONT SIZE=3D2>&gt;facilitate secure e-commerce among the trading =
partners where persistent </FONT>
<BR><FONT SIZE=3D2>&gt;digital signature for non-repudiation may be =
required.</FONT>
<BR><FONT SIZE=3D2>&gt;Also, given how organizations manage their Web =
sites and we hear about Web </FONT>
<BR><FONT SIZE=3D2>&gt;server break-in, persistent encryption (beyond =
SSL</FONT>
<BR><FONT SIZE=3D2>&gt;transport) may call for interoperable, =
inter-domain PKI.&nbsp; Again Bridge CA </FONT>
<BR><FONT SIZE=3D2>&gt;can help.</FONT>
<BR><FONT SIZE=3D2>&gt;Actually, I can see the benefits of layers =
(strata) of Bridge CAs, e.g., </FONT>
<BR><FONT SIZE=3D2>&gt;Bridge CAs from various vertical segments =
themselves</FONT>
<BR><FONT SIZE=3D2>&gt;connecting to a Omni-Bridge.&nbsp; In that case, =
the Bridge CAs will be </FONT>
<BR><FONT SIZE=3D2>&gt;Principal CAs.</FONT>
<BR><FONT SIZE=3D2>&gt;I assume you have had a chance to review the =
excellent paper on the Bridge </FONT>
<BR><FONT SIZE=3D2>&gt;concept developed by Bill Burr.</FONT>
<BR><FONT SIZE=3D2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Monday, April 09, 2001 2:08 PM</FONT>
<BR><FONT SIZE=3D2>&gt;To: Fillingham, David W.; PKIX-List; 'KPCMWG'; =
'DoD PKI TWG';</FONT>
<BR><FONT SIZE=3D2>&gt;[e-mail]; 'Bridge CA Mail List'; 'BCA =
Integration'; * ALL</FONT>
<BR><FONT SIZE=3D2>&gt;FIREBURST USERS *; 'Steve Capps'; Wagner, Clark =
J.;</FONT>
<BR><FONT SIZE=3D2>&gt;[e-mail]; =
[e-mail]; 'Steve Hanna</FONT>
<BR><FONT SIZE=3D2>&gt;(SUN)'; 'Susan Dernik'</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: Re: DoD Bridge Certification Authority =
Phase II Demonstrations</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;David,</FONT>
<BR><FONT SIZE=3D2>&gt;This is indeed an ambitious project. =
Unfortunately I doubt that the Bridge </FONT>
<BR><FONT SIZE=3D2>&gt;model has any relevance in</FONT>
<BR><FONT SIZE=3D2>&gt;the private sector that for inter-organization =
communication, is more </FONT>
<BR><FONT SIZE=3D2>&gt;likely to deploy domain-based</FONT>
<BR><FONT SIZE=3D2>&gt;PKI-solutions, that have the major advantage of =
already being supported by </FONT>
<BR><FONT SIZE=3D2>&gt;global TTPs which makes</FONT>
<BR><FONT SIZE=3D2>&gt;domain security solutions useful for =
organizations of any size. I.e. </FONT>
<BR><FONT SIZE=3D2>&gt;VeriSign's issuance of web-server</FONT>
<BR><FONT SIZE=3D2>&gt;certificates is &quot;approximately&quot; what =
is needed.</FONT>
<BR><FONT SIZE=3D2>&gt;That domain security is incompatible with most =
current digital signature </FONT>
<BR><FONT SIZE=3D2>&gt;laws is a pity.&nbsp; Particularly for</FONT>
<BR><FONT SIZE=3D2>&gt;the lawyers who created them.&nbsp; :-)</FONT>
<BR><FONT SIZE=3D2>&gt;Using domain security, tracing, message =
archiving, and user-control is </FONT>
<BR><FONT SIZE=3D2>&gt;essentially built-in.</FONT>
<BR><FONT SIZE=3D2>&gt;A further advantage of domain security models is =
that client security </FONT>
<BR><FONT SIZE=3D2>&gt;solutions can develop in a</FONT>
<BR><FONT SIZE=3D2>&gt;different pace at each organization.&nbsp; As =
they have for current </FONT>
<BR><FONT SIZE=3D2>&gt;Internet-banks that is so far the only</FONT>
<BR><FONT SIZE=3D2>&gt;large-scale (almost) secure multi-organization =
transaction-environment on </FONT>
<BR><FONT SIZE=3D2>&gt;the Internet.</FONT>
<BR><FONT SIZE=3D2>&gt;The question that comes to my mind is: Will all =
Governments in the world </FONT>
<BR><FONT SIZE=3D2>&gt;continue to adopt the</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;All-speak-with-all-PKI&quot; approach in =
spite of the fact that the private </FONT>
<BR><FONT SIZE=3D2>&gt;sector probably have shunned it</FONT>
<BR><FONT SIZE=3D2>&gt;due to complexity, privacy concerns, lack of =
control, and cost?</FONT>
<BR><FONT SIZE=3D2>&gt;Regard</FONT>
<BR><FONT SIZE=3D2>&gt;Anders Rundgren</FONT>
<BR><FONT SIZE=3D2>&gt;X-OBI&nbsp; read: <A =
HREF=3D"http://www.x-obi.com/purple" =
TARGET=3D"_blank">http://www.x-obi.com/purple</A>&nbsp; run: <A =
HREF=3D"http://buyer.x-obi.com" =
TARGET=3D"_blank">http://buyer.x-obi.com</A></FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Fillingham, David W.</FONT>
<BR><FONT SIZE=3D2>&gt;To: '[e-mail]' ; 'KPCMWG' ; 'DoD PKI =
TWG' ; '[e-mail]' ; </FONT>
<BR><FONT SIZE=3D2>&gt;'Bridge CA Mail List' ; 'BCA Integration' ; * =
ALL</FONT>
<BR><FONT SIZE=3D2>&gt;FIREBURST USERS * ; 'Steve Capps' ; Wagner, =
Clark J. ; </FONT>
<BR><FONT SIZE=3D2>&gt;'[e-mail]' ; =
'[e-mail]' ; 'Steve Hanna</FONT>
<BR><FONT SIZE=3D2>&gt;(SUN)' ; 'Susan Dernik'</FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Friday, April 06, 2001 16:48</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: DoD Bridge Certification Authority =
Phase II Demonstrations</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;For the last few years, the National Security =
Agency has led the </FONT>
<BR><FONT SIZE=3D2>&gt;development of Bridge Certification Authority =
(BCA) technology</FONT>
<BR><FONT SIZE=3D2>&gt;demonstrations.&nbsp; In 1999, Phase One of the =
Department of Defense BCA </FONT>
<BR><FONT SIZE=3D2>&gt;Technology Demonstration showed the technical =
feasibility of</FONT>
<BR><FONT SIZE=3D2>&gt;achieving signed e-mail interoperability using =
multi-vendor </FONT>
<BR><FONT SIZE=3D2>&gt;cross-certification in conjunction with chained =
directory systems.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Phase Two of the demonstration is now ready to =
be shown.&nbsp; Phase Two of the </FONT>
<BR><FONT SIZE=3D2>&gt;DoD Bridge CA Phase II Technology Demonstration =
includes:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Technologies:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Certificate chain building in complex =
certificate graphs;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Integration of both mesh-style =
cross-certified PKIs and hierarchical PKIs;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Multi-signature/hash algorithm =
processing in certificate chains;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Certificate acceptance/rejection based =
on Certificate Policy </FONT>
<BR><FONT SIZE=3D2>&gt;processing, including policy mapping;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Transitive trust limitation using Name =
Constraints processing;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Access Control using X.509 compliant =
attribute certificates (same </FONT>
<BR><FONT SIZE=3D2>&gt;attribute certificates used for e-mail and web =
based access</FONT>
<BR><FONT SIZE=3D2>&gt;control);</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; E-mail access control using S/MIME V3 =
labeling;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; E-mail encryption using public key =
certificates authenticated via a </FONT>
<BR><FONT SIZE=3D2>&gt;Bridge Certification Authority;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Border Directories;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Multivendor directory interoperation =
via X.500 chaining; and,</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Transparent sharing of certificate =
revocation information across </FONT>
<BR><FONT SIZE=3D2>&gt;several&nbsp; PKIs using products of multiple =
PKI vendors.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Client Applications:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Baltimore Technologies MailSecure =
enabled Microsoft Outlook</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Entrust Enabled Microsoft =
Outlook</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Getronics S/MIME Freeware Library, =
Certificate Management Library, and </FONT>
<BR><FONT SIZE=3D2>&gt;Access Control Library enabled Qualcomm =
Eudora</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Getronics Certificate Management =
Library and Access Control Library </FONT>
<BR><FONT SIZE=3D2>&gt;enabled Netscape Web Server</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Freeware Libraries:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Cygnacom Certificate Path Development =
Library</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.cygnacom.com/products/index.htm" =
TARGET=3D"_blank">http://www.cygnacom.com/products/index.htm</A>&gt;</FO=
NT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Getronics S/MIME (Version 3) Freeware =
Library</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/sfl_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/sfl_home.htm</A>&gt;</=
FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Getronics Certificate Management =
Library</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/cml_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/cml_home.htm</A>&gt;</=
FONT>
<BR><FONT SIZE=3D2>&gt;-- Getronics Access Control Library</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &lt;<A HREF=3D"http://www.getronicsgov.com/hot/acl_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/acl_home.htm</A>&gt;</=
FONT>
<BR><FONT SIZE=3D2>&gt;CA vendor interoperability =
demonstrations:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Baltimore Technologies</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Entrust Technologies</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Motorola</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; SPYRUS</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Directory Interoperability:</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Entrust ICL</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Entegrity Safepages Directory</FONT>
<BR><FONT SIZE=3D2>&gt;Demonstrations will be held at the following =
locations and dates (note </FONT>
<BR><FONT SIZE=3D2>&gt;that you MUST REGISTER to attend!&nbsp; =
Registration information</FONT>
<BR><FONT SIZE=3D2>&gt;is provided below):</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;----------</FONT>
<BR><FONT SIZE=3D2>&gt;CygnaCom</FONT>
<BR><FONT SIZE=3D2>&gt;Suite 100 West</FONT>
<BR><FONT SIZE=3D2>&gt;7927 Jones Branch Dr.</FONT>
<BR><FONT SIZE=3D2>&gt;McLean, Virginia</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Directions to CygnaCom are located </FONT>
<BR><FONT SIZE=3D2>&gt;at:&nbsp; &lt;<A =
HREF=3D"http://www.cygnacom.com/contact/directions.htm" =
TARGET=3D"_blank">http://www.cygnacom.com/contact/directions.htm</A>&gt;=
</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;26 April 2001 - 0900</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;26 April 2001 - 1300</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;16 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;16 May 2001 - 1300</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;---------</FONT>
<BR><FONT SIZE=3D2>&gt;Getronics Government Solutions</FONT>
<BR><FONT SIZE=3D2>&gt;141 National Business Parkway, Suite 210</FONT>
<BR><FONT SIZE=3D2>&gt;Annapolis Junction, Maryland</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; From Washington DC: Take I-95 north; take MD Rt =
32 east exit; take Dorsey</FONT>
<BR><FONT SIZE=3D2>&gt;Run exit; at stop sign turn left on Dorsey Run; =
at stop light turn right on</FONT>
<BR><FONT SIZE=3D2>&gt;Guilford Road which becomes National Business =
Pkwy.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; From Baltimore: Take BW Parkway (295) south; =
take MD Rt 32 west exit; stay</FONT>
<BR><FONT SIZE=3D2>&gt;in right lane of the exit which runs into =
National Business Pkwy; make a</FONT>
<BR><FONT SIZE=3D2>&gt;right on National Business Pkwy.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;30 April 2001 - 1300</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;8 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;8 May 2001 - 1300</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;24 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;24 May 2001 - 1300</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;---------</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;All showings last about half a day - with a =
mixture of conference room </FONT>
<BR><FONT SIZE=3D2>&gt;briefings and laboratory demonstrations.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;We are limited by available demonstration space =
to an absolute maximum of </FONT>
<BR><FONT SIZE=3D2>&gt;20 participants at each showing.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;IMPORTANT:&nbsp; PLEASE REGISTER WITH LISA =
FAULKNER ([e-mail] </FONT>
<BR><FONT SIZE=3D2>&gt;&lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
&gt;) AND MYSELF</FONT>
<BR><FONT SIZE=3D2>&gt;([e-mail] &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
&gt;) IF YOU PLAN TO </FONT>
<BR><FONT SIZE=3D2>&gt;ATTEND.&nbsp; IF YOU DO NOT REGISTER TO ATTEND, =
YOU WILL NOT BE</FONT>
<BR><FONT SIZE=3D2>&gt;ADMITTED TO THE DEMONSTRATION.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Please provide the following information to =
register:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Name</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Organization</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; E-mail address</FONT>
<BR><FONT SIZE=3D2>&gt;--&nbsp; Date and time of the demonstration =
showing you wish to attend (with </FONT>
<BR><FONT SIZE=3D2>&gt;alternates, if possible)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;We look forward to seeing you at the =
demonstration!</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Dave Fillingham</FONT>
<BR><FONT SIZE=3D2>&gt;NSA</FONT>
</P>

<P><FONT SIZE=3D2>--------</FONT>
<BR><FONT SIZE=3D2>TTFN</FONT>
<BR><FONT SIZE=3D2>Roger W. Younglove, CISSP</FONT>
<BR><FONT SIZE=3D2>Distinguished Member of Consulting Staff</FONT>
<BR><FONT SIZE=3D2>Lucent Worldwide Services--Information =
Security</FONT>
<BR><FONT SIZE=3D2>100 Galleria Officentre, Ste. 220</FONT>
<BR><FONT SIZE=3D2>Southfield, MI 48034-8428</FONT>
<BR><FONT SIZE=3D2>Numeric page: 888.935.6755</FONT>
<BR><FONT SIZE=3D2>E-mail page:</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>eFax number: 413.425.5368</FONT>
<BR><FONT SIZE=3D2>www.lucent.com/netcare</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C1F9.ECD51960--


Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA21506 for <[e-mail]>; Tue, 10 Apr 2001 12:39:04 -0700 (PDT)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maila.telia.com (8.9.3/8.9.3) with ESMTP id VAA19316; Tue, 10 Apr 2001 21:39:05 +0200 (CEST)
Received: from mega (t4o69p113.telia.com [62.20.145.233]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f3AJd3a06045; Tue, 10 Apr 2001 21:39:04 +0200 (CEST)
Message-ID: <012201c0c1f5$9f92cc00$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Frank Lawrence" <[e-mail]>
Cc: "PKIX-List" <[e-mail]>
References: <[e-mail]> <[e-mail]> <014d01c0c1df$aebe0390$0500a8c0@arport> <[e-mail]>
Subject: Domain-PKI. Was: DoD Bridge Certification Authority Phase II Demonstrations
Date: Tue, 10 Apr 2001 21:37:04 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id MAA21509

Frank,

> I will take a shot of the problem with the purple model.

Thanx for taking on the challenge!

Even the Sun has its flaws.  But that does not make domain-PKI useless.

Domain PKI references:

Purple (X-OBI's domain-PKI authentication system):
Read: http://www.x-obi.com/purple 
Run: http://buyer.x-obi.com 

Why client-certificates have no [direct] use in B2B:
   http://www.mobilephones-tng.com/papers/obi-2.1-sec.doc

S/MIME for domains:
  http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-08.txt

OAISIS Security Services:
  http://www.oasis-open.org/committees/security/

VISA's 3D SET (that though will be replaced by 3D Secure which so far I cannot disclose info about):
  http://www.visa.com/pd/eu_shop/merchants/3d_set/main.html#threedomain

Early mobile phone concept based on domain-PKI and client-PKI in a "combo"
  http://www.mobilephones-tng.com

Internet2's Shibboleth inter-campus web-authentication system:
  http://middleware.internet2.edu/shibboleth/


> The problem that I see with the Purple model is that there is a requirement for
> explicit trust between the "partners".  Known partners are nice but does not solve
> the broader problem of extending trust.

Now you hit a weak point in PKI in general.  What do we mean by trust?  That the
entity is the one they are claiming to be?  I do not belie (PKI is a religion?)
that it is enough that you have a certificate from a trusted CA.  Because if you want
to conduct business you may actually be more interested in knowing that a buyer
is capable of paying or that the supplier delivers.  Such information can sometimes be
obtained from TTP's specializing in such data (e.g. D & B).  By identifying the entity
with their organization certificate you have the "perfect handle" for perfoming such
queries.   And how much trust you have in an unkown organization is up to every
partner to decide.  I.e. a CA <> God!

> Works fine as long as the number of partners is small, but is combinatorially
> explosive as the number of partners becomes large.

No, domain-PKI follows a linear scale as partners are autonomous.  I.e. domain-PKI
is simply a way for an organization to sign messages using a digital version of their
company paper.  But unlike the paper-version, the digital version is usually issued by
a TTP and is extremely hard to forge.

>  The ability to manage that
> large number of trust relationships becomes just as difficult as the bridge CA
> problem.  The "unwieldy" PKI created by DoD elminates that problem, at least within
> DoD where there are hundreds (maybe thousands?) of "partner" domains.  At least
> within DoD there is an understanding of the level of trust involved in getting a
> certificate.

Many companies have more than 10000 suppliers, domain-PKI adds little
to the complexity (in principal at least).  And it definitely beats current 
"state-of-the-art-solutions" using user-ID passwords on partner sites.

> The current HTTPS model is a bad example of trust because there is no (valid)
> presumption of trust between a web server and a client.  SSL encrypts the pipe but
> there is no method for determining if the client or the server is who they claim to
> be.  Trivial to spoof either (or both) although the pipe is secure from
> observation.  Even IPSEC based authentication (a step above the SSL model) does not
> provide any assurance that the claimed user is who they say they are.  Unless there
> is a trust model that extends across the network, in a scalable manner, then the
> relying party is left holding the bag.

Client-PKI does not make you safe from impersonators, or does it?
 
> Finally, to trust a domain, you must understand how that domain issues
> certificates.  If there is no policy which tells a relying party what the level of
> assurance is involved in the creation of the certificate, then the level of trust
> you place in that certificate is zero.

If you refer to the Purple tickets they are no different than purchase orders (which 
BTW is sort of a certificate).  If you trust the purchase orders you ought to be able to
trust tickets as they are created about the same way by the very same system
run by the very same organization and staff.

But the motives for domain-PKI have so many more elements that I could go on
the whole night to describe them all but I think it is better to go through the
references instead of just repeating myself.

====================================================
With the exception of end-to-end authentication, domain-PKI IMO seems to
beat client-based PKIs for B2B by a mile.  Regarding end-to-end authentication
of Purple tickets (and Shibboleth and SAML dittos),  I have BTW a few suggestions
that I would like to discuss with interested parties.  It looks like this indeed can be
solved in a very convenient way (no local client configuration) but it requires an upgraded
browser.
====================================================

Anders



Received: from mclean5-mail.usae.bah.com (mclean5-mail.usae.bah.com [156.80.5.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA13153 for <[e-mail]>; Tue, 10 Apr 2001 10:40:31 -0700 (PDT)
Received: from bah.com ([134.205.161.104]) by mclean5-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id GBL7RK00.JPS; Tue, 10 Apr 2001 13:40:32 -0400 
Message-ID: <[e-mail]>
Date: Tue, 10 Apr 2001 13:40:33 -0400
From: "Frank Lawrence" <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Santosh Chokhani <[e-mail]>, "Fillingham David W." <[e-mail]>, PKIX-List <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, [e-mail], "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, * ALL FIREBURST USERS * <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner Clark J." <[e-mail]>, [e-mail], [e-mail], "'Steve Hanna (SUN)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>, Roger Younglove <[e-mail]>
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
References: <[e-mail]> <[e-mail]> <014d01c0c1df$aebe0390$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I will take a shot of the problem with the purple model.

The problem that I see with the Purple model is that there is a requirement for
explicit trust between the "partners".  Known partners are nice but does not solve
the broader problem of extending trust.

Works fine as long as the number of partners is small, but is combinatorially
explosive as the number of partners becomes large.   The ability to manage that
large number of trust relationships becomes just as difficult as the bridge CA
problem.  The "unwieldy" PKI created by DoD elminates that problem, at least within
DoD where there are hundreds (maybe thousands?) of "partner" domains.  At least
within DoD there is an understanding of the level of trust involved in getting a
certificate.

The current HTTPS model is a bad example of trust because there is no (valid)
presumption of trust between a web server and a client.  SSL encrypts the pipe but
there is no method for determining if the client or the server is who they claim to
be.  Trivial to spoof either (or both) although the pipe is secure from
observation.  Even IPSEC based authentication (a step above the SSL model) does not
provide any assurance that the claimed user is who they say they are.  Unless there
is a trust model that extends across the network, in a scalable manner, then the
relying party is left holding the bag.

Finally, to trust a domain, you must understand how that domain issues
certificates.  If there is no policy which tells a relying party what the level of
assurance is involved in the creation of the certificate, then the level of trust
you place in that certificate is zero.

Anders Rundgren wrote:

> Roger,
>
> >IMHO, when you have multiple PKIs with in any industry such as the
> >Automotive (ie. ANX) or the Government, cross certification become a
> >problem because the certificate chain of trust becomes so unwieldy and
> >revocation of a PKI is also a problem. The Bridge scenario solves this
> >problem. It is not the only solution but the simplest with a number of
> >existing PKIs.
>
> Agreed, Bridge CAs solves (some of) the problems created by
> unwieldy PKIs such as those created by DoD.
>
> Domain-PKI does not requires such solutions as it is much simpler
> to create and maintain.  100 millions users of Internet use it today
> when they address an https URL.  That's simplicity IMHO.
> Applied to B2B it gets just slightly more complicated.
>
> Anders
>
> At 05:21 AM 04/10/2001 , Anders Rundgren wrote:
> >Santosh,
> >Domain (server-based) PKI offers persistent signatures for non-repudiation
> >at a fraction
> >of the cost (and inconvenience) that inter-organization client-based
> >signatures introduce.
> >The need for bridge-CAs using domain-PKI is IMO very limited as the number
> >of CAs is
> >reduced by several orders of magnitude by such approaches. 5-10 CAs
> >worldwide is my guess.
> >
> >I do have read the paper by Bill Burr. Did you read about Purple? I.e. do
> >you see a problem with this model?
> >
> >BTW, I am a (currently only lurking due to high work-load) member of the
> >OASIS Security Services TC where
> >domain-based solutions are standardized. I have never ever seen such an
> >enormous committee activity so domain
> >security is indeed red-hot.
> >
> >Internet2 with their Shibboleth distributed multi-campus authentication
> >system will be based on domain-PKI.
> >
> >Personally I expect the next version of OBI (Open Buying on the Internet)
> >to be entirely based
> >on this concept by throwing out the inter-organization client-certs (that
> >never worked, so just about
> >everybody turned to user-ID/passwords in spite of not being a part of the
> >standard).
> >
> >VISA's coming 3D Secure credit-card payment system is also based on
> >domain-PKI.
> >
> >Due to this, I think that DoD (and similar organizations all over the
> >globe) should very carefully evaluate the
> >domain security alternative before they do any new investments in CA systems.
> >
> >Regards
> >Anders
> >----- Original Message -----
> >From: Santosh Chokhani
> >To: Anders Rundgren ; Fillingham, David W. ; PKIX-List ; 'KPCMWG' ; 'DoD
> >PKI TWG' ; [e-mail] ; 'Bridge CA Mail List' ; 'BCA
> >Integration' ; * ALL FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J.
> >; [e-mail] ;
> >[e-mail] ; 'Steve Hanna (SUN)' ; 'Susan Dernik'
> >Sent: Monday, April 09, 2001 22:39
> >Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
> >
> >
> >Anders:
> >I think Bridge technology can be helpful to a vertical segment such as
> >banking, health care, automotive industry etc. in order to
> >facilitate secure e-commerce among the trading partners where persistent
> >digital signature for non-repudiation may be required.
> >Also, given how organizations manage their Web sites and we hear about Web
> >server break-in, persistent encryption (beyond SSL
> >transport) may call for interoperable, inter-domain PKI.  Again Bridge CA
> >can help.
> >Actually, I can see the benefits of layers (strata) of Bridge CAs, e.g.,
> >Bridge CAs from various vertical segments themselves
> >connecting to a Omni-Bridge.  In that case, the Bridge CAs will be
> >Principal CAs.
> >I assume you have had a chance to review the excellent paper on the Bridge
> >concept developed by Bill Burr.
> >-----Original Message-----
> >From: Anders Rundgren [mailto:[e-mail]]
> >Sent: Monday, April 09, 2001 2:08 PM
> >To: Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD PKI TWG';
> >[e-mail]; 'Bridge CA Mail List'; 'BCA Integration'; * ALL
> >FIREBURST USERS *; 'Steve Capps'; Wagner, Clark J.;
> >[e-mail]; [e-mail]; 'Steve Hanna
> >(SUN)'; 'Susan Dernik'
> >Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
> >
> >
> >David,
> >This is indeed an ambitious project. Unfortunately I doubt that the Bridge
> >model has any relevance in
> >the private sector that for inter-organization communication, is more
> >likely to deploy domain-based
> >PKI-solutions, that have the major advantage of already being supported by
> >global TTPs which makes
> >domain security solutions useful for organizations of any size. I.e.
> >VeriSign's issuance of web-server
> >certificates is "approximately" what is needed.
> >That domain security is incompatible with most current digital signature
> >laws is a pity.  Particularly for
> >the lawyers who created them.  :-)
> >Using domain security, tracing, message archiving, and user-control is
> >essentially built-in.
> >A further advantage of domain security models is that client security
> >solutions can develop in a
> >different pace at each organization.  As they have for current
> >Internet-banks that is so far the only
> >large-scale (almost) secure multi-organization transaction-environment on
> >the Internet.
> >The question that comes to my mind is: Will all Governments in the world
> >continue to adopt the
> >"All-speak-with-all-PKI" approach in spite of the fact that the private
> >sector probably have shunned it
> >due to complexity, privacy concerns, lack of control, and cost?
> >Regard
> >Anders Rundgren
> >X-OBI  read: http://www.x-obi.com/purple  run: http://buyer.x-obi.com
> >
> >
> >
> >----- Original Message -----
> >From: Fillingham, David W.
> >To: '[e-mail]' ; 'KPCMWG' ; 'DoD PKI TWG' ; '[e-mail]' ;
> >'Bridge CA Mail List' ; 'BCA Integration' ; * ALL
> >FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. ;
> >'[e-mail]' ; '[e-mail]' ; 'Steve Hanna
> >(SUN)' ; 'Susan Dernik'
> >Sent: Friday, April 06, 2001 16:48
> >Subject: DoD Bridge Certification Authority Phase II Demonstrations
> >
> >
> >For the last few years, the National Security Agency has led the
> >development of Bridge Certification Authority (BCA) technology
> >demonstrations.  In 1999, Phase One of the Department of Defense BCA
> >Technology Demonstration showed the technical feasibility of
> >achieving signed e-mail interoperability using multi-vendor
> >cross-certification in conjunction with chained directory systems.
> >
> >Phase Two of the demonstration is now ready to be shown.  Phase Two of the
> >DoD Bridge CA Phase II Technology Demonstration includes:
> >
> >Technologies:
> >
> >--  Certificate chain building in complex certificate graphs;
> >--  Integration of both mesh-style cross-certified PKIs and hierarchical PKIs;
> >--  Multi-signature/hash algorithm processing in certificate chains;
> >--  Certificate acceptance/rejection based on Certificate Policy
> >processing, including policy mapping;
> >--  Transitive trust limitation using Name Constraints processing;
> >--  Access Control using X.509 compliant attribute certificates (same
> >attribute certificates used for e-mail and web based access
> >control);
> >--  E-mail access control using S/MIME V3 labeling;
> >--  E-mail encryption using public key certificates authenticated via a
> >Bridge Certification Authority;
> >--  Border Directories;
> >--  Multivendor directory interoperation via X.500 chaining; and,
> >--  Transparent sharing of certificate revocation information across
> >several  PKIs using products of multiple PKI vendors.
> >
> >Client Applications:
> >
> >--  Baltimore Technologies MailSecure enabled Microsoft Outlook
> >--  Entrust Enabled Microsoft Outlook
> >--  Getronics S/MIME Freeware Library, Certificate Management Library, and
> >Access Control Library enabled Qualcomm Eudora
> >--  Getronics Certificate Management Library and Access Control Library
> >enabled Netscape Web Server
> >
> >Freeware Libraries:
> >
> >--  Cygnacom Certificate Path Development Library
> >      <http://www.cygnacom.com/products/index.htm>
> >--  Getronics S/MIME (Version 3) Freeware Library
> >      <http://www.getronicsgov.com/hot/sfl_home.htm>
> >--  Getronics Certificate Management Library
> >      <http://www.getronicsgov.com/hot/cml_home.htm>
> >-- Getronics Access Control Library
> >           <http://www.getronicsgov.com/hot/acl_home.htm>
> >CA vendor interoperability demonstrations:
> >
> >--  Baltimore Technologies
> >--  Entrust Technologies
> >--  Motorola
> >--  SPYRUS
> >
> >Directory Interoperability:
> >--  Entrust ICL
> >--  Entegrity Safepages Directory
> >Demonstrations will be held at the following locations and dates (note
> >that you MUST REGISTER to attend!  Registration information
> >is provided below):
> >
> >----------
> >CygnaCom
> >Suite 100 West
> >7927 Jones Branch Dr.
> >McLean, Virginia
> >
> >Directions to CygnaCom are located
> >at:  <http://www.cygnacom.com/contact/directions.htm>
> >
> >26 April 2001 - 0900
> >
> >26 April 2001 - 1300
> >
> >16 May 2001 - 0900
> >
> >16 May 2001 - 1300
> >
> >---------
> >Getronics Government Solutions
> >141 National Business Parkway, Suite 210
> >Annapolis Junction, Maryland
> >
> > From Washington DC: Take I-95 north; take MD Rt 32 east exit; take Dorsey
> >Run exit; at stop sign turn left on Dorsey Run; at stop light turn right on
> >Guilford Road which becomes National Business Pkwy.
> >
> > From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit; stay
> >in right lane of the exit which runs into National Business Pkwy; make a
> >right on National Business Pkwy.
> >
> >30 April 2001 - 1300
> >
> >8 May 2001 - 0900
> >
> >8 May 2001 - 1300
> >
> >24 May 2001 - 0900
> >
> >24 May 2001 - 1300
> >
> >---------
> >
> >All showings last about half a day - with a mixture of conference room
> >briefings and laboratory demonstrations.
> >
> >We are limited by available demonstration space to an absolute maximum of
> >20 participants at each showing.
> >
> >IMPORTANT:  PLEASE REGISTER WITH LISA FAULKNER ([e-mail]
> ><mailto:[e-mail]>) AND MYSELF
> >([e-mail] <mailto:[e-mail]>) IF YOU PLAN TO
> >ATTEND.  IF YOU DO NOT REGISTER TO ATTEND, YOU WILL NOT BE
> >ADMITTED TO THE DEMONSTRATION.
> >
> >Please provide the following information to register:
> >
> >--  Name
> >--  Organization
> >--  E-mail address
> >--  Date and time of the demonstration showing you wish to attend (with
> >alternates, if possible)
> >
> >We look forward to seeing you at the demonstration!
> >
> >Dave Fillingham
> >NSA
>
> --------
> TTFN
> Roger W. Younglove, CISSP
> Distinguished Member of Consulting Staff
> Lucent Worldwide Services--Information Security
> 100 Galleria Officentre, Ste. 220
> Southfield, MI 48034-8428
> Numeric page: 888.935.6755
> E-mail page:
> [e-mail]
> eFax number: 413.425.5368
> www.lucent.com/netcare



Received: from mailb.telia.com ([e-mail] [194.22.194.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA09466 for <[e-mail]>; Tue, 10 Apr 2001 09:08:14 -0700 (PDT)
Received: from arport ([212.181.94.147]) by mailb.telia.com (8.9.3/8.9.3) with SMTP id SAA16121; Tue, 10 Apr 2001 18:08:03 +0200 (CEST)
Message-ID: <014d01c0c1df$aebe0390$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Fillingham,  David W." <[e-mail]>, "PKIX-List" <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, <[e-mail]>, "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, "* ALL FIREBURST USERS *" <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, <[e-mail]>, <[e-mail]>, "'Steve Hanna \(SUN\)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>, "Roger Younglove" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
Date: Tue, 10 Apr 2001 18:59:59 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Roger,

>IMHO, when you have multiple PKIs with in any industry such as the 
>Automotive (ie. ANX) or the Government, cross certification become a 
>problem because the certificate chain of trust becomes so unwieldy and 
>revocation of a PKI is also a problem. The Bridge scenario solves this 
>problem. It is not the only solution but the simplest with a number of 
>existing PKIs.

Agreed, Bridge CAs solves (some of) the problems created by
unwieldy PKIs such as those created by DoD.

Domain-PKI does not requires such solutions as it is much simpler
to create and maintain.  100 millions users of Internet use it today
when they address an https URL.  That's simplicity IMHO.
Applied to B2B it gets just slightly more complicated.

Anders

At 05:21 AM 04/10/2001 , Anders Rundgren wrote:
>Santosh,
>Domain (server-based) PKI offers persistent signatures for non-repudiation 
>at a fraction
>of the cost (and inconvenience) that inter-organization client-based 
>signatures introduce.
>The need for bridge-CAs using domain-PKI is IMO very limited as the number 
>of CAs is
>reduced by several orders of magnitude by such approaches. 5-10 CAs 
>worldwide is my guess.
>
>I do have read the paper by Bill Burr. Did you read about Purple? I.e. do 
>you see a problem with this model?
>
>BTW, I am a (currently only lurking due to high work-load) member of the 
>OASIS Security Services TC where
>domain-based solutions are standardized. I have never ever seen such an 
>enormous committee activity so domain
>security is indeed red-hot.
>
>Internet2 with their Shibboleth distributed multi-campus authentication 
>system will be based on domain-PKI.
>
>Personally I expect the next version of OBI (Open Buying on the Internet) 
>to be entirely based
>on this concept by throwing out the inter-organization client-certs (that 
>never worked, so just about
>everybody turned to user-ID/passwords in spite of not being a part of the 
>standard).
>
>VISA's coming 3D Secure credit-card payment system is also based on 
>domain-PKI.
>
>Due to this, I think that DoD (and similar organizations all over the 
>globe) should very carefully evaluate the
>domain security alternative before they do any new investments in CA systems.
>
>Regards
>Anders
>----- Original Message -----
>From: Santosh Chokhani
>To: Anders Rundgren ; Fillingham, David W. ; PKIX-List ; 'KPCMWG' ; 'DoD 
>PKI TWG' ; [e-mail] ; 'Bridge CA Mail List' ; 'BCA
>Integration' ; * ALL FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. 
>; [e-mail] ;
>[e-mail] ; 'Steve Hanna (SUN)' ; 'Susan Dernik'
>Sent: Monday, April 09, 2001 22:39
>Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
>
>
>Anders:
>I think Bridge technology can be helpful to a vertical segment such as 
>banking, health care, automotive industry etc. in order to
>facilitate secure e-commerce among the trading partners where persistent 
>digital signature for non-repudiation may be required.
>Also, given how organizations manage their Web sites and we hear about Web 
>server break-in, persistent encryption (beyond SSL
>transport) may call for interoperable, inter-domain PKI.  Again Bridge CA 
>can help.
>Actually, I can see the benefits of layers (strata) of Bridge CAs, e.g., 
>Bridge CAs from various vertical segments themselves
>connecting to a Omni-Bridge.  In that case, the Bridge CAs will be 
>Principal CAs.
>I assume you have had a chance to review the excellent paper on the Bridge 
>concept developed by Bill Burr.
>-----Original Message-----
>From: Anders Rundgren [mailto:[e-mail]]
>Sent: Monday, April 09, 2001 2:08 PM
>To: Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD PKI TWG';
>[e-mail]; 'Bridge CA Mail List'; 'BCA Integration'; * ALL
>FIREBURST USERS *; 'Steve Capps'; Wagner, Clark J.;
>[e-mail]; [e-mail]; 'Steve Hanna
>(SUN)'; 'Susan Dernik'
>Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
>
>
>David,
>This is indeed an ambitious project. Unfortunately I doubt that the Bridge 
>model has any relevance in
>the private sector that for inter-organization communication, is more 
>likely to deploy domain-based
>PKI-solutions, that have the major advantage of already being supported by 
>global TTPs which makes
>domain security solutions useful for organizations of any size. I.e. 
>VeriSign's issuance of web-server
>certificates is "approximately" what is needed.
>That domain security is incompatible with most current digital signature 
>laws is a pity.  Particularly for
>the lawyers who created them.  :-)
>Using domain security, tracing, message archiving, and user-control is 
>essentially built-in.
>A further advantage of domain security models is that client security 
>solutions can develop in a
>different pace at each organization.  As they have for current 
>Internet-banks that is so far the only
>large-scale (almost) secure multi-organization transaction-environment on 
>the Internet.
>The question that comes to my mind is: Will all Governments in the world 
>continue to adopt the
>"All-speak-with-all-PKI" approach in spite of the fact that the private 
>sector probably have shunned it
>due to complexity, privacy concerns, lack of control, and cost?
>Regard
>Anders Rundgren
>X-OBI  read: http://www.x-obi.com/purple  run: http://buyer.x-obi.com
>
>
>
>----- Original Message -----
>From: Fillingham, David W.
>To: '[e-mail]' ; 'KPCMWG' ; 'DoD PKI TWG' ; '[e-mail]' ; 
>'Bridge CA Mail List' ; 'BCA Integration' ; * ALL
>FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. ; 
>'[e-mail]' ; '[e-mail]' ; 'Steve Hanna
>(SUN)' ; 'Susan Dernik'
>Sent: Friday, April 06, 2001 16:48
>Subject: DoD Bridge Certification Authority Phase II Demonstrations
>
>
>For the last few years, the National Security Agency has led the 
>development of Bridge Certification Authority (BCA) technology
>demonstrations.  In 1999, Phase One of the Department of Defense BCA 
>Technology Demonstration showed the technical feasibility of
>achieving signed e-mail interoperability using multi-vendor 
>cross-certification in conjunction with chained directory systems.
>
>Phase Two of the demonstration is now ready to be shown.  Phase Two of the 
>DoD Bridge CA Phase II Technology Demonstration includes:
>
>Technologies:
>
>--  Certificate chain building in complex certificate graphs;
>--  Integration of both mesh-style cross-certified PKIs and hierarchical PKIs;
>--  Multi-signature/hash algorithm processing in certificate chains;
>--  Certificate acceptance/rejection based on Certificate Policy 
>processing, including policy mapping;
>--  Transitive trust limitation using Name Constraints processing;
>--  Access Control using X.509 compliant attribute certificates (same 
>attribute certificates used for e-mail and web based access
>control);
>--  E-mail access control using S/MIME V3 labeling;
>--  E-mail encryption using public key certificates authenticated via a 
>Bridge Certification Authority;
>--  Border Directories;
>--  Multivendor directory interoperation via X.500 chaining; and,
>--  Transparent sharing of certificate revocation information across 
>several  PKIs using products of multiple PKI vendors.
>
>Client Applications:
>
>--  Baltimore Technologies MailSecure enabled Microsoft Outlook
>--  Entrust Enabled Microsoft Outlook
>--  Getronics S/MIME Freeware Library, Certificate Management Library, and 
>Access Control Library enabled Qualcomm Eudora
>--  Getronics Certificate Management Library and Access Control Library 
>enabled Netscape Web Server
>
>Freeware Libraries:
>
>--  Cygnacom Certificate Path Development Library
>      <http://www.cygnacom.com/products/index.htm>
>--  Getronics S/MIME (Version 3) Freeware Library
>      <http://www.getronicsgov.com/hot/sfl_home.htm>
>--  Getronics Certificate Management Library
>      <http://www.getronicsgov.com/hot/cml_home.htm>
>-- Getronics Access Control Library
>           <http://www.getronicsgov.com/hot/acl_home.htm>
>CA vendor interoperability demonstrations:
>
>--  Baltimore Technologies
>--  Entrust Technologies
>--  Motorola
>--  SPYRUS
>
>Directory Interoperability:
>--  Entrust ICL
>--  Entegrity Safepages Directory
>Demonstrations will be held at the following locations and dates (note 
>that you MUST REGISTER to attend!  Registration information
>is provided below):
>
>----------
>CygnaCom
>Suite 100 West
>7927 Jones Branch Dr.
>McLean, Virginia
>
>Directions to CygnaCom are located 
>at:  <http://www.cygnacom.com/contact/directions.htm>
>
>26 April 2001 - 0900
>
>26 April 2001 - 1300
>
>16 May 2001 - 0900
>
>16 May 2001 - 1300
>
>---------
>Getronics Government Solutions
>141 National Business Parkway, Suite 210
>Annapolis Junction, Maryland
>
> From Washington DC: Take I-95 north; take MD Rt 32 east exit; take Dorsey
>Run exit; at stop sign turn left on Dorsey Run; at stop light turn right on
>Guilford Road which becomes National Business Pkwy.
>
> From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit; stay
>in right lane of the exit which runs into National Business Pkwy; make a
>right on National Business Pkwy.
>
>30 April 2001 - 1300
>
>8 May 2001 - 0900
>
>8 May 2001 - 1300
>
>24 May 2001 - 0900
>
>24 May 2001 - 1300
>
>---------
>
>All showings last about half a day - with a mixture of conference room 
>briefings and laboratory demonstrations.
>
>We are limited by available demonstration space to an absolute maximum of 
>20 participants at each showing.
>
>IMPORTANT:  PLEASE REGISTER WITH LISA FAULKNER ([e-mail] 
><mailto:[e-mail]>) AND MYSELF
>([e-mail] <mailto:[e-mail]>) IF YOU PLAN TO 
>ATTEND.  IF YOU DO NOT REGISTER TO ATTEND, YOU WILL NOT BE
>ADMITTED TO THE DEMONSTRATION.
>
>Please provide the following information to register:
>
>--  Name
>--  Organization
>--  E-mail address
>--  Date and time of the demonstration showing you wish to attend (with 
>alternates, if possible)
>
>We look forward to seeing you at the demonstration!
>
>Dave Fillingham
>NSA

--------
TTFN
Roger W. Younglove, CISSP
Distinguished Member of Consulting Staff
Lucent Worldwide Services--Information Security
100 Galleria Officentre, Ste. 220
Southfield, MI 48034-8428
Numeric page: 888.935.6755
E-mail page:
[e-mail]
eFax number: 413.425.5368
www.lucent.com/netcare




Received: from dtctxexchims05.ins.com ([208.164.93.100]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA04880 for <[e-mail]>; Tue, 10 Apr 2001 08:39:11 -0700 (PDT)
Received: from cpxuser (PPPa3-ResaleDialinx80018-1R7282.dialinx.net [4.48.36.64]) by dtctxexchims05.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 210KNC81; Tue, 10 Apr 2001 10:34:26 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 10 Apr 2001 09:14:58 -0400
To: "Anders Rundgren" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Fillingham,  David W." <[e-mail]>, "PKIX-List" <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, <[e-mail]>, "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, "* ALL FIREBURST USERS *" <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, <[e-mail]>, <[e-mail]>, "'Steve Hanna \(SUN\)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>
From: Roger Younglove <[e-mail]>
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
In-Reply-To: <002101c0c19f$a3e1d0e0$0500a8c0@arport>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

IMHO, when you have multiple PKIs with in any industry such as the 
Automotive (ie. ANX) or the Government, cross certification become a 
problem because the certificate chain of trust becomes so unwieldy and 
revocation of a PKI is also a problem. The Bridge scenario solves this 
problem. It is not the only solution but the simplest with a number of 
existing PKIs.
At 05:21 AM 04/10/2001 , Anders Rundgren wrote:
>Santosh,
>Domain (server-based) PKI offers persistent signatures for non-repudiation 
>at a fraction
>of the cost (and inconvenience) that inter-organization client-based 
>signatures introduce.
>The need for bridge-CAs using domain-PKI is IMO very limited as the number 
>of CAs is
>reduced by several orders of magnitude by such approaches. 5-10 CAs 
>worldwide is my guess.
>
>I do have read the paper by Bill Burr. Did you read about Purple? I.e. do 
>you see a problem with this model?
>
>BTW, I am a (currently only lurking due to high work-load) member of the 
>OASIS Security Services TC where
>domain-based solutions are standardized. I have never ever seen such an 
>enormous committee activity so domain
>security is indeed red-hot.
>
>Internet2 with their Shibboleth distributed multi-campus authentication 
>system will be based on domain-PKI.
>
>Personally I expect the next version of OBI (Open Buying on the Internet) 
>to be entirely based
>on this concept by throwing out the inter-organization client-certs (that 
>never worked, so just about
>everybody turned to user-ID/passwords in spite of not being a part of the 
>standard).
>
>VISA's coming 3D Secure credit-card payment system is also based on 
>domain-PKI.
>
>Due to this, I think that DoD (and similar organizations all over the 
>globe) should very carefully evaluate the
>domain security alternative before they do any new investments in CA systems.
>
>Regards
>Anders
>----- Original Message -----
>From: Santosh Chokhani
>To: Anders Rundgren ; Fillingham, David W. ; PKIX-List ; 'KPCMWG' ; 'DoD 
>PKI TWG' ; [e-mail] ; 'Bridge CA Mail List' ; 'BCA
>Integration' ; * ALL FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. 
>; [e-mail] ;
>[e-mail] ; 'Steve Hanna (SUN)' ; 'Susan Dernik'
>Sent: Monday, April 09, 2001 22:39
>Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
>
>
>Anders:
>I think Bridge technology can be helpful to a vertical segment such as 
>banking, health care, automotive industry etc. in order to
>facilitate secure e-commerce among the trading partners where persistent 
>digital signature for non-repudiation may be required.
>Also, given how organizations manage their Web sites and we hear about Web 
>server break-in, persistent encryption (beyond SSL
>transport) may call for interoperable, inter-domain PKI.  Again Bridge CA 
>can help.
>Actually, I can see the benefits of layers (strata) of Bridge CAs, e.g., 
>Bridge CAs from various vertical segments themselves
>connecting to a Omni-Bridge.  In that case, the Bridge CAs will be 
>Principal CAs.
>I assume you have had a chance to review the excellent paper on the Bridge 
>concept developed by Bill Burr.
>-----Original Message-----
>From: Anders Rundgren [mailto:[e-mail]]
>Sent: Monday, April 09, 2001 2:08 PM
>To: Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD PKI TWG';
>[e-mail]; 'Bridge CA Mail List'; 'BCA Integration'; * ALL
>FIREBURST USERS *; 'Steve Capps'; Wagner, Clark J.;
>[e-mail]; [e-mail]; 'Steve Hanna
>(SUN)'; 'Susan Dernik'
>Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
>
>
>David,
>This is indeed an ambitious project. Unfortunately I doubt that the Bridge 
>model has any relevance in
>the private sector that for inter-organization communication, is more 
>likely to deploy domain-based
>PKI-solutions, that have the major advantage of already being supported by 
>global TTPs which makes
>domain security solutions useful for organizations of any size. I.e. 
>VeriSign's issuance of web-server
>certificates is "approximately" what is needed.
>That domain security is incompatible with most current digital signature 
>laws is a pity.  Particularly for
>the lawyers who created them.  :-)
>Using domain security, tracing, message archiving, and user-control is 
>essentially built-in.
>A further advantage of domain security models is that client security 
>solutions can develop in a
>different pace at each organization.  As they have for current 
>Internet-banks that is so far the only
>large-scale (almost) secure multi-organization transaction-environment on 
>the Internet.
>The question that comes to my mind is: Will all Governments in the world 
>continue to adopt the
>"All-speak-with-all-PKI" approach in spite of the fact that the private 
>sector probably have shunned it
>due to complexity, privacy concerns, lack of control, and cost?
>Regard
>Anders Rundgren
>X-OBI  read: http://www.x-obi.com/purple  run: http://buyer.x-obi.com
>
>
>
>----- Original Message -----
>From: Fillingham, David W.
>To: '[e-mail]' ; 'KPCMWG' ; 'DoD PKI TWG' ; '[e-mail]' ; 
>'Bridge CA Mail List' ; 'BCA Integration' ; * ALL
>FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. ; 
>'[e-mail]' ; '[e-mail]' ; 'Steve Hanna
>(SUN)' ; 'Susan Dernik'
>Sent: Friday, April 06, 2001 16:48
>Subject: DoD Bridge Certification Authority Phase II Demonstrations
>
>
>For the last few years, the National Security Agency has led the 
>development of Bridge Certification Authority (BCA) technology
>demonstrations.  In 1999, Phase One of the Department of Defense BCA 
>Technology Demonstration showed the technical feasibility of
>achieving signed e-mail interoperability using multi-vendor 
>cross-certification in conjunction with chained directory systems.
>
>Phase Two of the demonstration is now ready to be shown.  Phase Two of the 
>DoD Bridge CA Phase II Technology Demonstration includes:
>
>Technologies:
>
>--  Certificate chain building in complex certificate graphs;
>--  Integration of both mesh-style cross-certified PKIs and hierarchical PKIs;
>--  Multi-signature/hash algorithm processing in certificate chains;
>--  Certificate acceptance/rejection based on Certificate Policy 
>processing, including policy mapping;
>--  Transitive trust limitation using Name Constraints processing;
>--  Access Control using X.509 compliant attribute certificates (same 
>attribute certificates used for e-mail and web based access
>control);
>--  E-mail access control using S/MIME V3 labeling;
>--  E-mail encryption using public key certificates authenticated via a 
>Bridge Certification Authority;
>--  Border Directories;
>--  Multivendor directory interoperation via X.500 chaining; and,
>--  Transparent sharing of certificate revocation information across 
>several  PKIs using products of multiple PKI vendors.
>
>Client Applications:
>
>--  Baltimore Technologies MailSecure enabled Microsoft Outlook
>--  Entrust Enabled Microsoft Outlook
>--  Getronics S/MIME Freeware Library, Certificate Management Library, and 
>Access Control Library enabled Qualcomm Eudora
>--  Getronics Certificate Management Library and Access Control Library 
>enabled Netscape Web Server
>
>Freeware Libraries:
>
>--  Cygnacom Certificate Path Development Library
>      <http://www.cygnacom.com/products/index.htm>
>--  Getronics S/MIME (Version 3) Freeware Library
>      <http://www.getronicsgov.com/hot/sfl_home.htm>
>--  Getronics Certificate Management Library
>      <http://www.getronicsgov.com/hot/cml_home.htm>
>-- Getronics Access Control Library
>           <http://www.getronicsgov.com/hot/acl_home.htm>
>CA vendor interoperability demonstrations:
>
>--  Baltimore Technologies
>--  Entrust Technologies
>--  Motorola
>--  SPYRUS
>
>Directory Interoperability:
>--  Entrust ICL
>--  Entegrity Safepages Directory
>Demonstrations will be held at the following locations and dates (note 
>that you MUST REGISTER to attend!  Registration information
>is provided below):
>
>----------
>CygnaCom
>Suite 100 West
>7927 Jones Branch Dr.
>McLean, Virginia
>
>Directions to CygnaCom are located 
>at:  <http://www.cygnacom.com/contact/directions.htm>
>
>26 April 2001 - 0900
>
>26 April 2001 - 1300
>
>16 May 2001 - 0900
>
>16 May 2001 - 1300
>
>---------
>Getronics Government Solutions
>141 National Business Parkway, Suite 210
>Annapolis Junction, Maryland
>
> From Washington DC: Take I-95 north; take MD Rt 32 east exit; take Dorsey
>Run exit; at stop sign turn left on Dorsey Run; at stop light turn right on
>Guilford Road which becomes National Business Pkwy.
>
> From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit; stay
>in right lane of the exit which runs into National Business Pkwy; make a
>right on National Business Pkwy.
>
>30 April 2001 - 1300
>
>8 May 2001 - 0900
>
>8 May 2001 - 1300
>
>24 May 2001 - 0900
>
>24 May 2001 - 1300
>
>---------
>
>All showings last about half a day - with a mixture of conference room 
>briefings and laboratory demonstrations.
>
>We are limited by available demonstration space to an absolute maximum of 
>20 participants at each showing.
>
>IMPORTANT:  PLEASE REGISTER WITH LISA FAULKNER ([e-mail] 
><mailto:[e-mail]>) AND MYSELF
>([e-mail] <mailto:[e-mail]>) IF YOU PLAN TO 
>ATTEND.  IF YOU DO NOT REGISTER TO ATTEND, YOU WILL NOT BE
>ADMITTED TO THE DEMONSTRATION.
>
>Please provide the following information to register:
>
>--  Name
>--  Organization
>--  E-mail address
>--  Date and time of the demonstration showing you wish to attend (with 
>alternates, if possible)
>
>We look forward to seeing you at the demonstration!
>
>Dave Fillingham
>NSA

--------
TTFN
Roger W. Younglove, CISSP
Distinguished Member of Consulting Staff
Lucent Worldwide Services--Information Security
100 Galleria Officentre, Ste. 220
Southfield, MI 48034-8428
Numeric page: 888.935.6755
E-mail page:
[e-mail]
eFax number: 413.425.5368
www.lucent.com/netcare



Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA28032 for <[e-mail]>; Tue, 10 Apr 2001 07:17:26 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <H95FXG6R>; Tue, 10 Apr 2001 10:18:24 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "ietf-pkix@imc. org (E-mail)" <[e-mail]>
Subject: Comments to PKIX AC profile
Date: Tue, 10 Apr 2001 10:18:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

In a separate message, Stephen Henson reported an incompatibility between
the Attribute Certificate (AC) ASN.1 syntaxes defined in the PKIX AC Profile
for Authorization <draft-ietf-pkix-ac509prof-06.txt> and draft 2000 X.509
Recommendation (4th Edition, Draft V7, 23 Feb 2001).  
The PKIX AC Profile, Appendix B, ASN.1 module includes "DEFINITIONS EXPLICIT
TAGS ::=", but the 2000 X.509 Recommendation ASN.1 module defining the AC
syntax includes "DEFINITIONS IMPLICIT TAGS ::=".  Recommend that the PKIX AC
Profile should be changed so that the AC ASN.1 syntax is equivalent (i.e.
produces the identical ASN.1 hex encoding) to that defined in the draft 2000
X.509 Recommendation.  This could be accomplished by moving the AC syntax
definition (and component syntax definitions) from the existing Appendix B
module to a new ASN.1 module that includes "DEFINITIONS IMPLICIT TAGS ::=".
That is the strategy used in the draft 2000 X.509 Recommendation.

Also, recommend that ac509prof-06 file should be changed so that the
Clearance attribute ASN.1 syntax defined in Appendix B is equivalent to that
defined in X.501.  X.501 defines the Clearance attribute syntax using
AUTOMATIC TAGS.  The Clearance attribute syntax in the PKIX AC profile
should be changed as follows to be consistent with X.501:

Clearance ::= SEQUENCE
  {
      policyId
          [0] OBJECT IDENTIFIER,
      classList
          [1] ClassList DEFAULT {unclassified},
      securityCategories
          [2] SET OF SecurityCategory OPTIONAL
  }

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA12701 for <[e-mail]>; Tue, 10 Apr 2001 04:04:37 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10891; Tue, 10 Apr 2001 07:04:36 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-06.txt
Date: Tue, 10 Apr 2001 07:04:36 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-06.txt
	Pages		: 119
	Date		: 09-Apr-01
	
This is the fourth draft of a specification based upon RFC 2459.
When complete, this specification will obsolete RFC 2459.  This
specification includes minor edits and clarifications.  The most
notable departures from RFC 2459 are found in Section 6, Path
Validation.  In RFC 2459, the reader was expected to augment the path
validation algorithm, which concentrated upon policy processing, with
information embedded in earlier sections.  For example, parameter
inheritance is discussed in Section 7, Algorithm Support, and can
certainly affect the validity of a certification path.

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

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA28771 for <[e-mail]>; Tue, 10 Apr 2001 01:53:48 -0700 (PDT)
Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id RAA01164 for <[e-mail]>; Tue, 10 Apr 2001 17:53:42 +0900 (JST) (envelope-from [e-mail])
Received: from dsa.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/21/01) with ESMTP id RAA27848 for <[e-mail]>; Tue, 10 Apr 2001 17:53:40 +0900 (JST) (envelope-from [e-mail])
Received: from cats by dsa.isl.ntt.co.jp (8.9.3/isl-2.0) id RAA13812; Tue, 10 Apr 2001 17:53:39 +0900 (JST)
Date: Tue, 10 Apr 2001 17:55:46 +0900
From: Hideyuki Odahara <[e-mail]>
To: [e-mail]
Subject: attributes in AC
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03

Please teach me the difference of the use of
"Service Authentication Infomation" and "Access Identity" 
in Attribute Certificate, and how to use the "Access Identity" 
attribute if you have any concrete example.

It is described that "this is a different use to that intended
for the svceAuthInfo attribute discribed in 4.4.1 above." at the
page 19 in the internet-draft(draft-ietf-pkix-ac509prof).
But there is no example what situation does it suit.

thanks

----------
  Hideyuki Odahara $B!'(B [e-mail]



Received: from mailb.telia.com ([e-mail] [194.22.194.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA24587 for <[e-mail]>; Tue, 10 Apr 2001 01:29:46 -0700 (PDT)
Received: from arport ([212.181.94.147]) by mailb.telia.com (8.9.3/8.9.3) with SMTP id KAA24050; Tue, 10 Apr 2001 10:29:36 +0200 (CEST)
Message-ID: <002101c0c19f$a3e1d0e0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Fillingham,  David W." <[e-mail]>, "PKIX-List" <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, <[e-mail]>, "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, "* ALL FIREBURST USERS *" <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, <[e-mail]>, <[e-mail]>, "'Steve Hanna \(SUN\)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>
References: <[e-mail]>
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
Date: Tue, 10 Apr 2001 11:21:31 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Santosh,
Domain (server-based) PKI offers persistent signatures for non-repudiation at a fraction
of the cost (and inconvenience) that inter-organization client-based signatures introduce.
The need for bridge-CAs using domain-PKI is IMO very limited as the number of CAs is
reduced by several orders of magnitude by such approaches. 5-10 CAs worldwide is my guess.

I do have read the paper by Bill Burr. Did you read about Purple? I.e. do you see a problem with this model?

BTW, I am a (currently only lurking due to high work-load) member of the OASIS Security Services TC where
domain-based solutions are standardized. I have never ever seen such an enormous committee activity so domain
security is indeed red-hot.

Internet2 with their Shibboleth distributed multi-campus authentication system will be based on domain-PKI.

Personally I expect the next version of OBI (Open Buying on the Internet) to be entirely based
on this concept by throwing out the inter-organization client-certs (that never worked, so just about
everybody turned to user-ID/passwords in spite of not being a part of the standard).

VISA's coming 3D Secure credit-card payment system is also based on domain-PKI.

Due to this, I think that DoD (and similar organizations all over the globe) should very carefully evaluate the
domain security alternative before they do any new investments in CA systems.

Regards
Anders
----- Original Message -----
From: Santosh Chokhani
To: Anders Rundgren ; Fillingham, David W. ; PKIX-List ; 'KPCMWG' ; 'DoD PKI TWG' ; [e-mail] ; 'Bridge CA Mail List' ; 'BCA
Integration' ; * ALL FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. ; [e-mail] ;
[e-mail] ; 'Steve Hanna (SUN)' ; 'Susan Dernik'
Sent: Monday, April 09, 2001 22:39
Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations


Anders:
I think Bridge technology can be helpful to a vertical segment such as banking, health care, automotive industry etc. in order to
facilitate secure e-commerce among the trading partners where persistent digital signature for non-repudiation may be required.
Also, given how organizations manage their Web sites and we hear about Web server break-in, persistent encryption (beyond SSL
transport) may call for interoperable, inter-domain PKI.  Again Bridge CA can help.
Actually, I can see the benefits of layers (strata) of Bridge CAs, e.g., Bridge CAs from various vertical segments themselves
connecting to a Omni-Bridge.  In that case, the Bridge CAs will be Principal CAs.
I assume you have had a chance to review the excellent paper on the Bridge concept developed by Bill Burr.
-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Monday, April 09, 2001 2:08 PM
To: Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD PKI TWG';
[e-mail]; 'Bridge CA Mail List'; 'BCA Integration'; * ALL
FIREBURST USERS *; 'Steve Capps'; Wagner, Clark J.;
[e-mail]; [e-mail]; 'Steve Hanna
(SUN)'; 'Susan Dernik'
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations


David,
This is indeed an ambitious project. Unfortunately I doubt that the Bridge model has any relevance in
the private sector that for inter-organization communication, is more likely to deploy domain-based
PKI-solutions, that have the major advantage of already being supported by global TTPs which makes
domain security solutions useful for organizations of any size. I.e. VeriSign's issuance of web-server
certificates is "approximately" what is needed.
That domain security is incompatible with most current digital signature laws is a pity.  Particularly for
the lawyers who created them.  :-)
Using domain security, tracing, message archiving, and user-control is essentially built-in.
A further advantage of domain security models is that client security solutions can develop in a
different pace at each organization.  As they have for current Internet-banks that is so far the only
large-scale (almost) secure multi-organization transaction-environment on the Internet.
The question that comes to my mind is: Will all Governments in the world continue to adopt the
"All-speak-with-all-PKI" approach in spite of the fact that the private sector probably have shunned it
due to complexity, privacy concerns, lack of control, and cost?
Regard
Anders Rundgren
X-OBI  read: http://www.x-obi.com/purple  run: http://buyer.x-obi.com



----- Original Message -----
From: Fillingham, David W.
To: '[e-mail]' ; 'KPCMWG' ; 'DoD PKI TWG' ; '[e-mail]' ; 'Bridge CA Mail List' ; 'BCA Integration' ; * ALL
FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. ; '[e-mail]' ; '[e-mail]' ; 'Steve Hanna
(SUN)' ; 'Susan Dernik'
Sent: Friday, April 06, 2001 16:48
Subject: DoD Bridge Certification Authority Phase II Demonstrations


For the last few years, the National Security Agency has led the development of Bridge Certification Authority (BCA) technology
demonstrations.  In 1999, Phase One of the Department of Defense BCA Technology Demonstration showed the technical feasibility of
achieving signed e-mail interoperability using multi-vendor cross-certification in conjunction with chained directory systems.

Phase Two of the demonstration is now ready to be shown.  Phase Two of the DoD Bridge CA Phase II Technology Demonstration includes:

Technologies:

--  Certificate chain building in complex certificate graphs;
--  Integration of both mesh-style cross-certified PKIs and hierarchical PKIs;
--  Multi-signature/hash algorithm processing in certificate chains;
--  Certificate acceptance/rejection based on Certificate Policy processing, including policy mapping;
--  Transitive trust limitation using Name Constraints processing;
--  Access Control using X.509 compliant attribute certificates (same attribute certificates used for e-mail and web based access
control);
--  E-mail access control using S/MIME V3 labeling;
--  E-mail encryption using public key certificates authenticated via a Bridge Certification Authority;
--  Border Directories;
--  Multivendor directory interoperation via X.500 chaining; and,
--  Transparent sharing of certificate revocation information across several  PKIs using products of multiple PKI vendors.

Client Applications:

--  Baltimore Technologies MailSecure enabled Microsoft Outlook
--  Entrust Enabled Microsoft Outlook
--  Getronics S/MIME Freeware Library, Certificate Management Library, and Access Control Library enabled Qualcomm Eudora
--  Getronics Certificate Management Library and Access Control Library enabled Netscape Web Server

Freeware Libraries:

--  Cygnacom Certificate Path Development Library
     <http://www.cygnacom.com/products/index.htm>
--  Getronics S/MIME (Version 3) Freeware Library
     <http://www.getronicsgov.com/hot/sfl_home.htm>
--  Getronics Certificate Management Library
     <http://www.getronicsgov.com/hot/cml_home.htm>
-- Getronics Access Control Library
          <http://www.getronicsgov.com/hot/acl_home.htm>
CA vendor interoperability demonstrations:

--  Baltimore Technologies
--  Entrust Technologies
--  Motorola
--  SPYRUS

Directory Interoperability:
--  Entrust ICL
--  Entegrity Safepages Directory
Demonstrations will be held at the following locations and dates (note that you MUST REGISTER to attend!  Registration information
is provided below):

----------
CygnaCom
Suite 100 West
7927 Jones Branch Dr.
McLean, Virginia

Directions to CygnaCom are located at:  <http://www.cygnacom.com/contact/directions.htm>

26 April 2001 - 0900

26 April 2001 - 1300

16 May 2001 - 0900

16 May 2001 - 1300

---------
Getronics Government Solutions
141 National Business Parkway, Suite 210
Annapolis Junction, Maryland

>From Washington DC: Take I-95 north; take MD Rt 32 east exit; take Dorsey
Run exit; at stop sign turn left on Dorsey Run; at stop light turn right on
Guilford Road which becomes National Business Pkwy.

>From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit; stay
in right lane of the exit which runs into National Business Pkwy; make a
right on National Business Pkwy.

30 April 2001 - 1300

8 May 2001 - 0900

8 May 2001 - 1300

24 May 2001 - 0900

24 May 2001 - 1300

---------

All showings last about half a day - with a mixture of conference room briefings and laboratory demonstrations.

We are limited by available demonstration space to an absolute maximum of 20 participants at each showing.

IMPORTANT:  PLEASE REGISTER WITH LISA FAULKNER ([e-mail] <mailto:[e-mail]>) AND MYSELF
([e-mail] <mailto:[e-mail]>) IF YOU PLAN TO ATTEND.  IF YOU DO NOT REGISTER TO ATTEND, YOU WILL NOT BE
ADMITTED TO THE DEMONSTRATION.

Please provide the following information to register:

--  Name
--  Organization
--  E-mail address
--  Date and time of the demonstration showing you wish to attend (with alternates, if possible)

We look forward to seeing you at the demonstration!

Dave Fillingham
NSA




Received: from tufan.tsk.mil.tr (tufan.tsk.mil.tr [212.50.38.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA25912 for <[e-mail]>; Mon, 9 Apr 2001 22:47:04 -0700 (PDT)
Received: from yengec (192.168.1.1 [192.168.1.1]) by tufan.tsk.mil.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H946ZZ3D; Tue, 10 Apr 2001 08:47:05 +0300
From: "Erdal YILDIZ" <[e-mail]>
To: <[e-mail]>
Subject: X.509 2000 Version
Date: Tue, 10 Apr 2001 00:33:03 +0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-9"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

Hi All;

I am looking for X.509 2000 Version documentation. If some one help me, I
will be really very appreciated.

Thanks

Erdal YILDIZ



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA00908 for <[e-mail]>; Mon, 9 Apr 2001 13:48:19 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <2S5ST36K>; Mon, 9 Apr 2001 16:47:50 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Anders Rundgren <[e-mail]>, "Fillingham,  David W." <[e-mail]>, PKIX-List <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, [e-mail], "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, * ALL FIREBURST USERS * <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, [e-mail], [e-mail], "'Steve Hanna (SUN)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>
Subject: RE: DoD Bridge Certification Authority Phase II Demonstrations
Date: Mon, 9 Apr 2001 16:39:16 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C135.2520D4F0"

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_01C0C135.2520D4F0
Content-Type: text/plain;
	charset="iso-8859-1"

Anders:

I think Bridge technology can be helpful to a vertical segment such as
banking, health care, automotive industry etc. in order to facilitate secure
e-commerce among the trading partners where persistent digital signature for
non-repudiation may be required.

Also, given how organizations manage their Web sites and we hear about Web
server break-in, persistent encryption (beyond SSL transport) may call for
interoperable, inter-domain PKI.  Again Bridge CA can help.

Actually, I can see the benefits of layers (strata) of Bridge CAs, e.g.,
Bridge CAs from various vertical segments themselves connecting to a
Omni-Bridge.  In that case, the Bridge CAs will be Principal CAs.

I assume you have had a chance to review the excellent paper on the Bridge
concept developed by Bill Burr.

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Monday, April 09, 2001 2:08 PM
To: Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD PKI TWG';
[e-mail]; 'Bridge CA Mail List'; 'BCA Integration'; * ALL
FIREBURST USERS *; 'Steve Capps'; Wagner, Clark J.;
[e-mail]; [e-mail]; 'Steve Hanna
(SUN)'; 'Susan Dernik'
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations


David, 
This is indeed an ambitious project. Unfortunately I doubt that the Bridge
model has any relevance in 
the private sector that for inter-organization communication, is more likely
to deploy domain-based 
PKI-solutions, that have the major advantage of already being supported by
global TTPs which makes
domain security solutions useful for organizations of any size. I.e.
VeriSign's issuance of web-server
certificates is "approximately" what is needed. 

That domain security is incompatible with most current digital signature
laws is a pity.  Particularly for
the lawyers who created them.  :-)

Using domain security, tracing, message archiving, and user-control is
essentially built-in.

A further advantage of domain security models is that client security
solutions can develop in a
different pace at each organization.  As they have for current
Internet-banks that is so far the only
large-scale (almost) secure multi-organization transaction-environment on
the Internet.

The question that comes to my mind is: Will all Governments in the world
continue to adopt the
"All-speak-with-all-PKI" approach in spite of the fact that the private
sector probably have shunned it
due to complexity, privacy concerns, lack of control, and cost?

Regard
Anders Rundgren
X-OBI  read: http://www.x-obi.com/purple  run: http://buyer.x-obi.com 



----- Original Message ----- 
From: Fillingham, David W. 
To: '[e-mail]' ; 'KPCMWG' ; 'DoD PKI TWG' ; '[e-mail]' ;
'Bridge CA Mail List' ; 'BCA Integration' ; * ALL FIREBURST USERS * ; 'Steve
Capps' ; Wagner, Clark J. ; '[e-mail]' ;
'[e-mail]' ; 'Steve Hanna (SUN)' ; 'Susan Dernik' 
Sent: Friday, April 06, 2001 16:48
Subject: DoD Bridge Certification Authority Phase II Demonstrations


For the last few years, the National Security Agency has led the development
of Bridge Certification Authority (BCA) technology demonstrations.  In 1999,
Phase One of the Department of Defense BCA Technology Demonstration showed
the technical feasibility of achieving signed e-mail interoperability using
multi-vendor cross-certification in conjunction with chained directory
systems.
 
Phase Two of the demonstration is now ready to be shown.  Phase Two of the
DoD Bridge CA Phase II Technology Demonstration includes: 
 
Technologies: 
  
--  Certificate chain building in complex certificate graphs; 
--  Integration of both mesh-style cross-certified PKIs and hierarchical
PKIs; 
--  Multi-signature/hash algorithm processing in certificate chains; 
--  Certificate acceptance/rejection based on Certificate Policy processing,
including policy mapping;
--  Transitive trust limitation using Name Constraints processing;
--  Access Control using X.509 compliant attribute certificates (same
attribute certificates used for e-mail and web based access control);
--  E-mail access control using S/MIME V3 labeling;
--  E-mail encryption using public key certificates authenticated via a
Bridge Certification Authority;
--  Border Directories;
--  Multivendor directory interoperation via X.500 chaining; and, 
--  Transparent sharing of certificate revocation information across several
PKIs using products of multiple PKI vendors.
 
Client Applications: 
  
--  Baltimore Technologies MailSecure enabled Microsoft Outlook 
--  Entrust Enabled Microsoft Outlook
--  Getronics S/MIME Freeware Library, Certificate Management Library, and
Access Control Library enabled Qualcomm Eudora
--  Getronics Certificate Management Library and Access Control Library
enabled Netscape Web Server 
  
Freeware Libraries: 
  
--  Cygnacom Certificate Path Development Library 
     <http://www.cygnacom.com/products/index.htm> 
--  Getronics S/MIME (Version 3) Freeware Library 
     <http://www.getronicsgov.com/hot/sfl_home.htm> 
--  Getronics Certificate Management Library 
     <http://www.getronicsgov.com/hot/cml_home.htm> 
-- Getronics Access Control Library 
          <http://www.getronicsgov.com/hot/acl_home.htm> 
CA vendor interoperability demonstrations: 
  
--  Baltimore Technologies
--  Entrust Technologies
--  Motorola
--  SPYRUS 
  
Directory Interoperability: 
--  Entrust ICL 
--  Entegrity Safepages Directory 
Demonstrations will be held at the following locations and dates (note that
you MUST REGISTER to attend!  Registration information is provided below):
 
---------- 
CygnaCom 
Suite 100 West 
7927 Jones Branch Dr.
McLean, Virginia 
  
Directions to CygnaCom are located at:
<http://www.cygnacom.com/contact/directions.htm> 
  
26 April 2001 - 0900 
  
26 April 2001 - 1300 
  
16 May 2001 - 0900 
  
16 May 2001 - 1300 
  
--------- 
Getronics Government Solutions 
141 National Business Parkway, Suite 210 
Annapolis Junction, Maryland 
  
>From Washington DC: Take I-95 north; take MD Rt 32 east exit; take Dorsey 
Run exit; at stop sign turn left on Dorsey Run; at stop light turn right on 
Guilford Road which becomes National Business Pkwy. 
  
>From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit; stay 
in right lane of the exit which runs into National Business Pkwy; make a 
right on National Business Pkwy. 
  
30 April 2001 - 1300 
  
8 May 2001 - 0900 
  
8 May 2001 - 1300 
  
24 May 2001 - 0900 
  
24 May 2001 - 1300 
  
--------- 
  
All showings last about half a day - with a mixture of conference room
briefings and laboratory demonstrations. 
  
We are limited by available demonstration space to an absolute maximum of 20
participants at each showing.  
  
IMPORTANT:  PLEASE REGISTER WITH LISA FAULKNER ([e-mail]
<mailto:[e-mail]>) AND MYSELF ([e-mail]
<mailto:[e-mail]>) IF YOU PLAN TO ATTEND.  IF YOU DO NOT
REGISTER TO ATTEND, YOU WILL NOT BE ADMITTED TO THE DEMONSTRATION.
 
Please provide the following information to register: 
  
--  Name 
--  Organization 
--  E-mail address 
--  Date and time of the demonstration showing you wish to attend (with
alternates, if possible) 
  
We look forward to seeing you at the demonstration! 
  
Dave Fillingham 
NSA 


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: DoD Bridge Certification Authority Phase II =
Demonstrations</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I think Bridge technology can be helpful to a =
vertical segment such as banking, health care, automotive industry etc. =
in order to facilitate secure e-commerce among the trading partners =
where persistent digital signature for non-repudiation may be =
required.</FONT></P>

<P><FONT SIZE=3D2>Also, given how organizations manage their Web sites =
and we hear about Web server break-in, persistent encryption (beyond =
SSL transport) may call for interoperable, inter-domain PKI.&nbsp; =
Again Bridge CA can help.</FONT></P>

<P><FONT SIZE=3D2>Actually, I can see the benefits of layers (strata) =
of Bridge CAs, e.g., Bridge CAs from various vertical segments =
themselves connecting to a Omni-Bridge.&nbsp; In that case, the Bridge =
CAs will be Principal CAs.</FONT></P>

<P><FONT SIZE=3D2>I assume you have had a chance to review the =
excellent paper on the Bridge concept developed by Bill Burr.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 09, 2001 2:08 PM</FONT>
<BR><FONT SIZE=3D2>To: Fillingham, David W.; PKIX-List; 'KPCMWG'; 'DoD =
PKI TWG';</FONT>
<BR><FONT SIZE=3D2>[e-mail]; 'Bridge CA Mail List'; 'BCA =
Integration'; * ALL</FONT>
<BR><FONT SIZE=3D2>FIREBURST USERS *; 'Steve Capps'; Wagner, Clark =
J.;</FONT>
<BR><FONT SIZE=3D2>[e-mail]; =
[e-mail]; 'Steve Hanna</FONT>
<BR><FONT SIZE=3D2>(SUN)'; 'Susan Dernik'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: DoD Bridge Certification Authority =
Phase II Demonstrations</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>David, </FONT>
<BR><FONT SIZE=3D2>This is indeed an ambitious project. Unfortunately I =
doubt that the Bridge model has any relevance in </FONT>
<BR><FONT SIZE=3D2>the private sector that for inter-organization =
communication, is more likely to deploy domain-based </FONT>
<BR><FONT SIZE=3D2>PKI-solutions, that have the major advantage of =
already being supported by global TTPs which makes</FONT>
<BR><FONT SIZE=3D2>domain security solutions useful for organizations =
of any size. I.e. VeriSign's issuance of web-server</FONT>
<BR><FONT SIZE=3D2>certificates is &quot;approximately&quot; what is =
needed. </FONT>
</P>

<P><FONT SIZE=3D2>That domain security is incompatible with most =
current digital signature laws is a pity.&nbsp; Particularly for</FONT>
<BR><FONT SIZE=3D2>the lawyers who created them.&nbsp; :-)</FONT>
</P>

<P><FONT SIZE=3D2>Using domain security, tracing, message archiving, =
and user-control is essentially built-in.</FONT>
</P>

<P><FONT SIZE=3D2>A further advantage of domain security models is that =
client security solutions can develop in a</FONT>
<BR><FONT SIZE=3D2>different pace at each organization.&nbsp; As they =
have for current Internet-banks that is so far the only</FONT>
<BR><FONT SIZE=3D2>large-scale (almost) secure multi-organization =
transaction-environment on the Internet.</FONT>
</P>

<P><FONT SIZE=3D2>The question that comes to my mind is: Will all =
Governments in the world continue to adopt the</FONT>
<BR><FONT SIZE=3D2>&quot;All-speak-with-all-PKI&quot; approach in spite =
of the fact that the private sector probably have shunned it</FONT>
<BR><FONT SIZE=3D2>due to complexity, privacy concerns, lack of =
control, and cost?</FONT>
</P>

<P><FONT SIZE=3D2>Regard</FONT>
<BR><FONT SIZE=3D2>Anders Rundgren</FONT>
<BR><FONT SIZE=3D2>X-OBI&nbsp; read: <A =
HREF=3D"http://www.x-obi.com/purple" =
TARGET=3D"_blank">http://www.x-obi.com/purple</A>&nbsp; run: <A =
HREF=3D"http://buyer.x-obi.com" =
TARGET=3D"_blank">http://buyer.x-obi.com</A> </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>----- Original Message ----- </FONT>
<BR><FONT SIZE=3D2>From: Fillingham, David W. </FONT>
<BR><FONT SIZE=3D2>To: '[e-mail]' ; 'KPCMWG' ; 'DoD PKI TWG' ; =
'[e-mail]' ; 'Bridge CA Mail List' ; 'BCA Integration' ; * ALL =
FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. ; =
'[e-mail]' ; '[e-mail]' ; 'Steve =
Hanna (SUN)' ; 'Susan Dernik' </FONT></P>

<P><FONT SIZE=3D2>Sent: Friday, April 06, 2001 16:48</FONT>
<BR><FONT SIZE=3D2>Subject: DoD Bridge Certification Authority Phase II =
Demonstrations</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>For the last few years, the National Security Agency =
has led the development of Bridge Certification Authority (BCA) =
technology demonstrations.&nbsp; In 1999, Phase One of the Department =
of Defense BCA Technology Demonstration showed the technical =
feasibility of achieving signed e-mail interoperability using =
multi-vendor cross-certification in conjunction with chained directory =
systems.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Phase Two of the demonstration is now ready to be =
shown.&nbsp; Phase Two of the DoD Bridge CA Phase II Technology =
Demonstration includes: </FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Technologies: </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Certificate chain building in complex =
certificate graphs; </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Integration of both mesh-style =
cross-certified PKIs and hierarchical PKIs; </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Multi-signature/hash algorithm processing =
in certificate chains; </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Certificate acceptance/rejection based on =
Certificate Policy processing, including policy mapping;</FONT>
<BR><FONT SIZE=3D2>--&nbsp; Transitive trust limitation using Name =
Constraints processing;</FONT>
<BR><FONT SIZE=3D2>--&nbsp; Access Control using X.509 compliant =
attribute certificates (same attribute certificates used for e-mail and =
web based access control);</FONT></P>

<P><FONT SIZE=3D2>--&nbsp; E-mail access control using S/MIME V3 =
labeling;</FONT>
<BR><FONT SIZE=3D2>--&nbsp; E-mail encryption using public key =
certificates authenticated via a Bridge Certification Authority;</FONT>
<BR><FONT SIZE=3D2>--&nbsp; Border Directories;</FONT>
<BR><FONT SIZE=3D2>--&nbsp; Multivendor directory interoperation via =
X.500 chaining; and, </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Transparent sharing of certificate =
revocation information across several&nbsp; PKIs using products of =
multiple PKI vendors.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Client Applications: </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Baltimore Technologies MailSecure enabled =
Microsoft Outlook </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Entrust Enabled Microsoft Outlook</FONT>
<BR><FONT SIZE=3D2>--&nbsp; Getronics S/MIME Freeware Library, =
Certificate Management Library, and Access Control Library enabled =
Qualcomm Eudora</FONT></P>

<P><FONT SIZE=3D2>--&nbsp; Getronics Certificate Management Library and =
Access Control Library enabled Netscape Web Server </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>Freeware Libraries: </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Cygnacom Certificate Path Development =
Library </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.cygnacom.com/products/index.htm" =
TARGET=3D"_blank">http://www.cygnacom.com/products/index.htm</A>&gt; =
</FONT>
<BR><FONT SIZE=3D2>--&nbsp; Getronics S/MIME (Version 3) Freeware =
Library </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/sfl_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/sfl_home.htm</A>&gt; =
</FONT>
<BR><FONT SIZE=3D2>--&nbsp; Getronics Certificate Management Library =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/cml_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/cml_home.htm</A>&gt; =
</FONT>
<BR><FONT SIZE=3D2>-- Getronics Access Control Library </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/acl_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/acl_home.htm</A>&gt; =
</FONT>
<BR><FONT SIZE=3D2>CA vendor interoperability demonstrations: </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Baltimore Technologies</FONT>
<BR><FONT SIZE=3D2>--&nbsp; Entrust Technologies</FONT>
<BR><FONT SIZE=3D2>--&nbsp; Motorola</FONT>
<BR><FONT SIZE=3D2>--&nbsp; SPYRUS </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>Directory Interoperability: </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Entrust ICL </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Entegrity Safepages Directory </FONT>
<BR><FONT SIZE=3D2>Demonstrations will be held at the following =
locations and dates (note that you MUST REGISTER to attend!&nbsp; =
Registration information is provided below):</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>---------- </FONT>
<BR><FONT SIZE=3D2>CygnaCom </FONT>
<BR><FONT SIZE=3D2>Suite 100 West </FONT>
<BR><FONT SIZE=3D2>7927 Jones Branch Dr.</FONT>
<BR><FONT SIZE=3D2>McLean, Virginia </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>Directions to CygnaCom are located at:&nbsp; &lt;<A =
HREF=3D"http://www.cygnacom.com/contact/directions.htm" =
TARGET=3D"_blank">http://www.cygnacom.com/contact/directions.htm</A>&gt;=
 </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>26 April 2001 - 0900 </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>26 April 2001 - 1300 </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>16 May 2001 - 0900 </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>16 May 2001 - 1300 </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>--------- </FONT>
<BR><FONT SIZE=3D2>Getronics Government Solutions </FONT>
<BR><FONT SIZE=3D2>141 National Business Parkway, Suite 210 </FONT>
<BR><FONT SIZE=3D2>Annapolis Junction, Maryland </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>From Washington DC: Take I-95 north; take MD Rt 32 =
east exit; take Dorsey </FONT>
<BR><FONT SIZE=3D2>Run exit; at stop sign turn left on Dorsey Run; at =
stop light turn right on </FONT>
<BR><FONT SIZE=3D2>Guilford Road which becomes National Business Pkwy. =
</FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>From Baltimore: Take BW Parkway (295) south; take MD =
Rt 32 west exit; stay </FONT>
<BR><FONT SIZE=3D2>in right lane of the exit which runs into National =
Business Pkwy; make a </FONT>
<BR><FONT SIZE=3D2>right on National Business Pkwy. </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>30 April 2001 - 1300 </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>8 May 2001 - 0900 </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>8 May 2001 - 1300 </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>24 May 2001 - 0900 </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>24 May 2001 - 1300 </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>--------- </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>All showings last about half a day - with a mixture =
of conference room briefings and laboratory demonstrations. </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>We are limited by available demonstration space to =
an absolute maximum of 20 participants at each showing.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>IMPORTANT:&nbsp; PLEASE REGISTER WITH LISA FAULKNER =
([e-mail] &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
&gt;) AND MYSELF ([e-mail] &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
&gt;) IF YOU PLAN TO ATTEND.&nbsp; IF YOU DO NOT REGISTER TO ATTEND, =
YOU WILL NOT BE ADMITTED TO THE DEMONSTRATION.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Please provide the following information to =
register: </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Name </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Organization </FONT>
<BR><FONT SIZE=3D2>--&nbsp; E-mail address </FONT>
<BR><FONT SIZE=3D2>--&nbsp; Date and time of the demonstration showing =
you wish to attend (with alternates, if possible) </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>We look forward to seeing you at the demonstration! =
</FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>Dave Fillingham </FONT>
<BR><FONT SIZE=3D2>NSA </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0C135.2520D4F0--


Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA28712 for <[e-mail]>; Mon, 9 Apr 2001 13:16:19 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id NAA01611; Mon, 9 Apr 2001 13:15:47 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id NAA29768; Mon, 9 Apr 2001 13:15:47 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 09 Apr 2001 13:19:36 -0700
To: "David P. Kemp" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Cc: Bob Jueneman <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:00 PM 4/9/01 -0400, David P. Kemp wrote:
>Bob Jueneman wrote:
> >
> > And given that scenario, I continue to believe that the currently
> > ill-defined bit should be officially deprecated, and some other
> > attributes defined as necessary with a great deal more precision.
> > If ISO X.509 and/or the PKIX group refuses to deprecate the bit,
> > then certainly the user community should.  IMHO, of course.
>
>And I continue to believe you are correct.  NR should be deprecated,
>and replaced with a new name for bit 0:  "Persistent Data
>Authentication", which would have the property that was once
>called "Technical NR".

I have to agree.  The greatest utility of this bit, a quality over which 
the CA actually has some control, is the commitment to provide for a degree 
of data-persistence.  If such a revision would occur, these discussions 
could actually address something tangible.

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from marcy.adiron.com (root@[128.230.111.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA24264 for <[e-mail]>; Mon, 9 Apr 2001 12:28:34 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.10.2/8.10.2) with ESMTP id f39JM6k06315; Mon, 9 Apr 2001 19:22:06 GMT
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Mon, 9 Apr 2001 15:22:06 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Aram Perez <[e-mail]>
cc: Bob Jueneman <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Meaning of Non-repudiation
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 8 Apr 2001, Aram Perez wrote:

> The problem is that nothing prevents me (or any other person) from having
> more than one certificate for my public key. So I can have one certificate
> with NR and the other without NR.

Isn't it really worse than that? Nothing prevents your public key being
associated with any other name (DN), keyCertSsign bit, any other
certificate extension, Novel Security Attributes, or otherwise. The only
thing that makes the certificate somewhat believable is *your* trust in
holder of the private key that signed the thing.

Isn't a certificate is merely nothing but a another generic document that
is "loosely"  signed by a private key? That document can mean anything to
the "relying" party.  The certificate key usage bits, extensions, or even
the associated DNs are meaningless without an agreement of interpretation
between all three parties involved (CA included), and probably (as Bob
frequently notes) their lawyers, and subsequent judges and juries, as
well.

What does it matter if it's called nonRepudiation, or keyCertSign, or
digitalSignature? I do not see carrying much weight to the key usage bits
at all. I cannot see how or why it really plays a part any validation
process.

BTW, I find it really bizarre that the digitalSignature bit alone says
that this key, which happens to be in this certificate, is allowed to sign
****ANY**** document EXCEPT for a document that just happens to look like
an X.509 Certificate or CRL. It's as if the X.509 certificate or CRL were
the strongest documents in the world one can sign! Is this correct?

Cheers,
-Polar

> > so that the system software can't
> > sign two or more things after the key is unlocked.  The bit could also be used
> > to bring up various dire warnings, cautioning the user to be really, really
> > sure that he knows what he is doing, thereby confirming the user's conscious
> > and willing intent.
> >
> > Of course this same meaning could be applied to a bit in an attribute
> > associated with the private key
>
> I agree that this is where it belongs, but the few crypto APIs (partial
> list: PKCS#11 and CDSA) that support private key attributes treat the
> attributes as optional and don't define a specific NR attribute.
>
> Regards,
> Aram Perez
>
> [snip]
>




Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA20801 for <[e-mail]>; Mon, 9 Apr 2001 11:43:13 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id LAA25118; Mon, 9 Apr 2001 11:42:46 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA03055; Mon, 9 Apr 2001 11:42:46 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 09 Apr 2001 11:46:34 -0700
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Meaning of Non-repudiation
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 10:55 AM 4/7/01 -0600, Bob Jueneman wrote:
>Although I enjoyed Tony's tongue-in-cheek usage scenario, I'm not sure 
>that I agree with his assumption that it is the issuing CA that is driving 
>this -- I don't view this as being a CA-centric issue.  Yes, I agree that 
>the CA COULD define the meaning of the bit in it's CPS and CP, but WILL 
>they -- that is the question.  and if they do, is it enforceable against 
>the CA, or only against the subscriber -- that is the issue.
>
>In particular, I do NOT think that the NR bit says something very 
>noteworthy about what the CA is going to do or not do. Instead, I believe 
>the NR bit is exclusively saying something about the signing party's 
>behavior.  It seems pretty unlikely that the CA (or some independent 
>auditing group) is going to actually go out to the subscriber's premises 
>and investigate their practices, not to mention intrusive.  And I don't 
>think that the NR bit should be construed as implying something about how 
>the CA is going to keep CRL records until infinity, etc.
>
>So at best the NR bit is a representation made by the subscriber to the 
>world via the CA.  In this case the CA is essentially acting as the 
>trusted publisher of a Legal Notice in the paper.  The CA/publisher is not 
>necessarily itself guaranteeing the correctness or truthfulness of the 
>notice, only that it is printed verbatim as received from the 
>subscriber.  Of course if the CA wants to get into the insurance business, 
>or the notary business, or some other business that involves guaranteeing 
>either the user's behavior or the particular transaction, that is a 
>completely different matter, and one that I don't believe could or should 
>be inferred from the NR bit.

Bob,

In essence, I agree with you.  The most that any CA can (currently) say 
about a certificate issued with NR=1 is "The subscriber asked that this bit 
be set."  (One would hope that the subscriber is NOT issued a NR=1 
certificate when this was NOT asked for.)

I was certainly not imagining that the CA would perform any 
"follow-through" on the key usage, but a CA that required the "subscriber 
affidavit of NR responsibility" is a possibility, and would mean something 
more than "they asked to set this bit, whatever it means."

A reputable CA should not issue to me a certificate as Bob Jueneman 
<[e-mail]> simply because I ask for it.  Why should things be 
any different for a request that NR=1?
I would prefer they go further still, and accommodate the "Technical 
Non-Repudiation"
assurances described in Tom Ginden's draft.

By issuing a certificate, a CA should be providing something more than the 
assurance that "string X has been cryptographically bound to string Y, 
under our CA-key".

Reading Aram's comment, though, (multiple certification of a single key,) 
things get muddier still.

___tony___





Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA18697 for <[e-mail]>; Mon, 9 Apr 2001 11:09:58 -0700 (PDT)
Received: from mega (t4o69p87.telia.com [62.20.145.207]) by mailg.telia.com (8.11.2/8.11.0) with SMTP id f39I9ob04664; Mon, 9 Apr 2001 20:09:50 +0200 (CEST)
Message-ID: <004a01c0c120$0172f840$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Fillingham,  David W." <[e-mail]>, "PKIX-List" <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, <[e-mail]>, "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, "* ALL FIREBURST USERS *" <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, <[e-mail]>, <[e-mail]>, "'Steve Hanna \(SUN\)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>
References: <[e-mail]>
Subject: Re: DoD Bridge Certification Authority Phase II Demonstrations
Date: Mon, 9 Apr 2001 20:07:51 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id LAA18698

David, 
This is indeed an ambitious project. Unfortunately I doubt that the Bridge model has any relevance in 
the private sector that for inter-organization communication, is more likely to deploy domain-based 
PKI-solutions, that have the major advantage of already being supported by global TTPs which makes
domain security solutions useful for organizations of any size. I.e. VeriSign's issuance of web-server
certificates is "approximately" what is needed. 

That domain security is incompatible with most current digital signature laws is a pity.  Particularly for
the lawyers who created them.  :-)

Using domain security, tracing, message archiving, and user-control is essentially built-in.

A further advantage of domain security models is that client security solutions can develop in a
different pace at each organization.  As they have for current Internet-banks that is so far the only
large-scale (almost) secure multi-organization transaction-environment on the Internet.

The question that comes to my mind is: Will all Governments in the world continue to adopt the
"All-speak-with-all-PKI" approach in spite of the fact that the private sector probably have shunned it
due to complexity, privacy concerns, lack of control, and cost?

Regard
Anders Rundgren
X-OBI  read: http://www.x-obi.com/purple  run: http://buyer.x-obi.com 



----- Original Message ----- 
From: Fillingham, David W. 
To: '[e-mail]' ; 'KPCMWG' ; 'DoD PKI TWG' ; '[e-mail]' ; 'Bridge CA Mail List' ; 'BCA Integration' ; * ALL FIREBURST USERS * ; 'Steve Capps' ; Wagner, Clark J. ; '[e-mail]' ; '[e-mail]' ; 'Steve Hanna (SUN)' ; 'Susan Dernik' 
Sent: Friday, April 06, 2001 16:48
Subject: DoD Bridge Certification Authority Phase II Demonstrations


For the last few years, the National Security Agency has led the development of Bridge Certification Authority (BCA) technology demonstrations.  In 1999, Phase One of the Department of Defense BCA Technology Demonstration showed the technical feasibility of achieving signed e-mail interoperability using multi-vendor cross-certification in conjunction with chained directory systems.
 
Phase Two of the demonstration is now ready to be shown.  Phase Two of the DoD Bridge CA Phase II Technology Demonstration includes: 
 
Technologies: 
  
--  Certificate chain building in complex certificate graphs; 
--  Integration of both mesh-style cross-certified PKIs and hierarchical PKIs; 
--  Multi-signature/hash algorithm processing in certificate chains; 
--  Certificate acceptance/rejection based on Certificate Policy processing, including policy mapping;
--  Transitive trust limitation using Name Constraints processing;
--  Access Control using X.509 compliant attribute certificates (same attribute certificates used for e-mail and web based access control);
--  E-mail access control using S/MIME V3 labeling;
--  E-mail encryption using public key certificates authenticated via a Bridge Certification Authority;
--  Border Directories;
--  Multivendor directory interoperation via X.500 chaining; and, 
--  Transparent sharing of certificate revocation information across several  PKIs using products of multiple PKI vendors.
 
Client Applications: 
  
--  Baltimore Technologies MailSecure enabled Microsoft Outlook 
--  Entrust Enabled Microsoft Outlook
--  Getronics S/MIME Freeware Library, Certificate Management Library, and Access Control Library enabled Qualcomm Eudora
--  Getronics Certificate Management Library and Access Control Library enabled Netscape Web Server 
  
Freeware Libraries: 
  
--  Cygnacom Certificate Path Development Library 
     <http://www.cygnacom.com/products/index.htm> 
--  Getronics S/MIME (Version 3) Freeware Library 
     <http://www.getronicsgov.com/hot/sfl_home.htm> 
--  Getronics Certificate Management Library 
     <http://www.getronicsgov.com/hot/cml_home.htm> 
-- Getronics Access Control Library 
          <http://www.getronicsgov.com/hot/acl_home.htm> 
CA vendor interoperability demonstrations: 
  
--  Baltimore Technologies
--  Entrust Technologies
--  Motorola
--  SPYRUS 
  
Directory Interoperability: 
--  Entrust ICL 
--  Entegrity Safepages Directory 
Demonstrations will be held at the following locations and dates (note that you MUST REGISTER to attend!  Registration information is provided below):
 
---------- 
CygnaCom 
Suite 100 West 
7927 Jones Branch Dr.
McLean, Virginia 
  
Directions to CygnaCom are located at:  <http://www.cygnacom.com/contact/directions.htm> 
  
26 April 2001 - 0900 
  
26 April 2001 - 1300 
  
16 May 2001 - 0900 
  
16 May 2001 - 1300 
  
--------- 
Getronics Government Solutions 
141 National Business Parkway, Suite 210 
Annapolis Junction, Maryland 
  
>From Washington DC: Take I-95 north; take MD Rt 32 east exit; take Dorsey 
Run exit; at stop sign turn left on Dorsey Run; at stop light turn right on 
Guilford Road which becomes National Business Pkwy. 
  
>From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit; stay 
in right lane of the exit which runs into National Business Pkwy; make a 
right on National Business Pkwy. 
  
30 April 2001 - 1300 
  
8 May 2001 - 0900 
  
8 May 2001 - 1300 
  
24 May 2001 - 0900 
  
24 May 2001 - 1300 
  
--------- 
  
All showings last about half a day - with a mixture of conference room briefings and laboratory demonstrations. 
  
We are limited by available demonstration space to an absolute maximum of 20 participants at each showing.  
  
IMPORTANT:  PLEASE REGISTER WITH LISA FAULKNER ([e-mail] <mailto:[e-mail]>) AND MYSELF ([e-mail] <mailto:[e-mail]>) IF YOU PLAN TO ATTEND.  IF YOU DO NOT REGISTER TO ATTEND, YOU WILL NOT BE ADMITTED TO THE DEMONSTRATION.
 
Please provide the following information to register: 
  
--  Name 
--  Organization 
--  E-mail address 
--  Date and time of the demonstration showing you wish to attend (with alternates, if possible) 
  
We look forward to seeing you at the demonstration! 
  
Dave Fillingham 
NSA 




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA17849 for <[e-mail]>; Mon, 9 Apr 2001 11:02:34 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA03226; Mon, 9 Apr 2001 14:02:06 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Mon, 09 Apr 2001 14:00:39 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: Bob Jueneman <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tony Bartoletti wrote:
> 
> (I feel as a moth drawn to a flame.)

How true - sigh :-(.


Bob Jueneman wrote:
>
> And given that scenario, I continue to believe that the currently
> ill-defined bit should be officially deprecated, and some other
> attributes defined as necessary with a great deal more precision.
> If ISO X.509 and/or the PKIX group refuses to deprecate the bit,
> then certainly the user community should.  IMHO, of course.

And I continue to believe you are correct.  NR should be deprecated,
and replaced with a new name for bit 0:  "Persistent Data
Authentication", which would have the property that was once
called "Technical NR".

As the HAK remark 13.48 says, 
  "A fundamental distinction exists between a party A being
  able to convince itself of the validity of a digital signature
  's' at a point in time t0, and that party being able to convince
  others at some time t1 >= t0 that 's' was valid at time t0."

It is reasonable for certificates to contain keys marked
for various cryptographic purposes, and "Persistent Data
Authentication" and "Entity Authentication" are two distinct
purposes suitable for being so marked.


Philip Hallam-Baker wrote:
> At the meeting the strongest statement that could be agreed upon
> concerning the non repudiation bit was:
>  
> 1) The setting of the non repudiation bit in the certificate was
>    a necessary but not sufficient condition for a relying party to
>    consider a signature to have the non-repudiation property.

Without delving too deeply (and this moth refuses to delve any
deeper), the "PDA" bit is not inconsistent with the ABA statement.


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13809 for <[e-mail]>; Mon, 9 Apr 2001 09:32:01 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA15251; Fri, 6 Apr 2001 10:45:59 -0400 (EDT)
Message-Id: <[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'KPCMWG'" <[e-mail]>, "'DoD PKI TWG'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Bridge CA Mail List'" <[e-mail]>, "'BCA Integration'" <[e-mail]>, * ALL FIREBURST USERS * <[e-mail]>, "'Steve Capps'" <[e-mail]>, "Wagner, Clark J." <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Steve Hanna (SUN)'" <[e-mail]>, "'Susan Dernik'" <[e-mail]>
Subject: DoD Bridge Certification Authority Phase II Demonstrations
Date: Fri, 6 Apr 2001 10:48:51 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;     boundary="------------InterScan_NT_MIME_Boundary"

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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0BEA8.B1B9C960"

------_=_NextPart_001_01C0BEA8.B1B9C960
Content-Type: text/plain;
	charset="ISO-8859-1"

For the last few years, the National Security Agency has led the development
of Bridge Certification Authority (BCA) technology demonstrations.  In 1999,
Phase One of the Department of Defense BCA Technology Demonstration showed
the technical feasibility of achieving signed e-mail interoperability using
multi-vendor cross-certification in conjunction with chained directory
systems.
 
Phase Two of the demonstration is now ready to be shown.  Phase Two of the
DoD Bridge CA Phase II Technology Demonstration includes: 
 
Technologies: 
 
--  Certificate chain building in complex certificate graphs;
--  Integration of both mesh-style cross-certified PKIs and hierarchical
PKIs;
--  Multi-signature/hash algorithm processing in certificate chains;
--  Certificate acceptance/rejection based on Certificate Policy processing,
including policy mapping;
--  Transitive trust limitation using Name Constraints processing;
--  Access Control using X.509 compliant attribute certificates (same
attribute certificates used for e-mail and web based access control);
--  E-mail access control using S/MIME V3 labeling;
--  E-mail encryption using public key certificates authenticated via a
Bridge Certification Authority;
--  Border Directories; 
--  Multivendor directory interoperation via X.500 chaining; and,
--  Transparent sharing of certificate revocation information across several
PKIs using products of multiple PKI vendors.
 
Client Applications: 
 
--  Baltimore Technologies MailSecure enabled Microsoft Outlook
--  Entrust Enabled Microsoft Outlook
--  Getronics S/MIME Freeware Library, Certificate Management Library, and
Access Control Library enabled Qualcomm Eudora
--  Getronics Certificate Management Library and Access Control Library
enabled Netscape Web Server
 
Freeware Libraries:
 
--  Cygnacom Certificate Path Development Library
     <http://www.cygnacom.com/products/index.htm>

--  Getronics S/MIME (Version 3) Freeware Library
     <http://www.getronicsgov.com/hot/sfl_home.htm>

--  Getronics Certificate Management Library
     <http://www.getronicsgov.com/hot/cml_home.htm>

-- Getronics Access Control Library
          <http://www.getronicsgov.com/hot/acl_home.htm>

CA vendor interoperability demonstrations: 
 
--  Baltimore Technologies 
--  Entrust Technologies
--  Motorola 
--  SPYRUS 
 
Directory Interoperability:

--  Entrust ICL
--  Entegrity Safepages Directory

Demonstrations will be held at the following locations and dates (note that
you MUST REGISTER to attend!  Registration information is provided below):
 
----------
CygnaCom
Suite 100 West
7927 Jones Branch Dr.
McLean, Virginia
 
Directions to CygnaCom are located at:
<http://www.cygnacom.com/contact/directions.htm> 
 
26 April 2001 - 0900
 
26 April 2001 - 1300
 
16 May 2001 - 0900
 
16 May 2001 - 1300
 
---------
Getronics Government Solutions
141 National Business Parkway, Suite 210
Annapolis Junction, Maryland
 
>From Washington DC: Take I-95 north; take MD Rt 32 east exit; take Dorsey
Run exit; at stop sign turn left on Dorsey Run; at stop light turn right on
Guilford Road which becomes National Business Pkwy. 
 
>From Baltimore: Take BW Parkway (295) south; take MD Rt 32 west exit; stay
in right lane of the exit which runs into National Business Pkwy; make a
right on National Business Pkwy.
 
30 April 2001 - 1300
 
8 May 2001 - 0900
 
8 May 2001 - 1300
 
24 May 2001 - 0900
 
24 May 2001 - 1300 
 
---------
 
All showings last about half a day - with a mixture of conference room
briefings and laboratory demonstrations.
 
We are limited by available demonstration space to an absolute maximum of 20
participants at each showing.  
 
IMPORTANT:  PLEASE REGISTER WITH LISA FAULKNER ([e-mail]
<mailto:[e-mail]>) AND MYSELF ([e-mail]
<mailto:[e-mail]>) IF YOU PLAN TO ATTEND.  IF YOU DO NOT
REGISTER TO ATTEND, YOU WILL NOT BE ADMITTED TO THE DEMONSTRATION.
 
Please provide the following information to register:
 
--  Name
--  Organization
--  E-mail address
--  Date and time of the demonstration showing you wish to attend (with
alternates, if possible)
 
We look forward to seeing you at the demonstration!
 
Dave Fillingham
NSA



------_=_NextPart_001_01C0BEA8.B1B9C960
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>DoD Bridge Certification Authority Phase II =
Demonstrations</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">For the last few years, the National =
Security Agency has led the development of Bridge Certification =
Authority (BCA) technology demonstrations.&nbsp; In 1999, Phase One of =
the Department of Defense BCA Technology Demonstration showed the =
technical feasibility of achieving signed e-mail interoperability using =
multi-vendor cross-certification in conjunction with chained directory =
systems.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Phase Two of the demonstration is now =
ready to be shown.&nbsp; Phase Two of the DoD Bridge CA Phase II =
Technology Demonstration includes: </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Technologies: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Certificate chain building =
in complex certificate graphs;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Integration of both =
mesh-style cross-certified PKIs and hierarchical PKIs;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Multi-signature/hash =
algorithm processing in certificate chains;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Certificate =
acceptance/rejection based on Certificate Policy processing, including =
policy mapping;<BR>
--&nbsp; Transitive trust limitation using Name Constraints =
processing;<BR>
--&nbsp; Access Control using X.509 compliant attribute certificates =
(same attribute certificates used for e-mail and web based access =
control);</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; E-mail access control using =
S/MIME V3 labeling;<BR>
--&nbsp; E-mail encryption using public key certificates authenticated =
via a Bridge Certification Authority;<BR>
--&nbsp; Border Directories;<BR>
--&nbsp; Multivendor directory interoperation via X.500 chaining; =
and,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Transparent sharing of =
certificate revocation information across several&nbsp; PKIs using =
products of multiple PKI vendors.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Client Applications: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Baltimore Technologies =
MailSecure enabled Microsoft Outlook</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Entrust Enabled Microsoft =
Outlook<BR>
--&nbsp; Getronics S/MIME Freeware Library, Certificate Management =
Library, and Access Control Library enabled Qualcomm Eudora<BR>
--&nbsp; Getronics Certificate Management Library and Access Control =
Library enabled Netscape Web Server</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Freeware Libraries:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Cygnacom Certificate Path =
Development Library</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.cygnacom.com/products/index.htm" =
TARGET=3D"_blank">http://www.cygnacom.com/products/index.htm</A>&gt;</FO=
NT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Getronics S/MIME (Version 3) =
Freeware Library</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/sfl_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/sfl_home.htm</A>&gt;</=
FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Getronics Certificate =
Management Library</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.getronicsgov.com/hot/cml_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/cml_home.htm</A>&gt;</=
FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- Getronics Access Control =
Library</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;<A HREF=3D"http://www.getronicsgov.com/hot/acl_home.htm" =
TARGET=3D"_blank">http://www.getronicsgov.com/hot/acl_home.htm</A>&gt;</=
FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">CA vendor interoperability =
demonstrations: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Baltimore Technologies<BR>
--&nbsp; Entrust Technologies<BR>
--&nbsp; Motorola<BR>
--&nbsp; SPYRUS </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Directory Interoperability:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Entrust ICL</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Entegrity Safepages =
Directory</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Demonstrations will be held at the =
following locations and dates (note that you MUST REGISTER to =
attend!&nbsp; Registration information is provided below):</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">----------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">CygnaCom</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Suite 100 West</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">7927 Jones Branch Dr.<BR>
McLean, Virginia</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Directions to CygnaCom are located =
at:&nbsp;<U> &lt;<A =
HREF=3D"http://www.cygnacom.com/contact/directions.htm" =
TARGET=3D"_blank">http://www.cygnacom.com/contact/directions.htm</A>&gt;=
</U> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">26 April 2001 - 0900</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">26 April 2001 - 1300</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">16 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">16 May 2001 - 1300</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">---------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Getronics Government Solutions</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">141 National Business Parkway, Suite =
210</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Annapolis Junction, Maryland</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From Washington DC: Take I-95 north; =
take MD Rt 32 east exit; take Dorsey</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Run exit; at stop sign turn left on =
Dorsey Run; at stop light turn right on</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Guilford Road which becomes National =
Business Pkwy. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From Baltimore: Take BW Parkway (295) =
south; take MD Rt 32 west exit; stay</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in right lane of the exit which runs =
into National Business Pkwy; make a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">right on National Business =
Pkwy.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">30 April 2001 - 1300</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">8 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">8 May 2001 - 1300</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">24 May 2001 - 0900</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">24 May 2001 - 1300 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">---------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">All showings last about half a day - =
with a mixture of conference room briefings and laboratory =
demonstrations.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">We are limited by available =
demonstration space to an absolute maximum of 20 participants at each =
showing.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">IMPORTANT:&nbsp; PLEASE REGISTER WITH =
LISA FAULKNER (</FONT><U><FONT SIZE=3D2 =
FACE=3D"Arial">[e-mail] &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
&gt;</FONT></U><FONT SIZE=3D2 FACE=3D"Arial">) AND MYSELF =
(</FONT><U><FONT SIZE=3D2 FACE=3D"Arial">[e-mail] &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
&gt;</FONT></U><FONT SIZE=3D2 FACE=3D"Arial">) IF YOU PLAN TO =
ATTEND.&nbsp; IF YOU DO NOT REGISTER TO ATTEND, YOU WILL NOT BE =
ADMITTED TO THE DEMONSTRATION.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Please provide the following =
information to register:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Name</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Organization</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; E-mail address</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--&nbsp; Date and time of the =
demonstration showing you wish to attend (with alternates, if =
possible)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">We look forward to seeing you at the =
demonstration!</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Dave Fillingham</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">NSA</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C0BEA8.B1B9C960--

--------------InterScan_NT_MIME_Boundary--


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA13074 for <[e-mail]>; Mon, 9 Apr 2001 03:50:13 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02550; Mon, 9 Apr 2001 06:50:13 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-14.txt
Date: Mon, 09 Apr 2001 06:50:12 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Time Stamp 
                          Protocols (TSP)
	Author(s)	: C. Adams, P. Cain, D. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-14.txt
	Pages		: 26
	Date		: 06-Apr-01
	
A time stamping service supports assertions of proof that a datum 
existed before a particular time. This document describes the format 
of a request sent to a Time Stamping Authority (TSA) and of the 
response that is returned. It also establishes several security-
relevant requirements for TSA operation, with regards to processing 
requests to generate responses. A TSA may be operated as a Trusted 
Third Party (TTP) service, though other operational models may be 
appropriate, e.g. an organization might require a TSA for internal 
time stamping purposes. 

Non-repudiation services [ISONR] require the ability to establish the 
existence of data before specified times. This protocol may be used as 
a building block to support such services. An example of how to prove 
that a digital signature was generated during the validity period of 
a public key certificate is given in an annex.

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

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-time-stamp-14.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA22377 for <[e-mail]>; Sun, 8 Apr 2001 21:47:33 -0700 (PDT)
Received: from [207.214.213.241] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Sun, 8 Apr 2001 21:47:25 -0700 (PDT)
Date: Sun, 08 Apr 2001 21:47:19 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Meaning of Non-repudiation
In-reply-to: <[e-mail]>
To: Bob Jueneman <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Bob Jueneman wrote:

> Alas, poor Dave, you have fallen into the black hole of PKI, from which there
> is no escape.
> 
> Having written several megabytes of e-mails on the subject over the last ten
> years or so, and having read countless more on this topic from others on this
> list and elsewhere, if you were merely some grad student trying to get a crib
> for a term paper, or if your company were one of the few remaining dot coms no
> one ever heard of, I would refer you to the archives, probably starting with
> Tom Ginden's RFC.  But you are not, and Identrus is at least potentially a
> very major player in this space, so you deserve a more extensive reply. Be
> careful what you ask for!

Dave should read the archives, specially since he is from Identrus.

> 
> The one sentence answer, IMHO, is that the NR bit in X.509 is neither
> necessary, nor sufficient, nor entirely useless;

I agree with most of what you wrote except, as I have previously stated, I
strongly believe the bit is useless. More below...

[snip]
> 
> So if the bit is neither necessary nor sufficient, is it completely useless?
> Maybe, but I believe that an argument could still be made for it, as a API
> signal to the originator's software.
> 
> What I would like to see the bit used for at this late date is to serve as a
> signal to the signing party's software that this certificate, and therefore
> the associated private key, is something special, and that particular care
> should be taken with it.  For example, it would be reasonable to use this as a
> signal within a smart card that the PIN or other identifier must be reentered
> every single time the private key is used,

The problem is that nothing prevents me (or any other person) from having
more than one certificate for my public key. So I can have one certificate
with NR and the other without NR.

> so that the system software can't
> sign two or more things after the key is unlocked.  The bit could also be used
> to bring up various dire warnings, cautioning the user to be really, really
> sure that he knows what he is doing, thereby confirming the user's conscious
> and willing intent.
> 
> Of course this same meaning could be applied to a bit in an attribute
> associated with the private key

I agree that this is where it belongs, but the few crypto APIs (partial
list: PKCS#11 and CDSA) that support private key attributes treat the
attributes as optional and don't define a specific NR attribute.

Regards,
Aram Perez

[snip]



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA29654 for <[e-mail]>; Sat, 7 Apr 2001 09:56:17 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Sat, 07 Apr 2001 10:55:48 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Sat, 07 Apr 2001 10:55:44 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_5F04A784.5E3F2BA8"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_5F04A784.5E3F2BA8
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Although I enjoyed Tony's tongue-in-cheek usage scenario, I'm not sure =
that I agree with his assumption that it is the issuing CA that is driving =
this -- I don't view this as being a CA-centric issue.  Yes, I agree that =
the CA COULD define the meaning of the bit in it's CPS and CP, but WILL =
they -- that is the question.  and if they do, is it enforceable against =
the CA, or only against the subscriber -- that is the issue.

In particular, I do NOT think that the NR bit says something very =
noteworthy about what the CA is going to do or not do. Instead, I believe =
the NR bit is exclusively saying something about the signing party's =
behavior.  It seems pretty unlikely that the CA (or some independent =
auditing group) is going to actually go out to the subscriber's premises =
and investigate their practices, not to mention intrusive.  And I don't =
think that the NR bit should be construed as implying something about how =
the CA is going to keep CRL records until infinity, etc.

So at best the NR bit is a representation made by the subscriber to the =
world via the CA.  In this case the CA is essentially acting as the =
trusted publisher of a Legal Notice in the paper.  The CA/publisher is not =
necessarily itself guaranteeing the correctness or truthfulness of the =
notice, only that it is printed verbatim as received from the subscriber.  =
Of course if the CA wants to get into the insurance business, or the =
notary business, or some other business that involves guaranteeing either =
the user's behavior or the particular transaction, that is a completely =
different matter, and one that I don't believe could or should be inferred =
from the NR bit.

So if the NR bit is a representation made by the subscriber, essentially =
in the form of a Legal Notice, then what specifically is being represented?=


Well, in an ideal world, the subscriber would have a Subscriber Usage =
Statement that would be similar to the Certification Practice Statement of =
a CA.  In one of the first implementations I did of PKI, back when I was =
with CSC, I included exactly that -- a set of representations as to what =
the subscriber would or would not agree to, digitally signed and made =
available as an Affidavit of Legal Mark.  Basically the Affidavit said "I =
am going to honor the herein described electronic process as though it =
were in every respect my legal mark or signature, subject to the following =
caveats and conditions."  If necessary, that affidavit could be printed =
and signed with a wet signature.

Of course if we could come to some reasonable agreement as to what a =
reasonable set of caveats and conditions might be -- not their values, =
just the semantic definitions -- then it would be possible codify those =
values in the certificate, as a representation made to the CA-as-publisher.=
  I've tried to do some of that in the Certificate Quality portion of =
Novell Security Attributes, but it just describes the technical conditions =
associated with the certificate -- key quality, class of user, etc. -- and =
not the conditions under which the subscriber would agree to be bound.  So =
there would be a lot more work required to implement such a concept in a =
way that wouldn't require reading a huge document along with every =
subscriber's signature.

>From this perspective, the thought of trying to condense all of that kind =
of information into a one-size-fits-all single bit, called nonRepudiation, =
would be truly laughable, if it weren't so naive and arrogant at the same =
time.

But to get back to the real world, I recently saw an very interesting =
device being made by Sony, the FIU-710 Fingerprint Identification Unit.  =
This isn't a plug for Sony -- other people may well make something =
similar, and their's might be better, cheaper, or just different -- I =
don't know.  I'm merely describing it for people who may not have seem =
something similar.

But the Sony unit is getting a lot closer to something that I think we =
need, and might be deserving of being represented with the NR bit.  =
According to the spec, the stand-alone unit is 54x85 mm and 9.5 mm thick. =
It plugs into a computer via a USB port or serial cable.  It has a =
fingerprint scanner capable of 1 second registration time and less than =
one second verification time, with the fingerprint recognition circuitry =
embedded in the device. The false acceptance rate is .008% or less, with a =
false rejection rate of 4% or less.

In addition the unit contains 512KB of user memory and is PKCS#11 =
compliant, able to generate and store up to 1024-bit RSA keys. It can also =
encrypt files with DES and triple-DES, and can store passwords lists, user =
profiles, and other data, and can support up to eight applications in one =
session.

According to a vendor (Saflink Corp.) that is marketing the device and =
their software as an authentication method for our NMAS authentication =
framework, the tamper-proof unit is supposed to be certified as FIPS 140-1 =
level three or better, some time in the next year, although I haven't seen =
that in writing anywhere.

The most important point, however, is that here is a tamper-proof device =
that is the equivalent of a smart card or a PCMCIA card in terms of its =
cryptographic capabilities, and in addition it has a biometric device =
built-in that is capable of locking the private keys so that they cannot =
be accessed without fingerprint identification.  Assuming all this is true =
and that the device has the necessary configuration flexibility to support =
this, this would go a very long way towards satisfying several elements =
that might reasonably be required for nonrepudiation, including biometric =
identification of the user for every NR signature operation.  Because I =
don't have a trusted display device, I still don't know that what was =
signed was really what I intended, but at least I can be certain that I =
only signed one thing, and that goes a long way.

I wouldn't go so far as what Tony suggests in terms of using it at a kiosk =
-- the unit may be tamper-proof, but that doesn't prevent the entire unit =
from being physically substituted, as in the "fake ATM" ploy.  But that =
unit, in combination with an operating system that was accredited at the =
C2 level of trust (and properly installed, which is harder), would go a =
long, long way in the desired direction.

To get back to Dave's question, though, at least we reach this nirvana =
state, I would suggest that he be very wary of generating or accepting a =
certificate that has his name on it in combination with the NR bit, =
because some judge somewhere might somehow come to the conclusion that the =
NR bit actually means something.  On the other hand, if I were a relying =
party I certainly wouldn't put much if any credence in a transaction that =
was verified against a certificate containing the NR bit, because some =
other judge might decide that the NR bit meant nothing at all.

And given that scenario, I continue to believe that the currently =
ill-defined bit should be officially deprecated, and some other attributes =
defined as necessary with a great deal more precision.  If ISO X.509 =
and/or the PKIX group refuses to deprecate the bit, then certainly the =
user community should.  IMHO, of course.

Regards,

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software



>>> Tony Bartoletti <[e-mail]> 04/06/01 06:24PM >>>
At 03:52 PM 4/6/01 -0600, Bob Jueneman wrote:
>Alas, poor Dave, you have fallen into the black hole of PKI, from =
which=20
>there is no escape.

Also Known As, the point of No Return (NR).

(I feel as a moth drawn to a flame.)

I think Bob has laid out the issues very nicely regarding the (lack of)=20
necessity, sufficiency, and (arguable) usefulness of the "NR" bit.

My feeling is that if the NR bit says anything at all, it is the issuing =
CA=20
that is speaking.  I cannot go to a (reputable) CA, and ask for a key to =
be=20
certified with any attributes of my choosing.  There is some understanding=
=20
(modulo CP/CPS) that the CA "stands behind" the attributes contained in =
the=20
certificates they issue, at least in terms of their having followed =
their=20
(self-defined) process.  (Beats me just what this is worth...).

The most I can hope is that, at some future point, the PKI Protocol =
Players=20
come to agree upon some common standard of certificate issuance processing=
=20
"guaranteed" by inclusion of the set NR bit.  Even then, it will be =
little=20
more than one more piece of evidence that may be provided in case of a =
dispute.

I have thought about how far one could really go, in making the NR-bit=20
stand for what folks naively expect it to be.  My "program" addresses =
both=20
issuance and usage.  (It may seem "humorous", but I wonder how far off =
this=20
will really be.)

Issuance of NR-bit Certificates:
--------------------------------

The NR-bit Certificate shall contain or reference:

1.  The CA-signed audio file of the certificate subject, reading aloud =
the=20
CA's CP/CPS verbatim, and correctly responding to several randomly =
selected=20
questions about this material.

2.  The CA-signed photograph of the certificate subject shaking hands =
with=20
the CA president under a banner that reads "Another Satisfied NR Customer".=


Usage of NR-bit Signature Keys:
-------------------------------

These keys will be contained in biometrically-sensitive key-cards that =
self=20
destruct under reasonable signs of tampering.

The keys/key-cards can be used in any of the "Signature Kiosks" that we=20
expect will replace the common "auto-teller" machines.  These kiosks =
will=20
be operated by the major banks, and serve as "secured web portals".  =
Users=20
will be able to insert their NR key-card to conduct transactions that =
would=20
otherwise require the presence of two witnesses and a roomful of lawyers.

Prior to reaching the "signature preparation phase" of a transaction, =
the=20
terms of agreement may be perused at the user's leisure.  To enter the=20
"signature preparation phase", the user must place their thumb, palm, =
or=20
otherwise previously-registered part of their warm body in full contact=20
with the key-card's "bio-read" surface, so that authentication and=20
biometric stress data can be recorded.  The user is then presented with =
5=20
randomly selected multiple-choice questions about the terms of the=20
transaction.  The user must answer all questions correctly in order to=20
proceed to the actual signature phase.

Note:  The card will refuse to unlock the contained NR-key if:

a.  Bio-authentication fails (fingerprint, DNA-read, etc).
b.  Excessive alcohol or other mind-altering elements are detected.
c.  Skin-galvanic properties detect undue psychological stress.

Once all of these simple measures are in place, you will be able to =
walk=20
down any city street, stop at a signature kiosk, withdraw some cash,=20
purchase some postage stamps, and close escrow on that house you've =
been=20
eyeing...

___tony___




Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900





--=_5F04A784.5E3F2BA8
Content-Type: text/plain
Content-Disposition: attachment; filename="Bob Jueneman.vcf"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Bob Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell Inc. -- the leading provider of Net services software;DS eBusiness Solutions
TEL;PREF;FAX:[phone]
EMAIL;WORK;PREF;NGW:[e-mail]
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;;Novell, Inc.\n1800 South Novell Place\n;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah  84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah  84606
X-GWUSERID:BJUENEMAN
END:VCARD

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell, Inc.;DS eBusiness Solutions
TEL;PREF;FAX:[phone]
EMAIL;WORK;PREF;NGW:[e-mail]
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah  84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah  84606
TEL;HOME:1-801-765-4378
TEL;CELL:1-801-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
X-GWUSERID:BJUENEMAN
END:VCARD


--=_5F04A784.5E3F2BA8--


Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA10409 for <[e-mail]>; Fri, 6 Apr 2001 17:20:53 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id RAA27215; Fri, 6 Apr 2001 17:20:26 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id RAA18141; Fri, 6 Apr 2001 17:20:26 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 06 Apr 2001 17:24:20 -0700
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Meaning of Non-repudiation
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 03:52 PM 4/6/01 -0600, Bob Jueneman wrote:
>Alas, poor Dave, you have fallen into the black hole of PKI, from which 
>there is no escape.

Also Known As, the point of No Return (NR).

(I feel as a moth drawn to a flame.)

I think Bob has laid out the issues very nicely regarding the (lack of) 
necessity, sufficiency, and (arguable) usefulness of the "NR" bit.

My feeling is that if the NR bit says anything at all, it is the issuing CA 
that is speaking.  I cannot go to a (reputable) CA, and ask for a key to be 
certified with any attributes of my choosing.  There is some understanding 
(modulo CP/CPS) that the CA "stands behind" the attributes contained in the 
certificates they issue, at least in terms of their having followed their 
(self-defined) process.  (Beats me just what this is worth...).

The most I can hope is that, at some future point, the PKI Protocol Players 
come to agree upon some common standard of certificate issuance processing 
"guaranteed" by inclusion of the set NR bit.  Even then, it will be little 
more than one more piece of evidence that may be provided in case of a dispute.

I have thought about how far one could really go, in making the NR-bit 
stand for what folks naively expect it to be.  My "program" addresses both 
issuance and usage.  (It may seem "humorous", but I wonder how far off this 
will really be.)

Issuance of NR-bit Certificates:
--------------------------------

The NR-bit Certificate shall contain or reference:

1.  The CA-signed audio file of the certificate subject, reading aloud the 
CA's CP/CPS verbatim, and correctly responding to several randomly selected 
questions about this material.

2.  The CA-signed photograph of the certificate subject shaking hands with 
the CA president under a banner that reads "Another Satisfied NR Customer".

Usage of NR-bit Signature Keys:
-------------------------------

These keys will be contained in biometrically-sensitive key-cards that self 
destruct under reasonable signs of tampering.

The keys/key-cards can be used in any of the "Signature Kiosks" that we 
expect will replace the common "auto-teller" machines.  These kiosks will 
be operated by the major banks, and serve as "secured web portals".  Users 
will be able to insert their NR key-card to conduct transactions that would 
otherwise require the presence of two witnesses and a roomful of lawyers.

Prior to reaching the "signature preparation phase" of a transaction, the 
terms of agreement may be perused at the user's leisure.  To enter the 
"signature preparation phase", the user must place their thumb, palm, or 
otherwise previously-registered part of their warm body in full contact 
with the key-card's "bio-read" surface, so that authentication and 
biometric stress data can be recorded.  The user is then presented with 5 
randomly selected multiple-choice questions about the terms of the 
transaction.  The user must answer all questions correctly in order to 
proceed to the actual signature phase.

Note:  The card will refuse to unlock the contained NR-key if:

a.  Bio-authentication fails (fingerprint, DNA-read, etc).
b.  Excessive alcohol or other mind-altering elements are detected.
c.  Skin-galvanic properties detect undue psychological stress.

Once all of these simple measures are in place, you will be able to walk 
down any city street, stop at a signature kiosk, withdraw some cash, 
purchase some postage stamps, and close escrow on that house you've been 
eyeing...

___tony___




Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA01988 for <[e-mail]>; Fri, 6 Apr 2001 14:53:00 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 06 Apr 2001 15:52:09 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Fri, 06 Apr 2001 15:52:01 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA01990

Alas, poor Dave, you have fallen into the black hole of PKI, from which there is no escape.

Having written several megabytes of e-mails on the subject over the last ten years or so, and having read countless more on this topic from others on this list and elsewhere, if you were merely some grad student trying to get a crib for a term paper, or if your company were one of the few remaining dot coms no one ever heard of, I would refer you to the archives, probably starting with Tom Ginden's RFC.  But you are not, and Identrus is at least potentially a very major player in this space, so you deserve a more extensive reply. Be careful what you ask for!

The one sentence answer, IMHO, is that the NR bit in X.509 is neither necessary, nor sufficient, nor entirely useless; nor is any given set of proposed semantics agreed upon by any particular group of lawyers, technologists, or relying parties. -- at least if the number of people in the group exceeds three.  As you may have noticed, the 2459 definition of NR is very nearly circular, except for the fact that "non-repudiation service" is not defined or agreed to by anyone, at least in any meaningful sense.

Why do I say that the NR bit is not necessary?  Because, at least in the US, the marvelously muddled eSign legislation says that parties can agree to just about anything, probably including smoke signals, as a legally binding signature if they choose to do so.  On the other hand, absent such an agreement in advance, there is no clear standard as to what is or should be required to make a digital signature legally binding. and enforceable.

OK, why is the bit not sufficient?  That's even clearer.  Despite what technologists might think there is (almost) no such thing as nonrepudiation, as your legal counsel has undoubtedly already advised you.  Physical duress, fraud, incompetence, lack of authority or agency, illegality of the act -- all these things and more are examples of why any agreement, signed or not, can be repudiated or made invalid.  Now with respect to a digital signature itself, there are a number of other defenses that might be possible, including the lack of knowledge that anything was being signed at all (a malevolent program was executed which caused some thing to be signed that the user was not aware of); insufficient protection given to a key that was not intended for important legal matters, allowing the key to be compromised; incorrect binding of a name to a key (that's my name, but that's not my key) by the CA; lack of archived CRL or OCSP checking by the relying party, making it impossible to prove that the signature was ostensibly valid at the time of issuance.

So if the bit is neither necessary nor sufficient, is it completely useless?  Maybe, but I believe that an argument could still be made for it, as a API signal to the originator's software.

What I would like to see the bit used for at this late date is to serve as a signal to the signing party's software that this certificate, and therefore the associated private key, is something special, and that particular care should be taken with it.  For example, it would be reasonable to use this as a signal within a smart card that the PIN or other identifier must be reentered every single time the private key is used, so that the system software can't sign two or more things after the key is unlocked.  The bit could also be used to bring up various dire warnings, cautioning the user to be really, really sure that he knows what he is doing, thereby confirming the user's conscious and willing intent.

Of course this same meaning could be applied to a bit in an attribute associated with the private key -- it wouldn't have to appear in the certificate.  But if such a use for the NR bit were to become widespread, it would at least serve some useful purpose, as it would help to rebut the argument "but I didn't know I was signing anything at all, much less something this important."

Now there are some people whom I respect that would argue that nothing is going to be settled in this area until some legal ruling is upheld with respect to the matter.  My general feeling, however, is "God forbid!"

I'm sure you're aware of the saying "hard cases make bad law."  The only thing that I can imagine that would be worse than the demonstrated impossibility of having to educate entire House and Senate, plus their respective staffs, about PKI would be the prospect of some randomly chosen plaintiff's attorney and some other randomly chosen defense attorney arguing the fine points of PKI in front of a clueless judge and an equally clueless jury, and having the outcome of that process end up setting a national precedent.  Ouch!

What we need in this environment is the equivalent of the Generally Accepted Accounting Principles, which are rules adopted by accountants and auditors on behalf of the people who pay them to make sure that some company isn't playing fast and loose with the facts.  We don't necessarily need a law, or a definitive court case -- we just need a sufficient strong set of customers who can step up and say "do it this way, or we aren't going to believe you" and make it stick.

So far, no constituency has developed that has that amount of clout, and both the legal and the technical community have sort of agreed to duck the issue for now.  SSL, for which  perhaps 97% of all certificates have issued, doesn't sign documents, and the use within the S/MIME community has so far been quite slow to pick up. 

Perhaps Identrus and their community of interest will eventually be able to marshal that amount of clout and make it stick -- I rather hope so. But I am afraid that if you look to the existing stakeholders for a definitive agreement, you are going to be waiting a long, long time.

Regards,

Bob

>I am trying to clarify the meaning of non-repudiation (as defined by the
>technology standards) for our legal counsel. 2459 says this about
>non-repudiation:
>     The nonRepudiation bit is asserted when the subject public key is
>      used to verify digital signatures used to provide a non-
>      repudiation service which protects against the signing entity
>      falsely denying some action, excluding certificate or CRL signing.
>
>The question is what does "some action" mean? Is the action merely signing
>the transaction? Or, is the action perhaps committing to the terms described
>in the signed transaction?
>
>To rephrase: Is non-repudiation stating simply that I, Dave Oshman, signed
>this document? Or, is it supposed to mean that I, Dave Oshman, attest that I
>am committing myself (or my company) to the terms described herein?
>
>Is this more clearly defined in X.813 (ITU-T Recommendation X.8131) |
>ISO/IEC 10181-3:...1), Information technology - Open Systems Interconnection
>- Security Frameworks in Open Systems - Non-repudiation framework)? Can
>anyone snip a description of non-repudiation from X.813?
>Thanks!
>Dave Oshman 
>Senior Vice President 
>Technology 
>Identrus LLC



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA20713 for <[e-mail]>; Fri, 6 Apr 2001 12:09:45 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 6 Apr 2001 12:09:41 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 06 Apr 2001 12:09:41 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26NZRH>; Fri, 06 Apr 2001 12:09:06 -0700
Content-return: allowed
Date: Fri, 06 Apr 2001 12:09:04 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Meaning of Non-repudiation
To: "'Philip Hallam-Baker'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Phillip,

This is intended as a pleasant message, before the PKI movement's
annual festival during which we can analyse the previous
year's concrete accomplishments and look forward
to enhancing privacy in email:

A valid implication of your expert group's statement is: that the IESG was 
wrong to have passed RFC 1421/1422, which seemed to claim to standardize a
mechanism for providing a proof of origin with non-repudiation service. IESG
was 
wrong as there was no NR bit in the certificate of the day, and, therefore,
the 1421/1422 mechanism for providing the claimed service was not adequate.

As this implication seems very far fetched indeed (as IESG
are infallible) it makes me doubt the validity of the expert group's very 
proper assertion. Lets try to find  evidence for the contrary 
position - which would support IESG decisions:

"Certificates are used in PEM to provide the originator of a
   message with the (authenticated) public component of each recipient
   and to provide each recipient with the (authenticated) public
   component of the originator.  " [RFC 1422]

"Authentication, integrity, and (when
   asymmetric key management is employed) non-repudiation of origin
   services are applied to all PEM messages; confidentiality services
   are optionally selectable." [ RFC 1421]


By focusing on authenticated public component, 1421/1422 removes from the
notion
of verification of digital signatures any requirement to consider
certificates. 
The phrase "Asymmetric key management" is declared to be the (only)
condition 
for provision of the non-repudiation with origin service. Indeed, 1422 never

mentions the term "repudiation": the architecture provides only for the 
distribution of authenticated public components.  Indeed, 1422 makes no
claim 
to support the non-repudiation of origin service declared in 1421. It goes
out 
of its way to limit its support to data origin authentication.
In summary, the "Certificate-based key distribution" specification of 1422 
does not claim to be "Asymmetric key management". By inference, 1422 support

for 1421 does not provide for non-repudiation of origin. Also by inference, 
certificates alone are not sufficient for non-repudiation - assuming 1422's 
avoidance of listing support for 1421's non-repudiation of origin service
was 
deliberate.

RFC 1422 apparently contrasts with RFC 3039, which introduces a
format-profile 
of certs that specifically claims to support an identification service,
suitable 
for a public non-repudiation service. But again, we note, 3039 does not
claim 
that certificates are necessary for non-repudiation - only, that conforming 
certificate schemes provide for the necessary assurance for the
"identification 
facility" used in providing a non-repudiation service. In this, 3038 is
compatible 
with 1422, in that certificate-assured identification is a common element
for both
the data origin authentication facility that 1422 does list as supporting,
and  
the "public" non-repudiation service that 3038 supports.

Other PKIX documents introduce bizzare, non-normative notions that we should
probably ignore: "Users of public key-based systems must be confident that, 
any time they rely on a public key, the subject that they are communicating
with owns the associated private key [...]" in case anyone claims that
PKIX is self-contradictory. This quote from a PKIX theory I-D introduces
the strange idea of "relying on" public keys, and introduces a (legal) 
contingency concerning  "ownership". Though strange, it is interesting to 
note the compatibility of the PKIX theory with 1422, in its focus on public
keys 
rather than certificates.

In conclusion, I can view the RFC/ID evidence as supporting either position
- for 
or against the experts statement that certificates and a given signal are
necessary 
for non-repudiation. PKIX and historical IETF PKI standards-track works are
apparently
very carefully worded to offer NO support for a formal claim of providing 
non-repudiation on the basis that (a) certificates are used and/or (b) that 
particular certificate processing is used. Bringing the issue uptodate for
the 
NR-relevant protocols that Internet subscribers use, we note that S/MIME v2 
has a largely PEM compatible model: non-repudiation of origin is a result of
"using 
digital signatures." To test the experts groups assertion seems to depend
upon 
the definition of a digital signature.   And on that there 
seems to be NO consensus in the statutory (legal) world we live in on 
the matter of any *necessary* relationship to certificates - as another
essay on
the definitions used in a statute to which IESG refers might show.

Peter.

 -----Original Message-----
From: Philip Hallam-Baker [mailto:[e-mail]]
Sent: Friday, April 06, 2001 9:09 AM
To: [e-mail]
Subject: RE: Meaning of Non-repudiation


I am confused here. Last washington IETF myself, Russ, Denis and Tim were
taken in a black limosine off to a meeting of the joint ABA-New world order
PKI working group being chaired by Michael Baum. We had a six hour dicussion
of the non repudiation bit puctuated only by the stream of liveried servants
dishing out foie gras, oysters and caviar to the lawyers. At the end of the
meeting Tim recieved a signed and sealed statement from Michael himself
stating that we did not need to discuss the topic ever again. I hope that
Tim has not lost the statement.

At the meeting the strongest statement that could be agreed upon concerning
the non repudiation bit was:

1) The setting of the non repudiation bit in the certificate was a necessary
but not sufficient condition for a relying party to consider a signature to
have the non-repudiation property.


Beyond that there was considerable dispute as to the legal and technical
issues. I believe that the utility of the bit is limited to identifying keys
which are considered (for whatever reason) repudiable. Beyond that
non-repudiation is not a binary quality, there will always be degrees of
repudiation contol and the degree of control provided in a specific
circumstance is ultimately determined by the CP and CPS. Trying to condense
that down to a single bit is futile.

There is a utility in leaving the non-repudiation bit clear in a certificate
for a cable modem, 802.11b card, SSL server or the like.

Unfortunately the people who are most concerned about the bit tend to want
it for an affirmation that non-repudiation services be provided.

One solution would be to call it the 'repudiation bit' and state that when
clear repudiability was asserted.

        Phill
Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
[e-mail]
781 245 6996 x227


Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA17497 for <[e-mail]>; Fri, 6 Apr 2001 11:14:59 -0700 (PDT)
Received: from barth ([12.82.138.241]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010406181428.IQMZ18668.mtiwmhc22.worldnet.att.net@barth>; Fri, 6 Apr 2001 18:14:28 +0000
From: "Dr. JohnDavid Hascup" <[e-mail]>
To: "Philip Hallam-Baker" <[e-mail]>, <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 6 Apr 2001 11:13:46 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C0BE8A.A5EB4F00"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

This is a multi-part message in MIME format.

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

Meaning of Non-repudiationThanks Phil, I do remember there being that
discussion in DC and also much more prior on the list. I just remember that
it seemed the lawyers wanted it their way and that the bit would be
insufficent in-and-of-itself for their usage.

If my message caused a misunderstanding beyond that, mea culpa.

JohnDavid

  -----Original Message-----
  From: Philip Hallam-Baker [mailto:[e-mail]]
  Sent: Friday, April 06, 2001 9:09 AM
  To: [e-mail]
  Subject: RE: Meaning of Non-repudiation


  I am confused here. Last washington IETF myself, Russ, Denis and Tim were
taken in a black limosine off to a meeting of the joint ABA-New world order
PKI working group being chaired by Michael Baum. We had a six hour dicussion
of the non repudiation bit puctuated only by the stream of liveried servants
dishing out foie gras, oysters and caviar to the lawyers. At the end of the
meeting Tim recieved a signed and sealed statement from Michael himself
stating that we did not need to discuss the topic ever again. I hope that
Tim has not lost the statement.

  At the meeting the strongest statement that could be agreed upon
concerning the non repudiation bit was:

  1) The setting of the non repudiation bit in the certificate was a
necessary but not sufficient condition for a relying party to consider a
signature to have the non-repudiation property.


  Beyond that there was considerable dispute as to the legal and technical
issues. I believe that the utility of the bit is limited to identifying keys
which are considered (for whatever reason) repudiable. Beyond that
non-repudiation is not a binary quality, there will always be degrees of
repudiation contol and the degree of control provided in a specific
circumstance is ultimately determined by the CP and CPS. Trying to condense
that down to a single bit is futile.

  There is a utility in leaving the non-repudiation bit clear in a
certificate for a cable modem, 802.11b card, SSL server or the like.

  Unfortunately the people who are most concerned about the bit tend to want
it for an affirmation that non-repudiation services be provided.

  One solution would be to call it the 'repudiation bit' and state that when
clear repudiability was asserted.

          Phill
  Phillip Hallam-Baker
  Principal Scientist
  VeriSign Inc.
  [e-mail]
  781 245 6996 x227

  Dr. JohnDavid Hascup
  Senior Security Architect
  ELF Technologies




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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>Meaning of =
Non-repudiation</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"cid:[e-mail]4D0ED0" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@font-face {
	font-family: Comic Sans MS;
}
@font-face {
	font-family: Tahoma;
}
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
H1 {
	FONT-WEIGHT: bold; FONT-SIZE: 16pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: =
Arial; mso-pagination: widow-orphan; mso-style-next: Normal; =
mso-outline-level: 1; mso-font-kerning: 16.0pt
}
P.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
SPAN.EmailStyle16 {
	COLOR: navy; mso-style-type: personal-reply; mso-ansi-font-size: =
12.0pt; mso-ascii-font-family: "Comic Sans MS"; mso-hansi-font-family: =
"Comic Sans MS"; mso-bidi-font-family: Arial
}
P.Heading1NoTOC {
	FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: =
Arial; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-family: "Times New Roman"; mso-style-name: "Heading 1 No =
TOC"; mso-bidi-font-size: 10.0pt; mso-bidi-font-weight: normal
}
LI.Heading1NoTOC {
	FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: =
Arial; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-family: "Times New Roman"; mso-style-name: "Heading 1 No =
TOC"; mso-bidi-font-size: 10.0pt; mso-bidi-font-weight: normal
}
DIV.Heading1NoTOC {
	FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: =
Arial; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-family: "Times New Roman"; mso-style-name: "Heading 1 No =
TOC"; mso-bidi-font-size: 10.0pt; mso-bidi-font-weight: normal
}
P.TableText {
	FONT-SIZE: 10pt; MARGIN: 3pt 0in; LINE-HEIGHT: 110%; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
LI.TableText {
	FONT-SIZE: 10pt; MARGIN: 3pt 0in; LINE-HEIGHT: 110%; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
DIV.TableText {
	FONT-SIZE: 10pt; MARGIN: 3pt 0in; LINE-HEIGHT: 110%; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: .5in">
<DIV><SPAN class=3D050370718-06042001><FONT face=3DArial color=3D#0000ff =
size=3D2>Thanks=20
Phil, I do remember there being that discussion in DC and also much more =
prior=20
on the list. I just remember that it seemed the lawyers wanted it their =
way and=20
that the bit would be insufficent in-and-of-itself for their=20
usage.</FONT></SPAN></DIV>
<DIV><SPAN class=3D050370718-06042001><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D050370718-06042001><FONT face=3DArial color=3D#0000ff =
size=3D2>If my=20
message caused a misunderstanding beyond that,&nbsp;mea=20
culpa.</FONT></SPAN></DIV>
<DIV><SPAN class=3D050370718-06042001></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D050370718-06042001><FONT face=3DArial color=3D#0000ff =

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

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Philip =
Hallam-Baker=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April 06, 2001 =
9:09=20
  AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> RE: Meaning of=20
  Non-repudiation<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D677224615-06042001>I am=20
  confused here. Last washington IETF myself, Russ, Denis and Tim were =
taken in=20
  a black limosine off to a meeting of the joint ABA-New world order PKI =
working=20
  group being chaired by Michael Baum. We had a six hour dicussion of =
the non=20
  repudiation bit puctuated only by the&nbsp;stream of liveried servants =
dishing=20
  out foie gras, oysters and caviar to the lawyers.&nbsp;At the end =
of&nbsp;the=20
  meeting Tim recieved a signed and sealed&nbsp;statement from Michael =
himself=20
  stating that we did not need to discuss the topic ever again. I hope =
that Tim=20
  has not lost the statement.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D677224615-06042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D677224615-06042001>At=20
  the meeting the strongest statement that could be agreed upon =
concerning the=20
  non repudiation bit was:</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D677224615-06042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D677224615-06042001>1)=20
  The setting of the non repudiation bit in the certificate was a =
necessary but=20
  not sufficient condition for a relying party to consider a signature=20
  to&nbsp;have the non-repudiation property.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D677224615-06042001>Beyond that there was considerable dispute =
as to the=20
  legal and technical issues. I believe that the utility of the bit is =
limited=20
  to identifying keys which are considered (for whatever reason) =
repudiable.=20
  Beyond that non-repudiation is not a binary quality, there will always =
be=20
  degrees of repudiation contol and the degree of control provided in a =
specific=20
  circumstance&nbsp;is ultimately determined by the CP and CPS. Trying =
to=20
  condense that down to a single bit is futile.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D677224615-06042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D677224615-06042001>There is a utility in leaving the =
non-repudiation bit=20
  clear in a certificate for a cable modem, 802.11b card, SSL server or =
the=20
  like.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D677224615-06042001>Unfortunately the people who are most =
concerned about=20
  the bit tend to want it for an affirmation that non-repudiation =
services be=20
  provided.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D677224615-06042001>One=20
  solution would be to call it the 'repudiation bit' and state that when =
clear=20
  repudiability was asserted.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D677224615-06042001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Phill</SPAN></FONT></DIV>
  <P><FONT size=3D2>Phillip Hallam-Baker<BR>Principal =
Scientist<BR>VeriSign=20
  Inc.<BR>[e-mail]<BR>781 245 6996 x227<BR><BR><SPAN=20
  class=3D050370718-06042001><FONT face=3DArial color=3D#0000ff>Dr. =
JohnDavid=20
  Hascup<BR>Senior Security Architect<BR>ELF=20
  Technologies</FONT></SPAN></FONT></P>
  <P><FONT size=3D2><SPAN class=3D050370718-06042001><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;&nbsp;</FONT></SPAN></FONT><![if =
!supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0038_01C0BE8A.A5EB4F00--



Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA15289 for <[e-mail]>; Fri, 6 Apr 2001 10:32:05 -0700 (PDT)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA15196; Fri, 6 Apr 2001 10:23:55 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <HQK2RHZQ>; Fri, 6 Apr 2001 10:29:45 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Carlin Covey'" <[e-mail]>, [e-mail]
Subject: RE: Meaning of Non-repudiation
Date: Fri, 6 Apr 2001 10:29:14 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0BEBF.19D82300"

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

------_=_NextPart_000_01C0BEBF.19D82300
Content-Type: text/plain;
	charset="iso-8859-1"


> From: Carlin Covey [mailto:[e-mail]]

> Philip Hallam-Baker wrote
>       "... We had a six hour discussion of the 
> non-repudiation bit ....
>       At the end of the meeting Tim received a signed and 
> sealed statement
>       from Michael [Baum] himself stating that we did not 
> need to discuss
>       the topic ever again.  ..."
> 
> Was the non-repudiation bit set in the certificate used to sign that
> statement?

Damn! You are right!

If the lawyers want to discuss the issue again they are going to have to
share the foix gras and caviar this time and not keep it to themselves!


Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
[e-mail]
781 245 6996 x227


------_=_NextPart_000_01C0BEBF.19D82300
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C0BEBF.19D82300--


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13302 for <[e-mail]>; Fri, 6 Apr 2001 09:34:00 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA34502 for <[e-mail]>; Fri, 6 Apr 2001 18:33:24 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA18000 for <[e-mail]>; Fri, 6 Apr 2001 18:33:26 +0200
Message-ID: <[e-mail]>
Date: Fri, 06 Apr 2001 18:33:26 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Changes to the TSP document
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The TSP document has got an extensive review at the IESG level.

In particular Marcus Leech on March 08, noticed the typo that had been
advertised on the PKIX mailing list by Bernd Matthes from Celo 
Communications GmbH on January, 23. 

"4. A client application using application using only a nonce ..."

This proves that the document has been carefully read by the IESG members.

Once upon a time I was joking that an obvious error should be left in every
document to make sure that it had been read. :-)

Other comments came from the IESG about some changes in Annexes E and F.

It has been requested to change the wording of the reference to son-of-2459
in APPENDIX E: Access descriptors for timeStamping. 

[This annex describes an extension based on the SIA extension that 
will be defined in the "son-of-RFC2459". Since at the time of 
publication of this document, "son-of-RFC2459" is not yet available, 
its description is placed in an informative annex. This annex will 
become normative, when this document will move from Proposed Standard 
to Standard.] 

Proposed change: 

" The contents of this annex will eventually become incorporated into 
the son-of-RFC2459 document, at which time this annex will no longer 
be needed. A future version of this document will likely omit this 
annex and refer to son-of-RFC2459 directly." 

In annex F, although there are MIME registration templates, they were not
clearly in an IANA considerations section. The header has been added, as 
well as some additional text.

Although these changes could have been made during the 48 hours notice time
before the document is posted by the IETF editor, I have produced a new
version that incorporates all the changes that have been requested up to
now. This new version has been posted to the web editor and should be
published soon.

I have also clarified one sentence in the introduction section, reusing the
first sentence from the abstract: "A time stamping service supports
assertions of proof that a datum existed *before* a particular time." 

Old sentence:

The TSA's role is to time stamp a datum to establish evidence 
indicating the time *at* which the datum existed.  

New sentence:

The TSA's role is to time stamp a datum to establish evidence 
indicating that a datum existed *before* a particular time.

I do hope that this will be the last version before the document 
is finally transformed into an RFC.

Denis 

TSP lead editor.


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA12379 for <[e-mail]>; Fri, 6 Apr 2001 09:21:55 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2LAWZDS0; Fri, 6 Apr 2001 09:17:57 -0700
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 6 Apr 2001 09:18:53 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Philip Hallam-Baker wrote
      "... We had a six hour discussion of the non-repudiation bit ....
      At the end of the meeting Tim received a signed and sealed statement
      from Michael [Baum] himself stating that we did not need to discuss
      the topic ever again.  ..."

Was the non-repudiation bit set in the certificate used to sign that
statement?




Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA11479 for <[e-mail]>; Fri, 6 Apr 2001 09:10:59 -0700 (PDT)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id JAA10501 for <[e-mail]>; Fri, 6 Apr 2001 09:03:16 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <HQK2RGLH>; Fri, 6 Apr 2001 09:09:06 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: [e-mail]
Subject: RE: Meaning of Non-repudiation
Date: Fri, 6 Apr 2001 09:08:35 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0BEB3.D54BC530"

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

------_=_NextPart_000_01C0BEB3.D54BC530
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0BEB3.D54BC530"


------_=_NextPart_001_01C0BEB3.D54BC530
Content-Type: text/plain;
	charset="iso-8859-1"

I am confused here. Last washington IETF myself, Russ, Denis and Tim were
taken in a black limosine off to a meeting of the joint ABA-New world order
PKI working group being chaired by Michael Baum. We had a six hour dicussion
of the non repudiation bit puctuated only by the stream of liveried servants
dishing out foie gras, oysters and caviar to the lawyers. At the end of the
meeting Tim recieved a signed and sealed statement from Michael himself
stating that we did not need to discuss the topic ever again. I hope that
Tim has not lost the statement.
 
At the meeting the strongest statement that could be agreed upon concerning
the non repudiation bit was:
 
1) The setting of the non repudiation bit in the certificate was a necessary
but not sufficient condition for a relying party to consider a signature to
have the non-repudiation property.
 
 
Beyond that there was considerable dispute as to the legal and technical
issues. I believe that the utility of the bit is limited to identifying keys
which are considered (for whatever reason) repudiable. Beyond that
non-repudiation is not a binary quality, there will always be degrees of
repudiation contol and the degree of control provided in a specific
circumstance is ultimately determined by the CP and CPS. Trying to condense
that down to a single bit is futile.
 
There is a utility in leaving the non-repudiation bit clear in a certificate
for a cable modem, 802.11b card, SSL server or the like.
 
Unfortunately the people who are most concerned about the bit tend to want
it for an affirmation that non-repudiation services be provided.
 
One solution would be to call it the 'repudiation bit' and state that when
clear repudiability was asserted.
 
        Phill
Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
[e-mail]
781 245 6996 x227


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Meaning of Non-repudiation</TITLE>

<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"cid:[e-mail]4D0ED0" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@font-face {
	font-family: Comic Sans MS;
}
@font-face {
	font-family: Tahoma;
}
P.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
H1 {
	FONT-FAMILY: Arial; FONT-SIZE: 16pt; FONT-WEIGHT: bold; MARGIN: 12pt =
0in 3pt; mso-pagination: widow-orphan; mso-style-next: Normal; =
mso-outline-level: 1; mso-font-kerning: 16.0pt
}
P.MsoAutoSig {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
LI.MsoAutoSig {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
DIV.MsoAutoSig {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
P {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN-LEFT: 0in; =
MARGIN-RIGHT: 0in; mso-margin-top-alt: auto; mso-margin-bottom-alt: =
auto; mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
SPAN.EmailStyle16 {
	COLOR: navy; mso-style-type: personal-reply; mso-ansi-font-size: =
12.0pt; mso-ascii-font-family: "Comic Sans MS"; mso-hansi-font-family: =
"Comic Sans MS"; mso-bidi-font-family: Arial
}
P.Heading1NoTOC {
	FONT-FAMILY: Arial; FONT-SIZE: 14pt; FONT-WEIGHT: bold; MARGIN: 12pt =
0in 3pt; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-family: "Times New Roman"; mso-style-name: "Heading 1 No =
TOC"; mso-bidi-font-size: 10.0pt; mso-bidi-font-weight: normal
}
LI.Heading1NoTOC {
	FONT-FAMILY: Arial; FONT-SIZE: 14pt; FONT-WEIGHT: bold; MARGIN: 12pt =
0in 3pt; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-family: "Times New Roman"; mso-style-name: "Heading 1 No =
TOC"; mso-bidi-font-size: 10.0pt; mso-bidi-font-weight: normal
}
DIV.Heading1NoTOC {
	FONT-FAMILY: Arial; FONT-SIZE: 14pt; FONT-WEIGHT: bold; MARGIN: 12pt =
0in 3pt; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-family: "Times New Roman"; mso-style-name: "Heading 1 No =
TOC"; mso-bidi-font-size: 10.0pt; mso-bidi-font-weight: normal
}
P.TableText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 10pt; LINE-HEIGHT: 110%; =
MARGIN: 3pt 0in; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
LI.TableText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 10pt; LINE-HEIGHT: 110%; =
MARGIN: 3pt 0in; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
DIV.TableText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 10pt; LINE-HEIGHT: 110%; =
MARGIN: 3pt 0in; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: .5in">
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D677224615-06042001>I am=20
confused here. Last washington IETF myself, Russ, Denis and Tim were =
taken in a=20
black limosine off to a meeting of the joint ABA-New world order PKI =
working=20
group being chaired by Michael Baum. We had a six hour dicussion of the =
non=20
repudiation bit puctuated only by the&nbsp;stream of liveried servants =
dishing=20
out foie gras, oysters and caviar to the lawyers.&nbsp;At the end =
of&nbsp;the=20
meeting Tim recieved a signed and sealed&nbsp;statement from Michael =
himself=20
stating that we did not need to discuss the topic ever again. I hope =
that Tim=20
has not lost the statement.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D677224615-06042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D677224615-06042001>At the=20
meeting the strongest statement that could be agreed upon concerning =
the non=20
repudiation bit was:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D677224615-06042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D677224615-06042001>1) The=20
setting of the non repudiation bit in the certificate was a necessary =
but not=20
sufficient condition for a relying party to consider a signature =
to&nbsp;have=20
the non-repudiation property.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D677224615-06042001>Beyond=20
that there was considerable dispute as to the legal and technical =
issues. I=20
believe that the utility of the bit is limited to identifying keys =
which are=20
considered (for whatever reason) repudiable. Beyond that =
non-repudiation is not=20
a binary quality, there will always be degrees of repudiation contol =
and the=20
degree of control provided in a specific circumstance&nbsp;is =
ultimately=20
determined by the CP and CPS. Trying to condense that down to a single =
bit is=20
futile.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D677224615-06042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D677224615-06042001>There=20
is a utility in leaving the non-repudiation bit clear in a certificate =
for a=20
cable modem, 802.11b card, SSL server or the like.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D677224615-06042001>Unfortunately the people who are most =
concerned about=20
the bit tend to want it for an affirmation that non-repudiation =
services be=20
provided.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D677224615-06042001>One=20
solution would be to call it the 'repudiation bit' and state that when =
clear=20
repudiability was asserted.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D677224615-06042001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Phill</SPAN></FONT></DIV>
<P><FONT size=3D2>Phillip Hallam-Baker<BR>Principal =
Scientist<BR>VeriSign=20
Inc.<BR>[e-mail]<BR>781 245 6996 x227<BR></FONT></P><![if =
!supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]></BODY></HTML>

------_=_NextPart_001_01C0BEB3.D54BC530--

------_=_NextPart_000_01C0BEB3.D54BC530
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C0BEB3.D54BC530--


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA24578 for <[e-mail]>; Fri, 6 Apr 2001 06:17:24 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA13232 for <[e-mail]>; Fri, 6 Apr 2001 09:16:55 -0400 (EDT)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Fri, 06 Apr 2001 09:14:56 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: A standard encoding for Certification Paths
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric Rescorla wrote:
> Jeff Nisewanger <[e-mail]> writes:
> >       It is true that TLS does not use a higher level ASN.1 structure
> > but it also doesn't literally stream or concatenate the DER encoded
> > certificates together. Instead, it wraps the individual DER certificate
> > encodings into a sequence using its own TLS encoding scheme.  The peer TLS
> > implementation then decodes and unwraps the individual DER encoded
> > certificates in the chain and then perhaps hands the individual DER
> > encodings to an X.509 toolkit.
>
> Quite so. Any other approach would require that the TLS toolkit
> be able to itself parse ASN.1. This would be very inconvenient.

Perhaps "distasteful" to those of a certain philosophical bent, but
certainly not "inconvenient".  The amount of code required to take
a bytestream of BER/DER* objects and return a list of Length-Value's
pointing to each object is trivial, and the API for such code is
as simple as, say, strtok().


* Note, an X.509 certificate is encoded using BER, even though the
to-be-signed portion is DER.


Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA23546 for <[e-mail]>; Fri, 6 Apr 2001 05:50:03 -0700 (PDT)
Received: from chrisf (1Cust68.tnt5.clearwater.fl.da.uu.net [63.25.149.68]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id FAA29661; Fri, 6 Apr 2001 05:49:57 -0700 (PDT)
From: "Christopher S. Francis" <[e-mail]>
To: "Dr. JohnDavid Hascup" <[e-mail]>, "Dave Oshman" <[e-mail]>, <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 6 Apr 2001 09:06:27 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C0BE78.DCDE19F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <[e-mail]>

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01C0BE78.DCDE19F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Dr. Hascup,

It’s not clear to me why you feel that the policies of the RP regarding the
meaning of the non-repudiation bit are the primary factor in defining the
meaning of non-repudiation in that environment.  I’m not a lawyer, but it
seems to me that, although the RP’s policy plays a role, the primary
definition of what non-repudiation means in a particular environment should
come from the published policies of the signer.

If I sign something, shouldn’t my policy state whether a RP should interpret
my signature as an endorsement of the contents of whatever I signed?

Chris Francis


-----Original Message-----
From: Dr. JohnDavid Hascup [mailto:[e-mail]]
Sent: Thursday, April 05, 2001 1:15 PM
To: Dave Oshman; [e-mail]
Subject: RE: Meaning of Non-repudiation

Dave
-----Original Message-----
From: Dave Oshman [mailto:[e-mail]]
Sent: Thursday, April 05, 2001 9:24 AM
To: [e-mail]
Subject: Meaning of Non-repudiation
I am trying to clarify the meaning of non-repudiation (as defined by the
technology standards) for our legal counsel. 2459 says this about
non-repudiation:
[JDH] this is the abyss of PKI. Having spent over three years working with
legal counsel on how to understand non-repudiation I have yet to find a
viable "legal" interpretation of the technological protocol. I think the
past year Tom Grindin was developing a "technical non-repudiation" draft
which I think has lapsed as of the past meeting in Minneapolis. It was an
attempt to ground non-repudiation with a meaning that would be "legal"
neutral but protocol specific.
     The nonRepudiation bit is asserted when the subject public key is
      used to verify digital signatures used to provide a non-
      repudiation service which protects against the signing entity
      falsely denying some action, excluding certificate or CRL signing.
The question is what does "some action" mean? Is the action merely signing
the transaction? Or, is the action perhaps committing to the terms described
in the signed transaction?
To rephrase: Is non-repudiation stating simply that I, Dave Oshman, signed
this document? Or, is it supposed to mean that I, Dave Oshman, attest that I
am committing myself (or my company) to the terms described herein?
[JDH] IMO "legal" non-repudiation must be set via the entire environment of
the PKI as specifically defined in whatever policies the RP sets. This means
that it is the RP's use of the bit or non-use that is important. The reason
I felt this was due to the fact that once the question enters the court it,
the technical setting of the bit is not what is important but rather the
interpretation placed upon it by the RP and thus the EE. Apart from a "clear
stated policy" of what the RP intends for it's understanding of
non-repudiation the technical aspects are meaningless. The asserting of the
bit must be given meaning in the context of the environment and cannot have
a meaning legally apart from that environment. Therefore, your second
meaning can only be grounded in the policies set by the environment in which
you are signing and not in the technical underlying protocol. As for the
first, at most, one can argue that the cert granted to you signed. This is
why we had such a difficult time moving "technical" non-repudiation into a
legal context. What is the legal relationship between the certificate and
the person to whom the cert was issued. The protocol can offer forensic
evidence regarding the relationship and the actions of the cert but in and
of itself offers no legal meaning.

Is this more clearly defined in X.813 (ITU-T Recommendation X.8131) |
ISO/IEC 10181-3:...1), Information technology - Open Systems
Interconnection - Security Frameworks in Open Systems - Non-repudiation
framework)? Can anyone snip a description of non-repudiation from X.813?
Thanks!
Dave Oshman
Senior Vice President
Technology
Identrus LLC
Dr. JohnDavid Hascup
Senior Security Architect
ELF Technologies

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:[e-mail]4D0ED0">
<title>Meaning of Non-repudiation</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
h1
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:Arial;
	mso-font-kerning:16.0pt;
	font-weight:bold;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle16
	{mso-style-type:personal-reply;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:navy;}
p.Heading1NoTOC, li.Heading1NoTOC, div.Heading1NoTOC
	{mso-style-name:"Heading 1 No TOC";
	mso-style-parent:"Heading 1";
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:14.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.TableText, li.TableText, div.TableText
	{mso-style-name:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Dr.
Hascup,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>It&#8217;s
not clear to me why you feel that the policies of the RP regarding the =
meaning
of the non-repudiation bit are the primary factor in defining the =
meaning of
non-repudiation in that environment.<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>I&#8217;m not a lawyer, but it seems to me that, although the =
RP&#8217;s policy
plays a role, the primary definition of what non-repudiation means in a
particular environment should come from the published policies of the =
signer.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>If
I sign something, shouldn&#8217;t my policy state whether a RP should =
interpret my
signature as an endorsement of the contents of whatever I signed?<span
style=3D"mso-spacerun: yes">&nbsp; =
</span><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Chris
Francis<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Dr. JohnDavid =
Hascup [mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, April 05, =
2001
1:15 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Dave Oshman; =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Meaning of
Non-repudiation</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblue face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Dave</span></font=
><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;
margin-left:1.0in'><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:black'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Dave Oshman
[mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, April 05, =
2001
9:24 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Meaning of
Non-repudiation</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>I am trying to clarify the =
meaning of
non-repudiation (as defined by the technology standards) for our legal =
counsel.
2459 says this about non-repudiation:<br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[JDH]&nbsp;this is the abyss of PKI. =
Having spent
over three years working with legal counsel on how to understand
non-repudiation I have yet to find a viable &quot;legal&quot; =
interpretation of
the technological protocol. I think the past year Tom Grindin&nbsp;was
developing a &quot;technical non-repudiation&quot; draft which =
I&nbsp;think has
lapsed as of the past meeting in Minneapolis. It was an attempt to =
ground non-repudiation
with a meaning that would be &quot;legal&quot; neutral but protocol =
specific.</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp; The
nonRepudiation bit is asserted when the subject public key =
is</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify digital =
signatures
used to provide a non-</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; repudiation service which =
protects
against the signing entity</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; falsely denying some action,
excluding certificate or CRL signing.</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>The question is what does =
&quot;some
action&quot; mean? Is the action merely signing the transaction? Or, is =
the
action perhaps committing to the terms described in the signed =
transaction?</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>To rephrase: Is non-repudiation =
stating
simply that I, Dave Oshman, signed this document? Or, is it supposed to =
mean
that I, Dave Oshman, attest that I am committing myself (or my company) =
to the terms
described herein?<br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[JDH]&nbsp;IMO &quot;legal&quot; =
non-repudiation
must be set via the entire environment of the PKI as specifically =
defined in
whatever policies the RP sets. This means that it is the RP's use of the =
bit or
non-use that is important. The reason I felt this was due to the fact =
that once
the question enters the court it, the technical setting of the bit is =
not what
is important but rather the interpretation placed upon it by the RP and =
thus
the EE. Apart from a &quot;clear stated policy&quot; of what the RP =
intends for
it's understanding of non-repudiation the technical aspects are =
meaningless.
The asserting of the bit must be given meaning in the context of the
environment and cannot have a meaning legally apart from that
environment.&nbsp;Therefore, your second meaning can only be grounded in =
the
policies set by the environment in which you are signing and not in the
technical underlying protocol. As for the first, at most, one can argue =
that
the cert granted to you signed. This is why we had such a difficult time =
moving
&quot;technical&quot; non-repudiation into a legal context. What is the =
legal
relationship between the certificate and the person to whom the cert was
issued. The protocol can offer forensic evidence regarding the =
relationship and
the actions of the cert but in and of itself offers no legal =
meaning.</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:1.0in'><font size=3D3 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Is this more clearly defined in =
X.813
(ITU-T Recommendation X.8131) | ISO/IEC 10181-3:...1), Information =
technology -
Open Systems Interconnection - Security Frameworks in Open Systems -
Non-repudiation framework)? Can anyone snip a description of =
non-repudiation
from X.813?</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:black'>Thanks!</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Dave Oshman </span></font><font color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Senior Vice President </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Technology </span></font><font color=3Dblack><span =
style=3D'color:
black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Identrus LLC</span></font><font color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.0in'><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Dr. JohnDavid =
Hascup</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.0in'><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Senior Security =
Architect</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:1.0in'><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>ELF Technologies</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------=_NextPart_000_0004_01C0BE78.DCDE19F0--



Received: from romeo.rtfm.com ([198.144.203.242]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA04754 for <[e-mail]>; Thu, 5 Apr 2001 20:23:10 -0700 (PDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id UAA13485; Thu, 5 Apr 2001 20:28:29 -0700 (PDT)
Sender: [e-mail]
To: Jeff Nisewanger <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: A standard encoding for Certification Paths
References: <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 05 Apr 2001 20:28:28 -0700
In-Reply-To: Jeff Nisewanger's message of "Thu, 5 Apr 2001 18:49:28 -0700 (PDT)"
Message-ID: <[e-mail]>
Lines: 28
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"

Jeff Nisewanger <[e-mail]> writes:
> Dean Povey writes:
> > Degenerate PKCS#7/CMS SignedData indeed seems to be the most common
> > method to pass around cert paths, which although something of an
> > insanity is a small insanity in a very large universe of insanities.
> > SEQUENCE OF Certificate is also not uncommon, and Polar's method of
> > just streaming the Certificates without wrapping them up in a higher
> > level ASN.1 structure is the way it is done in SSL/TLS.
> 
> 
> 	It is true that TLS does not use a higher level ASN.1 structure
> but it also doesn't literally stream or concatenate the DER encoded
> certificates together. Instead, it wraps the individual DER certificate
> encodings into a sequence using its own TLS encoding scheme.  The peer TLS
> implementation then decodes and unwraps the individual DER encoded
> certificates in the chain and then perhaps hands the individual DER
> encodings to an X.509 toolkit.
Quite so. Any other approach would require that the TLS toolkit
be able to itself parse ASN.1. This would be very inconvenient.

Note that from an encoding perspective a BER encoding of a
SEQUENCE or SET OF certificates can be formed by concatenating them and
then adding the tag and length. DER of SET OF is slightly trickier
because you have to sort them but then again you rarely have
to encode DER. Certainly you never do for S/MIME which is generally
BER encoded.

-Ekr


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA02750 for <[e-mail]>; Thu, 5 Apr 2001 18:49:25 -0700 (PDT)
Received: from shorter.eng.sun.com ([129.144.251.35]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA27119; Thu, 5 Apr 2001 18:49:29 -0700 (PDT)
Received: from crypto (crypto [129.144.250.112]) by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA06547; Thu, 5 Apr 2001 18:49:28 -0700 (PDT)
Message-Id: <[e-mail]>
Date: Thu, 5 Apr 2001 18:49:28 -0700 (PDT)
From: Jeff Nisewanger <[e-mail]>
Reply-To: Jeff Nisewanger <[e-mail]>
Subject: Re: A standard encoding for Certification Paths
To: [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 5lWTq1QFiggjKFgK0W+jRg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc

Polar Humenn writes:
> I believe the lowest common denominator for a sequence of certificates is
> exactly that, a stream of ASN.1 Certificate encodings.
> 

Dean Povey writes:
> Degenerate PKCS#7/CMS SignedData indeed seems to be the most common
> method to pass around cert paths, which although something of an
> insanity is a small insanity in a very large universe of insanities.
> SEQUENCE OF Certificate is also not uncommon, and Polar's method of
> just streaming the Certificates without wrapping them up in a higher
> level ASN.1 structure is the way it is done in SSL/TLS.


	It is true that TLS does not use a higher level ASN.1 structure
but it also doesn't literally stream or concatenate the DER encoded
certificates together. Instead, it wraps the individual DER certificate
encodings into a sequence using its own TLS encoding scheme.  The peer TLS
implementation then decodes and unwraps the individual DER encoded
certificates in the chain and then perhaps hands the individual DER
encodings to an X.509 toolkit.



	Jeff



Received: from hamster.gadens.com.au (ns.gadens.com.au [203.18.88.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA26869 for <[e-mail]>; Thu, 5 Apr 2001 16:44:50 -0700 (PDT)
Received: from exchange.gadens.com.au ([10.1.8.3]) by hamster.gadens.com.au (8.11.0/8.11.0) with ESMTP id f35NYK262364; Fri, 6 Apr 2001 09:34:21 +1000 (EST) (envelope-from [e-mail])
Received: by exchange.gadens.com.au with Internet Mail Service (5.5.2653.19) id <12HF5WPD>; Fri, 6 Apr 2001 09:49:24 +1000
Message-ID: <[e-mail]>
From: Adrian McCullagh <[e-mail]>
To: "'Dave Oshman'" <[e-mail]>, [e-mail]
Subject: RE: Meaning of Non-repudiation
Date: Fri, 6 Apr 2001 09:49:13 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0BE2B.043EA760"

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

------_=_NextPart_000_01C0BE2B.043EA760
Content-Type: text/plain;
	charset="iso-8859-1"

Dave,
 
I wrote a paper on Non-repudiation which was published in the journal
"first Monday".  First Monday is published by University of Chicago.  I
enclose a copy for your perusal which may assist in your deliberations.
 
 
 

Adrian McCullagh 
Director of Electronic CommerceTel: 617 3231 1522 
Gadens Lawyers                      Fax: [phone]      

level 39 
Central Plaza 1 
345 Queen Street 
Brisbane Australia 4000 

Ph. D. Candidate 
Thesis "The Incorporation of Trust Strategies in Digital Signature Regimes
for Elec. Comm." 
Information Security Research Centre 
Queensland University of Technology 

This message is confidential and privileged. It is solely intended for the
person or persons named in this message.  If this message is received by
anyone not named in this message then the sender does not relinquish any
rights of confidentiality or legal privilege as regards to the contents of
this email.  If you are not named in this email then would you please
contact the sender and destroy all copies of this email.  I thank you for
your assistance.   

 

-----Original Message-----
From: Dave Oshman [mailto:[e-mail]]
Sent: Friday, April 06, 2001 2:24 AM
To: [e-mail]
Subject: Meaning of Non-repudiation



I am trying to clarify the meaning of non-repudiation (as defined by the
technology standards) for our legal counsel. 2459 says this about
non-repudiation:

     The nonRepudiation bit is asserted when the subject public key is 
      used to verify digital signatures used to provide a non- 
      repudiation service which protects against the signing entity 
      falsely denying some action, excluding certificate or CRL signing. 

The question is what does "some action" mean? Is the action merely signing
the transaction? Or, is the action perhaps committing to the terms described
in the signed transaction?

To rephrase: Is non-repudiation stating simply that I, Dave Oshman, signed
this document? Or, is it supposed to mean that I, Dave Oshman, attest that I
am committing myself (or my company) to the terms described herein?

Is this more clearly defined in X.813 (ITU-T Recommendation X.8131) |
ISO/IEC 10181-3:...1), Information technology - Open Systems Interconnection
- Security Frameworks in Open Systems - Non-repudiation framework)? Can
anyone snip a description of non-repudiation from X.813?

Thanks! 
Dave Oshman 
Senior Vice President 
Technology 
Identrus LLC 


------_=_NextPart_000_01C0BE2B.043EA760
Content-Type: application/msword;
	name="Non Repudiation.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="Non Repudiation.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAlwAAAAAAAAAA
EAAAmQAAAAEAAAD+////AAAAAJUAAACWAAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAcQAJBAAACBK/AAAAAAAAEAAAAAAABAAAb5EAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAQLwAABZBAQAWQQEA5mwAAAAAAACCAAAAAAAAAAAAAAAGIAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJAPAAAAAAAAkA8AAJAP
AAAAAAAAkA8AAAAAAAC+EAAAAAAAAL4QAAAAAAAAvhAAABQAAAAAAAAAAAAAANIQAAAAAAAA0hAA
AAAAAADSEAAAAAAAANIQAAA4AAAAChEAADQAAAA+EQAAVAAAANIQAAAAAAAAlDYAAHYCAAC2EQAA
AAAAALYRAAA6AAAA8BEAAAAAAADwEQAAAAAAAHISAAAAAAAAchIAAK4AAAAgEwAANAAAAFQTAAAc
AAAAlScAAAIAAACXJwAAAAAAAJcnAAAAAAAAlycAAEgAAADfJwAAUAcAAC8vAABQBwAAfzYAAAAA
AAAKOQAA9AEAAP46AADqAAAAfzYAABUAAAAAAAAAAAAAAAAAAAAAAAAAvhAAAAAAAABwEwAAAAAA
AAAAAAAAAAAAAAAAAAAAAAByEgAAAAAAAHISAAAAAAAAcBMAAAAAAABwEwAAAAAAAH82AAAAAAAA
aBQAAAAAAACQDwAAsgAAAEIQAAB8AAAA8BEAAIIAAAAAAAAAAAAAAHISAAAAAAAAthEAAAAAAABo
FAAAAAAAAGgUAAAAAAAAaBQAAAAAAABwEwAAlAAAAL4QAAAAAAAAchIAAAAAAAC+EAAAAAAAAHIS
AAAAAAAA/SYAAJgAAAAAAAAAAAAAAAAAAAAAAAAA0hAAAAAAAADSEAAAAAAAAJAPAAAAAAAAkA8A
AAAAAAC+EAAAAAAAAL4QAAAAAAAAcBMAAAAAAACVJwAAAAAAAGgUAAAYBwAAaBQAAAAAAACAGwAA
pgEAAOMhAAD2BAAAvhAAAAAAAAC+EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/SYAAAAAAAByEgAAAAAAAJIRAAAkAAAA8CsrynhG
vwHSEAAAAAAAANIQAAAAAAAABBQAAGQAAADZJgAAJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATk9O
LVJFUFVESUFUSU9OIElOIFRIRSBESUdJVEFMIEVOVklST05NRU5UIA1CWQ1BZHJpYW4gTWNDdWxs
YWdoDU5hdGlvbmFsIERpcmVjdG9yIEVsZWN0cm9uaWMgQ29tbWVyY2UNR2FkZW5zIExhd3llcnMN
UGguIEQuICBDYW5kaWRhdGUNSW5mb3JtYXRpb24gU2VjdXJpdHkgUmVzZWFyY2ggQ2VudGVyDVF1
ZWVuc2xhbmQgVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5DVBoLiAgMDcgMzIzMSAxNTIyDUVtYWls
OiAgYW1jY3VsbGFnaEBnYWRlbnMuY29tLmF1DUFuZA1Qcm9mZXNzb3IgV2lsbGlhbSBDYWVsbGkN
SGVhZCBvZiBTY2hvb2wNU2Nob29sIG9mIERhdGEgQ29tbXVuaWNhdGlvbnMNUXVlZW5zbGFuZCBV
bml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kNUGguICAwNyAzODY0IDI3NTINRW1haWw6ICB3Y2FlbGxp
QHF1dC5lZHUuYXUNDE5PTi1SRVBVRElBVElPTiBJTiBUSEUgRElHSVRBTCBFTlZJUk9OTUVOVCgN
DZMgVGhlIHRpbWVzIHRoZXkgYXJlIGEgY2hhbmdpbpIglA1Cb2IgRHlsYW4NSW50cm9kdWN0aW9u
DVRoZSBpbnZlc3RtZW50IGNvbW11bml0eSBpbiBtYW55IGluc3RhbmNlcyBoYXMgdHJhZGl0aW9u
YWxseSByZWxpZWQgaGVhdmlseSBvbiBmYWNlIHRvIGZhY2UgY29tbXVuaWNhdGlvbnMuIFdpdGgg
dGhlIGFkdmVudCBvZiBuZXcgZGlnaXRhbCBzaWduYXR1cmUgdGVjaG5vbG9neSwgZmFjZSB0byBm
YWNlIGNvbW11bmljYXRpb24gYXMgYSBtYW5uZXIgb2YgZG9pbmcgYnVzaW5lc3Mgd2lsbCBpbiB0
aGUgbm90IHRvbyBkaXN0YW50IGZ1dHVyZSBiZWNvbWUgdGhlIGV4Y2VwdGlvbiBhcyBvcHBvc2Vk
IHRvIHRoZSBub3JtLiAgIFRoZSB0eXJhbm55IG9mIGRpc3RhbmNlIGZvciBlZmZlY3RpbmcgYnVz
aW5lc3Mgd2lsbCBiZSBvdmVyY29tZSwgc28gYXMgdG8gZW5oYW5jZSB0aGUgZWZmaWNpZW5jaWVz
IG9mIGJ1c2luZXNzLiAgIFRoaXMgaXMgb25lIG9mIHRoZSBwcmltYXJ5IGFkdmFudGFnZXMgb2Yg
ZWxlY3Ryb25pYyBjb21tZXJjZS4gDUVsZWN0cm9uaWMgQ29tbWVyY2UgaXMgYWZmZWN0aW5nIGFs
bCBpbmR1c3RyeSBzZWN0b3JzLiBUaGUgaW52ZXN0bWVudC9maW5hbmNlIGNvbW11bml0eSBoYXMs
IG1vcmUgdGhhbiBhbnkgb3RoZXIgY29tbXVuaXR5LCBpbmNyZWFzaW5nbHkgYmVjb21pbmcgZGVw
ZW5kZW50IHVwb24gdGVjaG5vbG9neSBhcyBhIGZvdW5kYXRpb24gZm9yIGl0cyBidXNpbmVzcyBz
dXJ2aXZhbC4gICBNdWNoIG9mIHRoaXMgaW5mbHVlbmNlIGhhcyBjZW50ZXJlZCB1cG9uIHRoZSBj
b3N0IHNhdmluZ3MgdGhhdCBjYW4gYXJpc2UgdGhyb3VnaCB0aGUgdXNlIG9mIHRlY2hub2xvZ3ku
ICBUaGVyZSBoYXZlIGJlZW4gbWFueSByZXBvcnRzIGRlYWxpbmcgd2l0aCB0aGUgaW5mbHVlbmNl
IHRoYXQgZWxlY3Ryb25pYyBjb21tZXJjZSBpcyBoYXZpbmcgb24gdGhlIGdlbmVyYWwgZWNvbm9t
eS4gIFRoZSBiYW5raW5nIGluZHVzdHJ5LCB0aGUgc2VjdXJpdGllcyBpbmR1c3RyeSBhbmQgdGhl
IGluc3VyYW5jZSBpbmR1c3RyeSBoYXZlIGVhY2ggaW4gcmVjZW50IHRpbWVzIHRha2VuIGEgc3Bl
Y2lmaWMgaW50ZXJlc3QgaW4gZWxlY3Ryb25pYyBjb21tZXJjZSBhbmQgdGhlIGJlbmVmaXRzIHRo
YXQgbWF5IGJlIGF2YWlsYWJsZSB0byB0aGVtIGVpdGhlciBpbmRpdmlkdWFsbHkgb3IgY3Jvc3Mg
c2VjdGlvbmFsbHkuICANRnVuZGFtZW50YWxseSwgZWxlY3Ryb25pYyBjb21tZXJjZSBpbnZvbHZl
cyB0aGUgdXNlIG9mIHJlbW90ZSBjb21tdW5pY2F0aW9ucyBhbmQgdGhlcmVmb3JlIG5lY2Vzc2l0
YXRlcyB0aGUgcGFydGllcyB0byBhdXRoZW50aWNhdGUgb25lIGFub3RoZXICLiAgT25lIG9mIHRo
ZSBwcmltYXJ5IHRlY2hub2xvZ2llcyBwcm9wb3NlZCB0byBlZmZlY3QgYXV0aGVudGljYXRpb24g
aXMgZGlnaXRhbCBzaWduYXR1cmUgdGVjaG5vbG9neSwgd2hpY2ggc29tZSBjb21tZW50YXRvcnMg
aGF2ZSBpZGVudGlmaWVkLCBwcm92aWRlcyB0aGUgaW52ZXN0bWVudC9maW5hbmNlIGNvbW11bml0
eSB3aXRoIHN1YnN0YW50aWFsIGNvc3QgZWZmaWNpZW5jaWVzAi4gICBBIGZ1cnRoZXIgY2xhaW1l
ZCBhZHZhbnRhZ2Ugb2YgZGlnaXRhbCBzaWduYXR1cmUgdGVjaG5vbG9neSBjb25jZXJucyB0aGUg
aXNzdWUgb2YgIm5vbh5yZXB1ZGlhdGlvbiIgY2xhaW1lZCBieSB0aGUgcmVseWluZyBwYXJ0eSBv
ZiBhIGRpZ2l0YWxseSBzaWduZWQgZG9jdW1lbnQgYWdhaW5zdCB0aGUgYWxsZWdlZCBzaWduZXIg
b2YgdGhlIGVsZWN0cm9uaWMgZG9jdW1lbnQuAg1UaGUgaXNzdWUgaXMgLSB3aGF0IGRvZXMgdGhl
IHRlcm0gIm5vbh5yZXB1ZGlhdGlvbiIgcmVhbGx5IG1lYW4/ICBUaGlzIHBhcGVyIHdpbGwgb25s
eSBkZWFsIHdpdGggdGhlIGluY29uc2lzdGVuY3kgdGhhdCBoYXMgYXJpc2VuIGJldHdlZW4gdGhl
IGNyeXB0byBtZWFuaW5nIGFuZCB0aGUgbGVnYWwgbWVhbmluZy4gIEluIHNvIGRvaW5nIHRoaXMg
cGFwZXIgZGVhbHMgd2l0aCB0aGUgZm9sbG93aW5nIGlzc3VlczoNdGhlIGxlZ2FsIG1lYW5pbmcg
b2Ygk25vbi1yZXB1ZGlhdGlvbpQgOw10aGUgY3J5cHRvIG1lYW5pbmcgb2Ygk25vbi1yZXB1ZGlh
dGlvbpQ7DXRoZSBVTkNJVFJBTCBNb2RlbCBMYXcgYW5kIHRoZSBvbnVzIG9mIHByb29mIGlzc3Vl
IHVuZGVyIEFydGljbGUgMTM7DXRoZSB0ZWNobmljYWwgdnVsbmVyYWJpbGl0aWVzIGluIGFkb3B0
aW5nIEFydGljbGUgMTMNVHJ1c3RlZCBzeXN0ZW1zIGFzIGEgYmFzaXMgdG8gc3VwcG9ydCB0aGUg
Q29tbW9uIExhdyBwb3NpdGlvbg1Db25jbHVzaW9uIA1UaGlzIHBhcGVyIHdpbGwgc2hvdyB0aGF0
IGxhdyBtYWtlcnMgYXJvdW5kIHRoZSB3b3JsZCBhcmUgYmVpbmcgY29uZnVzZWQgYnkgdGhlc2Ug
ZGVmaW5pdGlvbnMgYW5kIGFyZSBpbiB0dXJuIGNyZWF0aW5nIGEgZnVuZGFtZW50YWwgYW5kIG1h
am9yIHByb2JsZW0gYnkgbm90IGFkZHJlc3NpbmcgdGhlIGlzc3VlIG9mICJ0cnVzdCIgYXQgdGhl
IHNpZ25lcpJzIGVuZCBvZiB0aGUgZWxlY3Ryb25pYyBjb21tdW5pY2F0aW9uIHdpdGhpbiB0aGUg
ZWxlY3Ryb25pYyBjb21tZXJjZSBlbnZpcm9ubWVudC4gIA1UcmFkaXRpb25hbCBMZWdhbCBtZWFu
aW5nIG9mIJNOb24tcmVwdWRpYXRpb26UDVRoZXJlIGlzIGEgZGVmaW5pdGlvbmFsIGRpc3RpbmN0
aW9uIGJldHdlZW4gdGhlIGxlZ2FsIHVzZSBvZiB0aGUgdGVybSAibm9uHnJlcHVkaWF0aW9uIiBh
bmQgdGhlIGNyeXB0by10ZWNobmljYWwgdXNlIG9mIHRoaXMgdGVybS4gICBJbiB0aGUgbGVnYWwg
c2Vuc2UgYW4gYWxsZWdlZCBzaWduYXRvcnkgdG8gYSBkb2N1bWVudCBpcyBhbHdheXMgYWJsZSB0
byByZXB1ZGlhdGUgYSBzaWduYXR1cmUgdGhhdCBoYXMgYmVlbiBhdHRyaWJ1dGVkIHRvIGhpbS9o
ZXIuAiAgVGhlIGJhc2lzIGZvciBhIHJlcHVkaWF0aW9uIG9mIGEgdHJhZGl0aW9uYWwgc2lnbmF0
dXJlIG1heSBpbmNsdWRlOg1UaGUgc2lnbmF0dXJlIGJlaW5nIGEgZm9yZ2VyeTsNVGhlIHNpZ25h
dHVyZSBub3QgYmVpbmcgYSBmb3JnZXJ5LCBidXQgaGF2aW5nIGJlZW4gb2J0YWluZWQgdmlhOg1V
bmNvbnNjaW9uYWJsZSBjb25kdWN0IGJ5IGEgcGFydHkgdG8gYSB0cmFuc2FjdGlvbjsCDUZyYXVk
IGluc3RpZ2F0ZWQgYnkgYSB0aGlyZCBwYXJ0eTsCDVVuZHVlIGluZmx1ZW5jZSBleGVydGVkIGJ5
IGEgdGhpcmQgcGFydHkuAg1UaGVyZSBhcHBlYXJzIHRvIGJlIGEgbW92ZW1lbnQgd2l0aGluIHRo
ZSBlbGVjdHJvbmljIGNvbW1lcmNlIGVudmlyb25tZW50IHRvIHRha2UgYXdheSB0aGVzZSBmdW5k
YW1lbnRhbCByaWdodHMgdGhhdCBleGlzdCB3aXRoaW4gdGhlIGNvbW1vbiBsYXcganVyaXNkaWN0
aW9ucy4CICBUaGUgZ2VuZXJhbCBydWxlIG9mIGV2aWRlbmNlIGlzIHRoYXQgaWYgYSBwZXJzb24g
ZGVuaWVzIGEgcGFydGljdWxhciBzaWduYXR1cmUgdGhlbiBpdCBmYWxscyB1cG9uIHRoZSByZWx5
aW5nIHBhcnR5IHRvIHByb3ZlIHRoYXQgdGhlIHNpZ25hdHVyZSBpcyB0cnVseSB0aGF0IG9mIHRo
ZSBwZXJzb24gZGVueWluZyBpdAIuICAgSXQgc2hvdWxkIGJlIHVuZGVyc3Rvb2QgdGhhdCB0aGUg
dGVybSCTZGVueZQgYW5kIHRoZSB0ZXJtIJNyZXB1ZGlhdGWUIGFyZSBzeW5vbnltb3VzIGFuZCB0
aGlzIHBvc2l0aW9uIGlzIHN1cHBvcnRlZCBieSBzdGFuZGFyZCBkaWN0aW9uYXJ5IGRlZmluaXRp
b25zLgIgDUZ1cnRoZXJtb3JlLCB0aGUgY29tbW9uIGxhdyB0cnVzdCBtZWNoYW5pc20gZXN0YWJs
aXNoZWQgdG8gb3ZlcmNvbWUgYSBmYWxzZSBjbGFpbSBvZiBub24tcmVwdWRpYXRpb24gaXMgd2l0
bmVzc2luZwIuICBUaGUgaW1wb3J0YW50IGFzcGVjdCBvZiB3aXRuZXNzaW5nIGlzIHRoYXQgaXQg
aXMgZWZmZWN0ZWQgYXQgdGhlIHRpbWUgdGhlIHNpZ25hdHVyZSBpcyBiZWluZyBhZmZpeGVkLiAg
IFRoYXQgaXMsIGJ5IGhhdmluZyBhbiBpbmRlcGVuZGVudCBhZHVsdCB3aXRuZXNzIHRoZSBzaWdu
aW5nIG9mIHRoZSBkb2N1bWVudCB0aGF0IGlzIGV2aWRlbmNpbmcgdGhlIHRyYW5zYWN0aW9uIGJ5
IHRoZSBhbGxlZ2VkIHNpZ25hdG9yeSByZWR1Y2VzIHRoZSBhYmlsaXR5IG9mIHRoZSBhbGxlZ2Vk
IHNpZ25hdG9yeSB0byBzdWNjZXNzZnVsbHkgZGVueSB0aGUgc2lnbmF0dXJlIGFzIGEgZm9yZ2Vy
eSBhdCBhIGxhdGVyIGRhdGUuICBJdCBpcyBhbHdheXMgb3BlbiBmb3IgdGhlIGFsbGVnZWQgc2ln
bmF0b3J5IHRvIGRlbnkgdGhlIHNpZ25hdHVyZSBvbiBvdGhlciBncm91bmRzIHN1Y2ggYXMgdGhv
c2UgZW51bWVyYXRlZCBhYm92ZS4NVGhlIGlzc3VlIHRoYXQgYXJpc2VzIGlzIHdoZXRoZXIgYSBk
aWdpdGFsIHNpZ25hdHVyZSBzaG91bGQgYmUgdHJlYXRlZCBkaWZmZXJlbnRseSB0byB0aGF0IG9m
IGEgdHJhZGl0aW9uYWwgc2lnbmF0dXJlLiAgSXQgaXMgc3VibWl0dGVkIHRoYXQgdGhlIGxhdyBz
aG91bGQgbm90IGluIHRoZSBlbGVjdHJvbmljIGNvbW1lcmNlIGVudmlyb25tZW50IGFsdGVyIHRo
aXMgcG9zaXRpb24gYXMgcmVnYXJkcyB0byB0aGUgbGVnYWwgcmlnaHRzIG9mIHBhcnRpZXMgdG8g
cmVwdWRpYXRlIGEgZGlnaXRhbCBzaWduYXR1cmUuAiAgR292ZXJubWVudHOSIHdvcmxkd2lkZSBo
YXZlIGNvbnNpc3RlbnRseSBlc3BvdXNlZCB0aGlzIHBvc2l0aW9uAi4gIFRoZSBlbGVjdHJvbmlj
IGNvbW1lcmNlIGVudmlyb25tZW50IHNob3VsZCBub3QgaGF2ZSBkaWZmZXJlbnQgcnVsZXMgdG8g
dGhlIHJ1bGVzIHRoYXQgaGF2ZSBkZXZlbG9wZWQgb3ZlciBtYW55IGNlbnR1cmllcyBpbiB0aGUg
cGFwZXItYmFzZWQgZW52aXJvbm1lbnQuIFRoZXNlIHJ1bGVzIGhhdmUgYmVlbiBkZXZlbG9wZWQg
YW5kIGp1ZGljaWFsbHkgdGVzdGVkIHNvIGFzIG5vdCB0byBkaXNhZHZhbnRhZ2UgYW55IHBhcnR5
IHRvIHRyYW5zYWN0aW9uLg1UaGVyZSBpcyBhIGNsZWFyIGNvbnRyYWRpY3RvcnkgcG9zaXRpb24g
YmV0d2VlbiB0aGUgdGVjaG5pY2FsIG1lYW5pbmcgYW5kIHRoZSBsZWdhbCBtZWFuaW5nIG9mIHRo
ZSB0ZXJtICJub24tcmVwdWRpYXRpb24iIHdoZXJlIHRoZXJlIGlzIGEgY2xlYXIgY2FzZSBvZiBm
b3JnZXJ5IGFzIHJlZ2FyZHMgdG8gYW4gYWxsZWdlZCBkaWdpdGFsIHNpZ25hdHVyZS4NSW4gdGhl
IHRyYWRpdGlvbmFsIGxlZ2FsIHNlbnNlIHRoZSBvbnVzIG9mIHByb29mIGluIGEgY2FzZSBpbnZv
bHZpbmcgYSBmb3JnZWQgcGFwZXItYmFzZWQgc2lnbmF0dXJlIGxpZXMgdXBvbiB0aGUgcGFydHkg
d2lzaGluZyB0byByZWx5IHVwb24gdGhlIHNpZ25hdHVyZS4gIFRoZSByZWx5aW5nIHBhcnR5IGlu
IHJlbGF0aW9uIHRvIGFuIGFsbGVnZWQgZm9yZ2VkIHNpZ25hdHVyZSBpcyByZXF1aXJlZCB0byBl
c3RhYmxpc2g6DUluIGEgY2l2aWwgYWN0aW9uLCBvbiB0aGUgYmFsYW5jZSBvZiBwcm9iYWJpbGl0
aWVzOyBhbmQNSW4gYSBjcmltaW5hbCBhY3Rpb24sIGJleW9uZCByZWFzb25hYmxlIGRvdWJ0LA10
aGF0IHRoZSBzaWduYXR1cmUgaXMgbm90IGEgZm9yZ2VyeS4NVGhhdCBpcywgaWYgdGhlIGFsbGVn
ZWQgc2lnbmF0b3J5IGRpc3B1dGVzIHRoZSBzaWduYXR1cmUgYXMgYmVsb25naW5nIHRvIGhpbS9o
ZXIgdGhlbiB0aGUgb251cyBmYWxscyB1cG9uIHRoZSByZWx5aW5nIHBhcnR5IHRvIHByb3ZlIHRo
YXQgdGhlIHNpZ25hdHVyZSBpcyBpbiBmYWN0IHRoYXQgb2YgdGhlIGFsbGVnZWQgc2lnbmF0b3J5
Lg1DcnlwdG8tdGVjaG5pY2FsIG1lYW5pbmcgb2Ygk25vbi1yZXB1ZGlhdGlvbpQNSW4gZ2VuZXJh
bCB0ZXJtcywgdGhlIHRlcm0gIm5vbi1yZXB1ZGlhdGlvbiIgY3J5cHRvLXRlY2huaWNhbGx5IG1l
YW5zOg1JbiBhdXRoZW50aWNhdGlvbiwgYSBzZXJ2aWNlIHRoYXQgcHJvdmlkZXMgcHJvb2Ygb2Yg
dGhlIGludGVncml0eSBhbmQgb3JpZ2luIG9mIGRhdGEsIGJvdGggaW4gYW4gdW5mb3JnZWFibGUg
cmVsYXRpb25zaGlwLCB3aGljaCBjYW4gYmUgdmVyaWZpZWQgYnkgYW55IHRoaXJkIHBhcnR5IGF0
IGFueSB0aW1lOyBvcg1JbiBhdXRoZW50aWNhdGlvbiwgYW4gYXV0aGVudGljYXRpb24gdGhhdCB3
aXRoIGhpZ2ggYXNzdXJhbmNlIGNhbiBiZSBhc3NlcnRlZCB0byBiZSBnZW51aW5lLCBhbmQgdGhh
dCBjYW4gbm90IHN1YnNlcXVlbnRseSBiZSByZWZ1dGVkLiAoRW1waGFzaXMgYWRkZWQpAg1UaGUg
dGVybSCTcmVmdXRlZJQgYWNjb3JkaW5nIHRvIHRoZSBTaG9ydGVyIE94Zm9yZCBEaWN0aW9uYXJ5
IGFsc28gbWVhbnMgYW1vbmcgb3RoZXIgdGhpbmdzIJNkZW55lC4gIEluIDE5OTgsIHRoZSBBdXN0
cmFsaWFuIEZlZGVyYWwgR292ZXJubWVudJJzIEVsZWN0cm9uaWMgQ29tbWVyY2UgRXhwZXJ0IEdy
b3VwIGFkb3B0ZWQgYSB0ZWNobmljYWwgbWVhbmluZyBpbiBpdHMgcmVwb3J0IHRvIHRoZSBBdXN0
cmFsaWFuIEZlZGVyYWwgQXR0b3JuZXkgR2VuZXJhbCwgYnkgZGVmaW5pbmcgk05vbi1yZXB1ZGlh
dGlvbpQgYXMgZm9sbG93czoNTm9uLXJlcHVkaWF0aW9uIGlzIGEgcHJvcGVydHkgYWNoaWV2ZWQg
dGhyb3VnaCBjcnlwdG9ncmFwaGljIG1ldGhvZHMgd2hpY2ggcHJldmVudHMgYW4gaW5kaXZpZHVh
bCBvciBlbnRpdHkgZnJvbSBkZW55aW5nIGhhdmluZyBwZXJmb3JtZWQgYSBwYXJ0aWN1bGFyIGFj
dGlvbiByZWxhdGVkIHRvIGRhdGEgKHN1Y2ggYXMgbWVjaGFuaXNtcyBmb3Igbm9uLXJlamVjdGlv
biBvciBhdXRob3JpdHkgKG9yaWdpbik7IGZvciBwcm9vZiBvZiBvYmxpZ2F0aW9uLCBpbnRlbnQs
IG9yIGNvbW1pdG1lbnQ7IG9yIGZvciBwcm9vZiBvZiBvd25lcnNoaXApLgIoRW1waGFzaXMgYWRk
ZWQpDUl0IGlzIHRoaXMgZGVuaWFsIG9mIHRoZSByaWdodCBvZiBiZWluZyBhYmxlIHRvIHJlcHVk
aWF0ZQIgYSBkaWdpdGFsIHNpZ25hdHVyZSB0aGF0IGNhdXNlcyBncmVhdCBjb25jZXJuIGFuZCBp
cyByZXN1bHRpbmcgaW4gYSBtaXNpbnRlcnByZXRhdGlvbiBvZiBpdHMgdXNlIHdpdGhpbiBkaWdp
dGFsIHNpZ25hdHVyZSByZWdpbWVzLiBBZGRpdGlvbmFsbHksIHRoZSBkcmFmdCBzdGFuZGFyZCBm
b3IgR3VpZGVsaW5lcyBmb3IgdGhlIHVzZSBhbmQgbWFuYWdlbWVudCBvZiBUcnVzdGVkIFRoaXJk
IFBhcnR5IHNlcnZpY2VzIHRoYXQgaGFzIGJlZW4gcHJvbXVsZ2F0ZWQgYnkgdGhlIEludGVybmF0
aW9uYWwgU3RhbmRhcmRzIE9yZ2FuaXNhdGlvbiBhcyByZWdhcmRzIHRvIE5vbi1yZXB1ZGlhdGlv
biBTZXJ2aWNlcwIgcHJvdmlkZXMgdGhhdDoNVFRQcyBtYXkgYmUgaW52b2x2ZWQgaW4gdGhlIHBy
b3Zpc2lvbiBvZiBub24tcmVwdWRpYXRpb24gc2VydmljZXMsIGRlcGVuZGluZyBvbiB0aGUgbWVj
aGFuaXNtcyB1c2VkIGFuZCB0aGUgbm9uLXJlcHVkaWF0aW9uIHBvbGljeSBpbiBmb3JjZS4gVGhl
IHB1cnBvc2Ugb2Ygbm9uLXJlcHVkaWF0aW9uLCBpbiBjb25mb3JtYW5jZSB3aXRoIElTTy9JRUMg
MTM4ODgtMSwgLTIgYW5kIC0zLCBpcyB0byBwcm92aWRlIHZlcmlmaWFibGUgcHJvb2Ygb3IgZXZp
ZGVuY2UgcmVjb3JkaW5nIG9mIGRhdGEsIGJhc2VkIG9uIGNyeXB0b2dyYXBoaWMgY2hlY2sgdmFs
dWVzIGdlbmVyYXRlZCBieSB1c2luZyBzeW1tZXRyaWMgb3IgYXN5bW1ldHJpYyBjcnlwdG9ncmFw
aGljIHRlY2huaXF1ZXMsIG9mOg1BcHByb3ZhbCAtIE5vbi1yZXB1ZGlhdGlvbiBvZiBhcHByb3Zh
bCBzZXJ2aWNlIHByb3ZpZGVzIHByb29mIG9mIHdob20gaXMgcmVzcG9uc2libGUgZm9yIGFwcHJv
dmFsIG9mIHRoZSBjb250ZW50IG9mIGEgbWVzc2FnZTsNU2VuZGluZyAtIE5vbi1yZXB1ZGlhdGlv
biBvZiBzZW5kaW5nIHNlcnZpY2UgcHJvdmlkZXMgcHJvb2Ygb2Ygd2hvIHNlbnQgYSBtZXNzYWdl
Ow1PcmlnaW4gLSBOb24tcmVwdWRpYXRpb24gb2Ygb3JpZ2luIHNlcnZpY2UgaXMgYSBjb21iaW5h
dGlvbiBvZiBhcHByb3ZhbCBhbmQgc2VuZGluZyBzZXJ2aWNlcyBhcyBpdCBwcm92aWRlcyBwcm9v
ZiBvZiB3aG9tIGlzIHJlc3BvbnNpYmxlIGZvciBhcHByb3ZhbCBvZiB0aGUgY29udGVudCBhbmQg
d2hvIHNlbnQgYSBtZXNzYWdlOw1TdWJtaXNzaW9uIC0gTm9uLXJlcHVkaWF0aW9uIG9mIHN1Ym1p
c3Npb24gc2VydmljZSBwcm92aWRlcyBwcm9vZiB0aGF0IGEgZGVsaXZlcnkgYXV0aG9yaXR5IGhh
cyBhY2NlcHRlZCBhIG1lc3NhZ2UgZm9yIHRyYW5zbWlzc2lvbjsNVHJhbnNwb3J0IC0gTm9uLXJl
cHVkaWF0aW9uIG9mIHRyYW5zcG9ydCBzZXJ2aWNlIHByb3ZpZGVzIHByb29mIGZvciB0aGUgbWVz
c2FnZSBvcmlnaW5hdG9yIHRoYXQgYSBkZWxpdmVyeSBhdXRob3JpdHkgaGFzIGRlbGl2ZXJlZCBh
IG1lc3NhZ2UgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudDsNUmVjZWlwdCAtIE5vbi1yZXB1ZGlh
dGlvbiBvZiByZWNlaXB0IHNlcnZpY2UgcHJvdmlkZXMgcHJvb2YgdGhhdCB0aGUgcmVjaXBpZW50
IHJlY2VpdmVkIGEgbWVzc2FnZTsNS25vd2xlZGdlIC0gTm9uLXJlcHVkaWF0aW9uIG9mIGtub3ds
ZWRnZSBzZXJ2aWNlIHByb3ZpZGVzIHByb29mIHRoYXQgdGhlIHJlY2lwaWVudCByZWNvZ25pc2Vk
IHRoZSBjb250ZW50IG9mIGEgcmVjZWl2ZWQgbWVzc2FnZTsgYW5kDURlbGl2ZXJ5IC0gTm9uLXJl
cHVkaWF0aW9uIG9mIGRlbGl2ZXJ5IHNlcnZpY2UgaXMgYSBjb21iaW5hdGlvbiBvZiByZWNlaXB0
IGFuZCBrbm93bGVkZ2Ugc2VydmljZXMgYXMgaXQgcHJvdmlkZXMgcHJvb2YgdGhhdCB0aGUgcmVj
aXBpZW50IHJlY2VpdmVkIGFuZCByZWNvZ25pc2VkIHRoZSBjb250ZW50IG9mIGEgbWVzc2FnZS4N
SW4gdGhlIGVsZWN0cm9uaWMgY29tbWVyY2UgZW52aXJvbm1lbnQsIHRoZSB0ZWNobmljYWwgbWVh
bmluZyBvZiB0aGUgdGVybSAiTm9uHnJlcHVkaWF0aW9uIiBlaXRoZXIgc2hpZnRzIHRoZSBvbnVz
IG9mIHByb29mIGZyb20gdGhlIHJlY2lwaWVudCB0byB0aGUgYWxsZWdlZCBzaWduYXRvcnkgb3Ig
ZW50aXJlbHkgZGVuaWVzIHRoZSBzaWduYXRvcnkgdGhlIHJpZ2h0IHRvIHJlcHVkaWF0ZSBhIGRp
Z2l0YWwgc2lnbmF0dXJlLiAgVGhhdCBpcywgaWYgYSBkaWdpdGFsIHNpZ25hdHVyZSBpcyB2ZXJp
ZmllZCBzbyBhcyB0byBpZGVudGlmeSB0aGUgb3duZXIgb2YgdGhlIHByaXZhdGUga2V5IHRoYXQg
d2FzIHVzZWQgdG8gY3JlYXRlIHRoZSBkaWdpdGFsIHNpZ25hdHVyZSBpbiBxdWVzdGlvbiB0aGVu
IGl0IGlzIHRoYXQgcGVyc29uIHdobyBoYXMgdGhlIG9udXMgb2YgcHJvdmluZyB0aGF0IGl0IGlz
IG5vdCB0aGVpciBkaWdpdGFsIHNpZ25hdHVyZS4gIEhlbmNlLCB0aGVyZSBpcyBhIHNoaWZ0IGlu
IHRoZSBidXJkZW4gb2YgcHJvb2YuICBUaGlzIGNyeXB0by10ZWNobmljYWwgcG9zaXRpb24gZG9l
cyBub3QgY29ycmVzcG9uZCB3aXRoIHdoYXQgb2NjdXJzIGluIHRoZSBwYXBlci1iYXNlZCBlbnZp
cm9ubWVudCBmb3IgdHJhZGl0aW9uYWwgc2lnbmF0dXJlcy4NU29tZSBjb21tZW50YXRvcnMgaGF2
ZSBnb25lIHNvIGZhciBhcyB0byBhZHZvY2F0ZSB0aGF0IGlmIHRoZSBkaWdpdGFsIHNpZ25hdHVy
ZSBpcyB2ZXJpZmllZCB0aGVuIHRoZSBvd25lciBvZiB0aGUgcHJpdmF0ZSBrZXkgaXMgcHJldmVu
dGVkIGZyb20gcmVwdWRpYXRpbmcgdGhlIGRpZ2l0YWwgc2lnbmF0dXJlLiAgVGhpcyBpcyBjbGVh
cmx5IHRoZSBwb3NpdGlvbiB0YWtlbiBpbiB0aGUgc2Vjb25kIG1lYW5pbmcgYWJvdmUgb2YgdGhl
IHRlcm0uDUl0IGlzIHN1Ym1pdHRlZCB0aGF0IHRoZSB0ZWNobmljYWwgbWVhbmluZyBvZiBub24t
cmVwdWRpYXRpb24gaXMgd3JvbmcgYXMgaXQgZG9lcyBub3QgdGFrZSBhY2NvdW50IG9mIHRoZSBw
b3NzaWJpbGl0eSBvZiBwcml2YXRlIGtleSB0aGVmdCBhbmQvb3IgaWxsaWNpdCB1c2FnZSBzbyBh
cyB0byBlZmZlY3QgaWRlbnRpdHkgdGhlZnQuICBGdXJ0aGVybW9yZSwgdGhlIHRlY2huaWNhbCBt
ZWFuaW5nIHJlbGF0ZXMgdG8gcG9zdCBzaWduYXR1cmUgZXZlbnRzIGFuZCBub3QgdG8gdGhlIGFj
dHVhbCBzaWduaW5nIG1lY2hhbmlzbS4gIFRoYXQgaXMsIHRoZSB0cmFkaXRpb25hbCBjb25jZXB0
IG9mIHdpdG5lc3NpbmcgdGhlIGFmZml4YXRpb24gb2YgYSB0cmFkaXRpb25hbCBzaWduYXR1cmUg
aXMgdG8gcmVkdWNlIHRoZSBpbmNpZGVuY2Ugb2YgZm9yZ2VkIHNpZ25hdHVyZXMuICBPbmUgb2Yg
dGhlIHByaW1hcnkgcm9sZXMgb2YgdGhlIFRUUCBpcyB0byBlc3RhYmxpc2ggYSByZXBvc2l0b3J5
IG9mIGRpZ2l0YWwgY2VydGlmaWNhdGVzIHRoYXQgZW1ib2R5IHRoZSBwdWJsaWMga2V5IHRoYXQg
Y29ycmVzcG9uZHMgdG8gdGhlIHByaXZhdGUga2V5IHVzZWQgdG8gZWZmZWN0IHRoZSBkaWdpdGFs
IHNpZ25hdHVyZS4gVGhlIGNlcnRpZmljYXRlIGlzIHVzZWQgYnkgdGhlIHJlbHlpbmcgcGFydHkg
dG8gdmVyaWZ5IHRoYXQgdGhlIGRpZ2l0YWwgc2lnbmF0dXJlIHdhcyBlZmZlY3RlZCB1c2luZyB0
aGUgcHJpdmF0ZSBrZXkgdGhhdCBjb3JyZXNwb25kcyB0byB0aGUgcHVibGljIGtleSB0aGF0IGlz
IGVtYm9kaWVkIGluIHRoZSBkaWdpdGFsIGNlcnRpZmljYXRlLiAgSXRzIHVzYWdlIGRvZXMgbm90
IHJlbGF0ZSB0byB0aGUgc2lnbmluZyBwcm9jZXNzIGluIGFueSB3YXkuDUEgZnVydGhlciBjb21w
bGljYXRpbmcgZmFjdG9yIGlzIHRoYXQgUkZDIDI0NTkgWzFdIHNwZWNpZmllcyBhIGJpdCB3aXRo
aW4gdGhlIEtleVVzYWdlIGV4dGVuc2lvbiBjYWxsZWQgdGhlIE5vbnJlcHVkaWF0aW9uIGJpdC4g
IFRoaXMgYml0IGlzICJhc3NlcnRlZCB3aGVuIHRoZSBzdWJqZWN0IHB1YmxpYyBrZXkgaXMgdXNl
ZCB0byB2ZXJpZnkgZGlnaXRhbCBzaWduYXR1cmVzIHVzZWQgdG8gcHJvdmlkZSBhIG5vbi1yZXB1
ZGlhdGlvbiBzZXJ2aWNlIHdoaWNoIHByb3RlY3RzIGFnYWluc3QgdGhlIHNpZ25pbmcgZW50aXR5
IGZhbHNlbHkgZGVueWluZyBzb21lIGFjdGlvbiwgZXhjbHVkaW5nIGNlcnRpZmljYXRlIG9yIENS
TCBzaWduaW5nIi4gICBJdCBpcyBkaWZmaWN1bHQgdG8gYWNjZXB0IHRoYXQgdGhlIHVzZSBvZiBh
IHNpbmdsZSBiaXQgd2l0aGluIGFuIGV4dGVuc2lvbiBvZiBhIGRpZ2l0YWwgY2VydGlmaWNhdGUg
Y2FuIHN1ZmZpY2llbnRseSBhdHRyaWJ1dGUgbm9uLXJlcHVkaWF0aW9uLiAgVGhlIHZlcmlmaWNh
dGlvbiBvZiBhIGRpZ2l0YWwgc2lnbmF0dXJlIGRvZXMgbm90IGxvZ2ljYWxseSBwcm92ZSB0aGF0
IGlzIHdhcyB0aGUgYWxsZWdlZCBzaWduYXRvcnkgd2hvIGFjdHVhbGx5IGFmZml4ZWQgdGhlIGRp
Z2l0YWwgc2lnbmF0dXJlLiAgVGhlIHZlcmlmaWNhdGlvbiBwcm9jZXNzIG9ubHkgZXN0YWJsaXNo
ZXMgdGhhdCB0aGUgcHJpdmF0ZSBrZXkgb2YgdGhlIHBlcnNvbiB3aG9zZSBwdWJsaWMga2V5IGlz
IHNwZWNpZmllZCBpbiB0aGUgZGlnaXRhbCBjZXJ0aWZpY2F0ZQIgd2FzIHVzZWQgdG8gYWZmaXgg
dGhlIGRpZ2l0YWwgc2lnbmF0dXJlLiAgVGhpcyB2ZXJpZmljYXRpb24gcHJvY2VzcyBpcyBhIHBv
c3Qgc2lnbmluZyBtZWNoYW5pc20gYW5kIGRvZXMgbm90IGNvcnJlc3BvbmQgdG8gdGhlIHRydXN0
ZWQgd2l0bmVzc2luZyBtZWNoYW5pc20gZXN0YWJsaXNoZWQgd2l0aGluIHRoZSB0cmFkaXRpb25h
bCBzaWduYXR1cmUgZW52aXJvbm1lbnQuAg1JdCBpcyB0aGUgcHJvbXVsZ2F0aW9uIG9mIHRoZSB1
c2Ugb2YgdGhlIHRlcm0gbm9uLXJlcHVkaWF0aW9uIGFuZCBpdHMgbWVhbmluZyB3aXRoaW4gdGhl
IHRlY2huaWNhbCBjb21tdW5pdHkgdGhhdCBpcyBjb25mdXNpbmcgdGhlIGxlZ2FsIHBvbGljeSBj
b21tdW5pdHkuICBUaGlzIGNvbmZ1c2lvbiBhbHNvIGV4dGVuZCB0byB0aGUgcm9sZSBhbmQgdXNl
IG9mIHRoZSBlbnRpdHkga25vd24gYXMgYSCTVHJ1c3RlZCBUaGlyZCBQYXJ0eZQgYXMgdGhpcyBw
YXJ0eSBkb2VzIG5vdCBwYXJ0aWNpcGF0ZSBpbiB0aGUgc2lnbmluZyBwcm9jZXNzLiAgDVRoaXMg
aXMgYmVzdCBpbGx1c3RyYXRlZCBieSB0aGUgcG9zaXRpb24gdGFrZW4gYnkgdGhlIGRyYWZ0ZXJz
IG9mIHRoZSBVTkNJVFJBTCBNb2RlbCBMYXcuIA1VTkNJVFJBTCBNb2RlbCBMYXcgliBBcnRpY2xl
IDEzAg1UaGVyZSBpcyBhIHN0cm9uZyBtb3ZlbWVudCBhdCBsYXcgZm9yIHRoZXJlIHRvIGJlIGVz
dGFibGlzaGVkIGEgcmV2ZXJzYWwgb2YgdGhlIG9udXMgb2YgcHJvb2YgYXMgcmVnYXJkcyB0byBk
aWdpdGFsIHNpZ25hdHVyZXMuICBUaGUgcG9zaXRpb24gYmVpbmcgcHJvbW90ZWQgaXMgZm9yIHRo
ZSBhbGxlZ2VkIHNpZ25hdG9yeSB0byBoYXZlIHRoZSBvbnVzIG9mIHByb29mIGluIGVzdGFibGlz
aGluZyB0aGF0IGhlL3NoZSBkaWQgbm90IGRpZ2l0YWxseSBzaWduIHRoZSBkb2N1bWVudC4gIA1U
aGVyZSBhcmUgYXQgbGF3IG9ubHkgYSBmZXcgZXhhbXBsZXMgd2hlcmUgYSBkZWZlbmRhbnQgaGFz
IGZyb20gdGhlIGNvbW1lbmNlbWVudCBvZiBhbiBhY3Rpb24gdGhlIG9udXMgb2YgcHJvb2YuICBJ
biB0YXhhdGlvbiBjYXNlcywgaXQgaXMgY29tbW9uIGZvciB0aGUgb251cyBvZiBwcm9vZiB0byBs
aWUgd2l0aCB0aGUgdGF4cGF5ZXIuICBBZnRlciBhbGwsIGl0IGlzIHRoZSB0YXhwYXllciB0aGF0
L3dobyBpcyBjbGFpbWluZyBhIHBhcnRpY3VsYXIgcG9zaXRpb24gYW5kIGFzIHN1Y2ggaXMgaW4g
dGhlIGJldHRlciBwb3NpdGlvbiB0byBkaXNwcm92ZSB0aGUgcmV2ZW51ZSBjb2xsZWN0aW5nIGJv
ZHkncyBjYXNlLg1Bbm90aGVyIGV4YW1wbGUsIG9mIHdoZXJlIHRoZSBvbnVzIG9mIHByb29mIGlz
IHJldmVyc2VkLCBvY2N1cnMgd2hlbiB0aGUgcGxhaW50aWZmIGluIGEgbmVnbGlnZW5jZSBhY3Rp
b24gcmVsaWVzIHVwb24gdGhlIGxlZ2FsIG1heGltIHJlcyBpcHNhIGxvcXVpdHVyAi4gDUluIGEg
bmVnbGlnZW5jZSBhY3Rpb24sIHRoZSBwbGFpbnRpZmYgZ2VuZXJhbGx5IGhhcyB0aGUgb251cyBv
ZiBwcm9vZiBpbiBlc3RhYmxpc2hpbmcgdGhhdCB0aGUgZGVmZW5kYW50IGZhaWxlZCB0byBtZWV0
IHRoZSBzdGFuZGFyZCBvZiBjYXJlIHJlcXVpcmVkIGJ5IGxhdy4gIFRoaXMgb251cyBvZiBwcm9v
ZiBpcyBpbiBlZmZlY3Qgc2hpZnRlZCBpbiBjYXNlcyB3aGVyZSB0aGUgcGxhaW50aWZmIGlzIGFi
bGUgdG8gZXN0YWJsaXNoIHRoYXQgdGhlIGV2ZW50IHdvdWxkIG5vdCBoYXZlIG9jY3VycmVkIGJ1
dCBmb3IgdGhlIG5lZ2xpZ2VuY2Ugb24gdGhlIHBhcnQgb2YgdGhlIGRlZmVuZGFudC4NSW4gc3Vj
aCBjYXNlcywgaXQgaXMgZm9yIHRoZSBkZWZlbmRhbnQgdG8gdGVuZGVyIHN1Y2ggZXZpZGVuY2Ug
YXMgdG8gZGlzcHJvdmUgbmVnbGlnZW5jZS4gIEhlbmNlLCB0aGVyZSBpcyBhIHNoaWZ0aW5nIG9m
IGJ1cmRlbiBvZiBwcm9vZi4NSXQgaGFzIGJlZW4gcHJvcG9zZWQgYXMgcmVnYXJkcyB0byB0aGUg
ZWxlY3Ryb25pYyBjb21tZXJjZSBlbnZpcm9ubWVudCBpbiB0aGUgVU5DSVRSQUwgRWxlY3Ryb25p
YyBDb21tZXJjZSBNb2RlbCBMYXcsIEFydGljbGUgMTMgdGhhdCB0aGUgb251cyBvZiBwcm9vZiBz
aG91bGQgbGllIHVwb24gdGhlIGFsbGVnZWQgc2lnbmF0b3J5IHRvIHNob3cgdGhhdCB0aGUgZGln
aXRhbCBzaWduYXR1cmUgaXMgYSBmb3JnZXJ5LiAgDVRoaXMgaXMgY29udHJhcnkgdG8gdGhlIHBv
c2l0aW9uIGluIHRoZSBwYXBlci1iYXNlZCBlbnZpcm9ubWVudC4NSW4gc3VtbWFyeSwgdGhlIHRo
cmVlIHBvc2l0aW9ucyBhcmU6DSgJRWxlY3Ryb25pYyBDb21tZXJjZSBFbnZpcm9ubWVudCAoQXJ0
aWNsZSAxMyBNb2RlbCBMYXcpDU9udXMgb2YgcHJvb2YgaXMgdXBvbiB0aGUgc2lnbmF0b3J5IHRv
IHByb3ZlIHRoYXQgdGhlIGRpZ2l0YWwgc2lnbmF0dXJlIGlzIGEgZm9yZ2VyeS4NRWxlY3Ryb25p
YyBDb21tZXJjZSBFbnZpcm9ubWVudCAoU2VjdGlvbiAxNSBvZiB0aGUgRWxlY3Ryb25pYyBUcmFu
c2FjdGlvbnMgQWN0IChDV1RIKSAxOTk5AikNVGhlIEVDRUcgaW4gaXRzIDE5OTggcmVwb3J0IHNw
ZWNpZmljYWxseSByZWplY3RlZCBBcnRpY2xlIDEzLCBhcyB0aGUgZWxlY3Ryb25pYyBjb21tZXJj
ZSBlbnZpcm9ubWVudCBzaG91bGQgbm90IGJlIGRpZmZlcmVudCB0byB0aGF0IG9mIHRoZSBwYXBl
ci1iYXNlZCBlbnZpcm9ubWVudC4gIFNlY3Rpb24gMTUgcHJvdmlkZXMgdGhhdCBhIHBlcnNvbiBw
dXJwb3J0aW5nIHRvIGJlIHRoZSBvcmlnaW5hdG9yIG9mIGEgZWxlY3Ryb25pYyBjb21tdW5pY2F0
aW9uIHdpbGwgb25seSBiZSBib3VuZCBieSB0aGUgZWxlY3Ryb25pYyBjb21tdW5pY2F0aW9uIGlm
IGluIGZhY3QgdGhlIGVsZWN0cm9uaWMgY29tbXVuaWNhdGlvbiB3YXMgaW4gZmFjdCBzZW50IGJ5
IHRoYXQgcGVyc29uIHdpdGggdGhlaXIgYXV0aG9yaXR5LiAgVGhpcyBwb3NpdGlvbiBjb3JyZXNw
b25kcyB3aXRoIHRoZSBjb21tb24gbGF3IHBvc2l0aW9uIGFuZCBhcyBzdWNoIHRoZSBvbnVzIG9m
IHByb29mIHdpbGwgbGllIHdpdGggdGhlIHJlbHlpbmcgcGFydHkuDSgJUGFwZXIgQmFzZWQgRW52
aXJvbm1lbnQNT251cyBvZiBwcm9vZiBpcyB1cG9uIHRoZSByZWx5aW5nIHBhcnR5IHRvIHByb3Zl
IHRoYXQgdGhlIHNpZ25hdHVyZSBpcyBub3QgYSBmb3JnZXJ5LiAgDUluIHRoZSBwYXBlci1iYXNl
ZCBlbnZpcm9ubWVudCB0aGVyZSBleGlzdHMgYW4gYWJzb2x1dGUgdHJ1c3RlZCBzeXN0ZW0gYmVj
YXVzZSB0aGUgc2lnbmF0b3J5IGlzIHBsYWNlZCBpbiB0aGUgcG9zaXRpb24gb2YgdG90YWwgY29u
dHJvbCBvdmVyIHRoZSBzaWduaW5nIG1lY2hhbmlzbSBhbmQgdGhlIHNpZ25hdG9yeSBkb2VzIG5v
dCBoYXZlIHRvIHJlbHkgb24gYW55IGV4dGVybmFsIGluZm9ybWF0aW9uIG9yIGJlbGllZiBpbiBv
cmRlciB0byBhZmZpeCBoaXMvaGVyIHNpZ25hdHVyZS4gICBUaGUgc2FtZSBpcyBub3QgdHJ1ZSBp
biB0aGUgZWxlY3Ryb25pYyBjb21tZXJjZSBlbnZpcm9ubWVudCBiZWNhdXNlIHRoZSBzaWduYXRv
cnkgaGFzIHRvIHJlbHkgb24gdGhlIHNpZ25pbmcgbWVjaGFuaXNtIHRvIGFmZml4IGEgZGlnaXRh
bCBzaWduYXR1cmUgb25seSBvbiB0aGUgaW50ZW5kZWQgZG9jdW1lbnQuICANVGVjaG5pY2FsIFZ1
bG5lcmFiaWxpdGllcyBvZiBBcnRpY2xlIDEzIGFuZCB0aGUgQ29tbW9uIExhdyBQb3NpdGlvbg1C
b3RoIHRoZSBDb21tb24gTGF3IHBvc2l0aW9uIGFuZCB0aGUgQXJ0aWNsZSAxMyBwb3NpdGlvbiBp
cyBpbiB0aGUgYXV0aG9yc5Igb3BpbmlvbiBub3Qgc3VzdGFpbmFibGUgdW5sZXNzIHRoZSBzaWdu
aW5nIG1lY2hhbmlzbSBpcyBlZmZlY3RlZCB2aWEgYSB0cnVzdGVkIGVudmlyb25tZW50LiAgSW4g
MTk4NCwgVGhvbXBzb24gc2hvd2VkIHRoYXQgbW9iaWxlIGNvZGUgd2FzIGEgbWFqb3IgcHJvYmxl
bSBhbmQgdGhhdCBpdCB3YXMgcmVsYXRpdmVseSBlYXN5IHRvIGRldmVsb3AuAiANVGhlIGNvbmNl
cm4gYWJvdXQgbW9iaWxlIGNvZGUgaXMgaW5jcmVhc2luZyBhbmQgd2lsbCBiZWNvbWUgYW4gZXZl
biBncmVhdGVyIHByb2JsZW0gYmVjYXVzZSBvZiB0aGUgZGVwbG95bWVudCBvZiBBRFNMIHRlY2hu
b2xvZ3kgYW5kIGNhYmxlIG1vZGVtIGFjY2Vzcy4gAiAgVGhlIHVzZSBvZiBBRFNMIHdpbGwgcGVy
bWl0IHRoZSBnZW5lcmFsIHB1YmxpYyB0byBiZSBwZXJtYW5lbnRseSBjb25uZWN0ZWQgdG8gdGhl
IEludGVybmV0LiAgVGhpcyB3aWxsIHJlc3VsdCBpbjoNUEOScyBoYXZpbmcgYSBwZXJtYW5lbnQg
SVAgYWRkcmVzcyBpbnN0ZWFkIG9mIGJlaW5nIGFsbG9jYXRlZCBhIGR5bmFtaWMgSVAgYWRkcmVz
cyBlYWNoIHRpbWUgdGhlIFBDIGlzIGNvbm5lY3RlZCB0byB0aGUgSW50ZXJuZXQuICBIYXZpbmcg
YSBwZXJtYW5lbnQgSVAgYWRkcmVzcyBpbmNyZWFzZXMgdGhlIHZ1bG5lcmFiaWxpdHkgdG8gYXR0
YWNrcyBieSBoYWNrZXJzIGJlY2F1c2UgaXQgaW5jcmVhc2VzIHRoZSB0aW1lIGJ5IHdoaWNoIHRo
ZSBoYWNrZXIgY2FuIGVmZmVjdCB0aGUgYXR0YWNrLiAgQSBkeW5hbWljIElQIGFkZHJlc3MgcmVk
dWNlcyB0aGUgdGltZSBieSB3aGljaCBhIGhhY2tlciBjYW4gZWZmZWN0IGEgc3VjY2Vzc2Z1bCBh
dHRhY2s7DVBDknMgdGhhdCBhcmUgbm90IGxvY2F0ZWQgYXQgY29tbWVyY2lhbCBjZW50ZXJzIGFu
ZCB0aHVzIGJlaGluZCBhIHNlY3VyaXR5IGZpbHRlciBzdWNoIGFzIGEgZmlyZXdhbGwsIGJlY29t
ZSBleHBvc2VkIHRvIHBvc3NpYmxlIGF0dGFja3MgYnkgaGFja2Vycy4CDVVuZm9ydHVuYXRlbHks
IHRoZXJlIGRvZXMgbm90IGFwcGVhciB0byBiZSBhbnkgdHJ1c3R3b3J0aHkgZmlsdGVyaW5nIHRl
Y2hub2xvZ3kgY29tbWVyY2lhbGx5IGF2YWlsYWJsZSB0aGF0IGNhbiByZXNpZGUgb24gUEOScy4g
IFRoZXJlZm9yZSBzdWNoIFBDknMgYXJlIHZ1bG5lcmFibGUgdG8gYXR0YWNrLiAgT25lIG9mIHRo
ZSBtb3JlIHByZXZhbGVudCBhdHRhY2tzIGluIHJlY2VudCB5ZWFycyBoYXMgYmVlbiB0aGUgdXNl
IG9mIG1vYmlsZSBjb2RlIHN1Y2ggYXMgYSB0cm9qYW4gaG9yc2UgdG8gc3VycmVwdGl0aW91c2x5
IG9wZXJhdGUgY292ZXJ0bHkgb24gY29tcHV0ZXIgc3lzdGVtcy4NSXQgaXMgbm90IGRpZmZpY3Vs
dCB0byBpbWFnaW5lIGEgdmlydXMvdHJvamFuIGhvcnNlIHRoYXQgaXMgZGVzaWduZWQgdG8gc3Rl
YWwgcHJpdmF0ZSBrZXlzLiBUaGlzIGlzIHBhcnRpY3VsYXJseSBlYXN5IGlmIHRoZSBwcml2YXRl
IGtleSBpcyBzdG9yZWQgaW4gYSBjb21tb25seSBrbm93biBmaWxlLCBzdWNoIGFzIJNQR1BQcml2
YXRlS2V5UmluZ5QuICAgVGhlIHZpcnVzL3Ryb2phbiBob3JzZSBjb3VsZCBiZSBhIFZpc3VhbCBC
YXNpYyBtYWNybyB0aGF0IGlzIGF0dGFjaGVkIHRvIE1Td29yZCBkb2N1bWVudHMuICBJdHMgZnVu
Y3Rpb24gY291bGQgYmUgdG8gc2VhcmNoIHRoZSBoYXJkLWRyaXZlIGZvciB0aGUgUEdQIHNlY3Jl
dCBrZXkgcmluZyBhbmQgb25jZSBmb3VuZCB0aGUgdmlydXMvdHJvamFuIGhvcnNlIGNvdWxkIEZU
UCB0aGUgcHJpdmF0ZSBrZXkgdG8gdGhlIHJlbW90ZSBsb2NhbGl0eQIuIFRoZSB2aXJ1cy90cm9q
YW4gaG9yc2UgY291bGQgcGVyZm9ybSBpdHMgZnVuY3Rpb25zIHdpdGhvdXQgdGhlIGtub3dsZWRn
ZSBvZiB0aGUgb3duZXIgb2YgdGhlIFBDLiAgVGhhdCBpcywgdGhlIHZpcnVzL3Ryb2phbiBob3Jz
ZSBjb3VsZCB0dXJuIG9mZiBjZXJ0YWluIGRpc3BsYXkgZnVuY3Rpb25zIHNvIHRoYXQgbm8gZGlh
bG9ndWUgYm94ZXMgYXJlIGRpc3BsYXllZC4gICBPbiBjb21wbGV0aW9uIG9mIHRoZSB0cmFuc2Zl
ciB0aGUgdmlydXMvdHJvamFuIGhvcnNlIHRoZW4gY291bGQgY2hlY2sgdGhlIGFkZHJlc3MgYm9v
ayBvbiB0aGUgdGFyZ2V0IFBDIGFuZCBzZW5kIGEgd29yZCBkb2N1bWVudCB3aXRoIGl0c2VsZiBh
dHRhY2hlZCB0byA1IG90aGVyIHVuc3VzcGVjdGluZyBwZW9wbGUuICBGaW5hbGx5IHRoZSB2aXJ1
cy90cm9qYW4gaG9yc2UgY291bGQgZGVzdHJveSBpdHNlbGYgYW5kIGluIHRoZSBwcm9jZXNzIGRl
bGV0ZSBhbnkgcmVsZXZhbnQgZW50cmllcyBpbiB0aGUgc2VudCBtYWlsIGZvbGRlci4gIFN1Y2gg
YSB2aXJ1cy90cm9qYW4gaG9yc2Ugd291bGQgYmUgYSBjbGVhciB2aW9sYXRpb24gb2YgYSBwcm9w
ZXJseSBmb3JtdWxhdGVkIHNlY3VyaXR5IHBvbGljeS4gIEZvciBleGFtcGxlLCBpZiBvYmplY3Qv
YWN0aXZpdHkgbGFiZWxpbmcgc2VjdXJpdHkgbWVjaGFuaXNtIHBhcmFkaWdtIHdhcyBpbXBsZW1l
bnRlZCB0aGVuIHRoZSB0cm9qYW4gd291bGQgbm90IGJlIGNhcGFibGUgb2YgcGVyZm9ybWluZyBp
dHMgZnVuY3Rpb25zIGFzIHRoZSB0cm9qYW4gaG9yc2Ugd291bGQgbm90IGJlIHJlY29nbmlzZWQg
YnkgdGhlIHNlY3VyaXR5IGtlcm5lbCBhcyBhIHZhbGlkIHN1YmplY3QsIGEgdmFsaWQgb2JqZWN0
IG9yIGEgdmFsaWQgYWN0aXZpdHkCLg1TaGFtaXIgYW5kIFZhbiBTb21lcmVuAiBoYXZlIHByb3Bv
c2VkIGEgbW9iaWxlIGNvZGUgYXR0YWNrIHRoYXQgaXMga25vd24gYXMgdGhlIGx1bmNodGltZSBh
dHRhY2suICBUaGlzIGF0dGFjayBpbnZvbHZlcyB0aGUgZWZmaWNpZW50IHNlYXJjaGluZyBmb3Ig
UlNBIGNyeXB0b2dyYXBoaWMga2V5cyBpbiBsYXJnZSBhbW91bnRzIG9mIGRhdGEgdGhhdCBtYXkg
YmUgc3RvcmVkIG9uIHRoZSBoYXJkLWRyaXZlIG9mIGEgUEMuICBUaGUgcHJpdmF0ZSBrZXkgYW5k
IHRoZSBwdWJsaWMga2V5IGluIHRoZSBSU0EgY3J5cHRvLXN5c3RlbSBjb21wcmlzZXM6DVByaXZh
dGUga2V5OiBlIGFuZCBuDVB1YmxpYyBrZXk6IGQgYW5kIG4uDVRoZSBtb2R1bHVzIG4gZm9ybXMg
dml0YWwgcGFydCBvZiB0aGUgcHJpdmF0ZSBrZXkgYW5kIHRoZSBwdWJsaWMga2V5LiAgVGh1cywg
aWYgYSBoYXJkLWRyaXZlIHdhcyBzZWFyY2hlZCBmb3IgcmFuZG9tbmVzcyBhbmQgd2l0aGluIGFu
eSByYW5kb20gc2VjdGlvbiBsb2NhdGVkIGEgc2VhcmNoIHdhcyB1bmRlcnRha2VuIGZvciBhIGJp
dCBzdHJpbmcgdGhhdCBjb3JyZXNwb25kcyB0byBuLCB0aGVuIHRoZSBwcml2YXRlIGtleSBtYXkg
aGF2ZSBiZWVuIGxvY2F0ZWQuICBUaGUgZWZmaWNpZW5jeSBvZiB0aGlzIGF0dGFjayBpcyB0aGF0
IHRoZSBhbW91bnQgb2YgZGF0YSB0byBiZSBzZWFyY2hlZCBpcyBncmVhdGx5IHJlZHVjZWQuDUl0
IGlzIG5vdCBkaWZmaWN1bHQgdG8gc2VlIHRoYXQgdGhlc2UgYXR0YWNrcyBncmVhdGx5IGhhbXBl
ciBhbiBhbGxlZ2VkIHNpZ25hdG9yeSB3aGVyZSB0aGUgTW9kZWwgTGF3IGlzIGltcGxlbWVudGVk
IHdpdGhpbiBhIGxlZ2lzbGF0aXZlIG1lY2hhbmlzbS4gIEhvdyBjYW4gYW4gYWxsZWdlZCBzaWdu
YXRvcnkgZXZlciBzdWNjZXNzZnVsbHkgZGVueSB0aGF0IGl0IHdhcyBub3QgaGltL2hlciB3aG8g
c2lnbmVkIHRoZSBkb2N1bWVudD8gIFVuZGVyIHRoZSBNb2RlbCBMYXcgcG9zaXRpb24gdGhlIGFs
bGVnZWQgc2lnbmF0b3J5IGhhcyB0aGUgb251cyBvZiBwcm9vZiBpbiBzaG93aW5nIHRoYXQgaXQg
d2FzIG5vdCBoaW0vaGVyIHdobyBzaWduZWQgdGhlIGRvY3VtZW50Lg1GdXJ0aGVybW9yZSB3aXRo
IHRoaXMgdHlwZSBvZiBhdHRhY2sgcmVsYXRpdmVseSBlYXN5IHRvIGltcGxlbWVudDogaG93IGNh
biBhIHJlbHlpbmcgcGFydHkgdW5kZXIgdGhlIGNvbW1vbiBsYXcgcG9zaXRpb24gZXZlciBwcm9k
dWNlIHN1ZmZpY2llbnQgZXZpZGVuY2UgdG8gZXN0YWJsaXNoIHRoYXQgaXMgd2FzIHRoZSBhbGxl
Z2VkIHNpZ25hdG9yeSB3aG8gc2lnbmVkIHRoZSBkb2N1bWVudD8gICBVbmRlciB0aGUgY29tbW9u
IGxhdywgdGhlIHJlbHlpbmcgcGFydHkgaGFzIHRoZSBvbnVzIG9mIHByb29mIGluIGVzdGFibGlz
aGluZyB0aGF0IHRoZSBhbGxlZ2VkIHNpZ25hdG9yeSBkaWQgaW4gZmFjdCBhZmZpeCB0aGF0IHNp
Z25hdHVyZS4gIFRoZSBjb21tb24gbGF3IHBvc2l0aW9uIGhhcyBkZXZlbG9wZWQgdW5kZXIgYSBw
YXBlci1iYXNlZCBlbnZpcm9ubWVudCB3aGVyZSB3aXRuZXNzaW5nIHdhcyB0aGUgdHJ1c3RlZCBt
ZWNoYW5pc20gdG8gcHJldmVudCBub24tcmVwdWRpYXRpb24gb2YgYSBzaWduYXR1cmUuICBXaXRo
IHRoaXMgdHJ1c3RlZCBtZWNoYW5pc20gaXQgd2FzIHJlYXNvbmFibGUgZm9yIHRoZSBvbnVzIG9m
IHByb29mIHRvIGxpZSB1cG9uIHRoZSByZWx5aW5nIHBhcnR5IHRvIHNob3cgdGhhdCB0aGUgYWxs
ZWdlZCBzaWduYXRvcnkgZGlkIGluIGZhY3Qgc2lnbiB0aGUgZG9jdW1lbnQuDVdpdGhvdXQgdGhl
IGltcGxlbWVudGF0aW9uIG9mIGEgdHJ1c3RlZCBzaWduaW5nIG1lY2hhbmlzbXMgaXQgZG9lcyBu
b3QgbWF0dGVyIHdoaWNoIHBvc2l0aW9uIGlzIGFkb3B0ZWQuICBOZWl0aGVyIHBvc2l0aW9uIChN
b2RlbCBsYXcgb3IgQ29tbW9uIExhdykgYWRlcXVhdGVseSBwcm92aWRlcyBhIHNvbHV0aW9uIHRv
IHRoZSBvbnVzIG9mIHByb29mIHJlcXVpcmVtZW50Lg1UcnVzdGVkIENvbXB1dGluZyBTeXN0ZW1z
DUEgdHJ1c3RlZCBjb21wdXRpbmcgc3lzdGVtIGlzIGEgY29tcHV0aW5nIHN5c3RlbSB0aGF0IHBl
cmZvcm1zIGluIGFjY29yZGFuY2Ugd2l0aCBpdHMgZG9jdW1lbnRlZCBzcGVjaWZpY2F0aW9uIGFu
ZCB3aWxsIHByZXZlbnQgYW55IHVuYXV0aG9yaXNlZCBhY3Rpdml0eS4gIFNwZWNpZmljYWxseSBh
IHRydXN0ZWQgY29tcHV0aW5nIHN5c3RlbSBjYW4gYmUgcmVsaWVkIHVwb24gdG8gZW5mb3JjZSBh
IGRvY3VtZW50ZWQgc2VjdXJpdHkgcG9saWN5LiAgU3VjaCBzeXN0ZW1zIGFyZSB1c3VhbGx5IGNs
YXNzaWZpZWQgYXMgcHJvdmlkaW5nIGVpdGhlciBkaXNjcmV0aW9uYXJ5IG9yIG1hbmRhdG9yeSBz
ZWN1cml0eSBlbmZvcmNlbWVudCBwb2xpY2llcyBhbmQgZnVuY3Rpb25hbGl0eS4NVGhlIHJvbGUg
b2YgdHJ1c3RlZCBzeXN0ZW1zIGhhcyBmb3IgbW9yZSB0aGFuIDMwIHllYXJzIGJlZW4gaWRlbnRp
ZmllZCBhcyBhIHByb3BlciBtZWNoYW5pc20gdG8gcHJvdGVjdCB0aGUgY29ycmVjdCBmdW5jdGlv
bmluZyBvZiBhIGNvbXB1dGVyIHN5c3RlbS4NQ29tcHV0ZXIgc3lzdGVtcyBhcmUgY29udGludWFs
bHkgdW5kZXIgdGhyZWF0IG9mIGF0dGFjayBieSBub3Qgb25seSBoYWNrZXJzIGJ1dCBlc3BlY2lh
bGx5IHRocm91Z2ggdGhlIHVzZSBvZiAibW9iaWxlIGNvZGUiLiAgVGhlc2UgYXR0YWNrcyBzaW5j
ZSB0aGUgZGV2ZWxvcG1lbnQgYW5kIGNvbnRpbnVlZCBhZHZhbmNlbWVudCBvZiB0aGUgSW50ZXJu
ZXQgaGF2ZSBzdWJzdGFudGlhbGx5IGluY3JlYXNlZC4NVGhlIG9yaWdpbiBvZiBuZXR3b3JrIHNl
Y3VyaXR5IHdhcyBmaXJzdCBhcHByb2FjaGVkIGluIHRoZSBkZWZlbmNlIGVudmlyb25tZW50IGJ5
IHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgVVMgIlJhaW5ib3cgU2VyaWVzIiBpbiB0aGUgMTk4MJJz
IHdoaWNoIGFkdmFuY2VkIHRoZSBwcm9wb3NpdGlvbiBvZiBjb21wdXRlciBzeXN0ZW0gcHJvdGVj
dGlvbiB0aHJvdWdoIHRoZSBjb25zdHJ1Y3Rpb24gb2YgYSAiVHJ1c3RlZCBDb21wdXRpbmcgQmFz
ZSIuICBUaGUgY2xhc3NpZmljYXRpb24gb2YgdHJ1c3RlZCBzeXN0ZW1zIGhhcyByZWNlbnRseSBi
ZWVuIHN0YW5kYXJkaXNlZCBpbnRlcm5hdGlvbmFsbHkgdW5kZXIgdGhlIGdlbmVyYWwgdGVybSCT
Q29tbW9uIENyaXRlcmlhlCAoSVNPIDE1NDA4KS4NSW4gdGhlIFVTQSBpdCBpcyBub3cgcmVjb2du
aXNlZCB0aGF0IHRoZSBOYXRpb25hbCBJbmZvcm1hdGlvbiBJbmZyYXN0cnVjdHVyZSBpcyBjcml0
aWNhbCB0byB0aGUgZW50aXJlIHNvY2lhbCBmYWJyaWMgb2YgdGhlIFVTIGVjb25vbXkuICBCdXQg
c3VjaCByZWFsaXNhdGlvbiBzaG91bGQgbm90IGJlIFVTIGNlbnRyaWMgYnV0IHJhdGhlciBiZSBh
cHByb2FjaGVkIGZyb20gYSBnbG9iYWwgcGVyc3BlY3RpdmUuICBUaGUgZGV2ZWxvcG1lbnQgb2Yg
dGhlIEdsb2JhbCBJbmZvcm1hdGlvbiBJbmZyYXN0cnVjdHVyZSBhbmQgaXRzIGNvbnZlcnNpb24g
ZnJvbSBhIHB1cmVseSBkZWZlbmNlL2FjYWRlbWljIGVudmlyb25tZW50IHRvIGEgY29tbWVyY2lh
bCBjZW50cmljIHZlaGljbGUgaGFzIGJlZW4gYSBwcmltYXJ5IGltcGV0dXMgaW4gdGhlIGRldmVs
b3BtZW50IG9mIHRoZSBDb21tb24gQ3JpdGVyaWEgYXMgYW4gaW50ZXJuYXRpb25hbCBzdGFuZGFy
ZCAoSVNPKS4gIEJ1dCB0aGUgQ29tbW9uIENyaXRlcmlhIG9ubHkgYWRkcmVzcyB0aGUgc2VjdXJp
dHkgY3JpdGVyaWEgb2Ygc3lzdGVtcyB0aGF0IGhhdmUgYmVlbiBkZXNpZ25lZCBhbmQgbWFudWZh
Y3R1cmVkIGFnYWluc3Qga25vd24gc2VjdXJpdHkgYXJjaGl0ZWN0dXJlLg1UaGUgcHJvYmxlbSBs
aWVzIGluIHRoZSBjb25uZWN0aW9uIG9mIG1hbnkgdW50cnVzdGVkIHN5c3RlbXMgYnkgd2hhdCBl
dmVyIG1lYW5zIHRoZSBwYXJ0aWVzIHNvIHNlbGVjdC4gIENPVFMgcHJvZHVjdHMgaGF2ZSBwcm9s
aWZlcmF0ZWQgdGhlIGNvbXB1dGluZyBsYW5kc2NhcGUgYW5kIHRoZSBwZXJ2YXNpdmVuZXNzIG9m
IHVudHJ1c3RlZCBvcGVyYXRpbmcgc3lzdGVtcyBhbmQgYWxsaWVkIHNvZnR3YXJlIHN1Yi1zeXN0
ZW1zIGhhcyB2aXJ0dWFsbHkgbWFkZSBpdCBpbXBvc3NpYmxlIGZvciB0cnVzdCB0byBiZSBhbGxv
Y2F0ZWQgdG8gYW55IHRyYW5zYWN0aW9uIHRoYXQgaXMgZWZmZWN0ZWQgdXNpbmcgc3VjaCBjb21w
dXRpbmcgc3lzdGVtcy4gSW4gb3JkZXIgdG8gb3ZlcmNvbWUgdGhpcyBzZWN1cml0eSBmbGF3IGl0
IGlzIHBvc3NpYmxlIHRvIGltcGxlbWVudCBoaWdobHkgdHJ1c3RlZCBzdWJzeXN0ZW1zIHdoaWNo
IG1heSBiZSByZWFzb25hYmx5IGFuZCBjb3N0IGVmZmVjdGl2ZWx5IGluY29ycG9yYXRlZCBpbiB1
bnRydXN0ZWQgc3lzdGVtcy4gIEFuIGV4YW1wbGUgb2YgdGhpcyBpcyB0aGUgdW50cnVzdGVkIGNh
c2ggcmVnaXN0ZXIgYW5kIHRoZSBpbmNvcnBvcmF0aW9uIG9mIGEgc2VwYXJhdGUgk3BpbiBwYWSU
IHRoYXQgaXMgYW4gaW50ZWdyYWwgcGFydCBvZiB0aGUgaGlnaGx5IHRydXN0ZWQgRUZUUE9TIHN5
c3RlbSBpbiBBdXN0cmFsaWEuDVRoZSBvbmx5IHBvc2l0aW9uIGF2YWlsYWJsZSBhdCBsYXcgaXMg
Zm9yIHRoZSBkaWdpdGFsIHNpZ25hdHVyZSBtZWNoYW5pc20gdG8gYmUgZWZmZWN0ZWQgdmlhIGEg
dHJ1c3RlZCBjb21wdXRpbmcgc3lzdGVtLiAgU3VjaCBhIGJhc2Ugc2hvdWxkIGJlIGF0IGxlYXN0
IEJsIChUQ1NFQykvRTMoSVRTRUMpLyBvciBldmVuIHBvc3NpYmx5IEIyKFRDU0VDKS9FNCggSVRT
RUMpIG9yIHRoZWlyIGVxdWl2YWxlbnQgaW4gdGhlIENvbW1vbiBDcml0ZXJpYS4NV2hpbGUgc2Vj
dXJpdHkgZnVuY3Rpb25zIGFuZCB0aGVpciByZWxpYWJpbGl0eSBhc3Nlc3NtZW50IGFyZSBhIGJh
c2ljIHJlcXVpcmVtZW50IGZvciBJVFNFQy9UQ1NFQyBldmFsdWF0aW9uIHRoZXJlIGlzIGFuIGV2
ZW4gbW9yZSBmdW5kYW1lbnRhbCBuZWVkIGluIHJlbGF0aW9uIHRvIG92ZXJhbGwgc3lzdGVtIHJl
bGlhYmlsaXR5IGFuZCB0aHVzIHRydXN0LiBUaGUgb3JpZ2luYWwgVENTRUMgbm9taW5hdGVkIHNp
eCBmdW5kYW1lbnRhbCByZXF1aXJlbWVudHMgb2YgYW55IGNvbXB1dGVyIHN5c3RlbSB0aGF0IGFp
bXMgYXQgYXR0YWluaW5nIGEgbGV2ZWwgb2YgdHJ1c3R3b3J0aGluZXNzLiBUaGVzZSB3ZXJlOg1T
ZWN1cml0eSBQb2xpY3k6IFRoZXJlIG11c3QgYmUgYW4gZXhwbGljaXQgYW5kIHdlbGwgZGVmaW5l
ZCBzZWN1cml0eSBwb2xpY3kgZW5mb3JjZWQgYnkgdGhlIHN5c3RlbTsNTWFya2luZzogQWNjZXNz
IGNvbnRyb2wgbGFiZWxzIG11c3QgYmUgYXNzb2NpYXRlZCB3aXRoIG9iamVjdHM7DUlkZW50aWZp
Y2F0aW9uOiBJbmRpdmlkdWFsIHN1YmplY3RzICh1c2VycykgbXVzdCBiZSBpZGVudGlmaWVkOw1B
Y2NvdW50YWJpbGl0eTogQXVkaXQgaW5mb3JtYXRpb24gbXVzdCBiZSBzZWxlY3RpdmVseSBrZXB0
IGFuZCBwcm90ZWN0ZWQgc28gdGhhdCBhY3Rpb25zIGFmZmVjdGluZyBzZWN1cml0eSBjYW4gYmUg
dHJhY2VkIHRvIHRoZSByZXNwb25zaWJsZSBwYXJ0eTsgDUFzc3VyYW5jZTogQ29tcHV0ZXIgc3lz
dGVtIG11c3QgY29udGFpbiBoYXJkd2FyZS9zb2Z0d2FyZSBtZWNoYW5pc21zIHRoYXQgY2FuIGJl
IGluZGVwZW5kZW50bHkgZXZhbHVhdGVkIHRvIHByb3ZpZGUgc3VmZmljaWVudCAgYXNzdXJhbmNl
IHRoYXQgdGhlIHN5c3RlbSBlbmZvcmNlcyB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzOyBhbmQN
Q29udGludW91cyBQcm90ZWN0aW9uOiBUaGUgdHJ1c3RlZCBtZWNoYW5pc20gZW5mb3JjaW5nIHRo
ZXNlIGJhc2ljIHJlcXVpcmVtZW50cyBtdXN0IGJlIGNvbnRpbnVvdXNseSBwcm90ZWN0ZWQgYWdh
aW5zdCB0YW1wZXJpbmcgYW5kL29yIHVuYXV0aG9yaXNlZCBjaGFuZ2VzLiALDVdpdGggdGhlc2Ug
ZnVuZGFtZW50YWwgcmVxdWlyZW1lbnRzIGluIG1pbmQsIElUU0VDIHdlbnQgZnVydGhlciB0aGFu
IFRDU0VDIGFuZCBzZXBhcmF0ZWQgc2VjdXJpdHkgZnVuY3Rpb25zIGZyb20gdGhlaXIgcmVsaWFi
aWxpdHkgYW5kL29yIGFzc2Vzc21lbnQuIEl0IGRlZmluZWQgc2V2ZW4gZXZhbHVhdGlvbiBsZXZl
bHMgdG8gZm9ybSBhICCTdHJ1c3QgaGllcmFyY2h5lCBpbiB0aGUgcmVsaWFibGUgb3BlcmF0aW9u
IG9mIHRoZSBzZWN1cml0eSBmZWF0dXJlcyBvZiBhbiBpbmZvcm1hdGlvbiBzeXN0ZW0uIFNlY3Vy
aXR5IGZ1bmN0aW9ucyB3ZXJlIHRvIGJlIGFzc2Vzc2VkIG9yIGV2YWx1YXRlZCBieSBodW1hbiCT
ZXZhbHVhdG9yc5QgYW5kIGFzIGEgcmVzdWx0IG9mIHRoYXQgZXZhbHVhdGlvbiBhIHNpbXBsZSBt
ZWFzdXJlbWVudCBvciB0YWcgd2FzIHRvIGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgZnVuY3Rpb25z
LiBUaGUgd29yZHMgdXNlZCBhcmUgaW1wb3J0YW50IHNpbmNlIHRoZXkgZW1waGFzaXplIHRoaXMg
YnVpbGRpbmcgb2YgdHJ1c3QgYnkgaHVtYW4gdXNlcnMgaW4gb3ZlcmFsbCBpbmZvcm1hdGlvbiBz
eXN0ZW1zLiAgVGhlIGFzc3VyYW5jZSBsZXZlbHMgYXJlIGFzIGZvbGxvd3M6ICANRTAJSW5hZGVx
dWF0ZSBhc3N1cmFuY2UNRTEJSW5mb3JtYWwgZGVzY3JpcHRpb24gb2YgYXJjaGl0ZWN0dXJhbCBk
ZXNpZ24gb2YgcHJvZHVjdC9zeXN0ZW0gZXhpc3RzOg1GdW5jdGlvbmFsIHRlc3RpbmcgdXNlZCB0
byBjb25maXJtIHRhcmdldCBpcyBtZXQuDQ1FMglFMSBwbHVzOg1JbmZvcm1hbCBkZXNjcmlwdGlv
biBvZiBkZXRhaWxlZCBkZXNpZ24gZXhpc3RzOiALRXZpZGVuY2Ugb2YgZnVuY3Rpb25hbCB0ZXN0
aW5nIHRvIGJlIGV2YWx1YXRlZAtDb25maWd1cmF0aW9uIGNvbnRyb2wgc3lzdGVtIGV4aXN0cwtB
cHByb3ZlZCBkaXN0cmlidXRpb24gcHJvY2VzcyBleGlzdHMNRTMJRTIgcGx1czoNU291cmNlIGNv
ZGUgYW5kL29yIHNjaGVtYXRpY3MgZm9yIGhhcmR3YXJlIHRvIGJlIGV2YWx1YXRlZA1FdmlkZW5j
ZSBvZiB0ZXN0aW5nIG9mIHRoZXNlIG11c3QgYmUgZXZhbHVhdGVkDUU0CUUzIHBsdXM6DVVuZGVy
bHlpbmcgZm9ybWFsIG1vZGVsIG9mIHNlY3VyaXR5IHBvbGljeSBzdXBwb3J0aW5nIHRoZSBzZWN1
cml0eSB0YXJnZXQgZXhpc3RzLCBhbmQNU2VjdXJpdHkgZW5mb3JjaW5nIGZ1bmN0aW9ucywgYXJj
aGl0ZWN0dXJhbCBkZXNpZ24sIGRldGFpbGVkIGRlc2lnbiBzcGVjaWZpZWQgaW4gc2VtaS1mb3Jt
YWwgc3R5bGUNRTUJRTQgcGx1czoNQ2xvc2UgY29ycmVzcG9uZGVuY2UgYmV0d2VlbiBkZXRhaWxl
ZCBkZXNpZ24gYW5kIHNvZnR3YXJlIHNvdXJjZSBjb2RlL2VuZ2luZWVyaW5nIGhhcmR3YXJlIGRl
c2lnbiBkcmF3aW5ncy4NRTYJRTUgcGx1czoNU2VjdXJpdHkgZW5mb3JjaW5nIGZ1bmN0aW9ucyBh
bmQgYXJjaGl0ZWN0dXJhbCBkZXNpZ24gbXVzdCBiZSBzcGVjaWZpZWQgZm9ybWFsbHkgliBjb25z
aXN0ZW50IHdpdGggZm9ybWFsIG1vZGVsIG9mIHNlY3VyaXR5IHBvbGljeS4NVGhlIHVzZSBvZiBh
IHRydXN0ZWQgc3lzdGVtIHdpbGwgc29sdmUgdGhlIHByb2JsZW0gaWRlbnRpZmllZCBhYm92ZSBh
cyByZWdhcmRzIHRvIG1vYmlsZSBjb2RlIGFuZCB0aGUgc3RlYWxpbmcgb2YgY3J5cHRvZ3JhcGhp
YyBrZXlzLiAgSWYgdGhlIHNpZ25pbmcgbWVjaGFuaXNtIGlzIGVmZmVjdGVkIHZpYSBhIHRydXN0
ZWQgc3lzdGVtIG9mIGF0IGxlYXN0IEUzIHdoaWNoIGV2aWRlbmNlcyB0aGUgZnVuY3Rpb25hbGl0
eSBvZiB0aGUgc2lnbmluZyBtZWNoYW5pc20gc28gYXMgdG8gcHJldmVudCB1bmF1dGhvcmlzZWQg
YWNjZXNzIHRvIHRoZSBwcml2YXRlIGtleSB1c2VkIGZvciBzaWduaW5nIHB1cnBvc2VzIG9yIHVu
YXV0aG9yaXplZCBhY3Rpdml0eSB0aGVuIGl0IGlzIHN1Ym1pdHRlZCB0aGF0IHRoZSBjb21tb24g
bGF3IHBvc2l0aW9uIGNhbiBiZSBtYWludGFpbmVkIGluIHRoZSBlbGVjdHJvbmljIGNvbW1lcmNl
IGVudmlyb25tZW50LiAgIEUzIGFsc28gcHJvdmlkZXMgdGhhdCB0aGUgc291cmNlIGNvZGUgaXMg
ZXZhbHVhdGVkIGFuZCB0aHVzIGl0IGlzIHBvc3NpYmxlIHRvIHNob3cgdGhhdCB0aGUgc2lnbmlu
ZyBtZWNoYW5pc20gd2lsbCBvbmx5IHBlcmZvcm0gdGhlIGRlc2lyZWQgZnVuY3Rpb24gYW5kIG5v
IG90aGVyLiAgRnVydGhlciB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIHNlY3VyaXR5IGZlYXR1
cmVzIGNhbiBiZSBhZGVxdWF0ZWx5IGFzc2Vzc2VkIHNvIGFzIHRvIGVuc3VyZSB0aGF0IHRoZSBw
cml2YXRlIGtleSBjYW4gbm90IGJlIHVwbGlmdGVkLiAgV2l0aCB0aGVzZSBmZWF0dXJlcyBpdCBp
cyByZWFzb25hYmxlIGZvciB0aGUgY29tbW9uIGxhdyBwb3NpdGlvbiB0byBiZSBpbXBsZW1lbnRl
ZCBhbmQgdGh1cyBoYXZlIGEgYmFsYW5jZSBiZXR3ZWVuIHRoZSBlbGVjdHJvbmljIGNvbW1lcmNl
IGVudmlyb25tZW50IGFuZCB0aGUgcGFwZXItYmFzZWQgZW52aXJvbm1lbnQuDUNvbmNsdXNpb24N
VGhpcyBwYXBlciBzaG93cyB0aGF0IHRoZSBkZXBsb3ltZW50IG9mIGEgVHJ1c3RlZCBDb21wdXRp
bmcgU3lzdGVtIGZvciBkaWdpdGFsIHNpZ25hdHVyZSBtZWNoYW5pc21zIGlzIHRoZSBvbmx5IHNl
Y3VyZSBvcHRpb24gYW5kIHdpbGwgcmVzdWx0IGluIHRoZSBsZWdhbCBwb3NpdGlvbiB3aGVyZSB0
aGUgb251cyBvZiBwcm9vZiBmb3IgdGhlIGVsZWN0cm9uaWMgZW52aXJvbm1lbnQgd2lsbCBiZSB0
aGUgc2FtZSBhcyBmb3IgdGhlIHBhcGVyLWJhc2VkIGVudmlyb25tZW50LiAgVGhhdCBpcyBpZiBh
IHRydXN0ZWQgY29tcHV0aW5nIHN5c3RlbSBpcyB1c2VkIHRvIGVmZmVjdCBhIGRpZ2l0YWwgc2ln
bmF0dXJlIG1lY2hhbmlzbSB0aGVuIGFuZCBvbmx5IHRoZW4gY2FuIHRoZSBvbnVzIG9mIHByb29m
IGxpZSB3aXRoIHRoZSByZWNpcGllbnQgaW4gdGhlIHNhbWUgbWFubmVyIHRoYXQgZXhpdHMgaW4g
dGhlIHBhcGVyLWJhc2VkIGVudmlyb25tZW50LiAgV2l0aG91dCBhIHRydXN0ZWQgY29tcHV0aW5n
IHN5c3RlbSBuZWl0aGVyIHBhcnR5ICh0aGUgc2lnbmVyIG9yIHRoZSByZWNpcGllbnQpIGlzIGlu
IGEgcG9zaXRpb24gdG8gcHJvZHVjZSB0aGUgbmVjZXNzYXJ5IGV2aWRlbmNlIHRvIHByb3ZlIHRo
ZWlyIHJlc3BlY3RpdmUgY2FzZS4NSGVuY2UgdGhlIGltcGxlbWVudGF0aW9uIG9mIGEgdHJ1c3Rl
ZCBjb21wdXRpbmcgc3lzdGVtIHdpbGwgYWxsb3cgZm9yIGEgYmFsYW5jZSBiZXR3ZWVuIHRoZSAy
IGVudmlyb25tZW50cy4gIFRoZXJlZm9yZSwgbm8gcGFydHkgd2lsbCBiZSBkaXNhZHZhbnRhZ2Vk
Lg1UaGUgaXNzdWVzIHJhaXNlZCBpbiB0aGlzIHBhcGVyIGFyZSBoaWdobHkgaW1wb3J0YW50IHRv
IHRoZSBpbnZlc3RtZW50L2ZpbmFuY2UgY29tbXVuaXR5IGFzIHN1Y2ggaXNzdWVzIG5lZWQgdG8g
YmUgdW5kZXJzdG9vZCBzbyBhcyB0byBlbmdlbmRlciB0aGUgbmVjZXNzYXJ5IGNvbmZpZGVuY2Ug
cmVxdWlyZWQgdG8gZWZmZWN0IGdsb2JhbCB0cmFkaW5nIG9wcG9ydHVuaXRpZXMuICBGdXJ0aGVy
IHRoZSBpc3N1ZXMgcmFpc2VkIGluIHRoaXMgcGFwZXIgc2hvdWxkIGJlIHVuZGVyc3Rvb2QgYnkg
dGhlIHJlbGV2YW50IHBvbGljeSBsYXcgbWFraW5nIGNvbW11bml0eSBzbyBhcyB0byBlZmZlY3Qg
dGhlIG5lY2Vzc2FyeSBiYWxhbmNlIGJldHdlZW4gdGhlIHBhcGVyLWJhc2VkIGVudmlyb25tZW50
IGFuZCB0aGUgZW1lcmdpbmcgZ2xvYmFsIGVsZWN0cm9uaWMgY29tbWVyY2UgZW52aXJvbm1lbnQu
DQ0TIFBBR0UgFDEzFQ0NTWNDdWxsYWdoLCBBLiBhbmQgQ2FlbGxpLCBXIAkTIERBVEUgXEAgIk1N
L2RkL3l5IiAUMTIvMTUvOTkVDQ0TIEZJTEVOQU1FICBcKiBNRVJHRUZPUk1BVCAUQm9uZCBVbmkV
ICAgMTcvNi85MiBTDCAgDQ0NAiggIEFkcmlhbiBNY0N1bGxhZ2ggQi5BcHAuU2MgKENvbXB1dGlu
ZykgKFEuSS5UKSwgTC5MLkIuKEhvbnMpIChRLkkuVC4pLCBQaC4gRC4gQ2FuZGlkYXRlIChRLlUu
VCksIE5hdGlvbmFsIERpcmVjdG9yIGZvciBFbGVjdHJvbmljIENvbW1lcmNlLCBHYWRlbnMgTGF3
eWVycywgQnJpc2JhbmUsIEF1c3RyYWxpYS4LC1Byb2Zlc3NvciBXaWxsaWFtIENhZWxsaSBCLlNj
LihIb25zKSAoTmV3Y2FzdGxlKSwgUGguRC4gKEFOVSksIEhlYWQgb2YgU2Nob29sIG9mIERhdGEg
Q29tbXVuaWNhdGlvbnMsIFF1ZWVuc2xhbmQgVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5IChRVVQp
LEZvcm1lcmx5IERpcmVjdG9yIG9mIHRoZSBJbmZvcm1hdGlvbiBTZWN1cml0eSBSZXNlYXJjaCBD
ZW50ZXIsIFFVVC4gDQIgVGhhdCBpcyB0aGUgcGFydGllcyB3aWxsIG5vdCBhdCB0aGUgdGltZSBv
ZiB0cmFuc2FjdGluZyBoYXZlIGZhY2UgdG8gZmFjZSBkaWFsb2d1ZS4NAiBCYW5rIGZvciBJbnRl
cm5hdGlvbmFsIFNldHRsZW1lbnRzIJYgUmVwb3J0IE5vLiAzNSCTUmlzayBNYW5hZ2VtZW50IGZv
ciBFbGVjdHJvbmljIEJhbmtpbmcgYW5kIEVsZWN0cm9uaWMgTW9uZXkgQWN0aXZpdGllc5QgTWFy
Y2ggMTk5ODsgEyBIWVBFUkxJTksgaHR0cDovL3d3dy5iaXMub3JnL3B1YmwvaW5kZXguaHRtIAEU
aHR0cDovL3d3dy5iaXMub3JnL3B1YmwvaW5kZXguaHRtFSBhY2Nlc3NlZCBvbiAxNSBEZWNlbWJl
ciAxOTk5DXNlZSBhbHNvIJNDb21tdW5pY2F0aW9uIGZyb20gdGhlIENvbW1pc3Npb24gdG8gdGhl
IEV1cm9wZWFuIFBhcmxpYW1lbnQtIHRoZSBDb3VuY2lsLCB0aGUgRWNvbm9taWMgYW5kIFNvY2lh
bCBDb21taXR0ZWUgYW5kIHRoZSBDb21taXR0ZWUgb2YgdGhlIFJlZ2lvbnMtIJFQcm9wb3NhbCBm
b3IgYSBFdXJvcGVhbiBQYXJsaWFtZW50IGFuZCBDb3VuY2lsIERpcmVjdGl2ZSBvbiBhIENvbW1v
biBGcmFtZXdvcmsgZm9yIEVsZWN0cm9uaWMgU2lnbmF0dXJlc5IglCAgQ09NKDE5OTgpMjk3Zmlu
YWwsIDEzLjA1Ljk4DQIgk0FtZXJpY2FuIEJhciBBc3NvY2lhdGlvbiBHdWlkZWxpbmVzIGZvciBE
aWdpdGFsIFNpZ25hdHVyZXOUCyATSFlQRVJMSU5LICJodHRwOi8vd3d3LmFiYW5ldC5vcmcvc2Np
dGVjaC9lYy9pc2MvZHNnZnJlZS5odG1sIgEUaHR0cDovL3d3dy5hYmFuZXQub3JnL3NjaXRlY2gv
ZWMvaXNjL2RzZ2ZyZWUuaHRtbBUgICAgIGFjY2Vzc2VkIG9uIDE1IERlY2VtYmVyIDE5OTkNAiBM
J0VzdHJhbmdlICAgdi4gIEdyYXVjb2IgIFsxOTM0XSAyIEsuQi4gMzk0LgsgU2VlIGFsc28gOiBN
Y0N1bGxhZ2ggQS4sIENhZWxsaSBXLiwgTGl0dGxlIFAuLCCTRWxlY3Ryb25pYyBTaWduYXR1cmVz
IJYgVW5kZXJzdGFuZCAgdGhlICBQYXN0IHRvIERldmVsb3AgdGhlIEZ1dHVyZZQgMTk5OCBVTlNX
TEo7C2FjY2Vzc2VkIG9uIDE1IERlY2VtYmVyIDE5OTkgICAgEyBIWVBFUkxJTksgaHR0cDovL3d3
dy5sYXcudW5zdy5lZHUuYXUvdW5zd2xqL2Vjb21tZXJjZS9tY2N1bGxhZ2guaHRtbCABFGh0dHA6
Ly93d3cubGF3LnVuc3cuZWR1LmF1L3Vuc3dsai9lY29tbWVyY2UvbWNjdWxsYWdoLmh0bWwVDQIg
VW5jb25zY2lvbmFibGUgY29uZHVjdCByZXN0cyB1cG9uIHRoZSBjb25jZXB0IG9mIGluZXF1YWxp
dHkgb2YgYmFyZ2FpbmluZyBwb3dlci4gVGhlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgY29uY2Vw
dCBhcmU6DVVuY29uc2Npb25hYmxlIGludm9sdmVzIHRoZSBvYnRhaW5pbmcsIGJ5IG9uZSBwYXJ0
eSB0byBhIHRyYW5zYWN0aW9uLCBvZiBhbiB1bmZhaXIgYWR2YW50YWdlIGFnYWluc3QgdGhlIGJl
dHRlciBqdWRnZW1lbnQgb2YgdGhlIG90aGVyIHdlYWtlciBwYXJ0eSB0byB0aGUgdHJhbnNhY3Rp
b247DVRoZSBkb21pbmFudCBwYXJ0eSBrbm93aW5nIGVpdGhlciBhY3R1YWxseSBvciBieSBpbXB1
dGF0aW9uIG9mIHRoZSBkaXNhZHZhbnRhZ2U7DUluIG1hbnkgY2FzZXMgdGhlcmUgaXMgYSBzdHJp
a2luZyBkaXNwYXJpdHkgaW4gdGhlIHZhbHVlIG9mIHRoZSBjb25zaWRlcmF0aW9uIHBhc3Npbmcg
YmV0d2VlbiB0aGUgcGFydGllcy4NU2VlIE0uTC4gQ29wZSCTVGhlIFJldmlldyBvZiBVbmNvbnNj
aW9uYWJsZSBCYXJnYWlucyBpbiBFcXVpdHmULiAoMTk4MykgNTcgQS5MLkouIDI3OTsLQ29tbWVy
Y2lhbCBCYW5rIG9mIEF1c3RyYWxpYSB2LiBBbWFkaW8gKDE5ODItODMpIDE1MSBDLkwuUi4gNDQ3
Lg0CIEZyYXVkIGludm9sdmVzIGFueSBpbnRlbnRpb25hbCBjb25kdWN0IHRoYXQgaGFzIHRoZSBw
dXJwb3NlIG5vdCBuZWNlc3NhcmlseSB0aGUgc29sZSBvciBkb21pbmFudCBwdXJwb3NlIG9mIG9i
dGFpbmluZyBzb21lIGdhaW4gZnJvbSB0aGUgcGFydHkgd2hvIGlzIHRoZSBzdWJqZWN0IG9mIHRo
ZSBmcmF1ZHVsZW50IGNvbmR1Y3QuICBTZWUgRWFybCBvZiBBeWxlc2ZvcmQgdi4gTW9ycmlzICgx
ODczKSA4IEwuUi4gQ2guIEFwcC4gNDg0OiANAiBVbmR1ZSBpbmZsdWVuY2UgaW52b2x2ZXMgYSBz
aXR1YXRpb24gd2hlcmUgYSBwZXJzb24gaGFzIHRoZSBhYmlsaXR5IHRvIHRha2UgY29udHJvbCBv
dmVyIGFub3RoZXKScyBpbmRlcGVuZGVudCB3aWxsIHBvd2VyIHNvIHRoYXQgdGhlIGlubm9jZW50
IHBlcnNvbiBpcyBub3QgYWJsZSB0byByZXNpc3QgdGhlIGFjdGlvbnMgb2YgdGhlIGZpcnN0IHBl
cnNvbi4gIFN1Y2ggY2FzZXMgdXN1YWxseSBpbnZvbHZlIHNvbWUgZGlzYWJpbGl0eSBhcyBpbiBC
bG9tbGV5IHYgUnlhbiAoMTk1NikgOTkgQy5MLlIuIDM2Mi4gIE1yLiBSeWFuIHdhcyBhIHNldmVy
ZSBhbGNvaG9saWMgYW5kIHdhcyBuZXZlciBpbiBhIHBvc2l0aW9uIHRvIHJlc2lzdCB0aGUgYWN0
aW9ucyBvZiBNci4gQnJvbWxleS4NDQIgk1VOQ0lUUkFMIE1vZGVsIExhdyBvbiBFbGVjdHJvbmlj
IENvbW1lcmNlIHdpdGggR3VpZGUgdG8gRW5hY3RtZW50lCBBcnRpY2xlIDEzLgsgE0hZUEVSTElO
SyAiaHR0cDovL3d3dy51bi5vci5hdC91bmNpdHJhbC90ZXh0cy9lbGVjdGNvbS9tbC1lYy5odG0i
ARRodHRwOi8vd3d3LnVuLm9yLmF0L3VuY2l0cmFsL3RleHRzL2VsZWN0Y29tL21sLWVjLmh0bRUg
ICAgYWNjZXNzZWQgb24gMTUgRGVjZW1iZXIgMTk5OSANAiBNY0N1bGxhZ2ggQS4sIENhZWxsaSBX
LiwgTGl0dGxlIFAuLCCTRWxlY3Ryb25pYyBTaWduYXR1cmVzIJYgVW5kZXJzdGFuZCB0aGUgUGFz
dCB0byBEZXZlbG9wIHRoZSBGdXR1cmWUIDE5OTggVU5TV0xKLiBUaGVtYXRpYyBJc3N1ZSA6CyAT
IEhZUEVSTElOSyBodHRwOi8vd3d3Lmxhdy51bnN3LmVkdS5hdS91bnN3bGovZWNvbW1lcmNlL21j
Y3VsbGFnaC5odG1sIAEUaHR0cDovL3d3dy5sYXcudW5zdy5lZHUuYXUvdW5zd2xqL2Vjb21tZXJj
ZS9tY2N1bGxhZ2guaHRtbBUgC2FjY2Vzc2VkIG9uIDE1IERlY2VtYmVyIDE5OTkNAiBTaG9ydGVy
IE94Zm9yZCBEaWN0aW9uYXJ5LCBUaG9tcHNvbiwgRC4gKEVkKSAxOXRoIEVkaXRpb24sIENsYXJl
bmRvbiBQcmVzcywLk1JlcHVkaWF0ZZQgMSAoYSkgZGlzb3duLCBkaXNhdm93LCByZWplY3QsIChi
KSByZWZ1c2UgZGVhbGluZ3Mgd2l0aCwgKGMpIGRlbnkuIA0CIEliaWQuIA0CIFRoZSBhYm92ZSBw
b3NpdGlvbiBpcyB0aGUgc2FtZSBpbiBtYW55IGp1cmlzZGljdGlvbnMuDQIgUmVwb3J0IG9mIHRo
ZSBFbGVjdHJvbmljIENvbW1lcmNlIEV4cGVydCBHcm91cCB0byB0aGUgQXR0b3JuZXkgR2VuZXJh
bCA6IJNFbGVjdHJvbmljIENvbW1lcmNlOiBCdWlsZGluZyB0aGUgTGVnYWwgRnJhbWV3b3JrIC0g
MzEgbWFyY2ggMTk5OJQLOhNIWVBFUkxJTksgImh0dHA6Ly9sYXcuZ292LmF1L2FnaG9tZS9hZHZp
c29yeS9lY2VnL2VjZWcuaHRtIgEUaHR0cDovL2xhdy5nb3YuYXUvYWdob21lL2Fkdmlzb3J5L2Vj
ZWcvZWNlZy5odG0VICAgICAgICBhY2Nlc3NlZCBvbiAxNSBEZWNlbWJlciAxOTk5DQIgQ2FlbGxp
LCBXLiwgTG9uZ2xleSwgRC4sIFNoYWluLCBNLiCTSW5mb3JtYXRpb24gU2VjdXJpdHkgSGFuZGJv
b2uUIE1hY01pbGxhbiBQcmVzcyBMaW1pdGVkLCAxOTkxDQIgaWJpZC4NAiBTY2huZWllciwgQi4s
IJMgQXBwbGllZCBDcnlwdG9ncmFwaHkglnByb3RvY29scywgYWxnb3JpdGhtcyBhbmQgc291cmNl
IGNvZGUgaW4gQ5QgMTk5NiAoMmVkKSwgSm9obiBXaWxleSAmIFNvbnMgYXQgcGFnZSAyLg0CIEdy
YW5pdG8sIFIsIGFuZCBIb3ZzdPgsIEEuIChlZGl0b3JzKSwgIJNHdWlkZWxpbmVzIGZvciB0aGUg
dXNlIGFuZCBtYW5hZ2VtZW50IG9mIFRydXN0ZWQgVGhpcmQgUGFydHkgc2VydmljZXOULCBKVEMg
MS4yNy4xOShXb3JraW5nIERyYWZ0KQ0CIE9uZSBvZiB0aGUgcHJpbWFyeSByb2xlcyBvZiBhIFRU
UCBpcyB0b28gcmVsaWFibHkgYXV0aGVudGljYXRlIHRoZSBpZGVudGl0eSBvZiB0aGUgaG9sZGVy
IG9mIHRoZSBrZXkgcGFpciwgb2Ygd2hpY2ggdGhlIHB1YmxpYyBrZXkgaXMgZW1ib2RpZWQgaW4g
dGhlIGRpZ2l0YWwgY2VydGlmaWNhdGUuIA0CIFRoZSBpc3N1ZSBvZiB3aXRuZXNzaW5nIHRoZSBh
ZmZpeGluZyBvZiBkaWdpdGFsIHNpZ25hdHVyZXMgaXMgbW9yZSBmdWxseSBleHBsYWluZWQgaW4g
TWNDdWxsYWdoIGV0IGFsLiBJYmlkLiBub3RlIDkNAiBBcnRpY2xlIDEzLiBBdHRyaWJ1dGlvbiBv
ZiBkYXRhIG1lc3NhZ2VzIA0oMSkgQSBkYXRhIG1lc3NhZ2UgaXMgdGhhdCBvZiB0aGUgb3JpZ2lu
YXRvciBpZiBpdCB3YXMgc2VudCBieSB0aGUgb3JpZ2luYXRvciBpdHNlbGYuIAsoMikgQXMgYmV0
d2VlbiB0aGUgb3JpZ2luYXRvciBhbmQgdGhlIGFkZHJlc3NlZSwgYSBkYXRhIG1lc3NhZ2UgaXMg
ZGVlbWVkIHRvIGJlIHRoYXQgb2YgdGhlIG9yaWdpbmF0b3IgaWYgaXQgd2FzIHNlbnQ6IAsoYSkg
YnkgYSBwZXJzb24gd2hvIGhhZCB0aGUgYXV0aG9yaXR5IHRvIGFjdCBvbiBiZWhhbGYgb2YgdGhl
IG9yaWdpbmF0b3IgaW4gcmVzcGVjdCBvZiB0aGF0IGRhdGEgbWVzc2FnZTsgb3IgCyhiKSBieSBh
biBpbmZvcm1hdGlvbiBzeXN0ZW0gcHJvZ3JhbW1lZCBieSwgb3Igb24gYmVoYWxmIG9mLCB0aGUg
b3JpZ2luYXRvciB0byBvcGVyYXRlIGF1dG9tYXRpY2FsbHkuCygzKSBBcyBiZXR3ZWVuIHRoZSBv
cmlnaW5hdG9yIGFuZCB0aGUgYWRkcmVzc2VlLCBhbiBhZGRyZXNzZWUgaXMgZW50aXRsZWQgdG8g
cmVnYXJkIGEgZGF0YSBtZXNzYWdlIGFzIGJlaW5nIHRoYXQgb2YgdGhlIG9yaWdpbmF0b3IsIGFu
ZCB0byBhY3Qgb24gdGhhdCBhc3N1bXB0aW9uLCBpZjogCyhhKSBpbiBvcmRlciB0byBhc2NlcnRh
aW4gd2hldGhlciB0aGUgZGF0YSBtZXNzYWdlIHdhcyB0aGF0IG9mIHRoZSBvcmlnaW5hdG9yLCB0
aGUgYWRkcmVzc2VlIHByb3Blcmx5IGFwcGxpZWQgYSBwcm9jZWR1cmUgcHJldmlvdXNseSBhZ3Jl
ZWQgdG8gYnkgdGhlIG9yaWdpbmF0b3IgZm9yIHRoYXQgcHVycG9zZTsgb3IgCyhiKSB0aGUgZGF0
YSBtZXNzYWdlIGFzIHJlY2VpdmVkIGJ5IHRoZSBhZGRyZXNzZWUgcmVzdWx0ZWQgZnJvbSB0aGUg
YWN0aW9ucyBvZiBhIHBlcnNvbiB3aG9zZSByZWxhdGlvbnNoaXAgd2l0aCB0aGUgb3JpZ2luYXRv
ciBvciB3aXRoIGFueSBhZ2VudCBvZiB0aGUgb3JpZ2luYXRvciBlbmFibGVkIHRoYXQgcGVyc29u
IHRvIGdhaW4gYWNjZXNzIHRvIGEgbWV0aG9kIHVzZWQgYnkgdGhlIG9yaWdpbmF0b3IgdG8gaWRl
bnRpZnkgZGF0YSBtZXNzYWdlcyBhcyBpdHMgb3duLiALKDQpIFBhcmFncmFwaCAoMykgZG9lcyBu
b3QgYXBwbHk6IAsoYSkgYXMgb2YgdGhlIHRpbWUgd2hlbiB0aGUgYWRkcmVzc2VlIGhhcyBib3Ro
IHJlY2VpdmVkIG5vdGljZSBmcm9tIHRoZSBvcmlnaW5hdG9yIHRoYXQgdGhlIGRhdGEgbWVzc2Fn
ZSBpcyBub3QgdGhhdCBvZiB0aGUgb3JpZ2luYXRvciwgYW5kIGhhZCByZWFzb25hYmxlIHRpbWUg
dG8gYWN0IGFjY29yZGluZ2x5OyBvciALKGIpIGluIGEgY2FzZSB3aXRoaW4gcGFyYWdyYXBoICgz
KShiKSwgYXQgYW55IHRpbWUgd2hlbiB0aGUgYWRkcmVzc2VlIGtuZXcgb3Igc2hvdWxkIGhhdmUg
a25vd24sIGhhZCBpdCBleGVyY2lzZWQgcmVhc29uYWJsZSBjYXJlIG9yIHVzZWQgYW55IGFncmVl
ZCBwcm9jZWR1cmUsIHRoYXQgdGhlIGRhdGEgbWVzc2FnZSB3YXMgbm90IHRoYXQgb2YgdGhlIG9y
aWdpbmF0b3IuIAsoNSkgV2hlcmUgYSBkYXRhIG1lc3NhZ2UgaXMgdGhhdCBvZiB0aGUgb3JpZ2lu
YXRvciBvciBpcyBkZWVtZWQgdG8gYmUgdGhhdCBvZiB0aGUgb3JpZ2luYXRvciwgb3IgdGhlIGFk
ZHJlc3NlZSBpcyBlbnRpdGxlZCB0byBhY3Qgb24gdGhhdCBhc3N1bXB0aW9uLCB0aGVuLCBhcyBi
ZXR3ZWVuIHRoZSBvcmlnaW5hdG9yIGFuZCB0aGUgYWRkcmVzc2VlLCB0aGUgYWRkcmVzc2VlIGlz
IGVudGl0bGVkIHRvIHJlZ2FyZCB0aGUgZGF0YSBtZXNzYWdlIGFzIHJlY2VpdmVkIGFzIGJlaW5n
IHdoYXQgdGhlIG9yaWdpbmF0b3IgaW50ZW5kZWQgdG8gc2VuZCwgYW5kIHRvIGFjdCBvbiB0aGF0
IGFzc3VtcHRpb24uIFRoZSBhZGRyZXNzZWUgaXMgbm90IHNvIGVudGl0bGVkIHdoZW4gaXQga25l
dyBvciBzaG91bGQgaGF2ZSBrbm93biwgaGFkIGl0IGV4ZXJjaXNlZCByZWFzb25hYmxlIGNhcmUg
b3IgdXNlZCBhbnkgYWdyZWVkIHByb2NlZHVyZSwgdGhhdCB0aGUgdHJhbnNtaXNzaW9uIHJlc3Vs
dGVkIGluIGFueSBlcnJvciBpbiB0aGUgZGF0YSBtZXNzYWdlIGFzIHJlY2VpdmVkLiALKDYpIFRo
ZSBhZGRyZXNzZWUgaXMgZW50aXRsZWQgdG8gcmVnYXJkIGVhY2ggZGF0YSBtZXNzYWdlIHJlY2Vp
dmVkIGFzIGEgc2VwYXJhdGUgZGF0YSBtZXNzYWdlIGFuZCB0byBhY3Qgb24gdGhhdCBhc3N1bXB0
aW9uLCBleGNlcHQgdG8gdGhlIGV4dGVudCB0aGF0IGl0IGR1cGxpY2F0ZXMgYW5vdGhlciBkYXRh
IG1lc3NhZ2UgYW5kIHRoZSBhZGRyZXNzZWUga25ldyBvciBzaG91bGQgaGF2ZSBrbm93biwgaGFk
IGl0IGV4ZXJjaXNlZCByZWFzb25hYmxlIGNhcmUgb3IgdXNlZCBhbnkgYWdyZWVkIHByb2NlZHVy
ZSwgdGhhdCB0aGUgZGF0YSBtZXNzYWdlIHdhcyBhIGR1cGxpY2F0ZQ0NAiAgTGFtYm9zIHYuIENv
bW1vbndlYWx0aCBvZiBBdXN0cmFsaWEgKDE5NjctNjgpIDQxIEEuTC5SLiAxODANAiBUaGlzIHBv
c2l0aW9uIGhhcyBhbHNvIGJlZW4gYWNjZXB0ZWQgYnkgdGhlIFVLIEdvdmVybm1lbnQgYXMgcHJv
bW90ZWQgaW4gdGhlIGRyYWZ0ICCTRWxlY3Ryb25pYyBDb21tdW5pY2F0aW9ucyBBY3SUDQIgIFRo
b21wc29uLCBLLiCTUmVmbGVjdGlvbnMgb24gVHJ1c3RpbmcgVHJ1c3SULCByZXByaW50ZWQgaW4g
k0NvbXB1dGVycyBVbmRlciBBdHRhY2sgliBJbnRydWRlcnMsIFdvcm1zIGFuZCBWaXJ1c2VzlCBE
ZW5uaW5nLCBQLiAoZWRpdG9yKSBBZGRpc29uLVdlc3NsZXkgUHVibGlzaGluZyBDb21wYW55LCAx
OTkwLg0CIFNlcmJhbiwgQy4sIJRTZWN1cml0eSBJc3N1ZXMgZm9yIJFBbHdheXMgb26SIERldmlj
ZXM6IEFEU0wgYW5kIENhYmxlIE1vZGVtIEFjY2Vzc5QgQVQmVCAxOTk5LCB1bnB1Ymxpc2hlZCBj
b3B5IG9mIHRoaXMgcGFwZXIgd2FzIGdpdmVuIHRvIHRoZSBhdXRob3JzIGFuZCBpcyBpbiB0aGVp
ciBwb3NzZXNzaW9uLg0CIEliaWQuDQIgCVRoZSBzZWNyZXQga2V5IHJpbmcgaW4gUEdQIGlzIHVz
dWFsbHkgZW5jcnlwdGVkIHdpdGggYSBtdWNoIHNpbXBsZXIgY3J5cHRvLXN5c3RlbS4gIEFsc28g
dGhlIGtleSByaW5nIGlzIHN1YmplY3QgdG8gYSBwYXNzIHBocmFzZSBidXQgdGhpcyBjYW4gdXN1
YWxseSBiZSBicm9rZW4gdXNpbmcgb25lIG9mIHRoZSBoYWNrZXIgcHJvZ3JhbXMgYXZhaWxhYmxl
IG9uIHRoZSBJbnRlcm5ldCBzdWNoIGFzIGNyYWNrZXIsIFNhdGFuIG9yIGNvcHMuIA0CIEJlbGws
IEQuRS4gICYgTGEgUGFkdWxhLCBMLkouIJNTZWN1cmUgQ29tcHV0ZXIgU3lzdGVtIDogVW5pZmll
ZCBFeHBvc2l0aW9uIGFuZCBNdWx0aWNzIEludGVycHJldGF0aW9ulCBFU0QtVFItNzUtMzA2LiAg
TWFyY2ggMTk3NiwgTWl0cmUgQ29ycG9yYXRpb24NAiBTaGFtaXIsIEEgJiBWYW4gU29tZXJlbiwg
Ti4gk1BsYXlpbmcgaGlkZSBhbmQgc2VlayB3aXRoIHN0b3JlZCBrZXlzlAtsb2NhdGVkIGF0IBMg
SFlQRVJMSU5LIGh0dHA6Ly93d3cubmNpcGhlci5jb20vcHJvZHVjdHMvZmlsZXMvcGFwZXJzL2Fu
Z3VpbGxhL2tleWhpZGUyLnBkZiABFGh0dHA6Ly93d3cubmNpcGhlci5jb20vcHJvZHVjdHMvZmls
ZXMvcGFwZXJzL2FuZ3VpbGxhL2tleWhpZGUyLnBkZhUgC2FjY2Vzc2VkIG9uIDE1IERlY2VtYmVy
IDE5OTkuDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAACoEAADqBAAAAgUAAIsF
AACdBQAAngUAAMkFAADKBQAAzAUAAPgFAAAFBgAAFgsAABcLAADyCwAA8wsAAMwMAADNDAAAzgwA
APMPAAAiEAAAKREAACoRAABwEQAAAxIAAAQSAAAnEgAAKBIAAFISAABTEgAAVBIAAPMSAAD0EgAA
rBMAAK0TAABIFAAASRQAAL0UAAC+FAAAuRcAALoXAAD7FwAA/BcAAMMaAABPGwAAERwAAD8cAACG
HAAAqBwAALEcAAC9HAAAzBwAANocAADcHAAA5xwAAAEdAAA6HQAAmx0AAL8dAADCHQAA0R0AANId
AABLHwAAsx8AADwgAAA9IAAAPiAAAEwgAABOIAAA/QD7APsA/fT97P0A5QDlAOPlAP0A5QDe097T
3tPeAOUA5QDlAOUA5QDlAN4A/QDezcW/xb/ev94A+wC7sQD7AOUA/QAAAAAAAAAAAAAAEwNqAAAA
ADBKOgA1CIE2CIFVCAEGNQiBNgiBAAs2CIFPSgAAUUoAAA42CIE+KgFPSgAAUUoAAAALPioBT0oA
AFFKAAAVA2oAAAAAMEo6AE9KAABRSgAAVQgBCE9KAABRSgAAAANIKgENA2oAAAAAMEo6AFUIAQ41
CIE2CIFPSgMAUUoDAAANCWoBACrwMEo6ADUIgQM+KgEDNQiBAEQABAAALAQAAC8EAABABAAAZgQA
AHUEAACHBAAArAQAANAEAADiBAAAAwUAAAcFAAAgBQAALwUAAE0FAABxBQAAgwUAAJ4FAADLBQAA
zAUAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADW
AAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAAANYAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4wAAAAAA
AAAAAAAAAMcAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAANYAAAAAAAAAAAAA
AADWAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADHAAAAAAAAAAAAAAAAtwAA
AAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAADhYAEmTwAAEAE6TwAA3GDQHMAAPFAooF
TggAAAAQFgADJAESZPAAAQATpPAADcYNAcwAA8UCigVOCAAAAAAOKwAPhNsCEmTwAAEADcYNAdsC
A8UCigVOCAAAAAAMGAASZPAAAQANxg0BzAADxQKKBU4IAAAAAAwXABJk8AABAA3GDQHMAAPFAooF
TggAAAAADhgAEmTwAAEAE6TwAA3GDQHMAAPFAooFTggAAAAAEwAEAAAsBAAALwQAAEAEAABmBAAA
dQQAAIcEAACsBAAA0AQAAOIEAAADBQAABwUAACAFAAAvBQAATQUAAHEFAACDBQAAngUAAMsFAADM
BQAA7gUAAPgFAAAFBgAA4gcAAIcKAADPDAAAvQ0AAOYNAAAPDgAAVA4AAIkOAADHDgAA0w4AAPMP
AAAiEAAAcBEAAI8RAADQEQAABRIAACkSAABUEgAASxQAAJMWAAACGQAAzxkAAMMaAAD7GgAAKhsA
AE8bAAARHAAAPxwAAIYcAAA6HQAA0x0AAAYfAABOIAAA9CEAAHwjAAD7IwAATiQAAAslAACQJQAA
OCYAAJsmAAAgJwAA3CcAAHMqAABzKwAA7i4AAN8yAAAWNAAAcTQAAJI0AACpNQAACzcAAP39/fv9
/f37+/n9/f39+/v59/f39/v7+/v78vLy8vLy+/396+vk5N39/f39/dbr1P3S/cvryMbDwb6+vr6+
vr6+/fv7+/v7vPv7AAADAiUABQgkAAkBAwI2AAUCAQAFAAMCNwAFAgMABQIMAgMABQIHAggfAAkB
AAMCIgADAg8ADAIDAAUCBwIIIwAJAQAMAgQABQMHAwgOAAkBAAwCBAAFAwcDCB4ACQEADAIDAAUC
BwIIHgAJAQAIAhcACCYACQEAAwIWAAMCKwADAhcAAwIYAABKzAUAAO4FAAD4BQAABQYAAOIHAACH
CgAAzwwAAL0NAADmDQAADw4AAFQOAACJDgAAxw4AANMOAADzDwAAIhAAAHARAACPEQAA0BEAAPEA
AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADiAAAAAAAA
AAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAA0AAAAAAAAAAAAAAA
ANAAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAA0AAAAAAAAAAAAAAAANAAAAAAAAAAAAAAAADiAAAA
AAAAAAAAAAAAwAAAAAAAAAAAAAAAALEAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAqAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgDAA+ExQINxgcBoAUBxQIAAA4YABJk8AAB
ABOk8AANxg0BzAADxQKKBU4IAAAAEBgABiQBEmTwAAEAE6TwAA3GDQHMAAPFAooFTggAAAASFwAK
JgALRiYAEmTwAAEAE6TwAA3GDQHMAAPFAooFTggAAAAADhcAEmTwAAEAE6TwAA3GDQHMAAPFAooF
TggAAAAOFgADJAESZPAAAQANxg0BzAADxQKKBU4IAAAAABLQEQAABRIAACkSAABUEgAASxQAAJMW
AAACGQAAzxkAAMMaAAD7GgAAKhsAAE8bAAARHAAAPxwAAIYcAAA6HQAA0x0AAPcAAAAAAAAAAAAA
AAD3AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAA2gAA
AAAAAAAAAAAAANoAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAMUAAAAAAAAA
AAAAAADBAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAAK8AAAAAAAAAAAAAAACfAAAAAAAAAAAAAAAA
kwAAAAAAAAAAAAAAAMUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAwAKJgILRh8AD4TF
Ag3GBwGgBQHFAgYQGAAGJAESZPAAAQATpPAADcYNAcwAA8UCigVOCAAAABIiAAYkAQ+EAAASZPAA
AQATpPAADcYNAdYBA8UCigVOCAAAAAADDwAPhAAAAAgDAA+ExQINxgcBoAUBxQIGDAMACiYCC0Yj
AA+ExQINxgcBoAUBxQIGAA4YABJk8AABABOk8AANxg0BzAADxQKKBU4IAAAADgQACiYDC0YOAA+E
igURhDz9DcYHAWoIAYoFAAAHBAAPhIoFDcYFAAGKBQAAENMdAAAGHwAATiAAAPQhAAB8IwAA+yMA
AE4kAAALJQAAkCUAADgmAACbJgAAICcAANwnAABzKgAAcysAAO4uAADfMgAAFjQAAHE0AACSNAAA
qTUAAAs3AAD4AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADvAAAAAAAAAAAA
AAAA5AAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOQA
AAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADVAAAAAAAA
AAAAAAAAxgAAAAAAAAAAAAAAAMYAAAAAAAAAAAAAAADGAAAAAAAAAAAAAAAAxgAAAAAAAAAAAAAA
AMYAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAxgAAAAAAAAAAAAAAAMYAAAAAAAAAAAAAAAAAAAAQ
JQAGJAESZPAAAQATpPAADcYNAcwAA8UCigVOCAAAAAAOFwASZPAAAQATpPAADcYNAcwAA8UCigVO
CAAAAAAOGAASZPAAAQATpPAADcYNAcwAA8UCigVOCAAAAAsAAAomAAtGJAAPhDgEDcYFAAFoAQAA
ATYABQEACiYAC0YAAAABNwAHAwAKJgALRgAAD4T1/wAVTiAAAIcgAACIIAAAMSEAAHYhAAB3IQAA
4yEAAOQhAAD0IQAAfCMAANonAADbJwAA3CcAAIQqAACFKgAABjIAAAcyAADdMgAA3jIAAHE0AACQ
NAAAkTQAAJI0AACRNwAAojcAAKM3AAClNwAA3DoAAN06AAAVOwAAazsAAMU7AADGOwAAyDsAANY9
AADXPQAA8D0AAEg+AAAVQAAAWUAAAGtBAABsQQAABkIAAAdCAAAIQgAAhUQAAIZEAADZRQAAokcA
AKNHAAAeSwAAH0sAADdLAAA4SwAA9VIAAA9TAADuXQAATF8AAPns+eng+ez5ANj50wDRAMoAygDR
ytEAxry6ALXR06+ir9O10dMA0QDKAJ/KAMoA05TTlNOU09EA0wAAAAAAAAAVA2oAAAAAMEo6AE9K
AABRSgAAVQgBBDBKOgAAGANqAAAAADBKOgA1CIFPSgAAUUoAAFUIAQALNQiBT0oAAFFKAAAJCWoB
ALfwNQiBAzYIgRMDagAAAAAwSjoANgiBPioBVQgBBjYIgT4qAQANA2oAAAAAMEo6AFUIAQM1CIEI
T0oAAFFKAAAADzYIgU9KAABRSgAAbUgJCBAwSjoAT0oAAFFKAABtSAkIAARtSAkIABkDagAAAAAw
SjoAT0oAAFFKAABVCAFtSAkIDE9KAABRSgAAbUgJCDkLNwAApjcAAPs4AACFOQAAdjoAALc6AADc
OgAAFTsAAGs7AADIOwAA1j0AAPA9AABIPgAAFUAAAFlAAABuQQAAfEIAAPFDAACHRAAA2UUAACFL
AABbTAAAcEwAAIVMAADtTQAAbk8AAB9SAAD1UgAAD1MAAJRUAAAqVQAAFFYAAKBXAAAhWgAA7VwA
AO5dAABMXwAAsF8AAPBfAAAwYAAAxWAAAP39+/v7/fn38vf59/Dw+fnr6/nm4dzX0s3Iw765tK+q
paCblo+Fe3EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgI9AAYewP//CCoACQEKAwAAAAASAj0ABl7A
//8IKgAJAQoCAAAAABICPQAGnsD//wgqAAkBCgEAAAAADQI9AAYCwf//CCoACQEIAj0ABmDC//8A
CAIYAAZhw///AAgCGAAGLcb//wAIAhcABq7I//8ACAIXAAY6yv//AAgCFwAGJMv//wAIAhgABrrL
//8ACAIXAAY/zf//AAgCFgAGWc3//wAIAj0ABi/O//8ACAI9AAbg0P//AAgCPQAGYdL//wAIAj0A
BsnT//8ACAI9AAbe0///AAgCPQAG89P//wAIAj0ABi3V//8ACAI9AAZ12v//AAgCFgAIKQAJAQAD
AhgACAIPAAgoAAkBAAMCDwADAhYAAwIXAAMCJgAAKAs3AACmNwAA+zgAAIU5AAB2OgAAtzoAANw6
AAAVOwAAazsAAMg7AADWPQAA8D0AAEg+AAAVQAAAWUAAAG5BAAB8QgAA8AAAAAAAAAAAAAAAAPAA
AAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADRAAAAAAAA
AAAAAAAAwgAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAA
AKIAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAkwAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAACiAAAA
AAAAAAAAAAAAogAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOGAASZPAAAQATpPAADcYN
AcwAA8UCigVOCAAAABAWAAYkARJk8AABABOk8AANxg0BzAADxQKKBU4IAAAADg8ACiYAC0YoAA+E
0AIRhDD9DcYHAWgBAdACBgABDwAADhYAEmTwAAEAE6TwAA3GDQHMAAPFAooFTggAAAAQJgAGJAES
ZPAAAQATpPAADcYNAcwAA8UCigVOCAAAAAAOFwASZPAAAQATpPAADcYNAcwAA8UCigVOCAAAAAAO
JgASZPAAAQATpPAADcYNAcwAA8UCigVOCAAAAAAQfEIAAPFDAACHRAAA2UUAACFLAABbTAAAcEwA
AIVMAADtTQAAbk8AAB9SAAD1UgAAD1MAAJRUAAAqVQAAFFYAAKBXAAAhWgAA7VwAAO5dAABMXwAA
6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAANcAAAAA
AAAAAAAAAADXAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADXAAAAAAAAAAAA
AAAA1wAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAALkA
AAAAAAAAAAAAAADIAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAAC5AAAAAAAA
AAAAAAAAuQAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAOGAASZPAAAQATpPAADcYNAcwAA8UCigVOCAAAAAAOFwASZPAAAQATpPAADcYNAcwAA8UCigVO
CAAAAAADPQAPhAAAEBYABiQBEmTwAAEAE6TwAA3GDQHMAAPFAooFTggAAAAAExYABiQBCiYAC0Yp
ABJk8AABABOk8AANxg0BzAADxQKKBU4IAAAAABRMXwAAW18AALBfAAC3XwAA8F8AAP5fAAAwYAAA
PmAAAMVgAADOYAAAh2EAAJxhAAClZwAA82sAAP5rAADmcAAA53AAAO1wAADucAAA8HAAAPFwAAAP
cQAAEHEAABFxAAAlcQAAJnEAAC5xAAAvcQAAMXEAADJxAABMcQAATXEAAFVxAABWcQAAWXEAAGBx
AABicQAAY3EAAGhxAABpcQAAanEAAGxxAAB8cQAAHXIAADVyAADycgAA83IAAEhzAABJcwAA0nMA
ANNzAAAAdAAAAXQAAAJ0AAAjdAAAJHQAAGR1AAD59Pn0+fT59Pn0+fQA8gDr6Ovj6wDf1t/W0tYA
zQDNys0AyADDALy2ALIAsgCn9Kf0nvSSno+e9AAABDBKNAAAFwIIgQNqAAAAAAYIAU9KAABRSgAA
VQgBEQNqAAAAAE9KAABRSgAAVQgBFQNqAAAAADBKOgBPSgAAUUoAAFUIAQY1CIE2CIEACglqAQAq
8DBKOgAADQNqAAAAADBKMwBVCAEJA2oAAA4AVQgBAzwIgQRtSAAEAAkDagAAAABVCAEHaAgAbUgA
BBADagAAAABVCAFoCABuSAkEAAdoCABuSAkECDBKPwBtSAAEAAQwSj8AAA0DagAAAAAwSj8AVQgB
AzUIgQhPSgAAUUoAAAALPioBT0oAAFFKAAAAOExfAACwXwAA8F8AADBgAADFYAAAh2EAACdiAACc
ZAAAtGQAAP5kAAAwZQAAMWUAAD1lAADmZQAA8mUAAC1mAABcZgAAaGYAAL5mAAAhZwAALWcAAPYA
AAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAA
AAAAAAAA9gAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAA
ANYAAAAAAAAAAAAAAADMAAAAAAAAAAAAAAAAxAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAADhAAAA
AAAAAAAAAAAAuwAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAAuwAAAAAAAAAA
AAAAALQAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc9AAomAAtGKwAT
pAAABT0ACiYAC0YrAAADPQAPhKAFAAc9AA+EigURhDv9E6QAAAAJPQAPhDMHE6QAAA3GBQABTwgA
Cz0ACiYAC0YrAA+EvAYRhOT+E6QAAAADPQAPhMUCAAM9AA+EAAANPQAKJgALRioAD4TFAhGEO/0N
xgUAAcUCAAk9AAomAAtGKgAPhMUCEYQ7/QAUxWAAAIdhAAAnYgAAnGQAALRkAAD+ZAAAMGUAADFl
AAA9ZQAA5mUAAPJlAAAtZgAAXGYAAGhmAAC+ZgAAIWcAAC1nAACZZwAApWcAACloAADzawAA/msA
AIZuAAAebwAA5XAAAOZwAADncAAA7XAAAO5wAADwcAAA8XAAAPJwAADzcAAAMHEAADFxAABmcQAA
Z3EAAGhxAADycgAASHMAAEJ0AABldQAAOXYAAJB3AAALeAAAs3gAAAR5AABveQAAB3oAAAR7AACN
fAAAjnwAAH19AACpfgAAR38AAFB/AACIfwAAq4AAAA6BAAAWgQAAk4EAACCCAADOggAARIMAAHCD
AACpjAAAqowAAOmMAABfjQAAFI4AAMiOAADQjgAA0I8AAGeQAABtkQAAbpEAAPbs6urq5erq6url
5erl5erl6uPj4ePj4+Pf39/f39/f3N/c39/f2dnW1NnZzsa+2dnZ2dTZ2dnZ2dnU2dTZ2dTU2dnZ
2dnZ2dnZ3wAPAjkACCcACQEKAgAAAA0BDwI5AAgnAAkBCgEAAAANAQoCOQAIJwAJAQ0BAAINAQAF
AjUADQEFAjkADQEFAhQADQECAQEAAwIqAAMCGAAIAj0ACCsACQEAAwI9ABICPQAGx77//wgqAAkB
CgUAAAAAEgI9AAaJv///CCoACQEKBAAAAEstZwAAmWcAAKVnAAApaAAA82sAAP5rAACGbgAAHm8A
AOVwAADmcAAA8nAAAPNwAAAwcQAAMXEAAGZxAABncQAAaHEAAPJyAABIcwAA+gAAAAAAAAAAAAAA
APYAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAAAMUAAAAAAAAAAAAAAADnAAAA
AAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAtQAAAAAAAAAA
AAAAALIAAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAAKoAAAAAAAAAAAAAAACy
AAAAAAAAAAAAAAAAqAAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACgAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAFOQAPhLQAEYRM/wABOQAAAQAAAxQAMSQAAAQUAAMkATEkAAMAADEkAAMVADEkAAAMGAAS
ZPAAAQANxg0BzAADxQKKBU4IAAAAABAqAAMkAAYkARJk8AABABOk8AANxgsAA8UCigVOCAAAAAAQ
GAAOhLb/EmTwAAEAE6TwAA3GDQHMAAPFAooFTggAAAAADhgAEmTwAAEAE6TwAA3GDQHMAAPFAooF
TggAAAAAAz0AD4TFAgU9AAomAAtGKwAAEkhzAABCdAAAZXUAADl2AACQdwAAC3gAALN4AAAEeQAA
b3kAAAd6AAAEewAAjXwAAI58AAB9fQAAqX4AAEd/AABQfwAAiH8AAKuAAAAOgQAAFoEAAJOBAAAg
ggAAzoIAAPkAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA2QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAANEAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAMgAAAAA
AAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAJAAAGJAEPhLQAEYRM/xOkAAAABwAAD4S0ABGETP8T
pAAAAAM5AA+EtAAJOQAKJgALRicAD4S0ABGETP8JOQAKJgALRicAD4QcAhGE5P0ABQAAD4S0ABGE
TP8AAzUAD4S0AAAFOQAPhLQAEYRM/wAXZHUAAGV1AABmdQAApXUAAKZ1AADjdQAA5HUAAOV1AAAW
dgAAF3YAADl2AAA6dgAAO3YAAFN2AAALdwAADHcAAFJ3AABTdwAAVHcAAI53AACPdwAAkHcAAJF3
AAAHegAACHoAAAR7AAAFewAABXwAABN8AACOfAAAj3wAAOF8AADifAAAI30AACR9AAAlfQAAWn0A
AFt9AAB9fQAAfn0AAAZ+AAAHfgAATX4AAE5+AABPfgAAiX4AAIp+AACpfgAA+ezl2uXM2sPa5biz
rbOks5iklaSzuLO4s7izrbPs5drlh9rD2uW4s6Sze6SVpLMAAAAAAAAAFwIIgQNqEAQAAAYIAU9K
AABRSgAAVQgBGwIIgQNqMwMAAAYIAUNKFABPSgAAUUoAAFUIAQQwSjQAABcCCIEDatIBAAAGCAFP
SgAAUUoAAFUIAREDagAAAABPSgAAUUoAAFUIAQs2CIFPSgAAUUoAAAhPSgAAUUoAAAAVA2oAAAAA
MEo6AE9KAABRSgAAVQgBEDBKNABDShQAT0oAAFFKAAAAGwIIgQNq/QAAAAYIAUNKFABPSgAAUUoA
AFUIARUDagAAAABDShQAT0oAAFFKAABVCAEMQ0oUAE9KAABRSgAAABkDagAAAAAwSjoAQ0oUAE9K
AABRSgAAVQgBCzoIgU9KAABRSgAAAC+pfgAAqn4AANp+AADcfgAAQH8AAER/AABHfwAASH8AAFB/
AABRfwAAiH8AAIl/AACKfwAA1X8AAAiAAAAYgAAAGYAAAFSAAABVgAAAVoAAAIWAAACGgAAAqoAA
AKuAAACsgAAADoEAAA+BAAAWgQAAF4EAAJOBAACUgQAAqoEAALuBAAC9gQAAH4IAACCCAAAhggAA
IoIAAMuCAADOggAAz4IAAESDAABFgwAARoMAAG6DAAC7hQAAgocAAKWHAAA0iQAAqYwAAKqMAACr
jAAA6YwAAOqMAABfjQAAYI0AAPgA9gDyAOfi5+L4AOLc4tPix9PA0+IA+ACzrOfis6yjmaOs+ADi
AOfi+ACPrIysjKzi5+Ln4vgABENKFAAAEzBKPAA1CIFDShQAT0oAAFFKAAATNQiBQ0oUAE9KAABR
SgAAbUgJCBBDShQAT0oAAFFKAABtSAkIAAxDShQAT0oAAFFKAAAAGQNqAAAAADBKOgBDShQAT0oA
AFFKAABVCAEMMEo0AE9KAABRSgAAABcCCIEDanEFAAAGCAFPSgAAUUoAAFUIAREDagAAAABPSgAA
UUoAAFUIAQs1CIFPSgAAUUoAAAhPSgAAUUoAAAAVA2oAAAAAMEo6AE9KAABRSgAAVQgBBjYIgT4q
AQADSCoBDQNqAAAAADBKOgBVCAEAN86CAABEgwAAcIMAAKmMAACqjAAA6YwAAF+NAAAUjgAAyI4A
ANCOAADQjwAAZ5AAAG2RAABukQAAb5EAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7wAAAAAA
AAAAAAAAAOkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAOMAAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAN8AAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMGAASZPAAAQANxg0B
zAADxQKKBU4IAAAAAAEAAAABOQAABTkAD4QOARGE8v4ABTkAD4TQAhGEMP0AAwAAD4RoAQAFAAAP
hNACEYQw/QAFOQAPhLQAEYRM/wAOYI0AABSOAAAVjgAAyI4AAMmOAADQjgAA0Y4AANCPAADRjwAA
Z5AAAGiQAAC5kAAAupAAAAiRAAAJkQAACpEAAEyRAABNkQAAb5EAAAD4APgA+AD4APgA8wDr8+jz
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMEo0AAAPAgiBA2pCBgAABggBVQgBCQNqAAAA
AFUIAQ0DagAAAAAwSjoAVQgBABJukQAAb5EAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAMCGAAAAT4ACjABETABEjAAFDAqFpBoAR+waC4gsLRBIbAtByKwXQQjkKUG
JJC8BiWwAAAFMAAD8gDeIgTyANACA/IBBxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA/QAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAAIgAA
AGgAdAB0AHAAOgAvAC8AdwB3AHcALgBiAGkAcwAuAG8AcgBnAC8AcAB1AGIAbAAvAGkAbgBkAGUA
eAAuAGgAdABtAAAA4Mnqefm6zhGMggCqAEupC0QAAABoAHQAdABwADoALwAvAHcAdwB3AC4AYgBp
AHMALgBvAHIAZwAvAHAAdQBiAGwALwBpAG4AZABlAHgALgBoAHQAbQAAANUAAABEAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ
6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ6nn5us4RjIIAqgBLqQtkAAAAaAB0AHQAcAA6AC8ALwB3
AHcAdwAuAGEAYgBhAG4AZQB0AC4AbwByAGcALwBzAGMAaQB0AGUAYwBoAC8AZQBjAC8AaQBzAGMA
LwBkAHMAZwBmAHIAZQBlAC4AaAB0AG0AbAAAAGEBAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsC
AAAAFwAAADsAAABoAHQAdABwADoALwAvAHcAdwB3AC4AbABhAHcALgB1AG4AcwB3AC4AZQBkAHUA
LgBhAHUALwB1AG4AcwB3AGwAagAvAGUAYwBvAG0AbQBlAHIAYwBlAC8AbQBjAGMAdQBsAGwAYQBn
AGgALgBoAHQAbQBsAAAA4Mnqefm6zhGMggCqAEupC3YAAABoAHQAdABwADoALwAvAHcAdwB3AC4A
bABhAHcALgB1AG4AcwB3AC4AZQBkAHUALgBhAHUALwB1AG4AcwB3AGwAagAvAGUAYwBvAG0AbQBl
AHIAYwBlAC8AbQBjAGMAdQBsAGwAYQBnAGgALgBoAHQAbQBsAAAA3QAAAEQAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6
zhGMggCqAEupCwIAAAADAAAA4Mnqefm6zhGMggCqAEupC2wAAABoAHQAdABwADoALwAvAHcAdwB3
AC4AdQBuAC4AbwByAC4AYQB0AC8AdQBuAGMAaQB0AHIAYQBsAC8AdABlAHgAdABzAC8AZQBsAGUA
YwB0AGMAbwBtAC8AbQBsAC0AZQBjAC4AaAB0AG0AAABhAQAARAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoA
S6kLAgAAABcAAAA7AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGwAYQB3AC4AdQBuAHMAdwAuAGUA
ZAB1AC4AYQB1AC8AdQBuAHMAdwBsAGoALwBlAGMAbwBtAG0AZQByAGMAZQAvAG0AYwBjAHUAbABs
AGEAZwBoAC4AaAB0AG0AbAAAAODJ6nn5us4RjIIAqgBLqQt2AAAAaAB0AHQAcAA6AC8ALwB3AHcA
dwAuAGwAYQB3AC4AdQBuAHMAdwAuAGUAZAB1AC4AYQB1AC8AdQBuAHMAdwBsAGoALwBlAGMAbwBt
AG0AZQByAGMAZQAvAG0AYwBjAHUAbABsAGEAZwBoAC4AaAB0AG0AbAAAANEAAABEAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ
6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ6nn5us4RjIIAqgBLqQtgAAAAaAB0AHQAcAA6AC8ALwBs
AGEAdwAuAGcAbwB2AC4AYQB1AC8AYQBnAGgAbwBtAGUALwBhAGQAdgBpAHMAbwByAHkALwBlAGMA
ZQBnAC8AZQBjAGUAZwAuAGgAdABtAAAAgQEAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAX
AAAAQwAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBuAGMAaQBwAGgAZQByAC4AYwBvAG0ALwBwAHIA
bwBkAHUAYwB0AHMALwBmAGkAbABlAHMALwBwAGEAcABlAHIAcwAvAGEAbgBnAHUAaQBsAGwAYQAv
AGsAZQB5AGgAaQBkAGUAMgAuAHAAZABmAAAA4Mnqefm6zhGMggCqAEupC4YAAABoAHQAdABwADoA
LwAvAHcAdwB3AC4AbgBjAGkAcABoAGUAcgAuAGMAbwBtAC8AcAByAG8AZAB1AGMAdABzAC8AZgBp
AGwAZQBzAC8AcABhAHAAZQByAHMALwBhAG4AZwB1AGkAbABsAGEALwBrAGUAeQBoAGkAZABlADIA
LgBwAGQAZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAABIAQQAKAAEAWwAPAAIABAAAAAQANAAAQPH/AgA0AAAABgBOAG8AcgBtAGEAbAAA
AAYAAAATpPAAEABDShgAT0oFAFFKBQBtSAkMQAABQAEA8gBAAAAADwBIAGUAYQBkAGkAbgBnACAA
MQAsADEALgAsAGgAMQAAAAwAAQAKJgALRh4AQCYABABLSBwAOAACAAEA8gA4AAAADQBIAGUAYQBk
AGkAbgBnACAAMgAsADEALgAxAAAADAACAAomAQtGHgBAJgEAADgAA0ABAAIBOAAAAA0ASABlAGEA
ZABpAG4AZwAgADMALAAoAGEAKQAAAAwAAwAKJgILRh4AQCYCAAA4AARAAQASATgAAAANAEgAZQBh
AGQAaQBuAGcAIAA0ACwAKABpACkAAAAMAAQACiYDC0YeAEAmAwAAOAAFAAEAIgE4AAAADQBIAGUA
YQBkAGkAbgBnACAANQAsACgAQQApAAAADAAFAAomBAtGHgBAJgQAADgABgABADIBOAAAAA0ASABl
AGEAZABpAG4AZwAgADYALAAoAEkAKQAAAAwABgAKJgULRh4AQCYFAAAwAAcAEQByADAAAAAJAEgA
ZQBhAGQAaQBuAGcAIAA3AAAADAAHAAomBgtGHgBAJgYAADAACAARAIIAMAAAAAkASABlAGEAZABp
AG4AZwAgADgAAAAMAAgACiYHC0YeAEAmBwAANAAJABEAAgA0AAAACQBIAGUAYQBkAGkAbgBnACAA
OQAAAA8ACQADJAEKJggLRh4AQCYIAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABh
AHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAADgAQ0ABAPIAOAAAABAAQgBvAGQA
eQAgAFQAZQB4AHQAIABJAG4AZABlAG4AdAAAAAYADwAPhNACAABAAP4P8QACAUAAAAAUAEIAbwBk
AHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQAIAAoAGEAKQAAAAYAEAAPhIoFAABAAP4PAQESAUAA
AAAUAEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQAIAAoAGkAKQAAAAYAEQAPhGsIAABA
AP4PAQAiAUAAAAAUAEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQAIAAoAEEAKQAAAAYA
EgAPhKELAABAAP4PIQEyAUAAAAAUAEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQAIAAo
AEkAKQAAAAYAEwAPhNgNAAA2ACBAAQBCATYAAAAGAEYAbwBvAHQAZQByAAAAFAAUAAMkAhOkAAAN
xggAAjkQciABAgQAQ0oOADIAH0ABAFIBMgAAAAYASABlAGEAZABlAHIAAAAUABUAAyQBE6QAAA3G
CAACORByIAECAABEAP5PAQBiAUQAAAAHAFQAeABCAHIAXwBwADEAAAAUABYAEmT5AAAAE6QAAA3G
BQABzAAADwBPSgAAUUoAAGgIAG5ICQQARAD+TwEAcgFEAAAABwBUAHgAQgByAF8AcAAyAAAAFAAX
ABJk3QAAABOkAAANxgUAAcwAAA8AT0oAAFFKAABoCABuSAkEAEQA/k8BAIIBRAAAAAcAVAB4AEIA
cgBfAHAAMwAAABQAGAASZN0AAAATpAAADcYFAAHMAAAPAE9KAABRSgAAaAgAbkgJBABMAP4PAQCS
AUwAAAAHAFQAeABCAHIAXwBwADQAAAAcABkAD4SJBRGEev0SZN0AAAATpAAADcYFAAGGAgAPAE9K
AABRSgAAaAgAbkgJBABMAP4PAQCiAUwAAAAHAFQAeABCAHIAXwBwADUAAAAcABoAD4SJBRGEev0S
ZN0AAAATpAAADcYFAAFABAAPAE9KAABRSgAAaAgAbkgJBABMAP4PAQCyAUwAAAAHAFQAeABCAHIA
XwBwADYAAAAcABsAD4TPAxGEwPsSZEMBAAATpAAADcYFAAFABAAPAE9KAABRSgAAaAgAbkgJBAA8
AP4PAQDCATwAAAAHAFQAeABCAHIAXwBwADcAAAAMABwAEmTLAQAAE6QAAA8AT0oAAFFKAABoCABu
SAkEAFIA/g8BANIBUgAAAAgAVAB4AEIAcgBfAHAAMQAxAAAAHwAdAA+ETwARhBP+EmTdAAAAE6QA
AA3GCAAC/APpBQAAAA8AT0oAAFFKAABoCABuSAkEAEoA/g8BAOIBSgAAAAgAVAB4AEIAcgBfAHAA
MQAyAAAAGAAeAA+EdwYSZN0AAAATpAAADcYFAAGYAQAPAE9KAABRSgAAaAgAbkgJBABKAP4PAQDy
AUoAAAAIAFQAeABCAHIAXwBwADEAMwAAABgAHwAPhJkGEmTdAAAAE6QAAA3GBQABdgEADwBPSgAA
UUoAAGgIAG5ICQQARgD+DwEAAgJGAAAACABUAHgAQgByAF8AcAAxADUAAAAUACAAEmTwAAAAE6QA
AA3GBQABzAAADwBPSgAAUUoAAGgIAG5ICQQAUgD+DwEAEgJSAAAACABUAHgAQgByAF8AcAAxADYA
AAAfACEAD4RaARGEWP0SZN0AAAATpAAADcYIAAKYAUAEAAAADwBPSgAAUUoAAGgIAG5ICQQASgD+
TwEAIgJKAAAACABUAHgAQgByAF8AcAAxADcAAAAYACIAD4Q5BhJk8AAAABOkAAANxgUAAdYBAA8A
T0oAAFFKAABoCABuSAkEAEoA/g8BADICSgAAAAgAVAB4AEIAcgBfAHAAMQA4AAAAGAAjAA+EiQUS
ZPAAAAATpAAADcYFAAGGAgAPAE9KAABRSgAAaAgAbkgJBABKAP4PAQBCAkoAAAAIAFQAeABCAHIA
XwBwADIANAAAABgAJAAPhHIFEmTuAAAAE6QAAA3GBQABnAIADwBPSgAAUUoAAGgIAG5ICQQARgD+
TwEAUgJGAAAACABUAHgAQgByAF8AcAAyADEAAAAUACUAEmTwAAAAE6QAAA3GBQABzAAADwBPSgAA
UUoAAGgIAG5ICQQARgD+TwEAYgJGAAAACABUAHgAQgByAF8AcAAyADUAAAAUACYAEmTiAAAAE6QA
AA3GBQABzAAADwBPSgAAUUoAAGgIAG5ICQQAQgD+DwEAcgJCAAAACABUAHgAQgByAF8AYwAyADcA
AAAPACcAAyQBEmTwAAAAE6QAAAAPAE9KAABRSgAAaAgAbkgJBABKAP4PAQCCAkoAAAAIAFQAeABC
AHIAXwBwADIAOAAAABgAKAAPhN8EEmTdAAAAE6QAAA3GBQABMAMADwBPSgAAUUoAAGgIAG5ICQQA
RgD+DwEAkgJGAAAACABUAHgAQgByAF8AcAAyADkAAAAUACkAEmTdAAAAE6QAAA3GBQABzAAADwBP
SgAAUUoAAGgIAG5ICQQAQgD+TwEAogJCAAAACABUAHgAQgByAF8AYwAzADIAAAAPACoAAyQBEmTw
AAAAE6QAAAAPAE9KAABRSgAAaAgAbkgJBABOAP5PAQCyAk4AAAAIAFQAeABCAHIAXwBwADMAMwAA
ABwAKwAPhDQFEYQl/RJk8AAAABOkAAANxgUAAdsCAA8AT0oAAFFKAABoCABuSAkEAEoA/g8BAMIC
SgAAAAgAVAB4AEIAcgBfAHAAMwA0AAAAGAAsAA+E6gQSZPAAAAATpAAADcYFAAElAwAPAE9KAABR
SgAAaAgAbkgJBABEADAAAQDSAkQAAQALAEwAaQBzAHQAIABCAHUAbABsAGUAdAAAABsALQAKJgAL
RhUAD4TFAhGEO/0NxgcBaAEBxQI+AAAASAA2AAEA4gJIAAEADQBMAGkAcwB0ACAAQgB1AGwAbABl
AHQAIAAyAAAAGwAuAAomAAtGFwAPhIoFEYQ7/Q3GBwGDAgGKBQYAAABIADcAAQDyAkgAAQANAEwA
aQBzAHQAIABCAHUAbABsAGUAdAAgADMAAAAbAC8ACiYAC0YZAA+ETwgRhDv9DcYHAWgBAU8IAAAA
AEgAOAABAAIDSAABAA0ATABpAHMAdAAgAEIAdQBsAGwAZQB0ACAANAAAABsAMAAKJgALRhsAD4QT
CxGEO/0NxgcBuQQBEwsGAAAASAA5AAEAEgNIAAEADQBMAGkAcwB0ACAAQgB1AGwAbABlAHQAIAA1
AAAAGwAxAAomAAtGHQAPhNgNEYQ7/Q3GBwHUBQHYDQYAAAAyAB1AAQAiAzIAAAANAEYAbwBvAHQA
bgBvAHQAZQAgAFQAZQB4AHQAAAACADIABABDShQAOAAmQKIAMQM4AAAAEgBGAG8AbwB0AG4AbwB0
AGUAIABSAGUAZgBlAHIAZQBuAGMAZQAAAAMASCoBACgAVUCiAEEDKAAAAAkASAB5AHAAZQByAGwA
aQBuAGsAAAAGAD4qAUIqAioAQkABAFIDKgAAAAkAQgBvAGQAeQAgAFQAZQB4AHQAAAACADUABABD
ShQATABSQAEAYgNMAAAAEgBCAG8AZAB5ACAAVABlAHgAdAAgAEkAbgBkAGUAbgB0ACAAMgAAAAYA
NgAPhDgEDwA2CIFPSgAAUUoAAG1ICQgAQABTQAEAcgNAAAAAEgBCAG8AZAB5ACAAVABlAHgAdAAg
AEkAbgBkAGUAbgB0ACAAMwAAAAYANwAPhNACAwA2CIEAPABaAAEAggM8AAAACgBQAGwAYQBpAG4A
IABUAGUAeAB0AAAABgA4ABOkAAAQAENKFABPSgYAUUoGAG1ICQQwACtAAQCSAzAAAAAMAEUAbgBk
AG4AbwB0AGUAIABUAGUAeAB0AAAAAgA5AAQAQ0oUADYAKkCiAKEDNgAAABEARQBuAGQAbgBvAHQA
ZQAgAFIAZQBmAGUAcgBlAG4AYwBlAAAAAwBIKgEATAD+DwEAsgNMAAAACgBCAGwAbwBjAGsAcQB1
AG8AdABlAAAAEgA7AA6EaAEPhGgBE6RkABSkZAATAE9KAABRSgAAaAgAbUgJBG5ICQQAJABYQKIA
wQMkAAAACABFAG0AcABoAGEAcwBpAHMAAAADADYIgQAuAFBAAQDSAy4AAAALAEIAbwBkAHkAIABU
AGUAeAB0ACAAMgAAAAYAPQAPhNACAAA0AP4PAQDiAzQAAAAKAEwAZQB2AGUAbAAgADEALgBmAG8A
AAAGAD4AD4TQAggAT0oHAFFKBwAmAClAogDxAyYAAAALAFAAYQBnAGUAIABOAHUAbQBiAGUAcgAA
AAAAOABWQKIAAQQ4AAAAEQBGAG8AbABsAG8AdwBlAGQASAB5AHAAZQByAGwAaQBuAGsAAAAGAD4q
AUIqDMkBAAAWBwAA8gcAAM0IAAApDQAAAw4AACcOAABSDgAA8w4AAKwPAABIEAAAvRAAALkTAAD7
EwAA0RkAADwcAACHHAAA4x0AAAYuAADdLgAAkDAAAKIzAADFNwAAaz0AAAc+AACFQAAAokMAAB5H
AAA3RwAAb40AAAAAAQACAAMABAAFAAYABwAIAAkAAQAKAAsAAQABAAwAAQANAAEAAQABAA4ADwAB
AAEAAQABAAEAAQAAAAAAigEAAOABAAD9AwAA0QQAACgGAACfCAAAnAkAACYLAAAVDAAAQQ0AAN8N
AADoDQAAIA4AAEMPAACmDwAArg8AACsQAAC4EAAAZhEAANwRAABCGwAAgRsAAPcbAACsHAAAYB0A
AGgdAABoHgAA/x4AAAUgAAAIIAAAAAAAAG+NAAADAAC8AAAKAP////8AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA0AAAANAAAASwAAAEsAAACBAAAAhAAAAAAEAABOIAAATF8AAGR1AACp
fgAAYI0AAG+RAABKAAAAUAAAAFQAAABZAAAAWgAAAFwAAAAABAAAzAUAANARAADTHQAACzcAAHxC
AABMXwAALWcAAEhzAADOggAAb5EAAEsAAABNAAAATgAAAE8AAABSAAAAUwAAAFUAAABXAAAAWAAA
AFsAAAAABAAACzcAAMVgAABukQAAb5EAAEwAAABRAAAAVgAAAF0AAAAAAAAABwAAAAoAAAAqAAAA
PwAAAEgAAABLAAAAZgAAAG8AAACEAAAAEyE0/5WAEx80/5WAEx20/5WAagIAAJkCAAC7AgAAPQQA
AHwEAACuBAAAowUAAOsFAAAmBgAAeQsAALwLAADyCwAAngwAAOYMAAAhDQAAsA4AAO0OAAAdDwAA
UR8AAKEfAADkHwAACCAAABNYFP8VgBNYlAGVhBNYFP8VgBNYlAGVhBNYFP8VgBNYlAGVhBNYFP8V
gP//BgAAAA0AXwBUAG8AYwA0ADIAOQAzADkAOQA4ADcAMgANAF8AVABvAGMANAAzADMANwAyADEA
NgA5ADEADQBfAEgAbAB0ADQANgA5ADgANwA1ADgAMgA5AA0AXwBIAGwAdAA0ADYAOQA4ADcANQA3
ADMANQANAF8ASABsAHQANAA2ADkAOAA3ADUANgA2ADQADQBfAEgAbAB0ADQANgA5ADgANwA0ADgA
NgA5AE4cAABOHAAA/nEAAEl5AABNeQAAa3wAAHCNAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAADj
HQAA4x0AAP9xAABKeQAATnkAAGx8AABwjQAAAAAAAI9CAACgQgAA5mwAAGdtAABobQAAuXwAAMB8
AADGfAAAy3wAAPB8AAD5fAAAGH0AACB9AADYiwAA3IsAAOOLAADpiwAAIYwAACiMAABVjAAAWowA
AF6NAABmjQAAcI0AAAcAHAAHAAcAAgAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
BAAHAAAAAABURgAAV0YAAJhSAACkUgAAsGQAAApmAADmbAAAZ20AAGhtAAAQfQAAFX0AAAGMAAAJ
jAAAhYwAAGyNAABwjQAABwAaAAcAGgAHABoABwAHAAIABwAaAAcAGgAHAAQABwD//xQAAAAQAEEA
ZAByAGkAYQBuACAATQBjAEMAdQBsAGwAYQBnAGgAVgBDADoAXABXAEkATgBOAFQAXABQAHIAbwBm
AGkAbABlAHMAXABBAGQAcgBpAGEAbgAgAE0AYwBDAHUAbABsAGEAZwBoAFwARABlAHMAawB0AG8A
cABcAEEASgBNACAALQAgAFAASABEAFwAUABIAEQAXABwAGgAZAAtAGEAagBtAC0AYQByAHQAaQBj
AGwAZQBzAFwAQgBvAG4AZAAgAFUAbgBpAC4AZABvAGMAEABBAGQAcgBpAGEAbgAgAE0AYwBDAHUA
bABsAGEAZwBoAFYAQwA6AFwAVwBJAE4ATgBUAFwAUAByAG8AZgBpAGwAZQBzAFwAQQBkAHIAaQBh
AG4AIABNAGMAQwB1AGwAbABhAGcAaABcAEQAZQBzAGsAdABvAHAAXABBAEoATQAgAC0AIABQAEgA
RABcAFAASABEAFwAcABoAGQALQBhAGoAbQAtAGEAcgB0AGkAYwBsAGUAcwBcAEIAbwBuAGQAIABV
AG4AaQAuAGQAbwBjABAAQQBkAHIAaQBhAG4AIABNAGMAQwB1AGwAbABhAGcAaAApAEMAOgBcAFQA
RQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABCAG8AbgBk
ACAAVQBuAGkALgBhAHMAZAAQAEEAZAByAGkAYQBuACAATQBjAEMAdQBsAGwAYQBnAGgAVgBDADoA
XABXAEkATgBOAFQAXABQAHIAbwBmAGkAbABlAHMAXABBAGQAcgBpAGEAbgAgAE0AYwBDAHUAbABs
AGEAZwBoAFwARABlAHMAawB0AG8AcABcAEEASgBNACAALQAgAFAASABEAFwAUABIAEQAXABwAGgA
ZAAtAGEAagBtAC0AYQByAHQAaQBjAGwAZQBzAFwAQgBvAG4AZAAgAFUAbgBpAC4AZABvAGMAEABB
AGQAcgBpAGEAbgAgAE0AYwBDAHUAbABsAGEAZwBoAFYAQwA6AFwAVwBJAE4ATgBUAFwAUAByAG8A
ZgBpAGwAZQBzAFwAQQBkAHIAaQBhAG4AIABNAGMAQwB1AGwAbABhAGcAaABcAEQAZQBzAGsAdABv
AHAAXABBAEoATQAgAC0AIABQAEgARABcAFAASABEAFwAcABoAGQALQBhAGoAbQAtAGEAcgB0AGkA
YwBsAGUAcwBcAEIAbwBuAGQAIABVAG4AaQAuAGQAbwBjABAAQQBkAHIAaQBhAG4AIABNAGMAQwB1
AGwAbABhAGcAaAApAEMAOgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMA
YQB2AGUAIABvAGYAIABCAG8AbgBkACAAVQBuAGkALgBhAHMAZAAQAEEAZAByAGkAYQBuACAATQBj
AEMAdQBsAGwAYQBnAGgAVgBDADoAXABXAEkATgBOAFQAXABQAHIAbwBmAGkAbABlAHMAXABBAGQA
cgBpAGEAbgAgAE0AYwBDAHUAbABsAGEAZwBoAFwARABlAHMAawB0AG8AcABcAEEASgBNACAALQAg
AFAASABEAFwAUABIAEQAXABwAGgAZAAtAGEAagBtAC0AYQByAHQAaQBjAGwAZQBzAFwAQgBvAG4A
ZAAgAFUAbgBpAC4AZABvAGMAEABBAGQAcgBpAGEAbgAgAE0AYwBDAHUAbABsAGEAZwBoACkAQwA6
AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEIA
bwBuAGQAIABVAG4AaQAuAGEAcwBkABAAQQBkAHIAaQBhAG4AIABNAGMAQwB1AGwAbABhAGcAaABW
AEMAOgBcAFcASQBOAE4AVABcAFAAcgBvAGYAaQBsAGUAcwBcAEEAZAByAGkAYQBuACAATQBjAEMA
dQBsAGwAYQBnAGgAXABEAGUAcwBrAHQAbwBwAFwAQQBKAE0AIAAtACAAUABIAEQAXABQAEgARABc
AHAAaABkAC0AYQBqAG0ALQBhAHIAdABpAGMAbABlAHMAXABCAG8AbgBkACAAVQBuAGkALgBkAG8A
YwAQAEEAZAByAGkAYQBuACAATQBjAEMAdQBsAGwAYQBnAGgAVgBDADoAXABXAEkATgBOAFQAXABQ
AHIAbwBmAGkAbABlAHMAXABBAGQAcgBpAGEAbgAgAE0AYwBDAHUAbABsAGEAZwBoAFwARABlAHMA
awB0AG8AcABcAEEASgBNACAALQAgAFAASABEAFwAUABIAEQAXABwAGgAZAAtAGEAagBtAC0AYQBy
AHQAaQBjAGwAZQBzAFwAQgBvAG4AZAAgAFUAbgBpAC4AZABvAGMADwCA////UJPGpjEA/w//D/8P
/w//D/8P/w//DwEAgf///0CJqqQwAP8P/w//D/8P/w//D/8P/w8BAIL///+G6ayk/w//D/8P/w//
D/8P/w//D/8PAQCD////DvZuFi4A/w//D/8P/w//D/8P/w//DwEAif///zRUnNItAP8P/w//D/8P
/w//D/8P/w8BAPv////6NkaoAQACAAMABAAFAAYABwAIAAkAAAD+//////////8PAAAAAAAAAAAA
AAAAAAAAAAEAjE+RAdaI0Nb/DwAAAAAAAAAAAAAAAAAAAAABAFdwbTCCJSL2/w8AAAAAAAAAAAAA
AAAAAAAAAQBcWH5TGQAJBP8P/w//D/8P/w//D/8P/w//DwEArX/NXAEACQz/DwAAAAAAAAAAAAAA
AAAAAAABAEpBfWEBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQCfU/5uQOj0XS8AAAAAAAAAAAAAAAAA
AAAAAAEAuX66dkLNLsT/D/8P/w//D/8P/w//D/8P/w8BAIYnZngZAAkE/w//D/8P/w//D/8P/w//
D/8PAQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4TUBRGEmP4VxgUAAdQFBk9KAQBRSgEA
bygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhLkEEYSY/hXGBQABuQQGT0oBAFFK
AQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EngMRhJj+FcYFAAGeAwZPSgEA
UUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4SDAhGEmP4VxgUAAYMCBk9K
AQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEG
T0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+E0AIRhDD9FcYFAAHQ
AgYCAAAALgABAAAAAAABAwAAAAAAAAAAAAAAAAAAAAASEAAAD4TQAhGEMP0VxgUAAdACBjUIADYI
AENKGABPSgUAUUoFAAMAAAAuAAEAAQAAAAQAAgAAAAAAAAAAAAAAAAAAAAAAABAAAA+EoAURhDD9
FcYFAAGgBQYDACgAAgApAAEAAAACAAIAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGoIEYQ2/RXGBQAB
aggGAwAoAAMAKQABAAAAAwACAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RLCxGEH/0VxgUAAUsLBgMA
KAAEACkAAQAAAAEAAgAAAAAAAAAAAAAAAAAAAAAAABAAAA+EEA4RhDv9FcYFAAEQDgYDACgABQAp
AAEAAAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhOAQEYQw/RXGBQAB4BAGAAABAAAA/wAAAAAA
AAAAAAAAAAAAAAAAAAAAEAAAD4SwExGEMP0VxgUAAbATBgAAAQAAAP8AAAAAAAAAAAAAAgAAAAAA
AAAAAAgAAA+EgBYRhDD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAqAAEAAAAEQAEA
AAAAAAAAAAAAAAAAaAEAAAAIAAAPhIMCEYSY/gIAAAApAAEAAAAEQAIAAAAAAAAAAAAAAAAA0AIA
AAAIAAAPhNACEYQw/QMAKAAAACkAAQAAAAQAAgAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+
FcYFAAFoAQZvKAADACgAAAApAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXG
BQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+
FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGE
mP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAEAAIAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhCsC
EYTV/RXGBQABKwIGbygAAwAoAAAAKQABAAAABAACAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGE
mP4VxgUAAWgBBm8oAAMAKAAAACkAKwAAAPv///8AAAAAAAAAAAAAAAD7////AAAAAAAAAAAAAAAA
+////wAAAAAAAAAAAAAAAPv///8AAAAAAAAAAAAAAAD7////AAAAAAAAAAAAAAAA+////wAAAAAA
AAAAAAAAAPv///8AAAAAAAAAAAAAAAD7////AAAAAAAAAAAAAAAA+////wAAAAAAAAAAAAAAAK1/
zVwAAAAAAAAAAAAAAAD7////AAAAAAAAAAAAAAAA+////wAAAAAAAAAAAAAAAPv///8AAAAAAAAA
AAAAAAD7////AAAAAAAAAAAAAAAA+////wAAAAAAAAAAAAAAAPv///8AAAAAAAAAAAAAAAD7////
AAAAAAAAAAAAAAAA+////wAAAAAAAAAAAAAAAPv///8AAAAAAAAAAAAAAACJ////AAAAAAAAAAAA
AAAAif///wAAAAAAAAAAAAAAAIP///8AAAAAAAAAAAAAAACD////AAAAAAAAAAAAAAAAgv///wAA
AAAAAAAAAAAAAJ9T/m4AAAAAAAAAAAAAAACB////AAAAAAAAAAAAAAAAgf///wAAAAAAAAAAAAAA
AID///8AAAAAAAAAAAAAAACA////AAAAAAAAAAAAAAAA+////wAAAAAAAAAAAAAAAPv///8AAAAA
XLOYAgkAAAD7////AAAAAKizmAIJAAAA+////wAAAAD0s5gCCQAAAPv///8AAAAAAAAAAAAAAAD7
////AAAAAEC0mAIJAAAA/v///wAAAACMtJgCAQAAAIxPkQEAAAAAAAAAAAAAAABcWH5TAAAAAAAA
AAAAAAAAuX66dgAAAAAAAAAAAAAAAEpBfWEAAAAAAAAAAAAAAACGJ2Z4AAAAAAAAAAAAAAAAV3Bt
MAAAAAAAAAAAAAAAAP7///8AAAAA6LSYAgEAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////AQAAABAAAQABAAAAEQAAAAEA
AAASAAAAAQAAAFNK4QYBAAAAlDPhBgEAAAAVAAEDAQAAABYAAAABAAAAFwAAAAEAAABYSuEG////
/wEAAAAQAAEAAQAAABEAAAABAAAAEgAAAAEAAACTbeEGAQAAAJRt4QYBAAAAFQABAwEAAAAWAAAA
AQAAABcAAAABAAAA2G3hBv////8BAAAAUEoDAAEAAAARAAAAAQAAABIAAAABAAAAEwAAAAEAAAAU
AAAAAQAAANVV4QYBAAAAllXhBgEAAAAXhLkEAQAAABjGBQD//////////wEAAAAQAAEAAQAAABEA
AAABAAAAEgAAAAEAAADTMuEGAQAAANQy4QYBAAAAFQABAwEAAAAWAAAAAQAAABcAAAABAAAAGDPh
Bv////+YtJgCIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhGgBEYSY/k9KAQBRSgEA
bygAAQC38P/////////////////////////////////////0tJgCIAAyAAEAAAAXQAAAAAAAAAAA
AAAAAAAAaAEAAAsIAAAPhAgHEYSY/k9KAQBRSgEAbygAAQC38P//DwAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP//AwAEAAoAQQB1AHQAaABvAHIATgBhAG0AZQCQtZgCCwBEAG8AYwBW
AGEAcgBpAGEAYgBsAGUAuLWYAgcATwByAGwAaQBkAG8AYwDYtZgCEABBAGQAcgBpAGEAbgAgAE0A
YwBDAHUAbABsAGEAZwBoAA0ARwBhAGQAZQBuAHMAIABNAGEAcwB0AGUAcgAEAHQAcgB1AGUA/0Bc
XFBSSU5UX1NFUlZFUlxQbGFpbl9Db21UZWNoAE5lMDE6AHdpbnNwb29sAFhlcm94IERvY3VQcmlu
dCBOMjQvTjMyIFBTMgBcXFBSSU5UX1NFUlZFUlxQbGFpbl9Db21UZWNoAAAAAAEEAAScALQGE9cB
AAEACQCaCzQIZAABAA8AWAIBAAEAAAADAAAAQTQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQ
UklW4hAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAA6kUH
AP8E/wAB/wEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAEAAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAQAAAAEAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQBkAG0AaQBu
AGkAcwB0AHIAYQB0AG8AcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAADEAOQA5ADkAMAA5ADIAMQAwADAAMAAwADAAMAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABABcA
FwAXAAEAAAABAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAA
AAAEAABcXFBSSU5UX1NFUlZFUlxQbGFpbl9Db21UZWNoAAAAAAEEAAScALQGE9cBAAEACQCaCzQI
ZAABAA8AWAIBAAEAAAADAAAAQTQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUklW4hAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAA6kUHAP8E/wAB/wEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAEAAAABAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA
AAEAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQBkAG0AaQBuAGkAcwB0AHIA
YQB0AG8AcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAADEAOQA5ADkAMAA5ADIAMQAwADAAMAAwADAAMAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABABcAFwAXAAEAAAAB
AAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAEAAACEAAA
AAAAAABvjQAAMAAACABAAAAIAAAARxaQAQAAAgIGAwUEBQIDBIcCAAAAAAAAAAAAAAAAAACfAAAA
AAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAA
AAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBIcCAAAAAAAA
AAAAAAAAAACfAAAAAAAAAEEAcgBpAGEAbAAAAEUWkAEAAAIDCQQFAwYCBwSHAAAAAAAAAAAAAAAA
AAAAGwAAAAAAAABCAGUAbgBnAHUAaQBhAHQAIABCAGsAIABCAFQAAABZEpABAAkAAAAAAAAAAAAA
AwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAATgBlAHcAIABZAG8AcgBrAAAAVABpAG0AZQBzACAATgBl
AHcAIABSAG8AbQBhAG4AAABvFpABABMCBAYEBQUFAgMEAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAA
QwBlAG4AdAB1AHIAeQAgAFMAYwBoAG8AbwBsAGIAbwBvAGsAAABOAGUAdwBDAGUAbgB0AHUAcgB5
AFMAYwBoAGwAYgBrAAAAPzWQAQAAAgcDCQICBQIEBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAEMA
bwB1AHIAaQBlAHIAIABOAGUAdwAAAG8GkAFNEwAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA
AAAAAABOAGUAdwAgAEMAZQBuAHQAdQByAHkAIABTAGMAaABsAGIAawAAAE4AZQB3AEMAZQBuAHQA
dQByAHkAUwBjAGgAbABiAGsAAAAiAAQAQQAIGIAFMQIAAAAAAAAAAIU8OUbSeTxmKZI7hhcAQgQA
AMAPAADLWQAAAQAtAAAABACDgL8AAAA3PQAA71wBAAEAsgAAAOgCAAAAAAAAIQOABSuEAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACAADIwAAAQABkAZAAAABkAAABFbgAAJpoBAAAA
AAA5fZw+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAP//EgAAAAAAPwBDADoAXABQAHIAbwBnAHIAYQBtACAARgBpAGwAZQBzAFwATQBpAGMA
cgBvAHMAbwBmAHQAIABPAGYAZgBpAGMAZQBcAFQAZQBtAHAAbABhAHQAZQBzAFwAQgBGAE0AVABc
AEEANAAgAC0AIABCAGwAYQBuAGsALgBkAG8AdAABAKkAAAAAAAAAEABBAGQAcgBpAGEAbgAgAE0A
YwBDAHUAbABsAGEAZwBoABAAQQBkAHIAaQBhAG4AIABNAGMAQwB1AGwAbABhAGcAaAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAA
AAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAIABAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAACk
AAAABAAAALAAAAAFAAAAzAAAAAcAAADYAAAACAAAAOwAAAAJAAAACAEAABIAAAAUAQAACgAAADAB
AAALAAAAPAEAAAwAAABIAQAADQAAAFQBAAAOAAAAYAEAAA8AAABoAQAAEAAAAHABAAATAAAAeAEA
AAIAAADkBAAAHgAAAAIAAACpAHMAHgAAAAEAAAAAAHMAHgAAABEAAABBZHJpYW4gTWNDdWxsYWdo
AABkAB4AAAABAAAAAGRyaR4AAAALAAAAQTQgLSBCbGFuawBsHgAAABEAAABBZHJpYW4gTWNDdWxs
YWdoAABkAB4AAAADAAAAMjMAaR4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAABAAAAAAAxwRZgA
AABAAAAAAKb90UwxvwFAAAAAAN51rgf5vgFAAAAAADTVsnhGvwEDAAAAAQAAAAMAAADADwAAAwAA
AMtZAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAACAAAA
AtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuaAEAACQBAAAOAAAAAQAAAHgAAAAD
AAAAgAAAAA8AAACYAAAABAAAALAAAAAFAAAAuAAAAAYAAADAAAAAEQAAAMgAAAAXAAAA0AAAAAsA
AADYAAAAEAAAAOAAAAATAAAA6AAAABYAAADwAAAADQAAAPgAAAAMAAAABgEAAAIAAADkBAAAHgAA
AA4AAABXb3JkIERvY3VtZW50AHByHgAAAA8AAABHYWRlbnMgTGF3eWVycwByAwAAAPkqAAADAAAA
vwAAAAMAAAAtAAAAAwAAAEVuAAADAAAAMRUIAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAA
AAAAHhAAAAEAAAACAAAAqQAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAC4BQAACAAAAAAA
AABIAAAAAQAAAMQAAAACAAAAzAAAAAMAAAAkAQAABAAAAIgFAAAFAAAAlAUAAAYAAACgBQAABwAA
AKwFAAAGAAAAAgAAAAoAAABfUElEX0dVSUQAAwAAAAwAAABfUElEX0hMSU5LUwAEAAAAEAAAAHBy
T3BlcmF0b3JfaW5pdAAFAAAACQAAAHByTWF0dGVyAAYAAAAOAAAAcHJBdXRob3JfSW5pdAAHAAAA
CwAAAHByRG9jX1R5cGUAAgAAAOQEAABBAAAATgAAAHsANQA3ADEANwA3ADkAOQBCAC0AOQA4AEYA
RgAtADEAMQBEADEALQBCADEAOABCAC0AMAAwAEEAMABDADkAOABBAEIANgBEAEUAfQAAAAAAQQAA
AFwEAAAqAAAAAwAAACgAPAADAAAAEgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAQwAAAGgAdAB0AHAA
OgAvAC8AdwB3AHcALgBuAGMAaQBwAGgAZQByAC4AYwBvAG0ALwBwAHIAbwBkAHUAYwB0AHMALwBm
AGkAbABlAHMALwBwAGEAcABlAHIAcwAvAGEAbgBnAHUAaQBsAGwAYQAvAGsAZQB5AGgAaQBkAGUA
MgAuAHAAZABmAAAAAAAfAAAAAQAAAAAAAAADAAAAYQBlAAMAAAAPAAAAAwAAAAAAAAADAAAABQAA
AB8AAAAwAAAAaAB0AHQAcAA6AC8ALwBsAGEAdwAuAGcAbwB2AC4AYQB1AC8AYQBnAGgAbwBtAGUA
LwBhAGQAdgBpAHMAbwByAHkALwBlAGMAZQBnAC8AZQBjAGUAZwAuAGgAdABtAAAAHwAAAAEAAAAA
AAAAAwAAADUAbgADAAAADAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAOwAAAGgAdAB0AHAAOgAvAC8A
dwB3AHcALgBsAGEAdwAuAHUAbgBzAHcALgBlAGQAdQAuAGEAdQAvAHUAbgBzAHcAbABqAC8AZQBj
AG8AbQBtAGUAcgBjAGUALwBtAGMAYwB1AGwAbABhAGcAaAAuAGgAdABtAGwAAAAAAB8AAAABAAAA
AAAAAAMAAABTAE0AAwAAAAkAAAADAAAAAAAAAAMAAAAFAAAAHwAAADYAAABoAHQAdABwADoALwAv
AHcAdwB3AC4AdQBuAC4AbwByAC4AYQB0AC8AdQBuAGMAaQB0AHIAYQBsAC8AdABlAHgAdABzAC8A
ZQBsAGUAYwB0AGMAbwBtAC8AbQBsAC0AZQBjAC4AaAB0AG0AAAAfAAAAAQAAAAAAAAADAAAANQBu
AAMAAAAGAAAAAwAAAAAAAAADAAAABQAAAB8AAAA7AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGwA
YQB3AC4AdQBuAHMAdwAuAGUAZAB1AC4AYQB1AC8AdQBuAHMAdwBsAGoALwBlAGMAbwBtAG0AZQBy
AGMAZQAvAG0AYwBjAHUAbABsAGEAZwBoAC4AaAB0AG0AbAAAAAAAHwAAAAEAAAAAAAAAAwAAAAsA
HgADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAMgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBh
AGIAYQBuAGUAdAAuAG8AcgBnAC8AcwBjAGkAdABlAGMAaAAvAGUAYwAvAGkAcwBjAC8AZABzAGcA
ZgByAGUAZQAuAGgAdABtAGwAAAAfAAAAAQAAAAAAAAADAAAATgBeAAMAAAAAAAAAAwAAAAAAAAAD
AAAABQAAAB8AAAAiAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGIAaQBzAC4AbwByAGcALwBwAHUA
YgBsAC8AaQBuAGQAZQB4AC4AaAB0AG0AAAAfAAAAAQAAAAAAAAAeAAAABAAAAFRYQwAeAAAAAQAA
AABYQwAeAAAABAAAAEFKTQAeAAAAAgAAAGQATQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAA
CgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAY
AAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYA
AAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAA
ADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAA
QwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABR
AAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAP7/
//9gAAAAYQAAAGIAAABjAAAAZAAAAGUAAABmAAAA/v///2gAAABpAAAAagAAAGsAAABsAAAAbQAA
AG4AAABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAA
fAAAAH0AAAB+AAAAfwAAAIAAAACBAAAAggAAAIMAAACEAAAA/v///4YAAACHAAAAiAAAAIkAAACK
AAAAiwAAAIwAAAD+////jgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAP7////9/////f///5gA
AAD+/////v////7/////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA
RgAAAADAtRTPB/m+AUDTg8p4Rr8BmgAAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABfAAAAABAAAAAAAAAxAFQAYQBiAGwA
ZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAC
AAEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGcAAADoOwAA
AAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAaAAIBBgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAEC8AAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACFAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBt
AGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0AAAAAEAAAAAAAAAEAQwBvAG0AcABP
AGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB
AgAAAAcAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAA
AAAATwBiAGoAZQBjAHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAABYAAQD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAEDTg8p4Rr8BQNOD
ynhGvwEAAAAAAAAAAAAAAAABAAAA/v//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0
IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA

------_=_NextPart_000_01C0BE2B.043EA760--


Received: from thunder.dstc.qut.edu.au (thunder.dstc.qut.edu.au [131.181.71.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA17172 for <[e-mail]>; Thu, 5 Apr 2001 14:00:12 -0700 (PDT)
Received: from dstc.qut.edu.au (datsun.dstc.qut.edu.au [131.181.71.19]) by thunder.dstc.qut.edu.au (8.10.1/8.10.1) with ESMTP id f35L01m27649; Fri, 6 Apr 2001 07:00:05 +1000 (EST)
Message-Id: <[e-mail]>
To: Russ Housley <[e-mail]>
cc: [e-mail]
Subject: Re: A standard encoding for Certification Paths 
In-reply-to: Your message of "Thu, 05 Apr 2001 14:19:32 -0400." <[e-mail]> 
Date: Fri, 06 Apr 2001 07:00:00 +1000
From: Dean Povey <[e-mail]>

>Sean:
>
>You are right, but I want to explain why RFC 2630 uses a SET OF construct 
>for certificates.  We do not assume that each of the recipients has the 
>same trust anchors as the originator.  Therefore, the "bag of certificates" 
>provided might help construct certification paths to any number of 
>potential trust anchors.
>

Although just to be a grouch, the exact same semantics could have been
achieved using a SEQUENCE OF and saying that it is not ordered, as SET
OF is a pain in the butt to encode with DER.  But let us not start on
what is wrong with PKCS#7/CMS, as we could be here for a long time
:-).

Degenerate PKCS#7/CMS SignedData indeed seems to be the most common
method to pass around cert paths, which although something of an
insanity is a small insanity in a very large universe of insanities.
SEQUENCE OF Certificate is also not uncommon, and Polar's method of
just streaming the Certificates without wrapping them up in a higher
level ASN.1 structure is the way it is done in SSL/TLS.

Cheers.
--
Dean Povey,         | e-m: [e-mail] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  [phone]   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: [phone]   |        systems
Brisbane, Australia | www: security.dstc.com | 


Received: from mtiwmhc27.worldnet.att.net (mtiwmhc27.worldnet.att.net [204.127.131.52]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA15870 for <[e-mail]>; Thu, 5 Apr 2001 13:45:54 -0700 (PDT)
Received: from barth ([12.82.142.35]) by mtiwmhc27.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010405204524.ZJDE4349.mtiwmhc27.worldnet.att.net@barth>; Thu, 5 Apr 2001 20:45:24 +0000
From: "Dr. JohnDavid Hascup" <[e-mail]>
To: "Aisenberg, Michael" <[e-mail]>, <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Thu, 5 Apr 2001 13:44:41 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C0BDD6.9102BA60"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C0BDD6.9102BA60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Meaning of Non-repudiationMichael I wish the issue was as simple as you
desire it. Unfortunately when making use of PKI in the legal world there is
always an added complexity. I would love to see non-repudiation as a
non-issue, but having been in the discussion over the years, it is the one
issue that I continually faced at a table with legal councils. I know that
this list has quite often been faced with this and many points were
discussed with passion. Within the ABA the discussion has been also quite
active and gone on for years. Attempts were made to come to a common "legal"
understanding, unfortunately, until the legal councils I have to interact
with see decisions in a court related to non-repudiation by use of a
certificate they continue to make it hard for the acceptance of PKI in a
legal market. But I have no doubt that as with other new technologies the
real world will force lawyers to make use of it.

I know this seems strange given the history of questions surrounding the
introduction of any new technology by the legal market (privileged related
to faxes, then cell phones, and even email) and the eventual defining of the
issues. But in each of those cases the legal community came to its decisions
not on the basis of the technology but rather on the basis of court
decisions.

This may not be so for every market. Financial contracts and e-commerce
seems to have evolved with less issues surrounding non-repudiation in the
real world. But in the legal industry in which I am most familiar there are
always caveats and pages of interpretation to somehow work through. RFCs are
easy compared to the legal papers I have had to come to grips with.

Dr. JohnDavid Hascup
Senior Security Architect
ELF Technologies
  -----Original Message-----
  From: Aisenberg, Michael [mailto:[e-mail]]
  Sent: Thursday, April 05, 2001 1:01 PM
  To: 'Dr. JohnDavid Hascup'; Dave Oshman; [e-mail]
  Subject: RE: Meaning of Non-repudiation


  Am I missing something--Isn't the concept of non-repudiation to be framed
against the precedent of "repudiation" in the Code----2-610.

  Isn't the point of this great adventure to develop a common syntax for
deployment of certificate policies, not draw distinctions and
  create arguments for exceptions.  Complexities of this sort strike me as
being at the heart of marketplace resistance....

  Michael Aisenberg




------=_NextPart_000_0008_01C0BDD6.9102BA60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Meaning of Non-repudiation</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D030052820-05042001>Michael I wish the issue was as simple as you =
desire=20
it. Unfortunately when making use of PKI in the legal world there is =
always an=20
added complexity. I would love to see non-repudiation as a non-issue, =
but having=20
been in the discussion over the years, it is the one issue that I =
continually=20
faced at a table with legal councils. I know that this list has quite =
often been=20
faced with this and many points were discussed with passion. Within the =
ABA the=20
discussion has been also quite active and gone on for years. Attempts =
were made=20
to come to a common&nbsp;"legal" understanding, unfortunately, until the =
legal=20
councils I have to interact with see decisions in a court&nbsp;related =
to=20
non-repudiation by use of a certificate they continue to make it hard =
for the=20
acceptance of PKI in a legal market. But I have no doubt that as with =
other new=20
technologies the real world will force lawyers to make use of=20
it.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D030052820-05042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D030052820-05042001>I know=20
this seems strange given the history of questions surrounding the =
introduction=20
of any new technology by the legal market (privileged related to faxes, =
then=20
cell phones, and even email) and the eventual defining of the issues. =
But in=20
each of those cases the legal community came to its decisions not on the =
basis=20
of the technology but rather on the basis of court decisions.=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D030052820-05042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D030052820-05042001>This=20
may not be so for every market. Financial contracts and e-commerce seems =
to have=20
evolved with less issues surrounding non-repudiation in the real world. =
But in=20
the legal industry in which I am most familiar there are always caveats =
and=20
pages of interpretation to somehow work through. RFCs are easy compared =
to the=20
legal papers I have had to come to grips with.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D030052820-05042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D030052820-05042001>Dr.=20
JohnDavid Hascup</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D030052820-05042001>Senior=20
Security Architect</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D030052820-05042001>ELF=20
Technologies</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Aisenberg, Michael =

  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 05, =
2001 1:01=20
  PM<BR><B>To:</B> 'Dr. JohnDavid Hascup'; Dave Oshman;=20
  [e-mail]<BR><B>Subject:</B> RE: Meaning of=20
  Non-repudiation<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D013505619-05042001>Am I=20
  missing something--Isn't the concept of non-repudiation to be framed =
against=20
  the precedent of "repudiation" in the =
Code----2-610.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D013505619-05042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D013505619-05042001>Isn't the point of this great adventure to =
develop a=20
  common syntax for deployment of certificate policies, not draw =
distinctions=20
  and</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D013505619-05042001>create arguments for exceptions.&nbsp; =
Complexities=20
  of this sort strike me as being at the heart of marketplace=20
  resistance....</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D013505619-05042001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D013505619-05042001>
  <P><B><I><FONT face=3D"Monotype Corsiva" size=3D4>Michael =
Aisenberg</FONT></I></B>=20
  <BR></P></SPAN></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0008_01C0BDD6.9102BA60--



Received: from NETSOL-NIC-EX03.prod.netsol.com ([216.168.234.115]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA12973 for <[e-mail]>; Thu, 5 Apr 2001 13:03:00 -0700 (PDT)
Received: by netsol-nic-ex03.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9JYQYN>; Thu, 5 Apr 2001 15:59:13 -0400
Message-ID: <[e-mail]>
From: "Aisenberg, Michael" <[e-mail]>
To: "'Dr. JohnDavid Hascup'" <[e-mail]>, Dave Oshman <[e-mail]>, [e-mail]
Subject: RE: Meaning of Non-repudiation
Date: Thu, 5 Apr 2001 16:00:38 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BE0B.15A61EE0"

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_01C0BE0B.15A61EE0
Content-Type: text/plain;
	charset="iso-8859-1"

Am I missing something--Isn't the concept of non-repudiation to be framed
against the precedent of "repudiation" in the Code----2-610.
 
Isn't the point of this great adventure to develop a common syntax for
deployment of certificate policies, not draw distinctions and
create arguments for exceptions.  Complexities of this sort strike me as
being at the heart of marketplace resistance....
 
Michael Aisenberg 


-----Original Message-----
From: Dr. JohnDavid Hascup [mailto:[e-mail]]
Sent: Thursday, April 05, 2001 1:15 PM
To: Dave Oshman; [e-mail]
Subject: RE: Meaning of Non-repudiation


Dave

-----Original Message-----
From: Dave Oshman [mailto:[e-mail]]
Sent: Thursday, April 05, 2001 9:24 AM
To: [e-mail]
Subject: Meaning of Non-repudiation



I am trying to clarify the meaning of non-repudiation (as defined by the
technology standards) for our legal counsel. 2459 says this about
non-repudiation:
[JDH] this is the abyss of PKI. Having spent over three years working with
legal counsel on how to understand non-repudiation I have yet to find a
viable "legal" interpretation of the technological protocol. I think the
past year Tom Grindin was developing a "technical non-repudiation" draft
which I think has lapsed as of the past meeting in Minneapolis. It was an
attempt to ground non-repudiation with a meaning that would be "legal"
neutral but protocol specific.

     The nonRepudiation bit is asserted when the subject public key is 
      used to verify digital signatures used to provide a non- 
      repudiation service which protects against the signing entity 
      falsely denying some action, excluding certificate or CRL signing. 

The question is what does "some action" mean? Is the action merely signing
the transaction? Or, is the action perhaps committing to the terms described
in the signed transaction?

To rephrase: Is non-repudiation stating simply that I, Dave Oshman, signed
this document? Or, is it supposed to mean that I, Dave Oshman, attest that I
am committing myself (or my company) to the terms described herein?
[JDH] IMO "legal" non-repudiation must be set via the entire environment of
the PKI as specifically defined in whatever policies the RP sets. This means
that it is the RP's use of the bit or non-use that is important. The reason
I felt this was due to the fact that once the question enters the court it,
the technical setting of the bit is not what is important but rather the
interpretation placed upon it by the RP and thus the EE. Apart from a "clear
stated policy" of what the RP intends for it's understanding of
non-repudiation the technical aspects are meaningless. The asserting of the
bit must be given meaning in the context of the environment and cannot have
a meaning legally apart from that environment. Therefore, your second
meaning can only be grounded in the policies set by the environment in which
you are signing and not in the technical underlying protocol. As for the
first, at most, one can argue that the cert granted to you signed. This is
why we had such a difficult time moving "technical" non-repudiation into a
legal context. What is the legal relationship between the certificate and
the person to whom the cert was issued. The protocol can offer forensic
evidence regarding the relationship and the actions of the cert but in and
of itself offers no legal meaning.

 

Is this more clearly defined in X.813 (ITU-T Recommendation X.8131) |
ISO/IEC 10181-3:...1), Information technology - Open Systems Interconnection
- Security Frameworks in Open Systems - Non-repudiation framework)? Can
anyone snip a description of non-repudiation from X.813?

Thanks! 
Dave Oshman 
Senior Vice President 
Technology 
Identrus LLC 




Dr. JohnDavid Hascup
Senior Security Architect
ELF Technologies


------_=_NextPart_001_01C0BE0B.15A61EE0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Meaning of Non-repudiation</TITLE>

<META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=013505619-05042001>Am I 
missing something--Isn't the concept of non-repudiation to be framed against the 
precedent of "repudiation" in the Code----2-610.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=013505619-05042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=013505619-05042001>Isn't 
the point of this great adventure to develop a common syntax for deployment of 
certificate policies, not draw distinctions and</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=013505619-05042001>create 
arguments for exceptions.&nbsp; Complexities of this sort strike me as being at 
the heart of marketplace resistance....</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=013505619-05042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=013505619-05042001>
<P><B><I><FONT face="Monotype Corsiva" size=4>Michael Aisenberg</FONT></I></B> 
<BR></P></SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Dr. JohnDavid Hascup 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 05, 2001 1:15 
  PM<BR><B>To:</B> Dave Oshman; [e-mail]<BR><B>Subject:</B> RE: Meaning 
  of Non-repudiation<BR><BR></DIV></FONT>
  <DIV><SPAN class=520255216-05042001><FONT color=#0000ff face=Arial 
  size=2>Dave</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Dave Oshman 
    [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 05, 2001 
    9:24 AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Meaning of 
    Non-repudiation<BR><BR></FONT></DIV>
    <P><FONT size=2>I am trying to clarify the meaning of non-repudiation (as 
    defined by the technology standards) for our legal counsel. 2459 says this 
    about non-repudiation:<BR><SPAN class=520255216-05042001><FONT color=#0000ff 
    face=Arial>[JDH]&nbsp;this is the abyss of PKI. Having spent over three 
    years working with legal counsel on how to understand non-repudiation I have 
    yet to find a viable "legal" interpretation of the technological protocol. I 
    think the past year Tom Grindin&nbsp;was developing a "technical 
    non-repudiation" draft which I&nbsp;think has lapsed as of the past meeting 
    in Minneapolis. It was an attempt to ground non-repudiation with a meaning 
    that would be "legal" neutral but protocol 
specific.</FONT></SPAN></FONT></P>
    <P><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp; The nonRepudiation bit is asserted 
    when the subject public key is</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify digital signatures used 
    to provide a non-</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    repudiation service which protects against the signing entity</FONT> 
    <BR><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; falsely denying some action, 
    excluding certificate or CRL signing.</FONT> </P>
    <P><FONT size=2>The question is what does "some action" mean? Is the action 
    merely signing the transaction? Or, is the action perhaps committing to the 
    terms described in the signed transaction?</FONT></P>
    <P><FONT size=2>To rephrase: Is non-repudiation stating simply that I, Dave 
    Oshman, signed this document? Or, is it supposed to mean that I, Dave 
    Oshman, attest that I am committing myself (or my company) to the terms 
    described herein?<BR><SPAN class=520255216-05042001><FONT color=#0000ff 
    face=Arial>[JDH]&nbsp;<SPAN class=520255216-05042001><FONT color=#0000ff 
    face=Arial size=2>IMO "legal" non-repudiation must be set via the entire 
    environment of the PKI as specifically defined in whatever policies the RP 
    sets. This means that it is the RP's use of the bit or non-use that is 
    important. The reason I felt this was due to the fact that once the question 
    enters the court it, the technical setting of the bit is not what is 
    important but rather the interpretation placed upon it by the RP and thus 
    the EE. Apart from a "clear stated policy" of what the RP intends for it's 
    understanding of non-repudiation the technical aspects are meaningless. The 
    asserting of the bit must be given meaning in the context of the environment 
    and cannot have a meaning legally apart from that 
    environment.</FONT></SPAN>&nbsp;Therefore, your second meaning can only be 
    grounded in the policies set by the environment in which you are signing and 
    not in the technical underlying protocol. As for the first, at most, one can 
    argue that the cert granted to you signed. This is why we had such a 
    difficult time moving "technical" non-repudiation into a legal context. What 
    is the legal relationship between the certificate and the person to whom the 
    cert was issued. The protocol can offer forensic evidence regarding the 
    relationship and the actions of the cert but in and of itself offers no 
    legal meaning.</FONT></SPAN></FONT></P>
    <P><FONT color=#0000ff face=Arial size=2><SPAN 
    class=520255216-05042001></SPAN></FONT><FONT color=#0000ff face=Arial 
    size=2><SPAN class=520255216-05042001></SPAN></FONT>&nbsp;</P>
    <P><FONT size=2>Is this more clearly defined in X.813 (ITU-T Recommendation 
    X.8131) | ISO/IEC 10181-3:...1), Information technology - Open Systems 
    Interconnection - Security Frameworks in Open Systems - Non-repudiation 
    framework)? Can anyone snip a description of non-repudiation from 
    X.813?</FONT></P>
    <P><FONT size=2>Thanks!</FONT> <BR><FONT size=2>Dave Oshman </FONT><BR><FONT 
    size=2>Senior Vice President </FONT><BR><FONT size=2>Technology 
    </FONT><BR><FONT size=2>Identrus LLC</FONT> <BR></P><SPAN 
    class=520255216-05042001><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN></BLOCKQUOTE>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV><SPAN class=520255216-05042001><FONT color=#0000ff face=Arial 
    size=2>Dr. JohnDavid Hascup</FONT></SPAN></DIV>
    <DIV><SPAN class=520255216-05042001><FONT color=#0000ff face=Arial 
    size=2>Senior Security Architect</FONT></SPAN></DIV>
    <DIV><SPAN class=520255216-05042001><FONT color=#0000ff face=Arial 
    size=2>ELF 
Technologies</FONT></SPAN></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0BE0B.15A61EE0--


Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA06889 for <[e-mail]>; Thu, 5 Apr 2001 11:50:08 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Apr 2001 18:47:44 UT
Received: from HOUSLEY-LAP.rsasecurity.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA12727; Thu, 5 Apr 2001 14:49:51 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 05 Apr 2001 14:19:32 -0400
To: Sean Mullan <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: A standard encoding for Certification Paths
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Sean:

You are right, but I want to explain why RFC 2630 uses a SET OF construct 
for certificates.  We do not assume that each of the recipients has the 
same trust anchors as the originator.  Therefore, the "bag of certificates" 
provided might help construct certification paths to any number of 
potential trust anchors.

Russ

At 04:34 PM 4/5/2001 +0100, Sean Mullan wrote:
>X.509 defines several ASN.1 structures for encoding a
>certification path:
>
>Certificates ::= SEQUENCE {
>  userCertificate    Certificate,
>  certificationPath  ForwardCertificationPath OPTIONAL }
>
>CertificationPath ::= SEQUENCE {
>  userCertificate    Certificate,
>  theCACertificates  SEQUENCE OF CertificatePair OPTIONAL }
>
>ForwardCertificationPath ::= SEQUENCE OF CrossCertificates
>CrossCertificates ::= SET OF Certificate
>
>CertificatePair ::= SEQUENCE {
>  forward [0] Certificate OPTIONAL,
>  reverse [1] Certificate OPTIONAL
>  -- at least one of the pair shall be present -- }
>
>But they all seem a bit more complex than necessary. A much
>simpler structure should be sufficient for most applications:
>
>CertificationPath ::= SEQUENCE OF Certificate
>
>where the SEQUENCE OF Certificates are ordered from the end-entity
>certificate to the certificate issued by the trust anchor.
>
>It seems that a standard, simple ASN.1 format for representing an
>ordered certification path is useful and is missing.
>
>Has anyone else faced this issue and if so can you suggest any solutions
>or other possible standard encoding formats not mentioned above? Note that
>a PKCS #7 SignedData object is not a good solution, since it uses
>an ASN.1 SET OF construct to hold certificates, thus the order may not be
>preserved.
>
>Thanks,
>Sean



Received: from marcy.adiron.com (root@[128.230.111.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA05303 for <[e-mail]>; Thu, 5 Apr 2001 11:34:55 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.10.2/8.10.2) with ESMTP id f35ISbM18862; Thu, 5 Apr 2001 18:28:37 GMT
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 5 Apr 2001 14:28:37 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Sean Mullan <[e-mail]>
cc: <[e-mail]>
Subject: Re: A standard encoding for Certification Paths
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

Comment below:

On Thu, 5 Apr 2001, Sean Mullan wrote:

> X.509 defines several ASN.1 structures for encoding a
> certification path:
>
> Certificates ::= SEQUENCE {
>  userCertificate    Certificate,
>  certificationPath  ForwardCertificationPath OPTIONAL }
>
> CertificationPath ::= SEQUENCE {
>  userCertificate    Certificate,
>  theCACertificates  SEQUENCE OF CertificatePair OPTIONAL }
>
> ForwardCertificationPath ::= SEQUENCE OF CrossCertificates
> CrossCertificates ::= SET OF Certificate
>
> CertificatePair ::= SEQUENCE {
>  forward [0] Certificate OPTIONAL,
>  reverse [1] Certificate OPTIONAL
>  -- at least one of the pair shall be present -- }
>
> But they all seem a bit more complex than necessary. A much
> simpler structure should be sufficient for most applications:
>
> CertificationPath ::= SEQUENCE OF Certificate

I believe the lowest common denominator for a sequence of certificates is
exactly that, a stream of ASN.1 Certificate encodings.

Each ASN.1 Certificate object already has an encoded length, and is
therefore each object (certificate) is extractable from the stream.
Anyway, a byte stream is what sits behind the ASN.1 Sequence Header.

Usually, if you have such a stream, such as a file or a byte buffer, it is
encapsulated so that the length of the sequence is determinable from other
means, either by the length of the file, or buffer. So, the ASN.1 sequence
header information is really redundant. Isn't it?

IMHO, the only reason to standardize such a format, i.e. make an ASN.1
object out of a sequence of certificates, would be to place it inside
other ASN.1 object. However, that is easily accomplished by inserting

 member SEQUENCE OF Certificate

inside the object's description.

Cheers,
-Polar

> where the SEQUENCE OF Certificates are ordered from the end-entity
> certificate to the certificate issued by the trust anchor.
>
> It seems that a standard, simple ASN.1 format for representing an
> ordered certification path is useful and is missing.
>
> Has anyone else faced this issue and if so can you suggest any solutions
> or other possible standard encoding formats not mentioned above? Note that
> a PKCS #7 SignedData object is not a good solution, since it uses
> an ASN.1 SET OF construct to hold certificates, thus the order may not be
> preserved.
>
> Thanks,
> Sean
>




Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00722 for <[e-mail]>; Thu, 5 Apr 2001 10:16:18 -0700 (PDT)
Received: from barth ([12.82.137.231]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010405171533.XUJS10838.mtiwmhc24.worldnet.att.net@barth>; Thu, 5 Apr 2001 17:15:33 +0000
From: "Dr. JohnDavid Hascup" <[e-mail]>
To: "Dave Oshman" <[e-mail]>, <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Thu, 5 Apr 2001 10:14:35 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C0BDB9.36E2B340"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <2B55DABB95C4D4119C1300508BD953F114420B@BLUE01>

This is a multi-part message in MIME format.

------=_NextPart_000_0002_01C0BDB9.36E2B340
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Meaning of Non-repudiationDave
  -----Original Message-----
  From: Dave Oshman [mailto:[e-mail]]
  Sent: Thursday, April 05, 2001 9:24 AM
  To: [e-mail]
  Subject: Meaning of Non-repudiation


  I am trying to clarify the meaning of non-repudiation (as defined by the
technology standards) for our legal counsel. 2459 says this about
non-repudiation:
  [JDH] this is the abyss of PKI. Having spent over three years working with
legal counsel on how to understand non-repudiation I have yet to find a
viable "legal" interpretation of the technological protocol. I think the
past year Tom Grindin was developing a "technical non-repudiation" draft
which I think has lapsed as of the past meeting in Minneapolis. It was an
attempt to ground non-repudiation with a meaning that would be "legal"
neutral but protocol specific.

       The nonRepudiation bit is asserted when the subject public key is
        used to verify digital signatures used to provide a non-
        repudiation service which protects against the signing entity
        falsely denying some action, excluding certificate or CRL signing.

  The question is what does "some action" mean? Is the action merely signing
the transaction? Or, is the action perhaps committing to the terms described
in the signed transaction?

  To rephrase: Is non-repudiation stating simply that I, Dave Oshman, signed
this document? Or, is it supposed to mean that I, Dave Oshman, attest that I
am committing myself (or my company) to the terms described herein?
  [JDH] IMO "legal" non-repudiation must be set via the entire environment
of the PKI as specifically defined in whatever policies the RP sets. This
means that it is the RP's use of the bit or non-use that is important. The
reason I felt this was due to the fact that once the question enters the
court it, the technical setting of the bit is not what is important but
rather the interpretation placed upon it by the RP and thus the EE. Apart
from a "clear stated policy" of what the RP intends for it's understanding
of non-repudiation the technical aspects are meaningless. The asserting of
the bit must be given meaning in the context of the environment and cannot
have a meaning legally apart from that environment. Therefore, your second
meaning can only be grounded in the policies set by the environment in which
you are signing and not in the technical underlying protocol. As for the
first, at most, one can argue that the cert granted to you signed. This is
why we had such a difficult time moving "technical" non-repudiation into a
legal context. What is the legal relationship between the certificate and
the person to whom the cert was issued. The protocol can offer forensic
evidence regarding the relationship and the actions of the cert but in and
of itself offers no legal meaning.



  Is this more clearly defined in X.813 (ITU-T Recommendation X.8131) |
ISO/IEC 10181-3:...1), Information technology - Open Systems
Interconnection - Security Frameworks in Open Systems - Non-repudiation
framework)? Can anyone snip a description of non-repudiation from X.813?

  Thanks!
  Dave Oshman
  Senior Vice President
  Technology
  Identrus LLC


  Dr. JohnDavid Hascup
  Senior Security Architect
  ELF Technologies

------=_NextPart_000_0002_01C0BDB9.36E2B340
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Meaning of Non-repudiation</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D520255216-05042001><FONT face=3DArial color=3D#0000ff =

size=3D2>Dave</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Dave Oshman=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 05, =
2001=20
  9:24 AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Meaning of=20
  Non-repudiation<BR><BR></FONT></DIV>
  <P><FONT size=3D2>I am trying to clarify the meaning of =
non-repudiation (as=20
  defined by the technology standards) for our legal counsel. 2459 says =
this=20
  about non-repudiation:<BR><SPAN class=3D520255216-05042001><FONT =
face=3DArial=20
  color=3D#0000ff>[JDH]&nbsp;this is the abyss of PKI. Having spent over =
three=20
  years working with legal counsel on how to understand non-repudiation =
I have=20
  yet to find a viable "legal" interpretation of the technological =
protocol. I=20
  think the past year Tom Grindin&nbsp;was developing a "technical=20
  non-repudiation" draft which I&nbsp;think has lapsed as of the past =
meeting in=20
  Minneapolis. It was an attempt to ground non-repudiation with a =
meaning that=20
  would be "legal" neutral but protocol =
specific.</FONT></SPAN></FONT></P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; The nonRepudiation bit is =
asserted=20
  when the subject public key is</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify digital =
signatures used=20
  to provide a non-</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  repudiation service which protects against the signing entity</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; falsely denying some action, =
excluding=20
  certificate or CRL signing.</FONT> </P>
  <P><FONT size=3D2>The question is what does "some action" mean? Is the =
action=20
  merely signing the transaction? Or, is the action perhaps committing =
to the=20
  terms described in the signed transaction?</FONT></P>
  <P><FONT size=3D2>To rephrase: Is non-repudiation stating simply that =
I, Dave=20
  Oshman, signed this document? Or, is it supposed to mean that I, Dave =
Oshman,=20
  attest that I am committing myself (or my company) to the terms =
described=20
  herein?<BR><SPAN class=3D520255216-05042001><FONT face=3DArial=20
  color=3D#0000ff>[JDH]&nbsp;<SPAN class=3D520255216-05042001><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>IMO "legal" non-repudiation must be set via =
the entire=20
  environment of the PKI as specifically defined in whatever policies =
the RP=20
  sets. This means that it is the RP's use of the bit or non-use that is =

  important. The reason I felt this was due to the fact that once the =
question=20
  enters the court it, the technical setting of the bit is not what is =
important=20
  but rather the interpretation placed upon it by the RP and thus the =
EE. Apart=20
  from a "clear stated policy" of what the RP intends for it's =
understanding of=20
  non-repudiation the technical aspects are meaningless. The asserting =
of the=20
  bit must be given meaning in the context of the environment and cannot =
have a=20
  meaning legally apart from that =
environment.</FONT></SPAN>&nbsp;Therefore,=20
  your second meaning can only be grounded in the policies set by the=20
  environment in which you are signing and not in the technical =
underlying=20
  protocol. As for the first, at most, one can argue that the cert =
granted to=20
  you signed. This is why we had such a difficult time moving =
"technical"=20
  non-repudiation into a legal context. What is the legal relationship =
between=20
  the certificate and the person to whom the cert was issued. The =
protocol can=20
  offer forensic evidence regarding the relationship and the actions of =
the cert=20
  but in and of itself offers no legal meaning.</FONT></SPAN></FONT></P>
  <P><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D520255216-05042001></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2><SPAN class=3D520255216-05042001></SPAN></FONT>&nbsp;</P>
  <P><FONT size=3D2>Is this more clearly defined in X.813 (ITU-T =
Recommendation=20
  X.8131) | ISO/IEC 10181-3:...1), Information technology - Open Systems =

  Interconnection - Security Frameworks in Open Systems - =
Non-repudiation=20
  framework)? Can anyone snip a description of non-repudiation from=20
  X.813?</FONT></P>
  <P><FONT size=3D2>Thanks!</FONT> <BR><FONT size=3D2>Dave Oshman =
</FONT><BR><FONT=20
  size=3D2>Senior Vice President </FONT><BR><FONT size=3D2>Technology=20
  </FONT><BR><FONT size=3D2>Identrus LLC</FONT> <BR></P><SPAN=20
  class=3D520255216-05042001><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT></SPAN></BLOCKQUOTE>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D520255216-05042001><FONT face=3DArial =
color=3D#0000ff size=3D2>Dr.=20
  JohnDavid Hascup</FONT></SPAN></DIV>
  <DIV><SPAN class=3D520255216-05042001><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Senior Security Architect</FONT></SPAN></DIV>
  <DIV><SPAN class=3D520255216-05042001><FONT face=3DArial =
color=3D#0000ff size=3D2>ELF=20
  Technologies</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0002_01C0BDB9.36E2B340--



Received: from blue01.identrus.com ([216.213.93.123]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA29456 for <[e-mail]>; Thu, 5 Apr 2001 09:26:00 -0700 (PDT)
Received: by BLUE01 with Internet Mail Service (5.5.2653.19) id <G6T1YBBB>; Thu, 5 Apr 2001 12:24:04 -0400
Message-ID: <2B55DABB95C4D4119C1300508BD953F114420B@BLUE01>
From: Dave Oshman <[e-mail]>
To: [e-mail]
Subject: Meaning of Non-repudiation
Date: Thu, 5 Apr 2001 12:23:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BDEC.CF21BC40"

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_01C0BDEC.CF21BC40
Content-Type: text/plain;
	charset="iso-8859-1"

I am trying to clarify the meaning of non-repudiation (as defined by the
technology standards) for our legal counsel. 2459 says this about
non-repudiation:
     The nonRepudiation bit is asserted when the subject public key is
      used to verify digital signatures used to provide a non-
      repudiation service which protects against the signing entity
      falsely denying some action, excluding certificate or CRL signing.

The question is what does "some action" mean? Is the action merely signing
the transaction? Or, is the action perhaps committing to the terms described
in the signed transaction?

To rephrase: Is non-repudiation stating simply that I, Dave Oshman, signed
this document? Or, is it supposed to mean that I, Dave Oshman, attest that I
am committing myself (or my company) to the terms described herein?

Is this more clearly defined in X.813 (ITU-T Recommendation X.8131) |
ISO/IEC 10181-3:...1), Information technology - Open Systems Interconnection
- Security Frameworks in Open Systems - Non-repudiation framework)? Can
anyone snip a description of non-repudiation from X.813?
Thanks!
Dave Oshman 
Senior Vice President 
Technology 
Identrus LLC

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Meaning of Non-repudiation</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I am trying to clarify the meaning of non-repudiation =
(as defined by the technology standards) for our legal counsel. 2459 =
says this about non-repudiation:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; The nonRepudiation bit is =
asserted when the subject public key is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to verify =
digital signatures used to provide a non-</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; repudiation service =
which protects against the signing entity</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; falsely denying some =
action, excluding certificate or CRL signing.</FONT>
</P>

<P><FONT SIZE=3D2>The question is what does &quot;some action&quot; =
mean? Is the action merely signing the transaction? Or, is the action =
perhaps committing to the terms described in the signed =
transaction?</FONT></P>

<P><FONT SIZE=3D2>To rephrase: Is non-repudiation stating simply that =
I, Dave Oshman, signed this document? Or, is it supposed to mean that =
I, Dave Oshman, attest that I am committing myself (or my company) to =
the terms described herein?</FONT></P>

<P><FONT SIZE=3D2>Is this more clearly defined in X.813 (ITU-T =
Recommendation X.8131) | ISO/IEC 10181-3:...1), Information technology =
- Open Systems Interconnection - Security Frameworks in Open Systems - =
Non-repudiation framework)? Can anyone snip a description of =
non-repudiation from X.813?</FONT></P>

<P><FONT SIZE=3D2>Thanks!</FONT>
<BR><FONT SIZE=3D2>Dave Oshman </FONT>
<BR><FONT SIZE=3D2>Senior Vice President </FONT>
<BR><FONT SIZE=3D2>Technology </FONT>
<BR><FONT SIZE=3D2>Identrus LLC</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0BDEC.CF21BC40--


Received: from mail.funk.com (machine-22.funk.com [198.186.160.22] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA26868 for <[e-mail]>; Thu, 5 Apr 2001 08:47:49 -0700 (PDT)
Received: by machine-22.funk.com with Internet Mail Service (5.5.2653.19) id <H7V2SC0R>; Thu, 5 Apr 2001 11:48:53 -0400
Message-ID: <[e-mail]>
From: Aslam <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: V3 Extensions
Date: Thu, 5 Apr 2001 11:48:52 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"

> 	Hi,
> 
> 	I wanna know about some docs which give me datails about v3
> extensions like SubjectKeyIdentifier etc.. and how they r generated?
> 
> 	Thanks
> 	Aslam
> 


Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA24077 for <[e-mail]>; Thu, 5 Apr 2001 08:34:30 -0700 (PDT)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05776 for <[e-mail]>; Thu, 5 Apr 2001 08:34:31 -0700 (PDT)
Received: from sun.com (boston [129.156.220.153]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id QAA27088; Thu, 5 Apr 2001 16:34:30 +0100 (BST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 05 Apr 2001 16:34:30 +0100
From: Sean Mullan <[e-mail]>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: A standard encoding for Certification Paths
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

X.509 defines several ASN.1 structures for encoding a
certification path:

Certificates ::= SEQUENCE {
 userCertificate    Certificate,
 certificationPath  ForwardCertificationPath OPTIONAL }

CertificationPath ::= SEQUENCE {
 userCertificate    Certificate,
 theCACertificates  SEQUENCE OF CertificatePair OPTIONAL }

ForwardCertificationPath ::= SEQUENCE OF CrossCertificates
CrossCertificates ::= SET OF Certificate

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

But they all seem a bit more complex than necessary. A much 
simpler structure should be sufficient for most applications:

CertificationPath ::= SEQUENCE OF Certificate

where the SEQUENCE OF Certificates are ordered from the end-entity 
certificate to the certificate issued by the trust anchor.

It seems that a standard, simple ASN.1 format for representing an 
ordered certification path is useful and is missing. 
 
Has anyone else faced this issue and if so can you suggest any solutions
or other possible standard encoding formats not mentioned above? Note that
a PKCS #7 SignedData object is not a good solution, since it uses 
an ASN.1 SET OF construct to hold certificates, thus the order may not be 
preserved.  

Thanks,
Sean


Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA02967 for <[e-mail]>; Thu, 5 Apr 2001 03:41:07 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for <[e-mail]>; Thu, 5 Apr 2001 08:02:35 -0100
From: "Rita de Groot" <[e-mail]>
To: <[e-mail]>
Subject: huidziekte
Sender: "Rita de Groot" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Thu, 5 Apr 2001 11:00:06 +0200
Content-Transfer-Encoding: 8bit

Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose 
reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. 
Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien..........
http://www.naardedokter.com/testimonials/sys_lup_eryth.htm


Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA27525 for <[e-mail]>; Wed, 4 Apr 2001 13:33:22 -0700 (PDT)
Received: from santesson.addtrust.com ([62.20.231.85]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 4 Apr 2001 22:32:13 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 04 Apr 2001 22:33:35 +0200
To: Stephen Kent <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Logotypes in certificates
Cc: [e-mail]
In-Reply-To: <p05010400b6ef9022503a@[128.33.4.39]>
References: <[e-mail]> <[e-mail]> < <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 04 Apr 2001 20:32:14.0359 (UTC) FILETIME=[55586270:01C0BD46]

Steve,

At 10:43 2001-04-03 -0400, Stephen Kent wrote:
>I learned long ago that it's often a bad idea to agree to a concept 
>irrespective of a proposed means of achieving it. So, absent a concrete 
>proposal for HOW, I don't think we have consensus on WHETHER to pursue 
>this work item.  That's why I proposed that you, as the prime mover behind 
>the idea, develop a comprehensive proposal for what you are trying to 
>achieve and how you propose to achieve it. if you can't find the time to 
>do that, then we will not pursue it.

Well I will do my homework, including investigating other ways and foras to 
pursue this. If there is enough interest and consensus and if there is a 
general understanding that PKIX is the right place, then I will make sure 
that the material you ask for will be presented to the list.

/Stefan



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA06021 for <[e-mail]>; Tue, 3 Apr 2001 14:00:31 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA22223 for <[e-mail]>; Tue, 3 Apr 2001 17:00:32 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501041ab6efe961481e@[128.33.4.39]>
In-Reply-To: <p0501040fb6efdaa4d1c0@[128.33.4.39]>
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <p05100802b6e1aad52bbf@[165.227.249.20]> <p0501040bb6efb5d22afc@[128.33.4.39]> <p05100802b6efb8522a2a@[165.227.249.20]> <p0501040eb6efbec745a3@[128.33.4.39]> <p05100803b6efcacc8177@[165.227.249.20]> <p0501040fb6efdaa4d1c0@[128.33.4.39]>
Date: Tue, 3 Apr 2001 16:58:48 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: slides anyone
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

I have submitted the corrected minutes for our last meeting, (cc'd to 
this list as well) and was about to submit the slides. But I have 
contributions only from Mike Myers and Denis Pinkas (and, of course, 
me).  All other speakers from the PKIX WG meetings at the 50th IETF 
should send me their slides now, so that I can forward them to the 
secretariat.

Thanks,

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA06022 for <[e-mail]>; Tue, 3 Apr 2001 14:00:31 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA22220; Tue, 3 Apr 2001 17:00:31 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010417b6efe80ff8b5@[128.33.4.39]>
Date: Tue, 3 Apr 2001 16:57:32 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: PKIX minutes
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

PKIX WG Meeting 3/20/01
Edited by Steve Kent (WG co-chairs)

The PKIX WG met once during the 50th IETF. A total of approximately 
155 individuals participated in the meeting.


Tim quickly reviewed the agenda and document status, noting that 
there are many  I-Ds in progress. (see slides)

Two new RFCs:
	RFC 3029	Data Validation and Certification Server
			(Experimental)
	RFC 3039	Qualified Certificates (Proposed Standard)

In the IESG Review Process:
	Timestamp Protocol (missing IANA considerations section)
	Attribute Certificate Profile
		(missing IANA considerations section and another issue)

Soon to be Submitted to IESG:
	PKIX Roadmap (Informational)
	Permanent Identifier (Experimental?)
	Repository Locator Service (Experimental)

In WG Last Call:
	Son-of-RFC 2459
	Public Algorithms and Identifiers
	CRMF & CMP
CMP/CRMF Interoperability results?

Close to WG last call:
	OCSPv1 bis

Evolving Specifications
	Technical NR (being revised)
	OCSPv2
	Additional LDAP Schema
	Attribute Certificate Acquisition Protocol
	CP/CPS Framework
	DPD/DPV requirements

New Work
	Impersonation Certificates
	Group Name

Status of RFC 2459bis- Russ Housley (RSA Labs)
	After discussions with ITU-T counterparts, path length 
computation was fixed, in a fashion consistent with the existing PKIX 
documents. Also answered the question "who can issue CRLs," by 
allowing a CA certificate to contain EITHER the keyCertSign OR 
cRLSign bits OR BOTH. Thus only CAs (syntactically speaking) issue 
CRLs, bit it allows creation of an entity that is marked as a CA, but 
which is restricted to signing CRLs. (slides)

OCSPv1 - Ambarish Malpani (ValiCert)
	Moving OCSPv1 to Draft Standard. Interoperability efforts 
going well, including PKI Forum work. Also some minor clarifications 
of the text. Make RSA mandatory, drop required support for DSA. 
(slides)

CMC - Jim Schaad (Soaring Hawk Consulting)
	Updating document, symmetric key distribution ambiguity, 
minor editorial
corrections. Hope to complete updates and get interoperability test data
for progression to Draft in about 6 months. (no slides)

Impersonation Certificates - Stephen Tuecke (Argonne Labs)
	Renamed proxy certificates. Motivation is single signon delegation
support. Intent is to bind a new key pair to a subject alt name and to an
extension that labels this as a proxy certificate. However, there are
conflicts between this proposal and the existing and revised profile (and
X.509). Specifically, the EE is acting like a CA, syntactically, but the
EE certificate does not have the basicConstraints flag set to mark it as a
CA. Thus the path validation algorithm would reject these proxy
certificates. (slides)

DPD/DPV Requirements - Steve Kent (BBN)
	Presentation described revised proposals for DPD and DPV requests and
responses, using ASN.1 strawmen examples. Ended with a plan for progress
on the topic, resulting in selection of a protocol before the next IETF
meeting in August.  Steve Farrell expressed concern that the DPD request
is too complex, contains unnecessary controls, based on a model that does
not require returned paths to be ones that will necessarily 
successfully validate for the client. (slides)

OCSPv2 - Michael Myers (VeriSign)
	Expansion of OCSPv1 to create a candidate protocol for the DPD & DPV
functions. Includes a facility to support nonce relay, by concatenating
new nonces with old ones. Emphasis on reuse of OCSPv1 structures wherever
possible, e.g., with regard to status responses. There are fewer controls
on path construction for DPD vs. DPD, based on assumptions about relative
capability of clients and on perception of likely complexity of
certificate graphs. (slides)

DPD/DPV - Denis Pinkas (Bull)
	For DPV, major focus is valid/invalid response, plus optional proof
returned when needed, e.g., for NR. Can have a small response with Y/N
response and hash as a link to the supporting info. Suggests just a single
path and revocation status data should be returned. For DPD need a path
returned always, unlike DPV. Suggests partial revocation status data might
be returned, if complete data not available. (Both DPD + DPV specify the
target by either supplying a certificate or an Issuer name and serial
number.) Suggestion that CA and EE certificates may not want the same
revocation status data, but Mike Myers disagrees with this distinction.
Proposal for partial responses, e.g., incomplete paths. Argument against
DPV support for a posteriori validation when the time frame is outside of
the certificate validity period. Finally, argues for stateless servers,
i.e., no retry facility in DPD. (slides)

SCVP - Ambarish Malpani (ValiCert)
	Removed XML syntax, and will use CMS as secure enveloping 
mechanism. (one slide)

Group Name - Mike St. Johns (??)
	Motivation is to support a commonly employed OS naming convention in EE
certificates, instead of having to map from a DN. Possible uses in
attribute certificates too. Currently proposed as an OtherName but open to
suggestions for encoding. (slides)

Policy Requirements for TSAs - Denis Pinkas (Bull)
	This is a new ETSI work item. Will complement existing ETSI 
standards on
electronic signature formats, qualified certificates, and a document
addressing policy for CAs issuing qualified certificates. TSA policy will
be based on RFC 2527 and ETSI 456.  Welcome participation and inputs from
PKIX and SMIME WG members. (slides)



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA04257 for <[e-mail]>; Tue, 3 Apr 2001 13:40:54 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA18996; Tue, 3 Apr 2001 16:40:55 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010414b6efe45d1a47@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 3 Apr 2001 16:36:35 -0400
To: Nada Kapidzic Cicovic <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: draft meeting minutes, please comment
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 1:51 PM +0200 4/2/01, Nada Kapidzic Cicovic wrote:
>>...
>
>Hi Steve,
>
>Just one quick comment:
>
>>Status of RFC 2459bis- Russ Housley (RSA Labs)
>>         Fixed path length computation. Fix "who can issue CRLs" 
>>problem by allowing a CA certificate to contain EITHER the 
>>KeyCertSign OR cRLSign bits.
>
>My understanding of the explanation was "a certificate with either 
>keyCertSign bit on, or cRLSign bit on, or BOTH". The above sentence 
>implies that the presence of keyCertSign bit excludes the presence 
>of cRLSign bit, and vice versa.

There is some ambiguity in the Englsih language re expressing 
inclusive vs. exclusive OR.  My text was intended to connote the 
former, and it is proper to do so in that fashion, but I agree that 
it is less confusing to include the "BOTH" and avoid any possible 
confusion.  I'll make that change, plus a few others that have been 
submitted privately, and send in the minutes today.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA00926; Tue, 3 Apr 2001 13:00:42 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA13117; Tue, 3 Apr 2001 16:00:43 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040fb6efdaa4d1c0@[128.33.4.39]>
In-Reply-To: <p05100803b6efcacc8177@[165.227.249.20]>
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <p05100802b6e1aad52bbf@[165.227.249.20]> <p0501040bb6efb5d22afc@[128.33.4.39]> <p05100802b6efb8522a2a@[165.227.249.20]> <p0501040eb6efbec745a3@[128.33.4.39]> <p05100803b6efcacc8177@[165.227.249.20]>
Date: Tue, 3 Apr 2001 16:02:30 -0400
To: Paul Hoffman / IMC <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: some thoughts re DPD and DPV
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Paul,

>At 1:57 PM -0400 4/3/01, Stephen Kent wrote:
>>Well, we're not negotiating policy here, in general.
>
>OK, then I misunderstood your proposal.
>
>>  The client, absent serve-mandated overrides, is merely uploading 
>>policy to a server and getting back a policy reference.
>
>That sounds OK, although still more complicated than allowing a 
>client to say the same things directly in a request. It means two 
>protocols instead of one, or one protocol that has two modes: 
>"what's my policy reference?" and "is this cert valid using this 
>policy reference?".

Well, it depends on one's model of operation. If each application 
makes use of one or a few policies all the time, as several folks 
have suggested, then one can configure the OIDs for the appropriate 
policies in the app and have it use them in the request. In that 
case, one could get away without implementing the policy registration 
protocol protocol in the client.  If there are default policies 
mandated by an organization, then even this level of complexity might 
be avoided, if one has a means of signalling which application 
context is being invoked, although this begins to be a lot like the 
trivial case of the preceding mechanism.

>
>>  Or the client is asking the server to tell the client about 
>>server-configured (e.g., default) policies.
>
>This requires that a (supposedly simple) client can parse a huge bag 
>of bags of policies looking for the one it likes best. I believe 
>that this is unlikely to happen in the real world.

I see this as a separate application, a utility, outside of the 
client apps. Here too, one need not provide the facility if the 
client has no choice.

>
>>   Your concerns dont' seem to align with what I have proposed.
>
>My apologies. If what you meant was "there is a mode where a client 
>says what policy it wants to use in future requests and can get a 
>reference/OID for that", I think that's OK, but it doesn't simplify 
>the protocol, it just splits the protocol into two parts. And it 
>requires the client to remember the OID for the desired policy 
>across requests, which is probably feasble but more limiting than 
>allowing the client to just put the policy directly into the request.

You are right that this is cheating, in a way, splitting the protocol 
into two parts. But, if many client would not need to invoke the 
policy management facilities, the clients would not have to implement 
the policy management protocol and thus could be simpler.

>Why not have an optional second protocol for policy-to-OID mapping, 
>and allow either policies or OIDs in the request?

Because allowing policy parameters to be specified in the protocol 
makes the protocol much more complicated, syntactically, and makes it 
harder to extend if one wants to add more controls. The split permits 
policy invocation and policy management to be separated, which may 
generally be appropriate.

Steve


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA27165 for <[e-mail]>; Tue, 3 Apr 2001 12:18:40 -0700 (PDT)
Received: from dlinsenbardtpc ([207.212.34.102]) by mail.spyrus.com (8.9.3/8.9.3) with SMTP id MAA23020 for <[e-mail]>; Tue, 3 Apr 2001 12:18:10 -0700 (PDT)
From: "Duane Linsenbardt" <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Tue, 3 Apr 2001 12:18:45 -0700
Message-ID: <001a01c0bc72$e730e9d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal

subscribe




Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA25668; Tue, 3 Apr 2001 11:54:53 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100803b6efcacc8177@[165.227.249.20]>
In-Reply-To: <p0501040eb6efbec745a3@[128.33.4.39]>
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <p05100802b6e1aad52bbf@[165.227.249.20]> <p0501040bb6efb5d22afc@[128.33.4.39]> <p05100802b6efb8522a2a@[165.227.249.20]> <p0501040eb6efbec745a3@[128.33.4.39]>
Date: Tue, 3 Apr 2001 11:54:46 -0700
To: Stephen Kent <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: some thoughts re DPD and DPV
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 1:57 PM -0400 4/3/01, Stephen Kent wrote:
>Well, we're not negotiating policy here, in general.

OK, then I misunderstood your proposal.

>  The client, absent serve-mandated overrides, is merely uploading 
>policy to a server and getting back a policy reference.

That sounds OK, although still more complicated than allowing a 
client to say the same things directly in a request. It means two 
protocols instead of one, or one protocol that has two modes: "what's 
my policy reference?" and "is this cert valid using this policy 
reference?".

>  Or the client is asking the server to tell the client about 
>server-configured (e.g., default) policies.

This requires that a (supposedly simple) client can parse a huge bag 
of bags of policies looking for the one it likes best. I believe that 
this is unlikely to happen in the real world.

>   Your concerns dont' seem to align with what I have proposed.

My apologies. If what you meant was "there is a mode where a client 
says what policy it wants to use in future requests and can get a 
reference/OID for that", I think that's OK, but it doesn't simplify 
the protocol, it just splits the protocol into two parts. And it 
requires the client to remember the OID for the desired policy across 
requests, which is probably feasble but more limiting than allowing 
the client to just put the policy directly into the request.

Why not have an optional second protocol for policy-to-OID mapping, 
and allow either policies or OIDs in the request?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA24889 for <[e-mail]>; Tue, 3 Apr 2001 11:40:36 -0700 (PDT)
Received: from dlinsenbardtpc ([207.212.34.102]) by mail.spyrus.com (8.9.3/8.9.3) with SMTP id LAA21999 for <[e-mail]>; Tue, 3 Apr 2001 11:40:05 -0700 (PDT)
From: "Duane Linsenbardt" <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Tue, 3 Apr 2001 11:40:40 -0700
Message-ID: <001801c0bc6d$94ec5fb0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal

unsubscribe [e-mail]




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA22387; Tue, 3 Apr 2001 11:00:57 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA24474; Tue, 3 Apr 2001 14:00:58 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040eb6efbec745a3@[128.33.4.39]>
In-Reply-To: <p05100802b6efb8522a2a@[165.227.249.20]>
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <p05100802b6e1aad52bbf@[165.227.249.20]> <p0501040bb6efb5d22afc@[128.33.4.39]> <p05100802b6efb8522a2a@[165.227.249.20]>
Date: Tue, 3 Apr 2001 13:57:09 -0400
To: Paul Hoffman / IMC <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: some thoughts re DPD and DPV
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 10:31 AM -0700 4/3/01, Paul Hoffman / IMC wrote:
>At 1:20 PM -0400 4/3/01, Stephen Kent wrote:
>>I think we are dealing with a very different situation here, 
>>relative to the general policy mess you allude to.
>
>They all say that, often in their charters. :-)
>
>>  The motivation is to make the protocol exchange smaller, and the 
>>DPD/DPV protocols simpler. Don't you think reference to policies in 
>>this fashion achieves these goals?
>
>The first motivation seems spurious. Having policy negotiation does 
>not achieve the second motivation, and in fact fights directly 
>against it. SCVP already has references to policies: server-defined 
>OIDs. It also allows a client and a server to agree to use a bit 
>more bandwidth in passing the request in exchange for the client not 
>needing to know the server's OIDs. Prohibiting this sensible action 
>seems draconian, given that the clients and servers will aready 
>agree to use it. (If a server doesn't agree, it will return an error 
>for any requests other than OID-based ones.)

Well, we're not negotiating policy here, in general. The client, 
absent serve-mandated overrides, is merely uploading policy to a 
server and getting back a policy reference. Or the client is asking 
the server to tell the client about server-configured (e.g., default) 
policies.  Your concerns dont' seem to align with what I have 
proposed.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA21570; Tue, 3 Apr 2001 10:51:14 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA23050; Tue, 3 Apr 2001 13:51:00 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040db6efbc60b534@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 3 Apr 2001 13:44:21 -0400
To: "Carlin Covey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: some thoughts re DPD and DPV
Cc: "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 2:26 PM -0700 3/24/01, Carlin Covey wrote:
>Paul and Steve,
>
>I agree that the DPD and DPV protocols should be simplified by
>including just a reference to a server-resident path-validation
>policy.  I also agree with Paul that a typical client will
>make a choice among very few policies.  In fact, most clients
>will never make a choice.  The clients and servers will be
>pre-configured with one policy per client-type per enterprise. 
>Simply including one policy OID in the request (possibly echoed
>in the response) will satisfy the great majority of use cases. 
>
>Paul points out the near-zero success-rate of policy protocols.
>DPD/DPV should not be made into a quasi-policy-protocol by
>including explicit policy information in the requests.  An OID
>will do.  If there remains a need for client-configuration of
>server-resident policies, put that in a separate protocol as
>Steve has suggested. 
>
>Let's proceed with a simplified, low-bandwidth DPD/DPV that is as
>free as possible of the burden of policy configuration.

I think this is what I was proposing.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA20948 for <[e-mail]>; Tue, 3 Apr 2001 10:41:03 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA21399; Tue, 3 Apr 2001 13:41:01 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040cb6efb6d567dd@[128.33.4.39]>
In-Reply-To: <001001c0b453$62212b00$851efea9@vaio>
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <001001c0b453$62212b00$851efea9@vaio>
Date: Tue, 3 Apr 2001 13:43:12 -0400
To: "Liaquat Khan" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: some thoughts re DPD and DPV
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1225802689==_ma============"

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

At 11:12 AM +0000 3/24/01, Liaquat Khan wrote:
>I'm not against the idea of having a (validation) policy registered 
>on the server, which the client refers to in its request message. 
>However, IMO would it not be more practical for the CA which issued 
>the certificate to be responsible for defining this policy and 
>registering it directly with its validation server?  This may remove 
>some of the complexity of each client having its own policy and a 
>protocol for registering this at the server.    The client would 
>only need to refer to the appropriate policy, which will be based on 
>the target certificate being checked.   Just some initial thoughts...
>
>Regards,
>Liaquat
>
  The validation policy is a matter for the client (RP) to decide 
upon, not the CA that issued the cert being validated.

Steve
--============_-1225802689==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: some thoughts re DPD and
DPV</title></head><body>
<div>At 11:12 AM +0000 3/24/01, Liaquat Khan wrote:</div>
<blockquote type="cite" cite><font face="Arial" size="-1">I'm not
against the idea of having a (validation) policy registered on the
server, which the client refers to in its request message.&nbsp;
However, IMO would it not be more practical for the CA which issued
the certificate to be responsible for defining this policy and
registering it directly with its validation server?&nbsp; This may
remove some of the complexity of each client having&nbsp;its
own&nbsp;policy and a protocol for registering this at the server.&nbsp;
&nbsp;&nbsp;The client would only need to refer to&nbsp;the
appropriate policy, which will be&nbsp;based on the target certificate
being checked.&nbsp;&nbsp; Just some initial
thoughts...</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">Regards,</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">Liaquat</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<div>&nbsp;The validation policy is a matter for the client (RP) to
decide upon, not the CA that issued the cert being validated.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1225802689==_ma============--


Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA19920; Tue, 3 Apr 2001 10:31:40 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100802b6efb8522a2a@[165.227.249.20]>
In-Reply-To: <p0501040bb6efb5d22afc@[128.33.4.39]>
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <p05100802b6e1aad52bbf@[165.227.249.20]> <p0501040bb6efb5d22afc@[128.33.4.39]>
Date: Tue, 3 Apr 2001 10:31:34 -0700
To: Stephen Kent <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: some thoughts re DPD and DPV
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 1:20 PM -0400 4/3/01, Stephen Kent wrote:
>I think we are dealing with a very different situation here, 
>relative to the general policy mess you allude to.

They all say that, often in their charters. :-)

>  The motivation is to make the protocol exchange smaller, and the 
>DPD/DPV protocols simpler. Don't you think reference to policies in 
>this fashion achieves these goals?

The first motivation seems spurious. Having policy negotiation does 
not achieve the second motivation, and in fact fights directly 
against it. SCVP already has references to policies: server-defined 
OIDs. It also allows a client and a server to agree to use a bit more 
bandwidth in passing the request in exchange for the client not 
needing to know the server's OIDs. Prohibiting this sensible action 
seems draconian, given that the clients and servers will aready agree 
to use it. (If a server doesn't agree, it will return an error for 
any requests other than OID-based ones.)

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA18936 for <[e-mail]>; Tue, 3 Apr 2001 10:21:12 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA18350; Tue, 3 Apr 2001 13:21:04 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040ab6efb5540d51@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 3 Apr 2001 13:15:48 -0400
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: some thoughts re DPD and DPV
Cc: "Ietf-Pkix@Imc. Org" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 5:20 PM -0800 3/23/01, Michael Myers wrote:
>Steve,
>
>Speaking from the OCSP perspective, our formulations of OCSPv1 and OCSPv2
>implicitly assumed and continues to assume that policy management between
>relying parties and validating parties is out of scope.  We of the OCSP team
>agree that the parallel development of such protocols is strongly preferred
>vice deltas to OCSPv2.

There is no need for the policy registration/query mechanism to be 
part of the protocol that provides the base DPV/DPD service. My 
question was whether we progress both at the same time, or complete 
the DPD/DPV protocols first, then provide the policy management 
protocol.

>I have no problem with an optional evidentiary hash in a DPV response if
>it's client-precipitated.  As Denis and I had discussed earlier this week,
>some environments may prefer this to the constant reiteration by a server of
>a full chain or other policy indicators (e.g. the full text of a policy
>document).  We will take this as a requirement and study how best to fold
>this requirement into the current OCSPv2 technical framework.
>
>When you refer to "incremental queries relative to the same target
>certificate" are you speaking to the currently proposed retryReference
>mechanism?

yes.


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA18907; Tue, 3 Apr 2001 10:21:07 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA18359; Tue, 3 Apr 2001 13:21:08 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040bb6efb5d22afc@[128.33.4.39]>
In-Reply-To: <p05100802b6e1aad52bbf@[165.227.249.20]>
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <p05100802b6e1aad52bbf@[165.227.249.20]>
Date: Tue, 3 Apr 2001 13:20:11 -0400
To: Paul Hoffman / IMC <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: some thoughts re DPD and DPV
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 5:42 PM -0800 3/23/01, Paul Hoffman / IMC wrote:
>At 7:09 PM -0500 3/23/01, Stephen Kent wrote:
>>We could make ALL requests refer to a policy configured at the 
>>server, rather than allowing for explicit transmission of these 
>>parameters. To make this as flexible as the current proposals, we 
>>would have to add a new protocol, to allow a client to register a 
>>policy with a server, so that the client could later refer to that 
>>policy. We probably want a facility to inquire about a registered 
>>policy as well.
>
>This sounds horrendously complex. To date, the IETF has had 
>near-zero success with defining policy protocols, with policy 
>working groups pretty much being unable to get closure. The method 
>promoted in SCVP (can give individual policy info in requests or can 
>use aggregated OIDs) seems much more sensible than forcing all 
>clients to know (or, worse, discover and push) the policies on the 
>server.

I think we are dealing with a very different situation here, relative 
to the general policy mess you allude to. The set of parameters for 
controlling path validation is better defined, although there are 
some points of disagreement. If we have a policy registration 
protocol, then the user can (subject to local controls) just register 
the few policies he regularly uses, or can retrieve (for review) the 
ones that his company imposes.

>The number of policies a typical client wants will probably be few 
>(most likely, just roots). Why make this so much more complicated 
>than needed?
>
  The motivation is to make the protocol exchange smaller, and the 
DPD/DPV protocols simpler. Don't you think reference to policies in 
this fashion achieves these goals?

Steve


Received: from maild.telia.com (maild.telia.com [194.22.190.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA15054 for <[e-mail]>; Tue, 3 Apr 2001 09:02:58 -0700 (PDT)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maild.telia.com (8.9.3/8.9.3) with ESMTP id SAA26876; Tue, 3 Apr 2001 18:02:57 +0200 (CEST)
Received: from mega (t4o69p112.telia.com [62.20.145.232]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f33G2ua21174; Tue, 3 Apr 2001 18:02:57 +0200 (CEST)
Message-ID: <002501c0bc57$47146730$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> < <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Logotypes in certificates
Date: Tue, 3 Apr 2001 18:00:57 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA15055

> I think though that enough persons, where many of those actually represent 
> significant market players in PKI, has spoken in favour of including 
> logotypes in certificates in some form.

Stefan, welcome to the club!  I.e. the club of mentally disturbed engineers like me
who actually think that market aspects should influence standards!

In the same way as I insist that son-of-2459 should officially support e-mail addresses in the subject
field (which all major CA players use),  you will get nowhere with this issue.  Try PKI-forum.

Anders




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA05100 for <[e-mail]>; Tue, 3 Apr 2001 07:41:30 -0700 (PDT)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA21271; Tue, 3 Apr 2001 10:41:28 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010400b6ef9022503a@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> < <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 3 Apr 2001 10:43:13 -0400
To: Stefan Santesson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Logotypes in certificates
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Stefan,

>Steve,
>
>I have problem to find the time to compile the input you ask for.
>
>I think though that enough persons, where many of those actually 
>represent significant market players in PKI, has spoken in favour of 
>including logotypes in certificates in some form.

In the IETF we make decisions based on technical inputs from 
individuals, not endorsements from company representatives, so the 
motivation you cite here is not persuasive. Also, several folks other 
than I have pointed out potential vulnerabilities of logotype use. I 
think it fair to say that there are pluses and minuses here.

>I would further regard Bob Junemans very relevant input as yet 
>another very good reason for this.

Bob made an argument for the acceptability of the logotype notion 
based on presumed legal redress against a public (TTP) CA. The 
concerns I and others have raised assume a rogue CA  below that 
level. Also, the IETF, in making standards, tends to prefer security 
mechanisms that are proactive and that do not rely on the legal 
system for redress.

>So to me the question is more HOW instead of IF or WHY. Everybody 
>doesn't have to need or want a feature in order to motivate its 
>support in standards. What is important though is that there is a 
>consensus that the choosen solution doesn't break the systems for 
>those who doesn't need or want to use it.

I learned long ago that it's often a bad idea to agree to a concept 
irrespective of a proposed means of achieving it. So, absent a 
concrete proposal for HOW, I don't think we have consensus on WHETHER 
to pursue this work item.  That's why I proposed that you, as the 
prime mover behind the idea, develop a comprehensive proposal for 
what you are trying to achieve and how you propose to achieve it. if 
you can't find the time to do that, then we will not pursue it.


Steve


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA23694 for <[e-mail]>; Tue, 3 Apr 2001 04:53:22 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27333; Tue, 3 Apr 2001 07:53:21 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pi-02.txt
Date: Tue, 03 Apr 2001 07:53:20 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Permanent 
                          Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-02.txt
	Pages		: 9
	Date		: 02-Apr-01
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to a physical person.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pi-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-pi-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pi-02.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA20532 for <[e-mail]>; Tue, 3 Apr 2001 04:14:16 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA34270; Tue, 3 Apr 2001 13:13:23 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id NAA17364; Tue, 3 Apr 2001 13:13:30 +0200
Message-ID: <[e-mail]>
Date: Tue, 03 Apr 2001 13:13:33 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Gary Visser <[e-mail]>
CC: IETF-PKIX <[e-mail]>
Subject: Re: Interpretation of the Timestamp Accuracy
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gary,

> Up until now I have interpreted the accuracy field of a Timestamp Token to
> give an indication as to how accurate the genTime field is in relation to
> the actual time of day GMT. In other words its a statement of how accurate
> the clock is.

It is not a statement of how accurate the clock is.

The text says:

By adding the accuracy value to the GeneralizedTime, an upper limit 
of the time at which the timestamp has been created by the TSA can 
be obtained. In the same way, by subtracting the accuracy to the 
GeneralizedTime, a lower limit of the time at which the timestamp 
has been created by the TSA can be obtained.

> But there is another interpretation, the accuracy is an indication of how
> timely the timestamp was created. In other words the accuracy states that
> the Timestamp Token was generated within the time span allowed by the
> accuracy and not necessarily at the exact time state in the genTime field.

This is along the lines of the right interpretation.

Regards,

Denis

> For example: if GMT is 13:00:00, the clock of the TSA is 13:01:00, the
> genTime of a timestamp token from this TSA is 13:01:00 and the accuracy is 1
> second, then the token may have been created between 12:59:59 GMT and
> 13:00:01 GMT. 
> There are some other subtlety different interpretations: the
> difference in time between when the Timestamp Request was received and when
> the Token was issued, the difference in time between when the Request was
> validated and when the Token was created, or the difference in time between
> the genTime and when the actual timestamp Signature was generated, and so
> on.
> 
> So I have either overlooked something or there may be an ambiguity in the
> draft.
> 
> Sincerely,
> Gary Visser
> Timestamp.com


Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id VAA05980 for <[e-mail]>; Mon, 2 Apr 2001 21:18:33 -0700 (PDT)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Apr 2001 19:48:55 -0700 (Pacific Daylight Time)
Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 2 Apr 2001 20:48:56 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: search for PKCS10 extension
Date: Mon, 2 Apr 2001 20:48:55 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: search for PKCS10 extension
Thread-Index: AcC7YJDNQt1JpzEVSJqBYA3qOig0qAAj8f6A
From: "David Cross" <[e-mail]>
To: "Santoni Adriano" <[e-mail]>, "Martin Szotkowski" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 03 Apr 2001 03:48:56.0072 (UTC) FILETIME=[01F50080:01C0BBF1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id VAA05981

This is a sample dump from a PKCS#10 request generated by a Microsoft
client using rhe xenroll.dll control, sorry I don't have a specification
for you.  Here is the items you mentioned:

Attribute[2]: 1.3.6.1.4.1.311.13.2.2 (Enrollment CSP)
    Value[2][0]:
    Unknown Attribute type
    CSP Provider Info
    KeySpec = 1
    Provider = Microsoft Base Cryptographic Provider v1.0 

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

PKCS10 Certificate Request:
Version: 1
Subject:
    CN=test

Public Key Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.1  RSA
    Algorithm Parameters:
    05 00                                              ..
Public Key Length: 512 bits
Public Key: UnusedBits = 0
    0000  30 48 02 41 00 e2 c2 87  55 c1 14 1e 83 fe e0 86
    0010  c4 81 30 de 29 20 47 01  a3 5d 10 f0 cf 9f d4 57
    0020  58 40 2b 4a 05 22 83 65  65 7a a1 c1 e1 a7 94 37
    0030  df 7d 08 7d 46 50 f7 73  54 62 14 21 1f 5d 76 93
    0040  fe 32 97 61 e1 02 03 01  00 01
Request Attributes: 3
  3 attributes:

  Attribute[0]: 1.3.6.1.4.1.311.13.2.3 (OS Version)
    Value[0][0]:
        5.1.2462.2

  Attribute[1]: 1.2.840.113549.1.9.14 (Certificate Extensions)
    Value[1][0]:
    Unknown Attribute type
Certificate Extensions: 3
    2.5.29.15: Flags = 1(Critical), Length = 4
    Key Usage
        Digital Signature, Non-Repudiation, Key Encipherment, Data
Encipherment (f0)

    1.2.840.113549.1.9.15: Flags = 0, Length = 29
    SMIME Capabilities
        [1]SMIME Capability
             Object ID=1.2.840.113549.3.2
             Parameters=02 01 38
        [2]SMIME Capability
             Object ID=1.2.840.113549.3.4
             Parameters=02 01 38
        [3]SMIME Capability
             Object ID=1.3.14.3.2.7

    2.5.29.37: Flags = 0, Length = c
    Enhanced Key Usage
        Client Authentication (1.3.6.1.5.5.7.3.2)


  Attribute[2]: 1.3.6.1.4.1.311.13.2.2 (Enrollment CSP)
    Value[2][0]:
    Unknown Attribute type
    CSP Provider Info
    KeySpec = 1
    Provider = Microsoft Base Cryptographic Provider v1.0
    Signature: UnusedBits=0
    0000  27 21 0f 8f 03 85 29 c9  f9 74 c9 d5 76 71 99 df
    0010  0f 68 24 f8 5b 18 62 2a  49 85 e1 fa 8f dd ef 13
    0020  89 f9 a1 52 17 3e ee 7d  04 9f 71 72 ff 81 d7 75
    0030  5b f6 be f4 38 e1 0d 7a  f2 d5 b2 95 93 9a 98 1d
    0040  6a 75 6b b0 3c 9d 14 2e  cf 0f 96 eb a8 24 01 99
    0050  ee 53 78 4f f3 07 7a 10  bd f4 d8 e6 b8 67 58 4a
    0060  b1 cd bf f6 0a 60 8d 07  73 5c 28 b3 f2 4d c5 f6
    0070  5a 83 10 8f 65 36 c3 d6  30 16 96 2c 3d 61 e8 62
    0080  00 00 00 00 00 00 00 00
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.5  sha1RSA
    Algorithm Parameters:
    05 00                                              ..
Signature: UnusedBits=0
    0000  1b 6b 5c c0 61 6d 7e a0  e5 25 7a 6f 5c 14 90 d9
    0010  d4 77 d3 df 57 ea 19 57  6f ff 89 e5 df 23 8e 86
    0020  be de 34 11 6b cb ee e1  12 53 23 4c 77 5d 6a a8
    0030  00 4f 6f f6 a8 78 d5 d2  1d 3c 38 b8 53 19 6e 3c
Signature matches Public Key
Key Id Hash(sha1): 2d 5a 38 04 29 43 fb cf 50 68 76 b7 56 62 8c ad 12 08
29 ab
CertUtil: -dump command completed successfully.



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

Hope this helps,
 
David B. Cross

 



-----Original Message-----
From: Santoni Adriano [mailto:[e-mail]] 
Sent: Monday, April 02, 2001 3:30 AM
To: 'Martin Szotkowski'
Cc: [e-mail]
Subject: R: search for PKCS10 extension


Martin,

Afaik, there is no "standard" extension to do that. However, Microsoft
defined their own proprietary extension for exactly this purpose, and
that extension usually gets added to the PKCS#10 request if this is
generated via their XENROLL control. The extension has an OID of {1 3 6
1 4 1 311 13 2 2} (aka ???) and identifies a SEQUENCE of 3 items, one of
which is or contains the Unicode name of the CSP used to generate the
keypair.

Btw, it might be interesting to find out what is the inner structure of
this rather obscure Microsoft extension. I'va not been able to find any
mention of it on Microsoft websites.

Adriano

-----Messaggio originale-----
Da: Martin Szotkowski [mailto:[e-mail]]
Inviato: venerdì 30 marzo 2001 9.17
A: [e-mail]
Oggetto: search for PKCS10 extension


I will add into PKCS10 request information about source of private key,
but I don't know if some extension exist or if I must create own.

I search for cases:
1. This information will be CSP Name who generate request
2. This information will be SHA1 over the Secret data on hardware token

thanks Martin




Received: from wildpackets.com (wildpackets.com [192.216.124.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA25862 for <[e-mail]>; Mon, 2 Apr 2001 15:40:19 -0700 (PDT)
Received: from GARYNOTEBOOK (c939355-a.plstn1.sfba.home.com [24.20.160.126]) by wildpackets.com (8.11.1/8.10.1) with SMTP id f32MZb710395 for <[e-mail]>; Mon, 2 Apr 2001 15:35:37 -0700 (PDT)
From: "Gary Visser" <[e-mail]>
To: "IETF-PKIX" <[e-mail]>
Subject: Interpretation of the Timestamp Accuracy
Date: Mon, 2 Apr 2001 15:40:12 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Up until now I have interpreted the accuracy field of a Timestamp Token to
give an indication as to how accurate the genTime field is in relation to
the actual time of day GMT. In other words its a statement of how accurate
the clock is.

But there is another interpretation, the accuracy is an indication of how
timely the timestamp was created. In other words the accuracy states that
the Timestamp Token was generated within the time span allowed by the
accuracy and not necessarily at the exact time state in the genTime field.
For example: if GMT is 13:00:00, the clock of the TSA is 13:01:00, the
genTime of a timestamp token from this TSA is 13:01:00 and the accuracy is 1
second, then the token may have been created between 12:59:59 GMT and
13:00:01 GMT. There are some other subtlety different interpretations: the
difference in time between when the Timestamp Request was received and when
the Token was issued, the difference in time between when the Request was
validated and when the Token was created, or the difference in time between
the genTime and when the actual timestamp Signature was generated, and so
on.

So I have either overlooked something or there may be an ambiguity in the
draft.


Sincerely,
Gary Visser
Timestamp.com



Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA24709 for <[e-mail]>; Mon, 2 Apr 2001 15:20:25 -0700 (PDT)
From: [e-mail]
Received: from webmail.worldnet.att.net ([204.127.135.42]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Mon, 2 Apr 2001 22:19:52 +0000
Received: from [12.81.78.211] by webmail.worldnet.att.net; Mon, 02 Apr 2001 22:19:52 +0000
To: Stefan Santesson <[e-mail]>
Cc: [e-mail]
Subject: RE: Logotypes in certificates
Date: Mon, 02 Apr 2001 22:19:52 +0000
X-Mailer: AT&T Message Center Version 1 (Mar 27 2001)
Message-Id: <[e-mail]>

--
Regards,
Todd
> Steve,
> 
> I have problem to find the time to compile the input you ask for.
> 
> I think though that enough persons, where many of those actually represent 
> significant market players in PKI, 

You mean people that provide PKI solutions, not people that use them. This 
is a key differentiation, (pardon the pun) since I have yet to hear
anyone who would be using LogoTypes say what and how they would 
use them for.

> has spoken in favour of including 
> logotypes in certificates in some form.
> 
> I would further regard Bob Junemans very relevant input as yet another very 
> good reason for this.
> 
> So to me the question is more HOW instead of IF or WHY. Everybody doesn't 
> have to need or want a feature in order to motivate its support in 
> standards. 

here again. Is this feature for the users of the system or
for you as a technologist?


> What is important though is that there is a consensus that the 
> choosen solution doesn't break 

Impugn the QoS, or increase the overhead of

> the systems for those who don't need or 
> want to use it.
> 
> I agree with those who consider inclusion of logotypes in policy qualifiers 
> as a primitive hack, but I also see the good sides of this and right now I 
> agree with Russ that this is probably the best way to do it in order to 
> avoid the problems you address.

I see it differently. I see it as a way to complicate an
already very complex process. Once again more and more of the use model seems to 
be sneaking from the Application into the core protocol, making
creeping featureism an everyday word it seems.
> 
> If policy qualifiers would be deprecated, then I'm open for suggestions. I 
> don't care that much about HOW as long as this important need gets addressed.
> 
> /Stefan
> 
> 
> At 10:11 2001-03-23 -0500, Stephen Kent wrote:
> >Stefan,
> >
> >>Steve,
> >>
> >>There was a suggestion during a dinner yesterday that logotypes actually 
> >>could be provided as a policy qualifier. That would actually solve your 
> >>problem since you could directly tie acceptance of logotypes in 
> >>certificates to a particular policy.
> >>
> >>This enables you to control the path validation problem with the use of 
> >>policy constraints.
> >
> >I'd be comfortable with that approach, except that we have discouraged use 
> >of policy qualifiers, as Russ noted.
> >
> >Let me suggest again that you send another message that includes a 
> >comprehensive rationale for inclusion of logotypes, indicating what types 
> >of certs would be allowed to contain them, what reference form you 
> >envision, and what controls you think should be employed to prevent the 
> >sorts of misuse I warned about.  With a concrete proposal, and well 
> >articulated rationale on the table, I think we have a better chance of 
> >making progress.
> >
> >Steve
> 


Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA19227 for <[e-mail]>; Mon, 2 Apr 2001 14:27:38 -0700 (PDT)
Received: from santesson.addtrust.com ([62.20.231.166]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 2 Apr 2001 23:26:47 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 02 Apr 2001 23:28:03 +0200
To: Stephen Kent <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Logotypes in certificates
Cc: [e-mail]
In-Reply-To: <p05010408b6e11769eb54@[128.33.4.39]>
References: <[e-mail]> < <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 02 Apr 2001 21:26:47.0796 (UTC) FILETIME=[9FA3BB40:01C0BBBB]

Steve,

I have problem to find the time to compile the input you ask for.

I think though that enough persons, where many of those actually represent 
significant market players in PKI, has spoken in favour of including 
logotypes in certificates in some form.

I would further regard Bob Junemans very relevant input as yet another very 
good reason for this.

So to me the question is more HOW instead of IF or WHY. Everybody doesn't 
have to need or want a feature in order to motivate its support in 
standards. What is important though is that there is a consensus that the 
choosen solution doesn't break the systems for those who doesn't need or 
want to use it.

I agree with those who consider inclusion of logotypes in policy qualifiers 
as a primitive hack, but I also see the good sides of this and right now I 
agree with Russ that this is probably the best way to do it in order to 
avoid the problems you address.

If policy qualifiers would be deprecated, then I'm open for suggestions. I 
don't care that much about HOW as long as this important need gets addressed.

/Stefan


At 10:11 2001-03-23 -0500, Stephen Kent wrote:
>Stefan,
>
>>Steve,
>>
>>There was a suggestion during a dinner yesterday that logotypes actually 
>>could be provided as a policy qualifier. That would actually solve your 
>>problem since you could directly tie acceptance of logotypes in 
>>certificates to a particular policy.
>>
>>This enables you to control the path validation problem with the use of 
>>policy constraints.
>
>I'd be comfortable with that approach, except that we have discouraged use 
>of policy qualifiers, as Russ noted.
>
>Let me suggest again that you send another message that includes a 
>comprehensive rationale for inclusion of logotypes, indicating what types 
>of certs would be allowed to contain them, what reference form you 
>envision, and what controls you think should be employed to prevent the 
>sorts of misuse I warned about.  With a concrete proposal, and well 
>articulated rationale on the table, I think we have a better chance of 
>making progress.
>
>Steve



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA05019 for <[e-mail]>; Mon, 2 Apr 2001 11:05:28 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id GAA29400; Tue, 3 Apr 2001 06:05:28 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98623472812726>; Tue, 3 Apr 2001 06:05:28 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  OCSPv2 certHash option will be deleted
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 3 Apr 2001 06:05:28 (NZST)
Message-ID: <[e-mail]>

"Michael Myers" <[e-mail]> writes:

>We're going to take the certHash option out of ReqCert for the -03 rev. Anyone
>who cares for it, now's the time to speak up.

Well just for form's sake I'll have to register some dissatisfaction with this,
but given the issues which James Manger raised I guess it can't be salvaged.

One thing I would like to see included (and others have raised this issue in
the past) is that a responder MUST return a response identified in the same way
as the request (ie if the client sends in an issuerSerial, you can't come back
with a pKCert or certID).  I suspect everyone will do this automatically
anyway, but it'd be better to have it made explicit so we can beat the authors
of any new implementations with soggy weetbix if they decide to rewrite the IDs
in the response.

Peter.




Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA03269 for <[e-mail]>; Mon, 2 Apr 2001 10:35:28 -0700 (PDT)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f32HZPO10876 for <[e-mail]>; Mon, 2 Apr 2001 10:35:25 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: OCSPv2 certHash option will be deleted
Date: Mon, 2 Apr 2001 10:42:26 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

All,

We're going to take the certHash option out of ReqCert for the -03 rev.
Anyone who cares for it, now's the time to speak up.

Mike



Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA08148 for <[e-mail]>; Mon, 2 Apr 2001 04:55:19 -0700 (PDT)
Received: from cooper.entegrity.com (dave.entegrity.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GFRD0YSL; Mon, 2 Apr 2001 04:54:57 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 02 Apr 2001 13:51:58 +0200
To: "Stephen Kent" <[e-mail]>, [e-mail]
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: Re: draft meeting minutes, please comment
In-Reply-To: <p05010400b6de6e8bbcdf@[128.33.238.79]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

>...

Hi Steve,

Just one quick comment:

>Status of RFC 2459bis- Russ Housley (RSA Labs)
>         Fixed path length computation. Fix "who can issue CRLs" problem 
> by allowing a CA certificate to contain EITHER the KeyCertSign OR cRLSign 
> bits.

My understanding of the explanation was "a certificate with either 
keyCertSign bit on, or cRLSign bit on, or BOTH". The above sentence implies 
that the presence of keyCertSign bit excludes the presence of cRLSign bit, 
and vice versa.


Nada

...




Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA02000 for <[e-mail]>; Mon, 2 Apr 2001 03:31:00 -0700 (PDT)
Received: by ntsiaexch.office with Internet Mail Service (5.5.2653.19) id <2DPH0ARK>; Mon, 2 Apr 2001 12:30:30 +0200
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: "'Martin Szotkowski'" <[e-mail]>
Cc: [e-mail]
Subject: R: search for PKCS10 extension
Date: Mon, 2 Apr 2001 12:30:27 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id DAA02001

Martin,

Afaik, there is no "standard" extension to do that. However, Microsoft
defined their own proprietary extension for exactly this purpose, and that
extension usually gets added to the PKCS#10 request if this is generated via
their XENROLL control. The extension has an OID of {1 3 6 1 4 1 311 13 2 2}
(aka ???) and identifies a SEQUENCE of 3 items, one of which is or contains
the Unicode name of the CSP used to generate the keypair.

Btw, it might be interesting to find out what is the inner structure of this
rather obscure Microsoft extension. I'va not been able to find any mention
of it on Microsoft websites.

Adriano

-----Messaggio originale-----
Da: Martin Szotkowski [mailto:[e-mail]]
Inviato: venerdì 30 marzo 2001 9.17
A: [e-mail]
Oggetto: search for PKCS10 extension


I will add into PKCS10 request information about source of private key, but
I don't know if some extension exist or if I must create own.

I search for cases:
1. This information will be CSP Name who generate request
2. This information will be SHA1 over the Secret data on hardware token

thanks Martin



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

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




Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA10792 for <[e-mail]>; Sun, 1 Apr 2001 21:43:38 -0700 (PDT)
Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id NAA28166 for <[e-mail]>; Mon, 2 Apr 2001 13:43:36 +0900 (JST) (envelope-from [e-mail])
Received: from dsa.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/21/01) with ESMTP id NAA20412 for <[e-mail]>; Mon, 2 Apr 2001 13:43:34 +0900 (JST) (envelope-from [e-mail])
Received: from cats by dsa.isl.ntt.co.jp (8.9.3/isl-2.0) id NAA22901; Mon, 2 Apr 2001 13:43:33 +0900 (JST)
Date: Mon, 02 Apr 2001 13:45:14 +0900
From: Hideyuki Odahara <[e-mail]>
To: [e-mail]
Subject: a protocols of handling ACs
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03

Please teach me the way of handling ACs.

I concerned with handle of ACs (Attribute Certificates).
A few month ago, I could find LAAP on PKIX-homepage.
But now,it disappeared.
(http://www.imc.org/draft-ietf-pkix-laap).
Do you propose not to need protocols of handling ACs?

If you know protocols of handling ACs, would you teach me the following;
1)RFC or Internet-Draft to take place the LAAP
2)RFC or Internet-Draft to handle ACs
   for example,Issuing AC, Acquisition AC, Revoking AC, 
   Verifying AC, e.t.c.


----------
  Hideyuki Odahara $B!'(B [e-mail]



Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA10388 for <[e-mail]>; Sun, 1 Apr 2001 21:33:22 -0700 (PDT)
Received: from asn-1.com (user-2ivf262.dialup.mindspring.com [165.247.136.194]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id AAA09774 for <[e-mail]>; Mon, 2 Apr 2001 00:33:24 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sun, 01 Apr 2001 23:34:28 -0500
From: "Phillip H. Griffin" <[e-mail]>
Reply-To: [e-mail]
Organization: Griffin Consulting 
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Potential Security Risk in Qualified Certificate images?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If you are interested in the secure biometrics
(techniques for digital signatures and encryption) 
you may want to have a look at "X9.84 Biometric
Information Management and Security". This standard
was recently approved by ASC X9 for use in the 
financial services industry. It is very flexible 
and well thought out.

X9.84 defines the requirements needed to manage,
secure, and audit biometric information for customer 
identification and employee verification. It was 
developed in conjunction with the BioAPI Consortium,
the NIST Information Technology Laboratory's Common 
Biometric Exchange File Format (CBEFF) initiative, 
and the International Biometric Industry Association
(IBIA). 

X9.84 provides a solid set of guidelines for the
secure implementation of biometrics within financial
transaction environments, and is well suited for use
by other industry sectors as well.

The IBIA serves as the registrar for new biometric 
types, matching methods, processing algorithms and 
vendor specific formats that will be allocated under
an X9 defined OID arc that the IBIA will manage. See
http://www.ibia.org/formats.htm.

There is a lot more going in this effort than just
pictures and written signatures. The current set of 
biometric types defined for use in X9.84 secure 
messages in the financial services industry are:

BiometricTypes BIOMETRIC ::= {
   { BIOMETRIC id : body-Odor          } |
   { BIOMETRIC id : dna                } |
   { BIOMETRIC id : ear-Shape          } | 
   { BIOMETRIC id : facial-Features    } | 
   { BIOMETRIC id : finger-Image       } |
   { BIOMETRIC id : finger-Geometry    } |
   { BIOMETRIC id : hand-Geometry      } |
   { BIOMETRIC id : iris-Features      } |
   { BIOMETRIC id : keystroke-Dynamics } |
   { BIOMETRIC id : palm               } |
   { BIOMETRIC id : retina             } |
   { BIOMETRIC id : signature          } |
   { BIOMETRIC id : speech-Pattern     } |
   { BIOMETRIC id : thermal-Image      } |
   { BIOMETRIC id : vein-Pattern       },

   ... -- expect additional biometric types --
}

A CMS module is defined in X9.84 based on X9.73,
which is closely aligned with the work in SMIME,
but which extends the IETF effort. So the familiar
cryptographic types, SignedData, EnvelopedData, and
AuthenticatedData are used in X9.84 for security. 

And the x9.84 OID 

x9-84 OBJECT IDENTIFIER ::= {
   iso(1) identified-organization(3) tc68(133) 
      country(16) x9(840) x9Standards(9) x9-84(84) }

can be paired in any of the certificate formats defined
in X9.84 and X9.73 (X.509 identity certificates and 
AttributeCertificates, X9.68 Domain certificates, and
any other formats that may arise, such as WTLS and XML)
to carry a value of 

BiometricSyntax ::= CHOICE {
   biometricObject            BiometricObject, -- unprotected
   integrityObject            IntegrityObject,
    privacyObject             PrivacyObject,
   privacyAndIntegrityObject  PrivacyAndIntegrityObject
}

to allow applications that need to do so, to deal 
with privacy concerns, and to also support those
applications that have no such concerns. A very
flexible design.

You can find out more about this new standard at
http://www.x9.org. I believe that the work is now 
in a period of public review for those who would
like to comment. X9.84 has also been proposed as
a NWI for international standardization in ISO
TC 68.

Phil
----
Phillip H. Griffin    Griffin Consulting
http://asn-1.com      Secure ASN.1 Design & Implementation
p:  [phone]   1625 Glenwood Avenue
f:  [phone]   Hayes Barton at Five Points
e:  [e-mail]    Raleigh, North Carolina 27608-2319 USA
------------------------------------------------------------


Dean Povey wrote:
> 
> Hi all,
> 
> I have just being perusing RFC3039 (Qualified Certificates Profile) with
> a view to coming up with a more concrete proposal for logotypes in
> certificates.
> 
> RFC3039 uses the following syntax to represent an image of the subject in
> its biometricInfo Extension.
> 
>       biometricInfo  EXTENSION ::= {
>           SYNTAX             BiometricSyntax
>           IDENTIFIED BY      id-pe-biometricInfo }
> 
>       id-pe-biometricInfo OBJECT IDENTIFIER  ::= {id-pe 2}
> 
>       BiometricSyntax ::= SEQUENCE OF BiometricData
> 
>       BiometricData ::= SEQUENCE {
>           typeOfBiometricData  TypeOfBiometricData,
>           hashAlgorithm        AlgorithmIdentifier,
>           biometricDataHash    OCTET STRING,
>           sourceDataUri        IA5String OPTIONAL }
> 
>       TypeOfBiometricData ::= CHOICE {
>           predefinedBiometricType    PredefinedBiometricType,
>           biometricDataID            OBJECT IDENTIFIER }
> 
>       PredefinedBiometricType ::= INTEGER { picture(0),
>           handwritten-signature(1)} (picture|handwritten-signature,...)
> 
> Specifically it states:
> 
>    The predefined biometric type picture, when present, SHALL identify
>    that the source picture is in the form of a displayable graphical
>    image of the subject.  The hash of the graphical image SHALL only be
>    calculated over the image data excluding any labels defining the
>    image type.
> 
> i.e. The image type is not part of the digest and is therefore not
> authenticated.  This leads to a potential risk where the CA signs an image
> after viewing it one format, but it is presented to the user in a different
> format.  It is an open question whether it would be possible to produce
> a single binary data file crafted such that it would appear as a plausibly
> different image to both the CA and the user when presented in different
> formats. However, I think we would have to concede that it is possible.
> 
> It gets worse.  Even if the image type is included in the certificate many
> modern image formats have different options for how they are displayed.
> For example, I seem to recall that animated gifs on old browsers would just
> display the first image rather than the whole animated sequence.  It may be
> possible to fool a CA into signing an animated gif, where an initial image
> is shown for an imperceptibly brief time, before showing the final image.
> The user with the old browser then sees just the initial image.
> 
> There may well be many other ways of attacking specific formats.
> 
> Can anyone come up with a solution to this?  I can think of three
> less than perfect alternatives:
> 
> 1. The risk could be avoided by requiring the CA to always generate the image
>    from an analog source rather than certifying a digital image, but this
>    obviously makes such a scheme less flexible.
> 
> 2. Another approach might be to recommend a profile for common
>    image types and their options outlining which are appropriate for use.
>    The main disadvantage of this, is that these image types will evolve
>    over time, meaning they will need continual updating.  Another
>    disadvantage is that it may be very difficult for a CA to verify what
>    particular combination of options are being used in a particular
>    image they are being presented.
> 
> 3. A third approach might be that the CA and end-user must use the same
>    software/hardware to view the image.  However, in an environment with
>    many versions this would quickly become unworkable.
> 
> Are there any views on this?
> 
> Cheers.
> 
> --
> Dean Povey,         | e-m: [e-mail] | JCSI:  Java Crypto Toolkit
> Research Scientist  | ph:  [phone]   | uPKI:  C PKI toolkit for embedded
> Security Unit, DSTC | fax: [phone]   |        systems
> Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit


Received: from thunder.dstc.qut.edu.au (thunder.dstc.qut.edu.au [131.181.71.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA08332 for <[e-mail]>; Sun, 1 Apr 2001 20:12:51 -0700 (PDT)
Received: from dstc.qut.edu.au (garnet.dstc.qut.edu.au [131.181.71.36]) by thunder.dstc.qut.edu.au (8.10.1/8.10.1) with ESMTP id f323Com01048 for <[e-mail]>; Mon, 2 Apr 2001 13:12:50 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: [e-mail]
Subject: Potential Security Risk in Qualified Certificate images?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 02 Apr 2001 13:12:50 +1000
From: Dean Povey <[e-mail]>

Hi all,

I have just being perusing RFC3039 (Qualified Certificates Profile) with
a view to coming up with a more concrete proposal for logotypes in 
certificates.

RFC3039 uses the following syntax to represent an image of the subject in 
its biometricInfo Extension.

      biometricInfo  EXTENSION ::= {
          SYNTAX             BiometricSyntax
          IDENTIFIED BY      id-pe-biometricInfo }

      id-pe-biometricInfo OBJECT IDENTIFIER  ::= {id-pe 2}

      BiometricSyntax ::= SEQUENCE OF BiometricData

      BiometricData ::= SEQUENCE {
          typeOfBiometricData  TypeOfBiometricData,
          hashAlgorithm        AlgorithmIdentifier,
          biometricDataHash    OCTET STRING,
          sourceDataUri        IA5String OPTIONAL }

      TypeOfBiometricData ::= CHOICE {
          predefinedBiometricType    PredefinedBiometricType,
          biometricDataID            OBJECT IDENTIFIER }

      PredefinedBiometricType ::= INTEGER { picture(0),
          handwritten-signature(1)} (picture|handwritten-signature,...)


Specifically it states: 

   The predefined biometric type picture, when present, SHALL identify
   that the source picture is in the form of a displayable graphical
   image of the subject.  The hash of the graphical image SHALL only be
   calculated over the image data excluding any labels defining the
   image type.

i.e. The image type is not part of the digest and is therefore not 
authenticated.  This leads to a potential risk where the CA signs an image 
after viewing it one format, but it is presented to the user in a different
format.  It is an open question whether it would be possible to produce
a single binary data file crafted such that it would appear as a plausibly
different image to both the CA and the user when presented in different 
formats. However, I think we would have to concede that it is possible.

It gets worse.  Even if the image type is included in the certificate many 
modern image formats have different options for how they are displayed.  
For example, I seem to recall that animated gifs on old browsers would just
display the first image rather than the whole animated sequence.  It may be
possible to fool a CA into signing an animated gif, where an initial image 
is shown for an imperceptibly brief time, before showing the final image.  
The user with the old browser then sees just the initial image.  

There may well be many other ways of attacking specific formats.

Can anyone come up with a solution to this?  I can think of three 
less than perfect alternatives:

1. The risk could be avoided by requiring the CA to always generate the image 
   from an analog source rather than certifying a digital image, but this
   obviously makes such a scheme less flexible.  

2. Another approach might be to recommend a profile for common
   image types and their options outlining which are appropriate for use.
   The main disadvantage of this, is that these image types will evolve 
   over time, meaning they will need continual updating.  Another 
   disadvantage is that it may be very difficult for a CA to verify what
   particular combination of options are being used in a particular
   image they are being presented.

3. A third approach might be that the CA and end-user must use the same 
   software/hardware to view the image.  However, in an environment with
   many versions this would quickly become unworkable.

Are there any views on this?

Cheers.

-- 
Dean Povey,         | e-m: [e-mail] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  [phone]   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: [phone]   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 




Received: from server.village.com.ar (host069098.arnet.net.ar [200.45.69.98]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA04721 for <[e-mail]>; Sun, 1 Apr 2001 16:11:32 -0700 (PDT)
From: [e-mail]
Received: from 44mexi7server42 ([127.0.0.1]) by server.village.com.ar (8.9.3/8.9.3) with SMTP id UAA18150 for [e-mail]; Sun, 1 Apr 2001 20:26:29 -0400
Date: Sun, 1 Apr 2001 20:26:29 -0400
Message-Id: <[e-mail]>
To: <[e-mail]>
Subject: ADV: Top Search Engine Rankings
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit

Removal instructions below.

I saw your listing on the internet.

I work for a company that specializes
in getting clients web sites listed
as close to the top of the major
search engines as possible.

Our fee is only $29.95 per month to
submit your site at least twice a
month to over 350 search engines
and directories.

To get started and put your web site
in the fast lane, call our toll free
number below.


Mike Bender
888-532-8842


To be removed call: 888-800-6339 X1377