Re: Questions on Authority/Subject Key Identifiers

["Tom Gindin" <[e-mail]>]

      Peter:

      GIven the arbitrary nature of KID's, why is SKID/AKID chaining in the
absence of DN matches even a sensible thing to do?  If everybody used
method 1 in RFC 3280 section 4.2.1.2 (or maybe even method 2, since 2**60
is far beyond the square of the number of CA's in the world), it would be.
However, the comment about "unique values" doesn't seem to have enough
teeth to avoid collisions, and the "monotonically increasing sequence of
integers" technique which is explicitly considered reasonable by RFC's 2459
and 3280 makes collisions between different issuers fairly likely.  X.509
just says they have to be unique in an issuer's space.

            Tom Gindin

[e-mail] (Peter Gutmann)@mail.imc.org on 09/29/2002
01:52:22 AM

Sent by:    [e-mail]


To:    [e-mail], [e-mail]
cc:    [e-mail]
Subject:    Re: Questions on Authority/Subject Key Identifiers



Stephen Kent <[e-mail]> writes:

>The real world issue you describe calls for re-issuance of certs; it does
not
>justify violating the standards.

In *theory* it calls for the re-issuance of certs.  I can quite easily see
that the practical approach would be to chain by sKID, and obviously enough
people agree with this that they persuaded MS to change the behaviour of
their
code to allow it (the issue you're referring to was a bug, not a deliberate
design decision like sKID chaining).

Peter.








Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8TEMVP12171 for ietf-pkix-bks; Sun, 29 Sep 2002 07:22:31 -0700 (PDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8TEMTv12166 for <[e-mail]>; Sun, 29 Sep 2002 07:22:29 -0700 (PDT)
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8TEMCVL122254; Sun, 29 Sep 2002 10:22:13 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8TEMAkx167766; Sun, 29 Sep 2002 10:22:10 -0400
Importance: Normal
Sensitivity: 
Subject: Re: Questions on Authority/Subject Key Identifiers
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Sun, 29 Sep 2002 10:21:59 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11  |July 29, 2002) at 09/29/2002 10:22:11 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [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>

      Peter:

      GIven the arbitrary nature of KID's, why is SKID/AKID chaining in the
absence of DN matches even a sensible thing to do?  If everybody used
method 1 in RFC 3280 section 4.2.1.2 (or maybe even method 2, since 2**60
is far beyond the square of the number of CA's in the world), it would be.
However, the comment about "unique values" doesn't seem to have enough
teeth to avoid collisions, and the "monotonically increasing sequence of
integers" technique which is explicitly considered reasonable by RFC's 2459
and 3280 makes collisions between different issuers fairly likely.  X.509
just says they have to be unique in an issuer's space.

            Tom Gindin

[e-mail] (Peter Gutmann)@mail.imc.org on 09/29/2002
01:52:22 AM

Sent by:    [e-mail]


To:    [e-mail], [e-mail]
cc:    [e-mail]
Subject:    Re: Questions on Authority/Subject Key Identifiers



Stephen Kent <[e-mail]> writes:

>The real world issue you describe calls for re-issuance of certs; it does
not
>justify violating the standards.

In *theory* it calls for the re-issuance of certs.  I can quite easily see
that the practical approach would be to chain by sKID, and obviously enough
people agree with this that they persuaded MS to change the behaviour of
their
code to allow it (the issue you're referring to was a bug, not a deliberate
design decision like sKID chaining).

Peter.







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8T8Qnb15799 for ietf-pkix-bks; Sun, 29 Sep 2002 01:26:49 -0700 (PDT)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8T8Qmv15795 for <[e-mail]>; Sun, 29 Sep 2002 01:26:48 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maile.telia.com (8.12.5/8.12.5) with SMTP id g8T8QkFx020330 for <[e-mail]>; Sun, 29 Sep 2002 10:26:46 +0200 (CEST)
X-Original-Recipient: <[e-mail]>
Message-ID: <001901c26791$025c7dd0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-usergroup-01.txt
Date: Sun, 29 Sep 2002 10:20:02 +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
Sender: [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>

This is indeed an interesting topic...

Essentially there are two ways to make certificates more adapted
to their working environment:

1. Clobber certificates with more "stuff" to as the draft suggests

2. Use a mapping facility that maps a certificate into whatever
    is needed by the working environment

A major advantage with mapping is that you can use TTP-issued
certificates (a.k.a. 100% outsourced PKI), and that the very same
certificates can be used by multiple relying parties in many different
environments.

A major disadvantage with mapping is that Microsoft and probably
most others as well, do not yet support this fundamental capability
except to a very limited extent.  Contributing to that, is the fact that
current PKI-standards do not offer the kind of manageble mapping
support needed for efficient usage of TTP-issued certificates.

If Microsoft and others are to upgrade their PKI support
(which both solutions require), I really hope that they settle
for a mapping solution.

cheers,
Anders

========================================================
    Entities, here denoting individuals and organizations, using the Internet
    for handling sensitive information or performing critical transactions,
    need simple, low-cost, universal, unambiguous, non-forgeable, securely
    multipliable, revocable and renewable "digital handles" to themselves, 
    preferable issued by globally recognized, trusted third parties
========================================================




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8T5qY019900 for ietf-pkix-bks; Sat, 28 Sep 2002 22:52:34 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8T5qWv19896 for <[e-mail]>; Sat, 28 Sep 2002 22:52:33 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8T5qN4b029692; Sun, 29 Sep 2002 17:52:23 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA521260; Sun, 29 Sep 2002 17:52:22 +1200 (NZST) (sender [e-mail])
Date: Sun, 29 Sep 2002 17:52:22 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Questions on Authority/Subject Key Identifiers
Cc: [e-mail]
Sender: [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>

Stephen Kent <[e-mail]> writes:

>The real world issue you describe calls for re-issuance of certs; it does not
>justify violating the standards.

In *theory* it calls for the re-issuance of certs.  I can quite easily see
that the practical approach would be to chain by sKID, and obviously enough
people agree with this that they persuaded MS to change the behaviour of their
code to allow it (the issue you're referring to was a bug, not a deliberate
design decision like sKID chaining).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8SJHN918370 for ietf-pkix-bks; Sat, 28 Sep 2002 12:17:23 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8SJHMv18366 for <[e-mail]>; Sat, 28 Sep 2002 12:17:22 -0700 (PDT)
Received: from [128.33.238.47] (tc238-047.bbn.com [128.33.238.47]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17863; Sat, 28 Sep 2002 15:17:41 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05100301b9b8cce3b886@[142.131.246.130]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sat, 28 Sep 2002 15:07:16 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [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>

At 3:53 PM +1200 9/17/02, Peter Gutmann wrote:
>Phil Griffin <[e-mail]> writes:
>
>>Hoping to foment a groundswell of activity, I agree with Russ on this.
>
>Hoping to foment a nice stress-relieving flamewar, I'll agree with Phil that
>since PKIX will standardise anything with an ASN.1 syntax, we may as well do
>this one as well.
>
>Peter >:-).

Fortunately, the comment was so ludicrous that nobody took your 
comment seriously.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8SJGVS18356 for ietf-pkix-bks; Sat, 28 Sep 2002 12:16:31 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8SJGJv18352 for <[e-mail]>; Sat, 28 Sep 2002 12:16:29 -0700 (PDT)
Received: from [128.33.238.47] (tc238-047.bbn.com [128.33.238.47]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17759; Sat, 28 Sep 2002 15:16:06 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05100301b9b69ccb9bf3@[142.131.246.130]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sat, 28 Sep 2002 15:07:17 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Questions on Authority/Subject Key Identifiers
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [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>

At 6:44 PM +1200 9/24/02, Peter Gutmann wrote:
>"Tom Gindin" <[e-mail]> writes:
>
>>You should not IMO accept any certificate as a candidate to be the 
>>issuer of a
>>given certificate unless its subject matches the issuer field.
>
>What if the cert has been reparented, e.g. due to a company reorg or merger?
>This is a real-world issue, MS allow chaining by sKID (even if the DNs don't
>match) for this reason.
>
>Peter.

And MS implementations are non-compliant for this and several other 
reasons that have garnered considerable press recently. The real 
world issue you describe calls for re-issuance of certs; it does not 
justify violating the standards.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8S3AUg21196 for ietf-pkix-bks; Fri, 27 Sep 2002 20:10:30 -0700 (PDT)
Received: from 21cn.com ([61.140.60.248]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8S3AMv21181 for <[e-mail]>; Fri, 27 Sep 2002 20:10:23 -0700 (PDT)
Received: from 21cn.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm543d952599; Sat, 28 Sep 2002 11:09:36 +0800
Received: from 21cn.com([10.2.1.4]) by 21cn.com(AIMC 2.9.5.1) with SMTP id jm2c3d957032; Sat, 28 Sep 2002 11:09:36 +0800
Received: from above.proper.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm573d907c21; Tue, 24 Sep 2002 17:06:22 +0800
Received: from above.proper.com([208.184.76.45]) by 21cn.com(AIMC 2.9.5.1) with SMTP id jm223d904d38; Tue, 24 Sep 2002 17:06:22 +0800
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8O6ijL05382 for ietf-pkix-bks; Mon, 23 Sep 2002 23:44:45 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O6ihv05372 for <[e-mail]>; Mon, 23 Sep 2002 23:44:43 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8O6ibNF017567; Tue, 24 Sep 2002 18:44:37 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA30509; Tue, 24 Sep 2002 18:44:35 +1200 (NZST) (sender [e-mail])
Date: Tue, 24 Sep 2002 18:44:35 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Questions on Authority/Subject Key Identifiers
Cc: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [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>

"Tom Gindin" <[e-mail]> writes:

>You should not IMO accept any certificate as a candidate to be the issuer of a
>given certificate unless its subject matches the issuer field.

What if the cert has been reparented, e.g. due to a company reorg or merger?
This is a real-world issue, MS allow chaining by sKID (even if the DNs don't
match) for this reason.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8RLErE29883 for ietf-pkix-bks; Fri, 27 Sep 2002 14:14:53 -0700 (PDT)
Received: from stargazer-o.stars-smi.com (stargazer-o.stars-smi.com [151.200.173.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8RLEqv29879 for <[e-mail]>; Fri, 27 Sep 2002 14:14:52 -0700 (PDT)
Received: from excelsior.stars-smi.com by stargazer-o.stars-smi.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Sep 2002 21:12:30 UT
Received: by excelsior.stars-smi.com with Internet Mail Service (5.5.2655.55) id <RDBXQ5K9>; Fri, 27 Sep 2002 17:22:29 -0400
Message-ID: <DCE76463749C64499892A0DB3AF05AC60245751C@CHALLENGER>
From: "Hamrick, Matt" <[e-mail]>
To: "'Hallam-Baker, Phillip'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)
Date: Fri, 27 Sep 2002 17:10:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

Actually.... Joel White over at Tufts (http://www.neurosci.tufts.edu/White/)
is doing some interesting work in this field. I believe he's getting
research dollars to classify and encode scent information for automated
bomb-sniffing devices. I'll probably be chatting with him sometime over the
next couple of weeks, I'll ask him if he wants to write a draft standard for
scent encoding...

/etc
Matt H.

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[e-mail]]
Sent: Friday, September 27, 2002 2:38 PM
To: [e-mail]; [e-mail];
[e-mail]
Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)



I remember the same arguments taking place when we were putting
multimedia into the Web.

People saw the need for inline images - popping up XV windows 
was not very convenient. But Inline movies and sound were generally
considered excessive (at the time the whole of CERN hung off a T1
and that was upmarket connectivity).

And yes people did try to raise scent in the attempt to make
a joke of a serious issue. 

However the arguments against smells are pretty compelling. First
despite trying nobody has developed an effective technology for 
recording or playback.

Second, polyester is a pretty awfull movie and even odourama 
does not save it.

		Phill

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 2:41 AM
> To: [e-mail]; [e-mail]
> Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)
> 
> 
> 
> Franke Markus <[e-mail]> writes:
> 
> >To fix those security issues we would suggest to add an 
> additional third
> >party harm assertion statement (TPHAS). This TPHAS should be 
> protected by
> >cryptographic means to assure its authenticity and assure that the
> >accompanying scent logotype will not impose undesired 
> physical effects to its
> >receiver.
> 
> The addition of a reliance limit for damage caused by 
> logotype certificate
> extensions would be useful.  This would also cover 
> malicious-MPEG-induced
> epileptic seizures, MP3s with tones at the cranial resonant 
> frequency of your
> pets or designed to shatter the glass in your monitor, and 
> other occurrences.
> 
> Peter.
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8RJKbK25326 for ietf-pkix-bks; Fri, 27 Sep 2002 12:20:37 -0700 (PDT)
Received: from portal.gmu.edu (portalknot.gmu.edu [129.174.0.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8RJKYv25315 for <[e-mail]>; Fri, 27 Sep 2002 12:20:34 -0700 (PDT)
Received: from phessel ([129.174.244.115]) by portal.gmu.edu (8.8.8/8.8.8) with SMTP id PAA23122; Fri, 27 Sep 2002 15:18:53 -0400 (EDT)
Reply-To: <[e-mail]>
From: "Peter Hesse" <[e-mail]>
To: =?iso-8859-1?Q?Karol_G=F3rski?= <[e-mail]>, "Terry Hayes" <[e-mail]>, <[e-mail]>, "Russ" <[e-mail]>
Cc: "Tom Gindin" <[e-mail]>, <[e-mail]>
Subject: RE: Questions on Authority/Subject Key Identifiers
Date: Fri, 27 Sep 2002 15:18:51 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C26639.2F619AD0"
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: <006601c263a5$0e64b5b0$82a908d9@eserwer>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [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>

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C26639.2F619AD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Karol,

I am not sure that I agree with your interpretation.  It is not clear to me
that AKID/SKID must match for a path to be considered valid.  In fact, I
think that it would be best for path development operations to be written
flexible enough to deal with cases in which AKID/SKID do not match, no
matter which form of AKID is being used.

Here's where I'm coming from: most CA products currently available do not
allow the specification of the subject key identifier of a CA that they are
to cross-certify with.  For example, if A is to cross-certify B, A must
ensure that the certificate A issues to B contains a subject key identifier
that matches the authority key identifier in all certificates B issues.

Currently, when most CA products perform cross-certification, they calculate
the SKID based upon the public key.  Hopefully, if the CAs are the same
brand, or due to luck or configuration, they will calculate the SKID in the
same fashion.  However, since there are no guarantees on how the SKID is
calculated (the methods provided in RFC 2459/3280 are just common methods,
not requirements) it is quite possible that this will result in a mismatch.

If your path development algorithm cannot handle this mismatch, you will be
unable to build a path when a valid one exists.  Certainly matching
AKID/SKID should take priority over those that do not, but last I checked
there is nothing in the certificate path validation process for X.509, RFC
2459, or RFC 3280 that fails a path based upon a mismatched AKID/SKID.

--Peter

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

  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]On
Behalf Of Karol Górski
  Sent: Tuesday, September 24, 2002 4:33 AM
  To: Terry Hayes; [e-mail]; Russ
  Cc: Tom Gindin; [e-mail]
  Subject: Re: Questions on Authority/Subject Key Identifiers


  Quoting from X.509:2000 (section 8.2.2.1 Authority key identifier
extension):

  "The key may be identified by an explicit key identifier in the
keyIdentifier component, by identification of a certificate for the key
(giving certificate issuer in the authorityCertIssuer component and
certificate serial number in the authorityCertSerialNumber component) or by
both explicit key identifier and identification of a certificate for the
key. If both forms of identification are used then the certificate or CRL
issuer shall ensure they are consistent."

  and:

  "The keyIdentifier form can be used to select CA certificates during path
construction. The authorityCertIssuer, authorityCertSerialNumber pair can
only be used to provide preference to one certificate over others during
path construction."

  I interpret the last sentence in the following way: during path
construction I can look for certificates which match the identifier in the
keyIdentifier component. If among them I find a certificate which matches
the given issuer/serial number pair I treat it as the preferred certificate
to use. If not (ie. my certificate search failed to find the certificate
which the CA indicated as the preferred certificate to use) then I can use
any certificate among them and in this case there will be a mismatch between
the issuer/serial number fields in the subject certificate and issuer
certificate. However, the names must still match for validation to be
succesful so I would expect that the only mismatch may be in the serial
number.

  Karol Gorski



  ----- Original Message -----
    From: Terry Hayes
    To: [e-mail] ; Russ
    Cc: Tom Gindin ; [e-mail]
    Sent: Tuesday, September 24, 2002 12:15 AM
    Subject: Re: Questions on Authority/Subject Key Identifiers


    Russ,

    Yes, this is the case that I am talking about. Â All validation
algorithms (include the RFC 3280) require the matching that Tom describes. Â
The issue I'm raising is the correct handling during path construction
(discovery) when a certificate seems to have contradictory information about
the certificate for the issuer.

    So far I have one response in favor of  continuing to build a path as
long a one of the values in the authority key identifier extension matches
the data in the potential issuer's certificate. (Russ, please correct if I'm
misinterpreting).

    Terry

    Housley, Russ wrote:


      Tom:

      I believe that Terry is asking about the issuer/serial form of
identifying
      the issuer certificate in the authority key identifier extension.Â
So,
      within the extension, the issuer field identifies the issuer of the
      issuer's certificate, and the serial identifies the issuer's
certificate.

      Russ

      At 03:03 PM 9/23/2002 -0400, Tom Gindin wrote:


      >Â Â Â Â Â Â  Terry:
      >
      >       The interpretation in #2 looks very dangerous.  You
should not IMO
      >accept any certificate as a candidate to be the issuer of a given
      >certificate unless its subject matches the issuer field.  Outside
the PKIX
      >profile, you might allow a case with issuer null and issuerAltName
      >non-null, and then match the candidate issuing certificate's
subjectAltName
      >against issuerAltName.  I don't think that serialNumber even gets
involved
      >in this matching.  Even the public key, let alone the key id, is a
      >necessary but not sufficient element of a chaining match.
      >Â Â Â Â Â Â  I hope somebody else will comment on #1 and #3, where I
have nothing
      >useful to say.
      >
      >Â Â Â Â Â Â Â Â Â Â Â Â  Tom Gindin
      >
    My original question:


      >2) Assume that both the keyIdentifier and issuer name/serial number
fields
      >of the authority key identifier are present in a certificate.Â
Should both
      >values match the issuer's certificate?  Would it make sense to use a
      >certificate for the issuer that matches keyIdentifier fields, even
though
      >it doesn't match the issuer name/serial number values?
      >
      >

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2>Karol,</FONT></SPAN></DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2>I am not sure that I agree with your interpretation.&nbsp; It =
is not=20
clear to me that AKID/SKID must match for a path to be considered =
valid.&nbsp;=20
In fact, I think that it would be best for path development operations =
to be=20
written flexible enough to deal with cases in which AKID/SKID do not =
match, no=20
matter which form of AKID is being used.</FONT></SPAN></DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2>Here's where I'm coming from: most CA products currently =
available do not=20
allow the specification of the subject key identifier of a CA that they =
are to=20
cross-certify with.&nbsp; For example, if A is to cross-certify B, A =
must ensure=20
that the certificate A issues to B contains a subject key identifier =
that=20
matches the authority key identifier&nbsp;in all certificates&nbsp;B=20
issues.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2>Currently, when most CA products perform cross-certification, =
they=20
calculate the SKID based upon the public key.&nbsp; Hopefully, if the =
CAs are=20
the same brand, or due to luck or configuration, they =
will&nbsp;calculate the=20
SKID in the same fashion.&nbsp; However, s</FONT></SPAN><SPAN=20
class=3D849400319-27092002><FONT face=3D"Comic Sans MS" color=3D#800080 =
size=3D2>ince=20
there are no guarantees on how the SKID is calculated (the methods =
provided in=20
RFC 2459/3280 are just common methods, not requirements) it is quite =
possible=20
that this will result in a mismatch.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2>If your path development algorithm cannot handle this mismatch, =
you will=20
be unable to build a path when a valid one exists.&nbsp; Certainly =
matching=20
AKID/SKID should take priority over those that do not, but last I =
checked there=20
is nothing in the certificate path validation process for X.509, RFC =
2459, or=20
RFC 3280 that fails a path based upon a mismatched=20
AKID/SKID.</FONT></SPAN></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#800080 =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#800080 size=3D2><SPAN=20
class=3D849400319-27092002>--Peter</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#800080 =
size=3D2></FONT>&nbsp;</DIV><FONT=20
face=3D"Courier New" size=3D2><FONT=20
color=3Dgray>+-----------------------------------------------------------=
----+<BR>|&nbsp;</FONT><FONT=20
color=3D#3333cc>Peter=20
Hesse</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT=20
color=3Dblue>[e-mail]</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;<FONT=20
color=3Dgray>|<BR>|&nbsp;</FONT><FONT color=3D#3333cc>Phone:=20
[phone]</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;<FONT=20
color=3D#3333cc>Gemini Security Solutions, Inc.&nbsp;&nbsp;</FONT><FONT=20
color=3Dgray>|<BR>|&nbsp;</FONT><FONT color=3D#3333cc>ICQ:=20
1942828</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT =

color=3Dblue>www.geminisecurity.com</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;<FONT=20
color=3Dgray>|<BR>+------------------------------------------------------=
---------+<BR><FONT=20
color=3Dteal>"Pay no attention to what the critics say; there has never =
been <BR>a=20
statue set up in honor of a critic." --Jean =
Sibelius</FONT><BR></FONT></FONT>
<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> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of </B>Karol=20
  G=F3rski<BR><B>Sent:</B> Tuesday, September 24, 2002 4:33 =
AM<BR><B>To:</B> Terry=20
  Hayes; [e-mail]; Russ<BR><B>Cc:</B> Tom Gindin;=20
  [e-mail]<BR><B>Subject:</B> Re: Questions on =
Authority/Subject Key=20
  Identifiers<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Quoting from X.509:2000 (section =
8.2.2.1=20
  Authority key identifier extension):</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>"The key may be identified by an =
explicit key=20
  identifier in the keyIdentifier component, by identification of a =
certificate=20
  for the key (giving certificate issuer in the authorityCertIssuer =
component=20
  and certificate serial number in the authorityCertSerialNumber =
component) or=20
  by both explicit key identifier and identification of a certificate =
for the=20
  key. If both forms of identification are used then the certificate or =
CRL=20
  issuer shall ensure they are consistent."</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>and:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>"The keyIdentifier form can be used =
to select CA=20
  certificates during path construction. The authorityCertIssuer,=20
  authorityCertSerialNumber pair can only be used to provide preference =
to one=20
  certificate over others during path construction."</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I interpret the last sentence in the =
following=20
  way: during path construction I can look for certificates which match =
the=20
  identifier in the keyIdentifier component. If among them I find&nbsp;a =

  certificate which matches the given issuer/serial number pair I treat =
it as=20
  the preferred certificate to use. If not (ie. my certificate search =
failed to=20
  find the certificate which the CA indicated as the preferred =
certificate to=20
  use) then I can use any certificate among them and in this case there =
will be=20
  a mismatch between the issuer/serial number fields in the subject =
certificate=20
  and issuer certificate. However, the names must still match for =
validation to=20
  be succesful so I would expect that the only mismatch may be in the =
serial=20
  number.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Karol Gorski</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV>----- Original Message ----- </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=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=[e-mail] =
href=3D"mailto:[e-mail]">Terry=20
    Hayes</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
    href=3D"mailto:[e-mail]">[e-mail]</A> ; <A=20
    title=[e-mail]=20
    href=3D"mailto:[e-mail]">Russ</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
    href=3D"mailto:[e-mail]">Tom Gindin</A> ; <A =
title=[e-mail]=20
    href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, September 24, =
2002 12:15=20
    AM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Questions on=20
    Authority/Subject Key Identifiers</DIV>
    <DIV><BR></DIV>Russ,<BR><BR>Yes, this is the case that I am talking =
about.=20
    =C2&nbsp;All validation algorithms (include the RFC 3280) require =
the matching=20
    that Tom describes. =C2&nbsp;The issue I'm raising is the correct =
handling=20
    during path construction (discovery) when a certificate seems to =
have=20
    contradictory information about the certificate for the =
issuer.<BR><BR>So=20
    far I have one response in favor of =C2&nbsp;continuing to build a =
path as=20
    long a one of the values in the authority key identifier extension =
matches=20
    the data in the potential issuer's certificate. (Russ, please =
correct if I'm=20
    misinterpreting).<BR><BR>Terry<BR><BR>Housley, Russ wrote:=20
    <P></P>
    <BLOCKQUOTE=20
    style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue =
thin solid"=20
    type=3D"cite"><TT><BR>Tom: <BR><BR>I believe that Terry is asking =
about the=20
      issuer/serial form of identifying <BR>the issuer certificate in =
the=20
      authority key identifier extension.=C2&nbsp; So, <BR>within the =
extension,=20
      the issuer field identifies the issuer of the <BR>issuer's =
certificate,=20
      and the serial identifies the issuer's certificate. <BR><BR>Russ=20
      <BR><BR>At 03:03 PM 9/23/2002 -0400, Tom Gindin wrote:=20
      =
<BR><BR><BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; =
Terry: <BR>&gt;=20
      <BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; The =
interpretation in=20
      #2 looks very dangerous.=C2&nbsp; You should not IMO =
<BR>&gt;accept any=20
      certificate as a candidate to be the issuer of a given =
<BR>&gt;certificate=20
      unless its subject matches the issuer field.=C2&nbsp; Outside the =
PKIX=20
      <BR>&gt;profile, you might allow a case with issuer null and =
issuerAltName=20
      <BR>&gt;non-null, and then match the candidate issuing =
certificate's=20
      subjectAltName <BR>&gt;against issuerAltName.=C2&nbsp; I don't =
think that=20
      serialNumber even gets involved <BR>&gt;in this matching.=C2&nbsp; =
Even the=20
      public key, let alone the key id, is a <BR>&gt;necessary but not=20
      sufficient element of a chaining match.=20
      <BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; I =
hope somebody else=20
      will comment on #1 and #3, where I have nothing <BR>&gt;useful to =
say.=20
      <BR>&gt;=20
      =
<BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2=
&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=20
      Tom Gindin <BR>&gt; </TT></BLOCKQUOTE>My original question:<BR>
    <BLOCKQUOTE=20
    style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue =
thin solid"=20
    type=3D"cite"><TT><BR>&gt;2) Assume that both the keyIdentifier and =
issuer=20
      name/serial number fields <BR>&gt;of the authority key identifier =
are=20
      present in a certificate.=C2&nbsp; Should both <BR>&gt;values =
match the=20
      issuer's certificate?=C2&nbsp; Would it make sense to use a=20
      <BR>&gt;certificate for the issuer that matches keyIdentifier =
fields, even=20
      though <BR>&gt;it doesn't match the issuer name/serial number =
values?=20
      <BR>&gt; =
<BR>&gt;<BR></TT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0006_01C26639.2F619AD0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8RIaVq21021 for ietf-pkix-bks; Fri, 27 Sep 2002 11:36:31 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8RIaTv21017 for <[e-mail]>; Fri, 27 Sep 2002 11:36:29 -0700 (PDT)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8RIaO9M003890; Fri, 27 Sep 2002 11:36:25 -0700 (PDT)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <SLCQH25N>; Fri, 27 Sep 2002 11:38:22 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)
Date: Fri, 27 Sep 2002 11:38:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

I remember the same arguments taking place when we were putting
multimedia into the Web.

People saw the need for inline images - popping up XV windows 
was not very convenient. But Inline movies and sound were generally
considered excessive (at the time the whole of CERN hung off a T1
and that was upmarket connectivity).

And yes people did try to raise scent in the attempt to make
a joke of a serious issue. 

However the arguments against smells are pretty compelling. First
despite trying nobody has developed an effective technology for 
recording or playback.

Second, polyester is a pretty awfull movie and even odourama 
does not save it.

		Phill

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 2:41 AM
> To: [e-mail]; [e-mail]
> Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)
> 
> 
> 
> Franke Markus <[e-mail]> writes:
> 
> >To fix those security issues we would suggest to add an 
> additional third
> >party harm assertion statement (TPHAS). This TPHAS should be 
> protected by
> >cryptographic means to assure its authenticity and assure that the
> >accompanying scent logotype will not impose undesired 
> physical effects to its
> >receiver.
> 
> The addition of a reliance limit for damage caused by 
> logotype certificate
> extensions would be useful.  This would also cover 
> malicious-MPEG-induced
> epileptic seizures, MP3s with tones at the cranial resonant 
> frequency of your
> pets or designed to shatter the glass in your monitor, and 
> other occurrences.
> 
> Peter.
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8R6fSL16711 for ietf-pkix-bks; Thu, 26 Sep 2002 23:41:28 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8R6fQv16706 for <[e-mail]>; Thu, 26 Sep 2002 23:41:26 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8R6fK4b010268; Fri, 27 Sep 2002 18:41:20 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA363907; Fri, 27 Sep 2002 18:41:20 +1200 (NZST) (sender [e-mail])
Date: Fri, 27 Sep 2002 18:41:20 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)
Sender: [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>

Franke Markus <[e-mail]> writes:

>To fix those security issues we would suggest to add an additional third
>party harm assertion statement (TPHAS). This TPHAS should be protected by
>cryptographic means to assure its authenticity and assure that the
>accompanying scent logotype will not impose undesired physical effects to its
>receiver.

The addition of a reliance limit for damage caused by logotype certificate
extensions would be useful.  This would also cover malicious-MPEG-induced
epileptic seizures, MP3s with tones at the cranial resonant frequency of your
pets or designed to shatter the glass in your monitor, and other occurrences.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8R6DQF11337 for ietf-pkix-bks; Thu, 26 Sep 2002 23:13:26 -0700 (PDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8R6DOv11326 for <[e-mail]>; Thu, 26 Sep 2002 23:13:25 -0700 (PDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id IAA22164 for <[e-mail]>; Fri, 27 Sep 2002 08:13:28 +0200 (MET DST)
Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id IAA11545 for <[e-mail]>; Fri, 27 Sep 2002 08:13:27 +0200 (MET DST)
Received: by MCHH246E with Internet Mail Service (5.5.2656.59) id <RZASKCCW>; Fri, 27 Sep 2002 08:13:27 +0200
Message-ID: <1D82815C322BD41196EA00508B951F7B05343C32@MCHH265E>
From: Franke Markus <[e-mail]>
To: [e-mail]
Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt) 
Date: Fri, 27 Sep 2002 08:13:01 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [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>

Basically we're very positive with your proposal. Unfortunately we 
observed some shortcomings in section 7.1 "Security considerations". 

As opposed to other known PKIX mechanisms, scent logotypes might be abused 
to cause immediate physical harm to the relying party. Especially allergic 
subjects might be affected by scent logotypes from e.g. an online flower 
store. Worst case, scent logotypes might also be abused for terroristic 
attack.

To fix those security issues we would suggest to add an additional third 
party harm assertion statement (TPHAS). This TPHAS should be protected by
cryptographic means to assure its authenticity and assure that the 
accompanying scent logotype will not impose undesired physical effects to 
its receiver.

In case we get some positive feedback we could provide a more extensive 
outline for the intended TPHAS syntax and processing. There is already 
some activity here to define this as a new XML language extension 
(TPHASML).

Regards,

Markus


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, September 26, 2002 4:41 AM
To: [e-mail]
Subject: Re: Comments on (draft-ietf-pkix-logotypes-05.txt) 



First, Bob Jueneman suggested MPEGs in certificates as a joke.  This is now
being standardised in the logotypes draft.

Then I suggested theme music in certificates as a joke.  This is now being
standardised in the logotypes draft.

Now, in an attempt to make the discussion even more surreal, I give you...

4.3. Scent logotypes

Alongside audio and video logotypes, it may be desirable for certificates to
carry scent logotypes in order to uniquely brand certificate holders in a
manner meaningful to relying parties.  For example, McDonalds may choose to
imbue their certificates with the aroma of fried beef patties and grilled
cheese, the National Park Service may choose the essence of pure Colorado
mountain air with just a hint of pine, and the NRA would use a heady mixture
of cordite and gun oil.

The new logotype would be implemented in the form of scratch-n-sniff
certificates, and will assist relying parties in making informed decisions as
to whether a particular certificate is trustworthy and relevant for its
intended usage.  Service providers and product vendors invest a lot of money
and resources into creating a strong relation between positive user
experiences and easily recognizable scents such as grilled beef, fresh air,
and cordite, allowing easy and familiar branding of certificates.

The scent logotype extension MUST have the following syntax:

      LogotypeScent ::= SEQUENCE {
         scentSubtype    IA5String, -- MIME scent subtype
         scent           OCTET STRING }

A MIME type is used to specify the format of the file containing the scent
logotype data.  The scent element contains the scratch-n-sniff scent logotype
associated with the certificate.

7.1. Security considerations

Implementors should be aware that there exists the potential for confusion
among relying parties when evaluating similar scent logotypes.  For example,
relying parties may not be able to meaningfully differentiate between the
logos for McDonalds and Burger King, or Hersheys and Nestle, or Sealord and
Penthouse.  Resolution of this issue lies outside the scope of this memo.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8R5EaW04564 for ietf-pkix-bks; Thu, 26 Sep 2002 22:14:36 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8R5EXv04560 for <[e-mail]>; Thu, 26 Sep 2002 22:14:34 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8R5EW4b008716 for <[e-mail]>; Fri, 27 Sep 2002 17:14:32 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA339699 for [e-mail]; Fri, 27 Sep 2002 17:14:31 +1200 (NZST) (sender [e-mail])
Date: Fri, 27 Sep 2002 17:14:31 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Scent logotypes minor update
Sender: [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>

I got quite a bit of feedback on this, attached below is a revised version
with improvements suggested by various people (you know who you are :-).

(Incidentally, I do know what irony is: It's like goldy and silvery, only
 cheaper).

-- Snip --

First, Bob Jueneman suggested MPEGs in certificates as a joke.  This is now
being standardised in the logotypes draft.

Then I suggested theme music in certificates as a joke.  This is now being
standardised in the logotypes draft.

Now, in an attempt to make the discussion even more surreal, I give you...

4.3. Scent logotypes

Alongside audio and video logotypes, it may be desirable for certificates to
carry scent logotypes in order to uniquely brand certificate holders in a
manner meaningful to relying parties.  For example, McDonalds may choose to
imbue their certificates with the aroma of fried beef patties and grilled
cheese, the National Park Service may choose the essence of pure Colorado
mountain air with just a hint of pine, the NRA would use a heady mixture of
cordite and gun oil, and PKIX could use cold coffee and stale cigarette smoke.

The new logotype would be implemented in the form of scratch-n-sniff
certificates, and will assist relying parties in making informed decisions as
to whether a particular certificate is trustworthy and relevant for its
intended usage.  Service providers and product vendors invest a lot of money
and resources into creating a strong relation between positive user
experiences and easily recognizable scents such as grilled beef, fresh air,
and cordite, allowing easy and familiar branding of certificates.

The scent logotype extension MUST have the following syntax:

      LogotypeScent ::= SEQUENCE {
         scentSubtype     IA5String, -- MIME scent subtype
         scent            OCTET STRING,
         refreshInfo      ScentRefreshInfo OPTIONAL
         }
      
A MIME type is used to specify the format of the file containing the scent
logotype data.  The scent element contains the scratch-n-sniff scent logotype
associated with the certificate.

Since scents fade over time, it may be necessary to periodically refresh the
scent to preserve the user experience:

      ScentRefreshInfo ::= SEQUENCE {
         refreshTime      INTEGER DEFAULT 30,
         refreshCount [0] INTEGER DEFAULT 1,
         refreshUrl       IA5String,
         refreshUrlHash   OCTET STRING OPTIONAL }

The refresh time specifies the time in seconds after which the scent must be
refreshed, the refresh count specifies the number of times the scent should be
refreshed after initial deployment, and the URL and optional hash of the data
stored at the URL location contains the scent payload and integrity protection
mechanism.

7.1. Security considerations

Implementors should be aware that there exists the potential for confusion
among relying parties when evaluating similar scent logotypes.  For example,
relying parties may not be able to meaningfully differentiate between the
logos for McDonalds and Burger King, or Hersheys and Nestle, or Sealord and
Penthouse.  Resolution of this issue lies outside the scope of this memo.

Intensive usage of scent logotypes may trigger smoke alarms and, by extension,
sprinkler systems.  Users should be aware of this and carry an umbrella.

Certificate users involved in skunkworks projects are discouraged from adding
scent logotypes to their certificates.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8QHGAm23497 for ietf-pkix-bks; Thu, 26 Sep 2002 10:16:10 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QHG9v23492 for <[e-mail]>; Thu, 26 Sep 2002 10:16:09 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19713; Thu, 26 Sep 2002 11:16:10 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id NAA26380; Thu, 26 Sep 2002 13:16:08 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 13:11:11 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Marc Jadoul <[e-mail]>
CC: [e-mail]
Subject: Re: RFC 3280 error WRT rfc822Name
References: <[e-mail]> <[e-mail]> <010901c2647b$b955d400$2308a8c0@MJDeskproEN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

Marc Jadoul wrote:
> Sometimes it is better to break things! Having 2 users with
> the same email address except cases is really a stupid thing
> to do, and you won't break that much by changing that! Seems
> more like fixing things to me.
>
> Does it exist 1 real world example for having as requirement
> 'cases sensitive email addresses'?

But Ned Freed (one of the authors of the MIME spec) wrote:
> This requirement is well understood by those of us who work
> on email software. Any package that fails to support it gets
> in trouble sooner or later. Indeed, software that preserves
> case but isn't capable of supporting case sensitivity for
> domains it has administrative control over can be problematic.
> I've seen software sales won or lost over this issue.

So apparently there are real customers who care about this
issue, real software that implements case-sensitive matching
for local-part, and long-standing standards that say SMTP
servers must treat local-part as case-sensitive. I'm sure
this question was considered carefully when RFC 2821 and
RFC 2822 were developed. A decision was made to keep handling
local-part as case-sensitive.

The conclusion seems clear to me. We must change the successor
to RFC 3280 to say that local-part should be matched using
case-sensitive matching.

-Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8QGkBB21764 for ietf-pkix-bks; Thu, 26 Sep 2002 09:46:11 -0700 (PDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QGk9v21760 for <[e-mail]>; Thu, 26 Sep 2002 09:46:10 -0700 (PDT)
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.3/8.12.3/1.0) with ESMTP id g8QGk9nS015544; Thu, 26 Sep 2002 09:46:10 -0700 (PDT)
Received: from LLUNDBLA2.qualcomm.com (llundbla2.qualcomm.com [129.46.158.82]) by neophyte.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id g8QGk6JK010103; Thu, 26 Sep 2002 09:46:07 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 26 Sep 2002 09:46:06 -0700
To: Marc Jadoul <[e-mail]>, Steve Hanna <[e-mail]>
From: Laurence Lundblade <[e-mail]>
Subject: Re: RFC 3280 error WRT rfc822Name
Cc: [e-mail]
In-Reply-To: <010901c2647b$b955d400$2308a8c0@MJDeskproEN>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

At 12:10 PM 9/25/2002 +0200, Marc Jadoul wrote:

>Sometimes it is better to break things!

I agree that can be true, though you generally need a transition plan.

>Having 2 users with the same email
>address except cases is really a stupid thing to do,

That's probably true in general, but someone some where may have a 
non-stupid use. For example they have layered some application on top of 
email that involved user identification that is case sensitive and that 
application is one that can't be modified. Or maybe some one has a gateway 
to another mail system that is case sensitive.

>  and you won't break
>that much by changing that!

RFC-822 email addresses are used by more than 100 million users and 
thousands of products. These addresses are even used outside of email in 
things like SIP. Today the rules you follow for this particular part of the 
standard are clear.

If we were to change the rules to say that case doesn't matter then we 
should say that all software using these addresses should do comparisons 
independent of case. It would take years for all the currently deployed 
servers and clients to be upgraded to have that behavior. We'd probably 
never really get it straight. It would probably also take a few years to 
update RFC 2822.

>Seems more like fixing things to me.
>Does it exist 1 real world example for having as requirement 'cases
>sensitive email addresses'?

Don't have a really good concrete example (which doesn't mean one doesn't 
exist). What I would offer is the fact that UNIX, Linux, and Solaris login 
names are case sensitive even though sendmail seems to ignore the case.

LL



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8QCb0K07492 for ietf-pkix-bks; Thu, 26 Sep 2002 05:37:00 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QCaxv07485 for <[e-mail]>; Thu, 26 Sep 2002 05:36:59 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04477; Thu, 26 Sep 2002 08:34:56 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-usergroup-01.txt
Date: Thu, 26 Sep 2002 08:34:56 -0400
Sender: [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>

--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		: The PKIX UserGroupName GeneralName Type
	Author(s)	: M. StJohns
	Filename	: draft-ietf-pkix-usergroup-01.txt
	Pages		: 14
	Date		: 2002-9-25
	
A number of systems which understand X.509 client certificates have
developed various ad hoc mechanisms to map a certificate to a
'userid'/'group(s)' value which can then be used for access control.
The mechanisms include idiosyncratic name forms for the SubjectName
field such as encoding the userid as a CommonName and the group as an
OrganizationalUnit, or mapping the certificate against an entry in a
directory system.  This document describes an otherName extension of
the GeneralName type which can be used in the SubjectAltName
extension or IssuerAltName extension to directly encode userid and
group information.

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-usergroup-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 majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8Q2fGY11896 for ietf-pkix-bks; Wed, 25 Sep 2002 19:41:16 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8Q2fEv11891 for <[e-mail]>; Wed, 25 Sep 2002 19:41:14 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8Q2fC4b007981 for <[e-mail]>; Thu, 26 Sep 2002 14:41:12 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA226094 for [e-mail]; Thu, 26 Sep 2002 14:41:10 +1200 (NZST) (sender [e-mail])
Date: Thu, 26 Sep 2002 14:41:10 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Comments on (draft-ietf-pkix-logotypes-05.txt) 
Sender: [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>

First, Bob Jueneman suggested MPEGs in certificates as a joke.  This is now
being standardised in the logotypes draft.

Then I suggested theme music in certificates as a joke.  This is now being
standardised in the logotypes draft.

Now, in an attempt to make the discussion even more surreal, I give you...

4.3. Scent logotypes

Alongside audio and video logotypes, it may be desirable for certificates to
carry scent logotypes in order to uniquely brand certificate holders in a
manner meaningful to relying parties.  For example, McDonalds may choose to
imbue their certificates with the aroma of fried beef patties and grilled
cheese, the National Park Service may choose the essence of pure Colorado
mountain air with just a hint of pine, and the NRA would use a heady mixture
of cordite and gun oil.

The new logotype would be implemented in the form of scratch-n-sniff
certificates, and will assist relying parties in making informed decisions as
to whether a particular certificate is trustworthy and relevant for its
intended usage.  Service providers and product vendors invest a lot of money
and resources into creating a strong relation between positive user
experiences and easily recognizable scents such as grilled beef, fresh air,
and cordite, allowing easy and familiar branding of certificates.

The scent logotype extension MUST have the following syntax:

      LogotypeScent ::= SEQUENCE {
         scentSubtype    IA5String, -- MIME scent subtype
         scent           OCTET STRING }

A MIME type is used to specify the format of the file containing the scent
logotype data.  The scent element contains the scratch-n-sniff scent logotype
associated with the certificate.

7.1. Security considerations

Implementors should be aware that there exists the potential for confusion
among relying parties when evaluating similar scent logotypes.  For example,
relying parties may not be able to meaningfully differentiate between the
logos for McDonalds and Burger King, or Hersheys and Nestle, or Sealord and
Penthouse.  Resolution of this issue lies outside the scope of this memo.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8PA7BQ15227 for ietf-pkix-bks; Wed, 25 Sep 2002 03:07:11 -0700 (PDT)
Received: from mail.belbone.be (mail.belbone.be [195.13.1.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PA79v15221 for <[e-mail]>; Wed, 25 Sep 2002 03:07:10 -0700 (PDT)
Received: from MJDeskproEN ([192.168.8.35]) by mail.belbone.be (8.12.5/8.12.5) with SMTP id g8PA74Na027214; Wed, 25 Sep 2002 12:07:04 +0200 (MET DST)
Message-ID: <010901c2647b$b955d400$2308a8c0@MJDeskproEN>
From: "Marc Jadoul" <[e-mail]>
To: "Steve Hanna" <[e-mail]>, "Laurence Lundblade" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: RFC 3280 error WRT rfc822Name
Date: Wed, 25 Sep 2002 12:10: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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [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>

Sometimes it is better to break things! Having 2 users with the same email
address except cases is really a stupid thing to do, and you won't break
that much by changing that! Seems more like fixing things to me.
Does it exist 1 real world example for having as requirement 'cases
sensitive email addresses'?

Actually I suppose (Please confirm if you know) that most smime clients will
choose the certificates to encrypt emails using a case insensitive matching
of the destination email addresses. There will be less problems if we change
RFC 282? than if we have to change all the smime clients and if we need to
teach to users to be carefull with cases in the first part of the email
address...

Regards,

Marc Jadoul

----- Original Message -----
From: "Laurence Lundblade" <[e-mail]>
To: "Marc Jadoul" <[e-mail]>; "Steve Hanna"
<[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, September 24, 2002 10:32 PM
Subject: Re: RFC 3280 error WRT rfc822Name


>
> At 10:41 AM 9/18/2002 +0200, Marc Jadoul wrote:
>
> >Seems a BIG problem to me!
> >
> >May be RFC 3280 is wrong in his understanding of RFC 822.
> >But RFC 822 (or ...) is probably wrong in doing things so complex for End
> >Users.
> >And I do not see how it can be fixed except fixing RFC 2822 and RFC 2821.
> >
> >Why is it like this in RFC 822 and successor?
>
>
> The original reason was backward compatibility. 822 (actually I think it
> was RFC 733) was designed to be compatible with a number of existing email
> systems (a very long time ago).
>
> The reason it can't change is also backward compatibility. Such a change
> would cause any current conforming mail system that allows case-sensitive
> mailboxes to become non-conforming.
>
> LL
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OKWd310042 for ietf-pkix-bks; Tue, 24 Sep 2002 13:32:39 -0700 (PDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OKWSv10038 for <[e-mail]>; Tue, 24 Sep 2002 13:32:38 -0700 (PDT)
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.3/8.12.3/1.0) with ESMTP id g8OKWOnS015074; Tue, 24 Sep 2002 13:32:25 -0700 (PDT)
Received: from LLUNDBLA2.qualcomm.com (llundbla2.qualcomm.com [129.46.158.82]) by crowley.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id g8OKWLoY025739; Tue, 24 Sep 2002 13:32:22 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 24 Sep 2002 13:32:20 -0700
To: Marc Jadoul <[e-mail]>, Steve Hanna <[e-mail]>
From: Laurence Lundblade <[e-mail]>
Subject: Re: RFC 3280 error WRT rfc822Name
Cc: [e-mail]
In-Reply-To: <00f201c25eef$42ac7bb0$2308a8c0@MJDeskproEN>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

At 10:41 AM 9/18/2002 +0200, Marc Jadoul wrote:

>Seems a BIG problem to me!
>
>May be RFC 3280 is wrong in his understanding of RFC 822.
>But RFC 822 (or ...) is probably wrong in doing things so complex for End
>Users.
>And I do not see how it can be fixed except fixing RFC 2822 and RFC 2821.
>
>Why is it like this in RFC 822 and successor?


The original reason was backward compatibility. 822 (actually I think it 
was RFC 733) was designed to be compatible with a number of existing email 
systems (a very long time ago).

The reason it can't change is also backward compatibility. Such a change 
would cause any current conforming mail system that allows case-sensitive 
mailboxes to become non-conforming.

LL



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OEJIj19886 for ietf-pkix-bks; Tue, 24 Sep 2002 07:19:18 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8OEJGv19882 for <[e-mail]>; Tue, 24 Sep 2002 07:19:16 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Sep 2002 14:19:18 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA24709 for <[e-mail]>; Tue, 24 Sep 2002 10:19:17 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8OEGpB26359 for <[e-mail]>; Tue, 24 Sep 2002 10:16:51 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVXZ7B>; Tue, 24 Sep 2002 10:19:14 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.32]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVXZ66; Tue, 24 Sep 2002 10:19:11 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 24 Sep 2002 09:48:39 -0400
Subject: Re: Questions on Authority/Subject Key Identifiers
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Terry:

>> >3) Assume that a self-issued certificate (matching subject and issuer
>> >names) contains only a subject key identifier extension (the authority key
>> >identifier is omitted as suggested in the RFC). Is it reasonable to assume
>> >this certificate is self signed, and terminate the construction of the 
>> path?
>>
>>I do not understand this one.  Self-issued certificates can appear in the
>>middle of valid paths.  I expect them to occur during key rollover for an
>>intermediate CA.
>
>Yes, I agree that these certificates may appear in the middle of 
>paths.  I'm looking for a rule to tell when the certificate is actually 
>self-signed, and therefore a "root".
>
>I'm suggesting that roots may omit the authority key identifier extension, 
>or may have one with data that matches the subject key identifier in the 
>same certificate.  Other self-issued certificates would need to contain 
>both key identifier extensions, with different values.

I do not think that self-issued is the appropriate "flag" for a trust 
anchor.  An implementation needs to know all of its trust anchors.  So, 
when self-issued certificates are the way that trust anchors are 
ingratiated, you could search the list of trust anchors when a self-issued 
certificate is encountered.  But, do not stop path construction if the 
self-issued certificate does not represent a trust anchor.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8O8fgW24762 for ietf-pkix-bks; Tue, 24 Sep 2002 01:41:42 -0700 (PDT)
Received: from mr3.ipartners.pl (mr3.ipartners.pl [157.25.5.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O8ffv24756 for <[e-mail]>; Tue, 24 Sep 2002 01:41:41 -0700 (PDT)
Received: from eserwer (dlp-gtc-as1-as129.ipartners.pl [217.8.169.130]) by mr3.ipartners.pl with SMTP id g8O8fFr89691; Tue, 24 Sep 2002 10:41:15 +0200 (CEST)
Message-ID: <006601c263a5$0e64b5b0$82a908d9@eserwer>
From: =?ISO-8859-1?Q?Karol_G=F3rski?= <[e-mail]>
To: "Terry Hayes" <[e-mail]>, <[e-mail]>, "Russ" <[e-mail]>
Cc: "Tom Gindin" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Questions on Authority/Subject Key Identifiers
Date: Tue, 24 Sep 2002 10:33:22 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C263B5.CE495CE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [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>

This is a multi-part message in MIME format.

------=_NextPart_000_0063_01C263B5.CE495CE0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Quoting from X.509:2000 (section 8.2.2.1 Authority key identifier =
extension):

"The key may be identified by an explicit key identifier in the =
keyIdentifier component, by identification of a certificate for the key =
(giving certificate issuer in the authorityCertIssuer component and =
certificate serial number in the authorityCertSerialNumber component) or =
by both explicit key identifier and identification of a certificate for =
the key. If both forms of identification are used then the certificate =
or CRL issuer shall ensure they are consistent."

and:

"The keyIdentifier form can be used to select CA certificates during =
path construction. The authorityCertIssuer, authorityCertSerialNumber =
pair can only be used to provide preference to one certificate over =
others during path construction."

I interpret the last sentence in the following way: during path =
construction I can look for certificates which match the identifier in =
the keyIdentifier component. If among them I find a certificate which =
matches the given issuer/serial number pair I treat it as the preferred =
certificate to use. If not (ie. my certificate search failed to find the =
certificate which the CA indicated as the preferred certificate to use) =
then I can use any certificate among them and in this case there will be =
a mismatch between the issuer/serial number fields in the subject =
certificate and issuer certificate. However, the names must still match =
for validation to be succesful so I would expect that the only mismatch =
may be in the serial number.

Karol Gorski



----- Original Message -----=20
  From: Terry Hayes=20
  To: [e-mail] ; Russ=20
  Cc: Tom Gindin ; [e-mail]=20
  Sent: Tuesday, September 24, 2002 12:15 AM
  Subject: Re: Questions on Authority/Subject Key Identifiers


  Russ,

  Yes, this is the case that I am talking about. =C2 All validation =
algorithms (include the RFC 3280) require the matching that Tom =
describes. =C2 The issue I'm raising is the correct handling during path =
construction (discovery) when a certificate seems to have contradictory =
information about the certificate for the issuer.

  So far I have one response in favor of =C2 continuing to build a path =
as long a one of the values in the authority key identifier extension =
matches the data in the potential issuer's certificate. (Russ, please =
correct if I'm misinterpreting).

  Terry

  Housley, Russ wrote:=20


    Tom:=20

    I believe that Terry is asking about the issuer/serial form of =
identifying=20
    the issuer certificate in the authority key identifier extension.=C2 =
 So,=20
    within the extension, the issuer field identifies the issuer of the=20
    issuer's certificate, and the serial identifies the issuer's =
certificate.=20

    Russ=20

    At 03:03 PM 9/23/2002 -0400, Tom Gindin wrote:=20


    >=C2 =C2 =C2 =C2 =C2 =C2  Terry:=20
    >=20
    >=C2 =C2 =C2 =C2 =C2 =C2  The interpretation in #2 looks very =
dangerous.=C2  You should not IMO=20
    >accept any certificate as a candidate to be the issuer of a given=20
    >certificate unless its subject matches the issuer field.=C2  =
Outside the PKIX=20
    >profile, you might allow a case with issuer null and issuerAltName=20
    >non-null, and then match the candidate issuing certificate's =
subjectAltName=20
    >against issuerAltName.=C2  I don't think that serialNumber even =
gets involved=20
    >in this matching.=C2  Even the public key, let alone the key id, is =
a=20
    >necessary but not sufficient element of a chaining match.=20
    >=C2 =C2 =C2 =C2 =C2 =C2  I hope somebody else will comment on #1 =
and #3, where I have nothing=20
    >useful to say.=20
    >=20
    >=C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2  Tom Gindin=20
    >=20
  My original question:


    >2) Assume that both the keyIdentifier and issuer name/serial number =
fields=20
    >of the authority key identifier are present in a certificate.=C2  =
Should both=20
    >values match the issuer's certificate?=C2  Would it make sense to =
use a=20
    >certificate for the issuer that matches keyIdentifier fields, even =
though=20
    >it doesn't match the issuer name/serial number values?=20
    >=20
    >


------=_NextPart_000_0063_01C263B5.CE495CE0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Quoting from X.509:2000 (section =
8.2.2.1 Authority=20
key identifier extension):</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>"The key may be identified by an =
explicit key=20
identifier in the keyIdentifier component, by identification of a =
certificate=20
for the key (giving certificate issuer in the authorityCertIssuer =
component and=20
certificate serial number in the authorityCertSerialNumber component) or =
by both=20
explicit key identifier and identification of a certificate for the key. =
If both=20
forms of identification are used then the certificate or CRL issuer =
shall ensure=20
they are consistent."</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>and:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>"The keyIdentifier form can be used to =
select CA=20
certificates during path construction. The authorityCertIssuer,=20
authorityCertSerialNumber pair can only be used to provide preference to =
one=20
certificate over others during path construction."</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I interpret the last sentence in the =
following way:=20
during path construction I can look for certificates which match the =
identifier=20
in the keyIdentifier component. If among them I find&nbsp;a certificate =
which=20
matches the given issuer/serial number pair I treat it as the preferred=20
certificate to use. If not (ie. my certificate search failed to find the =

certificate which the CA indicated as the preferred certificate to use) =
then I=20
can use any certificate among them and in this case there will be a =
mismatch=20
between the issuer/serial number fields in the subject certificate and =
issuer=20
certificate. However, the names must still match for validation to be =
succesful=20
so I would expect that the only mismatch may be in the serial=20
number.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Karol Gorski</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>----- Original Message ----- </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=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">Terry Hayes</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> ; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">Russ</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Tom Gindin</A> ; <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, September 24, =
2002 12:15=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Questions on=20
  Authority/Subject Key Identifiers</DIV>
  <DIV><BR></DIV>Russ,<BR><BR>Yes, this is the case that I am talking =
about.=20
  =C2&nbsp;All validation algorithms (include the RFC 3280) require the =
matching=20
  that Tom describes. =C2&nbsp;The issue I'm raising is the correct =
handling=20
  during path construction (discovery) when a certificate seems to have=20
  contradictory information about the certificate for the =
issuer.<BR><BR>So far=20
  I have one response in favor of =C2&nbsp;continuing to build a path as =
long a=20
  one of the values in the authority key identifier extension matches =
the data=20
  in the potential issuer's certificate. (Russ, please correct if I'm=20
  misinterpreting).<BR><BR>Terry<BR><BR>Housley, Russ wrote:=20
  <P></P>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin =
solid"=20
  type=3D"cite"><TT><BR>Tom: <BR><BR>I believe that Terry is asking =
about the=20
    issuer/serial form of identifying <BR>the issuer certificate in the=20
    authority key identifier extension.=C2&nbsp; So, <BR>within the =
extension, the=20
    issuer field identifies the issuer of the <BR>issuer's certificate, =
and the=20
    serial identifies the issuer's certificate. <BR><BR>Russ <BR><BR>At =
03:03 PM=20
    9/23/2002 -0400, Tom Gindin wrote:=20
    =
<BR><BR><BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; =
Terry: <BR>&gt;=20
    <BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; The =
interpretation in #2=20
    looks very dangerous.=C2&nbsp; You should not IMO <BR>&gt;accept any =

    certificate as a candidate to be the issuer of a given =
<BR>&gt;certificate=20
    unless its subject matches the issuer field.=C2&nbsp; Outside the =
PKIX=20
    <BR>&gt;profile, you might allow a case with issuer null and =
issuerAltName=20
    <BR>&gt;non-null, and then match the candidate issuing certificate's =

    subjectAltName <BR>&gt;against issuerAltName.=C2&nbsp; I don't think =
that=20
    serialNumber even gets involved <BR>&gt;in this matching.=C2&nbsp; =
Even the=20
    public key, let alone the key id, is a <BR>&gt;necessary but not =
sufficient=20
    element of a chaining match.=20
    <BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; I =
hope somebody else will=20
    comment on #1 and #3, where I have nothing <BR>&gt;useful to say. =
<BR>&gt;=20
    =
<BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2=
&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=20
    Tom Gindin <BR>&gt; </TT></BLOCKQUOTE>My original question:<BR>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin =
solid"=20
  type=3D"cite"><TT><BR>&gt;2) Assume that both the keyIdentifier and =
issuer=20
    name/serial number fields <BR>&gt;of the authority key identifier =
are=20
    present in a certificate.=C2&nbsp; Should both <BR>&gt;values match =
the=20
    issuer's certificate?=C2&nbsp; Would it make sense to use a=20
    <BR>&gt;certificate for the issuer that matches keyIdentifier =
fields, even=20
    though <BR>&gt;it doesn't match the issuer name/serial number =
values?=20
    <BR>&gt; <BR>&gt;<BR></TT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0063_01C263B5.CE495CE0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8O6ijL05382 for ietf-pkix-bks; Mon, 23 Sep 2002 23:44:45 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O6ihv05372 for <[e-mail]>; Mon, 23 Sep 2002 23:44:43 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8O6ibNF017567; Tue, 24 Sep 2002 18:44:37 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA30509; Tue, 24 Sep 2002 18:44:35 +1200 (NZST) (sender [e-mail])
Date: Tue, 24 Sep 2002 18:44:35 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Questions on Authority/Subject Key Identifiers
Cc: [e-mail]
Sender: [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>

"Tom Gindin" <[e-mail]> writes:

>You should not IMO accept any certificate as a candidate to be the issuer of a
>given certificate unless its subject matches the issuer field.

What if the cert has been reparented, e.g. due to a company reorg or merger?
This is a real-world issue, MS allow chaining by sKID (even if the DNs don't
match) for this reason.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NMMM616809 for ietf-pkix-bks; Mon, 23 Sep 2002 15:22:22 -0700 (PDT)
Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NMMKv16805 for <[e-mail]>; Mon, 23 Sep 2002 15:22:20 -0700 (PDT)
Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id g8NLWmm07125 for <[e-mail]>; Mon, 23 Sep 2002 14:32:48 -0700 (PDT)
Received: from h-10-169-25-78.nscp.aoltw.net ([10.169.25.78]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H2WWT502.YQR; Mon, 23 Sep 2002 15:22:17 -0700 
Date: Mon, 23 Sep 2002 15:22:19 -0700
From: [e-mail] (Terry Hayes)
Subject: Re: Questions on Authority/Subject Key Identifiers
To: [e-mail], Russ <[e-mail]>
cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Mailer: Netscape Messenger M9 (powered by Photon [20020917.1])
Organization: Netscape Communications Corp.
MIME-Version: 1.0
Content-Type: TEXT/HTML; CHARSET=us-ascii
Sender: [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>

Housley, Russ wrote: 
<p> </p>
<blockquote type="cite"
 style="border-left: thin solid blue; padding-left: 10px; margin-left: 0pt;"> 
  <tt> <br>
 Terry: <br>
 <br>
 As you said in the introduction to your questions, these questions are  <br>
 really beyond the scope of the PKIX RFCs, but I will share my opinion. <br>
 </tt></blockquote>
Agreed, and thanks for responding.<br>
<blockquote type="cite"
 style="border-left: thin solid blue; padding-left: 10px; margin-left: 0pt;"><tt><br>
 &gt;3) Assume that a self-issued certificate (matching subject and issuer
 <br>
 &gt;names) contains only a subject key identifier extension (the authority
key  <br>
 &gt;identifier is omitted as suggested in the RFC). Is it reasonable to
assume  <br>
 &gt;this certificate is self signed, and terminate the construction of the
path? <br>
 <br>
 I do not understand this one.  Self-issued certificates can appear in the
 <br>
 middle of valid paths.  I expect them to occur during key rollover for an
 <br>
 intermediate CA. <br>
 </tt></blockquote>
<br>
Yes, I agree that these certificates may appear in the middle of paths.  I'm
looking for a rule to tell when the certificate is actually self-signed,
and therefore a "root".<br>
<br>
I'm suggesting that roots may omit the authority key identifier extension,
or may have one with data that matches the subject key identifier in the
same certificate.  Other self-issued certificates would need to contain both
key identifier extensions, with different values.<br>
<br>
Terry<br>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NMFwU16653 for ietf-pkix-bks; Mon, 23 Sep 2002 15:15:58 -0700 (PDT)
Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NMFvv16649 for <[e-mail]>; Mon, 23 Sep 2002 15:15:57 -0700 (PDT)
Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id g8NLQPu26218 for <[e-mail]>; Mon, 23 Sep 2002 14:26:25 -0700 (PDT)
Received: from h-10-169-25-78.nscp.aoltw.net ([10.169.25.78]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H2WWII01.1RT; Mon, 23 Sep 2002 15:15:54 -0700 
Date: Mon, 23 Sep 2002 15:15:54 -0700
From: [e-mail] (Terry Hayes)
Subject: Re: Questions on Authority/Subject Key Identifiers
To: [e-mail], Russ <[e-mail]>
cc: Tom Gindin <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Mailer: Netscape Messenger M9 (powered by Photon [20020917.1])
Organization: Netscape Communications Corp.
MIME-Version: 1.0
Content-Type: TEXT/HTML; CHARSET=us-ascii
Sender: [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>

Russ,<br>
<br>
Yes, this is the case that I am talking about.  All validation algorithms
(include the RFC 3280) require the matching that Tom describes.  The issue
I'm raising is the correct handling during path construction (discovery)
when a certificate seems to have contradictory information about the certificate
for the issuer.<br>
<br>
So far I have one response in favor of  continuing to build a path as long
a one of the values in the authority key identifier extension matches the
data in the potential issuer's certificate. (Russ, please correct if I'm
misinterpreting).<br>
<br>
Terry<br>
<br>
Housley, Russ wrote: 
<p> </p>
<blockquote type="cite"
 style="border-left: thin solid blue; padding-left: 10px; margin-left: 0pt;"> 
  <tt> <br>
 Tom: <br>
 <br>
 I believe that Terry is asking about the issuer/serial form of identifying
 <br>
 the issuer certificate in the authority key identifier extension.  So,  <br>
 within the extension, the issuer field identifies the issuer of the  <br>
 issuer's certificate, and the serial identifies the issuer's certificate. 
  <br>
 <br>
 Russ <br>
 <br>
 At 03:03 PM 9/23/2002 -0400, Tom Gindin wrote: <br>
 <br>
 <br>
 &gt;       Terry: <br>
 &gt; <br>
 &gt;       The interpretation in #2 looks very dangerous.  You should not
IMO <br>
 &gt;accept any certificate as a candidate to be the issuer of a given <br>
 &gt;certificate unless its subject matches the issuer field.  Outside the
PKIX <br>
 &gt;profile, you might allow a case with issuer null and issuerAltName <br>
 &gt;non-null, and then match the candidate issuing certificate's subjectAltName 
  <br>
 &gt;against issuerAltName.  I don't think that serialNumber even gets involved 
  <br>
 &gt;in this matching.  Even the public key, let alone the key id, is a <br>
 &gt;necessary but not sufficient element of a chaining match. <br>
 &gt;       I hope somebody else will comment on #1 and #3, where I have
nothing <br>
 &gt;useful to say. <br>
 &gt; <br>
 &gt;             Tom Gindin <br>
 &gt; </tt></blockquote>
My original question:<br>
<blockquote type="cite"
 style="border-left: thin solid blue; padding-left: 10px; margin-left: 0pt;"><tt><br>
 &gt;2) Assume that both the keyIdentifier and issuer name/serial number
fields <br>
 &gt;of the authority key identifier are present in a certificate.  Should
both <br>
 &gt;values match the issuer's certificate?  Would it make sense to use a 
  <br>
 &gt;certificate for the issuer that matches keyIdentifier fields, even though 
  <br>
 &gt;it doesn't match the issuer name/serial number values? <br>
 &gt; <br>
 &gt;<br>
 </tt> </blockquote>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NKe7B13957 for ietf-pkix-bks; Mon, 23 Sep 2002 13:40:07 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8NKe4v13949 for <[e-mail]>; Mon, 23 Sep 2002 13:40:04 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Sep 2002 20:40:07 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA13140 for <[e-mail]>; Mon, 23 Sep 2002 16:40:06 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8NKbgb26670 for <[e-mail]>; Mon, 23 Sep 2002 16:37:42 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVXPZK>; Mon, 23 Sep 2002 16:40:04 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVXPZG; Mon, 23 Sep 2002 16:39:58 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 23 Sep 2002 16:36:05 -0400
Subject: Re: Questions on Authority/Subject Key Identifiers
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Terry:

As you said in the introduction to your questions, these questions are 
really beyond the scope of the PKIX RFCs, but I will share my opinion.

>I have some questions about the use of the authority key identifier and 
>subject key identifier fields during the construction of certificate 
>paths. The PKIX RFC is clear that these extensions do not have a role 
>during the path validation phase, however there seem to be ambiguities in 
>how they should be used to build the path.  These gray areas may lead to 
>interoperability problems when application software fails to build (or 
>rejects) a certain certificate path.
>
>Let me say that some of these questions assume certificates may not follow 
>the PKIX profile as written.  In particular, these situations assume that 
>key identifier extensions may be missing, where they are required by the 
>profile. These questions apply when software is allowing a broader range 
>of certificates than described by the PKIX profile.
>
>1)  Assume an authority key identifier extension with a populated 
>keyIdentifier is present in a certificate. Should a corresponding subject 
>key identifier field be REQUIRED in the issuer's certificate?  That is, 
>should candidate certificates for the issuer be rejected because the 
>subject key identifier is missing?

No.  These are not needed for the certificate path validation algorithm to 
be successful.

>2) Assume that both the keyIdentifier and issuer name/serial number fields 
>of the authority key identifier are present in a certificate.  Should both 
>values match the issuer's certificate?  Would it make sense to use a 
>certificate for the issuer that matches keyIdentifier fields, even though 
>it doesn't match the issuer name/serial number values?

Yes.  These are not needed for the certificate path validation algorithm to 
be successful.

>3) Assume that a self-issued certificate (matching subject and issuer 
>names) contains only a subject key identifier extension (the authority key 
>identifier is omitted as suggested in the RFC). Is it reasonable to assume 
>this certificate is self signed, and terminate the construction of the path?

I do not understand this one.  Self-issued certificates can appear in the 
middle of valid paths.  I expect them to occur during key rollover for an 
intermediate CA.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NKe7A13958 for ietf-pkix-bks; Mon, 23 Sep 2002 13:40:07 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8NKe4v13950 for <[e-mail]>; Mon, 23 Sep 2002 13:40:05 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Sep 2002 20:40:07 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA13142; Mon, 23 Sep 2002 16:40:06 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8NKbf826666; Mon, 23 Sep 2002 16:37:41 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVXPZJ>; Mon, 23 Sep 2002 16:40:04 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVXPZH; Mon, 23 Sep 2002 16:39:59 -0400
From: "Housley, Russ" <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 23 Sep 2002 16:39:33 -0400
Subject: Re: Questions on Authority/Subject Key Identifiers
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Tom:

I believe that Terry is asking about the issuer/serial form of identifying 
the issuer certificate in the authority key identifier extension.  So, 
within the extension, the issuer field identifies the issuer of the 
issuer's certificate, and the serial identifies the issuer's certificate.

Russ

At 03:03 PM 9/23/2002 -0400, Tom Gindin wrote:


>       Terry:
>
>       The interpretation in #2 looks very dangerous.  You should not IMO
>accept any certificate as a candidate to be the issuer of a given
>certificate unless its subject matches the issuer field.  Outside the PKIX
>profile, you might allow a case with issuer null and issuerAltName
>non-null, and then match the candidate issuing certificate's subjectAltName
>against issuerAltName.  I don't think that serialNumber even gets involved
>in this matching.  Even the public key, let alone the key id, is a
>necessary but not sufficient element of a chaining match.
>       I hope somebody else will comment on #1 and #3, where I have nothing
>useful to say.
>
>             Tom Gindin
>
>[e-mail] (Terry Hayes)@mail.imc.org on 09/23/2002 12:52:07 AM
>
>Sent by:    [e-mail]
>
>
>To:    [e-mail]
>cc:
>Subject:    Questions on Authority/Subject Key Identifiers
>
>
>I have some questions about the use of the authority key identifier and
>subject key identifier fields during the construction of certificate paths.
>The PKIX RFC is clear that these extensions do not have a role during the
>path validation phase, however there seem to be ambiguities in how they
>should be used to build the path.  These gray areas may lead to
>interoperability problems when application software fails to build (or
>rejects) a certain certificate path.
>
>Let me say that some of these questions assume certificates may not follow
>the PKIX profile as written.  In particular, these situations assume that
>key identifier extensions may be missing, where they are required by the
>profile. These questions apply when software is allowing a broader range of
>certificates than described by the PKIX profile.
>
>1)  Assume an authority key identifier extension with a populated
>keyIdentifier is present in a certificate. Should a corresponding subject
>key identifier field be REQUIRED in the issuer's certificate?  That is,
>should candidate certificates for the issuer be rejected because the
>subject key identifier is missing?
>
>2) Assume that both the keyIdentifier and issuer name/serial number fields
>of the authority key identifier are present in a certificate.  Should both
>values match the issuer's certificate?  Would it make sense to use a
>certificate for the issuer that matches keyIdentifier fields, even though
>it doesn't match the issuer name/serial number values?
>
>3) Assume that a self-issued certificate (matching subject and issuer
>names) contains only a subject key identifier extension (the authority key
>identifier is omitted as suggested in the RFC). Is it reasonable to assume
>this certificate is self signed, and terminate the construction of the
>path?
>
>I would appreciate your thoughts on these situations.
>
>Terry Hayes
>[e-mail]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NJ3Co11573 for ietf-pkix-bks; Mon, 23 Sep 2002 12:03:12 -0700 (PDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NJ3Av11568 for <[e-mail]>; Mon, 23 Sep 2002 12:03:10 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8NJ36IV283586; Mon, 23 Sep 2002 15:03:06 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8NJ33Ot035490; Mon, 23 Sep 2002 15:03:03 -0400
Importance: Normal
Sensitivity: 
Subject: Re: Questions on Authority/Subject Key Identifiers
To: [e-mail] (Terry Hayes)
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 23 Sep 2002 15:03:02 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11  |July 29, 2002) at 09/23/2002 03:03:04 PM
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 g8NJ3Av11570
Sender: [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>

      Terry:

      The interpretation in #2 looks very dangerous.  You should not IMO
accept any certificate as a candidate to be the issuer of a given
certificate unless its subject matches the issuer field.  Outside the PKIX
profile, you might allow a case with issuer null and issuerAltName
non-null, and then match the candidate issuing certificate's subjectAltName
against issuerAltName.  I don't think that serialNumber even gets involved
in this matching.  Even the public key, let alone the key id, is a
necessary but not sufficient element of a chaining match.
      I hope somebody else will comment on #1 and #3, where I have nothing
useful to say.

            Tom Gindin

[e-mail] (Terry Hayes)@mail.imc.org on 09/23/2002 12:52:07 AM

Sent by:    [e-mail]


To:    [e-mail]
cc:
Subject:    Questions on Authority/Subject Key Identifiers


I have some questions about the use of the authority key identifier and
subject key identifier fields during the construction of certificate paths.
The PKIX RFC is clear that these extensions do not have a role during the
path validation phase, however there seem to be ambiguities in how they
should be used to build the path.  These gray areas may lead to
interoperability problems when application software fails to build (or
rejects) a certain certificate path.

Let me say that some of these questions assume certificates may not follow
the PKIX profile as written.  In particular, these situations assume that
key identifier extensions may be missing, where they are required by the
profile. These questions apply when software is allowing a broader range of
certificates than described by the PKIX profile.

1)  Assume an authority key identifier extension with a populated
keyIdentifier is present in a certificate. Should a corresponding subject
key identifier field be REQUIRED in the issuer's certificate?  That is,
should candidate certificates for the issuer be rejected because the
subject key identifier is missing?

2) Assume that both the keyIdentifier and issuer name/serial number fields
of the authority key identifier are present in a certificate.  Should both
values match the issuer's certificate?  Would it make sense to use a
certificate for the issuer that matches keyIdentifier fields, even though
it doesn't match the issuer name/serial number values?

3) Assume that a self-issued certificate (matching subject and issuer
names) contains only a subject key identifier extension (the authority key
identifier is omitted as suggested in the RFC). Is it reasonable to assume
this certificate is self signed, and terminate the construction of the
path?

I would appreciate your thoughts on these situations.

Terry Hayes
[e-mail]







Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NGBT907571 for ietf-pkix-bks; Mon, 23 Sep 2002 09:11:29 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8NGBRv07567 for <[e-mail]>; Mon, 23 Sep 2002 09:11:27 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Sep 2002 16:11:29 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA11558 for <[e-mail]>; Mon, 23 Sep 2002 12:11:28 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8NG93W18002 for <[e-mail]>; Mon, 23 Sep 2002 12:09:03 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVXJLP>; Mon, 23 Sep 2002 12:11:25 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.49]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVXJLK; Mon, 23 Sep 2002 12:11:23 -0400
From: "Housley, Russ" <[e-mail]>
To: David Maurus <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 23 Sep 2002 08:28:35 -0400
Subject: Re: Comments to draft-ietf-pkix-logotypes-05.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

David:

>Two comments to the current draft:

Thanks for reading the draft.

>*** 3rd paragraph on page 7: There's a typo
>"...Compliant application MUST display and play more just one (or none) of 
>the images and one (or none) of the audio sequences at the same time."
>
>Presumably this should be "display and play just one", or perhaps "display 
>and play more than just one" ?

I tried to reword the paragraph.  Let me know if I did not resolve the problem.

    If a logotype is represented by more than one image file, then the
    image files MUST contain variants of the roughly the same image.
    Likewise, if a logotype is represented by more than one audio file,
    then the audio files MUST contain variants of the roughly the same
    audio sequence. Compliant applications MUST display more just one (or
    none) of the images and play just one (or none) of the audio
    sequences at the same time.

>*** 4th paragraph on page 9: Unfortunate use of patent-encumbered formats
>'Implementations that support audio MUST support the MP3 audio format 
>(with a MIME type of "audio/mpeg").'
>
>I would propose to make MP3 optional, and make OGG VORBIS 
>("audio/x-vorbis") a MUST
>
>Proposed wording:
>'Implementations that support audio MUST support the OGG Vorbis format 
>(with a MIME type of "audio/x-vorbis"), and might support the MP3 audio 
>format (with a MIME type of "audio/mpeg")'
>
>The reasoning behind my proposal is that otherwise
>=> Selling any software capable of playing this extension would be subject 
>to mp3 licensing terms, i.e. would require obtaining a license from Thomson.
>=> While currently, Thomson does not charge licensing fees for *freely* 
>distributed player software, this might change in the future. This would 
>make it illegal to use free / Open Source software supporting the logo 
>extension without having a license from Thomson.
>=> Selling hardware (Personal Trusted Devices?) playing logotype-audio 
>would be commercially unattractive
>Ogg Vorbis is considered patent free, offers better quality than mp3 
>according to recent studies, and is available in numerous free 
>implementations and as source code with a BSD style license.

The authors selected MP3 because every media player seems to support it.

Before receiving your note, I had never heard of OGG Vorbis.  I did a 
Google search, and I found lots of information.

What do others think about this proposed change?

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NFjlW07120 for ietf-pkix-bks; Mon, 23 Sep 2002 08:45:47 -0700 (PDT)
Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NFjjv07116 for <[e-mail]>; Mon, 23 Sep 2002 08:45:45 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05111a18b9b4e5666af8@[165.227.249.18]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Mon, 23 Sep 2002 08:45:36 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Comments to draft-ietf-pkix-logotypes-05.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [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>

At 6:33 PM +0200 9/22/02, David Maurus wrote:
>*** 4th paragraph on page 9: Unfortunate use of patent-encumbered formats
>'Implementations that support audio MUST support the MP3 audio 
>format (with a MIME type of "audio/mpeg").'
>
>I would propose to make MP3 optional, and make OGG VORBIS 
>("audio/x-vorbis") a MUST

It is really likely that the IESG (or at least IANA) will strenuously 
object to an "x-" mediatype. They should.

>=> Selling any software capable of playing this extension would be 
>subject to mp3 licensing terms, i.e. would require obtaining a 
>license from Thomson.

The fact that we know that there are intellectual property issues 
with the MP3 format doesn't mean that we *don't* know that there are 
intellectual property issues with OGG.

>=> While currently, Thomson does not charge licensing fees for 
>*freely* distributed player software, this might change in the 
>future. This would make it illegal to use free / Open Source 
>software supporting the logo extension without having a license from 
>Thomson.

We have no proof that the same won't happen to OGG.

>=> Selling hardware (Personal Trusted Devices?) playing 
>logotype-audio would be commercially unattractive

<aside>Many people on this mailing list would say that is a good thing</aside>

>Ogg Vorbis is considered patent free, offers better quality than mp3 
>according to recent studies, and is available in numerous free 
>implementations and as source code with a BSD style license.

"considered patent free" is a bad phrase to use in the IETF, 
particularly in the PKIX WG.

The audio format debate has been raging for years in the VPIM working 
group. If you really want to make a change to this, go spend some 
time in their archives and then suggest an acceptable type. In the 
meantime, MP3 is a common format with a wide variety of encoders and 
decoders available, some of them freely.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NES8T05326 for ietf-pkix-bks; Mon, 23 Sep 2002 07:28:08 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NES6v05319 for <[e-mail]>; Mon, 23 Sep 2002 07:28:06 -0700 (PDT)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8NES59M015041; Mon, 23 Sep 2002 07:28:05 -0700 (PDT)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <SLCPVFRZ>; Mon, 23 Sep 2002 07:30:02 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'David Maurus'" <[e-mail]>, [e-mail]
Subject: RE: Comments to draft-ietf-pkix-logotypes-05.txt
Date: Mon, 23 Sep 2002 07:29:55 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

> *** 4th paragraph on page 9: Unfortunate use of 
> patent-encumbered formats
> 'Implementations that support audio MUST support the MP3 
> audio format (with a MIME type of "audio/mpeg").'
> 
> I would propose to make MP3 optional, and make OGG VORBIS 
> ("audio/x-vorbis") a MUST
> 
> Proposed wording:
> 'Implementations that support audio MUST support the OGG 
> Vorbis format (with a MIME type of "audio/x-vorbis"), and 
> might support the MP3 audio format (with a MIME type of "audio/mpeg")'

I agree we have to change from MUST under IETF IP policy.

'Might' is not standards speak. 

What is the advantage to requiring support for a particular format? There is
none on the CA side since the CA can opt to only include a particular format
(Wave for example).

On the client side the format may well be set by other considerations, i.e.
if I am going to put a sound in the cert it is proabably because the format
is already supported on the platform, I can't see someone implementing Ogg
on an MP3 player just to play the cert jingles...


		Phill


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8N4qC423289 for ietf-pkix-bks; Sun, 22 Sep 2002 21:52:12 -0700 (PDT)
Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8N4qBv23285 for <[e-mail]>; Sun, 22 Sep 2002 21:52:11 -0700 (PDT)
Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id g8N42bu17419 for <[e-mail]>; Sun, 22 Sep 2002 21:02:38 -0700 (PDT)
Received: from THAYES-PC ([10.169.192.42]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H2VK6X00.ILK for <[e-mail]>; Sun, 22 Sep 2002 21:52:09 -0700 
Date: Sun, 22 Sep 2002 21:52:07 -0700
From: [e-mail] (Terry Hayes)
Subject: Questions on Authority/Subject Key Identifiers
To: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: Netscape Messenger M9 (powered by Photon [20020917.1])
Organization: Netscape Communications Corp.
MIME-Version: 1.0
Content-Type: TEXT/HTML; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: [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>

I have some questions about the use of the authority key identifier and sub=
ject
key identifier fields during the construction of certificate paths. The PKI=
X
RFC is clear that these extensions do not have a role during the path valid=
ation
phase, however there seem to be ambiguities in how they should be used to
build the path. =A0These gray areas may lead to interoperability problems w=
hen
application software fails to build (or rejects) a certain certificate path=
.<br>
<br>
Let me say that some of these questions assume certificates may not follow
the PKIX profile as written. =A0In particular, these situations assume that
key identifier extensions may be missing, where they are required by the
profile. These questions apply when software is allowing a broader range
of certificates than described by the PKIX profile.<br>
<br>
1) =A0Assume an authority key identifier extension with a populated keyIden=
tifier
is present in a certificate. Should a corresponding subject key identifier
field be REQUIRED in the issuer's certificate? =A0That is, should candidate
certificates for the issuer be rejected because the subject key identifier
is missing?<br>
<br>
2) Assume that both the keyIdentifier and issuer name/serial number fields
of the authority key identifier are present in a certificate. =A0Should bot=
h
values match the issuer's certificate? =A0Would it make sense to use a cert=
ificate
for the issuer that matches keyIdentifier fields, even though it doesn't
match the issuer name/serial number values?<br>
<br>
3) Assume that a self-issued certificate (matching subject and issuer names=
)
contains only a subject key identifier extension (the authority key identif=
ier
is omitted as suggested in the RFC). Is it reasonable to assume this certif=
icate
is self signed, and terminate the construction of the path?<br>
<br>
I would appreciate your thoughts on these situations.<br>
<br>
Terry Hayes<br>
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[e-mail]">t=
[e-mail]</a><br>
<br>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8MJP1h29142 for ietf-pkix-bks; Sun, 22 Sep 2002 12:25:01 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8MJP0v29137 for <[e-mail]>; Sun, 22 Sep 2002 12:25:00 -0700 (PDT)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 22 Sep 2002 12:24:58 -0700
Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 22 Sep 2002 12:24:58 -0700
Received: from RED-MSG-10.redmond.corp.microsoft.com ([157.54.12.47]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 22 Sep 2002 12:24:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: Comments on (draft-ietf-pkix-logotypes-05.txt)
Date: Sun, 22 Sep 2002 12:24:57 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on (draft-ietf-pkix-logotypes-05.txt)
thread-index: AcJf01o9osRPCjdZTsutM7cBvQSpzgCmkqFg
From: "David Cross" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 22 Sep 2002 19:24:57.0752 (UTC) FILETIME=[BCC10980:01C2626D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g8MJP1v29138
Sender: [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>

I hate to re-visit this late in the game, but...

I would like to strongly propose the following:

Section 3 - Support for the audio format should be optional for clients.
Again, this is a matter of practical implementation and I would like to
esnure that clients and compliant CA MAY support the audio file
logotype.

Section 4.1 - The indirect addressing scheme should be optional for
clients.  The indirect adressing schema MAY be supported by clients and
compliant CA.  I am afraid that unless pre-caching is performed by
clients, this option will not be practical to implement.

Section 7 - Security considerations.  Clients especially should be
cognizant that the URI of a logotype may point to an unusually large
binary object or contain executable code.  Clients MAY impose
constraints on the size or time to download a particular logotype.

Regards,
 
David B. Cross


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, September 19, 2002 4:47 AM
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-05.txt


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:
Logotypes in
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-05.txt
	Pages		: 19
	Date		: 2002-9-18
	
This document specifies a certificate extension for including logotypes
in public key certificates and attribute certificates. Please send
comments on this document to the [e-mail] mailing list.

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



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8MGYh020079 for ietf-pkix-bks; Sun, 22 Sep 2002 09:34:43 -0700 (PDT)
Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8MGYev20067 for <[e-mail]>; Sun, 22 Sep 2002 09:34:42 -0700 (PDT)
Received: from fwd06.sul.t-online.de  by mailout02.sul.t-online.com with smtp  id 17t9gg-0008Hl-02; Sun, 22 Sep 2002 18:34:26 +0200
Received: from mailbag.de (520021154063-0001@[217.0.88.251]) by fmrl06.sul.t-online.com with esmtp id 17t9gQ-2AcoXAC; Sun, 22 Sep 2002 18:34:10 +0200
Message-ID: <[e-mail]>
Date: Sun, 22 Sep 2002 18:33:37 +0200
From: David Maurus <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Comments to draft-ietf-pkix-logotypes-05.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [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>

Two comments to the current draft:

*** 3rd paragraph on page 7: There's a typo
"...Compliant application MUST display and play more just one (or none) of the images and one (or none) of the audio sequences at the same time."

Presumably this should be "display and play just one", or perhaps "display and play more than just one" ?


*** 4th paragraph on page 9: Unfortunate use of patent-encumbered formats
'Implementations that support audio MUST support the MP3 audio format (with a MIME type of "audio/mpeg").'

I would propose to make MP3 optional, and make OGG VORBIS ("audio/x-vorbis") a MUST

Proposed wording:
'Implementations that support audio MUST support the OGG Vorbis format (with a MIME type of "audio/x-vorbis"), and might support the MP3 audio format (with a MIME type of "audio/mpeg")'

The reasoning behind my proposal is that otherwise
=> Selling any software capable of playing this extension would be subject to mp3 licensing terms, i.e. would require obtaining a license from Thomson.
=> While currently, Thomson does not charge licensing fees for *freely* distributed player software, this might change in the future. This would make it illegal to use free / Open Source software supporting the logo extension without having a license from Thomson.
=> Selling hardware (Personal Trusted Devices?) playing logotype-audio would be commercially unattractive 

Ogg Vorbis is considered patent free, offers better quality than mp3 according to recent studies, and is available in numerous free implementations and as source code with a BSD style license.

Best Regards,
David




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8LEEeL26404 for ietf-pkix-bks; Sat, 21 Sep 2002 07:14:40 -0700 (PDT)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LEEck26397 for <[e-mail]>; Sat, 21 Sep 2002 07:14:38 -0700 (PDT)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id g8LEEdJn023752 for <[e-mail]>; Sat, 21 Sep 2002 10:14:39 -0400 (EDT)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id g8LEEd7n000943 for <[e-mail]>; Sat, 21 Sep 2002 10:14:39 -0400 (EDT)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id g8LEEdCV000942 for [e-mail]; Sat, 21 Sep 2002 10:14:39 -0400 (EDT)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
To: [e-mail]
Subject: Note that 3 documents are in Last Call
Message-ID: <[e-mail]>
Date: Sat, 21 Sep 2002 10:14:39 -0400 (EDT)
From: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Originating-IP: 141.156.180.214
Sender: [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>

Folks,

Just a reminder and a bit of an explanation.  There are now three documents in 
WG Last Call within PKIX:  Wireless LAN extension, Policy Requirements for 
TSAs, and Logotypes.

In the past I have staggered WG Last Call, rather than pound the group with 
multiple documents.  However, it is not clear that this strategy has increased 
the quality or auntity of document reviews. In an effort to clear as many of 
the mature documents as possible from our queue before Atlanta, I am initiating 
Last Call whenever a document is ready.

Note that Last Call can be extended.  I will not close Last Call for a document 
if it is being actively discussed on the list.  However, silence will be 
considered acceptance.

Thanks,

Tim Polk


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8LE7fb25425 for ietf-pkix-bks; Sat, 21 Sep 2002 07:07:41 -0700 (PDT)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LE7dk25419 for <[e-mail]>; Sat, 21 Sep 2002 07:07:39 -0700 (PDT)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id g8LE7eJn022580 for <[e-mail]>; Sat, 21 Sep 2002 10:07:40 -0400 (EDT)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id g8LE7d7n000905 for <[e-mail]>; Sat, 21 Sep 2002 10:07:39 -0400 (EDT)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id g8LE7dh2000904 for [e-mail]; Sat, 21 Sep 2002 10:07:39 -0400 (EDT)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
To: [e-mail]
Subject: WG Last Call: Logotypes
Message-ID: <[e-mail]>
Date: Sat, 21 Sep 2002 10:07:39 -0400 (EDT)
From: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Originating-IP: 141.156.180.214
Sender: [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>

This email initiates working group Last Call For "Internet X.509 Public Key 
Infrastructure: Logotypes in X.509 certificates", which is available at 

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

Working Group Last Call will complete on or after October 5, 2002.  This 
document would be recommended as a standards track document.



Received: by above.proper.com (8.11.6/8.11.3) id g8LDxRG25025 for ietf-pkix-bks; Sat, 21 Sep 2002 06:59:27 -0700 (PDT)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LDxPk25019 for <[e-mail]>; Sat, 21 Sep 2002 06:59:25 -0700 (PDT)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id g8LDxLJn021341 for <[e-mail]>; Sat, 21 Sep 2002 09:59:21 -0400 (EDT)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id g8LDxK7n000888 for <[e-mail]>; Sat, 21 Sep 2002 09:59:20 -0400 (EDT)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id g8LDxKBC000887 for [e-mail]; Sat, 21 Sep 2002 09:59:20 -0400 (EDT)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
To: [e-mail]
Subject: WG Last Call: Policy Requirements for TSAs
Message-ID: <[e-mail]>
Date: Sat, 21 Sep 2002 09:59:20 -0400 (EDT)
From: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Originating-IP: 141.156.180.214
Sender: [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>

This email initiates Working Group Last Call for the Internet-Draft "Policy 
Requirements for Time-Stamping Authorities", available at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-02.txt.

Last Call will close on or after October 5, 2002.  Assuming successful 
completion of Last Call, this document will be recommended for the 
Informational track.

Note that Working Group Last Call is *optional* for Informational Track 
documents.  However, other topics have dominated the mailing list over the last 
year.  To ensure that the maximum number WG members review this document, we 
have chosen to have a Last Call.

Thanks,

Tim POlk


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KJRXO03290 for ietf-pkix-bks; Fri, 20 Sep 2002 12:27:33 -0700 (PDT)
Received: from bosgeo2.geotrust.com (bosgeo2.geotrust.com [208.59.15.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KJRWk03286 for <[e-mail]>; Fri, 20 Sep 2002 12:27:32 -0700 (PDT)
Received: by bosgeo2.boston.geotrust.com with Internet Mail Service (5.5.2653.19) id <PLXK98Y6>; Fri, 20 Sep 2002 15:27:29 -0400
Message-ID: <[e-mail]>
From: Mike Rowan <[e-mail]>
To: "'Hallam-Baker, Phillip'" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, Mike Rowan <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, Mike Rowan <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 15:27:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_001E_01C260BA.37675E60"; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [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>

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C260BA.37675E60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Good idea, signing makes sense.

- Michael 

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[e-mail]] 
Sent: Friday, September 20, 2002 3:18 PM
To: Tony Bartoletti; Mike Rowan; 'Ambarish Malpani'; Mike Rowan;
'[e-mail]'
Subject: RE: formularze (INFECTED)


Perhaps if we all signed our mail with S/MIME?

	Phill

> -----Original Message-----
> From: Tony Bartoletti [mailto:[e-mail]]
> Sent: Friday, September 20, 2002 3:07 PM
> To: Mike Rowan; 'Ambarish Malpani'; Mike Rowan; '[e-mail]'
> Subject: RE: formularze (INFECTED)
> 
> 
> 
> All,
> 
> Our laboratory announced yesterday a change in virus-firewall
> protocol.  Upon detecting an incoming infected email, they 
> will simply 
> "cleanse" the mail, and no longer generate separate automatic 
> notification 
> to the intended recipient, nor generate any reply to the (apparent) 
> sender.  This is due to the Klez virus infestation, which 
> spoofs sender 
> addresses by gleaning them from the address books of infected victims.
> 
> What a world.
> 
> Cheers! ____tony____
> 
> At 02:21 PM 9/20/2002 -0400, Mike Rowan wrote:
> 
> >Thanks for the response Ambarish.  As I am sure you know the
> message was
> >sent as a notification to the list.  And, you have gone the
> extra mile to
> >track this.
> >
> >- Michael
> 
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIILDCCAnow
ggHjoAMCAQICARcwDQYJKoZIhvcNAQEFBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTAyMDQxODE1MjkzN1oXDTIwMDQxMzE1MjkzN1owTjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdl
b1RydXN0IEluYy4xJzAlBgNVBAMTHkdlb1RydXN0IFRydWUgQ3JlZGVudGlhbHMgQ0EgMjCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAspcspZISpYX/aJqWoYcSyyGqFby3OvsepRzLRU0ENDJR
wJo7DwFpirRFOUQkTkKXsY6BQzX/CeCRrn9i4ny5gcXuI2JSyrSmDwobbwl52n5cPEbHGcebybWd
KfAf8vvkxYUnTmDZPtt2ob5RNpJTeTiq9MpNCB/5G7Ocr1hEljcCAwEAAaNjMGEwDgYDVR0PAQH/
BAQDAgHGMB0GA1UdDgQWBBQig0tNIAIMMfR8WrAaTRXIeF0RSTAPBgNVHRMBAf8EBTADAQH/MB8G
A1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA0GCSqGSIb3DQEBBQUAA4GBACmw3z+sLsLS
fAfdECQJPfiZFzJzSPQKLwY7vHnNWH2lAKYECbtAFHBpdyhSPkrj3KghXeIJnKyMFjsK6xd1k1Yu
wMXrauUH+HIDuZUg4okBwQbhBTqjjEdo/cCHILQsaLeU2kM+n5KKrpb0uvrHrocGffRMrWhz9zYB
lxoq0/EEMIICgjCCAeugAwIBAgIBBDANBgkqhkiG9w0BAQQFADBTMQswCQYDVQQGEwJVUzEcMBoG
A1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1c2lu
ZXNzIENBLTEwHhcNOTkwNjIxMDQwMDAwWhcNMjAwNjIxMDQwMDAwWjBTMQswCQYDVQQGEwJVUzEc
MBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1
c2luZXNzIENBLTEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM4vGbwXt3fek6lfWg0XTzQa
DJj0ItlZ1MRoRvC0NcWFAyDGr0WlIVFFQesWWDYyb+JQYmT5/VGcqiTZ9J2DKocKIdMSODRsjQBu
WqDZQu4aIZX5UkxVWsUPOE9G+m34LjXWHXzr4vCwdYDIqROsvojvOm6rXyo4YgKwEnv+j6YDAgMB
AAGjZjBkMBEGCWCGSAGG+EIBAQQEAwIABzAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFEp4
MlIR21kWNl7fwRQ2QGpHfEyhMB0GA1UdDgQWBBRKeDJSEdtZFjZe38EUNkBqR3xMoTANBgkqhkiG
9w0BAQQFAAOBgQB1W6ibAxHm6VZMzfmpTMANmvPMZWnmJXbMWbfWVMMdzZmsGd20hdXgPfxiIKeE
S1hl8eL5lSE/9dR+WB5Hh1Q+WKG1tfgq73HnvMP2sUlG4tega+VWeponmHxGYhTnyfxuAxJ5gDgd
SIKN/Bf+KpYrtWKmpj29f5JZzVoqgrI3eTCCAyQwggKNoAMCAQICAxAAEzANBgkqhkiG9w0BAQQF
ADBOMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1
c3QgVHJ1ZSBDcmVkZW50aWFscyBDQSAyMB4XDTAyMDYxMjIyMDYyNFoXDTAzMDYyNjIyMDYyNFow
ggEWMT8wPQYDVQQLEzZDUFMgdGVybXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZSBsaWFiaWxp
dHkgbGltaXRlZC4xPjA8BgNVBAsTNVNlZSBQdWJsaWMgUy9NSU1FIENQUyB3d3cuZ2VvdHJ1c3Qu
Y29tL3Jlc291cmNlcy9DUFMuMSswKQYDVQQLEyJQaG9uZSBWYWxpZGF0aW9uIC0gMSg3ODEpIDI2
My00MTI0MSgwJgYDVQQLEx9FbWFpbCBhbmQgcGhvbmUgdmFsaWRhdGVkIG9ubHkuMRkwFwYDVQQD
ExBNaWNoYWVsIEouIFJvd2FuMSEwHwYJKoZIhvcNAQkBFhJtaWtlckBnZW90cnVzdC5jb20wgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM6BaCBBQBqcnpp0LM89OWMrqcCnPvRpoVDseFZftumy
VpsXK1wZp4XMObd2V+Z41V8r02ZphVK5yjX3cRus8E0F94HaUAL0h3zcHM6+A0H6wBFtSGJFULEk
oFNMbTe/11vGInVHeUGoCuCjwlXZWSF5bRJMMpE5Ju98PVB3CamjAgMBAAGjRjBEMBEGCWCGSAGG
+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUIoNLTSACDDH0fFqwGk0VyHhd
EUkwDQYJKoZIhvcNAQEEBQADgYEAdQDuv7gXW1h+Rdj1cQK8nDOo1y3a30au/zCA1mruPZ1bHC6v
ieoV6j+HrhS2bpJNpXntYWCjY/tbmH0iT4T/PBDBgYo+1yEetmKsyYT28A52hCdBBoRE7M/Iw0i4
9IVPADhQWRBVlaoLSjYTHqsrxCLP/s9ahASRQhQiBzXc7K4xggKTMIICjwIBATBVME4xCzAJBgNV
BAYTAlVTMRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMScwJQYDVQQDEx5HZW9UcnVzdCBUcnVlIENy
ZWRlbnRpYWxzIENBIDICAxAAEzAJBgUrDgMCGgUAoIIBlDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA5MjAxOTI3MjJaMCMGCSqGSIb3DQEJBDEWBBRN4lWrhDmJ
Kgk5t4k0kTjYl7IKnjBkBgkrBgEEAYI3EAQxVzBVME4xCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1H
ZW9UcnVzdCBJbmMuMScwJQYDVQQDEx5HZW9UcnVzdCBUcnVlIENyZWRlbnRpYWxzIENBIDICAxAA
EzBmBgsqhkiG9w0BCRACCzFXoFUwTjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IElu
Yy4xJzAlBgNVBAMTHkdlb1RydXN0IFRydWUgQ3JlZGVudGlhbHMgQ0EgMgIDEAATMGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwBwYFKw4DAhowDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIGA
SGRYBHydi8xzt7Qm9AxPFbjcd4uMJRqIZ1775r+DrFj4Nv2uNEma9wZAw3ouEjYvOFMGl3OzAc6g
7nSyHvsDeyiX97TBn6ulbXc5IfGvJ2OWy6vlWUw94FFNCkx6RdWyTfKdk6QfIsD81LZd7/BzRzZR
ZmIkk3FnqKdS1K43LxIAAAAAAAA=

------=_NextPart_000_001E_01C260BA.37675E60--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KJG4U02829 for ietf-pkix-bks; Fri, 20 Sep 2002 12:16:04 -0700 (PDT)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KJG2k02824 for <[e-mail]>; Fri, 20 Sep 2002 12:16:02 -0700 (PDT)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g8KJFvLl021178; Fri, 20 Sep 2002 12:15:58 -0700 (PDT)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id <S780JKFZ>; Fri, 20 Sep 2002 12:17:57 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: Tony Bartoletti <[e-mail]>, Mike Rowan <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, Mike Rowan <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 12:17:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C260B8.DA26CCA0"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [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>

This is a multi-part message in MIME format.

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

Perhaps if we all signed our mail with S/MIME?

	Phill

> -----Original Message-----
> From: Tony Bartoletti [mailto:[e-mail]]
> Sent: Friday, September 20, 2002 3:07 PM
> To: Mike Rowan; 'Ambarish Malpani'; Mike Rowan; '[e-mail]'
> Subject: RE: formularze (INFECTED)
> 
> 
> 
> All,
> 
> Our laboratory announced yesterday a change in virus-firewall 
> protocol.  Upon detecting an incoming infected email, they 
> will simply 
> "cleanse" the mail, and no longer generate separate automatic 
> notification 
> to the intended recipient, nor generate any reply to the (apparent) 
> sender.  This is due to the Klez virus infestation, which 
> spoofs sender 
> addresses by gleaning them from the address books of infected victims.
> 
> What a world.
> 
> Cheers! ____tony____
> 
> At 02:21 PM 9/20/2002 -0400, Mike Rowan wrote:
> 
> >Thanks for the response Ambarish.  As I am sure you know the 
> message was
> >sent as a notification to the list.  And, you have gone the 
> extra mile to
> >track this.
> >
> >- Michael
> 
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ
da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw
MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu
LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1
81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL
tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC
AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp
c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud
DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK
+gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK
D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/
H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa
BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkyMDE5
MTczNlowIwYJKoZIhvcNAQkEMRYEFHbokRP091ck7anlLNQHDSS1QZtKMFgGCSqGSIb3DQEJDzFL
MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG
BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug
aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj
KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO
rwvJMA0GCSqGSIb3DQEBAQUABIGAm8D74RiacSAkWqjWRErSbkR/shhDRdNweI3J3YdWal5AWncN
NRPb6NcwmhNWZPqeYF3fCMgEX7rgAbFBYGSKhD58Kfg5w8b1Wy0tjdgTR//o5EV2L8i2FcbV86a5
bP0tCCBO6fUStjR0p5WsQY7Ao9dtBuwAbkkqetYDfwGfChAAAAAAAAA=

------=_NextPart_000_0000_01C260B8.DA26CCA0--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KJ2sX02250 for ietf-pkix-bks; Fri, 20 Sep 2002 12:02:54 -0700 (PDT)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KJ2rk02245 for <[e-mail]>; Fri, 20 Sep 2002 12:02:53 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id MAA23771; Fri, 20 Sep 2002 12:02:42 -0700 (PDT)
Received: from [128.115.222.68] (HELO catalyst2b.llnl.gov) by poptop.llnl.gov (CommuniGate Pro SMTP 3.5.9) with ESMTP id 2113024; Fri, 20 Sep 2002 12:02:19 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 20 Sep 2002 12:07:12 -0700
To: Mike Rowan <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, Mike Rowan <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: formularze (INFECTED)
In-Reply-To: <[e-mail] otrust.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

All,

Our laboratory announced yesterday a change in virus-firewall 
protocol.  Upon detecting an incoming infected email, they will simply 
"cleanse" the mail, and no longer generate separate automatic notification 
to the intended recipient, nor generate any reply to the (apparent) 
sender.  This is due to the Klez virus infestation, which spoofs sender 
addresses by gleaning them from the address books of infected victims.

What a world.

Cheers! ____tony____

At 02:21 PM 9/20/2002 -0400, Mike Rowan wrote:

>Thanks for the response Ambarish.  As I am sure you know the message was
>sent as a notification to the list.  And, you have gone the extra mile to
>track this.
>
>- Michael




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KILfl27834 for ietf-pkix-bks; Fri, 20 Sep 2002 11:21:41 -0700 (PDT)
Received: from bosgeo2.geotrust.com (bosgeo2.geotrust.com [208.59.15.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KILdk27828 for <[e-mail]>; Fri, 20 Sep 2002 11:21:39 -0700 (PDT)
Received: by bosgeo2.boston.geotrust.com with Internet Mail Service (5.5.2653.19) id <PLXK98QH>; Fri, 20 Sep 2002 14:21:08 -0400
Message-ID: <[e-mail]>
From: Mike Rowan <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, Mike Rowan <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 14:21:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [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>

Thanks for the response Ambarish.  As I am sure you know the message was
sent as a notification to the list.  And, you have gone the extra mile to
track this.

- Michael 

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Friday, September 20, 2002 2:06 PM
To: Mike Rowan; [e-mail]
Subject: RE: formularze (INFECTED)



Hi Mike,
    The mail was a spam. Came from somewhere in Poland. Wasn't sent by me.
Just claims to be sent by me.


Here is a mail I got from Paul (Hoffman):

-------------Begin included mail - including my message to Paul----

>Do you have easy access to the orginal mail you received. I want to 
>know whether the mail actually originated from ValiCert or somebody is 
>just spoofing the name.

I don't have them, but you can see for yourself that it was relayed through
a system in .pl. It's clearly a worm/virus.

The mail log entry says:

Sep 20 07:04:30 above sendmail[12331]: g8KE4Tk12331:
from=<[e-mail]
>, size=39749, class=0, nrcpts=1, 
>msgid=<[e-mail].
com>, proto=SMTP, daemon=MTA25, relay=robot.unizeto.pl [217.153.69.1]

--Paul Hoffman, Director
--Internet Mail Consortium

----------------End Inclusion-------------------------------

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]On Behalf Of Mike Rowan
> Sent: Friday, September 20, 2002 9:13 AM
> To: 'ambarish'; '[e-mail]'
> Subject: RE: formularze (INFECTED)
>
>
>
> Please protect your system with a virus protection engine, these are 
> readily available today.  Below is the information sent in your post 
> to this list. Thank you.
>
> Sender of the infected attachment:  ambarish
> Subject of the message:  formularze
> One or more attachments were quarantined.
>   Attachment formularze.mpg
> .pif was Quarantined for the following reasons:
>     Virus W32.Yaha.F@mm was found.
>
> Michael J. Rowan
> Director, Product Management
> Enterprise Security Services
> GeoTrust, Inc.
> 781.263.4124 (direct)
> 401.952.1240 (mobile)
>
> [e-mail]
> www.geotrust.com
>
>
> -----Original Message-----
> From: ambarish [mailto:[e-mail]]
> Sent: Sunday, September 01, 2002 12:05 PM
> To: [e-mail]
> Subject: formularze
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KHuQd26417 for ietf-pkix-bks; Fri, 20 Sep 2002 10:56:26 -0700 (PDT)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KHuPk26412 for <[e-mail]>; Fri, 20 Sep 2002 10:56:25 -0700 (PDT)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id g8KHuIGk017941; Fri, 20 Sep 2002 10:56:18 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Mike Rowan" <[e-mail]>, <[e-mail]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 11:05:59 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [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>

Hi Mike,
    The mail was a spam. Came from somewhere in Poland. Wasn't
sent by me. Just claims to be sent by me.


Here is a mail I got from Paul (Hoffman):

-------------Begin included mail - including my message to Paul----

>Do you have easy access to the orginal mail you received. I
>want to know whether the mail actually originated from
>ValiCert or somebody is just spoofing the name.

I don't have them, but you can see for yourself that it was relayed
through a system in .pl. It's clearly a worm/virus.

The mail log entry says:

Sep 20 07:04:30 above sendmail[12331]: g8KE4Tk12331:
from=<[e-mail]
>, size=39749, class=0, nrcpts=1,
>msgid=<[e-mail].
com>, proto=SMTP, daemon=MTA25, relay=robot.unizeto.pl [217.153.69.1]

--Paul Hoffman, Director
--Internet Mail Consortium

----------------End Inclusion-------------------------------

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Mike Rowan
> Sent: Friday, September 20, 2002 9:13 AM
> To: 'ambarish'; '[e-mail]'
> Subject: RE: formularze (INFECTED)
>
>
>
> Please protect your system with a virus protection engine, these
> are readily
> available today.  Below is the information sent in your post to this list.
> Thank you.
>
> Sender of the infected attachment:  ambarish
> Subject of the message:  formularze
> One or more attachments were quarantined.
>   Attachment formularze.mpg
> .pif was Quarantined for the following reasons:
>     Virus W32.Yaha.F@mm was found.
>
> Michael J. Rowan
> Director, Product Management
> Enterprise Security Services
> GeoTrust, Inc.
> 781.263.4124 (direct)
> 401.952.1240 (mobile)
>
> [e-mail]
> www.geotrust.com
>
>
> -----Original Message-----
> From: ambarish [mailto:[e-mail]]
> Sent: Sunday, September 01, 2002 12:05 PM
> To: [e-mail]
> Subject: formularze
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KHjpf26102 for ietf-pkix-bks; Fri, 20 Sep 2002 10:45:51 -0700 (PDT)
Received: from bosgeo2.geotrust.com (bosgeo2.geotrust.com [208.59.15.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KHjok26098 for <[e-mail]>; Fri, 20 Sep 2002 10:45:50 -0700 (PDT)
Received: by bosgeo2.boston.geotrust.com with Internet Mail Service (5.5.2653.19) id <PLXK98KT>; Fri, 20 Sep 2002 13:45:18 -0400
Message-ID: <[e-mail]>
From: Mike Rowan <[e-mail]>
To: "'Hallam-Baker, Phillip'" <[e-mail]>, "'ambarish'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 13:45:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [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>

If you will notice the reply was addressed no one person in particular,
instead was a reply to all.  The message came from someone having post
access to this list.  No need to point fingers nor brag about our virus
knowledge.  The purpose is to post a general message of concern.  No harm
done.

- Michael 

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[e-mail]] 
Sent: Friday, September 20, 2002 1:32 PM
To: 'Mike Rowan'; 'ambarish'; '[e-mail]'
Subject: RE: formularze (INFECTED)


Hang on, before getting onto Ambarish, remember that the latest and greatest
strategy of viruses has been to fake the sender ID so that the infected host
is not known.

In some cases the virus causes the infected host to send messages from A
claiming to be from B and vice versa so that two people with completely
uninfected systems are bombarding each other with complaints about viruses.


Paul's mailer does not forward the original headers, proper.com being one of
his hosts so I can't trace the mail.


Received: from mail.imc.org (robot.unizeto.pl [217.153.69.1])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8KE4Tk12331
	for <[e-mail]>; Fri, 20 Sep 2002 07:04:29 -0700 (PDT)
Message-Id: <[e-mail]>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KHUbw25611 for ietf-pkix-bks; Fri, 20 Sep 2002 10:30:37 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KHUak25607 for <[e-mail]>; Fri, 20 Sep 2002 10:30:36 -0700 (PDT)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8KHUV9M002178; Fri, 20 Sep 2002 10:30:31 -0700 (PDT)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <SLCPNP3P>; Fri, 20 Sep 2002 10:32:27 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Mike Rowan'" <[e-mail]>, "'ambarish'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 10:32:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

Hang on, before getting onto Ambarish, remember that the latest and greatest
strategy of viruses has been to fake the sender ID so that the infected host
is not known.

In some cases the virus causes the infected host to send messages from A
claiming to be from B and vice versa so that two people with completely
uninfected systems are bombarding each other with complaints about viruses.


Paul's mailer does not forward the original headers, proper.com being one of
his hosts so I can't trace the mail.


Received: from mail.imc.org (robot.unizeto.pl [217.153.69.1])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8KE4Tk12331
	for <[e-mail]>; Fri, 20 Sep 2002 07:04:29 -0700 (PDT)
Message-Id: <[e-mail]>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KGDTO21291 for ietf-pkix-bks; Fri, 20 Sep 2002 09:13:29 -0700 (PDT)
Received: from bosgeo2.geotrust.com (bosgeo2.geotrust.com [208.59.15.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KGDSk21287 for <[e-mail]>; Fri, 20 Sep 2002 09:13:28 -0700 (PDT)
Received: by bosgeo2.boston.geotrust.com with Internet Mail Service (5.5.2653.19) id <PLXK976M>; Fri, 20 Sep 2002 12:12:55 -0400
Message-ID: <[e-mail]>
From: Mike Rowan <[e-mail]>
To: "'ambarish'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 12:12:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [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>

Please protect your system with a virus protection engine, these are readily
available today.  Below is the information sent in your post to this list.
Thank you.

Sender of the infected attachment:  ambarish
Subject of the message:  formularze
One or more attachments were quarantined.
  Attachment formularze.mpg
.pif was Quarantined for the following reasons:
    Virus W32.Yaha.F@mm was found.

Michael J. Rowan
Director, Product Management
Enterprise Security Services
GeoTrust, Inc.
781.263.4124 (direct)
401.952.1240 (mobile)

[e-mail]
www.geotrust.com


-----Original Message-----
From: ambarish [mailto:[e-mail]] 
Sent: Sunday, September 01, 2002 12:05 PM
To: [e-mail]
Subject: formularze



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KE4VN12335 for ietf-pkix-bks; Fri, 20 Sep 2002 07:04:31 -0700 (PDT)
Received: from mail.imc.org (robot.unizeto.pl [217.153.69.1]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8KE4Tk12331 for <[e-mail]>; Fri, 20 Sep 2002 07:04:29 -0700 (PDT)
Message-Id: <[e-mail]>
From: ambarish<[e-mail]>
To: [e-mail]
Subject: formularze
Date: Fri,20 Sep 2002 16:04:31 PM
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=sxcxpcc
Sender: [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>

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

<HTML><HEAD></HEAD><BODY>
<FONT></FONT>
http://www.eforms.com/content/Eform_Companies.html
http://www.formatta.com
http://www.pureedge.com
http://www.beachtech.com
http://www.conciseforms.com
http://www.itmassoc.com
http://www.webbase.com
http://www.quask.com
http://www.primarysoftware.com
http://www.atforms.com
http://www.am<BR>.<BR>.<BR><BR></BODY></HTML>

--sxcxpcc
Content-Type: application/octet-stream;
	name=formularze.mpg                                                                                                                                                                                                                            .pif
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="formularze.mpg                                                                                                                                                                                                                            .pif"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAABXZioCEwdEURMHRFETB0RRkBtKUR4HRFH7GE5RCQdEURMHRFEQB0RRcRhX
UR4HRFETB0VRkAdEUfsYT1EWB0RRqwFCURIHRFFSaWNoEwdEUQAAAAAAAAAAUEUAAEwBAwC+0QI9
AAAAAAAAAADgAA8BCwEGAABgAAAAEAAAAOAAAABLAQAA8AAAAFABAAAAQAAAEAAAAAIAAAQAAAAA
AAAABAAAAAAAAAAAYAEAAAQAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA
AAAYVwEApAEAAABQAQAYBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAuLi4wAAAAAADgAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgLi4uMQAAAAAA
YAAAAPAAAABeAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAABQAQAACgAAAGIAAAAA
AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAkLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLiAkCgAuLi4hDAkCCVblYQe3/adfWykBAPdaAAAAAAEAJgMAm337
//+LRCQEi8iKEITSdA2A8r2IEYpRAUEMdfPDkP///48AVleLfCQMvvzQQACLBlBX6AMAVvyDxAiF
wHUT8l/+/4PGBIH+sNFAAHzlX7gBAF7DXzPAXsOQt7fdB4HsIBpTVUdowNMq/xW7u//d5KBJ2IXb
iVwkGA+EQhyLNegTaLDft993HlP/1micB4v4CYvoaIQLiW227e1sJCgNhf+JqhQxCYXta3fLswcB
wPl4aNAHBJo127+9V4eL8JwEhfaJdCQcGuWNpvseuzQQUB9W/9cvwBSL++9d+zPtwegCEFQQD46r
FN6LC1FqS9q3p3v/Dx+m7PBJdHSNVH72trXvRSRSagRQQwwwNHRfiwe7+Xb/JI1MJCxoBIZRUhck
R418E7e7X3iDyf8G8q730Uk2LFFQTKihYXMjLL9CD00SUkZhs20vdAlyVm7wg8dP371uZP/YEfiA
nEWDwwQ7vq5h++gPjF//AIszi9pW63w8/Gbr6VNbEF9eXVuBxGjDhe/WLG8oVVRqAmTYRD/3ZOGD
/f8KggTHAyBQVYa30H0d0n9kax196Alpxr499L6nDjRadwi7F4wYUB/XEQUMuobL2NvTBcoQEGAQ
dusYeVHMJ66dW1XPnDDOdl2kKB9kAwvurYudDIK8JIAOsD/tuobuAA8Aa9z/aDGAVizU4XPPzgwH
MMwH0A0ogO7cz8ItCIQkeDyFFI2UrWvd1yaEiwtSR6hRI1zYNJgEuxgQUjgAoPDPUIiqOoPDiy0A
lnXf20uNhDpFIDTVLK5waxYUByBShBgYTT7bkGcrNAIk/B0U4bHQ4RiG/ieFVsqywdxh0/VF1EHV
NCdD9okPwZREjA35LI9Qi0RRUlDm3uywV8fNIJKOp7PwYY/np4P4AvKtY4PsPawhsKqELnUNjlVe
NWAdUqkNQTUE6VjVyyCXfPu5d5yYINaD6AXGtEVRVyexdzaYNldjvz03hdO9p1YEuA4yBAswCbEM
cSt0TL2MALKMUR8QAe3t1Y14CG4MR7hoWNQt13U0TQICDGFk4hgity7sQhwjaEwaSVwAoWzL3TUw
FmjEDtZgIAvf/SmWr0ufmbkJlPf5ixSVnJMO4XDMQALWWBBdQ8t1jYAiBIwBbDCFIFu7aA2AUNBg
Qx3MtrkjJx1TEkyzPVuXO4UQYywnnPjCJr11xnzxdRJTEWC3nu1YAQRXKqDo5XUGR/en21fpnQZk
ejPJM/bQQxB99/e3B3Yqi9WB6sSB+Sk9cxqKhAr3f2/3DotdiIEJKEE7yHLeVcYPL7+Vj2OY6+t0
v/AFsCA7e/vvbyoUc1SKlC4OgPo6fAUEQH4KCbNvf3N6fTB/FDrQdCAIDXUmRlHIdsn3R0HrHQ8L
DQqRwsKePQJGR4t8pnHiEBZeIYfuUVNUwQ7zkN+wl6wAWXKdgiYOZ05ccQ7hEF57A8NGBNf40Ax+
OdNScAmOhXp2M3FXZGEGg23wCW1XB+RADrBWF1ZNyc5hpVcrF7yfMyedAKlYsBJo3mVPjqxLmKGk
AlhrZ2bApEAUV5A9sJkcZ1Sv0R1s1GymM6qBaAVkJTDMA66F/d6Vmg22/XPECYXSfjWJOBQU+uaN
He5rFooXiP8XjVSJh2ALHVBO/Ugxeq1J+HXPVYYc4t+Z3WXr1lYCV7kQw75outmDNet45vOlpOkT
MM6RkMrtksCTkaUTdyQR31aJyQnLi+hVoFZ+POHrxKgRVY9Q/yG85ewZIJ6HflcagVxgoBZGmtDF
U3Qkgk7ttwycJfnnIXmKBFgT//8WRsHgCDv1fQsz24ocFgPDbhQStf+3A4vQFPoSg+I/ilQUeIgX
Drv5HrINDFcBDgaD4D83K/DdXxOKRAQXAohHA34DBP0mfn89jUUBO/AKAj3xQYP5E3U1a2fhcNsQ
G8bbyEPTme4KB4HxSFDnWmuYcDRQU9yZKMBe9gubLRVBhclrxkSMKABFHBjABjWLrww9zWALVDVS
ZwdDpC7cUJk2aQZLOJBRlPpELGTpWxJQU1D1Bo8Or09+/3QEEnAG3qsKxwV8RhrPdqYT+rhMG6rM
7EnICe9DBV5XM/+4z4k9L8Bg5BKp/KEQLFwyt3NMG59oG94AohvflP0793UjvQxXTQLeQv9zrCTY
g/v/dQ2wxafvnm7NImPk33AIHzvHdQ/xH+TSahl8DKLrBA+/QAhmx/Hv2MCY1GaFHotWDGoQiwKb
oQs9R1IsCIn2ohDHLmSRoljQYAt3f3IPplh2FCXNCkyhgNf1ZnLZ0m90D4vtIO16UHgj1xA7xSkQ
w6kWSP0FInhs4G6m7Dn0Hg6l2CjknuG1V8S7GO3aP+Z0SDmsgIl1P5wzGxbchBss18OKHw6EZrvm
UkQa4N+Z3het6V4sJCbGAk72EbZO1yykh3UOg7ywvlfeIlSFOwFy+1VpvtjDFnVLUm1QjEGY4y18
jnlmI+G64nDBgFCIvs4d62t2D2i8O194ILRoJLPtC1HHLXQn1Tci32s+fBlhUlak323P5lgtqh+c
39V2KLvYOdKjJt9AXBM2HbXh7zR8JQzrUKlkGxZLMGdn65EqPGSwc/QUDTjNY+7szK5wfEJWdxTT
dLYZwGNsWrivCmfkYN+kUZ+6oS1CPS4QeC0Yosdpe/XbTEi0nFcdnWNG1VMjtFxwagVLyBlyUbxs
hvnIJTOjeH5mZffSpAF8aoKOH1rGdnHotUwhcg6w1SXIF/6PpHkFSIPI/kAB/v7//+h25VFk3k8N
Xaj4h4Bh5rlw6MFQcGyYmd78H+stUwwJM/7AAXUjRytMhjQYlh8usCZIKBQCLSWUSyZ7M29mlUDd
2CUNksQUZGqQjAcyYSNRZpRSPF0sIV9euDgFWQjh8V4qB+HAoTjpBQ85yDfND5ZoaDDeQIAI8OtG
oMjgIBRqSgkEvd6bPOmQIDNYZV25NZloLNFAC5Q7nDwX8lJoFGyETIvBprlQUVQQ3l3zuVOyp7AI
hnlRNCMD9hVRIATWilxoxoWLEuZ1LMjDvmbAkyE24N/JAHZgGVcAnr0ZLw5O0g743Www18WlWGxj
JFAgWBu/ty8gg/+SaIzIQx42MHvs3XAb5CGbE2zf62Lc3Y/sLDYvJFKc6zJ2tmRz6mOUUXCgC2SH
RLcdsYNkTQZ814xYqXNYm3DPdicZS3Jo6ViEIJKCTSBQIJEPjJWxy6xYDMnIL2ZOY0zdAEt2lb1o
0DyYxQl52RkYLPzcvOQF2eTcpLMLyNwP4RKSRTAnsNywF8ghmIzcr2ySiJx43ElAMpMDe8CfuWgx
iwwCaQYbMD5gfgwswrcW7qIiIQ9hXxCE2+PkZEyIDkjbjP2zJCMRmlG8pJk5kFDaZpPCygXTFR1Z
AZiQXhYZ5O6E2gAs2QTyJh94IA5ADghmVAVM2nMhh+wtbFzLRDx7KbAt+5r0HiQXMoE8NJBXUqyu
lyTaUNIB5G4U2tY8jK7feCDrEQoPO8zZyAnhhETZKwjZ2aEETpTYF4TXIM3oJkNIgRIgK+yBlyTr
FQ8S/BsJvMiQ1jtaO3KBbAwDioSHFWAXfEpArEAOWA5k1lmrsk5/pjGGPiV0I2CLDIW0TWGDdAlj
JMsPrzkIBs5Uoic41kJ2kwkskjIdIGGKVK+wOZoc9sIdMwJ0KzUk4i3jkNMTbxuyIDBIOVukZZML
ORwQ+EJOctgorwCYIA/jskST1etfp8jV7CXkITIds9DkwkK2tNCMnunMt2DASLSBMMQAjEVPPMzR
Mw2EUv1RsNU4kM7gDbwjV4zAbED8mMFeV+QAEodArITVAfmSLfkoVxIOsJB0eagWMiHwaNXzwMIi
CB3G37FdyCUxT3xMKbYyknf2EYIihL0rRIwgWMhV9kuDPEIOWJziAPzcJCYTcuTcyJ4nEnIKENWF
lAo5YP741K6k2ZA0PLz8BCxpZUwT1sgBgyTM4/TUdoCQHA2ILQcIyRQDy/IQUknvStzUEQKnUMVd
zY2keMgI5RJq5JBBk2AF3AiEK040hHbUsCJlD34sxKxoBHzUMIqVXVaAFDQNrHhaHxjxUpRTBDAH
ait1DykO7FFXzFdmFIv4YcGRPddWzFKLNaSn45wwPIQgZbgggQGT0BmSZg8w3+sGUVIumawRvkm8
DBGLkELxBECCydMwvLwDkCDSkPO0A7mSATmEUIzCUtgbtFrlWrOZzo0eDxwFIDXBECm9qaQLpHhZ
cVFWajLJWfspLKLY6RcJ2drJJJNM29zdZDB3M97GBd8FLtCRSSaZ0dLTVANwkNQnjJtQRiRYclvg
L13TdJjuyHhqD7F0xnA+1U33/wiUXlnDH6wFV1gRoThCLSFHqjwAAUICR/JIKiAEBJSyeciuBcnY
6agF0OkOOesFdEbcA/xDviZ8uNGpdzIjdsSThJTGLgzgCBu5si8Q63JFDFEYEV8OOQf4FIUIybvs
IJOGBZDIFBNzgTxPDowMyADwT/XxGGjs/oT4M/+JPeTMEu2frSZMOT0U6wr4Bg7/x85P9xGNBJKN
DICNFE3oC2KBvsE5oRlI0xin41vuK4zBArseU6YkIZRgdhWEkK6JcmQLGZoeNhdNwAQrGAX+HeWg
2AEoXje9/ZEv3EzB3oNTi1UAQFBSYAmnA5LmB91edMAejbSLRLlPdzdM1ExSAnA8BXb8U1JOYFPC
86X8UBEKbPvd55aFUDT6jRuDxQSB/cyNCmvRgh9sv29CWyzZa7ZvUzzADJBNUHoSDEEJeIFAHvb8
R6jcfen+2PgrfXaNLIVMDCusBfqNMN0gh8r8kAD4aHwyBBGAlcoxvSjsDr9+db1/dBQPu4bg/RJA
hDvBA3yxweGskBczB/INw7fu7bwdwzJJHBgiD45E/aB7ix6mBNdoD48gEeMrSICqe8KFfx4IQc9A
BTP2V4mTHFiPNYWDLdb2SA6MAdrVmAMemku6EoMo1TwCuZJL1UOQIawX84BvwmpVgtR9BcCwEHt4
LDb69avwEEmFyXenu3xkU2QUDIJp6i4IytgGhsEvBCg1FMxC48EljUOcKB5YoQHyMCxSUEI+OxdG
HC6EQIHDWSofL+EDEKR5wxwknhBQQAUBcEKIDQz/FAItZQhmj5BPEQvEAR6uHy4cu4HYIg+A8PQQ
QQQgl0s03CgBFOCUkaUgiCAcBM+BAOMEVMGBJyeDUvihsYYmAU/tV2eavzOAQph9FR2L2LgB3BqX
tzvTCBSjy218+9HGpRNtfWyZfCMHbhJwewV9YRx9PqDCz2J0hRsnTdX9QkJGf/tYA/SJCo0ciYpi
E4D5O4iMW9bt3l7nXlZ1vh9AXA0Bt/Z9icaETh0Ae1x8mhfCYWCMLT9EPCN4MDtWuljg4BQMAq8Q
ygWHxqxGP80QritiN6NTDkDsuizKBFVXUyDIeHxUjiAQ9OW/TZxOgYPI/e5kgYgQAyucNxbw8DBS
aQyhLHkZH7iudeh7JFSuDMCd0QRnjDJpWFO52RJPzFCeEKcCMlEhyZ0FMAEekHbLD/7Mc0jg0xSN
R5zDY20We5bpFV0qNHSugXh6KmQTMozAGt6L3BDh1mLbYQm5IC9Sa2QCH5t4ahOBx9dCkB8suMMD
JBBH2hPKgSwc6V9diQpbXqJENx4ZpM55D77CMmJ/fHoHsBUUfusyD8gAVpvNnb9ikuAz2yz5fnSL
XqTprIygBYhVd7e5izWEPbcldQNTn6wi3Juv4THcVYkdsC6G4sZLjhZq/NTgNr0RipvgFcihPawt
XnvbgCcoVtAab0D7ERzbRrwFuOnlo8AHgyHbHaPEBmioOTwkvoWmYQNOpFV8BT4CF2MnHX7MjBhR
udtXKMz7q1NVHczZwLU16w9sTL7gTj4egZiQMCS35D68scxwPYowLAPTdF1XMPc0BzgDPEA128hd
RCNIpOBMV7yhvZcO4ITsxHUmobdXa/xrssRTVlNTuwMQeh//2pAFNmoI/9f3g/nGfqUlWjW+L6G8
NLhz/NpPK9BVUhdBK9H8PuPE7ORAUz2j9e8d4aboUKPMsjCgQEu29r1nOaPIVhtRQh40F+vpRRNM
KHocuW3Hsq2YAMxgU3knBZubJgopJLVqutY7uwVEwKE2f0UssxXACiCzQDKADQZ8KBgGnhJm+mf/
M8mK6olJFLmybyCKisrB4QgZRKfge3Yj0XILwrk8JXOwwsO4PMJ8gS1oAQY7sqYqVBBYT0axXcBO
8g6gTBoW6S5l+IP+D3wE7An6DxVQG+jY3BA9UCZML2ABdQvLHytgvAKI92YDZRxhCdgVaxDd8GNW
UIaU4SdUahNokKaP/p+ZEdrAwlKZg+IHA8LB+AM8YQT4yiA+OGEYSMF0ll7c6c3z70uGB4M9grB1
L7gm12A9U0lTKQzMGb+NMXO0HC2s/IjZi3cIWQmDMBfyBA51297IAJCGprvug+xUglzjCDDh7hM+
z2JkdgwMGAkHFOifjQx32w+HsQY2g/gg07bw0ndOk4vISTxJuxBEA9wWDNgM+yUwMN0EpYRFVMIQ
ziW/Zcer1KESItyht3+htkuByy7/dAmD6QRSvQJrJcshAajEcxVbxXxkJ0Wic/GjvXG7+hquaGxi
YBSK4DRRVTALUkN513QUwC3pPZZVFD0VbCGLleUqPypTOv0P7lyvaHWgTUN4lDGk6cBKSuxMzDnp
pFgMTqFAUCshUwg65BQISe9shBjQT7Kwn5Buu4r6MYraweMIEekxu5Q/C9qFTD8jOZILKDDkQiaS
NCgokaaZ5CwsKDwFz9edPA1CBEFHiCGpbGJARVVngKQzJ1VHaA7jYZZo1e0njXiL35USEYP5B3dt
/2zoQEB8HNzDVnVVpJuVocQv4Hqgj3jIeQL32eueBRw3iKzCD9g+NjLeeAp/HvQKfiGGTJq6kR0I
GExkz2CzlXAGhU3iZ9gnt90zG5Blhg4+A8tAsrmE3rJACxd/lDDqeMEogFfBKSOzlPeYxBmQT0e/
oMzhDOLB7JBXNAtRkK8sppQkrEbDIoLFqsHQs6F4uSKhROEQFVulTCPLoUhEF4+Kzs8oPYAczEzd
DbXUQCNlJx0UjVCyYJN9SlAWUTMt6WhYRYeLlEHNCSEPGFYjVpJzN4lDzpnk7BAFCfX24uduJvfG
BfgFEDEMGH1Ssaz/8A9BO1oRo4UD4uZes4ohG2YYAQjCudB7z9XeHAGQC2v4ziDTAlkcT4C+Q3P7
CIxPECgYvc48BBqd2WLlxh3UIUBhFOidUAQ2iy1f91qPOTwqYRAWVHQ0CyoLFhgxng7onwMMFn8z
uZNQig90ajxhfgo8ejANn/t9BgTgiBKvV5kE3S3Q91EnBAEUOQQgiLZDhvMMhMxrIxgPLl1gOJw9
AAwOdWfNjZGKJYQZgp5LrpoNlgxWpzEDxWH12HQIBwR1U/4IXGjACE5DJnvHiojd/10BOhZ1HITJ
dBSKUAEMVgH00u2X4sACg8YCE3XgTusFG42iobhS2P+BV6YrvNmIALo0g8cDgD9flga7fYpHAUd7
dfgHiPtfXz1ZgM8DcASInGiHQ+wkeASZ6kqdPNkZvqZs5QccZCBckydPniRUKFAsSOGAx8kwQBR7
jugRtnrADuKtOIsxoBPRXcBoLAxSXI2HPLfcQAM0+IOqfTQ193RVaBwkK25EWBAwIMOBMjxVcxVM
R5f3HIM4/iZmnF2IQAJx2T46RIYvUeMdVKONoiNOwvEHLCY2wsCHVVgTToV5Ev1wBIKZzXzHgWgM
BGxopLBgzJpkEMRbFiNpWT6PPzaDR8MIAwxw6qLKPXSHH3L/XwBLHa8OeMPqEoXCHKy0LXKfoLMC
rdFA+YZH9FT+8GZPR91I0VBW6OTcQAff2NSrqWZ2zxEkhF4Ivw1++nQLjUb87TWs63QGHItO2yAL
wBBRFjRHKSBmFR38O/hy0uucHqhgDHP1xlTeylDHMHEyX0IIZt61dqBeOCh9K5kWmcmd2xXXWJwt
DhVqLtS20SAOkF8ESCHBJRpgo/9eLys6wDkUBGM4sQwoD8jigcEEHh54ExeS7BERcFnaTQ42BvLA
1lIcKLYl8Hq8mdY8JGXBY+YVNBeZHnilaGVQ1lDOgJ5J8FZ929QOZgOMFLTlog1qVrVEUSgTuDHH
iwWnNLLrfAo4A/QYoCQ+N2gTHFFDUjZsdTIZXKgOHiRE8q4NMahvgHT30VBJUoLuhhmBVv8cLmi4
zzugFHUQgd72dYTLimZQbeosZBJOsEt04QSQPEUTi+hDSkaYKv1BiDZSctLBFK8clHBCTghU42Oz
SHLkZAIkAoRATiC8lBJnLAMphJk7KBU0Z0jxTMk4AuhVRq8jDHEoXCIcF3g1MhKICL7hJl10ZBOT
MCRAtMGhI0I9GqCLcLoyQsH4NMDPuYQtDOOjVSEarzKEEdxRUgcGagvxUwBE2zYXLMFAOFI4bxjW
HbxL1Gg5ajtQPnUQDShWzLQbhIGbgRj/a0UyYuEwfeP5cjJkLCRRMzA1NC+HDCQ4Vf/WJMaA4JYQ
RFSa2XChITVDSFNRPjTICAYemM6FMdhjGIJFvf6IABoeETiT/6WPjAWHc3RFJqsW6IFwcFSSioV1
46Spse4Y+wD4qeRDdSYcj7gHR63JGBCfvynfl2A6jKSJKJyTDrNwEnQQAQRqh61Oz8AFUH4fxDwU
XTBw9WyueGOE7p3VvBlKKBMU31WYYNk/jZNwm5tYmYe0LNMkNogGMglQJ6pD9Q2xw3g3uQE4kFGs
BG3U/x1ARFIr+YvBi/eL+sHpAkU3qd8/yIPhA/OkRpNE57r/WLFEg+oDxgQQZPhEsBhQu22xFTJS
FghhEdl+073QBEN0HXiAfAR3XHTNTLOIPFAYUe55cuwXwKzjBzCkNJw6TZ48OJQ8jC/Hd0OFfJks
iwZuUtiSzS5KfKqIA4TjhPOrwwlOfAMM38KEuxf0gIT/BXy6opoLCBEW4+h0ZkA+BFmQULOokTnW
kUPyRS1qzL1XV0YAmCwotihd8kKiT7gHUytql0C/GJpkii2JGlNRLTkhwOlzeFx4AhyCdQLIBtcJ
U8jnA1jEBngCjAhZbljT5M8FylC940xhGwDcy3wBD4a2BVy/dFYSAAxvv46P3Ki+D1NPWVx8g8PA
MsGFEGoQU4IGeG6Ge2eL+zVpe1WjBaPNcHNyUXR40DCdGoB7lPoC1uenDFE9clIB2XLwM7czUHqh
KlFNYEM7dBlMDTpggm3HsyHIAtWxKNQYa2GQEt4tbn/IUko6VATf2vDSpNNjq+zetcLkEg0gjmAD
tTiWdErtuPsZlxxga3TVI6pGlqiKAjxHJflAFBx1FFuCkVS9qRaERc6a5BnqVy3+S1SDIMh+Y4pm
YYpeYnUL/wOmD75+ZMHj78mMWAjFY9/hik5gC9jCUgvZxUfyUW8ZnFCMbpDk5CRkAlHRXAIFFnVG
WIP+yDjkbAHVg8fB4AQD7Zsb6AQCQo6KAFBDuPHwAHq0Gv734gPeweoGHxDTFdt3r7pVGPfZEYPB
AojoLIAXbwDCRH7xlwcDRttlcLSKLBkATAelFJc0aTpmmMbKV9Mo3R68A9NWEVZESEZ1JAcStJNW
MOBRRlhoUYQSQEjo21JvvwIJYMlYuNk0E0ZPEBhkAnDRkCcg5EDZ+FzCABJpYcPBYEACiB0aehz4
ekPlPQqnEmyFW7AcSzXwWS+caPVMPC5FKywUdAVe3EFvBBB1B2RS6zNB3axpqii4yCr+HG9xc9h0
Di4LdAaFDtTrDprBRnVYTEVWcq5w2IsGZqzimwc8Im2PtH4CBiZkK1GALnpMPhXj4aIaX2XeYPAe
ww481pj4JgXBIXMKVcMjF79qRCy/yRtksC9SapCBUL34h4xM2W2MUZSzMaAlk0whQ85mEWptUigg
bBDmlnqFseDCv0zvBPOJZ9Vz/h+oV1XmoQ1c4ZyUEid01g/REf0UaDDkVQqRKHcaMKrkQhw+Ij4E
AQPJlISW8lXNnQsvjngUbJNoB3wP2LIYINhAwtsSsosTS2/kDEgCPYHfLCooi9Fyyk+raM2dK8op
sCvDexWf3kJORfzDDo1RfpTkSAy9lFV4Q4i5f8Glku8Fq9JI5q5SH3H4ACGLhGwgUambMAcSvekE
JTORcAkFKUzOJdOdpr8UShzGRdNIAHBXlyDIBoAIaNSAUHBfQH4UD4TEfLMQ+yxiX75kD4yqGTmD
6GQkH8gWgPooGHUScIEckFYUAxewQ/FaJCY4KziSCxASHAEcDpALDHokICS5QkYcMCGLZAA+PsXN
Ak1xALubv0DkwOL7hDeNDC5oElE6G2xxaWepLgY7Bok86Xb3rSJoiEQMIBABQUYNdfLSHRBo7sYR
vsk3UCCZi2KnPFqBTHUxmWBM5tXcBfmiVClSEOsBRkno5FgkjGkYgZrUWQAGV4uBjIBgq1QPnQAu
kDXWzXGYsVXCGAfeeyDNswnF/7zvZCqYMCrAKEYUBmQK2QlVUxuBcQbJwhnWDS45ecmUUv+EUC65
5ECMUZTKSAZNWA2EDLfkjH0NZ6PFaAkH/QmpXzD6kEiNFC5EElLI0gwYCXkHB+Nv8P8iPCB0Hjw/
dBo8J/o8PHQSPD4dhMTkId6NROdHJyPNNRwoKEWS5yNJPRtEUCaJZjkYV1XkFMahWUkvVBvIJ4AE
vyBZPAWRYlXpMDLBoZ3VS3Am1MFFk8meao1gkofLOAHXreBNiAmE6jULJuHrDtMmAtTVoE4ITcLQ
1po8AbM3oUnXlkgxQQjGD83TM//B0Jl5MMBXV9jLgBUoJOlqMUzgaELXduYUUL405mF9tHA66lCn
U/lGTcGJ6+IxcOrQ3/4z7YH9/FM7fVM7+H0tglS5gqbEVD5+11jUqHwTExdHRoiEDDjHKeCGOzw7
i54n3Mp9Q4uVRoPFMokHmDv4mnDMvBQ3BFx8pWeLT0GQHCFI/pqcnZp+fFuNWQFHHEsRPpDo5Rbm
agR+zlb3GRoc9H4a5clXnsBTBxcjNsxWx3OtL03GMkt1VERWCy7RzdBJB5SwSHQcAR18f3ducP+D
/gF8dgRhopy7ej9wYgq7AiCIjVf0jyzRzlcgCCs73n8ZK/NY3b5v4UaNeDJ0Tgp19LD/ul+5NLBJ
TmUYQoPHMkPuBvtjQUP/O8Z+t4UccUE7zlQHwIeSfoqoQqbBNZsJ3hVgLPfogsCL/hhcLPbenVvS
QNMSLBDkTcSER8B1zeVCR8AIOMS907kxHtbD/6AFQBBoRsAjoE6XkbHNKljoMqBUOz4W+YsN/MLc
rOQW1IglOEowHEjZ5ACiM0UdCmYEnn2CC3iAIlBmFF8RcIyAmGoQfwTcyIicVwyGDFJWvQnsPBiX
oZbWH6cuoWh0Wo5oUOT2T9CMSLNwMwvgdqzbpIv5qX4gbSh9tR2L16ErKyRA0r8U8CPNSwPYO998
5srG0oHeFI08KQRD0SDdN9cfKxNUUgzSfCPOGBcTRFAhIEGPdehWp32PrBpZuX/AAyugfBDY/DGE
azDB2Jf8z4owKRkSIk0cr4qV8xsJ8OAB9yz+60W72P+p9uoDgpB8IcQCA/ns0zQRaPArM5i93hQq
cxRIrDpLBcccP0EHXi3bpTkkOPBVVJcoUvcmSxF3HCRTfdewjDEWBwsyHOtkv+5jy+IYSQ6KVAwm
Esyb62UQiBX+FkQMJ78HdgByLqL4HEwMumEG4CiIDYM5RSlIbpTZOPf1iACBIAtRiIgykCIHRLGr
YGxW5YwmNuQJWAbxziiIcTBNDfzco9lzJheM+VQKz02KyG9OkAF/gvIn6lSGioQEh2xmYJBciBxz
FHOy7r+D6gJRigQQGhWOvuCdNWAKuisAHBLiFcgC5hB1GPNh5Ovu1LmMUJgpXKoX8jDyHOIaamwI
5UDMzAT9BHE+EaoAHO4LE9HiBaGI2KzEQCJM/fjxvYRI8kU1xBrWiH3tsxR9AcynS1wRTs/mFgbI
QUzksNy7B9/ZfehT0M0cwKBFPARjF7wbo43NrcLGupTGDa7Vx7bAvaERmUQyHXzgNreKYCbIDMjm
rZuHZMImEwSFkFDobiG5kL8FdAjJTsmEfJitCFzLnJILeXEtcMw5JRfySgm0zHNKLuQjAtjMZEom
5PysA/R8bots1SZ0OM2urHlOyYQNLMKH8pySCwbkwmDkOSUXB0zBOdhzSi4gTNASJkc7glwrWz/s
V+Qhm928CUosOWw8DCInu0ZcC0I8ABqbh5kGJAScBny2yFbkiq/HGLx06uRAZdbvg2oPU9kZ/Wzf
dD1woI4GCpKMvYCmM3D26pEimHQDUOJS5mrJyFIQFxxEksvMVW9mQI0s3XV0B1dNcJT3iuboNNME
rQgOkhHfVQRXy2Om6c8GexBowCcJQtSeDEd27zM8Nawzn9AFBwaRUqVRMM02s/30y9T/yHVtG4sC
CbAnVufqAkYC3kIe7Ovjv3D5oPVpktRoiLLEGDGI8NQ7CB8vHIA30h0A4gQYjmhWXRl21u4BDgR6
vBCb1ymAjMEb0xxqUmLttsgFKeVHCOVNCxDhLN2RiQLgCBSPOnEQboH5ClTwW1WaxchSzP7/KFde
j1wZn3hoMHWWnWxmEB8UcvTkL/SEEDPag/vs0I10YTBXddL7cdNd2s++BAfViUAET3XkIYsGf+zg
CsRK4Bbv65WQ/yU5MrK54A4F3NiYoRCwZuSUnMwAE4Wj3ygIV1NWihFCBC3+439pinEBhPZ0T4v3
LIoHRjjQUNwIvreEqAuKBgoK7/Ve//82WrQEwxDwdeuNfv+KYQKE5HTd/R2UKFo44HXEikEDMRiK
Zti1d0s2wRB03+uxLzSKwn2lum85WKKNR/8MwxQF/670LqLJhFrTWcNmDNhEtJsIWxRZDRCjMLHf
/m2ew6EFacD9QxkFw54mABXW0UKJweRqf7bMAOwaqhdRPRyN1XIUH/vdUN5n3i0QhQEXc+wryB1+
o9uLxAyL4UCLQARQw7hLxAXI+SRU51R+Rm/5/g8PtgdqCFCEdusO4gcbEN1Ib4qp4PoVL3T7A0fr
0hU3RzQti+4Oa/S+bf4rdQQPSEMMs4cVIlVAC6E8+/dvlnAEDY0Em41cRtAw68+D/ULYqRJxw3Xs
hci1rr09jUL/Co2kJKvFZAZtmYAG9CtDwZEJuKN9kAj3wud+1sS/WIoKQjjZdNHdURJ17QvY+Lcl
2srD6lYIiwq///7+fhYL/6ZpM8sD8AP5g/GL8ITF7VLwzzPGrYHhpQGBbhHntxolBnTTToHm/A0v
nFS9Xl9b3YtC/DjYdDame8M3x+843HQn3+fB6BASFXvWbprcBtTrli2xQv430jsnnQb9/M/rh9z/
9uxXVr5NEOMmi9mLfQiQCcbt3+rZA8u8i3UM86aKRpbJOhLudiH+dwR0BElJ4cFbO8nDN8Nl0xvc
aCiioxx2ZKEQW8TW+1BkiSUHRFiaiWH6z9Zl6JHE0orUiRU4+XIb4FLS4f+UDTQN3c52AecDygow
u6MsbLl+2Acz9ppk4VkHqBybtt1/ea9ZiXX8CGM2TVgdozhjN56IFrhifhQRCV+91Da7twRe/lwg
K55FpFAv/D+zKowWpolFnPZF0AEQD7dFoKm3LwNqClgddZxWeGD+W3YGkCNOnKAIXE2LRew9jtA7
eQmJTZhkXSLprG7j28d1mB5eQhxyAaIWrYN0ZvAbZymC1xvCXDlA5S8kWSV+BQ8FQ8NmhfZ+pebX
BO5oula7gmjl3FN33UFew0s1ABXVVKMOSObWDw18En6DfOPbwV7gdyJdW0BAWXUWOYrmeA62dBAT
cMXeK2x9v1s7OzXCSncLcGwQGhz2t4VGqQ4B1MYPg+bwVnNR4eFcXOFRDmlDtbFiSIP5qncMaaBw
qTBGautSyRu99OdYDsH5CC3R9kS9gGz/S/1edA6AZf79TfyIRf1qAusJDf2eRXy7RfxjWI1NCqpQ
jRY4AtUQ3HDgexy1NzQa5wJNmgojRQwIg/iBa+/CHAvIRgP0q4GjZvfh3XbpKzUFZB33dRQDCWpy
7H7hA9NbGqE0Eb0CgzsbNGE1wAS9wJCv1QhCDgB2DadoT8EhDBBcb98m5FkMAVcPXzk9aExGhw3D
dRFysPA3UK3BdwyLR4k9ZM4KfHciiB1gKDwEgyJr8O8WJCwJVo1x/DvwchMCl3z/FT6D7gSAInPt
XmgYlBSWfBeGzGggEBwZse8tj1t1EHqJhjNItgvCX8eqcw1XUosIN1fr7atAMLuCzYbaXmMPhLWL
WPSrJooI9RXg+wXmoNu9y4NgCOpY6SRgxyQvNNzm9gANbGHvdE0MiTq24WMLi0gEg9OFyB3Y5/b/
rgkI3AUD0VY7yn0VjTRJK9EEGtzB7rVoEoMm2AxKdYvb0tUux+TnKo7AacfA3gW9BQwW63A9kBJ+
BuRngV09kYRKPZMG5GdAhTc9jYLnZ0B+JD2PhhE9kil6p5MKimCIXN+lWKvTNwpO6wj6UUrE63AR
z6PjpWqz0Tad/0nrTFtdXavZmr0E7OA5FgVW/k/3nrh07etgwAw7xnMEORC83/YlX40MSV4DjRU7
wRJkuWQqiWX2KBYAqMTLdHYvHadzUKAFFiAlQwEozYZLI5oRLMBQp3IpdPFtu9DmRnWAPiENBwo8
IHZ3XXsrsQwgd/o0KAQP6YvGAu8GC9tTuTkdWlFuv1qwW1r4M/8nOsOtP32Bjz10AUfVdzxZjeUS
ptjgAevoxL2dJW7hDSKRWTvzCUgxfwtPA1EJigc9QTgfdN2+Uew5VVc5sFlFgD9JIlVCyxaONDvD
PAYuO/btjt82eExZblkD/Td1yV3/hCV+zyIaiR0LiR4n9QhwC4ckqX4E7pWNQFG9vnArw0jQ4Nt3
2qEpW9s/tqJYfP44GHSz+CT4G+3vWChTU59gUIsPoPzWqIZt2IjUkdbXhk26oQgvJyRsOxp2hlBW
NVIUSFpALQbdzZyjPAZbu0yU2g22GBwUpIMhcmpyxBpLl31UtSBtUCyZnHc3+onhJVi4FIA4m0Sd
QID6vrRfaGgpfiW+0vaC4RNH/gY2Sg49AcEGihCIFkZApWNHxgvV684MBIAdFhm7vUZAHOtDHgUE
92/J20BE2vaDGRiIHkZlBcpbcyB0CQkICXXMnhuFYo1Iu0qqgGWyQSwVPThB4GPb97VEKwUnA17x
F8iv/QMzvItVFP8Cx9DX3xfaCoUiXAhAQ+v3kiwQ9Ebj9sMBlkE5fRhW4ta+VngBIo3jHYvCHjf9
RgnDCAyxGBgPlMKJhX63vwXR64vTS4WTDkOIxgYdtA9Bb7FLdfORSoM/S23zbVUKij90Og9ndDBh
wLouKBniBh82NyCcGw9AAxUBQH1tCLuQYTwwDw4KCTK02scDg52j+SZulFr7oEmhdAIWgtNE1ERJ
9oaButHAqHUzegtL9T3XdBYh7evTPDkzC5uhO/sX6hsCs1WgnV5i4bPggd1ssw5DDD8nwmY5Hn32
ditz60BACBh1+QbyK8ZG29gtL0BO0fiOQAJd+tITtQN41zU763QygNYBSzISIxwVrhQ0aA8lh2BS
91AODBAnM0vws3UDVp5Qw+tT+XUqncy1TKWFsXQ8YP+2W5R8DkA4e/sE9ivHQGqFJW1qVc6q+w5G
KjW6uvW8szxyfbZXPUjG64mtla+KXyHsRK8AmjQVhjplMhtaLphYFSDtGCAWIDZu8D7Nhim0cxpt
BHfp/Va2xkYFCqEj9QgFG8QJHeDr4uhbZo0R1NEJQnXFr0TfS5+t6Qu5MI3cuAAISo1l7t/uHC58
djk1Y31SvyRMj8d+9oEAOIN/iQeNiH7Bc7ZYluYYgGAIQIuZwGeOsY34wXzk1Ul8WyFWgruaCfvR
ftb4G+hGiwPLNopNAPbBAX4EFyIL8Ah1C8I40MeLtWBjq8+OBY0fudC9RevPIVwLiQgviBp/BG3r
R8D+fLpQlHiBz+w82P/y2HVNO7dvlSoAirRq9ljriMNI0G4zQOSN9VgwoUYnO0i5F1dmDCXY1ij9
MD7QBoBOauoKX2J38wN1CgjrBAWAQ3QDfJv/GJDZYrg2NHvgkIvgRMN5u1uD0oM4diBVJFGDQyOj
kDfBIdTxF3xKD6H0alJNPOfDzcPDLNoPaG5Vizx1GQlDHWz6gmRdO4vl3ExD+kEOakEEMsx0D311
Ux09TIkCuJvDm/pH1D6LTv5oRHXN/zXFoZg0AM6EYwfdS4twDIguO9utEv0CJTR2iwyz5G5FF24B
e3yzsnUS99u/7Ysts31l9v9UCOvDZI8FQ1eic46jjOhkZQ/41tL3gXkEaHUOUadSDDlRwcTdW7IF
m4pRu/RYcttWIFgIqWFLAkO/teBb0WsMWVva71ZDMjBY/GtB7kMwMPdu+vyLXQwOS7ENuvdA5NqC
itYctA4yReEQCD4t8V22IXN7CMFhu3a2UP2ysY90RVZVjbpUC77uhe5dXkELxTN4PCVTwCBAY10L
GR1WDGIx2QrNbDZw3o++c922S49VDDsIMBqLNI/rof2OfTX3fRzJ6xVcav/aEGKTP10WlLyV7PYb
O4spi0EcUAMYUCQFXK8MHD+imnfzVg3zKk5E5UAhaPw+GHUdK0qheMxZ8T+Y1SN2YNiB7NFK1Iek
hFUI2qhPbdpyoJELQ0E9/XxVeH+L8ZbxweYDO5YaJjNLw0xBbL3ocGgP3aQNENeo+nVKxaartvGF
XKEPdsiIjHUTFwilQImzsygnWRJXk3s7Fm+9B2JAWWU8dikZgbOzOFB1+A2DR7Oprn1qAwP4WUFX
qXt8Z0M2N1Vg/+ikEFd+yGBjDFwd5Fz/tgyq1Wzm0xYRC7eDDGYFJ7x68VksXxoi5urrJo3YMOw2
06TdhDwIavTdgHC3aCrPXitoQO2GNiUEGpb8FE04m3mhAfIl9BQG+BC4B94co/AUUegFQsBbMjKc
oRhu/qhr7KH8B4jeFGorUAwKLewWWAAkcgecFLHY2GKYy8wcVaVNtkGp4dISGXdxDPxLv8VawcL8
V8Huss6LevxpyQTRjRIdw0uk1IwBtbTUXSuJXfS78IkTjdr/zfkI+HV/wfkEaj9JXwutUmv94s92
AwVME94DXwVfytRI4dggcxy/tvhb30fT741MARXXIXywRP5EKy7YS+11ITlhg8HgHi10OvdgIbyw
xBIkBoxtG664Ubh8VYkKBAK/294IA134DQiMi/vB/wRPGgoY2to/e4ZfsnWaqdvol+xqoEIrpxGu
1VvEoVj4SVpOpj+3te52BYnzykEb+0A+O/qW2m2DdjX6v3RrLsNRkZEB275RvbrqCxa55NIhVBEe
vbGWkA/SIZRMUspytm2/Sb5KCwQIcGGL1hGRvezVCTmFwmujM+6J91iymuvesPkpCyaJLw6KL1vZ
BQiXSmOKTAfdvvu32SCITQ/+wYgLcyWAfQ9GDrsk293giHjT63YJGQ03Yt9KQbEJGOspJONP4ENw
z2IZJVkED51bvOGxhLcJOItURfCJGjsTEw9z6fz/CLP6AHZw2cI9wN+j7A2haAvYNrrB4Q8yDFKA
KdjsgaBAh9cfMh/2HoQcCVAIDjlAEIOd3c3epIhsJA/+SEMKSGyJhhtmeUMTg5L+EQ1ML3GDeJh1
bFMQDYQF3WtaEgkQrhCjAY/0M/I4dqNo9UGLyCgryODTt1qSERKNSBRRinx84/12YLEX/w0vOwUi
NTr92lYKFJY6iQ1MOD8DNJCyrIk1CliQGjzJKmbjk3tXL2hXjTyCLBtIF3Z1R4dp8BdqSTR9DoPH
l4gvktPug03CdfTrECbgLtQAAELT6A6NBvB1JqFpi0F/Lb5d+AhzGYtL4TsjKyP+C89Hu13jFhwU
O5oYcucHdXnbTMj3i9o72CYVBevmGQVocHd1WSRzEYMRbHfIs3MTN+vtJg0bRRuasy/uDghvGbRf
q86BHHSQDspZWxa2DRq3aUOoOGwH697mthvpFEodpRSLFh3eSm36x0oti4yQttvZwy6AkESIN4sS
cBFVUKBVK900vu4G1L4ORAvWiwvtkYQc9N8K5v9F/AS//iM5C9d06YthzSrUl8pKXFiwBt3GTXZM
V84PZuoLQXdqIGRfxQXR4Uer67bbRosgVPlDCit/8Xvjpku8wf4ETl4/fvheO/ebtOkkcw0BJGEg
fSvb0oWAEaJ8OJzT8+xb4Lj7I1yIRIkD/g916oXsaLGB9CEL6zEXK5UVXLvFoTIhGSk2mJNzFIIs
hSIKwNem12V6BPgAla96CJBbg+c2hJQ0qflCDMsAUmulIsJkBloq3Sz+C30pxJkLpbHNNRcRYr+w
zoyw2y7ZCTsKjwl8rusvKOz7kB4NjU62CXsEsbytItcjXRa+7gk3am7pRgUHdQqJA/yyDb/tXXl1
8APRIgESMvyfi6HHb7cOIY15Dz51Gjsd8lEGjUhdSzukBmsivZELEbmNQgQILMCDkwINbxD/LRSA
Gl2WTVBDeio1clCQGFeXUCgFmXzaiC9YDGacwD0K0Mz0wWjEvwhFMN/iyLbdgTNciUZBKmoEaMj2
wVcjaLJXGYgABtI/DHUU/3YQV/z7rbXUtnxOJMWJfgT/BWKxlakWQc6bX8ZHrVlT6W5xyLOjtcVB
pNvFT+BDY+vjRsM3acCBWvswgtDFdhtF6kAIAgS/Ss9269Ye+4XB5995DIsQgGRy0JAALNFLdNXe
J3DAjZcER/rQjY4Gl7ZHd0jyg4h+9Azm3VZf/AbHQPzwQudeqt0O7/+l/8eA6BAUwQ1+0QWZSPCW
dsfdU9V2R08MvmNfJontZWtvrI1KDAiPQWSeREK7bvzDvJ7jikZDisgLhMB6iE5BgTH+Q3UDCXgE
uizLaPGEVsB+atirgBJVyEBfIA+ettEkTn38BL/6O3KBNEulGKGEQLbYgIIw8T695GzVfYFCXlZo
JDNWgoTZ3gKcBP8dGxggJwAsxF4ooM599T5B9lijQ6EkGBx0t64cSQWhoFfG2YIpGosORlAz9vJc
giVyF5Q5XRgZNtsK7qGwKpONUyxBa0A8wCAS4O0O6baZbRg3LB/gVnRjoRda0EI+PEO5AyQv0J2I
/I3Ai2t13Feit+mAU7R/6wv/BBtNUF3Kg9f/ydrstsQpSeBWXxxVMHOtc1IRFNeg7WfBxB3njWXM
liYNh0CNCGMg23JbqUGbOg+2Pt4RhIIG7IKIcnUctNDRDdqhDsNFUuQjDtDxCgdKQAFNEAEmGIpw
Q3N9l8BSbzW8+XVOIj9bM0RKpwlW0rioznJ5U2I5MHRyMELpRjANF4DoUJOAQCS05d4+Q0BjWb/g
gqLobhZ4rOFQ86uq0+QPhu/7T1M/MH3uZrtN74oRhNIMfiF+aq55tkH/MjvCD4eTyzYg9iXHXO5S
L2VYakiuUnHYBKqNKeqF3Z64kYA7e8t0LCot3WJEsoW2+q93b9/uHV38ipKgIAiQRkATdvVBbeBg
4UGAORjUFJMIEBs5vp38BHLBysTMLPXwnktQo6wLTjGs2v2927/AD6WlWaO7petVQHn/zAymukxI
Z0KhsVZfbRM9l3JwOfbay2YsVOsG+gvCCu63sU2rAOsNOR2ICpuCqev7MIEEqksD1toN76EotyUh
Vf6EB9kaIEuI/yV4aktELmz9FGR5D+3Yshi3GUktpF/fLkFtYCL1dBcEDXQMSDZXRNN0A4i4WgUS
LzzPdgsIEVdsWTPAGyHYIKq0F6PFYgT43tzDX4AUjGfgJqBF7FaDIgqrfz8GFjTAvoeIhAXs+YG+
/4KCxnL0ikXyxoUNIPeDbmxxN1PIVWC2CijHGrpA0HcdNbwqQbgqNEG7IACL2WWr3i8AvwmPqkJC
ikL/8tBfWwdBaxDJQ+5QY89eNY16UI1WVtl3xoJvI/0dVh7JyG42VjQjgBT8lkUIWPEn8P+all5c
go1yZosR9sIBdBZvm7+f+hCKlAVkiJDg6xwaAnQQbZA7JyBb9KDhhkbjHIE8AL/rSRWssd0wJUFy
GQRaqktjSzQ6yECYiEkfNycvbx1hchN6dw4g6SDrIdHdsOBMSr5eyYiDXPj1Emr9CGtZ/CgWzAFY
cgBN8mrBh3hDPIv/G1f3wQMWAP6s4YoBQYE7DnXxiwG6NNQAbKUD0JrCMKlAd+sAkMhB/CYj5RyG
C2AaqROzBnnbStx4AuvNv9wNBP7rCIM5ann96wP8xl8ZHexNS9ZBkGSIF0di7utarBFb/RfXZ266
yQrBaU5r4S809sZeAu8n98JpEgdqtmGINsc4xXNmCC2ZKWAIDAiTwV6wiAff3hQiO8SQQJjj4ZKT
5jIkE0E1SSbZHivBwwn+/TAMYJD8zF8BNIAGSGER/H/LXVvRA8Y7/nYIO/gPgnhRd4x1WseMFNWD
4gPrwMS/eHIp86X/JJX3P7oc3uBCwf1yDGYDA8i75lbeF4UgiB6NGJAHnIj6Tdc1MARcA4Aj0YoG
iAetue2FcIhHAQUCVghZ2UnGlsbHXMyNSSt5lmVsJQECAqbk684mkCNGIUc/jJqu6w7/b+wD5Afc
1PybpmnMxLyLRI7kiUSP5NM0TdPo6Ozs8E3TNE3w9PT4+PwBhy0ywY2adN8hbBf4Cf/wIAMsTUCB
10ARo4aQwWYDe50L+REwQ0Jwow0KKzIIm/qNdDFYOfx/JO2z214N/eP8d6CK99nvczIJ541Qio/5
K+u6X+SoiSyQuAvYAwAM190Km20DOm8DTlhPVoRhb8m2Sx+jkG8huu6IAimMJeEtG5AnJKtzbbyy
LQOuRVqrW6bpugtUBlwDZGyMsGmadHyEl4qXHNM0TdMcGBgUFE3TNE0QEAwMCAgTFtI0BAQflrDp
urAFuAPI3IqXYbYE57e1hw+DCWFgCxO3UPz5VDSMEkJoZKWj6ouCUR1njzUQpjhYLMij/J4t8Cl0
oEgQaDQHo5CLet0fetajlAahC7nsD6KRdusOoZQQNKyh9wVTETEYA4Ij0HMyTavr+BtBV79/DFe5
eiTZ9So1QR/3SzYK3tBBJAeLdW/rIXW1uNFpZEdJaTEpzf7Xnh916y0dUYPjA3QNIIGDGtUdLzlo
fK0ZG0LDedE6D9zZZC2aAAvuOmwYRWBW2y76Ksgn8iEnsGOvKgYWg8YySNMM3iweDM5AfHt1xjnr
GIHi9wlihUaaDgAEvlN2v9vW51UKBIkHX3X4sHWF5BVZw6O/yI3z5MgL4IzYjVyNIZDLZfCMHI1A
jSPkAcjIjciN03TdYD+/BqwDpJzA2jRNlIyEfI2/pvvOI8iN8OAD7EkeQNYAjr9gj82RU8gQj2iO
YI94HEgul46YjsCOYI+NQh6BYI9N03WDWxQGHAMkLDQAa9M0PERXj7/TdSeMH3AFeAOIRYQAa5yP
v140ooC/Dg8UidgAQUcrjgoLL4H5g/qBLZnCJeLS9HQIK9HnSYvIQW0wNN8DwQYQys0qdAYWpusa
6zoGI0rSQk6CckQzcOsGEBkc4T24z05wKbh1RlfVW1MwBB1FjGkPcLbyW4g2Ix0j6yIgIIAnwWcb
dDgiAZHgTzo8uDl9FH4QLpPg31RhOFlZiUUUobhUJYEDth0WHLNOm+cTvEhNgaTTfSAszNohIHMu
OSRWjFwSTSCLMq6IAPHkO99f2ME2IcEEG1HEQdzWBgk2OesTSv8mEVuCtzaLOGfcdGas3GFzXbI2
IVf0Tewa0aV3FqVwbdR12LZGX6j89PZFDQQmPhyzmwnYeLIj1X8e2sBsbWQySNKPnfpCmozIx0X8
cmTkF7KzNtyJXeASexdrkO6yfd90tFZkanOnrORndJyPs3Urw9klCusGjFatk6orYt/VQL92cQ5H
hI5XxnF7+0KwwR97Vo1K3Q0l3RLwhexAi/FJBvMMXsy98eN1BStLi8Kx/yVsQgBsriiq/29q+P+u
AGcDcnVudGltZSBlcnJvchXPfiO2VExPU1MNDQraD9hdc0lORw4ARE9NQRLydvvLEVI2MDI4CC0g
R2FibLNv3/50byBpbmlSYWxpeg1oZWFwN/+t/XwnN25vdD0EdWdoIHNwYWNtwN5tI2Z3bG93aThh
BvIUctlvbjc2c3Rk9tvPQDVwdXIrdmlydHUhse23tTOlYyMgYwxsKO02hXxfNF8qZXhcJ3vttS9Y
BtziXzE53c19YfdvcGVYMXNvD2TaZMC2ZXNjKzhGgRDh1iSBZWQZV3Z7SL4jN211bKx0aL8hjOTb
YS9sb2NrF5rbBls0ZLdhLgL2reHWoiFybQBwQGdyYW0geyEUtkptNi8wOU+jGVoKEEEqJxTyuUYs
Lis4PQ/h+2FyZ3Uoc18wMmaLbduuwW5uZ4JvBXQ6EdAKZ61k5n9NLWAY//C2OWYVVmlzqkMrKyBS
nGHuuz1MaWK0cnknCi0WGmfbw0UOIRFQ1Dq+XBt22QAuADzl4CU+y3jbLGtsd24+/92BOza+W+ED
R2V0TGFGQRZ2ZW1n74VQwnVwABMPV6lkWKD/rTqbZXNzYWdlQm94HXNBzxpfOTMyLmQ+RyiRpNh8
rncDC9zgkRmVFYqIHgCQFUV9KvmgM4ZA0NzU0ZFnQP4L0MWPkwCMRka+2Y2PExeMj46zk7H3GyIr
jo5LsD/dkowH3MncjJAUgv3lf9TT39LI09kAzs2Q2sqQiSftftbdF5CNOcVDzdLS0Q7T2G8b+785
2dnP2M7OAMrY30HKAJ0jfth/sNhP2MXe1dzT2thv1dLOyfc6s/0L084E2VjIVBv2N2v+ztjPy9jP
yQknzcjfInx4w9reBxGXPzDA0zRNtzgDREhQWE3TNE1cYGhsdHw0TdM0hJCYpKzTNE3TuMjc5Oym
aZZN9ADBDBAUmaZpmhwoNDxEt8Lb/wD+1dje1p3JBZ3cyQjn0NiPDdjP08nu2NgV2Bb409fYbhjZ
0sQVKfDSzxLZ3eEwZ0f+GtkPg+iNAvc0/MJv2XbZ/7kEAwD11J2B/++DfvxSsPe9A5OTG4LICC+3
B2shZ3qd0tMf+tQNs9a22xjbmUIdh8rwcvn/8uqd/vX4/vad6fX07tXJh5KS67rt3+6TzdzWk9rS
ywfWJ0ireAOv65qmnLwIswwDzMPHysaHAMfczxHUX8nPu7HRtsht8TsexHWd3hrR0N5ctRXbz9SZ
BOqxrfG9LJ3UzhH/YpD7Ft4YsI+dK9YnnV/NzcShuyV76U0A+dLbylVo2+5Zx9HScMnU8ABEZzPe
bRnu3gXTnc7cZFjOYbeFbZXNGUrS1qmwhtuyIy/z2CfcfrLta26CPyQP2i7Zu9r2DVixzpv0INAP
MbKwHVIL8V7Y2DMYPuMUNfPSyRWe8shu323KGc/E0Ogh8MT7Ydnadu7cEZpMQtbkMxsDYWGajtIy
Z9y3Nee2ziDqJEjKxdEdFJZ9wtET6tLKAG22zxViDiBTWul+ztvWNvc0M33fyUHIN9RqhWec1rvv
0nepbRtLV4sV2/Gymi/5VnLOsRHe0T7O5KetEGuNC8TvenbL5Pjc/NoNvfFU6CfOtQrt9YNdLCrv
1o+FhM5vU/HcyNrVQ3HCzDHyisrV8QyCe807K0H05/xhS/hwMjvRqxrNcNveAPZazTXWziC+wmHd
GPvVRMnT29Xe8Xhat9VYMt/c38QdNgnJD13Ok/W2TXYrKRfPzmfyHtp7cySMpTnbJY9uWXtvg8zR
2RqMMxPLJoVsLpxryx5LS2zUJ9GvUVZozLrV+dzvG93OaKYFN81UXYLjH7G5QXY0AzP80Suom/Ae
034TgKrTNM12BMMDHDBIYE3TNE1shJiwyNh0btM07PwIxDMDMNM0TdNEZICYuKZZNk3M7ATFIDCa
pmmaQFRwjKCw65qmacTY8ASPHAOmaZqmNEBMXGCapmmaZGhscHR43zCeaXwAoQvVBcfTwsjQJc+r
yvdBEAMHCybbs48uDa+h4LX+DePez9D2wCM5OKPZ1NLA80ImNHyE1//I0dF5yfcMH0sYixjTF/pG
YHTw8BT/+tzOK512F75GzaPbyFn30jqwZ2rNU5B6AxsLaZrOPWDHxwN0eISmaZqmjJSgqLCapmma
vMDI0NzkNGumaez0GPtjYEyaSEczoyK1tg0d0bPenJqu696ByNvbB1w7aAN0fMIwBWuIS2/0nN6M
WQ/AH2PNeq17gxfOdB9MrFlrgzvKaA4L4W7MMNgLzmqLqGeapmm6uAPI0Njk8Ae2rGn8zssLic0N
MgM6D5YRW9aBudsOP9ELvS0L9t4HHw8oss0MlyPa0Quw0lhsyS9DicjUWOAYWCzUCy6zQsCKDDM8
DHiTBnsLFt7dD3uzYUurMgelE3vLYinzMw4PHQbyA9/Uz9kSLQKxkg92m8WjQIFknbCUFk73grEA
3+t1x9a9x5vFB4YL3+l32MCGC7pHyAtn47a1FxTJIwDa7NglW/YOBDgPkyEWy5YSEyGPLw4mDttb
nSmlIbxhtAuLbDqz0AOLAJ/JA0RpmqZpVGR0fISmaZqmjKCsuMCbpmmayNTg6PgEyjRN0ywUICg0
PNM0TdNIWGh4iE3TNE2UnKiwvMh2TdM03Ojw/E8My9M0TWcDMDxIVJbr/DDj0djJyRu1SiUKjhTF
fkNotY4WP9kUxBRSodFyObDNPZlTe4LhVrbZ21/H2NYghjE7JHcJ89M0ndnHzAMoMDwx2zRNRFBg
aMyDa1vtKnD4ksUC1AcPugJLA8jLzyeoU6/AQZPeYAf3LDgTsQfzBkvM1mKQzifQzSDDNN2HgSE6
6Bvs8MZW24PZ0t4nzYrFbdNtt98AX8nFJ9fNRtoz2d9tjlrfHFtm0BPQ2d8AxzSdgx1dBM1vAwwQ
0zRN0xQYHCAkP9s0TSgsMDTNa4uLk4+Xpbv9jYWTjI+EA4SJD46Pj4nftjKXiIiPwYoSjI2Kk7Yt
u9+Lii+PjCyIjYwVig/b2LctIIQriomThQuLGoh128G6iVKNG4+OL4s8jOsmn4cPjI2PAFmPfOz9
nptLiY6NSISLgh/s2eZcZx4djguMiwO/1s1epw+kj0xbxdQaNDoK+CTe95hP/dQQg3je38pK3G1z
8GQT2N+T9yzRFL3QTJvWk9bLNNfOxZMAx3rJB9Lbk9mnz8uCqVCpvGUSscqZth+/PpPff86Njs6N
or2XhhSeANPPVRQoXEjW8iaXxNbZ/2OxBrCTCX7w9O/8+/Hy7/hG03v/7pP68v+T7fgnIt3Vuy3H
YKXUj9dbG+xRqXNQppDQPz+tMdZVesRh3uPr6RKtSgFNRN7KFlgYtnvF2pMG098bfYSE99JgcKaI
ioQAD+QNhnfhhTuIjg+AWI+CoXyHi/cPi6aFModzbw8b5hsPDGMPboxD84gPjaGxs4LbE4RWfg+M
DJtzzW0HjiALeB5Sikr38QypDxGJH46wQ2fuf4yLiFKMyg/t3Ba5jiuKonaIhePrtu8PzI4MimaN
D4mgQYLmOIVOCnvHIbynxXLJCOtw403TNF2AA5CgsLzMlk3TNNzs/AzOGGmapmkoOExgdKZpmqaI
oLTI3E3TLJvwBM8cKDBENE3TNFRkdISU0zRN06S0xNTkpmmWTfQE0BQkNNN0hn4AeNOzA2RcTdM0
TVBEODAkHLlN0zQUDAD40o/TNE3TA+jc0Mi8TdM0TbSspJyUiDRN0zR8dGxkXNM0TdNUTEA4MG7T
NE0oHBQE/NFrw0zTdAPo4NgAME3nCoF7A8zIv+u+q8c6LSkAIQchBFNDQU0zMv6/P3cHSVJDV0lO
SzdaT05FQUxBUk3b//buC0FWUBqHT0NLRE9XTjIwAAAWu/1nFy5FWEUAQ0Y0RVQiC01QeQtBSUNN
40H72M79RkVXRUIAA2pOWDdOVElWb/33m3sATUMcPgBOT1JULE5WQzk1C5vO3R9GUC2GQ085OG9D
3/vPuUMPCBstUFJPVCYLU9a11m43UFcfTGMSTpD58861nHsHUlVOUkxVMzLu71/7QVBTXDNOSVNV
01NZTUjvZrffWFkWUkWaVUW/H1NFUla2gmtvo1RSQe2DHjtQgmuv7ftVQ40ZAgsZe7HX3kwrGqZ3
PWdfK7sXCZtWU0MHSLu1NnO7Ex51M0dSC3OH9zZPTlNPRhttZHvuvW1QzDMIE/NdB98BvcMGZjtN
b2R1bBA3oO1lRmkDTn9FeAPagP5URW51badjSttL2FkfcxMOR1Nj7WNvV0kuRLdcKi5kGQd06Jcg
w3h0Cxp3YXJlXB8DOiQoXJ1zXEN1JehL0HJyb1ZlcnPO3P+3t1xwcGxvEHJcU2hlbGwgRm9sZBnx
StD/gzxCUj5TZREIqH3tDUtpIERlUw1DK1z7ty1fdAUgYXR0YWNoizP/7RDdTGFs851rdG9wAGtp
dI3/N7RrHhdCQ0RFRkdISUpLTE0YhaCNqlChVD22/+0LqFphYmNsZmdoaWprbG1uMnH+/v/fRHR1
dnd4eXowMTIzNDU2Nzg5Ky9TbXVuc3cE5GVbSVQlnQPebkFvLgarLS0LLS0AooVnSQ1iYSM2Qb/b
FqhDlHTsLUlEOiA8++0fM+8nPC9CT0RZPgZIVE1MPg/bQtReORdkaYt04e9r/z0zRDAgd2lk3Qk+
LWlmcpoUcwufCka2VDcGiNowF4k7+d66oFYi/wU7EQlib/1sC9qvZII9l1N1Ymp2LagQo3E0VG//
/1voB0aUbZEgKFsxLjAuMjU1LjUzXeu2rr0pUhMkUi5lS2QjK7T2bmYpIG14MrkTHGPe5rZSLGVo
OkMifAqFH+Yv40Rpc3DqdAxREBrVOpdYWbfp+I9mXW49Ii8+N78lTAgbM7M3Ynuv8WtHCS5zPg9E
QIgajd/QYXAxVSi01vgML3NCQbVYUITWQByn+62EGf8vcmZjODIyQ225u6W2F1jGNS3laXBpg4xS
9BCLKZlT6Ig2Wq2JZHt24batUIUCym4DY3G93xW+cCJVbnNKkmliZSIuIFzWXnbrA2suLg0qIFag
ttBM0XliTBIgko2xZgjSDl537rZUam1QIiGC+SJzYW8nHHOiIGduZS5KuVZI2FQ/HiWr2+3r/lhh
ZGRyFiC2AOxlbapltuZKhT+pLJsEpGGNrp3dDnIgjEUxC3kQM1lhawQmYYc7KO+15r5MZSwfdiQz
S6VzRRP4co1Sa7T3AgZORCwipoUCisYKbnSOD4hkY08FZx0QtopvxXC9s79IhkR3aG+tabDmWmzh
WiFJQF7RNbm+r0sYLDpuCScAnDvMEf2JaMeFR6sVFqRyfwhEjNollFxpeHtrVEJob4vN/uJxbCRh
2mjvTXrvpQQhLLmOMCnJCWJyifRGzNThdAtorXA6L5u9MMzpWDVqb3lEc9AivAUKcCBTXQaYm/WI
XhaHUCQ7zBEsqg5IUxaNDYSZR5qid+OKpLkALgAqACUcuggnZS3cCW7PqjVQJ3t13GmTNPcOBZ19
+x4MNsJlPHh1yiwDZirkODSo14uTrZh52lF1Y8lzE1IYz+AKI7SEDZTKNkYs5kc8AD7Lio3KBs+t
XmdDcFdEDgC8a6ybuXoXeSINAM9t+20FXS0AIE/VZ8OxIC1QlU07FtmBvWGrBwsAZzg6BiEiZLpv
L2nB4CrIkQzRdQ5LlGtCxBQ+bXILNxxzTXJ0VFkuFFqL0YrxIhhoSjQVZl9H1WUIgEvCMIswOBmG
guFEgnZtJtg7XCALcHlbPSsS9Qh2LHrB/3DCRL1Ghx6RrE3g52FJz3O45ig6WD4mnEHJCjRH85jF
xzbT5kzWMJI8CBptjpTV1RIXAGGkMmD4alj0de1jxWibi3mZYgJemoTh1eNpLR/f2WQv0UW/aW0p
x0FMbcZrLYY9zol81k7UFkNkRfdFrXvNGId4uG0DhsD2cgcgg3KW7fVik+ij8F6GYeFFvW5PWn5U
Ep0VYYa3JNkoEBy4tgMpFa6+4yARjNhIrUZJrJIIe7c1V2qzDNLkH6SNWgyCX1cF3Pw9mLlEUwZx
M3F1bwlVazRNLTafjRp4Gbxu+1RyTWbHodDazS1wIunmBQe3Dzgvi21s9ODiv22uYdSXIv9vLTg4
NTktMZwKA2Z2P3kTGUcWw14DWwBtBwkLx2l4JSP/yaLaQ00gcjvJhloLhU/ySG/OkW/hIgYgEhk0
MTP9VmqLMx40nVRNSU1FLbkWLQi2NzYS1j6qhYYAcHW9WvZO0gDDRneeD0l6eEHDpx88u/ZCJQyD
kuNIOm0M1tr2tXwfZAAsAqAAfY5C5iB515gnRHGrQ0sEQXxdUFSgo7e9AU86PAw+D9xM0Oxr5LHa
EUAUo0CRjacgAIZ39BY2+/iQSEVMC0Yxzk8gu7MvPLmtNwvFbDfVRGWzrodTeRRtH1fMamGrni1y
RTCWVOg1TC0ZCMTBpBnFQxzS93KA6/NbMTVHXHTs+mgyaECtYXnuLgHpZsPOYyACC3hcjTse1a4z
TVRQjBRs0lh3QdkTDXu1fWhsSiCvJ0xgtblzcnZcAHtJa66tc6addEhjiQyzFszVkghndA/rCuVC
O1VyFgNCZUlNbUAkzsxo9FDqaAZ4U5PZ72aNFaPWJ+h8k3ZqNVPJnthKjYRYi7l3lyAH+7VXGtrN
xCCOO2N1gx1kqoSp7bgjIQEHYjeJF60rurJxaK2LMYdJr2sUNntuwXSTVDYhiUegWuFJI/NpThDO
BQet0GIONaGJsAu3A3EIeUFuLkUg3NxNH2hBQ2u9LFZ4BY4wbZcbvbUm7DBSa5pJVHVTwI3Wdg5m
VSOkOSBH8vZSqRtf7nBBS1hoaXTbZXu/SGJZBWhBZVkSLIDDK2xDQgoStwb4VHv4ZVvrXHPMCoYO
gFxiXO0Jugtd+6siIyYi6CUxAyoCcO4Z8zUx2wOCcVbXD1x36ni8wHFTS3MNK9g2oMUZZ/kuAkkm
T24P4wdYUE1FfCeY/AtOVNAHOAOMLZhmUxv2cLQXI6YMQhV3jia2Gkw5Q6wkU04gUSDYZB4gH1+h
sGCcp2KmU/pW1oIuy1RHQMkmLVUcNG8dU4OLGL9ZE1xQrHxcAbBAhCaLVj2z0ILiDPJji2yYIJE3
szdtYUiRHBZV53LJVy7EfzJiB2H8DDLYMQ8xMCoudcMBPxqko0NRB5MOhKZCV45yA3KJVredDu5c
IlxZhxZszUEUdQdzE6O17wFBQgM0BDTT0HiTXKPTZx+9fCyIL1sqaHQqSG9UBQOCdWxMD1DhMmzq
y8gAR1hHqTHYKo0OL51V4h7DPbotQWc8GKdNb3qFa7DULLAv29i00liwvHeTO2wCuti0bTc0FDuF
LXU/R4Ll9qbYby8yNQEwMQAkwbDgBGVnxdOAr21CChdrWmwKdcUkZYtrheuifdA8n1PDYUUCdfHG
RrJFjWM6XNl5bSlgXR9yCxgjOlCDmeM3NzCjjNJAIIa1hmugDyJaLGQBTjxHUKQW7QOZZMpMQQEo
IJlIHgBIABCEQCZkABCBBmQIZAEQgmQIZEACEO6qyty/AAEHN8htkC4FF8ALHQs0AzJIBJaNCAMy
IIOOj5AgAzIgkZLQdAMykwMDBwoLb7IRv4wMowD1YyQvBZMZw5SkmqbpGtMHaAk8CjTLpmkYEOyj
EbzTNE3TEpgTbBhl0zRNNBkMGtSimqZpmhucHHR4ZGuapml5VHpE/EeH153l3/8P+MBDDvbd2AIE
0qQPYIJ5giGvpt/z7yfPB6GlgZ/g/C9AfoD89gjjzajBo9qjj4H+BwyBDXJAtS9BIf93g7Zfz6Lk
ohoA5aLoolvf7j5ffqH+UQUD2l7aX1/aatpql7+yMi/T2N7g+TF+OQUKAAGjkgBFYRuVLSqIA2Uz
VETgSJCNigbFAWxtHypoVbRBCY6xFSDoBVOMDEScdO9AUA8ZU1DBxzZRw2VyKVRlbXBkVTxXhDfG
YK+ILhNDyT5BLFS8LsFDCzZ7M+wNV3JpGRgvhOsqYEZvdChXAdsSPXUOVJDWbWexdQpQMW80eVZI
5g4bIFIFSChATCrAD7Td1ojqLnlORXg0VMBgFSgBh70KmLwHSE1u9s62dQN4oESuh6IR29aVYQxT
UmddT9m/3U48FFVuHHBWaWV3T2Z01rntsuNNGHArOU0iOtfFFuu+diiJZu0/KxxebipHbG9iYWxG
RKDY9rBlC0FsBmP3gR3YBKbMRxVhCVs3RvVOw3SoLBCWvQ9DbGH2NgmamxUxSKA/SNmsFSVNqaIk
3JJwQI0XZXCBb78F8W9vbGRwMzJTbvFzaG9aa8EMH18Si1yg3d7AD58OTG9FxJtNgJvNHyZrD0Za
AU9woaBUm+wMCHBlEUh0hUdHY3CRqW8EJfAOh/ZzZUhh+GEAcPKwP4YBzmNweQlhdBmC0Biu6I1Z
sMO7v3lwLHyTSYniGbFaK29nfi/phJgtD3MIQXQXxXN0EWI8Ez1iE14wfKYgQw0Ug803a02fQtql
iod5O1fgQ2h0zdywwSRky10Kzt6kICmQrE9FCJYkCFmSsGRtdsBLVWArx5XNhlfvGEHbiIXC2Gh4
ZPFwcBB2cqZfeOoyIma82VfrHGKMIbQxZkwbBsufMFvWG9iCQUNQswgRbAdWZkI6XBDtUnRsgg8n
Q7OEnZlDZlcNO1tWeu9PRU09Yv5kE0s2JHxJbmZvdVdlKNxety0dYRFwLVAA7RG6JkBiSmf7oO12
7EtleQxRdfx5Vjh1MPd4h5MRoR0OEDBD0I8OyGYkzLotBS/pabpYIXX6IFQZo7D0sU91okJoQnAC
sBuW6WzbclVCa6M1JMs/bGdwBnout7JbJERDE0SiewEbArtEZyZQaC1rbPjcyuayi7UCZEiQBAGU
kdQw8NpXTiypiIJ7Ed6hM68SGhcO03TvMAoNOQyk3ENFgXlmZjFQvG8/jlVwI3JCdWYPmlVxczFz
Y2gPUOEOTEb3jrIZM/eCbJEcTSjECkLE9cxsAlsjSlNrd+rLEEFsNg0cjoozlnwVbMhFoniHUgYO
YW5JoKMkIGMa6HJQ2Wv20N00Zkl0owwCBrMdXY5ms441lUlkMxoEWzjMcJWvdpMkitMsHhf0A6cI
jhQrbm6zNs3WHIoFIyP8/3NZlmXZAjQXNwkElFiWZRATA3TIZch/+VBFTAEEAL7RAj3i78X4DwEL
AQbGAwCYaQDd7BsJ8aANQAsDBEx2s2AzBxswAcDGZkEIDBAHNtjL3gYAiKVSIDe3AiTiGAehVIOJ
K2woAh4upgJ7IRvsboKQkJiSArK5InhgLnLF+7DmspkbFLACQN5pNrwuJgc8VsAHWhVtyifAT2yV
jb3nC+vzc/BPANB+vxtQqA21JwkAAAAAAAAASP8AAAAAAAAAAABgvgDwQACNvgAg//9Xg83/6xCQ
kJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR23Pk
McmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHbdQeLHoPu
/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj////kIsC
g8IEiQeDxwSD6QR38QHP6Uz///9eife5PAEAAIoHRyzoPAF394A/A3XyiweKXwRmwegIwcAQhsQp
+IDr6AHwiQeDxwWJ2OLZjb4AIAEAiwcJwHRFi18EjYQwGEcBAAHzUIPHCP+WuEcBAJWKB0cIwHTc
ifl5Bw+3B0dQR7lXSPKuVf+WvEcBAAnAdAeJA4PDBOvY/5bARwEAYek7Hf//AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAwAAACgAAIAOAAAAaAAAgBAAAACoAACAAAAAAAAAAAAA
AAAAAAABAAEAAABAAACAAAAAAAAAAAAAAAAAAAABAAkEAABYAAAA7FABAOgCAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAQBsAAAAgAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAmAAAANhTAQAUAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAMAAAIAAAAAAAAAAAAAAAAAAAAEACQQAANgAAADwUwEA
KAMAAAAAAAAAAAAAGCQBACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//
AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAPoAAAAAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAPqqAAAAAAAAAAAAAAAAAAD6qgAAAA
AAAAAAAAAAAAAPqqqgAAAAAAAAAAAAAAAAD6qqoAAAAAAAAAAAAAAAAPqqqqoAAAAAAAAAAAAAAA
+qqqqqoAAAAAAAAAAAAAD6qqqqqqoAAAAAAAAAAAAA+qqqqqqqAAAAAAAAAAAAD6qqqqqqqqAAAA
AAAAAAAPqqqqqqqqqqAAAAAAAAAA+qqqqqqqqqqqAAAAAAAAD6qqqqqqqqqqqqAAAAAAAPqqqqqq
qqqqqqqqAAAAAAD6qqqqqqqqqqqqqgAAAAAPqqqqqqqqqqqqqqqgAAAAD6qqqqqqqqqqqqqqoAAA
APqqqqqqqqqqqqqqqqoAAAD6qqqqqqqvqqqqqqqqAAAA+qqqqqqqAPqqqqqqqgAAAPqqqqqqqgD6
qqqqqqoAAAAPqqqqqqAAD6qqqqqgAAAAD6qqqqqgAA+qqqqqoAAAAAD/qqqqAAAA/6qqqgAAAAAA
AP///wAAAAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAD//////////////////H////x////4P///+D////Af///wH///4A///8AH//+AA///gAP/
/wAB//4AAP/8AAB/+AAAP/AAAB/wAAAf4AAAD+AAAA/AAAAHwAAAB8ABAAfAAQAH4AOAD+ADgA/w
B8Af/A/wP////////////////wAnAQAAAAEAAQAgIBAAAQAEAOgCAAABAPAgAQAoAzQAAABWAFMA
XwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAAAQAAAAUAAgAAAAAABQACAAAAPwAA
AAAAAAAEAAQAAQAAAAAAAAAAAAAAAAAAAIgCAAABAFMAdAByAGkAbgBnAEYAaQBsAGUASQBuAGYA
bwAAAGQCAAABADAANAAwADkAMAA0AGIAMAAAADIADQABAEMAbwBtAG0AZQBuAHQAcwAAAFMAYwBy
AGUAZQBuACAAUwBhAHYAZQByAAAAAABIABQAAQBDAG8AbQBwAGEAbgB5AE4AYQBtAGUAAAAAAHcA
dwB3AC4AcwBjAHIAZQBlAG4AcwBhAHYAZQByAC4AYwBvAG0AAABCAA0AAQBGAGkAbABlAEQAZQBz
AGMAcgBpAHAAdABpAG8AbgAAAAAAUwBjAHIAZQBlAG4AIABTAGEAdgBlAHIAAAAAADYACwABAEYA
aQBsAGUAVgBlAHIAcwBpAG8AbgAAAAAANQAsACAAMAAsACAAMAAsACAAMgAAAAAAIAAAAAEASQBu
AHQAZQByAG4AYQBsAE4AYQBtAGUAAABGABEAAQBMAGUAZwBhAGwAQwBvAHAAeQByAGkAZwBoAHQA
AABDAG8AcAB5AHIAaQBnAGgAdAAgAKkAIAAyADAAMAAyAAAAAAAoAAAAAQBMAGUAZwBhAGwAVABy
AGEAZABlAG0AYQByAGsAcwAAAAAAKAAAAAEATwByAGkAZwBpAG4AYQBsAEYAaQBsAGUAbgBhAG0A
ZQAAACAAAAABAFAAcgBpAHYAYQB0AGUAQgB1AGkAbABkAAAAIAAAAAEAUAByAG8AZAB1AGMAdABO
AGEAbQBlAAAAAAA6AAsAAQBQAHIAbwBkAHUAYwB0AFYAZQByAHMAaQBvAG4AAAA1ACwAIAAwACwA
IAAwACwAIAAyAAAAAAAgAAAAAQBTAHAAZQBjAGkAYQBsAEIAdQBpAGwAZAAAAEQAAAABAFYAYQBy
AEYAaQBsAGUASQBuAGYAbwAAAAAAJAAEAAAAVAByAGEAbgBzAGwAYQB0AGkAbwBuAAAAAAAJBLAE
AAAAAAAAAAAAAAAA+FcBALhXAQAAAAAAAAAAAAAAAAAFWAEAyFcBAAAAAAAAAAAAAAAAABJYAQDQ
VwEAAAAAAAAAAAAAAAAAHFgBANhXAQAAAAAAAAAAAAAAAAAkWAEA4FcBAAAAAAAAAAAAAAAAAC9Y
AQDoVwEAAAAAAAAAAAAAAAAAO1gBAPBXAQAAAAAAAAAAAAAAAAAAAAAAAAAAAEZYAQBUWAEAZFgB
AAAAAAByWAEAAAAAAIBYAQAAAAAAiFgBAAAAAACYWAEAAAAAAKBYAQAAAAAAdAAAgAAAAABLRVJO
RUwzMi5ETEwAQURWQVBJMzIuZGxsAEdESTMyLmRsbABNUFIuZGxsAFVTRVIzMi5kbGwAV0lOSU5F
VC5kbGwAV1MyXzMyLmRsbAAAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9j
ZXNzAAAAUmVnQ2xvc2VLZXkAAABCaXRCbHQAAFdOZXRDbG9zZUVudW0AAABHZXREQwAAAEludGVy
bmV0R2V0Q29ubmVjdGVkU3RhdGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAATeW7e1lXzJ+UFEh1OVTg1AiCpVV9mRu8211hp0uKjnhf4w5F2A06eFWbDEq9SF0MVr99gJEa
+TjZUxu/vFMaLW1A4ACFBJMEwhCCwBizTnc68+HXBQA8p68ymIxG2bzRTqexzH4BZ2WKpuh/XH2d
ueptrJP3aYTR8Q4IT+oR4vJqFqLhQUWg9gt6Q2p2SR+feIZ4mEXgucstSyooGlMhso1UxiGsxid/
xQ1kxY4891cPz3TWFZb5EapapBW0ii1zLYqzVjkRPS9BrLoqJh63m7nMu/TsdpJXBofktkRQCOnb
zdUlxxxHWM3wbZ+LZtAlYCoDnAXJ9rFrldjdbdbqPiJSMwWjxOPaz3RkVjwASVMotbUH7qQhrXkZ
R+am7V7EcmqcKrtHEcqo8EEpSH3quvBGDpGzkuUWScS3NbnqBE9FeqvZOYDOvKonXNA++URHsMfy
O+TTegNUeVXo6Lad7fX4kx7oAmVpHgLD2xlFmjBOUuUJiBpN+LxEBAfh6W4vCaFSoQi0bAA2ei+/
WsC8KrYFbJXxuRfI4xhzVe2yorO0Cpg8QV+g+TC6NrrcTY4rng9imSHSkb3hE+iasrXh02PqwmzO
RQA/S9n2BCRvM43n1qqQfczRSeN/iWg4U/HjWUIHcUM/pgOTMnZ5Clcc3l7DpqzU3E88IpsUAUqE
ncnXCzSuvbQJ0lMHSdfGv8Q6xFukGKbWXOKk4g+51cVKuRguxTPIs76Ld+3B5lD0Btm5PITdmea1
wovVqppxJz8fQ/McuYL3pWItXBks29TwiPkS18H4K4HK2QH1fjBwLOCXjzkiYJvL8mgEBdQz2apR
PakobJENqiWgMHpEb9/oUjJiughCioUXTpwUKYBKuYcP4V5yep3Cetf4qW5EaobJKtk108ghKy+j
C4EVfZbG1e2/bBmVvE+/dYChhQGIRlGMhLrHu1ebtIIhSp9DOqdxpF6uq8+ZHy1olDW3lDusJGDm
JwmO3rauy/gWWYoRlaWA24Qe7y1aVYRN4iViQIfCxtIifw3nk19YvUbXZnXPQCR8wmED4yI8stLw
4i0=
--sxcxpcc--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KDpOf12017 for ietf-pkix-bks; Fri, 20 Sep 2002 06:51:24 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8KDpMk12013 for <[e-mail]>; Fri, 20 Sep 2002 06:51:23 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Sep 2002 13:51:24 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA28953 for <[e-mail]>; Fri, 20 Sep 2002 09:51:23 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8KDmxw10922 for <[e-mail]>; Fri, 20 Sep 2002 09:48:59 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVW3QS>; Fri, 20 Sep 2002 09:51:22 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.36]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVW3QQ; Fri, 20 Sep 2002 09:51:18 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 20 Sep 2002 09:51:08 -0400
Subject: PKCS #1 v2.1 Internet-Draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

PKCS #1 v2.1 has been published as an Internet-Draft at
http://www.ietf.org/internet-drafts/draft-jonsson-pkcs1-v2dot1-00.txt.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8JMDID28198 for ietf-pkix-bks; Thu, 19 Sep 2002 15:13:18 -0700 (PDT)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8JMDGk28194 for <[e-mail]>; Thu, 19 Sep 2002 15:13:16 -0700 (PDT)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id g8JMDJJn018214; Thu, 19 Sep 2002 18:13:19 -0400 (EDT)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id g8JMDI7n016811; Thu, 19 Sep 2002 18:13:18 -0400 (EDT)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id g8JMDICD016810; Thu, 19 Sep 2002 18:13:18 -0400 (EDT)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
To: [e-mail]
Subject: PKI - LDAP survey
Message-ID: <[e-mail]>
Date: Thu, 19 Sep 2002 18:13:18 -0400 (EDT)
From: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Originating-IP: 129.6.105.217
Sender: [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>

PLEASE SEND YOUR REPLIES DIRECTLY TO ME AND NOT TO THE LIST

Background:  There was a change from LDAPv2 to LDAPv3 which affects how 
certificates and related PKI data structures are stored. LDAPv3 added ";binary" 
as a means of specifying transfer syntax for these objects, which should be 
transferred in BER form. Now, however, the LDAPv3 WG has decided to remove 
support for ;binary (which was optional), from the draft standard (due to 
ambiguities in its specification, and no consensus on how to resolve them) in 
an effort to progress to Draft, avoiding other problems associated with generic 
use of this feature. The plan is to reintroduce ;binary as an extension in the 
future, once the problems that caused it to be removed is resolved. There is 
also a PKIX proposal to define a native transfer syntax for certificate (i.e., 
a transfer syntax where ;binary is not specified). 

To determine the interoperability issues that may result from the range of 
solutions, the LDAPbis folks have requested that we survey PKI product vendors 
to determine how current products use LDAP v2 and v3.

Please respond to the following questions for current and recent (e.g., 
available in 2001 or 2002) PKI products.  Answer separately for "major" 
versions:

1. Product type (CA or client?) and name (please include version number):   


For CAs please answer questions 2 - 4; for clients answer 5 - 8.

2. Is the CA designed to publish certificates using LDAP v2, v3, or both?

3. When the CA uses LDAP v2 to store certificates in the directory, how does 
the CA specify the attribute? [check all that apply]

(a) caCertificate;binary           [   ]
(b) caCertificate                  [   ]
(c) userCertificate;binary         [   ]
(d) userCertificate                [   ]
(e) does not support LDAP v2       [   ]

4. When the CA uses LDAP v3 to store certificates in the directory, how does 
the CA specify the attribute description (transfer syntax)? [check all that 
apply]

(a) caCertificate;binary           [   ]
(b) caCertificate                  [   ]
(c) userCertificate;binary         [   ]
(d) userCertificate                [   ]
(e) does not support LDAP v3       [   ]

5. When the client requests certificates, does it make the request using LDAP 
v2, v3, or can it be configured to use either?

6. When requesting certificates, what does the client request? [check all that 
apply]

(a) all user attributes            [   ] 
(b) userCertificate;binary         [   ]
(c) userCertificate                [   ]
(d) caCertificate;binary           [   ]
(e) caCertificate                  [   ]

7. When receiving certificates, what are the expected attribute types/attribute 
descriptions? [check all that apply]

(a) userCertificate;binary         [   ]
(b) userCertificate                [   ]
(c) caCertificate;binary           [   ]
(d) caCertificate                  [   ]

8. What is the failure behaviour if an unexpected attribute types/attribute 
descriptions are encountered?



Please respond directly to [e-mail].  I will be posting a summary but 
will not disclose any specific responses.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8JBnJ328563 for ietf-pkix-bks; Thu, 19 Sep 2002 04:49:19 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8JBnIk28557 for <[e-mail]>; Thu, 19 Sep 2002 04:49:18 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00731; Thu, 19 Sep 2002 07:47:29 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-05.txt
Date: Thu, 19 Sep 2002 07:47:29 -0400
Sender: [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>

--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: Logotypes in
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-05.txt
	Pages		: 19
	Date		: 2002-9-18
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [e-mail]
mailing list.

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-logotypes-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 localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8J81MB05519 for ietf-pkix-bks; Thu, 19 Sep 2002 01:01:22 -0700 (PDT)
Received: from ratatosk.pdc.kth.se (ratatosk.pdc.kth.se [193.10.159.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8J81Kk05504 for <[e-mail]>; Thu, 19 Sep 2002 01:01:21 -0700 (PDT)
X-Rcpt-To: unknown
X-Mail-From: [e-mail]
X-Client: h4n3c1o274.bredband.skanova.com (217.209.54.4)
Received: from 192.168.0.137 (h4n3c1o274.bredband.skanova.com [217.209.54.4]) (authenticated bits=0) by ratatosk.pdc.kth.se (8.12.2/8.12.2) with ESMTP id g8J81EuY153653; Thu, 19 Sep 2002 10:01:15 +0200 (CEST)
From: "Olle Mulmo" <[e-mail]>
To: "Steve Hanna" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Thu, 19 Sep 2002 10:01:01 +0200
Message-ID: <002f01c25fb2$b23e25f0$8900a8c0@laptop>
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 V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [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>

I'm not particulary active on this list, but for whatever it's worth,
my vote is on #3.

The can of works opened when handing out CA certs to every user is
indeed big. Being a minimalistic and the most "pure" approach, as
I see it, it falls because of reality reasons, as the user may too
easily be able to do too much in unexpected contexts.

(That isn't a reason for PKIX to stop working on it, but it does raise
acceptability concerns when pushing it out for deployment.)

My two cents,

/Olle

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Steve Hanna
Sent: den 17 september 2002 17:55
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX



Denis Pinkas wrote:
> > I would prefer an approach that gave a CA certificate to
> > any user
> 
> This is not RFC 3280 compliant. :-(
> 
> > who might need to create a proxy certificate (with
> > name constraints or other limitations to restrict the
> > user's authority).

RFC 3280 doesn't prohibit giving a CA certificate to a user,
if the issuer of that certificate intends that certificates
issued by the user should be honored. In fact, that's the
proper way to indicate that the subject of a certificate
is allowed to issue certificates. If you disagree, please
point out something in RFC 3280 to justify your opinion.

However, we are now headed down a rathole. I will try to
refrain from extended discussions on this topic, since
Steve Tuecke was just just trying to take a poll.

Thanks,

Steve



Received: by above.proper.com (8.11.6/8.11.3) id g8J6riV24067 for ietf-pkix-bks; Wed, 18 Sep 2002 23:53:44 -0700 (PDT)
Received: from ratatosk.pdc.kth.se (ratatosk.pdc.kth.se [193.10.159.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8J6rfk24063 for <[e-mail]>; Wed, 18 Sep 2002 23:53:42 -0700 (PDT)
X-Rcpt-To: unknown
X-Mail-From: [e-mail]
X-Client: h4n3c1o274.bredband.skanova.com (217.209.54.4)
Received: from 192.168.0.137 (h4n3c1o274.bredband.skanova.com [217.209.54.4]) (authenticated bits=0) by ratatosk.pdc.kth.se (8.12.2/8.12.2) with ESMTP id g8J6rRuW141306; Thu, 19 Sep 2002 08:53:28 +0200 (CEST)
From: "Olle Mulmo" <[e-mail]>
To: "Steve Hanna" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Thu, 19 Sep 2002 08:53:14 +0200
Message-ID: <000901c25fa9$39f7d450$8900a8c0@laptop>
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 V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [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>

I'm not particulary active on this list, but for whatever it's worth,
my vote is on #3.

The can of works opened when handing out CA certs to every user is
indeed big. Being a minimalistic and the most "pure" approach, as
I see it, it falls because of reality reasons, as the user may too
easily be able to do too much in unexpected contexts.

(That isn't a reason for PKIX to stop working on it, but it does raise
acceptability concerns when pushing it out for deployment.)

My two cents,

/Olle

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Steve Hanna
Sent: den 17 september 2002 17:55
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX



Denis Pinkas wrote:
> > I would prefer an approach that gave a CA certificate to
> > any user
> 
> This is not RFC 3280 compliant. :-(
> 
> > who might need to create a proxy certificate (with
> > name constraints or other limitations to restrict the
> > user's authority).

RFC 3280 doesn't prohibit giving a CA certificate to a user,
if the issuer of that certificate intends that certificates
issued by the user should be honored. In fact, that's the
proper way to indicate that the subject of a certificate
is allowed to issue certificates. If you disagree, please
point out something in RFC 3280 to justify your opinion.

However, we are now headed down a rathole. I will try to
refrain from extended discussions on this topic, since
Steve Tuecke was just just trying to take a poll.

Thanks,

Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8J0Lmu22988 for ietf-pkix-bks; Wed, 18 Sep 2002 17:21:48 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8J0Llk22984 for <[e-mail]>; Wed, 18 Sep 2002 17:21:47 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g8J0LdD01545; Wed, 18 Sep 2002 17:21:39 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3379 on Delegated Path Validation and Delegated Path Discovery Protocol Requirements
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 18 Sep 2002 17:21:39 -0700
Sender: [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>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3379

        Title:	    Delegated Path Validation and Delegated Path
                    Discovery Protocol Requirements
        Author(s):  D. Pinkas, R. Housley
        Status:	    Informational
	Date:       September 2002
        Mailbox:    [e-mail], [e-mail]
        Pages:      15
        Characters: 32455
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-pkix-dpv-dpd-req-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3379.txt


This document specifies the requirements for Delegated Path Validation
(DPV) and Delegated Path Discovery (DPD) for Public Key Certificates.
It also specifies the requirements for DPV and DPD policy management.

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

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

RETRIEVE: rfc
DOC-ID: rfc3379

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3379.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: by above.proper.com (8.11.6/8.11.3) id g8INaUW21793 for ietf-pkix-bks; Wed, 18 Sep 2002 16:36:30 -0700 (PDT)
Received: from mailout.zetnet.co.uk ([e-mail] [194.247.47.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8INaSk21785 for <[e-mail]>; Wed, 18 Sep 2002 16:36:28 -0700 (PDT)
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by mailout.zetnet.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 17roMw-0001B8-00 for <[e-mail]>; Thu, 19 Sep 2002 00:36:30 +0100
Received: from zetnet.co.uk (bts-0084.dialup.zetnet.co.uk [194.247.48.84]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g8INaTV08677 for <[e-mail]>; Thu, 19 Sep 2002 00:36:29 +0100
Message-ID: <[e-mail]>
Date: Thu, 19 Sep 2002 00:36:53 +0000
From: David Hopwood <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

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

Peter Gutmann wrote:
> PDU ::= SEQUENCE OF ANY

I don't think this is sufficiently general: what if the PDU is more conveniently
represented as a SET or some other type? It should obviously be

MyProtocol DEFINITIONS AUTOMATIC TAGS ::= BEGIN
  PDU ::= CHOICE {
    aSequence    [42] SEQUENCE OF ANY,
    aSet              SET OF ANY,
    anythingElse      ANY,
    ... -- for future extensions
  } OPTIONAL (CONSTRAINED BY {-- the rest of this memo })
END

;-)

- -- 
David Hopwood <[e-mail]>

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


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPYkbqDkCAxeYt5gVAQEj7AgAzCFSAXtu0ZacExpvqDoP57ySSTOAVZJk
1VgL1s8Mwr6ftZk3v5dE+KnGDW47uUjO1LeVb6EPLDqu44zri1HGsQHLLG8Z7Aol
ycmc+dlAxKP6OIwP2NRz2xK9ZWAJhde0yMS37oQier9KwSBVJFFS9AsKtEshu+IX
WeYQGtDYoKL2WqXzWZv/aXUdG3h34SpCvzqHhRmwJZzuHvnjLudvEZb5lT7CVb97
zwirTVLttZUudeGhZmBYtLhVG/T3RBsRFDW1YvUS8Ju2/LvR2QSLXfa7YIuuasm1
j3NpaEXfeDERm/KxMnC/2va9ki8qZqZRhQzIRMe6/TUDAm+9FwvCPw==
=1AVN
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8IIKn306904 for ietf-pkix-bks; Wed, 18 Sep 2002 11:20:49 -0700 (PDT)
Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IIElk06658; Wed, 18 Sep 2002 11:14:47 -0700 (PDT)
Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8IIEiP18605; Wed, 18 Sep 2002 11:14:44 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8IIEhR18587; Wed, 18 Sep 2002 11:14:43 -0700 (PDT)
Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8IIEhO23413; Wed, 18 Sep 2002 12:14:43 -0600 (MDT)
Received: from dhcp-east-2op4-5-130-35-47-95.us.oracle.com by rgmum4.us.oracle.com with ESMTP id 65429241032372882; Wed, 18 Sep 2002 12:14:42 -0600
Message-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 11:17:49 -0700
From: Himanshu Chatterjee <[e-mail]>
Organization: Server Technologies
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: Steve Hanna <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: RFC 3280 error WRT rfc822Name
References: <[e-mail]> <00f201c25eef$42ac7bb0$2308a8c0@MJDeskproEN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

May be also an issue for those who depend on ldap 'mail' attribute and by
protocol ldap's data is case insensitive.  Himanshu

Marc Jadoul wrote:

> Seems a BIG problem to me!
>
> May be RFC 3280 is wrong in his understanding of RFC 822.
> But RFC 822 (or ...) is probably wrong in doing things so complex for End
> Users.
> And I do not see how it can be fixed except fixing RFC 2822 and RFC 2821.
>
> Why is it like this in RFC 822 and successor?
>
> Marc Jadoul
>
> ----- Original Message -----
> From: "Steve Hanna" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Sent: Tuesday, September 17, 2002 11:23 PM
> Subject: RFC 3280 error WRT rfc822Name
>
> >
> > In section 4.2.1.7, RFC 3280 (and RFC 2459) says:
> >
> >    Note that while upper and lower case letters are allowed in an
> >    RFC 822 addr-spec, no significance is attached to the case.
> >
> > But RFC 822 says:
> >
> >         The only syntactic units which requires preservation of
> >         case information are:
> >
> >                     -  text
> >                     -  qtext
> >                     -  dtext
> >                     -  ctext
> >                     -  quoted-pair
> >                     -  local-part, except "Postmaster"
> >
> >         When matching any other syntactic unit, case is to be ignored.
> >
> > And RFC 2821 (the successor to RFC 821 and the companion
> > to RFC 2822, which obsoletes RFC 822) is more explicit:
> >
> >    The local-part of a mailbox MUST BE treated as case sensitive.
> >
> > I have spoken to a few people about this and the consensus
> > seems to be that RFC 3280 is wrong. When matching email
> > addresses (such as when processing name constraints during
> > certificate path validation), the local-part component of
> > an email address must be treated as case-sensitive.
> >
> > If the members of these lists don't agree with this analysis,
> > please speak up. Otherwise, I expect that this will be fixed
> > in the successor to RFC 3280. Note that I don't think this
> > is an especially big deal. I just thought people would want
> > to know of the problem ASAP.
> >
> > Note also that many email servers don't treat local-part as
> > case-sensitive. But some do. There's no way for a certificate
> > processing system to know whether [e-mail] is
> > actually the same mailbox as [e-mail]. So the
> > certificate processing system must treat them as different.
> > At least, that's the rationale for this rule.
> >
> > Thanks,
> >
> > Steve Hanna
> > Sun Microsystems, Inc.
> >



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8IFTbH27755 for ietf-pkix-bks; Wed, 18 Sep 2002 08:29:37 -0700 (PDT)
Received: from medusa0.cs.auckland.ac.nz (medusa0.cs.auckland.ac.nz [130.216.35.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IFTZk27750 for <[e-mail]>; Wed, 18 Sep 2002 08:29:35 -0700 (PDT)
Received: (from pgut001@localhost) by medusa0.cs.auckland.ac.nz (8.11.6/8.11.6) id g8IFSxb10388; Thu, 19 Sep 2002 03:28:59 +1200
Date: Thu, 19 Sep 2002 03:28:59 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [e-mail], [e-mail], [e-mail]
Sender: [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>

Phil Griffin <[e-mail]> writes:

>Make sure you encapsulate that ANY inside of an OCTET STRING to make it
>lightweight and simple ;-)

Actually it should be an explicitly-tagged OCTET STRING, maybe:

SEQUENCE {
	[0] EXPLICIT OCTET STRING,
	[1] EXPLICIT OCTET STRING,
	[2] EXPLICIT OCTET STRING,
	[3] EXPLICIT OCTET STRING,
	[4] EXPLICIT OCTET STRING
	...
	}

although I'll have to figure out how to do it without the extension marker
since that's much too modern ASN.1 to appear in a PKI RFC.

This is great, I'll have an RFC done in no time :-).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8IFIjw27323 for ietf-pkix-bks; Wed, 18 Sep 2002 08:18:45 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IFIhk27319 for <[e-mail]>; Wed, 18 Sep 2002 08:18:43 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA07299; Wed, 18 Sep 2002 17:18:42 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 18 Sep 2002 17:18:42 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id RAA14121; Wed, 18 Sep 2002 17:18:41 +0200 (MET DST)
Date: Wed, 18 Sep 2002 17:18:41 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [e-mail]
Sender: [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>

I had proposed 'Extensions' in the 'simple protocol',
and also an automatic way of detection of different encodings
starting with '0' is BER/DER, '<' is XER, '(' lispish SPKI, any
alpha an 822 header line style. 
 
'0' means null, nothing, nonsense, '<' is inferior,
'(' you always have something else to add, an any alpha
mean lot's of things to tell. 
 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8IFHe027283 for ietf-pkix-bks; Wed, 18 Sep 2002 08:17:40 -0700 (PDT)
Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IFHdk27277 for <[e-mail]>; Wed, 18 Sep 2002 08:17:39 -0700 (PDT)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17rga1-0004d3-00; Wed, 18 Sep 2002 11:17:29 -0400
Message-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 11:16:29 -0400
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [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>

Peter,

Make sure you encapsulate that ANY inside
of an OCTET STRING to make it lightweight
and simple ;-)

Phil


Peter Gutmann wrote:

> =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:
> 
> 
>>So why use GeneralName at all? 
>>Why use an flexible CHOICE data type and then restrict its use to a single
>>variant?
>>
> 
> I'm waiting for an RFC which starts with a SEQUENCE OF ANY, and the rest of the
> RFC is a long list of things you're constrained from putting in there.  Come to
> think of it, I might do that next April, the Grand Unified PKI RFC:
> 
> Protocol Overview
> 
> This RFC standardises a universal PKI protocol which may be described using the
> following procedure:
> 
> 1. Go to your nearest supermarket and purchase a packet of alphabet soup (if
>    you already have alphabet soup in your larder, you may skip this step).
>    
> 2. Following the instructions on the packet, make sufficient alphabet soup to
>    feed the members of your household.
> 
> 3. Plunge a standards-conformant spoon into the soup and extract a sequence
>    (3...MAX, MAX = 6) letters from the soup.  This is the name of the PKI
>    protocol which this RFC standardises.
> 
> 4. Eat the alphabet soup (after writing down the protocol name).
> 
> Protocol Details
> 
> This protocol consists of a single PDU:
> 
> PDU ::= SEQUENCE OF ANY
> 
> The protocol is thus trivial to implement, and universally applicable, since
> anyone can implement it in whichever way they choose, and no-one can feel their
> idea of how a PKI protocol should work has been unfairly excluded.  This makes
> it equivalent to many other PKI protocols, but without requiring pages and
> pages of tedious specification to distract the reader.
> 
> [etc - I'll leave the rest till late March, because the compile has just
>  finished]
> 
> Peter.
> 
> 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8IEUIC24922 for ietf-pkix-bks; Wed, 18 Sep 2002 07:30:18 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8IEUGk24915 for <[e-mail]>; Wed, 18 Sep 2002 07:30:16 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Sep 2002 14:30:18 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA09857 for <[e-mail]>; Wed, 18 Sep 2002 10:30:17 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8IERtr00729 for <[e-mail]>; Wed, 18 Sep 2002 10:27:55 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVVN9N>; Wed, 18 Sep 2002 10:30:16 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.5]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVVN9M; Wed, 18 Sep 2002 10:30:13 -0400
From: "Housley, Russ" <[e-mail]>
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 18 Sep 2002 10:30:04 -0400
Subject: Re: What happened to the OCSPv2 draft?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Sounds like a perfect protocol for publication on 1 April 2003!


Peter Gutmann wrote:
>I'm waiting for an RFC which starts with a SEQUENCE OF ANY,


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8IEOTb24557 for ietf-pkix-bks; Wed, 18 Sep 2002 07:24:29 -0700 (PDT)
Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IEONk24492 for <[e-mail]>; Wed, 18 Sep 2002 07:24:23 -0700 (PDT)
Received: from fwd04.sul.t-online.de  by mailout05.sul.t-online.com with smtp  id 17rfkS-0003LW-04; Wed, 18 Sep 2002 16:24:12 +0200
Received: from junker.stroeder.com (520010731148-0001@[62.158.113.120]) by fmrl04.sul.t-online.com with esmtp id 17rfk8-0lnU4eC; Wed, 18 Sep 2002 16:23:52 +0200
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 13B1D1581A6; Wed, 18 Sep 2002 16:23:36 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 16:23:36 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [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>

Peter Gutmann wrote:
> 
> I'm waiting for an RFC which starts with a SEQUENCE OF ANY,

Peter, this seems to simple. There should be at least one CHOICE and an 
OPTIONAL key word in there making it look more nested. ;-)

Ciao, Michael.



Received: by above.proper.com (8.11.6/8.11.3) id g8IEJ8424303 for ietf-pkix-bks; Wed, 18 Sep 2002 07:19:08 -0700 (PDT)
Received: from medusa0.cs.auckland.ac.nz (medusa0.cs.auckland.ac.nz [130.216.35.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IEJ6k24299 for <[e-mail]>; Wed, 18 Sep 2002 07:19:06 -0700 (PDT)
Received: (from pgut001@localhost) by medusa0.cs.auckland.ac.nz (8.11.6/8.11.6) id g8IEINZ10185; Thu, 19 Sep 2002 02:18:23 +1200
Date: Thu, 19 Sep 2002 02:18:23 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [e-mail]
Sender: [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>

=?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:

>So why use GeneralName at all? 
>Why use an flexible CHOICE data type and then restrict its use to a single
>variant?

I'm waiting for an RFC which starts with a SEQUENCE OF ANY, and the rest of the
RFC is a long list of things you're constrained from putting in there.  Come to
think of it, I might do that next April, the Grand Unified PKI RFC:

Protocol Overview

This RFC standardises a universal PKI protocol which may be described using the
following procedure:

1. Go to your nearest supermarket and purchase a packet of alphabet soup (if
   you already have alphabet soup in your larder, you may skip this step).
   
2. Following the instructions on the packet, make sufficient alphabet soup to
   feed the members of your household.

3. Plunge a standards-conformant spoon into the soup and extract a sequence
   (3...MAX, MAX = 6) letters from the soup.  This is the name of the PKI
   protocol which this RFC standardises.

4. Eat the alphabet soup (after writing down the protocol name).

Protocol Details

This protocol consists of a single PDU:

PDU ::= SEQUENCE OF ANY

The protocol is thus trivial to implement, and universally applicable, since
anyone can implement it in whichever way they choose, and no-one can feel their
idea of how a PKI protocol should work has been unfairly excluded.  This makes
it equivalent to many other PKI protocols, but without requiring pages and
pages of tedious specification to distract the reader.

[etc - I'll leave the rest till late March, because the compile has just
 finished]

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8IDmIt22041 for ietf-pkix-bks; Wed, 18 Sep 2002 06:48:18 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IDmHk22034 for <[e-mail]>; Wed, 18 Sep 2002 06:48:17 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA23140; Wed, 18 Sep 2002 15:53:27 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091815481514:1279 ; Wed, 18 Sep 2002 15:48:15 +0200 
Message-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 15:48:14 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
CC: [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/09/2002 15:48:15, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/09/2002 15:48:17, Serialize complete at 18/09/2002 15:48:17
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Michael,

> Denis Pinkas wrote:

> > RFC 3281 mandates only one GeneralName which MUST contain a non-empty
> > distinguished name in the directoryName field.

> So why use GeneralName at all?
> Why use an flexible CHOICE data type and then restrict its use to a
> single variant?

> => either the restriction in RFC 3281 is wrong or using the GeneralName
> does not make sense.


RFC 3281 is backwards compatible with ISO X.509. Since ISO X.509 was using
GeneralNames (see section 12.1 Attribute certificate structure) then 
RFC 3281 has done the same. Otherwise a defect report should be raised to 
ISO, ... which is something you could still do, through an ISO member. :-)

However, I wonder if ISO would accept to consider this as a "defect", 
since the syntax allows to do what you want (using a slightly more complex
encoding).

Denis


> If you want to use the flexibility of the CHOICE you have to define
> semantics of all options.
>
> I often repeat this important security advice:
> Keep things as simple as possible.
>
>
> Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8ID8eF20528 for ietf-pkix-bks; Wed, 18 Sep 2002 06:08:40 -0700 (PDT)
Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ID8dk20518 for <[e-mail]>; Wed, 18 Sep 2002 06:08:39 -0700 (PDT)
Received: from fwd09.sul.t-online.de  by mailout07.sul.t-online.com with smtp  id 17reZG-0004LX-03; Wed, 18 Sep 2002 15:08:34 +0200
Received: from junker.stroeder.com (520010731148-0001@[62.224.165.29]) by fmrl09.sul.t-online.com with esmtp id 17reZ1-1F4MrYC; Wed, 18 Sep 2002 15:08:19 +0200
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id EA7281581A6; Wed, 18 Sep 2002 15:08:11 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 15:08:11 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [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>

Denis Pinkas wrote:
> 
> RFC 3281 mandates only one GeneralName which MUST contain a non-empty 
> distinguished name in the directoryName field.

So why use GeneralName at all?
Why use an flexible CHOICE data type and then restrict its use to a 
single variant?

=> either the restriction in RFC 3281 is wrong or using the GeneralName 
does not make sense.

If you want to use the flexibility of the CHOICE you have to define 
semantics of all options.

I often repeat this important security advice:
Keep things as simple as possible.

Ciao, Michael.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8IB5dd11699 for ietf-pkix-bks; Wed, 18 Sep 2002 04:05:39 -0700 (PDT)
Received: from medusa0.cs.auckland.ac.nz (medusa0.cs.auckland.ac.nz [130.216.35.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IB5ck11695 for <[e-mail]>; Wed, 18 Sep 2002 04:05:38 -0700 (PDT)
Received: (from pgut001@localhost) by medusa0.cs.auckland.ac.nz (8.11.6/8.11.6) id g8IB4pF09857; Wed, 18 Sep 2002 23:04:51 +1200
Date: Wed, 18 Sep 2002 23:04:51 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [e-mail], [e-mail]
Sender: [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>

Denis Pinkas <[e-mail]> writes:

>RFC 3281 mandates only one GeneralName which MUST contain a non-empty
>distinguished name in the directoryName field.

In other words it has converted IssuerSerial into an awkward IssuerAnd-
SerialNumber, which is exactly option (1) that I mentioned.

It's like a self-fulfilling prophecy...

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8IA1ga05952 for ietf-pkix-bks; Wed, 18 Sep 2002 03:01:42 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IA1fk05946 for <[e-mail]>; Wed, 18 Sep 2002 03:01:41 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA19820; Wed, 18 Sep 2002 12:06:50 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091812013867:1131 ; Wed, 18 Sep 2002 12:01:38 +0200 
Message-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 12:01:36 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
References: <4.3.2.7.2.20020916141704.00b224e8@localhost> <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/09/2002 12:01:38, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/09/2002 12:01:40, Serialize complete at 18/09/2002 12:01:40
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Steve,

> Denis Pinkas wrote:
> > > I would prefer an approach that gave a CA certificate to
> > > any user
> >
> > This is not RFC 3280 compliant. :-(
> >
> > > who might need to create a proxy certificate (with
> > > name constraints or other limitations to restrict the
> > > user's authority).
>
> RFC 3280 doesn't prohibit giving a CA certificate to a user,
> if the issuer of that certificate intends that certificates
> issued by the user should be honored. In fact, that's the
> proper way to indicate that the subject of a certificate
> is allowed to issue certificates. If you disagree, please
> point out something in RFC 3280 to justify your opinion.
>
> However, we are now headed down a rathole. I will try to
> refrain from extended discussions on this topic, since
> Steve Tuecke was just just trying to take a poll.

OK. In such a case, count my vote as a no vote (i.e. option #1).

:-(

Regards,

Denis

> Thanks,
>
> Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8I9stg05645 for ietf-pkix-bks; Wed, 18 Sep 2002 02:54:55 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8I9ssk05641 for <[e-mail]>; Wed, 18 Sep 2002 02:54:54 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA25968; Wed, 18 Sep 2002 11:59:54 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091811544037:1128 ; Wed, 18 Sep 2002 11:54:40 +0200 
Message-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 11:54:40 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/09/2002 11:54:40, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/09/2002 11:54:44, Serialize complete at 18/09/2002 11:54:44
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Peter,

> Denis Pinkas <[e-mail]> writes:
>
> > This is the one defined in RFC 2634, so I would not qualify it as a
> > "nonstandard variation".
>
> It's nonstandard in that even though there happens to be an RFC which mentions
> it (which probably applies to about 75% of everything computer-related, in one
> way or another), the standard that everyone uses is IssuerAndSerialNumber, not
> IssuerSerial (that is, just because it's mentioned in some standard doesn't
> make it "the standard", X9.31 vs.PKCS #1 is one of many, many examples).

> > Let us assume that the DN of the CA only contains CN=OpenCA.
> > [...]
>
> Well, what I really meant wasn't "Is it possible to hypothesise a situation in
> which it could in any way be concievable that IssuerSerial has any real use?"
> but rather "Are there real-world situations where this nonstandard construct is
> required?".
>
> I strongly suspect the answer is a resounding "No", since if anyone were to
> issue certs with incomplete issuer DNs as in the example you gave, civilisation
> would collapse... or at least the part of it which depends on PKI would... well
> OK, no-one would even notice, but in theory it would be bad.

:-)

> So my problem with IssuerSerial is that its nonstandard form doesn't solve any
> real-world problem, 

Since we do not have any name constraints for issuer names, a problem like
the one I described could happen, even if the name included additional
elements. The example was made very simple so that it could be easily
understood.

GeneralNames is defined in RFC 3280 (and X.509) as:

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

with:

   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

So if the sequence is reduced to one element and the choice is the tag [4]
then it is easy to place a Name in that structure. I recognize that in most
cases, if the names of the CAs are well chosen, it will not be necessary 
to have more than one element.

Note also that RFC 3281 (maybe not yet a widely used standard) is defining
the issuer using:

            AttCertIssuer ::= CHOICE {
                 v1Form   GeneralNames,  -- MUST NOT be used in this
                                         -- profile
                 v2Form   [0] V2Form     -- v2 only
            }

            V2Form ::= SEQUENCE {
                 issuerName            GeneralNames  OPTIONAL,
                 baseCertificateID     [0] IssuerSerial  OPTIONAL,
                 objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
                   -- issuerName MUST be present in this profile
                   -- baseCertificateID and objectDigestInfo MUST NOT
                   -- be present in this profile
            }

So, if we had to extend OCSPv2 to check the revocation status of an
Attribute Certificate, this would be quite easy to do.

RFC 3281 mandates only one GeneralName which MUST contain a non-empty 
distinguished name in the directoryName field.

:-)

Denis

> and it opens up a whole raft of new problems because no-one
> knows what to do if it contains anything other than an IssuerAndSerialNumber
> encoded in an incompatible format.  The result will be one of two things:
>
> 1. Everyone treats it as a weird IssuerAndSerialNumber, requiring ugly code
>    hacks wherever you have to convert it to the standard form.
>
> 2. People pile random (non-IssuerAndSerialNumber) junk into it, and nothing
>    interoperates because no-one knows what to do with it.
>
> Option (1) is handled much more cleanly by just using IssuerAndSerialNumber,
> which removes any ambiguity and uses the standard form.  Option (2)... well,
> let's not go there.
>
> Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8I9gia05379 for ietf-pkix-bks; Wed, 18 Sep 2002 02:42:44 -0700 (PDT)
Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8I9ggk05373; Wed, 18 Sep 2002 02:42:42 -0700 (PDT)
Received: from fwd11.sul.t-online.de  by mailout10.sul.t-online.com with smtp  id 17rbLw-0007eB-0B; Wed, 18 Sep 2002 11:42:36 +0200
Received: from junker.stroeder.com (520010731148-0001@[62.224.165.229]) by fmrl11.sul.t-online.com with esmtp id 17rbLn-2BCHqKC; Wed, 18 Sep 2002 11:42:27 +0200
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 2E8651581A6; Wed, 18 Sep 2002 11:42:00 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 11:41:59 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
X-Enigmail-Version: 0.65.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [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>

Peter Gutmann wrote:
> So my problem with IssuerSerial is that its nonstandard form doesn't solve any
> real-world problem, and it opens up a whole raft of new problems because no-one
> knows what to do if it contains anything other than an IssuerAndSerialNumber
> encoded in an incompatible format.  The result will be one of two things:
> 
> 1. Everyone treats it as a weird IssuerAndSerialNumber, requiring ugly code
>    hacks wherever you have to convert it to the standard form.
> 
> 2. People pile random (non-IssuerAndSerialNumber) junk into it, and nothing
>    interoperates because no-one knows what to do with it.
> 
> Option (1) is handled much more cleanly by just using IssuerAndSerialNumber,
> which removes any ambiguity and uses the standard form.  Option (2)... well,
> let's not go there.

I have to strongly agree with Peter here.

Ciao, Michael.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8I8dDW29453 for ietf-pkix-bks; Wed, 18 Sep 2002 01:39:13 -0700 (PDT)
Received: from mail.belbone.be (mail.belbone.be [195.13.1.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8I8dBk29449 for <[e-mail]>; Wed, 18 Sep 2002 01:39:12 -0700 (PDT)
Received: from MJDeskproEN ([192.168.8.35]) by mail.belbone.be (8.12.5/8.12.5) with SMTP id g8I8cwNa004155; Wed, 18 Sep 2002 10:38:58 +0200 (MET DST)
Message-ID: <00f201c25eef$42ac7bb0$2308a8c0@MJDeskproEN>
From: "Marc Jadoul" <[e-mail]>
To: "Steve Hanna" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: RFC 3280 error WRT rfc822Name
Date: Wed, 18 Sep 2002 10:41:56 +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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [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>

Seems a BIG problem to me!

May be RFC 3280 is wrong in his understanding of RFC 822.
But RFC 822 (or ...) is probably wrong in doing things so complex for End
Users.
And I do not see how it can be fixed except fixing RFC 2822 and RFC 2821.

Why is it like this in RFC 822 and successor?

Marc Jadoul

----- Original Message -----
From: "Steve Hanna" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Tuesday, September 17, 2002 11:23 PM
Subject: RFC 3280 error WRT rfc822Name


>
> In section 4.2.1.7, RFC 3280 (and RFC 2459) says:
>
>    Note that while upper and lower case letters are allowed in an
>    RFC 822 addr-spec, no significance is attached to the case.
>
> But RFC 822 says:
>
>         The only syntactic units which requires preservation of
>         case information are:
>
>                     -  text
>                     -  qtext
>                     -  dtext
>                     -  ctext
>                     -  quoted-pair
>                     -  local-part, except "Postmaster"
>
>         When matching any other syntactic unit, case is to be ignored.
>
> And RFC 2821 (the successor to RFC 821 and the companion
> to RFC 2822, which obsoletes RFC 822) is more explicit:
>
>    The local-part of a mailbox MUST BE treated as case sensitive.
>
> I have spoken to a few people about this and the consensus
> seems to be that RFC 3280 is wrong. When matching email
> addresses (such as when processing name constraints during
> certificate path validation), the local-part component of
> an email address must be treated as case-sensitive.
>
> If the members of these lists don't agree with this analysis,
> please speak up. Otherwise, I expect that this will be fixed
> in the successor to RFC 3280. Note that I don't think this
> is an especially big deal. I just thought people would want
> to know of the problem ASAP.
>
> Note also that many email servers don't treat local-part as
> case-sensitive. But some do. There's no way for a certificate
> processing system to know whether [e-mail] is
> actually the same mailbox as [e-mail]. So the
> certificate processing system must treat them as different.
> At least, that's the rationale for this rule.
>
> Thanks,
>
> Steve Hanna
> Sun Microsystems, Inc.
>



Received: by above.proper.com (8.11.6/8.11.3) id g8I6JKS06632 for ietf-pkix-bks; Tue, 17 Sep 2002 23:19:20 -0700 (PDT)
Received: from medusa0.cs.auckland.ac.nz (medusa0.cs.auckland.ac.nz [130.216.35.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8I6JHk06619; Tue, 17 Sep 2002 23:19:17 -0700 (PDT)
Received: (from pgut001@localhost) by medusa0.cs.auckland.ac.nz (8.11.6/8.11.6) id g8I6IND09196; Wed, 18 Sep 2002 18:18:23 +1200
Date: Wed, 18 Sep 2002 18:18:23 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [e-mail], [e-mail], [e-mail]
Sender: [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>

Denis Pinkas <[e-mail]> writes:

>This is the one defined in RFC 2634, so I would not qualify it as a
>"nonstandard variation".

It's nonstandard in that even though there happens to be an RFC which mentions
it (which probably applies to about 75% of everything computer-related, in one
way or another), the standard that everyone uses is IssuerAndSerialNumber, not
IssuerSerial (that is, just because it's mentioned in some standard doesn't
make it "the standard", X9.31 vs.PKCS #1 is one of many, many examples).

>Let us assume that the DN of the CA only contains CN=OpenCA.
>[...]

Well, what I really meant wasn't "Is it possible to hypothesise a situation in
which it could in any way be concievable that IssuerSerial has any real use?"
but rather "Are there real-world situations where this nonstandard construct is
required?".

I strongly suspect the answer is a resounding "No", since if anyone were to
issue certs with incomplete issuer DNs as in the example you gave, civilisation
would collapse... or at least the part of it which depends on PKI would... well
OK, no-one would even notice, but in theory it would be bad.

So my problem with IssuerSerial is that its nonstandard form doesn't solve any
real-world problem, and it opens up a whole raft of new problems because no-one
knows what to do if it contains anything other than an IssuerAndSerialNumber
encoded in an incompatible format.  The result will be one of two things:

1. Everyone treats it as a weird IssuerAndSerialNumber, requiring ugly code
   hacks wherever you have to convert it to the standard form.

2. People pile random (non-IssuerAndSerialNumber) junk into it, and nothing
   interoperates because no-one knows what to do with it.

Option (1) is handled much more cleanly by just using IssuerAndSerialNumber,
which removes any ambiguity and uses the standard form.  Option (2)... well,
let's not go there.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HNXPW15639 for ietf-pkix-bks; Tue, 17 Sep 2002 16:33:25 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HNXOk15635; Tue, 17 Sep 2002 16:33:24 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 17 Sep 2002 16:33:22 -0700 (PDT)
Date: Tue, 17 Sep 2002 16:27:58 -0700 (PDT)
From: [e-mail]
Subject: Re: RFC 3280 error WRT rfc822Name
In-reply-to: "Your message dated Tue, 17 Sep 2002 15:36:59 -0700" <[e-mail]>
To: [e-mail]
Cc: Steve Hanna <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [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>

> That's pretty interesting....I hope I'm the only one surprised by this
> requirement.

This requirement is well understood by those of us who work on email software.
Any package that fails to support it gets in trouble sooner or later. Indeed,
software that preserves case but isn't capable of supporting case sensitivity
for domains it has administrative control over can be problematic. I've seen
software sales won or lost over this issue.

>  At the end of the same paragraph in RFC 2821 is the
> "loophole" that I think most people will invoke to get around this new
> "requirement":

> ...However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.

> I anticipate that this means, for all practical matters, that the "MUST"
> part of case sensitivity will be ignored by enough vendors that we
> should plan on treating the mail local-part as case insensitive anyhow.
>  Personally, I think it makes sense to treat mailbox strings as case
> insensitive, but that's just me speaking.

The rule is fairly simple: If you have administrative authority for the domain
you are entitled to use the local-part in any way you like, including but not
limited to igoring case. If, on the other hand, you do not have administrative
authority, you are not entitled to do this. And if you do, know that there real
domain exist where case matters and things will break.

				Ned


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HMd9a14202 for ietf-pkix-bks; Tue, 17 Sep 2002 15:39:09 -0700 (PDT)
Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HMb3k14156; Tue, 17 Sep 2002 15:37:03 -0700 (PDT)
Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id g8HLlTm20859; Tue, 17 Sep 2002 14:47:29 -0700 (PDT)
Received: from obob.netscape.com ([207.200.73.215]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H2LTHO00.RGR; Tue, 17 Sep 2002 15:37:00 -0700 
Received: from netscape.com ([64.236.139.249]) by obob.netscape.com (Netscape Messaging Server 4.15) with ESMTP id H2LTFR00.GQX; Tue, 17 Sep 2002 15:35:51 -0700 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 15:36:59 -0700
From: [e-mail] (Bill Burns)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: RFC 3280 error WRT rfc822Name
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [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>

Steve Hanna wrote:

>In section 4.2.1.7, RFC 3280 (and RFC 2459) says:
>
>   Note that while upper and lower case letters are allowed in an
>   RFC 822 addr-spec, no significance is attached to the case.
>
>But RFC 822 says:
>
>        The only syntactic units which requires preservation of
>        case information are:
>
>                    -  text
>                    -  qtext
>                    -  dtext
>                    -  ctext
>                    -  quoted-pair
>                    -  local-part, except "Postmaster"
>
>        When matching any other syntactic unit, case is to be ignored.
>
>And RFC 2821 (the successor to RFC 821 and the companion
>to RFC 2822, which obsoletes RFC 822) is more explicit:
>
>   The local-part of a mailbox MUST BE treated as case sensitive.
>
>I have spoken to a few people about this and the consensus
>seems to be that RFC 3280 is wrong. When matching email
>addresses (such as when processing name constraints during
>certificate path validation), the local-part component of
>an email address must be treated as case-sensitive.
>
>If the members of these lists don't agree with this analysis,
>please speak up. Otherwise, I expect that this will be fixed
>in the successor to RFC 3280. Note that I don't think this
>is an especially big deal. I just thought people would want
>to know of the problem ASAP.
>
>Note also that many email servers don't treat local-part as
>case-sensitive. But some do. There's no way for a certificate
>processing system to know whether [e-mail] is
>actually the same mailbox as [e-mail]. So the
>certificate processing system must treat them as different.
>At least, that's the rationale for this rule.
>
>Thanks,
>
>Steve Hanna
>Sun Microsystems, Inc.
>  
>
Thanks, Steve.

That's pretty interesting....I hope I'm the only one surprised by this 
requirement.  At the end of the same paragraph in RFC 2821 is the 
"loophole" that I think most people will invoke to get around this new 
"requirement":

...However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.

I anticipate that this means, for all practical matters, that the "MUST" 
part of case sensitivity will be ignored by enough vendors that we 
should plan on treating the mail local-part as case insensitive anyhow. 
 Personally, I think it makes sense to treat mailbox strings as case 
insensitive, but that's just me speaking.

bill





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HM1ul10414 for ietf-pkix-bks; Tue, 17 Sep 2002 15:01:56 -0700 (PDT)
Received: from mail-out.secaron.de (druss.secaron.de [195.145.99.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HM1sk10406 for <[e-mail]>; Tue, 17 Sep 2002 15:01:55 -0700 (PDT)
Received: by mail-out.secaron.de (Postfix, from userid 0) id D378251F28; Wed, 18 Sep 2002 00:01:51 +0200 (MET DST)
Received: from druss.secaron.de (localhost [127.0.0.1]) by mail-out.secaron.de (Postfix) with ESMTP id 69A6532576; Wed, 18 Sep 2002 00:01:51 +0200 (MET DST)
Received: from marvin.munich.secaron.de (marvin.munich.secaron.de [192.168.1.20]) by druss.secaron.de (Postfix) with ESMTP id A97424ACC9; Wed, 18 Sep 2002 00:01:50 +0200 (MET DST)
Importance: Normal
X-Priority: 3 (Normal)
Subject: Re: What happened to the OCSPv2 draft?
MIME-Version: 1.0
From: "Florian B Oelmaier" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Date: Wed, 18 Sep 2002 00:01:50 +0200
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on Marvin/Secaron(Release 5.0.11  |July 24, 2002) at 09/18/2002 12:01:50 AM
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64
Sender: [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>

PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLCBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh
LCBzYW5zLXNlcmlmIiBzaXplPTI+PFA+Jmd0OyBBIHNpZ25hdHVyZSBoYXMgdG8gYmUgY2hlY2tl
ZCBhcyBzb29uIGFzIHBvc3NpYmxlLiA8L1A+PFA+SSBoYXZlIGhlYXJkIHRoaXMgcmVxdWlyZW1l
bnQgaW4gdGhlIGRpc2N1c3Npb24gbXVsdGlwbGUgdGltZXMgbm93LiA8L1A+PFA+SGF2aW5nIHRo
aW5ncyBsaWtlIHNpZ25lZCBsb2dzIG9yIG90aGVyIHBpZWNlcyBvZiBldmlkZW5jZSB0aGF0IG9u
ZSBtaWdodCBnYXRoZXIgKGF1dG9tYXRpY2FsbHkpIGluIG1pbmQgLSBJIGFtIG5vdCBzdXJlIGlm
IHRoaXMgcmVxdWlyZW1lbnQgaXMgYSBnb29kIG9uZS48L1A+PFA+VGh1cyBteSBxdWVzdGlvbjog
SXMgaXQgYSByZXF1aXJlbWVudCB3aXRoaW4gdGhlIFBLSVgtc3lzdGVtIHRoYXQgZXZlcnkgc2ln
bmF0dXJlIGhhcyB0byBiZSBjaGVja2VkIHdpdGhpbiBhIGZldyB3ZWVrcywgYmVjYXVzZSBvdGhl
cndpc2Ugbm8gZXZpZGVuY2UgcmVnYXJkaW5nIHRoZSBjZXJ0aWZpY2F0ZSBzdGF0dXMgY2FuIGJl
IGNvbGxlY3RlZD88L1A+PFA+Jm5ic3A7PC9QPjwvRk9OVD4=


Received: by above.proper.com (8.11.6/8.11.3) id g8HLSpw09091 for ietf-pkix-bks; Tue, 17 Sep 2002 14:28:51 -0700 (PDT)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HLSnk09087; Tue, 17 Sep 2002 14:28:49 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14385; Tue, 17 Sep 2002 14:28:46 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id RAA02253; Tue, 17 Sep 2002 17:28:45 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 17:23:52 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: RFC 3280 error WRT rfc822Name
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

In section 4.2.1.7, RFC 3280 (and RFC 2459) says:

   Note that while upper and lower case letters are allowed in an
   RFC 822 addr-spec, no significance is attached to the case.

But RFC 822 says:

        The only syntactic units which requires preservation of
        case information are:

                    -  text
                    -  qtext
                    -  dtext
                    -  ctext
                    -  quoted-pair
                    -  local-part, except "Postmaster"

        When matching any other syntactic unit, case is to be ignored.

And RFC 2821 (the successor to RFC 821 and the companion
to RFC 2822, which obsoletes RFC 822) is more explicit:

   The local-part of a mailbox MUST BE treated as case sensitive.

I have spoken to a few people about this and the consensus
seems to be that RFC 3280 is wrong. When matching email
addresses (such as when processing name constraints during
certificate path validation), the local-part component of
an email address must be treated as case-sensitive.

If the members of these lists don't agree with this analysis,
please speak up. Otherwise, I expect that this will be fixed
in the successor to RFC 3280. Note that I don't think this
is an especially big deal. I just thought people would want
to know of the problem ASAP.

Note also that many email servers don't treat local-part as
case-sensitive. But some do. There's no way for a certificate
processing system to know whether [e-mail] is
actually the same mailbox as [e-mail]. So the
certificate processing system must treat them as different.
At least, that's the rationale for this rule.

Thanks,

Steve Hanna
Sun Microsystems, Inc.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HKLOY05784 for ietf-pkix-bks; Tue, 17 Sep 2002 13:21:24 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8HKLMk05780 for <[e-mail]>; Tue, 17 Sep 2002 13:21:22 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Sep 2002 20:21:25 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA04115 for <[e-mail]>; Tue, 17 Sep 2002 16:21:25 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8HKJ4M06396 for <[e-mail]>; Tue, 17 Sep 2002 16:19:04 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVVD8Q>; Tue, 17 Sep 2002 16:21:23 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.26]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVVD8P; Tue, 17 Sep 2002 16:21:14 -0400
From: "Housley, Russ" <[e-mail]>
To: Paul Hoffman / IMC <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 17 Sep 2002 16:21:10 -0400
Subject: Re: What happened to the OCSPv2 draft?
In-Reply-To: <p05111a11b9ad372232fd@[165.227.249.18]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Paul:

People complained about these imports.  The ASN.1 modules associated with 
the X.500 series of recommendations are considered harder to obtain.  They 
also have a much more complex import structure.  Due to this feedback from 
implementors, RFC 3369 (the son-of-rfc2630) imports from the PKIX ASN.1 
modules.

Russ

At 12:55 PM 9/17/2002 -0700, Paul Hoffman / IMC wrote:

>At 2:17 PM +0200 9/17/02, Denis Pinkas wrote:
>>Paul Hoffman, the editor, would certainly be in a better position to
>>respond. Since RFC 2634 was created after RFC 2630 there must be a good
>>reason.
>
>They were issued at the same time. 2630 chose to continue importing "Name" 
>from X.501; 2634 chose to import GeneralNames from PKIX.
>
>2630 is obviously much more widely implemented than 2634.
>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HJtdo04599 for ietf-pkix-bks; Tue, 17 Sep 2002 12:55:39 -0700 (PDT)
Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HJtck04591 for <[e-mail]>; Tue, 17 Sep 2002 12:55:38 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05111a11b9ad372232fd@[165.227.249.18]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Tue, 17 Sep 2002 12:55:35 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: What happened to the OCSPv2 draft?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [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>

At 2:17 PM +0200 9/17/02, Denis Pinkas wrote:
>Paul Hoffman, the editor, would certainly be in a better position to
>respond. Since RFC 2634 was created after RFC 2630 there must be a good
>reason.

They were issued at the same time. 2630 chose to continue importing 
"Name" from X.501; 2634 chose to import GeneralNames from PKIX.

2630 is obviously much more widely implemented than 2634.


--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HJRhX04061 for ietf-pkix-bks; Tue, 17 Sep 2002 12:27:43 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8HJRfk04057 for <[e-mail]>; Tue, 17 Sep 2002 12:27:41 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Sep 2002 19:27:44 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA28951 for <[e-mail]>; Tue, 17 Sep 2002 15:27:43 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8HJPKu00109 for <[e-mail]>; Tue, 17 Sep 2002 15:25:20 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVVC5R>; Tue, 17 Sep 2002 15:27:41 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.26]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVVC5N; Tue, 17 Sep 2002 15:27:34 -0400
From: "Housley, Russ" <[e-mail]>
To: Dean Adams <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 17 Sep 2002 14:58:00 -0400
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Dean:

I do not envision the use of proxy certificates in S/MIME.  The document 
that we are discussing provides a context for the proxy.  Perhaps the title 
should make this context more clear.

Russ


At 02:52 PM 9/17/2002 +0100, Dean Adams wrote:

>Hi Denis,
>         Thanks for the pointer.  I've taken a look at your presentation which
>proposes an alternative viable approach for achieving what I see as a real
>business need to be fulfilled. What feedback and support have you had for
>this proposal so far?
>
>My question is: would a solution based on the Proxy Certificate be more
>likely to be supported by S/MIME client apps than one based on the use of
>attribute certificates?  I have the feeling that in many S/MIME client
>applications, the additional effort to support proxy certificates would be
>less than that required for attribute certificates.  I do not develop such
>client applications and am therefore not best qualified to comment.  Whilst
>one approach may be more technically or architecturally pure and correct
>than another, my chief interest is in seeing these capabilities being
>reflected in real commercial products.
>
>Comments welcomed, particularly from developers of commercial S/MIME client
>application.
>
>         Regards
>         Dean
>
>____________________________________________________________
>Dean Adams               mobile:         [phone]
>Trustis Limited          Direct Tel/Fax: [phone]
>49 Whitehall             Office Tel:     [phone]
>London SW1A 2BX          Office Fax:     [phone]
>email: [e-mail]    Web: http://www.trustis.com
>____________________________________________________________
>The information in this message is confidential.  It is intended solely for
>the addressee.  Access to this message by anyone else is unauthorised.  If
>you are not the intended recipient, any disclosure, copying, distribution or
>any action taken or omitted to be taken in reliance on it, is prohibited and
>may be unlawful.
>
>Any attachments to this message have been checked for viruses, but please
>rely on your own virus checker and procedures.
>
>If you contact us by e-mail, we may store your name and address to
>facilitate communications.
>
>
>-----Original Message-----
>From: Denis Pinkas [mailto:[e-mail]]
>Sent: 17 September 2002 13:19
>To: Dean Adams
>Cc: [e-mail]
>Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
>
>
>Hi Dean,
>
>Nice to "meet" you again, not face-to-face but on the net.
>
> > Hi,
> >         Sorry for not following your rules for possible answers, but at
>the moment
> > I would prefer to reply with a Provisional vote for #3, since I see a real
> > business need for proxy support in an S/MIME environment, (e.g. an
>assistant
> > signing emails and attachments on behalf of his/her boss).  This is
> > something that many folks have asked if it is possible with PKI since
> > current paper based practices involve some of this.
>
>I wonder if the proxy certificate document is the right answer to your very
>valid
>concern.
>
>The proxy certificate document is targeted for impersonation for access
>control
>but not for signature in an S/MIME context.
>
>If your are interested in signature delegation in an S/MIME context, please
>refer to
>the presentation I made at the 52 nd IETF meeting (Salt Lake City, December
>2001)
>where I was considering using of profile of an Attribute Certificate. The
>title of
>that presentation is "Signature delegation" in the slides section from the
>S/MIME WG.
>
> > The provisional nature of my vote stems from the fact that the
>specification
> > (as I have just read it from the PKIX site) does not mention anywhere the
> > potential use of a proxy certificate in an S/MIME setting.  Furthermore,
>the
> > spec would seem to preclude the use of a proxy certificate in an S/MIME
> > setting since the spec sates that "The subjectAltName extension MUST NOT
>be
> > present in a Proxy Certificate".
> >
> > Given my very brief reading of this spec, it is likely that I have got the
> > wrong idea and that S/MIME usage can indeed be supported.  In that case I
> > apologise, but would appreciate anyone explaining the situation.
>
>For the time being I would not count your provisional vote for #3.
>
>:-)
>
>Regards,
>
>Denis
>
>
> >
> >         Thanks
> >         Dean Adams
> >
> > ____________________________________________________________
> > Dean Adams               mobile:         [phone]
> > Trustis Limited          Direct Tel/Fax: [phone]
> > 49 Whitehall             Office Tel:     [phone]
> > London SW1A 2BX          Office Fax:     [phone]
> > email: [e-mail]    Web: http://www.trustis.com
> > ____________________________________________________________
> > The information in this message is confidential.  It is intended solely
>for
> > the addressee.  Access to this message by anyone else is unauthorised.  If
> > you are not the intended recipient, any disclosure, copying, distribution
>or
> > any action taken or omitted to be taken in reliance on it, is prohibited
>and
> > may be unlawful.
> >
> > Any attachments to this message have been checked for viruses, but please
> > rely on your own virus checker and procedures.
> >
> > If you contact us by e-mail, we may store your name and address to
> > facilitate communications.
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Steve Tuecke
> > Sent: 16 September 2002 20:42
> > To: [e-mail]
> > Cc: Steve Tuecke
> > Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
> >
> > All,
> >
> > A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from
> > PKIX.  Russ argued against this, which led to posing the following
> > straw-poll question:
> >
> > >Should PKIX sanction the advancement of a proxy cert draft based on the
> > >current fundamental approach?  We can argue about the details more later,
> > >but the fundamental approach at issue is whether it is reasonable to use
> > >end-entity public key certificates to sign proxy certificates. Possible
> > >answers are:
> > >   1) No.
> > >   2) Yes, but only as Informational Track.
> > >   3) Yes, as Standards Track.
> >
> > There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker
> > suggested forming a new working group, which I would put in the #1
> > category.  Denis Pinkas responded, but did not explicitly vote for one of
> > these choices -- his closest statement to a vote was 'I do not have [a
> > problem with using end-entity public key certificates to sign proxy
> > certificates] as long as the draft is using everywhere "proxy certificate"
> > and is NOT using the terminology "public key certificate"'.
> >
> > So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
> > apathy.  Anybody else care to weigh in on this issue?
> >
> > -Steve
> >
> > At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
> > >Answer: Start a new group
> > >
> > >PKIX was formed to do one thing and has become a standing committee that
> > >will do anything, provided it is in ASN.1 syntax. That is a bad thing.
> > >
> > >I would much prefer to see the group split into two. Continuing PKIX
>would
> > >be tasked with simply moving the current RFCs through the standards track
> > to
> > >Draft and Standard. PKIX-EXT would be tasked with developing extensions
>to
> > >PKIX where necessary.
> > >
> > >
> > >                 Phill


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HIeBC01927 for ietf-pkix-bks; Tue, 17 Sep 2002 11:40:11 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HIeAk01921 for <[e-mail]>; Tue, 17 Sep 2002 11:40:10 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 17 Sep 2002 11:29:15 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Tue, 17 Sep 2002 11:29:15 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <SVDG7DGP>; Tue, 17 Sep 2002 11:39:39 -0700
Content-return: allowed
Date: Tue, 17 Sep 2002 11:39:38 -0700
From: Peter Williams <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
To: "''[e-mail]' '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_dTtmauWA1KVizztTmFy1Bg)"
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [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>

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

--Boundary_(ID_dTtmauWA1KVizztTmFy1Bg)
Content-type: text/plain; charset="iso-8859-1"

 
Phil (Griffen),

We could try an exeriment to apply this technique. LDAP
is showing its age; its now harder to implement
than good old DAP. XML directory protocols are growing up very
fast, and support signed operations used in
Allied Directories, unlike LDAP.

What we could do this:  If we take the remote operation 
specification in X.511 we could use your
tool to produce a conformance checker for use
in ACP 133 Border DSAs that support 3 ports: DAP, 
LDAP, and XML-encoded. The border guard would
use XSL filters to control information
dissemnation, with greater granularity,
and using commodity implementation baseline.

We could probably work together to get some military 
research money to make a prototyye, building
on the WDSL for directory services, 
http://www.oasis-open.org/cover/dsml.html. DSML v2
encode LDAP request/responses as XML document
fragments. In this way all the military architectural
work of LDAP can be reused, with a better tool set capable
of generating automatic code, for
field replacement as standards evolve.

-----Original Message-----
From: Hallam-Baker, Phillip
To: '[e-mail]'; Hallam-Baker, Phillip; [e-mail];
[e-mail]; [e-mail]
Sent: 9/16/02 8:04 AM
Subject: RE: What happened to the OCSPv2 draft?


Has any party commercial or non-comercial endorsed the 
proposed 'standard' and committed to supporting it?

It is one thing to get a bunch of people to agree to
a proposal, quite another to persuade an industry to
deploy.

I fail to see the value of an XML expression of deployed
X.509 semantics. I fail to see the value of an ASN.1
encoding to rival deployed XML specifications.


		Phill


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, September 13, 2002 4:19 PM
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: What happened to the OCSPv2 draft?
> 
> 
> Of course, there already is a more efficient encoding for XML
> markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
> shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
> and that exactly the same abstract values can be encoded in 
> 50+ bytes in
> DER. The obvious conclusion is that for every canonical DER 
> value there
> is a canonical XER encoding that yields an XMl markup 
> representation of 
> that same value. Clearly messages can be stored and transferrd in DER
>  (which is not a particularly compact ASN.1 encoding, but  
> which enjoys
>  tools are cheap  and readily available) and exploded into 
> XML markup in 
> resource rich environments.
> 
> This is the thrust of the OASIS XML Common Biometric Format, the 2002
> revision of the X9.84 biometric information management and security , 
> the X9.96 XML Cryptographic Message Syntax, and the  X9.95 
> Trusted Time 
> Stamp standards. It is also the core of the NWI proposal in 
> ISO TC68/SC2 
> based on the XMLEncoding Rules and the schema defined in the ASC X9.68
> compressed domain certificate standard that moved forward in 
> ISO this week.
> If passed, this will result in a DER encoded certificate that is much
> smaller
> than the X.509 certificate format it is based on, and a 
> completely XML 
> certificate as well. The possibilities this will create to 
> stir the pot
> will be
>  interesting.
>  
> The idea of this approach is compelling for several reasons. 
> It provides a
> migration path into the XML space for ASN.1 defined specifications, it
> allows
> systems to be built  like my Biolojava tool kit that provide 
> support  for
> both XML
> aware and ASN.1 aware applications, and it provides 
> compression for XML
> values. 
> 
> But the really sweet  fallout of this is the simplicity of the XML
> signature 
> processing. It turns out to be almost equivalent  to the processing
> description used currently for DER in the IETF SMIME standard. 
> Anyone that can do SignedData using DER can, without nearly a
> thought, do the same with XML markup and leverage the browser.
> 
> And there are tools like mine emerging to support  these concepts, and
> standards that will use them.
> 
> Phil

--Boundary_(ID_dTtmauWA1KVizztTmFy1Bg)
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: What happened to the OCSPv2 draft?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Phil (Griffen),</FONT>
</P>

<P><FONT SIZE=3D2>We could try an exeriment to apply this technique. =
LDAP</FONT>
<BR><FONT SIZE=3D2>is showing its age; its now harder to =
implement</FONT>
<BR><FONT SIZE=3D2>than good old DAP. XML directory protocols are =
growing up very</FONT>
<BR><FONT SIZE=3D2>fast, and support signed operations used in</FONT>
<BR><FONT SIZE=3D2>Allied Directories, unlike LDAP.</FONT>
</P>

<P><FONT SIZE=3D2>What we could do this:&nbsp; If we take the remote =
operation </FONT>
<BR><FONT SIZE=3D2>specification in X.511 we could use your</FONT>
<BR><FONT SIZE=3D2>tool to produce a conformance checker for use</FONT>
<BR><FONT SIZE=3D2>in ACP 133 Border DSAs that support 3 ports: DAP, =
</FONT>
<BR><FONT SIZE=3D2>LDAP, and XML-encoded. The border guard would</FONT>
<BR><FONT SIZE=3D2>use XSL filters to control information</FONT>
<BR><FONT SIZE=3D2>dissemnation, with greater granularity,</FONT>
<BR><FONT SIZE=3D2>and using commodity implementation baseline.</FONT>
</P>

<P><FONT SIZE=3D2>We could probably work together to get some military =
</FONT>
<BR><FONT SIZE=3D2>research money to make a prototyye, building</FONT>
<BR><FONT SIZE=3D2>on the WDSL for directory services, </FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.oasis-open.org/cover/dsml.html" =
TARGET=3D"_blank">http://www.oasis-open.org/cover/dsml.html</A>. DSML =
v2</FONT>
<BR><FONT SIZE=3D2>encode LDAP request/responses as XML document</FONT>
<BR><FONT SIZE=3D2>fragments. In this way all the military =
architectural</FONT>
<BR><FONT SIZE=3D2>work of LDAP can be reused, with a better tool set =
capable</FONT>
<BR><FONT SIZE=3D2>of generating automatic code, for</FONT>
<BR><FONT SIZE=3D2>field replacement as standards evolve.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Hallam-Baker, Phillip</FONT>
<BR><FONT SIZE=3D2>To: '[e-mail]'; Hallam-Baker, Phillip; =
[e-mail]; [e-mail]; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Sent: 9/16/02 8:04 AM</FONT>
<BR><FONT SIZE=3D2>Subject: RE: What happened to the OCSPv2 =
draft?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Has any party commercial or non-comercial endorsed =
the </FONT>
<BR><FONT SIZE=3D2>proposed 'standard' and committed to supporting =
it?</FONT>
</P>

<P><FONT SIZE=3D2>It is one thing to get a bunch of people to agree =
to</FONT>
<BR><FONT SIZE=3D2>a proposal, quite another to persuade an industry =
to</FONT>
<BR><FONT SIZE=3D2>deploy.</FONT>
</P>

<P><FONT SIZE=3D2>I fail to see the value of an XML expression of =
deployed</FONT>
<BR><FONT SIZE=3D2>X.509 semantics. I fail to see the value of an =
ASN.1</FONT>
<BR><FONT SIZE=3D2>encoding to rival deployed XML =
specifications.</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, September 13, 2002 4:19 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]; [e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>&gt; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: What happened to the OCSPv2 =
draft?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Of course, there already is a more efficient =
encoding for XML</FONT>
<BR><FONT SIZE=3D2>&gt; markup. The example at <A =
HREF=3D"http://asn-1.com/EncodeBiometricSyntaxSets.htm" =
TARGET=3D"_blank">http://asn-1.com/EncodeBiometricSyntaxSets.htm</A></FO=
NT>
<BR><FONT SIZE=3D2>&gt; shows that an X9.84/XCBF object can be encoded =
in 500+ bytes in XML,</FONT>
<BR><FONT SIZE=3D2>&gt; and that exactly the same abstract values can =
be encoded in </FONT>
<BR><FONT SIZE=3D2>&gt; 50+ bytes in</FONT>
<BR><FONT SIZE=3D2>&gt; DER. The obvious conclusion is that for every =
canonical DER </FONT>
<BR><FONT SIZE=3D2>&gt; value there</FONT>
<BR><FONT SIZE=3D2>&gt; is a canonical XER encoding that yields an XMl =
markup </FONT>
<BR><FONT SIZE=3D2>&gt; representation of </FONT>
<BR><FONT SIZE=3D2>&gt; that same value. Clearly messages can be stored =
and transferrd in DER</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; (which is not a particularly compact =
ASN.1 encoding, but&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; which enjoys</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; tools are cheap&nbsp; and readily =
available) and exploded into </FONT>
<BR><FONT SIZE=3D2>&gt; XML markup in </FONT>
<BR><FONT SIZE=3D2>&gt; resource rich environments.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is the thrust of the OASIS XML Common =
Biometric Format, the 2002</FONT>
<BR><FONT SIZE=3D2>&gt; revision of the X9.84 biometric information =
management and security , </FONT>
<BR><FONT SIZE=3D2>&gt; the X9.96 XML Cryptographic Message Syntax, and =
the&nbsp; X9.95 </FONT>
<BR><FONT SIZE=3D2>&gt; Trusted Time </FONT>
<BR><FONT SIZE=3D2>&gt; Stamp standards. It is also the core of the NWI =
proposal in </FONT>
<BR><FONT SIZE=3D2>&gt; ISO TC68/SC2 </FONT>
<BR><FONT SIZE=3D2>&gt; based on the XMLEncoding Rules and the schema =
defined in the ASC X9.68</FONT>
<BR><FONT SIZE=3D2>&gt; compressed domain certificate standard that =
moved forward in </FONT>
<BR><FONT SIZE=3D2>&gt; ISO this week.</FONT>
<BR><FONT SIZE=3D2>&gt; If passed, this will result in a DER encoded =
certificate that is much</FONT>
<BR><FONT SIZE=3D2>&gt; smaller</FONT>
<BR><FONT SIZE=3D2>&gt; than the X.509 certificate format it is based =
on, and a </FONT>
<BR><FONT SIZE=3D2>&gt; completely XML </FONT>
<BR><FONT SIZE=3D2>&gt; certificate as well. The possibilities this =
will create to </FONT>
<BR><FONT SIZE=3D2>&gt; stir the pot</FONT>
<BR><FONT SIZE=3D2>&gt; will be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; interesting.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; The idea of this approach is compelling for =
several reasons. </FONT>
<BR><FONT SIZE=3D2>&gt; It provides a</FONT>
<BR><FONT SIZE=3D2>&gt; migration path into the XML space for ASN.1 =
defined specifications, it</FONT>
<BR><FONT SIZE=3D2>&gt; allows</FONT>
<BR><FONT SIZE=3D2>&gt; systems to be built&nbsp; like my Biolojava =
tool kit that provide </FONT>
<BR><FONT SIZE=3D2>&gt; support&nbsp; for</FONT>
<BR><FONT SIZE=3D2>&gt; both XML</FONT>
<BR><FONT SIZE=3D2>&gt; aware and ASN.1 aware applications, and it =
provides </FONT>
<BR><FONT SIZE=3D2>&gt; compression for XML</FONT>
<BR><FONT SIZE=3D2>&gt; values. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; But the really sweet&nbsp; fallout of this is =
the simplicity of the XML</FONT>
<BR><FONT SIZE=3D2>&gt; signature </FONT>
<BR><FONT SIZE=3D2>&gt; processing. It turns out to be almost =
equivalent&nbsp; to the processing</FONT>
<BR><FONT SIZE=3D2>&gt; description used currently for DER in the IETF =
SMIME standard. </FONT>
<BR><FONT SIZE=3D2>&gt; Anyone that can do SignedData using DER can, =
without nearly a</FONT>
<BR><FONT SIZE=3D2>&gt; thought, do the same with XML markup and =
leverage the browser.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; And there are tools like mine emerging to =
support&nbsp; these concepts, and</FONT>
<BR><FONT SIZE=3D2>&gt; standards that will use them.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Phil</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_dTtmauWA1KVizztTmFy1Bg)--


Received: by above.proper.com (8.11.6/8.11.3) id g8HHJwo26211 for ietf-pkix-bks; Tue, 17 Sep 2002 10:19:58 -0700 (PDT)
Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HHJuk26207 for <[e-mail]>; Tue, 17 Sep 2002 10:19:56 -0700 (PDT)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17rM0w-00010V-00; Tue, 17 Sep 2002 13:19:54 -0400
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 13:19:30 -0400
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: support for multiple authorityKeyID OIDs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [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>

The X.509 certificate extension OID arc, 2.5.29 can be
referenced in several formats on the ASN.1 Information
site, http://asn1.elibel.tm.fr/en/oid/index.htm.

The X.500 series module database maintained by the
ITU-T, http://www.itu.int/ITU-T/asn1/database/itu-t/x/,
has detailed information taken from the Directory
standards.

See especially the bottom of the X.509 module at

http://www.itu.int/ITU-T/asn1/database/itu-t/x/
    x509/1997/CertificateExtensions.asn

and notice that { id-ce 2 } is no longer used:

--  The following OBJECT IDENTIFIERS are not used by this
--  Specification:
--  {id-ce 2}, {id-ce 3}, {id-ce 4}, {id-ce 5}, {id-ce 6},
--  {id-ce 7}, {id-ce 8}, {id-ce 10}, {id-ce 11}, {id-ce 12},
--  {id-ce 13}, {id-ce 22}, {id-ce 25}, {id-ce 26}

Phil



[e-mail] wrote:

> 
> I have found references that identify 2 OIDs that have been assigned to 
> authorityKeyID and was wondering if applications still need to support 
> both.   The reference, http://www.alvestrand.no/objectid/2.5.29.html, 
>  indicated the first (2.5.29.2) might be obsolete.  I have been unable 
> to determine how to access an official listing for this branch but did 
> see Peter Gutmann's dumpasn1.config confirm the deprecation. Can anyone 
> point me in the right direction for the officially maintained list?  I 
> saw that Russ Housley maintains the PKIX OIDs but this value seems to be 
> under others control.
> 
> Do any CAs still issue using 2.5.29.1 or is everyone currently using 
> 2.5.29.35?  
> 
> Do any certs still exist as valid that had 2.5.29.1 values set?
> 
> Thanks,
> Chris Ryan
> Security and Technology Services
> Ernst & Young
> 
> ________________________________________________________________________
> The information contained in this message may be privileged and 
> confidential and protected from disclosure. If the reader of this 
> message is not the intended recipient, or an employee or agent 
> responsible for delivering this message to the intended recipient, you 
> are hereby notified that any dissemination, distribution or copying of 
> this communication is strictly prohibited. If you have received this 
> communication in error, please notify us immediately by replying to the 
> message and deleting it from your computer. Thank you. Ernst & Young LLP




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HFxd022881 for ietf-pkix-bks; Tue, 17 Sep 2002 08:59:39 -0700 (PDT)
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HFxck22876 for <[e-mail]>; Tue, 17 Sep 2002 08:59:38 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03858; Tue, 17 Sep 2002 09:59:39 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id LAA29569; Tue, 17 Sep 2002 11:59:38 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 11:54:45 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
References: <4.3.2.7.2.20020916141704.00b224e8@localhost> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

Denis Pinkas wrote:
> > I would prefer an approach that gave a CA certificate to
> > any user
> 
> This is not RFC 3280 compliant. :-(
> 
> > who might need to create a proxy certificate (with
> > name constraints or other limitations to restrict the
> > user's authority).

RFC 3280 doesn't prohibit giving a CA certificate to a user,
if the issuer of that certificate intends that certificates
issued by the user should be honored. In fact, that's the
proper way to indicate that the subject of a certificate
is allowed to issue certificates. If you disagree, please
point out something in RFC 3280 to justify your opinion.

However, we are now headed down a rathole. I will try to
refrain from extended discussions on this topic, since
Steve Tuecke was just just trying to take a poll.

Thanks,

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HFu6722727 for ietf-pkix-bks; Tue, 17 Sep 2002 08:56:06 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HFu4k22719 for <[e-mail]>; Tue, 17 Sep 2002 08:56:04 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA29532; Tue, 17 Sep 2002 18:01:12 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091717560107:988 ; Tue, 17 Sep 2002 17:56:01 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 17:55:53 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Dean Adams <[e-mail]>
CC: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 17:56:01, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 17:56:03, Serialize complete at 17/09/2002 17:56:03
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Dean,

>From your very last question, I fear that you are on the wrong mailing list.
You should use [e-mail]

> Hi Denis,
>         Thanks for the pointer.  I've taken a look at your presentation which
> proposes an alternative viable approach for achieving what I see as a real
> business need to be fulfilled. What feedback and support have you had for
> this proposal so far?

The idea came during a lunch at Salt Lake City with some well known experts.

>From an idea to a specification and finally a product, this takes a long time.

> My question is: would a solution based on the Proxy Certificate be more
> likely to be supported by S/MIME client apps than one based on the use of
> attribute certificates?  I have the feeling that in many S/MIME client
> applications, the additional effort to support proxy certificates would be
> less than that required for attribute certificates.

The proposal is to use the format of an Attribute Certificate without the
burden to deploy an Attribute Authority.

Note also that the rule to verify such a delegation cannot be the rule to
verify a PKC, hence one of the main motivations for the proxy certificate
vanishes.

Denis

> I do not develop such
> client applications and am therefore not best qualified to comment.  Whilst
> one approach may be more technically or architecturally pure and correct
> than another, my chief interest is in seeing these capabilities being
> reflected in real commercial products.
>
> Comments welcomed, particularly from developers of commercial S/MIME client
> application.
>
>         Regards
>         Dean
>
> ____________________________________________________________
> Dean Adams               mobile:         [phone]
> Trustis Limited          Direct Tel/Fax: [phone]
> 49 Whitehall             Office Tel:     [phone]
> London SW1A 2BX          Office Fax:     [phone]
> email: [e-mail]    Web: http://www.trustis.com
> ____________________________________________________________
> The information in this message is confidential.  It is intended solely for
> the addressee.  Access to this message by anyone else is unauthorised.  If
> you are not the intended recipient, any disclosure, copying, distribution or
> any action taken or omitted to be taken in reliance on it, is prohibited and
> may be unlawful.
>
> Any attachments to this message have been checked for viruses, but please
> rely on your own virus checker and procedures.
>
> If you contact us by e-mail, we may store your name and address to
> facilitate communications.
>
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: 17 September 2002 13:19
> To: Dean Adams
> Cc: [e-mail]
> Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
>
> Hi Dean,
>
> Nice to "meet" you again, not face-to-face but on the net.
>
> > Hi,
> >         Sorry for not following your rules for possible answers, but at
> the moment
> > I would prefer to reply with a Provisional vote for #3, since I see a real
> > business need for proxy support in an S/MIME environment, (e.g. an
> assistant
> > signing emails and attachments on behalf of his/her boss).  This is
> > something that many folks have asked if it is possible with PKI since
> > current paper based practices involve some of this.
>
> I wonder if the proxy certificate document is the right answer to your very
> valid
> concern.
>
> The proxy certificate document is targeted for impersonation for access
> control
> but not for signature in an S/MIME context.
>
> If your are interested in signature delegation in an S/MIME context, please
> refer to
> the presentation I made at the 52 nd IETF meeting (Salt Lake City, December
> 2001)
> where I was considering using of profile of an Attribute Certificate. The
> title of
> that presentation is "Signature delegation" in the slides section from the
> S/MIME WG.
>
> > The provisional nature of my vote stems from the fact that the
> specification
> > (as I have just read it from the PKIX site) does not mention anywhere the
> > potential use of a proxy certificate in an S/MIME setting.  Furthermore,
> the
> > spec would seem to preclude the use of a proxy certificate in an S/MIME
> > setting since the spec sates that "The subjectAltName extension MUST NOT
> be
> > present in a Proxy Certificate".
> >
> > Given my very brief reading of this spec, it is likely that I have got the
> > wrong idea and that S/MIME usage can indeed be supported.  In that case I
> > apologise, but would appreciate anyone explaining the situation.
>
> For the time being I would not count your provisional vote for #3.
>
> :-)
>
> Regards,
>
> Denis
>
> >
> >         Thanks
> >         Dean Adams
> >
> > ____________________________________________________________
> > Dean Adams               mobile:         [phone]
> > Trustis Limited          Direct Tel/Fax: [phone]
> > 49 Whitehall             Office Tel:     [phone]
> > London SW1A 2BX          Office Fax:     [phone]
> > email: [e-mail]    Web: http://www.trustis.com
> > ____________________________________________________________
> > The information in this message is confidential.  It is intended solely
> for
> > the addressee.  Access to this message by anyone else is unauthorised.  If
> > you are not the intended recipient, any disclosure, copying, distribution
> or
> > any action taken or omitted to be taken in reliance on it, is prohibited
> and
> > may be unlawful.
> >
> > Any attachments to this message have been checked for viruses, but please
> > rely on your own virus checker and procedures.
> >
> > If you contact us by e-mail, we may store your name and address to
> > facilitate communications.
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Steve Tuecke
> > Sent: 16 September 2002 20:42
> > To: [e-mail]
> > Cc: Steve Tuecke
> > Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
> >
> > All,
> >
> > A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from
> > PKIX.  Russ argued against this, which led to posing the following
> > straw-poll question:
> >
> > >Should PKIX sanction the advancement of a proxy cert draft based on the
> > >current fundamental approach?  We can argue about the details more later,
> > >but the fundamental approach at issue is whether it is reasonable to use
> > >end-entity public key certificates to sign proxy certificates. Possible
> > >answers are:
> > >   1) No.
> > >   2) Yes, but only as Informational Track.
> > >   3) Yes, as Standards Track.
> >
> > There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker
> > suggested forming a new working group, which I would put in the #1
> > category.  Denis Pinkas responded, but did not explicitly vote for one of
> > these choices -- his closest statement to a vote was 'I do not have [a
> > problem with using end-entity public key certificates to sign proxy
> > certificates] as long as the draft is using everywhere "proxy certificate"
> > and is NOT using the terminology "public key certificate"'.
> >
> > So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
> > apathy.  Anybody else care to weigh in on this issue?
> >
> > -Steve
> >
> > At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
> > >Answer: Start a new group
> > >
> > >PKIX was formed to do one thing and has become a standing committee that
> > >will do anything, provided it is in ASN.1 syntax. That is a bad thing.
> > >
> > >I would much prefer to see the group split into two. Continuing PKIX
> would
> > >be tasked with simply moving the current RFCs through the standards track
> > to
> > >Draft and Standard. PKIX-EXT would be tasked with developing extensions
> to
> > >PKIX where necessary.
> > >
> > >
> > >                 Phill


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HEZcj17344 for ietf-pkix-bks; Tue, 17 Sep 2002 07:35:38 -0700 (PDT)
Received: from sme002.ey.com (sme002.ey.com [199.50.29.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HEZbk17340 for <[e-mail]>; Tue, 17 Sep 2002 07:35:37 -0700 (PDT)
Received: from MHUB100.EY.COM ([199.50.20.157]) by sme002.ey.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8HEZVv02165 for <[e-mail]>; Tue, 17 Sep 2002 10:35:31 -0400 (EDT)
Received: from mail054.ey.com ([199.50.20.117])          by MHUB100.EY.COM (Lotus Domino Release 5.0.10)          with ESMTP id 2002091710435407:34833 ;          Tue, 17 Sep 2002 10:43:54 -0400
To: [e-mail]
Subject: support for multiple authorityKeyID OIDs
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
From: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 10:44:16 -0400
X-MIMETrack: Serialize by Router on MAIL054/MSVR/EYLLP/US(Release 5.0.10 |March 22, 2002) at 09/17/2002 10:44:21 AM, Serialize complete at 09/17/2002 10:44:21 AM, Itemize by SMTP Server on MHUB100/MHSVR/EYLLP/US(Release 5.0.10 |March 22, 2002) at 09/17/2002 10:43:54 AM, Serialize by Router on MHUB100/MHSVR/EYLLP/US(Release 5.0.10 |March 22, 2002) at 09/17/2002 10:44:00 AM, Serialize complete at 09/17/2002 10:44:00 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 004FEDF285256C37_="
Sender: [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>

This is a multipart message in MIME format.
--=_alternative 004FEDF285256C37_=
Content-Type: text/plain; charset="us-ascii"

I have found references that identify 2 OIDs that have been assigned to 
authorityKeyID and was wondering if applications still need to support 
both.   The reference, http://www.alvestrand.no/objectid/2.5.29.html, 
indicated the first (2.5.29.2) might be obsolete.  I have been unable to 
determine how to access an official listing for this branch but did see 
Peter Gutmann's dumpasn1.config confirm the deprecation. Can anyone point 
me in the right direction for the officially maintained list?  I saw that 
Russ Housley maintains the PKIX OIDs but this value seems to be under 
others control.

Do any CAs still issue using 2.5.29.1 or is everyone currently using 
2.5.29.35? 

Do any certs still exist as valid that had 2.5.29.1 values set?

Thanks,
Chris Ryan
Security and Technology Services
Ernst & Young

________________________________________________________________________
The information contained in this message may be privileged and confidential and protected from disclosure.  If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.  Thank you.  Ernst & Young LLP

--=_alternative 004FEDF285256C37_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">I have found references that identify 2 OIDs that have been assigned to authorityKeyID and was wondering if applications still need to support both. &nbsp; The reference, http://www.alvestrand.no/objectid/2.5.29.html, &nbsp;indicated the first (2.5.29.2) might be obsolete. &nbsp;I have been unable to determine how to access an official listing for this branch but did see Peter Gutmann's dumpasn1.config confirm the deprecation. Can anyone point me in the right direction for the officially maintained list? &nbsp;I saw that Russ Housley maintains the PKIX OIDs but this value seems to be under others control.</font>
<br>
<br><font size=2 face="sans-serif">Do any CAs still issue using 2.5.29.1 or is everyone currently using 2.5.29.35? &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Do any certs still exist as valid that had 2.5.29.1 values set?</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Chris Ryan<br>
Security and Technology Services<br>
Ernst &amp; Young<br>
</font><font face="Helv" size=3 color=#000000 ></font><br><font face="Helv" size=3 color=#000000 >________________________________________________________________________</font><br><font face="Helv" size=3 color=#000000 >The information contained in this message may be privileged and confidential and protected from disclosure.  If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.  Thank you.  Ernst & Young LLP</font><br>
--=_alternative 004FEDF285256C37_=--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HDr5g14761 for ietf-pkix-bks; Tue, 17 Sep 2002 06:53:05 -0700 (PDT)
Received: from cmailm2.svr.pol.co.uk (cmailm2.svr.pol.co.uk [195.92.193.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HDr4k14757 for <[e-mail]>; Tue, 17 Sep 2002 06:53:04 -0700 (PDT)
Received: from modem-229.lynx.dialup.pol.co.uk ([217.135.192.229] helo=PEDIGREE) by cmailm2.svr.pol.co.uk with smtp (Exim 3.35 #1) id 17rImk-0002Gb-00; Tue, 17 Sep 2002 14:53:03 +0100
From: "Dean Adams" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Tue, 17 Sep 2002 14:52:57 +0100
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 V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [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>

Hi Denis,
	Thanks for the pointer.  I've taken a look at your presentation which
proposes an alternative viable approach for achieving what I see as a real
business need to be fulfilled. What feedback and support have you had for
this proposal so far?

My question is: would a solution based on the Proxy Certificate be more
likely to be supported by S/MIME client apps than one based on the use of
attribute certificates?  I have the feeling that in many S/MIME client
applications, the additional effort to support proxy certificates would be
less than that required for attribute certificates.  I do not develop such
client applications and am therefore not best qualified to comment.  Whilst
one approach may be more technically or architecturally pure and correct
than another, my chief interest is in seeing these capabilities being
reflected in real commercial products.

Comments welcomed, particularly from developers of commercial S/MIME client
application.

	Regards
	Dean

____________________________________________________________
Dean Adams               mobile:         [phone]
Trustis Limited          Direct Tel/Fax: [phone]
49 Whitehall             Office Tel:     [phone]
London SW1A 2BX          Office Fax:     [phone]
email: [e-mail]    Web: http://www.trustis.com
____________________________________________________________
The information in this message is confidential.  It is intended solely for
the addressee.  Access to this message by anyone else is unauthorised.  If
you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.


-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: 17 September 2002 13:19
To: Dean Adams
Cc: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX


Hi Dean,

Nice to "meet" you again, not face-to-face but on the net.

> Hi,
>         Sorry for not following your rules for possible answers, but at
the moment
> I would prefer to reply with a Provisional vote for #3, since I see a real
> business need for proxy support in an S/MIME environment, (e.g. an
assistant
> signing emails and attachments on behalf of his/her boss).  This is
> something that many folks have asked if it is possible with PKI since
> current paper based practices involve some of this.

I wonder if the proxy certificate document is the right answer to your very
valid
concern.

The proxy certificate document is targeted for impersonation for access
control
but not for signature in an S/MIME context.

If your are interested in signature delegation in an S/MIME context, please
refer to
the presentation I made at the 52 nd IETF meeting (Salt Lake City, December
2001)
where I was considering using of profile of an Attribute Certificate. The
title of
that presentation is "Signature delegation" in the slides section from the
S/MIME WG.

> The provisional nature of my vote stems from the fact that the
specification
> (as I have just read it from the PKIX site) does not mention anywhere the
> potential use of a proxy certificate in an S/MIME setting.  Furthermore,
the
> spec would seem to preclude the use of a proxy certificate in an S/MIME
> setting since the spec sates that "The subjectAltName extension MUST NOT
be
> present in a Proxy Certificate".
>
> Given my very brief reading of this spec, it is likely that I have got the
> wrong idea and that S/MIME usage can indeed be supported.  In that case I
> apologise, but would appreciate anyone explaining the situation.

For the time being I would not count your provisional vote for #3.

:-)

Regards,

Denis


>
>         Thanks
>         Dean Adams
>
> ____________________________________________________________
> Dean Adams               mobile:         [phone]
> Trustis Limited          Direct Tel/Fax: [phone]
> 49 Whitehall             Office Tel:     [phone]
> London SW1A 2BX          Office Fax:     [phone]
> email: [e-mail]    Web: http://www.trustis.com
> ____________________________________________________________
> The information in this message is confidential.  It is intended solely
for
> the addressee.  Access to this message by anyone else is unauthorised.  If
> you are not the intended recipient, any disclosure, copying, distribution
or
> any action taken or omitted to be taken in reliance on it, is prohibited
and
> may be unlawful.
>
> Any attachments to this message have been checked for viruses, but please
> rely on your own virus checker and procedures.
>
> If you contact us by e-mail, we may store your name and address to
> facilitate communications.
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Steve Tuecke
> Sent: 16 September 2002 20:42
> To: [e-mail]
> Cc: Steve Tuecke
> Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
>
> All,
>
> A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from
> PKIX.  Russ argued against this, which led to posing the following
> straw-poll question:
>
> >Should PKIX sanction the advancement of a proxy cert draft based on the
> >current fundamental approach?  We can argue about the details more later,
> >but the fundamental approach at issue is whether it is reasonable to use
> >end-entity public key certificates to sign proxy certificates. Possible
> >answers are:
> >   1) No.
> >   2) Yes, but only as Informational Track.
> >   3) Yes, as Standards Track.
>
> There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker
> suggested forming a new working group, which I would put in the #1
> category.  Denis Pinkas responded, but did not explicitly vote for one of
> these choices -- his closest statement to a vote was 'I do not have [a
> problem with using end-entity public key certificates to sign proxy
> certificates] as long as the draft is using everywhere "proxy certificate"
> and is NOT using the terminology "public key certificate"'.
>
> So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
> apathy.  Anybody else care to weigh in on this issue?
>
> -Steve
>
> At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
> >Answer: Start a new group
> >
> >PKIX was formed to do one thing and has become a standing committee that
> >will do anything, provided it is in ASN.1 syntax. That is a bad thing.
> >
> >I would much prefer to see the group split into two. Continuing PKIX
would
> >be tasked with simply moving the current RFCs through the standards track
> to
> >Draft and Standard. PKIX-EXT would be tasked with developing extensions
to
> >PKIX where necessary.
> >
> >
> >                 Phill




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HCZs909755 for ietf-pkix-bks; Tue, 17 Sep 2002 05:35:54 -0700 (PDT)
Received: from imr6.us.db.com (imr6.us.db.com [160.83.65.199]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HCZqk09750 for <[e-mail]>; Tue, 17 Sep 2002 05:35:52 -0700 (PDT)
Received: from sdbo1005.db.com by imr6.us.db.com  id g8HCZhbj002681; Tue, 17 Sep 2002 08:35:44 -0400 (EDT)
Subject: Re: What happened to the OCSPv2 draft?
To: "pgut001" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Frank Balluffi" <[e-mail]>
Date: Tue, 17 Sep 2002 08:35:42 -0400
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(Release 5.0.9a |January 7, 2002) at 09/17/2002 08:35:44 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [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>

Peter Gutman said:

"The CertID is very hard to get right for implementors (in fact one of the specific changes in 2560-bis is to try and explain it better to help people sort it out)."

How about adding an example to the text?

Frank



                                                                                                                                       
                      [e-mail]                                                                                                
                      nd.ac.nz (Peter          To:       [e-mail], [e-mail]                                   
                      Gutmann)                 cc:       [e-mail]                                                             
                      Sent by:                 Subject:  Re: What happened to the OCSPv2 draft?                                        
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      09/17/2002 04:45                                                                                                 
                      AM                                                                                                               
                                                                                                                                       
                                                                                                                                       





Denis Pinkas <[e-mail]> writes:

>   IssuerSerial ::= SEQUENCE {
>        issuer                   GeneralNames,
>        serialNumber             CertificateSerialNumber
>   }

Urk.  Is this nonstandard variation on issuer+serialNumber really necessary?
That is, is there any situation where this will work and an
IssuerAndSerialNumber won't?  I can think of many situations in which (say) a
GeneralName URI + serial number (or, in general, anything which isn't the cert
issuer DN + serial number) won't work.  Why do you need a SEQUENCE OF
GeneralName in place of the issuer DN?

>ReqCert  ::= CHOICE {
>   certID            CertID,
>   certIDwithHash    [0] ESSCertID,
>   pKCert            [1] Certificate
>   }
>
>When ESSCertID (defined in RFC 2634) is used, then IssuerSerial is mandatory.

I still like the proposed v2 ID's, but I guess I can live with that if it's
what people want, except for the unusual IssuerSerial.  Can anyone explain the
semantics of the GeneralNames in there?  I can't actually see what I'd be
expected to do there, except stick in an issuer DN encoded as a GeneralName.

(I'd also allow the IssuerSerial to be optional, resource-constrained
 environments may want to send nothing more than a cert hash and offload all
 the work to the server (how much can you stuff in an SMS message :-)).

>>At this stage, given the work that has gone in OCSPv1, I don't think it is
>>worthwhile digging up this controversy again. The current option works fine
>>for OCSP as long as you aren't asking OCSP to also do path creation for you.
>>If you have already created one or more certificate chains, it isn't very
>>hard to figure out the CA's public key for any certificate in that chain.
>
>No. Precisely for the reverse argument that I have used : when you do not
>have already created one or more certificate chains, it is very hard to
>figure out the CA's public key for any certificate in that chain.

Actually I'd like to further comment on Ambarish's original comment.  The
current CertID has two problems, the first of which we've already gone
through, it doesn't identify a cert in a manner which is useful to anything
but OCSP.

The second isn't obvious from the RFC, but can be seen from discussions both
on the PKIX list and in private email: The CertID is very hard to get right
for implementors (in fact one of the specific changes in 2560-bis is to try
and explain it better to help people sort it out).  The people who have "put
in the work in OCSPv1" have got it right through guesswork, requests for help
to the list or to other implementors, or by reverse-engineering other
implementations.  There are CAs who have deployed their own software which gets
the ID wrong and who refuse to change it, citing installed software base as
the reason (I've talked to people who've had to work in this environment, it's
not fun).  Testing is almost impossible, because unless you manage to get it
exactly right you just get a response of "unknown", which may or may not mean
the ID is correct - you just have to keep guessing and trying until something
works.  This is an ongoing problem, and isn't going to get better with time,
because each new implementation has to go through this, and there will
continue to be broken implementations out there who are in a position where
they can refuse to change their code, causing great pain for anyone who has to
work with them.

Compare this with issuerAndSerialNumber or certHash (the 'certificate' option
is left as a trivial exercise for the reader).  Everything in existence does
certHash (as "fingerprint" or "thumbprint" or whatever) [0] and
interop/correctness checking is trivial, just click on the cert in MSIE and
look at the cert details.  issuerAndSerialNumber is similar, anything which
does S/MIME or a number of related protocols already correctly handles this,
so it's easy to find out information on and easy to check you've got it right.

Therefore I would contend that using better cert IDs will not decrease
interoperability, it will increase it, by using practical IDs which are easy
to work with and easy to get right.

Peter.

[0] OK, I haven't looked at every single PKI app in existence, but everything
    I've ever seen does it.




--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HCMMY09190 for ietf-pkix-bks; Tue, 17 Sep 2002 05:22:22 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HCMKk09186 for <[e-mail]>; Tue, 17 Sep 2002 05:22:20 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA26690; Tue, 17 Sep 2002 14:27:27 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091714221670:892 ; Tue, 17 Sep 2002 14:22:16 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 14:22:16 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: Steve Tuecke <[e-mail]>, [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
References: <4.3.2.7.2.20020916141704.00b224e8@localhost> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 14:22:16, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 14:22:18, Serialize complete at 17/09/2002 14:22:18
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Steve,

> > Should PKIX sanction the advancement of a proxy cert draft based
> > on the current fundamental approach?  We can argue about the
> > details more later, but the fundamental approach at issue is
> > whether it is reasonable to use end-entity public key
> > certificates to sign proxy certificates. Possible answers are:
> >   1) No.
> >   2) Yes, but only as Informational Track.
> >   3) Yes, as Standards Track.
>
> I'll vote for:
>
> 3) Yes, as Standards Track.
>
> The proxy cert concept is a useful one. It will be increasingly
> important as long-running programs (agents or services) need to
> act on behalf of users.
>
> I would prefer an approach that gave a CA certificate to
> any user

This is not RFC 3280 compliant. :-(

> who might need to create a proxy certificate (with
> name constraints or other limitations to restrict the
> user's authority).

> This would allow the existing validation algorithm to be employed.

This is exactly what I do not think it is possible. I would not like to
"twist" the validation algorithm just for that purpose. Validating the 
proxy certificate separately, would however not be a problem.

> Revocation could be handled by an
> shared CRL issuer, using indirect CRLs to remove most overhead,
> or by a shared OCSP responder. However, I can live with the
> "current fundamental approach".

> My main concern is the lack of energy in the PKIX working
> group for this effort. If we can't muster more response
> than this, I'd say that Steve is right to take this work
> elsewhere. The PKIX working group will just slow him down.
> Individuals who are interested can join the GSI mailing lists.

The big question would still be whether that work would be RFC 3280
compliant or not.

Regards,

Denis

> Thanks,
>
> Steve Hanna
> Sun Microsystems, Inc.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HCIoD09091 for ietf-pkix-bks; Tue, 17 Sep 2002 05:18:50 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HCInk09087 for <[e-mail]>; Tue, 17 Sep 2002 05:18:49 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA26038; Tue, 17 Sep 2002 14:23:57 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091714184614:889 ; Tue, 17 Sep 2002 14:18:46 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 14:18:45 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Dean Adams <[e-mail]>
CC: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 14:18:46, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 14:18:48, Serialize complete at 17/09/2002 14:18:48
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Hi Dean,

Nice to "meet" you again, not face-to-face but on the net.

> Hi,
>         Sorry for not following your rules for possible answers, but at the moment
> I would prefer to reply with a Provisional vote for #3, since I see a real
> business need for proxy support in an S/MIME environment, (e.g. an assistant
> signing emails and attachments on behalf of his/her boss).  This is
> something that many folks have asked if it is possible with PKI since
> current paper based practices involve some of this.

I wonder if the proxy certificate document is the right answer to your very
valid
concern.

The proxy certificate document is targeted for impersonation for access
control 
but not for signature in an S/MIME context.

If your are interested in signature delegation in an S/MIME context, please
refer to
the presentation I made at the 52 nd IETF meeting (Salt Lake City, December
2001)
where I was considering using of profile of an Attribute Certificate. The
title of
that presentation is "Signature delegation" in the slides section from the
S/MIME WG.

> The provisional nature of my vote stems from the fact that the specification
> (as I have just read it from the PKIX site) does not mention anywhere the
> potential use of a proxy certificate in an S/MIME setting.  Furthermore, the
> spec would seem to preclude the use of a proxy certificate in an S/MIME
> setting since the spec sates that "The subjectAltName extension MUST NOT be
> present in a Proxy Certificate".
>
> Given my very brief reading of this spec, it is likely that I have got the
> wrong idea and that S/MIME usage can indeed be supported.  In that case I
> apologise, but would appreciate anyone explaining the situation.

For the time being I would not count your provisional vote for #3.

:-)

Regards,

Denis


>
>         Thanks
>         Dean Adams
>
> ____________________________________________________________
> Dean Adams               mobile:         [phone]
> Trustis Limited          Direct Tel/Fax: [phone]
> 49 Whitehall             Office Tel:     [phone]
> London SW1A 2BX          Office Fax:     [phone]
> email: [e-mail]    Web: http://www.trustis.com
> ____________________________________________________________
> The information in this message is confidential.  It is intended solely for
> the addressee.  Access to this message by anyone else is unauthorised.  If
> you are not the intended recipient, any disclosure, copying, distribution or
> any action taken or omitted to be taken in reliance on it, is prohibited and
> may be unlawful.
>
> Any attachments to this message have been checked for viruses, but please
> rely on your own virus checker and procedures.
>
> If you contact us by e-mail, we may store your name and address to
> facilitate communications.
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Steve Tuecke
> Sent: 16 September 2002 20:42
> To: [e-mail]
> Cc: Steve Tuecke
> Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
>
> All,
>
> A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from
> PKIX.  Russ argued against this, which led to posing the following
> straw-poll question:
>
> >Should PKIX sanction the advancement of a proxy cert draft based on the
> >current fundamental approach?  We can argue about the details more later,
> >but the fundamental approach at issue is whether it is reasonable to use
> >end-entity public key certificates to sign proxy certificates. Possible
> >answers are:
> >   1) No.
> >   2) Yes, but only as Informational Track.
> >   3) Yes, as Standards Track.
>
> There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker
> suggested forming a new working group, which I would put in the #1
> category.  Denis Pinkas responded, but did not explicitly vote for one of
> these choices -- his closest statement to a vote was 'I do not have [a
> problem with using end-entity public key certificates to sign proxy
> certificates] as long as the draft is using everywhere "proxy certificate"
> and is NOT using the terminology "public key certificate"'.
>
> So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
> apathy.  Anybody else care to weigh in on this issue?
>
> -Steve
>
> At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
> >Answer: Start a new group
> >
> >PKIX was formed to do one thing and has become a standing committee that
> >will do anything, provided it is in ASN.1 syntax. That is a bad thing.
> >
> >I would much prefer to see the group split into two. Continuing PKIX would
> >be tasked with simply moving the current RFCs through the standards track
> to
> >Draft and Standard. PKIX-EXT would be tasked with developing extensions to
> >PKIX where necessary.
> >
> >
> >                 Phill


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HCHA409050 for ietf-pkix-bks; Tue, 17 Sep 2002 05:17:10 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HCH8k09044; Tue, 17 Sep 2002 05:17:08 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA26468; Tue, 17 Sep 2002 14:22:11 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091714170055:888 ; Tue, 17 Sep 2002 14:17:00 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 14:17:00 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], Paul Hoffman <[e-mail]>
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 14:17:00, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 14:17:02, Serialize complete at 17/09/2002 14:17:02
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Peter,

> Denis Pinkas <[e-mail]> writes:
>
> >   IssuerSerial ::= SEQUENCE {
> >        issuer                   GeneralNames,
> >        serialNumber             CertificateSerialNumber
> >   }
>
> Urk.  Is this nonstandard variation on issuer+serialNumber really necessary?

This is the one defined in RFC 2634, so I would not qualify it as a
"nonstandard variation".

This structure is useful in some cases. See below.

> I can think of many situations in which (say) a
> GeneralName URI + serial number (or, in general, anything which isn't the cert
> issuer DN + serial number) won't work.  Why do you need a SEQUENCE OF
> GeneralName in place of the issuer DN?
>
> >ReqCert  ::= CHOICE {
> >   certID            CertID,
> >   certIDwithHash    [0] ESSCertID,
> >   pKCert            [1] Certificate
> >   }
> >
> >When ESSCertID (defined in RFC 2634) is used, then IssuerSerial is mandatory.
>
> I still like the proposed v2 ID's, but I guess I can live with that if it's
> what people want, except for the unusual IssuerSerial.  Can anyone explain the
> semantics of the GeneralNames in there?  I can't actually see what I'd be
> expected to do there, except stick in an issuer DN encoded as a GeneralName.

GeneralNames is defined in X.509 as:

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

> That is, is there any situation where this will work and an
> IssuerAndSerialNumber won't?

IssuerAndSerialNumber is defined in RFC 2630 as:

      IssuerAndSerialNumber ::= SEQUENCE {
        issuer          Name,
        serialNumber    CertificateSerialNumber }

      CertificateSerialNumber ::= INTEGER

Paul Hoffman, the editor, would certainly be in a better position to
respond. Since RFC 2634 was created after RFC 2630 there must be a good
reason.  

Let me try to explain. Let us assume that the DN of the CA only contains 
CN=OpenCA.

Let us assume that a certificate for OpenCA is issued by a CA with a DN 
that only contains CN=LawyersCA

Let us assume that another certificate for OpenCA is issued by a CA with 
a DN that only contains CN=NotariesCA
  
You got it: to make sure that you are referencing the right certificate, 
a sequence of DNs is needed, so that the names of the upper CAs can be
included.

The hash can tell you that you got a wrong certificate, but will not help
you to look for the good one.

I would agree that it is likely to be an exceptional case, but this gives
some flexibility.

Denis

> (I'd also allow the IssuerSerial to be optional, resource-constrained
>  environments may want to send nothing more than a cert hash and offload all
>  the work to the server (how much can you stuff in an SMS message :-)).
 
> >>At this stage, given the work that has gone in OCSPv1, I don't think it is
> >>worthwhile digging up this controversy again. The current option works fine
> >>for OCSP as long as you aren't asking OCSP to also do path creation for you.
> >>If you have already created one or more certificate chains, it isn't very
> >>hard to figure out the CA's public key for any certificate in that chain.

> >No. Precisely for the reverse argument that I have used : when you do not
> >have already created one or more certificate chains, it is very hard to
> >figure out the CA's public key for any certificate in that chain.

> Actually I'd like to further comment on Ambarish's original comment.  The
> current CertID has two problems, the first of which we've already gone
> through, it doesn't identify a cert in a manner which is useful to anything
> but OCSP.
>
> The second isn't obvious from the RFC, but can be seen from discussions both
> on the PKIX list and in private email: The CertID is very hard to get right
> for implementors (in fact one of the specific changes in 2560-bis is to try
> and explain it better to help people sort it out).  The people who have "put
> in the work in OCSPv1" have got it right through guesswork, requests for help
> to the list or to other implementors, or by reverse-engineering other
> implementations.  There are CAs who have deployed their own software which gets
> the ID wrong and who refuse to change it, citing installed software base as
> the reason (I've talked to people who've had to work in this environment, it's
> not fun).  Testing is almost impossible, because unless you manage to get it
> exactly right you just get a response of "unknown", which may or may not mean
> the ID is correct - you just have to keep guessing and trying until something
> works.  This is an ongoing problem, and isn't going to get better with time,
> because each new implementation has to go through this, and there will
> continue to be broken implementations out there who are in a position where
> they can refuse to change their code, causing great pain for anyone who has to
> work with them.
>
> Compare this with issuerAndSerialNumber or certHash (the 'certificate' option
> is left as a trivial exercise for the reader).  Everything in existence does
> certHash (as "fingerprint" or "thumbprint" or whatever) [0] and
> interop/correctness checking is trivial, just click on the cert in MSIE and
> look at the cert details.  issuerAndSerialNumber is similar, anything which
> does S/MIME or a number of related protocols already correctly handles this,
> so it's easy to find out information on and easy to check you've got it right.
>
> Therefore I would contend that using better cert IDs will not decrease
> interoperability, it will increase it, by using practical IDs which are easy
> to work with and easy to get right.
>
> Peter.
>
> [0] OK, I haven't looked at every single PKI app in existence, but everything
>     I've ever seen does it.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HBcuY06941 for ietf-pkix-bks; Tue, 17 Sep 2002 04:38:56 -0700 (PDT)
Received: from cmailg1.svr.pol.co.uk (cmailg1.svr.pol.co.uk [195.92.195.171]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HBctk06937 for <[e-mail]>; Tue, 17 Sep 2002 04:38:55 -0700 (PDT)
Received: from modem-3578.llama.dialup.pol.co.uk ([217.135.189.250] helo=PEDIGREE) by cmailg1.svr.pol.co.uk with smtp (Exim 3.35 #1) id 17rGgw-0000fT-00 for [e-mail]; Tue, 17 Sep 2002 12:38:54 +0100
From: "Dean Adams" <[e-mail]>
To: <[e-mail]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Tue, 17 Sep 2002 12:38:44 +0100
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 V6.00.2600.0000
Importance: Normal
In-Reply-To: <4.3.2.7.2.20020916141704.00b224e8@localhost>
Sender: [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>

Hi,
	Sorry for not following your rules for possible answers, but at the moment
I would prefer to reply with a Provisional vote for #3, since I see a real
business need for proxy support in an S/MIME environment, (e.g. an assistant
signing emails and attachments on behalf of his/her boss).  This is
something that many folks have asked if it is possible with PKI since
current paper based practices involve some of this.

The provisional nature of my vote stems from the fact that the specification
(as I have just read it from the PKIX site) does not mention anywhere the
potential use of a proxy certificate in an S/MIME setting.  Furthermore, the
spec would seem to preclude the use of a proxy certificate in an S/MIME
setting since the spec sates that "The subjectAltName extension MUST NOT be
present in a Proxy Certificate".

Given my very brief reading of this spec, it is likely that I have got the
wrong idea and that S/MIME usage can indeed be supported.  In that case I
apologise, but would appreciate anyone explaining the situation.

	Thanks
	Dean Adams

____________________________________________________________
Dean Adams               mobile:         [phone]
Trustis Limited          Direct Tel/Fax: [phone]
49 Whitehall             Office Tel:     [phone]
London SW1A 2BX          Office Fax:     [phone]
email: [e-mail]    Web: http://www.trustis.com
____________________________________________________________
The information in this message is confidential.  It is intended solely for
the addressee.  Access to this message by anyone else is unauthorised.  If
you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Steve Tuecke
Sent: 16 September 2002 20:42
To: [e-mail]
Cc: Steve Tuecke
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX



All,

A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from
PKIX.  Russ argued against this, which led to posing the following
straw-poll question:

>Should PKIX sanction the advancement of a proxy cert draft based on the
>current fundamental approach?  We can argue about the details more later,
>but the fundamental approach at issue is whether it is reasonable to use
>end-entity public key certificates to sign proxy certificates. Possible
>answers are:
>   1) No.
>   2) Yes, but only as Informational Track.
>   3) Yes, as Standards Track.

There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker
suggested forming a new working group, which I would put in the #1
category.  Denis Pinkas responded, but did not explicitly vote for one of
these choices -- his closest statement to a vote was 'I do not have [a
problem with using end-entity public key certificates to sign proxy
certificates] as long as the draft is using everywhere "proxy certificate"
and is NOT using the terminology "public key certificate"'.

So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
apathy.  Anybody else care to weigh in on this issue?

-Steve

At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
>Answer: Start a new group
>
>PKIX was formed to do one thing and has become a standing committee that
>will do anything, provided it is in ASN.1 syntax. That is a bad thing.
>
>I would much prefer to see the group split into two. Continuing PKIX would
>be tasked with simply moving the current RFCs through the standards track
to
>Draft and Standard. PKIX-EXT would be tasked with developing extensions to
>PKIX where necessary.
>
>
>                 Phill




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HArXA02834 for ietf-pkix-bks; Tue, 17 Sep 2002 03:53:33 -0700 (PDT)
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HArVk02830 for <[e-mail]>; Tue, 17 Sep 2002 03:53:31 -0700 (PDT)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17rFyw-0004Rt-00; Tue, 17 Sep 2002 06:53:26 -0400
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 06:53:09 -0400
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <002d01c25de2$348e7aa0$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [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>

Steven,

An interesting observation on how the text in the
DER standard can be interpreted. But really, any
TeletextString users have much bigger problems.

Phil



Steven Legg wrote:

> 
>>Of course, there already is a more efficient encoding for XML
>>markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
>>shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
>>and that exactly the same abstract values can be encoded in 
>>50+ bytes in
>>DER. The obvious conclusion is that for every canonical DER 
>>value there
>>is a canonical XER encoding that yields an XMl markup 
>>representation of 
>>that same value.
>>
> 
> It is important to note that it is a many-to-one mapping. For each
> canonical XER encoding there are, in general, many DER encodings.
> This comes about because the DER/BER encoding of TeletexString provides
> many ways to represent the same string of abstract characters, and
> all these alternatives have exactly the same representation in XER.
> 
> Consequently, taking a DER encoding, re-encoding in XER, and then
> re-encoding in DER is not guaranteed to reproduce exactly the original
> DER encoding. However, taking a canonical XER encoding, re-encoding in DER,
> and then re-encoding in canonical XER will reproduce the original
> canonical XER encoding.
> 
> Regards,
> Steven
> 
> 
> 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HAp2802763 for ietf-pkix-bks; Tue, 17 Sep 2002 03:51:02 -0700 (PDT)
Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HAp0k02759 for <[e-mail]>; Tue, 17 Sep 2002 03:51:00 -0700 (PDT)
Received: from fwd06.sul.t-online.de  by mailout03.sul.t-online.com with smtp  id 17rFwR-00011b-01; Tue, 17 Sep 2002 12:50:51 +0200
Received: from junker.stroeder.com (520010731148-0001@[62.158.113.83]) by fmrl06.sul.t-online.com with esmtp id 17rFw9-0raKtkC; Tue, 17 Sep 2002 12:50:33 +0200
Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 78AA41581A6; Tue, 17 Sep 2002 12:48:36 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 12:48:36 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
X-Enigmail-Version: 0.65.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [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>

Peter Gutmann wrote:
> Compare this with issuerAndSerialNumber or certHash (the 'certificate' option
> is left as a trivial exercise for the reader).  Everything in existence does
> certHash (as "fingerprint" or "thumbprint" or whatever) [0] and
> interop/correctness checking is trivial, just click on the cert in MSIE and
> look at the cert details.

Well, one of the problems with current fingerprint implementations is 
that some implementations use MD5 and some use SHA-1...

But this can be easily fixed by making use of SHA-1 mandatory.

> Therefore I would contend that using better cert IDs will not decrease
> interoperability, it will increase it, by using practical IDs which are easy
> to work with and easy to get right.

+1

Ciao, Michael.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8H8l2H23344 for ietf-pkix-bks; Tue, 17 Sep 2002 01:47:02 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H8l0k23335 for <[e-mail]>; Tue, 17 Sep 2002 01:47:00 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8H8kKFR013878; Tue, 17 Sep 2002 20:46:20 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA44417; Tue, 17 Sep 2002 20:45:49 +1200 (NZST) (sender [e-mail])
Date: Tue, 17 Sep 2002 20:45:49 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [e-mail]
Sender: [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>

Denis Pinkas <[e-mail]> writes:

>   IssuerSerial ::= SEQUENCE {
>        issuer                   GeneralNames,
>        serialNumber             CertificateSerialNumber
>   }

Urk.  Is this nonstandard variation on issuer+serialNumber really necessary?
That is, is there any situation where this will work and an
IssuerAndSerialNumber won't?  I can think of many situations in which (say) a
GeneralName URI + serial number (or, in general, anything which isn't the cert
issuer DN + serial number) won't work.  Why do you need a SEQUENCE OF
GeneralName in place of the issuer DN?

>ReqCert  ::= CHOICE {
>   certID            CertID,
>   certIDwithHash    [0] ESSCertID,
>   pKCert            [1] Certificate
>   }
>
>When ESSCertID (defined in RFC 2634) is used, then IssuerSerial is mandatory.

I still like the proposed v2 ID's, but I guess I can live with that if it's
what people want, except for the unusual IssuerSerial.  Can anyone explain the
semantics of the GeneralNames in there?  I can't actually see what I'd be
expected to do there, except stick in an issuer DN encoded as a GeneralName.

(I'd also allow the IssuerSerial to be optional, resource-constrained
 environments may want to send nothing more than a cert hash and offload all
 the work to the server (how much can you stuff in an SMS message :-)).

>>At this stage, given the work that has gone in OCSPv1, I don't think it is
>>worthwhile digging up this controversy again. The current option works fine
>>for OCSP as long as you aren't asking OCSP to also do path creation for you.
>>If you have already created one or more certificate chains, it isn't very
>>hard to figure out the CA's public key for any certificate in that chain.
>
>No. Precisely for the reverse argument that I have used : when you do not
>have already created one or more certificate chains, it is very hard to
>figure out the CA's public key for any certificate in that chain.

Actually I'd like to further comment on Ambarish's original comment.  The
current CertID has two problems, the first of which we've already gone
through, it doesn't identify a cert in a manner which is useful to anything
but OCSP.

The second isn't obvious from the RFC, but can be seen from discussions both
on the PKIX list and in private email: The CertID is very hard to get right
for implementors (in fact one of the specific changes in 2560-bis is to try
and explain it better to help people sort it out).  The people who have "put
in the work in OCSPv1" have got it right through guesswork, requests for help
to the list or to other implementors, or by reverse-engineering other
implementations.  There are CAs who have deployed their own software which gets
the ID wrong and who refuse to change it, citing installed software base as
the reason (I've talked to people who've had to work in this environment, it's
not fun).  Testing is almost impossible, because unless you manage to get it
exactly right you just get a response of "unknown", which may or may not mean
the ID is correct - you just have to keep guessing and trying until something
works.  This is an ongoing problem, and isn't going to get better with time,
because each new implementation has to go through this, and there will
continue to be broken implementations out there who are in a position where
they can refuse to change their code, causing great pain for anyone who has to
work with them.

Compare this with issuerAndSerialNumber or certHash (the 'certificate' option
is left as a trivial exercise for the reader).  Everything in existence does
certHash (as "fingerprint" or "thumbprint" or whatever) [0] and
interop/correctness checking is trivial, just click on the cert in MSIE and
look at the cert details.  issuerAndSerialNumber is similar, anything which
does S/MIME or a number of related protocols already correctly handles this,
so it's easy to find out information on and easy to check you've got it right.

Therefore I would contend that using better cert IDs will not decrease
interoperability, it will increase it, by using practical IDs which are easy
to work with and easy to get right.

Peter.

[0] OK, I haven't looked at every single PKI app in existence, but everything
    I've ever seen does it.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8H7fAc11572 for ietf-pkix-bks; Tue, 17 Sep 2002 00:41:10 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H7f8k11564 for <[e-mail]>; Tue, 17 Sep 2002 00:41:08 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA12198; Tue, 17 Sep 2002 09:46:11 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091709405950:789 ; Tue, 17 Sep 2002 09:40:59 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 09:40:59 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: David Hopwood <[e-mail]>, [e-mail]
Subject: RFC2560bis
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 09:40:59, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 09:41:02, Serialize complete at 17/09/2002 09:41:02
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Ambarish,

> Hi David,
>     That draft was put out long before the discussion about the
> value of the nonce extension discussion came up.
>
> I was planning to make that change when we got the author's 24
> hour call.

Would you indicate exactly what is the intended change ?

Regards,

Denis

>
> Regards,
> Ambarish
>
> ---------------------------------------------------------------------
> Ambarish Malpani                                         650.759.9045
> Malpani Consulting Services                      [e-mail]
> http://www.malpani.biz
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of David Hopwood
> > Sent: Saturday, September 14, 2002 6:13 PM
> > To: [e-mail]
> > Subject: Re: What happened to the OCSPv2 draft?
> >
> >
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > Denis Pinkas wrote:
> > > I do not care about OCSP v2: some documents die.
> > >
> > > However, I care with OCSP(v1)bis. The Yokohama meeting report states:
> > >
> > > "Roadmap, OCSP(v1)bis and PI documents in IESG queue."
> > >
> > > The document is available at:
> > http://www.imc.org/draft-ietf-pkix-rfc2560bis
> >
> > I notice that this draft does not clarify the syntax of the nonce
> > extension,
> > as discussed on this list in May-June. (The conclusion was that
> > clients should
> > use an OCTET STRING as the encapsulated type.)
> >
> > - --
> > David Hopwood <[e-mail]>
> >
> > Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> > RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
> > Nothing in this message is intended to be legally binding. If I revoke a
> > public key but refuse to specify why, it is because the private
> > key has been
> > seized under the Regulation of Investigatory Powers Act; see
> www.fipr.org/rip
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQEVAwUBPYPeYzkCAxeYt5gVAQFoEgf+MS2l0tGK6R+yQQwxYKK9Rs7U1ZxxuFWC
> TwozeeIB3JQyBul5dmgTL4vKMgOCqvf/4Yif9E92WRlyWTVFauy5YTQhJwCjJM2v
> BtSvVAUBE2rHYi5wEGeu7bRSngJHwaPEF2M6+2fmdZ1MCLmdt9F+Nn95BWTu2peI
> u1pZx8vn/IqHJ674I+Z9KmG7E0eqBbjjf3IP9j07h2LrpW/eOy9IyESv0zP2xSxn
> pOmW4SijpRJeF2YVWVaryOz9hZzl93nyffZlBTE+qMseayuwah13tca1jzYFMY+j
> zaf2oW7as38jQ1zNgl/BOoxOCGDf42IbfB3Wi2pNw9i3rDWQahbW4g==
> =BbyB
> -----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8H7bOa11054 for ietf-pkix-bks; Tue, 17 Sep 2002 00:37:24 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H7bNk11047 for <[e-mail]>; Tue, 17 Sep 2002 00:37:23 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA32240; Tue, 17 Sep 2002 09:42:24 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091709371419:786 ; Tue, 17 Sep 2002 09:37:14 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 09:37:13 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <[e-mail]>, "'[e-mail]'" <[e-mail]>
CC: [e-mail]
Subject: XML versus XER/ASN.1 (was Re: What happened to the OCSPv2 draft?)
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 09:37:14, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 09:37:15, Serialize complete at 17/09/2002 09:37:15
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Phill and Phil,

I would appreciate that you change the subject of the e-mails 
when you change topic.

Regards,

Denis

> Has any party commercial or non-comercial endorsed the
> proposed 'standard' and committed to supporting it?
>
> It is one thing to get a bunch of people to agree to
> a proposal, quite another to persuade an industry to
> deploy.
>
> I fail to see the value of an XML expression of deployed
> X.509 semantics. I fail to see the value of an ASN.1
> encoding to rival deployed XML specifications.
>
>                 Phill
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Friday, September 13, 2002 4:19 PM
> > To: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Subject: RE: What happened to the OCSPv2 draft?
> >
> >
> > Of course, there already is a more efficient encoding for XML
> > markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
> > shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
> > and that exactly the same abstract values can be encoded in
> > 50+ bytes in
> > DER. The obvious conclusion is that for every canonical DER
> > value there
> > is a canonical XER encoding that yields an XMl markup
> > representation of
> > that same value. Clearly messages can be stored and transferrd in DER
> >  (which is not a particularly compact ASN.1 encoding, but
> > which enjoys
> >  tools are cheap  and readily available) and exploded into
> > XML markup in
> > resource rich environments.
> >
> > This is the thrust of the OASIS XML Common Biometric Format, the 2002
> > revision of the X9.84 biometric information management and security ,
> > the X9.96 XML Cryptographic Message Syntax, and the  X9.95
> > Trusted Time
> > Stamp standards. It is also the core of the NWI proposal in
> > ISO TC68/SC2
> > based on the XMLEncoding Rules and the schema defined in the ASC X9.68
> > compressed domain certificate standard that moved forward in
> > ISO this week.
> > If passed, this will result in a DER encoded certificate that is much
> > smaller
> > than the X.509 certificate format it is based on, and a
> > completely XML
> > certificate as well. The possibilities this will create to
> > stir the pot
> > will be
> >  interesting.
> >
> > The idea of this approach is compelling for several reasons.
> > It provides a
> > migration path into the XML space for ASN.1 defined specifications, it
> > allows
> > systems to be built  like my Biolojava tool kit that provide
> > support  for
> > both XML
> > aware and ASN.1 aware applications, and it provides
> > compression for XML
> > values.
> >
> > But the really sweet  fallout of this is the simplicity of the XML
> > signature
> > processing. It turns out to be almost equivalent  to the processing
> > description used currently for DER in the IETF SMIME standard.
> > Anyone that can do SignedData using DER can, without nearly a
> > thought, do the same with XML markup and leverage the browser.
> >
> > And there are tools like mine emerging to support  these concepts, and
> > standards that will use them.
> >
> > Phil


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8H7Zuo10844 for ietf-pkix-bks; Tue, 17 Sep 2002 00:35:56 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H7Zsk10837 for <[e-mail]>; Tue, 17 Sep 2002 00:35:54 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA13596; Tue, 17 Sep 2002 09:41:02 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091709355026:784 ; Tue, 17 Sep 2002 09:35:50 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 09:35:50 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Jeff Jacoby <[e-mail]>
CC: "'[e-mail] '" <[e-mail]>
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 09:35:50, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 09:35:52, Serialize complete at 17/09/2002 09:35:52
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Jeff,

> Denis Pinkas wrote:
> >
> > Florian,
> 
> [snip]
> 
> > > Thus we should add an extension regarding the time of revocation
> > > checking - to allow the validation protocol to use OCSP while
> > fulfilling
> > > the DPV-DPD requirements:
> >
> > > "The client can request that the server determine the certificate
> > > validity at a time other than the current time. The DPV server MUST
> > > obtain revocation status information for the validation time in the
> > > client request." - DPV-DPD requirements document
> >
> > I do not think that adding a parameter in the request to specify a time
> > in the past (which is I guess what you are proposing) is necessary.
> 
> 
> I've never quite understood the utility of the archive cutoff value.
> 
> I find the "contribute to a proof" arguement, in section 4.4.4, rather
> vague. So I know the responder archives data for the last 7 years.

It is true that the text is not very explicit. The intent was not an archive
for 7 years.

> So what?
> 
> If I can't query the responder to see if a cert was revoked 6.5 years
> ago how does knowing the cutoff was 7 year ago really contribute to a proof
> 
> I think having a request parameter specify a time in the past better
> enables a client to take advantage of the cutoff information.  I can see
> it's not strictly necessary, but it would be really nice to have.
> 
> > A signature has to be validated close to the time it was made and thus
> > the revocation status information has to be captured close to that time.
> 
> I would argue this is too limiting.  If revocation information is
> archived then we shouldn't restrict an RP from getting that information
> no matter when the signature was created.
> 
> Here's an example (somewhat contrived):
> 
>   - Executive of company E signs some financial documents/contracts.
> 
>   - After a short time the certificate is revoked (say, the Executive
>     left the company).
> 
>   - A year later company E is under investigation for shady financial
>     dealings, which may include the above signed document.
> 
> Isn't it reasonable for the investigators to determine--a year after the
> signature was created--if the cert was revoked then?

A signature has to be checked as soon as possible. The problem is that you
can receive a signed e-mail while you are in vacations. I do not assume that
anyone is taking 7 years vacations. :-)

Let us assume that archive cutoff period to be set to a maximum of six
weaks. This means that when you come back for your 4 weeks vacations 
(2 weeks in your country), you can still check the revocation state of 
the certificate, even if the certificate was used the very last day of 
its validity period.
 
Denis
 
> > We already have the archive cutoff in case an OCSP responder chooses
> > to retain revocation information beyond a certificate's expiration.
> 
> My apologies if I've mis-understood some of these issues.
> 
> Jeff
> --
> Jeff Jacoby, Principal Programmer
> RSA Security Inc., SMDC                    [e-mail]
> 2955 Campus Dr., Ste. 400                  [phone]
> San Mateo, CA  94403


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8H7YUa10669 for ietf-pkix-bks; Tue, 17 Sep 2002 00:34:30 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H7YSk10662 for <[e-mail]>; Tue, 17 Sep 2002 00:34:29 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA28768; Tue, 17 Sep 2002 09:38:43 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091709333199:776 ; Tue, 17 Sep 2002 09:33:31 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 09:33:31 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 09:33:32, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 09:33:36, Serialize complete at 17/09/2002 09:33:36
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Peter,

> Denis Pinkas <[e-mail]> writes:
> 
> >OCSP v2 should NOT expand its possibilities beyond certificate revocation
> >checking and certainly should NOT try to expand its capabilities to cover
> >certificate validation.
> >
> >To be more precise, I do not care about the expired OCSP v2 draft, but I
> >care about fixing RFC 2560, while sticking to its original functionality:
> >individual certificate revocation information status check.
> >
> >Having said that, we should correct the major problem that exists in
> >RFC 2560, which is how the certificate can be defined.
> >
> >[...]
> 
> I agree with absolutely everything Denis has said.

Fine.
 
> [Pause.  Rereads post two more times]
> 
> Ah, I finally found something to disagree with: The tag for the OCTET STRING
> is redundant :-).
> 
> All OCSP really needs is a more usable way to identify certs, and the CRL
> locator would be useful too.  

Yes.

> Both of these are trivial additions to OCSP  which could be easily added 
> to 2560-bis, and don't require any v2, which was adding all sorts of other 
> stuff to the extent where it was almost a different protocol.  

Yes.

> If there's total opposition to making this tiny change to 2560-
> bis, and since no-one has spoken out for the current v2 draft, I'll do the new
> v2 draft myself (or do you want to do it Denis?).  It's only going to be a
> page or so of text by the looks of it.

Before doing it, it would be nice to agree on the additions to OCSP allowing 
more usable way to identify certs.

See my detailed response to Ambarish on that topic.

Then if we all agree, I would rather prefer that we first propose the role
of editor to one of the original authors. If no one volonteers, then your
proposal of being the lead editor should certainly be considered.

Regards,

Denis 

 
> Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8H7Vwp10326 for ietf-pkix-bks; Tue, 17 Sep 2002 00:31:58 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H7Vuk10319 for <[e-mail]>; Tue, 17 Sep 2002 00:31:56 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA16504; Tue, 17 Sep 2002 09:36:59 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091709314859:768 ; Tue, 17 Sep 2002 09:31:48 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 09:31:48 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
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: What happened to the OCSPv2 draft?
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 09:31:48, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/09/2002 09:31:51, Serialize complete at 17/09/2002 09:31:51
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Ambarish,

> Hi Denis,

>     To make this easier to read, I will skip the part we agree on.

Fine.
 
> Here is the controversial topic: Do we need multiple ways of
> identifying a certificate. My contention is no. We need to
> decide on one and use that.
> 
> I see 2 reasonable options:
> 1. The current cert serial number and issuer name/key hash
> 2. The full certificate

The very first question is whether the current way is reasonable: 
i.e. cert serial number + issuer name hash + issuer key hash.

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

I do not think it is.

It does not allow optimization of path checking. I would like a RP to be
able to send an OCSP request with only the certificate at hand. 

Today a path must first be constructed because the certificate only does not
allow to know the hash of the issuer's public key. 

Then, in order to make sure that the OCSP response is coming from the right
responder (in the case where the CA has designated its OCSP responders by
including id-kp-OCSPSigning in an extendedKeyUsage certificate extension
included in the OCSP response signer's certificates), the RP has to check
that the OCSP name included in the certificate matches the Name included in
the ResponderID: 

   ResponderID ::= CHOICE {
      byName               [1] Name,
      byKey                [2] KeyHash }

Alternatively, the RP has to check the KeyHash and for doing this.

In any case, the RP needs the OCSP certificate.
  
The certs field from the BasicOCSPResponse is only optional, and I would
make it mandatory  in the case where the CA has designated its OCSP
responders by including id-kp-OCSPSigning ... It would be nice for that
field to contain not only the OCSP responder certificate, but also the
certification chain. I already see Phill struggling to get that protocol
packaging into a single ethernet frame. Thus it would be nice to be able to
request the full chain, only when needed. This could be done using
requestExtensions.

In this way, the RP could validate the signature from the OCSP responder,
but much more important, when the OCSP request is not forwarded to another 
OCSP server, would get "for free" the certification path the verify the 
certificate that was under the original query, and could even get rid of 
using LDAP.

When the request is forwarded to another OCSP server, certs could include, 
upon request, another certification chain for the certificate under query 
up to a root key. This could be done using singleRequestExtensions.

Now let us come to the conclusion:

Option 1 does not fill the case mentioned above.
Option 2 of course does fill it.

What about an option 3 ?

pkix-rfc2560bis-01.txt defines Request as:

   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

The expired OCSPv2 draft was proposing to define: 

Request         ::=     SEQUENCE {
   reqCert                     ReqCert,
   singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

with:

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 }

In order to identify unambiguously a certificate, RFC 2634 is using the
right syntax:

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

with:

   IssuerSerial ::= SEQUENCE {
        issuer                   GeneralNames,
        serialNumber             CertificateSerialNumber
   }

This is a very compact form that Phill should like, despite it is in ASN.1. 
:-)

So let us come to my proposal for identifying a certificate:

Request         ::=     SEQUENCE {
   reqCert                     ReqCert,
   singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

with:

ReqCert  ::= CHOICE {
   certID            CertID,
   certIDwithHash    [0] ESSCertID,
   pKCert            [1] Certificate
   }

When ESSCertID (defined in RFC 2634) is used, then IssuerSerial is
mandatory.
 
> I know in the past folks from VeriSign hated the second option. I
> believe this was because their certs were pretty large (with
> statements about limitations of liability, etc.).
> 
> At this stage, given the work that has gone in OCSPv1, I don't
> think it is worthwhile digging up this controversy again. The
> current option works fine for OCSP as long as you aren't asking
> OCSP to also do path creation for you. If you have already
> created one or more certificate chains, it isn't very hard
> to figure out the CA's public key for any certificate in that
> chain.
 
> Makes sense?

No. Precisely for the reverse argument that I have used : when you do not
have already created one or more certificate chains, it is very hard to
figure out the CA's public key for any certificate in that chain.

Regards,

Denis

> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani                                         650.759.9045
> Malpani Consulting Services                      [e-mail]
> http://www.malpani.biz
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Friday, September 13, 2002 7:58 AM
> > To: Ambarish Malpani
> > Cc: [e-mail]
> > Subject: Re: What happened to the OCSPv2 draft?
> >
> >
> > Ambarish,
> >
> > > Oops - too many messages just while I am transitioning....
> > >
> > > Steve, if I remember correctly, what we agreed on was that
> > > badly designed extensions can screw up a perfectly good
> > > protocol. So can badly designed implementations....
> > >
> > > Denis, I like the suggestion about allowing a client to include
> > > the CRLDP extension in requests.
> >
> > Good. This is a point on which we both agree. :-)
> >
> > > I don't like the suggestion of
> > > providing multiple means of identifying certificates - it
> > > adds more interoperability problems and doesn't add much to
> > > the protocol - assuming that we agree that OCSP was meant to
> > > provide the status of a certificate.
> >
> > The current ways to specify the certificate are not that easy.
> >
> >    CertID ::=     SEQUENCE {
> >        hashAlgorithm       AlgorithmIdentifier,
> >        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> >        issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
> >        serialNumber        CertificateSerialNumber }
> >
> >    CertificateSerialNumber  ::=  INTEGER
> >
> > You cannot directly know the DN of the CA. You have to use a list of known
> > CAs and compute the hash over each of them to perform the match. This is a
> > severe limitation.
> >
> > > For the former, all we need to do is define the extension. That
> > > really doesn't need work on a OCSPv2 at all.
> >
> > I agree that, for defining an extension for handling a CRLDP extension in
> > requests, we do not need to define a v2 version, since it would be
> > applicable to v1.
> >
> > Regards,
> >
> > Denis
> >
> > > Regards,
> > > Ambarish
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]On Behalf Of Denis Pinkas
> > > > Sent: Thursday, September 12, 2002 1:48 AM
> > > > To: Stephen Kent
> > > > Cc: Peter Williams; '[e-mail] '
> > > > Subject: Re: What happened to the OCSPv2 draft?
> > > >
> > > >
> > > >
> > > > Steve,
> > > >
> > > > You said:
> > > >
> > > > "Ambarish later recalled that I warned him about the problems that
> > > > extensions to OCSP might engender, and he agreed that they had come
> > > > to cause problems."
> > > >
> > > > I do agree we you.
> > > >
> > > > To come back to technical issues, the expired OCSP v2 draft
> > was expanding
> > > > its possibilities beyond certificate revocation checking, whereas some
> > > > fixing on the deficiencies of RFC 2560 would have been needed, in
> > > > particular, as pointed by Peter, more ways to select the
> > certificate to be
> > > > checked.
> > > >
> > > > OCSP v2 should NOT expand its possibilities beyond
> > certificate revocation
> > > > checking and certainly should NOT try to expand its
> > capabilities to cover
> > > > certificate validation.
> > > >
> > > > To be more precise, I do not care about the expired OCSP v2
> > draft, but I
> > > > care about fixing RFC 2560, while sticking to its original
> > functionality:
> > > > individual certificate revocation information status check.
> > > >
> > > > Having said that, we should correct the major problem that exists in
> > > > RFC 2560, which is how the certificate can be defined.
> > > >
> > > > The proposal in the last draft
> > (draft-ietf-pkix-ocspv2-02.txt) was fine:
> > > >
> > > > 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 }
> > > >
> > > > In addition, RFC 2560 includes a serviceLocator request
> > extension, which
> > > > is nice when an OCSP service is supported in the background.
> > However, it
> > > > does not include any extension when a CRL is supported in the
> > background.
> > > > This means that the OCSP server cannot know in general where
> > the CRL to be
> > > > used is located.
> > > >
> > > > :-(
> > > >
> > > > One way would be to send the whole certificate (this is NOT
> > possible with
> > > > RFC 2560) so that the CDP can be extracted by the receiving OCSP
> > > > responder,
> > > > but another possibility would be to use an extension where the CDP
> > > > information present in the certificate would copied and pasted in that
> > > > extension. Then, using issuerSerial, the OCSP responder can
> > > > perform the CRL
> > > > check and to transform it into an OCSP response.
> > > >
> > > > Such extension would look like:
> > > >
> > > > ==================================================================
> > > > =========
> > > > 8.X     CRL Locator
> > > >
> > > > An OCSP server may be operated in a mode whereby the server receives a
> > > > request and fetches the CRL which authoritative for the identified
> > > > certificate. The crlLocator request extension is defined for this
> > > > purpose.
> > > > This extension is included as one of the singleRequestExtensions in
> > > > requests.
> > > >
> > > >    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }
> > > >
> > > >    CrlLocator ::= CRLDistributionPoints
> > > >
> > > > The value for this field is obtained from the corresponding
> > field in the
> > > > subject certificate.
> > > >
> > > > ==================================================================
> > > > =========
> > > >
> > > > So my proposal would be to issue a new OCSP v2 draft, only
> > > > including these
> > > > two changes. Anything else I forgot ?
> > > >
> > > > Regards,
> > > >
> > > > Denis
> > > >
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8H3sXA20826 for ietf-pkix-bks; Mon, 16 Sep 2002 20:54:33 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H3sWk20822 for <[e-mail]>; Mon, 16 Sep 2002 20:54:32 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8H3sUFR007310 for <[e-mail]>; Tue, 17 Sep 2002 15:54:30 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA05584 for [e-mail]; Tue, 17 Sep 2002 15:53:59 +1200 (NZST) (sender [e-mail])
Date: Tue, 17 Sep 2002 15:53:59 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [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>

Phil Griffin <[e-mail]> writes:

>Hoping to foment a groundswell of activity, I agree with Russ on this.

Hoping to foment a nice stress-relieving flamewar, I'll agree with Phil that
since PKIX will standardise anything with an ASN.1 syntax, we may as well do
this one as well.

Peter >:-).


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8H2fKO15598 for ietf-pkix-bks; Mon, 16 Sep 2002 19:41:20 -0700 (PDT)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H2fJk15592 for <[e-mail]>; Mon, 16 Sep 2002 19:41:19 -0700 (PDT)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id g8H2fFGk014895; Mon, 16 Sep 2002 19:41:16 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "David Hopwood" <[e-mail]>, <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Mon, 16 Sep 2002 19:50:45 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [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>

Hi David,
    That draft was put out long before the discussion about the
value of the nonce extension discussion came up.

I was planning to make that change when we got the author's 24
hour call.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of David Hopwood
> Sent: Saturday, September 14, 2002 6:13 PM
> To: [e-mail]
> Subject: Re: What happened to the OCSPv2 draft?
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Denis Pinkas wrote:
> > I do not care about OCSP v2: some documents die.
> >
> > However, I care with OCSP(v1)bis. The Yokohama meeting report states:
> >
> > "Roadmap, OCSP(v1)bis and PI documents in IESG queue."
> >
> > The document is available at:
> http://www.imc.org/draft-ietf-pkix-rfc2560bis
>
> I notice that this draft does not clarify the syntax of the nonce
> extension,
> as discussed on this list in May-June. (The conclusion was that
> clients should
> use an OCTET STRING as the encapsulated type.)
>
> - --
> David Hopwood <[e-mail]>
>
> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
> Nothing in this message is intended to be legally binding. If I revoke a
> public key but refuse to specify why, it is because the private
> key has been
> seized under the Regulation of Investigatory Powers Act; see
www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPYPeYzkCAxeYt5gVAQFoEgf+MS2l0tGK6R+yQQwxYKK9Rs7U1ZxxuFWC
TwozeeIB3JQyBul5dmgTL4vKMgOCqvf/4Yif9E92WRlyWTVFauy5YTQhJwCjJM2v
BtSvVAUBE2rHYi5wEGeu7bRSngJHwaPEF2M6+2fmdZ1MCLmdt9F+Nn95BWTu2peI
u1pZx8vn/IqHJ674I+Z9KmG7E0eqBbjjf3IP9j07h2LrpW/eOy9IyESv0zP2xSxn
pOmW4SijpRJeF2YVWVaryOz9hZzl93nyffZlBTE+qMseayuwah13tca1jzYFMY+j
zaf2oW7as38jQ1zNgl/BOoxOCGDf42IbfB3Wi2pNw9i3rDWQahbW4g==
=BbyB
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8H0b1s08278 for ietf-pkix-bks; Mon, 16 Sep 2002 17:37:01 -0700 (PDT)
Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g8H0awk08274 for <[e-mail]>; Mon, 16 Sep 2002 17:36:58 -0700 (PDT)
Received: (qmail 23349 invoked from network); 17 Sep 2002 00:35:32 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 17 Sep 2002 00:35:32 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Tue, 17 Sep 2002 11:36:03 +1100
Message-ID: <002d01c25de2$348e7aa0$[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.2377.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal
Sender: [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>

> Of course, there already is a more efficient encoding for XML
> markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
> shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
> and that exactly the same abstract values can be encoded in 
> 50+ bytes in
> DER. The obvious conclusion is that for every canonical DER 
> value there
> is a canonical XER encoding that yields an XMl markup 
> representation of 
> that same value.

It is important to note that it is a many-to-one mapping. For each
canonical XER encoding there are, in general, many DER encodings.
This comes about because the DER/BER encoding of TeletexString provides
many ways to represent the same string of abstract characters, and
all these alternatives have exactly the same representation in XER.

Consequently, taking a DER encoding, re-encoding in XER, and then
re-encoding in DER is not guaranteed to reproduce exactly the original
DER encoding. However, taking a canonical XER encoding, re-encoding in DER,
and then re-encoding in canonical XER will reproduce the original
canonical XER encoding.

Regards,
Steven



Received: by above.proper.com (8.11.6/8.11.3) id g8GNhF407249 for ietf-pkix-bks; Mon, 16 Sep 2002 16:43:15 -0700 (PDT)
Received: from anchor-post-39.mail.demon.net (anchor-post-39.mail.demon.net [194.217.242.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GNh8k07245 for <[e-mail]>; Mon, 16 Sep 2002 16:43:08 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=gemplus.com) by anchor-post-39.mail.demon.net with esmtp (Exim 3.36 #2) id 17r5Vr-0000pC-0U for [e-mail]; Tue, 17 Sep 2002 00:42:44 +0100
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 00:43:03 +0100
From: Dr S N Henson <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

I'll vote for #3 too.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



Received: by above.proper.com (8.11.6/8.11.3) id g8GLLMc29809 for ietf-pkix-bks; Mon, 16 Sep 2002 14:21:22 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GLLKk29803 for <[e-mail]>; Mon, 16 Sep 2002 14:21:20 -0700 (PDT)
Received: from MMyersLapTop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by mail.coastside.net  with SMTP id g8GLLKb8022876; Mon, 16 Sep 2002 14:21:20 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Steve Tuecke" <[e-mail]>, <[e-mail]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Mon, 16 Sep 2002 14:17:30 -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: <4.3.2.7.2.20020916141704.00b224e8@localhost>
Sender: [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>

Steve,

I think #3 is a good way to address this recurring class of
unmet needs.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Steve Tuecke
> Sent: Monday, September 16, 2002 12:42 PM
> To: [e-mail]
> Cc: Steve Tuecke
> Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
>
>
>
> All,
>
> A couple weeks ago, I proposed withdrawal of the
> Proxy Cert Profile from
> PKIX.  Russ argued against this, which led to posing
> the following
> straw-poll question:
>
> >Should PKIX sanction the advancement of a proxy cert
> draft based on the
> >current fundamental approach?  We can argue about
> the details more later,
> >but the fundamental approach at issue is whether it
> is reasonable to use
> >end-entity public key certificates to sign proxy
> certificates. Possible
> >answers are:
> >   1) No.
> >   2) Yes, but only as Informational Track.
> >   3) Yes, as Standards Track.
>
> There were 3 responses.  Russ Housley voted #3.
> Phill Hallam-Baker
> suggested forming a new working group, which I would
> put in the #1
> category.  Denis Pinkas responded, but did not
> explicitly vote for one of
> these choices -- his closest statement to a vote was
> 'I do not have [a
> problem with using end-entity public key certificates
> to sign proxy
> certificates] as long as the draft is using
> everywhere "proxy certificate"
> and is NOT using the terminology "public key certificate"'.
>
> So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
> apathy.  Anybody else care to weigh in on this issue?
>
> -Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8GL7xM29343 for ietf-pkix-bks; Mon, 16 Sep 2002 14:07:59 -0700 (PDT)
Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GL7wk29337 for <[e-mail]>; Mon, 16 Sep 2002 14:07:58 -0700 (PDT)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17r367-0008UH-00; Mon, 16 Sep 2002 17:07:59 -0400
Message-ID: <[e-mail]>
Date: Mon, 16 Sep 2002 17:07:57 -0400
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
To: Steve Tuecke <[e-mail]>
CC: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
References: <4.3.2.7.2.20020916141704.00b224e8@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [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>

Hoping to foment a groundswell of activity,
I agree with Russ on this.

Phil


Steve Tuecke wrote:

> 
> All,
> 
> A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from 
> PKIX.  Russ argued against this, which led to posing the following 
> straw-poll question:
> 
>> Should PKIX sanction the advancement of a proxy cert draft based on 
>> the current fundamental approach?  We can argue about the details more 
>> later, but the fundamental approach at issue is whether it is 
>> reasonable to use end-entity public key certificates to sign proxy 
>> certificates. Possible answers are:
>>   1) No.
>>   2) Yes, but only as Informational Track.
>>   3) Yes, as Standards Track.
> 
> 
> There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker 
> suggested forming a new working group, which I would put in the #1 
> category.  Denis Pinkas responded, but did not explicitly vote for one 
> of these choices -- his closest statement to a vote was 'I do not have 
> [a problem with using end-entity public key certificates to sign proxy 
> certificates] as long as the draft is using everywhere "proxy 
> certificate" and is NOT using the terminology "public key certificate"'.
> 
> So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of apathy.  
> Anybody else care to weigh in on this issue?
> 
> -Steve
> 
> At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
> 
>> Answer: Start a new group
>>
>> PKIX was formed to do one thing and has become a standing committee that
>> will do anything, provided it is in ASN.1 syntax. That is a bad thing.
>>
>> I would much prefer to see the group split into two. Continuing PKIX 
>> would
>> be tasked with simply moving the current RFCs through the standards 
>> track to
>> Draft and Standard. PKIX-EXT would be tasked with developing 
>> extensions to
>> PKIX where necessary.
>>
>>
>>                 Phill
> 
> 
> 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8GL5um29309 for ietf-pkix-bks; Mon, 16 Sep 2002 14:05:56 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GL5tk29304 for <[e-mail]>; Mon, 16 Sep 2002 14:05:55 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01470; Mon, 16 Sep 2002 15:05:57 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id RAA07535; Mon, 16 Sep 2002 17:05:56 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 16 Sep 2002 17:01:04 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Tuecke <[e-mail]>
CC: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
References: <4.3.2.7.2.20020916141704.00b224e8@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

> Should PKIX sanction the advancement of a proxy cert draft based
> on the current fundamental approach?  We can argue about the
> details more later, but the fundamental approach at issue is
> whether it is reasonable to use end-entity public key
> certificates to sign proxy certificates. Possible answers are:
>   1) No.
>   2) Yes, but only as Informational Track.
>   3) Yes, as Standards Track.

I'll vote for:

3) Yes, as Standards Track.

The proxy cert concept is a useful one. It will be increasingly
important as long-running programs (agents or services) need to
act on behalf of users.

I would prefer an approach that gave a CA certificate to
any user who might need to create a proxy certificate (with
name constraints or other limitations to restrict the
user's authority). This would allow the existing validation
algorithm to be employed. Revocation could be handled by an
shared CRL issuer, using indirect CRLs to remove most overhead,
or by a shared OCSP responder. However, I can live with the
"current fundamental approach".

My main concern is the lack of energy in the PKIX working
group for this effort. If we can't muster more response
than this, I'd say that Steve is right to take this work
elsewhere. The PKIX working group will just slow him down.
Individuals who are interested can join the GSI mailing lists.

Thanks,

Steve Hanna
Sun Microsystems, Inc.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8GK1vq27623 for ietf-pkix-bks; Mon, 16 Sep 2002 13:01:57 -0700 (PDT)
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GK1uk27619 for <[e-mail]>; Mon, 16 Sep 2002 13:01:56 -0700 (PDT)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17r243-0001nB-00; Mon, 16 Sep 2002 16:01:47 -0400
Message-ID: <[e-mail]>
Date: Mon, 16 Sep 2002 16:01:46 -0400
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [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>

Phillip,

Hallam-Baker, Phillip wrote:

> 
>>>I fail to see the value of an XML expression of deployed
>>>X.509 semantics. I fail to see the value of an ASN.1
>>>encoding to rival deployed XML specifications.
>>>
> 
>>I see much value in X.509 semantics, regardless of the
>>form of their expression. XML markup is just another
>>encoding rule for ASN.1 values.
>>
> 
> I still fail to see the advantage to an incompatible syntax
> for an existing deployed standard.


You misunderstand my statement. X9.68 supports all of
the X.509 certificate payloads required in the ISO 15782
profile for the fincvs industry. But the format is not
the same as that in the deployed X.509 standard. But a
DER encoding of some 170 bytes in X9.68 can carry the
same information content as that found in an 11-1200
byte X.509 certificate.


> ASN.1 is not such a barrier to deployment of PKI that any


I would say that given the freely available tools,
ASN.1 is hardly a barrier to deployment.

> party I am aware of is willing to forgo interoperability
> with the deployed X.509v3 base just for the sake of being
> able to avoid ASN.1 encoding.
> 
> The only justification for an incompatible data format is
> if the standard is going to support substantially different
> semantics that addresses a substantially different application
> domain, in the case of XKMS the specification is service
> oriented and the semantics are key centric as opposed to 
> certificate centric.


In the case of X9.68, the certificate format is domain
centric and not identity centric - there are no DNs, and
each domain certificate name uniquely identifies that
certificate as well as all of the certificates needed for
path validation.


> I don't believe that there is the slightest possibility
> that the Web Services community is going to adopt ASN.1
> as a compressed encoding layer. XML and ASN.1 are both 
> already complex enough without taking the cross product
> of both.


I'm sure that I am not alone in remaining hopeful that
the Web Services community will end up with viable,
efficient solutions that are simple and secure.

Phil


> 
> 		Phill
> 
> 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8GJidU27315 for ietf-pkix-bks; Mon, 16 Sep 2002 12:44:39 -0700 (PDT)
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GJibk27309 for <[e-mail]>; Mon, 16 Sep 2002 12:44:37 -0700 (PDT)
Received: from monkeyboy2001.mcs.anl.gov (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id OAA107308; Mon, 16 Sep 2002 14:44:29 -0500
Message-Id: <4.3.2.7.2.20020916141704.00b224e8@localhost>
X-Sender: tuecke@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 16 Sep 2002 14:41:40 -0500
To: [e-mail]
From: Steve Tuecke <[e-mail]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Cc: Steve Tuecke <[e-mail]>
In-Reply-To: <[e-mail] n.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

All,

A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from 
PKIX.  Russ argued against this, which led to posing the following 
straw-poll question:

>Should PKIX sanction the advancement of a proxy cert draft based on the 
>current fundamental approach?  We can argue about the details more later, 
>but the fundamental approach at issue is whether it is reasonable to use 
>end-entity public key certificates to sign proxy certificates. Possible 
>answers are:
>   1) No.
>   2) Yes, but only as Informational Track.
>   3) Yes, as Standards Track.

There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker 
suggested forming a new working group, which I would put in the #1 
category.  Denis Pinkas responded, but did not explicitly vote for one of 
these choices -- his closest statement to a vote was 'I do not have [a 
problem with using end-entity public key certificates to sign proxy 
certificates] as long as the draft is using everywhere "proxy certificate" 
and is NOT using the terminology "public key certificate"'.

So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of 
apathy.  Anybody else care to weigh in on this issue?

-Steve

At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
>Answer: Start a new group
>
>PKIX was formed to do one thing and has become a standing committee that
>will do anything, provided it is in ASN.1 syntax. That is a bad thing.
>
>I would much prefer to see the group split into two. Continuing PKIX would
>be tasked with simply moving the current RFCs through the standards track to
>Draft and Standard. PKIX-EXT would be tasked with developing extensions to
>PKIX where necessary.
>
>
>                 Phill



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8GJ95g26411 for ietf-pkix-bks; Mon, 16 Sep 2002 12:09:05 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8GJ93k26407 for <[e-mail]>; Mon, 16 Sep 2002 12:09:04 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Sep 2002 19:09:06 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA06354 for <[e-mail]>; Mon, 16 Sep 2002 15:09:05 -0400 (EDT)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8GJ6gj08610 for <[e-mail]>; Mon, 16 Sep 2002 15:06:42 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <S55T039V>; Mon, 16 Sep 2002 12:09:02 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPV4362; Mon, 16 Sep 2002 15:08:56 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 16 Sep 2002 15:08:51 -0400
Subject: FWD: ;binary a/b design teams' summary / recommendation review
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Please take any discussion of this topic to the LDAPbis mail list.  I post 
it here to ensure that everyone who cares about this issue is aware it.

Russ


-----Original Message-----
From: Kurt D. Zeilenga [mailto:[e-mail]]
Sent: Wednesday, May 08, 2002 7:04 PM
To: [e-mail]
Subject: ;binary a/b design teams' summary / recommendation review


Two design teams were formed to consider how to clarify the specification of
the ;binary (and other) transfer option features in the LDAP "core"
technical specification.
   http://www.openldap.org/lists/ietf-ldapbis/200204/msg00073.html

This message provides a brief summary of the teams discussions, a combined
recommendation, and initiates a 2-week WG discussion period to determine
whether the WG consensus supports adopting the teams' recommendation.  Both
design teams are now disbanded.

While each team mission was to produce alternative text, both teams worked
together to ensure each understood the issues and to determine the areas of
contention.  One key area was the semantics of all user attribute search
requests. One camp (a cross section of both teams), basically, thought that
a server should choose between returning either the native encoding (if
defined and supported) and the binary (if supported) encoding.  One camp
thought that a server should only return values in their native encoding (to
avoid interoperability caused by a server choice).  After much debate, it
was found that both approaches are problematic.  In short, the first
approach is problematic in that imperatives required to ensure
interoperability caused by the server choice would limit the general
usefulness of all user attribute search requests. The second approach is
problematic because it requires redefinition of all user attributes requests
in a manner inconsistent with the existing technical specification.

It was clear that the camps were deadlocked and that it
would be difficult for either camp to garner WG consensus.

Removal of the ;binary feature (and all mention of transfer
options) was then discussed.  The teams concluded that,
given the known interoperability problems with ;binary, limitations of the
;binary features, and the unsuitability of proposed revisions of its
technical specification, the ;binary feature (and all mention of transfer
options) should be removed from the technical specification.

The teams recognized that removal of the ;binary feature
would raise some backwards compatibility issues and is an
area which subsequent work may be appropriate to pursue.

The WG is to consider the teams' proposal to remove ;binary feature (and all
mention of transfer options).  A two-week comment period is hereby initiated
on this proposal ending 24 May 2002.  Based upon your comments, the WG
chairs will gauge WG consensus and take appropriate actions.

-- LDAPbis WG chairs 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8GHo4M20976 for ietf-pkix-bks; Mon, 16 Sep 2002 10:50:04 -0700 (PDT)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GHo3k20972 for <[e-mail]>; Mon, 16 Sep 2002 10:50:03 -0700 (PDT)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g8GHo2Ql019210; Mon, 16 Sep 2002 10:50:02 -0700 (PDT)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id <S7896C6A>; Mon, 16 Sep 2002 10:51:58 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Phil Griffin'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: What happened to the OCSPv2 draft?
Date: Mon, 16 Sep 2002 10:51:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

> > I fail to see the value of an XML expression of deployed
> > X.509 semantics. I fail to see the value of an ASN.1
> > encoding to rival deployed XML specifications.

> I see much value in X.509 semantics, regardless of the
> form of their expression. XML markup is just another
> encoding rule for ASN.1 values.

I still fail to see the advantage to an incompatible syntax
for an existing deployed standard.

ASN.1 is not such a barrier to deployment of PKI that any
party I am aware of is willing to forgo interoperability
with the deployed X.509v3 base just for the sake of being
able to avoid ASN.1 encoding.

The only justification for an incompatible data format is
if the standard is going to support substantially different
semantics that addresses a substantially different application
domain, in the case of XKMS the specification is service
oriented and the semantics are key centric as opposed to 
certificate centric.

I don't believe that there is the slightest possibility
that the Web Services community is going to adopt ASN.1
as a compressed encoding layer. XML and ASN.1 are both 
already complex enough without taking the cross product
of both.


		Phill


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8GHZJw20714 for ietf-pkix-bks; Mon, 16 Sep 2002 10:35:19 -0700 (PDT)
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GHZHk20710 for <[e-mail]>; Mon, 16 Sep 2002 10:35:18 -0700 (PDT)
Received: from user-0c8h20e.cable.mindspring.com ([24.136.136.14] helo=asn-1.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17qzmC-0002iK-00; Mon, 16 Sep 2002 13:35:12 -0400
Message-ID: <[e-mail]>
Date: Mon, 16 Sep 2002 13:35:12 -0400
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [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>

Hallam-Baker, Phillip wrote:

> Has any party commercial or non-comercial endorsed the 
> proposed 'standard' and committed to supporting it?


There are at least two firms that I am aware of that are
building support for this into their tools. Note that
X9.68 has only recently become a US national standard.
It is now being "proposed" as an international standard.

 
> It is one thing to get a bunch of people to agree to
> a proposal, quite another to persuade an industry to
> deploy.


Very true.


> I fail to see the value of an XML expression of deployed
> X.509 semantics. I fail to see the value of an ASN.1
> encoding to rival deployed XML specifications.
> 


I see much value in X.509 semantics, regardless of the
form of their expression. XML markup is just another
encoding rule for ASN.1 values.

Phil


> 		Phill
> 
> 
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]
>>Sent: Friday, September 13, 2002 4:19 PM
>>To: [e-mail]; [e-mail]; [e-mail];
>>[e-mail]
>>Subject: RE: What happened to the OCSPv2 draft?
>>
>>
>>Of course, there already is a more efficient encoding for XML
>>markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
>>shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
>>and that exactly the same abstract values can be encoded in 
>>50+ bytes in
>>DER. The obvious conclusion is that for every canonical DER 
>>value there
>>is a canonical XER encoding that yields an XMl markup 
>>representation of 
>>that same value. Clearly messages can be stored and transferrd in DER
>> (which is not a particularly compact ASN.1 encoding, but  
>>which enjoys
>> tools are cheap  and readily available) and exploded into 
>>XML markup in 
>>resource rich environments.
>>
>>This is the thrust of the OASIS XML Common Biometric Format, the 2002
>>revision of the X9.84 biometric information management and security , 
>>the X9.96 XML Cryptographic Message Syntax, and the  X9.95 
>>Trusted Time 
>>Stamp standards. It is also the core of the NWI proposal in 
>>ISO TC68/SC2 
>>based on the XMLEncoding Rules and the schema defined in the ASC X9.68
>>compressed domain certificate standard that moved forward in 
>>ISO this week.
>>If passed, this will result in a DER encoded certificate that is much
>>smaller
>>than the X.509 certificate format it is based on, and a 
>>completely XML 
>>certificate as well. The possibilities this will create to 
>>stir the pot
>>will be
>> interesting.
>> 
>>The idea of this approach is compelling for several reasons. 
>>It provides a
>>migration path into the XML space for ASN.1 defined specifications, it
>>allows
>>systems to be built  like my Biolojava tool kit that provide 
>>support  for
>>both XML
>>aware and ASN.1 aware applications, and it provides 
>>compression for XML
>>values. 
>>
>>But the really sweet  fallout of this is the simplicity of the XML
>>signature 
>>processing. It turns out to be almost equivalent  to the processing
>>description used currently for DER in the IETF SMIME standard. 
>>Anyone that can do SignedData using DER can, without nearly a
>>thought, do the same with XML markup and leverage the browser.
>>
>>And there are tools like mine emerging to support  these concepts, and
>>standards that will use them.
>>
>>Phil
>>
> 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8GH0vb19288 for ietf-pkix-bks; Mon, 16 Sep 2002 10:00:57 -0700 (PDT)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GH0tk19283 for <[e-mail]>; Mon, 16 Sep 2002 10:00:55 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id g8GH0u0Y022939 for <[e-mail]>; Mon, 16 Sep 2002 13:00:57 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 16 Sep 2002 12:57:01 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call:draft-ietf-pkix-wlan-extns-02.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Folks,

The authors have requested working group Last Call for the PKIX I-D 
"Wireless LAN Certificate Extensions and Attributes".  My review of network 
traffic since Yokohoma indicates that the new draft implements the minor 
changes requested by the list, and that there are no open issues.  IMHO, 
this document is ready to progress.

So, this email initiates a two week WG Last Call for "Wireless LAN 
Certificate Extensions and Attributes".  The current draft is available at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-02.txt

Thanks,

Tim Polk





At 07:46 AM 9/16/02 -0400, [e-mail] wrote:
>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           : Wireless LAN Certificate Extensions and Attributes
>         Author(s)       : R. Housley, T. Moore
>         Filename        : draft-ietf-pkix-wlan-extns-02.txt
>         Pages           : 8
>         Date            : 2002-9-13
>
>This document defines two EAP extended key usage values and a public
>key certificate extension to carry Wireless LAN (WLAN) System Service
>identifiers (SSIDs).
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-02.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-pkix-wlan-extns-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-wlan-extns-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.
>Content-Type: text/plain
>Content-ID:     <[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-pkix-wlan-extns-02.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-02.txt>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8GF2g213228 for ietf-pkix-bks; Mon, 16 Sep 2002 08:02:42 -0700 (PDT)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GF2ek13222 for <[e-mail]>; Mon, 16 Sep 2002 08:02:41 -0700 (PDT)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g8GF2cQl021493; Mon, 16 Sep 2002 08:02:39 -0700 (PDT)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id <S7895VA5>; Mon, 16 Sep 2002 08:04:34 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: What happened to the OCSPv2 draft?
Date: Mon, 16 Sep 2002 08:04:18 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

Has any party commercial or non-comercial endorsed the 
proposed 'standard' and committed to supporting it?

It is one thing to get a bunch of people to agree to
a proposal, quite another to persuade an industry to
deploy.

I fail to see the value of an XML expression of deployed
X.509 semantics. I fail to see the value of an ASN.1
encoding to rival deployed XML specifications.


		Phill


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, September 13, 2002 4:19 PM
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: What happened to the OCSPv2 draft?
> 
> 
> Of course, there already is a more efficient encoding for XML
> markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
> shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
> and that exactly the same abstract values can be encoded in 
> 50+ bytes in
> DER. The obvious conclusion is that for every canonical DER 
> value there
> is a canonical XER encoding that yields an XMl markup 
> representation of 
> that same value. Clearly messages can be stored and transferrd in DER
>  (which is not a particularly compact ASN.1 encoding, but  
> which enjoys
>  tools are cheap  and readily available) and exploded into 
> XML markup in 
> resource rich environments.
> 
> This is the thrust of the OASIS XML Common Biometric Format, the 2002
> revision of the X9.84 biometric information management and security , 
> the X9.96 XML Cryptographic Message Syntax, and the  X9.95 
> Trusted Time 
> Stamp standards. It is also the core of the NWI proposal in 
> ISO TC68/SC2 
> based on the XMLEncoding Rules and the schema defined in the ASC X9.68
> compressed domain certificate standard that moved forward in 
> ISO this week.
> If passed, this will result in a DER encoded certificate that is much
> smaller
> than the X.509 certificate format it is based on, and a 
> completely XML 
> certificate as well. The possibilities this will create to 
> stir the pot
> will be
>  interesting.
>  
> The idea of this approach is compelling for several reasons. 
> It provides a
> migration path into the XML space for ASN.1 defined specifications, it
> allows
> systems to be built  like my Biolojava tool kit that provide 
> support  for
> both XML
> aware and ASN.1 aware applications, and it provides 
> compression for XML
> values. 
> 
> But the really sweet  fallout of this is the simplicity of the XML
> signature 
> processing. It turns out to be almost equivalent  to the processing
> description used currently for DER in the IETF SMIME standard. 
> Anyone that can do SignedData using DER can, without nearly a
> thought, do the same with XML markup and leverage the browser.
> 
> And there are tools like mine emerging to support  these concepts, and
> standards that will use them.
> 
> Phil


Received: by above.proper.com (8.11.6/8.11.3) id g8GBmXe03026 for ietf-pkix-bks; Mon, 16 Sep 2002 04:48:33 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8GBmWk03019 for <[e-mail]>; Mon, 16 Sep 2002 04:48:32 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00845; Mon, 16 Sep 2002 07:46:48 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-wlan-extns-02.txt
Date: Mon, 16 Sep 2002 07:46:48 -0400
Sender: [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>

--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		: Wireless LAN Certificate Extensions and Attributes
	Author(s)	: R. Housley, T. Moore
	Filename	: draft-ietf-pkix-wlan-extns-02.txt
	Pages		: 8
	Date		: 2002-9-13
	
This document defines two EAP extended key usage values and a public
key certificate extension to carry Wireless LAN (WLAN) System Service
identifiers (SSIDs).

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-wlan-extns-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 localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8G24uv13788 for ietf-pkix-bks; Sun, 15 Sep 2002 19:04:56 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8G24sk13783 for <[e-mail]>; Sun, 15 Sep 2002 19:04:55 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8G24DFR006427; Mon, 16 Sep 2002 14:04:13 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA411456; Mon, 16 Sep 2002 14:03:43 +1200 (NZST) (sender [e-mail])
Date: Mon, 16 Sep 2002 14:03:43 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [e-mail], [e-mail]
Sender: [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>

Denis Pinkas <[e-mail]> writes:

>OCSP v2 should NOT expand its possibilities beyond certificate revocation
>checking and certainly should NOT try to expand its capabilities to cover
>certificate validation.
>
>To be more precise, I do not care about the expired OCSP v2 draft, but I
>care about fixing RFC 2560, while sticking to its original functionality:
>individual certificate revocation information status check.
>
>Having said that, we should correct the major problem that exists in
>RFC 2560, which is how the certificate can be defined.
>
>[...]

I agree with absolutely everything Denis has said.

[Pause.  Rereads post two more times]

Ah, I finally found something to disagree with: The tag for the OCTET STRING
is redundant :-).

All OCSP really needs is a more usable way to identify certs, and the CRL
locator would be useful too.  Both of these are trivial additions to OCSP
which could be easily added to 2560-bis, and don't require any v2, which was
adding all sorts of other stuff to the extent where it was almost a different
protocol.  If there's total opposition to making this tiny change to 2560-
bis, and since no-one has spoken out for the current v2 draft, I'll do the new
v2 draft myself (or do you want to do it Denis?).  It's only going to be a
page or so of text by the looks of it.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8G21sS13743 for ietf-pkix-bks; Sun, 15 Sep 2002 19:01:54 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8G21qk13739 for <[e-mail]>; Sun, 15 Sep 2002 19:01:52 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8G215FR006310; Mon, 16 Sep 2002 14:01:05 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA411296; Mon, 16 Sep 2002 14:00:31 +1200 (NZST) (sender [e-mail])
Date: Mon, 16 Sep 2002 14:00:31 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: What happened to the OCSPv2 draft?
Cc: [e-mail], [e-mail]
Sender: [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>

"Liaquat Khan" <[e-mail]> writes:

>I was thinking the OCSP responder could also use the serialNumber from the
>CertID to do this.

... except that the issuer DN has been smashed by the hashing, making it
impossible to locate the CRL even if you do know the serialNumber.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8G1vKp13600 for ietf-pkix-bks; Sun, 15 Sep 2002 18:57:20 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8G1vIk13595 for <[e-mail]>; Sun, 15 Sep 2002 18:57:18 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8G1uiFR006189; Mon, 16 Sep 2002 13:56:44 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id NAA411188; Mon, 16 Sep 2002 13:56:09 +1200 (NZST) (sender [e-mail])
Date: Mon, 16 Sep 2002 13:56:09 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: What happened to the OCSPv2 draft?
Cc: [e-mail]
Sender: [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>

"Hallam-Baker, Phillip" <[e-mail]> writes:

>>Todd's most recent effort was directed at removing me as chair of the
>>PKIX WG, by persuading someone to take my place, or create a new WG
>>for which I was not the chair, or to persuade the IESG or IAB that
>>PKIX was broken and needed to be fixed, and then, ultimately, to
>>convince the IAB & IESG that the IETF was broken and needed to be
>>fixed.
>
>And you foiled the plot by putting a fake timestamp on the moment at which
>the IESG and IAB were convinced?

He foiled the plot by using an X.509 cert from a public CA and having it
verified using COTS software (or was that how Todd started the plot?).

Peter :-).


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8F0NjK05550 for ietf-pkix-bks; Sat, 14 Sep 2002 17:23:45 -0700 (PDT)
Received: from mailout.zetnet.co.uk ([e-mail] [194.247.47.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8F0Nik05543 for <[e-mail]>; Sat, 14 Sep 2002 17:23:44 -0700 (PDT)
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by mailout.zetnet.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 17qNCU-0001dU-00 for <[e-mail]>; Sun, 15 Sep 2002 01:23:46 +0100
Received: from zetnet.co.uk (bts-0520.dialup.zetnet.co.uk [194.247.50.8]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g8F0Nif14744 for <[e-mail]>; Sun, 15 Sep 2002 01:23:44 +0100
Message-ID: <[e-mail]>
Date: Sun, 15 Sep 2002 01:12:44 +0000
From: David Hopwood <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

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

Denis Pinkas wrote:
> I do not care about OCSP v2: some documents die.
> 
> However, I care with OCSP(v1)bis. The Yokohama meeting report states:
> 
> "Roadmap, OCSP(v1)bis and PI documents in IESG queue."
> 
> The document is available at: http://www.imc.org/draft-ietf-pkix-rfc2560bis

I notice that this draft does not clarify the syntax of the nonce extension,
as discussed on this list in May-June. (The conclusion was that clients should
use an OCTET STRING as the encapsulated type.)

- -- 
David Hopwood <[e-mail]>

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


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPYPeYzkCAxeYt5gVAQFoEgf+MS2l0tGK6R+yQQwxYKK9Rs7U1ZxxuFWC
TwozeeIB3JQyBul5dmgTL4vKMgOCqvf/4Yif9E92WRlyWTVFauy5YTQhJwCjJM2v
BtSvVAUBE2rHYi5wEGeu7bRSngJHwaPEF2M6+2fmdZ1MCLmdt9F+Nn95BWTu2peI
u1pZx8vn/IqHJ674I+Z9KmG7E0eqBbjjf3IP9j07h2LrpW/eOy9IyESv0zP2xSxn
pOmW4SijpRJeF2YVWVaryOz9hZzl93nyffZlBTE+qMseayuwah13tca1jzYFMY+j
zaf2oW7as38jQ1zNgl/BOoxOCGDf42IbfB3Wi2pNw9i3rDWQahbW4g==
=BbyB
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DNJTX22280 for ietf-pkix-bks; Fri, 13 Sep 2002 16:19:29 -0700 (PDT)
Received: from relay3.softcomca.com (relay3.softcomca.com [168.144.1.70]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DNJQk22274 for <[e-mail]>; Fri, 13 Sep 2002 16:19:26 -0700 (PDT)
Received: from M2W052.mail2web.com ([168.144.108.52]) by relay3.softcomca.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 19:19:18 -0400
Message-ID: <[e-mail]>
X-Priority: 3
Reply-To: [e-mail]
X-Originating-IP: 193.115.10.150
X-URL: http://mail2web.com/
From: "[e-mail]" <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: What happened to the OCSPv2 draft?
Date: Fri, 13 Sep 2002 19:19:18 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
X-OriginalArrivalTime: 13 Sep 2002 23:19:18.0556 (UTC) FILETIME=[FBEDB5C0:01C25B7B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g8DNJQk22275
Sender: [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>

Of course, there already is a more efficient encoding for XML
markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
and that exactly the same abstract values can be encoded in 50+ bytes in
DER. The obvious conclusion is that for every canonical DER value there
is a canonical XER encoding that yields an XMl markup representation of 
that same value. Clearly messages can be stored and transferrd in DER
 (which is not a particularly compact ASN.1 encoding, but  which enjoys
 tools are cheap  and readily available) and exploded into XML markup in 
resource rich environments.

This is the thrust of the OASIS XML Common Biometric Format, the 2002
revision of the X9.84 biometric information management and security , 
the X9.96 XML Cryptographic Message Syntax, and the  X9.95 Trusted Time 
Stamp standards. It is also the core of the NWI proposal in ISO TC68/SC2 
based on the XMLEncoding Rules and the schema defined in the ASC X9.68
compressed domain certificate standard that moved forward in ISO this week.
If passed, this will result in a DER encoded certificate that is much
smaller
than the X.509 certificate format it is based on, and a completely XML 
certificate as well. The possibilities this will create to stir the pot
will be
 interesting.
 
The idea of this approach is compelling for several reasons. It provides a
migration path into the XML space for ASN.1 defined specifications, it
allows
systems to be built  like my Biolojava tool kit that provide support  for
both XML
aware and ASN.1 aware applications, and it provides compression for XML
values. 

But the really sweet  fallout of this is the simplicity of the XML
signature 
processing. It turns out to be almost equivalent  to the processing
description used currently for DER in the IETF SMIME standard. 
Anyone that can do SignedData using DER can, without nearly a
thought, do the same with XML markup and leverage the browser.

And there are tools like mine emerging to support  these concepts, and
standards that will use them.

Phil


Original Message:
-----------------
From: Hallam-Baker, Phillip [e-mail]
Date: Fri, 13 Sep 2002 09:46:35 -0700
To: [e-mail], [e-mail], [e-mail]
Subject: RE: What happened to the OCSPv2 draft?



No, I think it was because we have customers and the customers don't want to
send more data than is required, particularly the ones who are paying by the
kb over wireless links.

If you are using the 2048 bit RSA keys you have 512 bytes of incompressible
crypto information alone in a cert. You are going to struggle to get that
plus protocol packaging into a single ethernet frame.

If there is a point to developing another delegated path discovery and
validation algorithm it is to allow for shorter messages than XKMS in XML
text encoding. Of course we could just develop an efficient encoding for
XML.

		Phill

> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Friday, September 13, 2002 8:46 AM
> To: Denis Pinkas
> Cc: [e-mail]
> Subject: RE: What happened to the OCSPv2 draft?
> 
> 
> 
> 
> Hi Denis,
>     To make this easier to read, I will skip the part we agree on.
> 
> Here is the controversial topic: Do we need multiple ways of
> identifying a certificate. My contention is no. We need to
> decide on one and use that.
> 
> I see 2 reasonable options:
> 1. The current cert serial number and issuer name/key hash
> 2. The full certificate
> 
> I know in the past folks from VeriSign hated the second option. I
> believe this was because their certs were pretty large (with
> statements about limitations of liability, etc.).
> 
> At this stage, given the work that has gone in OCSPv1, I don't
> think it is worthwhile digging up this controversy again. The
> current option works fine for OCSP as long as you aren't asking
> OCSP to also do path creation for you. If you have already
> created one or more certificate chains, it isn't very hard
> to figure out the CA's public key for any certificate in that
> chain.
> 
> Makes sense?
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani                                         650.759.9045
> Malpani Consulting Services                      [e-mail]
> http://www.malpani.biz
> 
> 
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Friday, September 13, 2002 7:58 AM
> > To: Ambarish Malpani
> > Cc: [e-mail]
> > Subject: Re: What happened to the OCSPv2 draft?
> >
> >
> > Ambarish,
> >
> > > Oops - too many messages just while I am transitioning....
> > >
> > > Steve, if I remember correctly, what we agreed on was that
> > > badly designed extensions can screw up a perfectly good
> > > protocol. So can badly designed implementations....
> > >
> > > Denis, I like the suggestion about allowing a client to include
> > > the CRLDP extension in requests.
> >
> > Good. This is a point on which we both agree. :-)
> >
> > > I don't like the suggestion of
> > > providing multiple means of identifying certificates - it
> > > adds more interoperability problems and doesn't add much to
> > > the protocol - assuming that we agree that OCSP was meant to
> > > provide the status of a certificate.
> >
> > The current ways to specify the certificate are not that easy.
> >
> >    CertID ::=     SEQUENCE {
> >        hashAlgorithm       AlgorithmIdentifier,
> >        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> >        issuerKeyHash       OCTET STRING, -- Hash of Issuers 
> public key
> >        serialNumber        CertificateSerialNumber }
> >
> >    CertificateSerialNumber  ::=  INTEGER
> >
> > You cannot directly know the DN of the CA. You have to use 
> a list of known
> > CAs and compute the hash over each of them to perform the 
> match. This is a
> > severe limitation.
> >
> > > For the former, all we need to do is define the extension. That
> > > really doesn't need work on a OCSPv2 at all.
> >
> > I agree that, for defining an extension for handling a 
> CRLDP extension in
> > requests, we do not need to define a v2 version, since it would be
> > applicable to v1.
> >
> > Regards,
> >
> > Denis
> >
> > > Regards,
> > > Ambarish
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]On Behalf Of Denis Pinkas
> > > > Sent: Thursday, September 12, 2002 1:48 AM
> > > > To: Stephen Kent
> > > > Cc: Peter Williams; '[e-mail] '
> > > > Subject: Re: What happened to the OCSPv2 draft?
> > > >
> > > >
> > > >
> > > > Steve,
> > > >
> > > > You said:
> > > >
> > > > "Ambarish later recalled that I warned him about the 
> problems that
> > > > extensions to OCSP might engender, and he agreed that 
> they had come
> > > > to cause problems."
> > > >
> > > > I do agree we you.
> > > >
> > > > To come back to technical issues, the expired OCSP v2 draft
> > was expanding
> > > > its possibilities beyond certificate revocation 
> checking, whereas some
> > > > fixing on the deficiencies of RFC 2560 would have been 
> needed, in
> > > > particular, as pointed by Peter, more ways to select the
> > certificate to be
> > > > checked.
> > > >
> > > > OCSP v2 should NOT expand its possibilities beyond
> > certificate revocation
> > > > checking and certainly should NOT try to expand its
> > capabilities to cover
> > > > certificate validation.
> > > >
> > > > To be more precise, I do not care about the expired OCSP v2
> > draft, but I
> > > > care about fixing RFC 2560, while sticking to its original
> > functionality:
> > > > individual certificate revocation information status check.
> > > >
> > > > Having said that, we should correct the major problem 
> that exists in
> > > > RFC 2560, which is how the certificate can be defined.
> > > >
> > > > The proposal in the last draft
> > (draft-ietf-pkix-ocspv2-02.txt) was fine:
> > > >
> > > > 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 }
> > > >
> > > > In addition, RFC 2560 includes a serviceLocator request
> > extension, which
> > > > is nice when an OCSP service is supported in the background.
> > However, it
> > > > does not include any extension when a CRL is supported in the
> > background.
> > > > This means that the OCSP server cannot know in general where
> > the CRL to be
> > > > used is located.
> > > >
> > > > :-(
> > > >
> > > > One way would be to send the whole certificate (this is NOT
> > possible with
> > > > RFC 2560) so that the CDP can be extracted by the receiving OCSP
> > > > responder,
> > > > but another possibility would be to use an extension 
> where the CDP
> > > > information present in the certificate would copied and 
> pasted in that
> > > > extension. Then, using issuerSerial, the OCSP responder can
> > > > perform the CRL
> > > > check and to transform it into an OCSP response.
> > > >
> > > > Such extension would look like:
> > > >
> > > > 
> ==================================================================
> > > > =========
> > > > 8.X     CRL Locator
> > > >
> > > > An OCSP server may be operated in a mode whereby the 
> server receives a
> > > > request and fetches the CRL which authoritative for the 
> identified
> > > > certificate. The crlLocator request extension is 
> defined for this
> > > > purpose.
> > > > This extension is included as one of the 
> singleRequestExtensions in
> > > > requests.
> > > >
> > > >    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { 
> id-pkix-ocsp X }
> > > >
> > > >    CrlLocator ::= CRLDistributionPoints
> > > >
> > > > The value for this field is obtained from the corresponding
> > field in the
> > > > subject certificate.
> > > >
> > > > 
> ==================================================================
> > > > =========
> > > >
> > > > So my proposal would be to issue a new OCSP v2 draft, only
> > > > including these
> > > > two changes. Anything else I forgot ?
> > > >
> > > > Regards,
> > > >
> > > > Denis
> > > >
> >
> 

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DIiRK08743 for ietf-pkix-bks; Fri, 13 Sep 2002 11:44:27 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8DIiMk08737 for <[e-mail]>; Fri, 13 Sep 2002 11:44:26 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Sep 2002 18:44: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 OAA06106 for <[e-mail]>; Fri, 13 Sep 2002 14:44:23 -0400 (EDT)
Received: from rsasecurity.com (vanquish.rsa.com [10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id LAA27485 for <[e-mail]>; Fri, 13 Sep 2002 11:54:40 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 13 Sep 2002 11:43:15 -0700
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] '" <[e-mail]>
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

Denis Pinkas wrote:
> 
> Florian,

[snip]

> > Thus we should add an extension regarding the time of revocation
> > checking - to allow the validation protocol to use OCSP while
> fulfilling
> > the DPV-DPD requirements:
> 
> > "The client can request that the server determine the certificate
> > validity at a time other than the current time. The DPV server MUST
> > obtain revocation status information for the validation time in the
> > client request." - DPV-DPD requirements document
> 
> I do not think that adding a parameter in the request to specify a time
> in
> the past (which is I guess what you are proposing) is necessary.
> 

I've never quite understood the utility of the archive cutoff value.

I find the "contribute to a proof" arguement, in section 4.4.4, rather
vague.  
So I know the responder archives data for the last 7 years.  

So what?  

If I can't query the responder to see if a cert was revoked 6.5 years
ago
how does knowing the cutoff was 7 year ago really contribute to a proof

I think having a request parameter specify a time in the past better 
enables a client to take advantage of the cutoff information.  I can see 
it's not strictly necessary, but it would be really nice to have.

> A signature has to be validated close to the time it was made and thus
> the
> revocation status information has to be captured close to that time.

I would argue this is too limiting.  If revocation information is
archived then we shouldn't restrict an RP from getting that information
no matter when the signature was created.

Here's an example (somewhat contrived):  

  - Executive of company E signs some financial documents/contracts.

  - After a short time the certificate is revoked (say, the Executive
    left the company).

  - A year later company E is under investigation for shady financial
    dealings, which may include the above signed document.

Isn't it reasonable for the investigators to determine--a year after the
signature was created--if the cert was revoked then?

> We already have the archive cutoff in case an OCSP responder chooses
> to retain revocation information beyond a certificate's expiration.

My apologies if I've mis-understood some of these issues.

Jeff
-- 
Jeff Jacoby, Principal Programmer                
RSA Security Inc., SMDC                    [e-mail]
2955 Campus Dr., Ste. 400                  [phone]
San Mateo, CA  94403


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DGs3X02051 for ietf-pkix-bks; Fri, 13 Sep 2002 09:54:03 -0700 (PDT)
Received: from mail.hackmasters.net (ppp-217-133-229-253.dialup.tiscali.it [217.133.229.253]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DGs0k02041 for <[e-mail]>; Fri, 13 Sep 2002 09:54:00 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id E4B5BF358; Fri, 13 Sep 2002 18:55:16 +0200 (CEST)
Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id 7EEB6F354; Fri, 13 Sep 2002 18:55:04 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 13 Sep 2002 18:55:27 +0200
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Marc Poulaud <[e-mail]>
Cc: [e-mail]
Subject: Re: CDP CRL format?
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040803070005060000010009"
X-Virus-Scanned: by AMaViS perl-11
Sender: [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>

This is a cryptographically signed message in MIME format.

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

Marc Poulaud wrote:
> In relation to a CRL that is pointed at by the URI contained in a cert's 
> CDP, what *typically* might you expect the format of the CRL to be in? 
> I'd thought this would be an x.509x2 CRL wrapped in a PKCS#7.
>  
> Do some applications or platforms expect/want something else?

Some applications do want Base64 or binary DER encoded CRLs (Netscape does).

> I've noticed that on a particular server that hold CRLs (from a Verisign 
> CA), there are a number of files of different formats. One file is 
> LatestCRL and another is LatestCRL.crl (amongst others). Anybody know 
> what the difference might be?

Probably to handle the mimetype directly within the web-server (take a look
at the .crl datatype handling in the example apache config file).

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [e-mail]
                                                      [e-mail]
http://www.openca.org                            Tel.:   [phone]
http://openca.sourceforge.net                    Mobile: [phone]

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMCjCC
BNMwggO7oAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UEBhMCSVQxGDAWBgNVBAoT
D0hhY2ttYXN0ZXJzLm5ldDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN
MDIwODA0MDkxNzEyWhcNMDMwODA0MDkxNzEyWjBmMQswCQYDVQQGEwJJVDEYMBYGA1UEChMP
SGFja21hc3RlcnMubmV0MRQwEgYDVQQLEwtUcnVzdGNlbnRlcjEaMBgGA1UEAxMRTWFzc2lt
aWxpYW5vIFBhbGExCzAJBgNVBAUTAjAyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6
LQwcyGanZZvp3VgStM297TyD/gPCwmOxs0mnqDWMlqoRvRSjqx9NI8AbA6MnxfO8w8GsT55C
G8BmaYrmosbJHBLGsX6XF2lzy4uk6bf+5FzRK++yyOSuIsWSTckkZFTzPuYRrv/zKp62qfD4
Qxc3Wk1KKEAy/5Z7tH7wLKyd3wIDAQABo4ICKzCCAicwCQYDVR0TBAIwADARBglghkgBhvhC
AQEEBAMCBLAwCwYDVR0PBAQDAgXgMEEGCWCGSAGG+EIBDQQ0FjJSZWdpc3RyYXRpb24gQXV0
aG9yaXR5IE9wZXJhdG9yIG9mIEhhY2ttYXN0ZXJzLm5ldDAdBgNVHQ4EFgQUZDKIv2Wbml4L
pp3fjm45od/lp/UwcQYDVR0jBGowaIAUYXb9wMMvaaXHhMxACEZY0aSMoBahTaRLMEkxCzAJ
BgNVBAYTAklUMRgwFgYDVQQKEw9IYWNrbWFzdGVycy5uZXQxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5ggEAMCIGA1UdEQQbMBmBF21hZHdvbGZAaGFja21hc3RlcnMubmV0
MAkGA1UdEgQCMAAwUAYJYIZIAYb4QgEEBEMWQWh0dHBzOi8vZ2FsYWRyaWVsLm1wbmV0Lmhh
Y2ttYXN0ZXJzLm5ldC9jZ2ktYmluL3B1Yi9jcmwvY2FjcmwuY3JsMFAGCWCGSAGG+EIBAwRD
FkFodHRwczovL2dhbGFkcmllbC5tcG5ldC5oYWNrbWFzdGVycy5uZXQvY2dpLWJpbi9wdWIv
Y3JsL2NhY3JsLmNybDBSBgNVHR8ESzBJMEegRaBDhkFodHRwczovL2dhbGFkcmllbC5tcG5l
dC5oYWNrbWFzdGVycy5uZXQvY2dpLWJpbi9wdWIvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0B
AQUFAAOCAQEAd9Dxc3gMPFCl4yNFeMbUHAfpHQszDdyLMjblnxHxDxW3V8dCPEXwehFW+Q15
PmP1CokOS5dUoM9NHOWmw9c244rAIUM7Kogx/9NwMEYUtApzqaciqKAsDFdifNjhUc0qws7n
t7CoSgma3I2U+0jq0rd9hr4qMiWTA/eEaN6Xb9CIKkBQb4wlQFTVI39ZSi8x7frEhsNjjTfq
Yu/DwMh3+uUNr4uT4b/9o1Fk0g5O6mq8TaVWsqNlkp/MGNXUBhcHvaazDiwviwIBcb+/u1sK
l/P8Sh7F8ivM9uFvEfCFYv7GedURDcA4qca6Z3aQmwCKnPLg6e9dDQk8uSYVqFH6BDCCBy8w
ggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh
aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu
MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE
BhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMRTWFz
c2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlhIGRl
bGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMlVW5p
dmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOml//l
WMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23KS3Oa
7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQBMIID
/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo14pK
LqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEiMCAG
CSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBFbnRl
IGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEgZSBS
ZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0dG8g
UG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVn
Z2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhhY2tt
YXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8vcGtp
LnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2kudW5p
bW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2kudW5p
bW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmltby5p
dC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0L2Ny
bC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVuZXdh
bDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYDVR0g
BIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJvcGtp
Lm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYlaHR0
cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYwNAYI
KwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0wDQYJ
KoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueexIe6H
U+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqrRZKA
jIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+SNoTy
TXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSLoVHW
4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxImVVp
aaYxggJNMIICSQIBATCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5p
dDEnMCUGA1UEAxMeVW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVV
bml2ZXJzaXRhJyBkaSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDAJ
BgUrDgMCGgUAoIIBEjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wMjA5MTMxNjU1MzBaMCMGCSqGSIb3DQEJBDEWBBS7rIX7v6/6IhnBCvlIta+O2NLPxzBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDBfBgsqhkiG9w0BCRACCzFQoE4wSTELMAkG
A1UEBhMCSVQxGDAWBgNVBAoTD0hhY2ttYXN0ZXJzLm5ldDEgMB4GA1UEAxMXQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkCAQIwDQYJKoZIhvcNAQEBBQAEgYCwjW9peX5bwKIHbPPVE/TdQIrL
g14Zsy2L0qkqa/YG/c611ogX64iHMXcSANJVQ88MpRthnak9RbUzOvfFt17ExyN9uQNa4/ZV
S/a6j/jlBzdBeTMKl+w6blA7F9I0qMn8Iw19oKFtGGVp74D5lFFPlXDZ9QRoRgnydzPPb5bx
PQAAAAAAAA==
--------------ms040803070005060000010009--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DGioc01479 for ietf-pkix-bks; Fri, 13 Sep 2002 09:44:50 -0700 (PDT)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DGimk01474 for <[e-mail]>; Fri, 13 Sep 2002 09:44:48 -0700 (PDT)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g8DGioZc007010; Fri, 13 Sep 2002 09:44:50 -0700 (PDT)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id <SYYWWT50>; Fri, 13 Sep 2002 09:46:43 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: What happened to the OCSPv2 draft?
Date: Fri, 13 Sep 2002 09:46:35 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

No, I think it was because we have customers and the customers don't want to
send more data than is required, particularly the ones who are paying by the
kb over wireless links.

If you are using the 2048 bit RSA keys you have 512 bytes of incompressible
crypto information alone in a cert. You are going to struggle to get that
plus protocol packaging into a single ethernet frame.

If there is a point to developing another delegated path discovery and
validation algorithm it is to allow for shorter messages than XKMS in XML
text encoding. Of course we could just develop an efficient encoding for
XML.

		Phill

> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Friday, September 13, 2002 8:46 AM
> To: Denis Pinkas
> Cc: [e-mail]
> Subject: RE: What happened to the OCSPv2 draft?
> 
> 
> 
> 
> Hi Denis,
>     To make this easier to read, I will skip the part we agree on.
> 
> Here is the controversial topic: Do we need multiple ways of
> identifying a certificate. My contention is no. We need to
> decide on one and use that.
> 
> I see 2 reasonable options:
> 1. The current cert serial number and issuer name/key hash
> 2. The full certificate
> 
> I know in the past folks from VeriSign hated the second option. I
> believe this was because their certs were pretty large (with
> statements about limitations of liability, etc.).
> 
> At this stage, given the work that has gone in OCSPv1, I don't
> think it is worthwhile digging up this controversy again. The
> current option works fine for OCSP as long as you aren't asking
> OCSP to also do path creation for you. If you have already
> created one or more certificate chains, it isn't very hard
> to figure out the CA's public key for any certificate in that
> chain.
> 
> Makes sense?
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani                                         650.759.9045
> Malpani Consulting Services                      [e-mail]
> http://www.malpani.biz
> 
> 
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Friday, September 13, 2002 7:58 AM
> > To: Ambarish Malpani
> > Cc: [e-mail]
> > Subject: Re: What happened to the OCSPv2 draft?
> >
> >
> > Ambarish,
> >
> > > Oops - too many messages just while I am transitioning....
> > >
> > > Steve, if I remember correctly, what we agreed on was that
> > > badly designed extensions can screw up a perfectly good
> > > protocol. So can badly designed implementations....
> > >
> > > Denis, I like the suggestion about allowing a client to include
> > > the CRLDP extension in requests.
> >
> > Good. This is a point on which we both agree. :-)
> >
> > > I don't like the suggestion of
> > > providing multiple means of identifying certificates - it
> > > adds more interoperability problems and doesn't add much to
> > > the protocol - assuming that we agree that OCSP was meant to
> > > provide the status of a certificate.
> >
> > The current ways to specify the certificate are not that easy.
> >
> >    CertID ::=     SEQUENCE {
> >        hashAlgorithm       AlgorithmIdentifier,
> >        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> >        issuerKeyHash       OCTET STRING, -- Hash of Issuers 
> public key
> >        serialNumber        CertificateSerialNumber }
> >
> >    CertificateSerialNumber  ::=  INTEGER
> >
> > You cannot directly know the DN of the CA. You have to use 
> a list of known
> > CAs and compute the hash over each of them to perform the 
> match. This is a
> > severe limitation.
> >
> > > For the former, all we need to do is define the extension. That
> > > really doesn't need work on a OCSPv2 at all.
> >
> > I agree that, for defining an extension for handling a 
> CRLDP extension in
> > requests, we do not need to define a v2 version, since it would be
> > applicable to v1.
> >
> > Regards,
> >
> > Denis
> >
> > > Regards,
> > > Ambarish
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]On Behalf Of Denis Pinkas
> > > > Sent: Thursday, September 12, 2002 1:48 AM
> > > > To: Stephen Kent
> > > > Cc: Peter Williams; '[e-mail] '
> > > > Subject: Re: What happened to the OCSPv2 draft?
> > > >
> > > >
> > > >
> > > > Steve,
> > > >
> > > > You said:
> > > >
> > > > "Ambarish later recalled that I warned him about the 
> problems that
> > > > extensions to OCSP might engender, and he agreed that 
> they had come
> > > > to cause problems."
> > > >
> > > > I do agree we you.
> > > >
> > > > To come back to technical issues, the expired OCSP v2 draft
> > was expanding
> > > > its possibilities beyond certificate revocation 
> checking, whereas some
> > > > fixing on the deficiencies of RFC 2560 would have been 
> needed, in
> > > > particular, as pointed by Peter, more ways to select the
> > certificate to be
> > > > checked.
> > > >
> > > > OCSP v2 should NOT expand its possibilities beyond
> > certificate revocation
> > > > checking and certainly should NOT try to expand its
> > capabilities to cover
> > > > certificate validation.
> > > >
> > > > To be more precise, I do not care about the expired OCSP v2
> > draft, but I
> > > > care about fixing RFC 2560, while sticking to its original
> > functionality:
> > > > individual certificate revocation information status check.
> > > >
> > > > Having said that, we should correct the major problem 
> that exists in
> > > > RFC 2560, which is how the certificate can be defined.
> > > >
> > > > The proposal in the last draft
> > (draft-ietf-pkix-ocspv2-02.txt) was fine:
> > > >
> > > > 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 }
> > > >
> > > > In addition, RFC 2560 includes a serviceLocator request
> > extension, which
> > > > is nice when an OCSP service is supported in the background.
> > However, it
> > > > does not include any extension when a CRL is supported in the
> > background.
> > > > This means that the OCSP server cannot know in general where
> > the CRL to be
> > > > used is located.
> > > >
> > > > :-(
> > > >
> > > > One way would be to send the whole certificate (this is NOT
> > possible with
> > > > RFC 2560) so that the CDP can be extracted by the receiving OCSP
> > > > responder,
> > > > but another possibility would be to use an extension 
> where the CDP
> > > > information present in the certificate would copied and 
> pasted in that
> > > > extension. Then, using issuerSerial, the OCSP responder can
> > > > perform the CRL
> > > > check and to transform it into an OCSP response.
> > > >
> > > > Such extension would look like:
> > > >
> > > > 
> ==================================================================
> > > > =========
> > > > 8.X     CRL Locator
> > > >
> > > > An OCSP server may be operated in a mode whereby the 
> server receives a
> > > > request and fetches the CRL which authoritative for the 
> identified
> > > > certificate. The crlLocator request extension is 
> defined for this
> > > > purpose.
> > > > This extension is included as one of the 
> singleRequestExtensions in
> > > > requests.
> > > >
> > > >    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { 
> id-pkix-ocsp X }
> > > >
> > > >    CrlLocator ::= CRLDistributionPoints
> > > >
> > > > The value for this field is obtained from the corresponding
> > field in the
> > > > subject certificate.
> > > >
> > > > 
> ==================================================================
> > > > =========
> > > >
> > > > So my proposal would be to issue a new OCSP v2 draft, only
> > > > including these
> > > > two changes. Anything else I forgot ?
> > > >
> > > > Regards,
> > > >
> > > > Denis
> > > >
> >
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DFb5t26051 for ietf-pkix-bks; Fri, 13 Sep 2002 08:37:05 -0700 (PDT)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DFb2k26039 for <[e-mail]>; Fri, 13 Sep 2002 08:37:02 -0700 (PDT)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id g8DFaPGk004560; Fri, 13 Sep 2002 08:36:25 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Fri, 13 Sep 2002 08:45:51 -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 V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [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>

Hi Denis,
    To make this easier to read, I will skip the part we agree on.

Here is the controversial topic: Do we need multiple ways of
identifying a certificate. My contention is no. We need to
decide on one and use that.

I see 2 reasonable options:
1. The current cert serial number and issuer name/key hash
2. The full certificate

I know in the past folks from VeriSign hated the second option. I
believe this was because their certs were pretty large (with
statements about limitations of liability, etc.).

At this stage, given the work that has gone in OCSPv1, I don't
think it is worthwhile digging up this controversy again. The
current option works fine for OCSP as long as you aren't asking
OCSP to also do path creation for you. If you have already
created one or more certificate chains, it isn't very hard
to figure out the CA's public key for any certificate in that
chain.

Makes sense?
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [e-mail]
http://www.malpani.biz



> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Friday, September 13, 2002 7:58 AM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: Re: What happened to the OCSPv2 draft?
>
>
> Ambarish,
>
> > Oops - too many messages just while I am transitioning....
> >
> > Steve, if I remember correctly, what we agreed on was that
> > badly designed extensions can screw up a perfectly good
> > protocol. So can badly designed implementations....
> >
> > Denis, I like the suggestion about allowing a client to include
> > the CRLDP extension in requests.
>
> Good. This is a point on which we both agree. :-)
>
> > I don't like the suggestion of
> > providing multiple means of identifying certificates - it
> > adds more interoperability problems and doesn't add much to
> > the protocol - assuming that we agree that OCSP was meant to
> > provide the status of a certificate.
>
> The current ways to specify the certificate are not that easy.
>
>    CertID ::=     SEQUENCE {
>        hashAlgorithm       AlgorithmIdentifier,
>        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
>        issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
>        serialNumber        CertificateSerialNumber }
>
>    CertificateSerialNumber  ::=  INTEGER
>
> You cannot directly know the DN of the CA. You have to use a list of known
> CAs and compute the hash over each of them to perform the match. This is a
> severe limitation.
>
> > For the former, all we need to do is define the extension. That
> > really doesn't need work on a OCSPv2 at all.
>
> I agree that, for defining an extension for handling a CRLDP extension in
> requests, we do not need to define a v2 version, since it would be
> applicable to v1.
>
> Regards,
>
> Denis
>
> > Regards,
> > Ambarish
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf Of Denis Pinkas
> > > Sent: Thursday, September 12, 2002 1:48 AM
> > > To: Stephen Kent
> > > Cc: Peter Williams; '[e-mail] '
> > > Subject: Re: What happened to the OCSPv2 draft?
> > >
> > >
> > >
> > > Steve,
> > >
> > > You said:
> > >
> > > "Ambarish later recalled that I warned him about the problems that
> > > extensions to OCSP might engender, and he agreed that they had come
> > > to cause problems."
> > >
> > > I do agree we you.
> > >
> > > To come back to technical issues, the expired OCSP v2 draft
> was expanding
> > > its possibilities beyond certificate revocation checking, whereas some
> > > fixing on the deficiencies of RFC 2560 would have been needed, in
> > > particular, as pointed by Peter, more ways to select the
> certificate to be
> > > checked.
> > >
> > > OCSP v2 should NOT expand its possibilities beyond
> certificate revocation
> > > checking and certainly should NOT try to expand its
> capabilities to cover
> > > certificate validation.
> > >
> > > To be more precise, I do not care about the expired OCSP v2
> draft, but I
> > > care about fixing RFC 2560, while sticking to its original
> functionality:
> > > individual certificate revocation information status check.
> > >
> > > Having said that, we should correct the major problem that exists in
> > > RFC 2560, which is how the certificate can be defined.
> > >
> > > The proposal in the last draft
> (draft-ietf-pkix-ocspv2-02.txt) was fine:
> > >
> > > 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 }
> > >
> > > In addition, RFC 2560 includes a serviceLocator request
> extension, which
> > > is nice when an OCSP service is supported in the background.
> However, it
> > > does not include any extension when a CRL is supported in the
> background.
> > > This means that the OCSP server cannot know in general where
> the CRL to be
> > > used is located.
> > >
> > > :-(
> > >
> > > One way would be to send the whole certificate (this is NOT
> possible with
> > > RFC 2560) so that the CDP can be extracted by the receiving OCSP
> > > responder,
> > > but another possibility would be to use an extension where the CDP
> > > information present in the certificate would copied and pasted in that
> > > extension. Then, using issuerSerial, the OCSP responder can
> > > perform the CRL
> > > check and to transform it into an OCSP response.
> > >
> > > Such extension would look like:
> > >
> > > ==================================================================
> > > =========
> > > 8.X     CRL Locator
> > >
> > > An OCSP server may be operated in a mode whereby the server receives a
> > > request and fetches the CRL which authoritative for the identified
> > > certificate. The crlLocator request extension is defined for this
> > > purpose.
> > > This extension is included as one of the singleRequestExtensions in
> > > requests.
> > >
> > >    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }
> > >
> > >    CrlLocator ::= CRLDistributionPoints
> > >
> > > The value for this field is obtained from the corresponding
> field in the
> > > subject certificate.
> > >
> > > ==================================================================
> > > =========
> > >
> > > So my proposal would be to issue a new OCSP v2 draft, only
> > > including these
> > > two changes. Anything else I forgot ?
> > >
> > > Regards,
> > >
> > > Denis
> > >
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DEvn324454 for ietf-pkix-bks; Fri, 13 Sep 2002 07:57:49 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DEvlk24449 for <[e-mail]>; Fri, 13 Sep 2002 07:57:47 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA06782; Fri, 13 Sep 2002 17:02:50 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091316574192:414 ; Fri, 13 Sep 2002 16:57:41 +0200 
Message-ID: <[e-mail]>
Date: Fri, 13 Sep 2002 16:57:37 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
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: What happened to the OCSPv2 draft?
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/09/2002 16:57:41, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/09/2002 16:57:44, Serialize complete at 13/09/2002 16:57:44
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Ambarish,
 
> Oops - too many messages just while I am transitioning....
> 
> Steve, if I remember correctly, what we agreed on was that
> badly designed extensions can screw up a perfectly good
> protocol. So can badly designed implementations....
> 
> Denis, I like the suggestion about allowing a client to include
> the CRLDP extension in requests. 

Good. This is a point on which we both agree. :-)

> I don't like the suggestion of
> providing multiple means of identifying certificates - it
> adds more interoperability problems and doesn't add much to
> the protocol - assuming that we agree that OCSP was meant to
> provide the status of a certificate.

The current ways to specify the certificate are not that easy.

   CertID ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

   CertificateSerialNumber  ::=  INTEGER

You cannot directly know the DN of the CA. You have to use a list of known
CAs and compute the hash over each of them to perform the match. This is a
severe limitation.
 
> For the former, all we need to do is define the extension. That
> really doesn't need work on a OCSPv2 at all.

I agree that, for defining an extension for handling a CRLDP extension in
requests, we do not need to define a v2 version, since it would be
applicable to v1.

Regards,

Denis
 
> Regards,
> Ambarish
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Denis Pinkas
> > Sent: Thursday, September 12, 2002 1:48 AM
> > To: Stephen Kent
> > Cc: Peter Williams; '[e-mail] '
> > Subject: Re: What happened to the OCSPv2 draft?
> >
> >
> >
> > Steve,
> >
> > You said:
> >
> > "Ambarish later recalled that I warned him about the problems that
> > extensions to OCSP might engender, and he agreed that they had come
> > to cause problems."
> >
> > I do agree we you.
> >
> > To come back to technical issues, the expired OCSP v2 draft was expanding
> > its possibilities beyond certificate revocation checking, whereas some
> > fixing on the deficiencies of RFC 2560 would have been needed, in
> > particular, as pointed by Peter, more ways to select the certificate to be
> > checked.
> >
> > OCSP v2 should NOT expand its possibilities beyond certificate revocation
> > checking and certainly should NOT try to expand its capabilities to cover
> > certificate validation.
> >
> > To be more precise, I do not care about the expired OCSP v2 draft, but I
> > care about fixing RFC 2560, while sticking to its original functionality:
> > individual certificate revocation information status check.
> >
> > Having said that, we should correct the major problem that exists in
> > RFC 2560, which is how the certificate can be defined.
> >
> > The proposal in the last draft (draft-ietf-pkix-ocspv2-02.txt) was fine:
> >
> > 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 }
> >
> > In addition, RFC 2560 includes a serviceLocator request extension, which
> > is nice when an OCSP service is supported in the background. However, it
> > does not include any extension when a CRL is supported in the background.
> > This means that the OCSP server cannot know in general where the CRL to be
> > used is located.
> >
> > :-(
> >
> > One way would be to send the whole certificate (this is NOT possible with
> > RFC 2560) so that the CDP can be extracted by the receiving OCSP
> > responder,
> > but another possibility would be to use an extension where the CDP
> > information present in the certificate would copied and pasted in that
> > extension. Then, using issuerSerial, the OCSP responder can
> > perform the CRL
> > check and to transform it into an OCSP response.
> >
> > Such extension would look like:
> >
> > ==================================================================
> > =========
> > 8.X     CRL Locator
> >
> > An OCSP server may be operated in a mode whereby the server receives a
> > request and fetches the CRL which authoritative for the identified
> > certificate. The crlLocator request extension is defined for this
> > purpose.
> > This extension is included as one of the singleRequestExtensions in
> > requests.
> >
> >    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }
> >
> >    CrlLocator ::= CRLDistributionPoints
> >
> > The value for this field is obtained from the corresponding field in the
> > subject certificate.
> >
> > ==================================================================
> > =========
> >
> > So my proposal would be to issue a new OCSP v2 draft, only
> > including these
> > two changes. Anything else I forgot ?
> >
> > Regards,
> >
> > Denis
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DEv9H24416 for ietf-pkix-bks; Fri, 13 Sep 2002 07:57:09 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DEv8k24411 for <[e-mail]>; Fri, 13 Sep 2002 07:57:08 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA06772; Fri, 13 Sep 2002 17:02:14 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091316570587:412 ; Fri, 13 Sep 2002 16:57:05 +0200 
Message-ID: <[e-mail]>
Date: Fri, 13 Sep 2002 16:57:01 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Florian Oelmaier <[e-mail]>
CC: "'[e-mail] '" <[e-mail]>
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]> <p0510030db9a5731d9184@[10.0.170.56]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/09/2002 16:57:05, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/09/2002 16:57:08, Serialize complete at 13/09/2002 16:57:08
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Florian,

> > OCSP v2 should NOT expand its possibilities beyond certificate revocation
> > checking and certainly should NOT try to expand its capabilities to cover
> > certificate validation.
> 
> Although this bears some odds from a marketing perspective, I can see
> your arguments and agree to them.
> 
> > To be more precise, I do not care about the expired OCSP v2 draft, but I
> > care about fixing RFC 2560, while sticking to its original functionality:
> > individual certificate revocation information status check.
> 
> Agree.
> 
> > Having said that, we should correct the major problem that exists in
> > RFC 2560, which is how the certificate can be defined.
> 
> [...]
> 
> > So my proposal would be to issue a new OCSP v2 draft, only including these
> > two changes. Anything else I forgot ?
 
> It would be nice to streamline OCSP so that it can be used as some sort
> of "revocation service provider" for one of the upcoming validation
> protocols - I think that is what you all have in mind.
 
> Thus we should add an extension regarding the time of revocation
> checking - to allow the validation protocol to use OCSP while fulfilling
> the DPV-DPD requirements:
 
> "The client can request that the server determine the certificate
> validity at a time other than the current time. The DPV server MUST
> obtain revocation status information for the validation time in the
> client request." - DPV-DPD requirements document

I do not think that adding a parameter in the request to specify a time in
the past (which is I guess what you are proposing) is necessary.

A signature has to be validated close to the time it was made and thus the
revocation status information has to be captured close to that time. 
We already have the archive cutoff in case an OCSP responder chooses
to retain revocation information beyond a certificate's expiration.

Denis 

> --
> Florian Oelmaier
> SyTrust


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DCuGM16218 for ietf-pkix-bks; Fri, 13 Sep 2002 05:56:16 -0700 (PDT)
Received: from atlgeo3.geotrust.com ([66.21.21.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DCuEk16208 for <[e-mail]>; Fri, 13 Sep 2002 05:56:15 -0700 (PDT)
Received: by atlgeo3.atlanta.geotrust.com with Internet Mail Service (5.5.2653.19) id <K49J0HT4>; Fri, 13 Sep 2002 08:53:41 -0400
Message-ID: <[e-mail]>
From: Kefeng Chen <[e-mail]>
To: "'Marc Poulaud'" <[e-mail]>, [e-mail]
Subject: RE: CDP CRL format?
Date: Fri, 13 Sep 2002 08:53:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25B24.92738630"
Sender: [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>

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

Sometime people publish both binary formatted CRL and base64 formatted CRL.
But they are all X.509 v2 CRL.
 
Kefeng
 

-----Original Message-----
From: Marc Poulaud [mailto:[e-mail]]
Sent: Friday, September 13, 2002 6:14 AM
To: [e-mail]
Subject: CDP CRL format?


In relation to a CRL that is pointed at by the URI contained in a cert's
CDP, what *typically* might you expect the format of the CRL to be in? I'd
thought this would be an x.509x2 CRL wrapped in a PKCS#7.
 
Do some applications or platforms expect/want something else?
 
I've noticed that on a particular server that hold CRLs (from a Verisign
CA), there are a number of files of different formats. One file is LatestCRL
and another is LatestCRL.crl (amongst others). Anybody know what the
difference might be?
 
Thanks,

Marc 
______________________________

iSolve Ltd
Making eTrust happen
 
Tel:     [phone]
Email:  [e-mail] <mailto:[e-mail]> 
Web:   www.i-solve.co.uk <http://www.i-solve.co.uk/> 
______________________________
 


------_=_NextPart_001_01C25B24.92738630
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 6.00.2600.0" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=124345212-13092002><FONT face=Arial color=#0000ff 
size=2>Sometime people&nbsp;publish both binary formatted CRL and base64 
formatted CRL.</FONT></SPAN></DIV>
<DIV><SPAN class=124345212-13092002><FONT face=Arial color=#0000ff size=2>But 
they are all X.509 v2 CRL.</FONT></SPAN></DIV>
<DIV><SPAN class=124345212-13092002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=124345212-13092002><FONT face=Arial color=#0000ff 
size=2>Kefeng</FONT></SPAN></DIV>
<DIV><SPAN class=124345212-13092002></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Marc Poulaud 
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, September 13, 2002 
  6:14 AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> CDP CRL 
  format?<BR><BR></FONT></DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial size=2>In relation to a 
  CRL that is pointed at by the URI contained in a cert's CDP, what *typically* 
  might you expect the format of the CRL to be in? I'd thought this would be an 
  x.509x2 CRL wrapped in&nbsp;a PKCS#7.</FONT></SPAN></DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial size=2>Do some 
  applications or platforms expect/want something else?</FONT></SPAN></DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial size=2>I've noticed that 
  on a particular server that hold CRLs (from a Verisign CA), there are a number 
  of files of different formats. One file is LatestCRL and another is 
  LatestCRL.crl (amongst others). Anybody know what the difference might 
  be?</FONT></SPAN></DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial 
  size=2>Thanks,</FONT></SPAN></DIV><FONT face=Arial size=2>
  <DIV><FONT face=Arial size=2>
  <P><FONT size=7><FONT 
  face="French Script MT"><EM>Marc</EM>&nbsp;</FONT></FONT><BR>______________________________</FONT></P></DIV>
  <DIV><FONT face=Arial size=2>iSolve Ltd</FONT></DIV>
  <DIV><FONT face=Arial size=2><EM>Making eTrust happen</EM></FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Tel:&nbsp;&nbsp;&nbsp;&nbsp; [phone] 
  990</FONT></DIV>
  <DIV><FONT face=Arial size=2>Email:&nbsp;<A 
  href="mailto:[e-mail]">[e-mail]</A></FONT></DIV>
  <DIV><FONT face=Arial size=2>Web:&nbsp;&nbsp; <A 
  href="http://www.i-solve.co.uk/">www.i-solve.co.uk</A></FONT></DIV>
  <DIV><FONT face=Arial 
size=2>______________________________</FONT></DIV></FONT>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C25B24.92738630--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DAEVN04620 for ietf-pkix-bks; Fri, 13 Sep 2002 03:14:31 -0700 (PDT)
Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DAETk04615 for <[e-mail]>; Fri, 13 Sep 2002 03:14:29 -0700 (PDT)
Received: from f67j40j ([80.5.45.65]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020913101429.GYXJ292.mta01-svc.ntlworld.com@f67j40j> for <[e-mail]>; Fri, 13 Sep 2002 11:14:29 +0100
From: "Marc Poulaud" <[e-mail]>
To: <[e-mail]>
Subject: CDP CRL format?
Date: Fri, 13 Sep 2002 11:14:13 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C25B16.B09A3720"
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 V6.00.2600.0000
Importance: Normal
Sender: [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>

This is a multi-part message in MIME format.

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

In relation to a CRL that is pointed at by the URI contained in a cert's
CDP, what *typically* might you expect the format of the CRL to be in? I'd
thought this would be an x.509x2 CRL wrapped in a PKCS#7.

Do some applications or platforms expect/want something else?

I've noticed that on a particular server that hold CRLs (from a Verisign
CA), there are a number of files of different formats. One file is LatestCRL
and another is LatestCRL.crl (amongst others). Anybody know what the
difference might be?

Thanks,
Marc
______________________________

iSolve Ltd
Making eTrust happen

Tel:     [phone]
Email: [e-mail]
Web:   www.i-solve.co.uk
______________________________


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial size=3D2>In =
relation to a CRL=20
that is pointed at by the URI contained in a cert's CDP, what =
*typically* might=20
you expect the format of the CRL to be in? I'd thought this would be an =
x.509x2=20
CRL wrapped in&nbsp;a PKCS#7.</FONT></SPAN></DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial size=3D2>Do =
some applications=20
or platforms expect/want something else?</FONT></SPAN></DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial size=3D2>I've =
noticed that on=20
a particular server that hold CRLs (from a Verisign CA), there are a =
number of=20
files of different formats. One file is LatestCRL and another is =
LatestCRL.crl=20
(amongst others). Anybody know what the difference might =
be?</FONT></SPAN></DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial=20
size=3D2>Thanks,</FONT></SPAN></DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<P><FONT size=3D7><FONT=20
face=3D"French Script =
MT"><EM>Marc</EM>&nbsp;</FONT></FONT><BR>______________________________</=
FONT></P></DIV>
<DIV><FONT face=3DArial size=3D2>iSolve Ltd</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><EM>Making eTrust =
happen</EM></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Tel:&nbsp;&nbsp;&nbsp;&nbsp; +44 =
(0)7718 209=20
990</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Email:&nbsp;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>=
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Web:&nbsp;&nbsp; <A=20
href=3D"http://www.i-solve.co.uk/">www.i-solve.co.uk</A></FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>______________________________</FONT></DIV></FONT>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_001B_01C25B16.B09A3720--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8D42Yv17781 for ietf-pkix-bks; Thu, 12 Sep 2002 21:02:34 -0700 (PDT)
Received: from webgw099.acc.org.nz (acc.org.nz [203.167.220.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8D42Wk17777 for <[e-mail]>; Thu, 12 Sep 2002 21:02:33 -0700 (PDT)
Received: from mh_acc099 (not verified[10.99.5.50]) by webgw099.acc.org.nz with MailMarshal (4,2,5,0)  id <B000495676>; Fri, 13 Sep 2002 16:08:52 +1200
Received: from ACC_DOM-Message_Server by mh_acc099 with Novell_GroupWise; Fri, 13 Sep 2002 16:02:42 +1200
Message-Id: <sd820c22.028@mh_acc099>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 13 Sep 2002 16:02:34 +1200
From: "Joji Jacob" <[e-mail]>
To: "<"<[e-mail]>
Subject: un subscribe
Sender: [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>

--------------------------------------------------------------------------------------
Disclaimer:
"The information contained in this document is confidential to the addressee(s) and
 may be legally privileged.   Any view or opinions expressed are those of the author
 and may not be those of the organisation to which the author belongs.  If you have
 received this e-mail message in error please delete it and notify me. Thank you."
--------------------------------------------------------------------------------------


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8D1mhh09439 for ietf-pkix-bks; Thu, 12 Sep 2002 18:48:43 -0700 (PDT)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8D1mgk09434 for <[e-mail]>; Thu, 12 Sep 2002 18:48:42 -0700 (PDT)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id g8D1mj0X014939 for <[e-mail]>; Thu, 12 Sep 2002 21:48:45 -0400 (EDT)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id g8D1mi7n024103 for <[e-mail]>; Thu, 12 Sep 2002 21:48:44 -0400 (EDT)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id g8D1miwx024102 for [e-mail]; Thu, 12 Sep 2002 21:48:44 -0400 (EDT)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
Received: from 141.156.49.215 ( [141.156.49.215]) as user [e-mail] by imp.nist.gov with HTTP; Thu, 12 Sep 2002 21:48:44 -0400
Message-ID: <[e-mail]>
Date: Thu, 12 Sep 2002 21:48:44 -0400
From: [e-mail]
To: [e-mail]
Subject: RE: What happened to the OCSPv2 draft?
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [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>

As I recall, the OCSPv2 draft was collateral damage in the DPD/DPV wars.  While 
there were some changes to the base specification, the biggest enhancements 
were focused on DPV.   If memory serves, sometimes DPV was in the "core" v2 
specification, and sometimes in a separate document.  (By "core", I mean 
certificate status rather than DPV.)  Either way, the core and DPV tended to be 
worked in tandem.
 
Of course, the DPV portion of the specification got stuck while we discussed 
the requirements document.  There was not a big push to progress the OCSPv2 
specification without the DPV work.

I have the impression that has changed... from this thread, there seems to be 
sufficient interest to resume work on the OCSP core functionality regardless of 
the outcome on DPV.

Please note - I am not choosing sides in the *new* debate (change the base 
message versus only define new extensions).  If the needed functionality can be 
implemented with new extensions, great.  If the basic meesage needs to be 
updated, that's okay too.  (That's why the request syntax has a version number!)

Tim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8CMFKE28420 for ietf-pkix-bks; Thu, 12 Sep 2002 15:15:20 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8CMFIk28409 for <[e-mail]>; Thu, 12 Sep 2002 15:15:18 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Sep 2002 22:15:21 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id SAA17382 for <[e-mail]>; Thu, 12 Sep 2002 18:15:20 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8CMD0Q04038 for <[e-mail]>; Thu, 12 Sep 2002 18:13:00 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVTK7S>; Thu, 12 Sep 2002 18:15:18 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.18]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVTK73; Thu, 12 Sep 2002 18:15:16 -0400
From: "Housley, Russ" <[e-mail]>
To: "Manger, James H" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 12 Sep 2002 12:15:04 -0400
Subject: Re: Logos: 04: ~editorial comments
In-Reply-To: <[e-mail] l.telstra.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

James:

Thanks for your careful reading of the document.  These are all good 
comments, and I agree with all of them except the background.  I do not 
think that you proposal allows the inclusion of both a foreground and a 
background logotypes.

Russ


At 07:27 PM 9/5/2002 +1000, Manger, James H wrote:

>1.
>The URI fields (imageURI, audioURI and refStructURI) are all a SEQUENCE OF
>IA5String.  There is no mention about why multiple URIs can be included or
>how they should be handled.  I am guessing that they are supposed to be
>alternative URIs for exactly the same item.  Consequently, a client can use
>any URI from the sequence.  If a URI fails, the client should try another.
>If so, a sentence to that affect would help.
>
>2.
>Renaming the imageFormat and audioFormat fields to imageSubtype and
>audioSubtype should make it clearer (in code, not just an ASN.1 comment)
>that the fields hold MIME subtypes.
>
>3.
>Community, issuer, subject & loyalty types tell you what a logo is related
>to.  Whether a logo can be used as a background image is a different style
>of information.  Instead of defining id-logo-background, how about including
>a flag in LogotypeImageInfo.
>         LogotypeImageInfo ::= SEQUENCE {
>                 ...
>                 background      BOOLEAN DEFAULT FALSE }
>
>         If background is true it indicates that the image is appropriate
>         for use as a background image for other certificate details, in
>which case
>         it MUST allow black text placed over the image to be clearly
>readable.
>
>4.
>That logos can - to some degree - circumvent name constraints is understood
>and explained in the Security considerations section.  A client can take
>steps to minimise this risk by, for instance, consistently displaying logos
>in a separate, clearly delineated, section of the screen -- so at least a
>careful user would not be fooled.  Using a logo as a background image seems
>to make this much harder -- now the client would need to, say, make the logo
>wobble for a careful user to be able to distinguish what come from the logo
>and what is generated by the (trusted) client.  Perhaps background images
>should not be supported.
>
>
> > ----------
> > From: [e-mail] [SMTP:[e-mail]]
> > Sent: Wednesday, 4 September 2002 9:57 pm
> >
> >       Title           : Internet X.509 Public Key Infrastructure Logotypes
> > in X.509 certificates
> >       Author(s)       : S. Santesson, R. Housley, T. Freeman
> >       Filename        : draft-ietf-pkix-logotypes-04.txt
> >       Pages           : 19
> >       Date            : 2002-9-3
> >
> > This document specifies a certificate extension for including logotypes in
> > public key certificates and attribute certificates.
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-04.txt
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8CHx9X15034 for ietf-pkix-bks; Thu, 12 Sep 2002 10:59:09 -0700 (PDT)
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CHx7k15025 for <[e-mail]>; Thu, 12 Sep 2002 10:59:07 -0700 (PDT)
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.5/8.12.5) with SMTP id g8CHwLGk003728; Thu, 12 Sep 2002 10:58:22 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Peter Williams" <[e-mail]>, <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Thu, 12 Sep 2002 11:07:45 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [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>

Oops - too many messages just while I am transitioning....

Steve, if I remember correctly, what we agreed on was that
badly designed extensions can screw up a perfectly good
protocol. So can badly designed implementations....

Denis, I like the suggestion about allowing a client to include
the CRLDP extension in requests. I don't like the suggestion of
providing multiple means of identifying certificates - it
adds more interoperability problems and doesn't add much to
the protocol - assuming that we agree that OCSP was meant to
provide the status of a certificate.

For the former, all we need to do is define the extension. That
really doesn't need work on a OCSPv2 at all.

Regards,
Ambarish


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Thursday, September 12, 2002 1:48 AM
> To: Stephen Kent
> Cc: Peter Williams; '[e-mail] '
> Subject: Re: What happened to the OCSPv2 draft?
>
>
>
> Steve,
>
> You said:
>
> "Ambarish later recalled that I warned him about the problems that
> extensions to OCSP might engender, and he agreed that they had come
> to cause problems."
>
> I do agree we you.
>
> To come back to technical issues, the expired OCSP v2 draft was expanding
> its possibilities beyond certificate revocation checking, whereas some
> fixing on the deficiencies of RFC 2560 would have been needed, in
> particular, as pointed by Peter, more ways to select the certificate to be
> checked.
>
> OCSP v2 should NOT expand its possibilities beyond certificate revocation
> checking and certainly should NOT try to expand its capabilities to cover
> certificate validation.
>
> To be more precise, I do not care about the expired OCSP v2 draft, but I
> care about fixing RFC 2560, while sticking to its original functionality:
> individual certificate revocation information status check.
>
> Having said that, we should correct the major problem that exists in
> RFC 2560, which is how the certificate can be defined.
>
> The proposal in the last draft (draft-ietf-pkix-ocspv2-02.txt) was fine:
>
> 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 }
>
> In addition, RFC 2560 includes a serviceLocator request extension, which
> is nice when an OCSP service is supported in the background. However, it
> does not include any extension when a CRL is supported in the background.
> This means that the OCSP server cannot know in general where the CRL to be
> used is located.
>
> :-(
>
> One way would be to send the whole certificate (this is NOT possible with
> RFC 2560) so that the CDP can be extracted by the receiving OCSP
> responder,
> but another possibility would be to use an extension where the CDP
> information present in the certificate would copied and pasted in that
> extension. Then, using issuerSerial, the OCSP responder can
> perform the CRL
> check and to transform it into an OCSP response.
>
> Such extension would look like:
>
> ==================================================================
> =========
> 8.X     CRL Locator
>
> An OCSP server may be operated in a mode whereby the server receives a
> request and fetches the CRL which authoritative for the identified
> certificate. The crlLocator request extension is defined for this
> purpose.
> This extension is included as one of the singleRequestExtensions in
> requests.
>
>    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }
>
>    CrlLocator ::= CRLDistributionPoints
>
> The value for this field is obtained from the corresponding field in the
> subject certificate.
>
> ==================================================================
> =========
>
> So my proposal would be to issue a new OCSP v2 draft, only
> including these
> two changes. Anything else I forgot ?
>
> Regards,
>
> Denis
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8CGjGu11691 for ietf-pkix-bks; Thu, 12 Sep 2002 09:45:16 -0700 (PDT)
Received: from mail-out.secaron.de (druss.secaron.de [195.145.99.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CGjDk11685 for <[e-mail]>; Thu, 12 Sep 2002 09:45:14 -0700 (PDT)
Received: by mail-out.secaron.de (Postfix, from userid 0) id D569E51F69; Thu, 12 Sep 2002 18:45:06 +0200 (MET DST)
Received: from druss.secaron.de (localhost [127.0.0.1]) by mail-out.secaron.de (Postfix) with ESMTP id 6B95B325F3; Thu, 12 Sep 2002 18:45:06 +0200 (MET DST)
Received: from marvin.munich.secaron.de (marvin.munich.secaron.de [192.168.1.20]) by druss.secaron.de (Postfix) with ESMTP id D77EB4ACC2; Thu, 12 Sep 2002 18:45:04 +0200 (MET DST)
Received: from sytrust.com ([192.168.2.3]) by marvin.munich.secaron.de (Lotus Domino Release 5.0.11) with ESMTP id 2002091218450332:1111 ; Thu, 12 Sep 2002 18:45:03 +0200 
Message-ID: <[e-mail]>
Date: Thu, 12 Sep 2002 18:43:00 +0200
From: Florian Oelmaier <[e-mail]>
Organization: SyTrust GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.1) Gecko/20020826
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: Stephen Kent <[e-mail]>, Peter Williams <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]> <p0510030db9a5731d9184@[10.0.170.56]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on Marvin/Secaron(Release 5.0.11  |July 24, 2002) at 09/12/2002 06:45:03 PM, Serialize by Router on Marvin/Secaron(Release 5.0.11  |July 24, 2002) at 09/12/2002 06:45:04 PM, Serialize complete at 09/12/2002 06:45:04 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [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>

> OCSP v2 should NOT expand its possibilities beyond certificate revocation
> checking and certainly should NOT try to expand its capabilities to cover
> certificate validation.

Although this bears some odds from a marketing perspective, I can see 
your arguments and agree to them.

> To be more precise, I do not care about the expired OCSP v2 draft, but I
> care about fixing RFC 2560, while sticking to its original functionality:
> individual certificate revocation information status check.

Agree.

> Having said that, we should correct the major problem that exists in 
> RFC 2560, which is how the certificate can be defined.

[...]

> So my proposal would be to issue a new OCSP v2 draft, only including these 
> two changes. Anything else I forgot ?  

It would be nice to streamline OCSP so that it can be used as some sort 
of "revocation service provider" for one of the upcoming validation 
protocols - I think that is what you all have in mind.

Thus we should add an extension regarding the time of revocation 
checking - to allow the validation protocol to use OCSP while fulfilling 
the DPV-DPD requirements:

"The client can request that the server determine the certificate 
validity at a time other than the current time. The DPV server MUST 
obtain revocation status information for the validation time in the 
client request." - DPV-DPD requirements document

--
Florian Oelmaier
SyTrust





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8CF5xP05414 for ietf-pkix-bks; Thu, 12 Sep 2002 08:05:59 -0700 (PDT)
Received: from host8.successfulhosting.com (host8.successfulhosting.com [209.239.36.32]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CF5wk05410 for <[e-mail]>; Thu, 12 Sep 2002 08:05:58 -0700 (PDT)
Received: from ascertiacompaq (host213-122-245-20.in-addr.btopenworld.com [213.122.245.20]) by host8.successfulhosting.com (8.10.2/8.10.2) with SMTP id g8CF5mS19344; Thu, 12 Sep 2002 11:05:49 -0400
From: "Liaquat Khan" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Peter Williams" <[e-mail]>, <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Thu, 12 Sep 2002 16:02:09 +0500
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [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>

Hi,

I think this would be a very useful feature.  A number of PKIs are
hierarchical, and where CRLs are supported at higher levels (for checking
the revocation status of CA certs) and OCSP at lower levels (for checking
the revocation status of end-user certs).  This may be justified for various
reasons.

It should be possible for the OCSP responder to trace the relevant back-end
CRL using the information from the target certificate.  Either the target
certificate should be sent to the OCSP responder in full (so that the CDP
extension can be extracted by the OCSP responder directly) or the relying
party application needs to strip out the CDP extension from the target
certificate and send this in an extension of the OCSP request message as you
mention.

I remember asking for this over a year ago from the authors, and was told
that as OCSPv2 would allow a full certificate to be sent to the OCSP
responder so a special extension would not be needed and I should just wait
for this.  Since then we all know what happend to OCSPv2.

One comment on your post Denis:

>>Then, using issuerSerial, the OCSP responder can perform the CRL
check and to transform it into an OCSP response.

I was thinking the OCSP responder could also use the serialNumber from the
CertID to do this.

Regards,
LK


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Denis Pinkas
Sent: 12 September 2002 13:48
To: Stephen Kent
Cc: Peter Williams; '[e-mail] '
Subject: Re: What happened to the OCSPv2 draft?



Steve,

You said:

"Ambarish later recalled that I warned him about the problems that
extensions to OCSP might engender, and he agreed that they had come
to cause problems."

I do agree we you.

To come back to technical issues, the expired OCSP v2 draft was expanding
its possibilities beyond certificate revocation checking, whereas some
fixing on the deficiencies of RFC 2560 would have been needed, in
particular, as pointed by Peter, more ways to select the certificate to be
checked.

OCSP v2 should NOT expand its possibilities beyond certificate revocation
checking and certainly should NOT try to expand its capabilities to cover
certificate validation.

To be more precise, I do not care about the expired OCSP v2 draft, but I
care about fixing RFC 2560, while sticking to its original functionality:
individual certificate revocation information status check.

Having said that, we should correct the major problem that exists in
RFC 2560, which is how the certificate can be defined.

The proposal in the last draft (draft-ietf-pkix-ocspv2-02.txt) was fine:

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 }

In addition, RFC 2560 includes a serviceLocator request extension, which
is nice when an OCSP service is supported in the background. However, it
does not include any extension when a CRL is supported in the background.
This means that the OCSP server cannot know in general where the CRL to be
used is located.

:-(

One way would be to send the whole certificate (this is NOT possible with
RFC 2560) so that the CDP can be extracted by the receiving OCSP responder,
but another possibility would be to use an extension where the CDP
information present in the certificate would copied and pasted in that
extension. Then, using issuerSerial, the OCSP responder can perform the CRL
check and to transform it into an OCSP response.

Such extension would look like:

===========================================================================
8.X     CRL Locator

An OCSP server may be operated in a mode whereby the server receives a
request and fetches the CRL which authoritative for the identified
certificate. The crlLocator request extension is defined for this purpose.
This extension is included as one of the singleRequestExtensions in
requests.

   id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

   CrlLocator ::= CRLDistributionPoints

The value for this field is obtained from the corresponding field in the
subject certificate.

===========================================================================

So my proposal would be to issue a new OCSP v2 draft, only including these
two changes. Anything else I forgot ?

Regards,

Denis



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8CEKXY03976 for ietf-pkix-bks; Thu, 12 Sep 2002 07:20:33 -0700 (PDT)
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CEKQk03968 for <[e-mail]>; Thu, 12 Sep 2002 07:20:26 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id g8CEKQ0Y029201; Thu, 12 Sep 2002 10:20:27 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 12 Sep 2002 10:16:35 -0400
To: "Singer, Ari" <[e-mail]>, "Housley, Russ" <[e-mail]>, [e-mail]
From: Tim Polk <[e-mail]>
Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated sig natures
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Folks,

The SHA-xxx OIDs identified by Terry are "official" in that they are 
NIST-assigned OIDs from the NIST arc.  These OIDs were assigned based on a 
draft published a few years back, rather than an official NIST publication, 
which is probably why Terry had noted them as provisional.  The OIDs were 
official; the algorithms were not... if the FIPS differed from the draft 
algorithm specification, I intended to issue new OIDs.  (That is also why I 
had not promoted them on the CSOR web pages.)

However, the new secure hash FIPS was issued in August, and the algorithms 
are exactly those defined in the draft specification.   (BTW, the new FIPS 
is available at 
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf).   There is 
no reason to assign new OIDs, so please (continue?) to use the current OIDs:

 > >>     SHA-256:    2.16.840.1.101.3.4.2.1
 > >>     SHA-384:    2.16.840.1.101.3.4.2.2
 > >>     SHA-512:    2.16.840.1.101.3.4.2.3

Clearly, updates to my OID pages are overdue.  I will specify the new SHA 
oids and point to PKCS #1 for the new RSA with SHA-xxx signature algorithm 
oids.  I'm glad to see those have been assigned!

I will also talk to NIST's X9 representatives about  signature OIDs for 
ECDSA with the new hashes, and OIDs for a revised digital signature 
algorithm with larger key sizes (when available).  It doesn't matter to me 
who assigns them; the important thing is that there be just one...   X9 
assigned the previous OIDs, so maybe they'll want to handle these as 
well.  If they can't move quickly enough, I will assign them.  (That 
creates a new problem of course - convincing X9 to specify the NIST oids.)

Thanks,

Tim Polk

At 05:17 PM 9/10/02 -0400, Singer, Ari wrote:

>Hi, Terry and Russ.
>
>This won't answer the question of the "official" source for the SHA-xxx
>OIDs, but I will follow up with Tim to make sure that these are the correct
>OIDs and include them (along with the new RSA OIDs that use them) in the
>next draft of the supplemental algorithms draft as imported OIDs.  That
>should suffice for the PKIX working group, at least.  The new draft will be
>available before the Atlanta meeting.
>
>Best regards,
>Ari
>
>Ari Singer, Principal Engineer
>NTRU
>5 Burlington Woods
>Burlington, MA 01803
>Main: [phone]
>Personal: [phone]
>Fax: [phone]
>
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: Tuesday, September 10, 2002 12:52 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
> > signatures
> >
> >
> >
> > Terry:
> >
> > It is my understanding from Tim Polk that these OIDs are
> > official.  I do
> > not know the method that will be used to publish them.
> >
> > Russ
> >
> > At 05:25 PM 9/9/2002 -0700, Terry Hayes wrote:
> > >Thanks Russ for the pointers to the new RSA values.  I
> > hadn't noticed the
> > >June update to PKCS #1.
> > >
> > >I see that the latest PKCS #1 update, the lastest S/MIME
> > RSAES-OAEP draft
> > >and the latest PKIX supplimental algorithms draft all refer
> > to the new
> > >hash algorithms using the OIDs that I had seen previously.
> > >
> > >Is there any timetable for an official publication of these
> > OIDs, perhaps
> > >on the CSOR page at NIST
> > >(<http://csrc.nist.gov/csor/algorithms.htm>http://csrc.nist.g
> > ov/csor/algorithms.htm)?
> > >
> > >Terry
> > >
> > >Housley, Russ wrote:
> > >
> > >>Terry:
> > >>
> > >>The most recent PKCS#1 ASN.1 module includes:
> > >>
> > >>    --
> > >>    -- When the following OIDs are used in an
> > AlgorithmIdentifier the
> > >>    -- parameters MUST be present and MUST be NULL.
> > >>    --
> > >>    md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
> > >>    md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
> > >>    sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
> > >>    sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
> > >>    sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
> > >>    sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }
> > >>
> > >>
> > >>Russ
> > >>
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: <mailto:[e-mail]>[e-mail]
> > >>To: <mailto:[e-mail]>[e-mail]
> > >>Sent: 9/9/02 6:42 PM
> > >>Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
> > >>signatures
> > >>
> > >>Now that FIPS 180-2 will be effective in Feburary 2003, it's time to
> > >>implement them in cryptographic libraries and in protocol
> > >>implementations. However I have not been able to find official
> > >>definitions of the OID values for these new algorithms.
> > >>
> > >>I've seen the following values proposed as the OIDs for the new SHA
> > >>variants:
> > >>
> > >>     SHA-256:    2.16.840.1.101.3.4.2.1
> > >>     SHA-384:    2.16.840.1.101.3.4.2.2
> > >>     SHA-512:    2.16.840.1.101.3.4.2.3
> > >>
> > >>My source for these called these values "provisional."  Is there an
> > >>official definition somewhere?
> > >>
> > >>In addition to OIDs for the hash functions themselves,
> > additional OIDs
> > >>need to be defined for other operations that use them.  In
> > particular, a
> > >>value for sha-256WithRSAEncryption should be defined as soon as
> > >>possible.  I expect that this algorithm will become popular fairly
> > >>quickly, replacing sha-1WithRSAEncryption in deployments
> > that want an
> > >>effective security level of 128 bits.
> > sha-256WithRSAEncryption should
> > >>also be added to the PKIX algorithms RFC (probably as a
> > SHOULD) at the
> > >>next opportunity.
> > >>
> > >>Who will be defining sha-256WithRSAEncryption?
> > >>
> > >>Terry Hayes
> > >><mailto:[e-mail]>[e-mail]
><mailto:[e-mail]>
> >>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8C8m9Q08358 for ietf-pkix-bks; Thu, 12 Sep 2002 01:48:09 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8C8m8k08350 for <[e-mail]>; Thu, 12 Sep 2002 01:48:08 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA20708; Thu, 12 Sep 2002 10:52:58 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091210474905:54 ; Thu, 12 Sep 2002 10:47:49 +0200 
Message-ID: <[e-mail]>
Date: Thu, 12 Sep 2002 10:47:49 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Peter Williams <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]> <p0510030db9a5731d9184@[10.0.170.56]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 12/09/2002 10:47:49, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 12/09/2002 10:47:52, Serialize complete at 12/09/2002 10:47:52
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Steve,

You said:

"Ambarish later recalled that I warned him about the problems that
extensions to OCSP might engender, and he agreed that they had come 
to cause problems."

I do agree we you.

To come back to technical issues, the expired OCSP v2 draft was expanding
its possibilities beyond certificate revocation checking, whereas some
fixing on the deficiencies of RFC 2560 would have been needed, in
particular, as pointed by Peter, more ways to select the certificate to be
checked.

OCSP v2 should NOT expand its possibilities beyond certificate revocation
checking and certainly should NOT try to expand its capabilities to cover
certificate validation.

To be more precise, I do not care about the expired OCSP v2 draft, but I
care about fixing RFC 2560, while sticking to its original functionality:
individual certificate revocation information status check.

Having said that, we should correct the major problem that exists in 
RFC 2560, which is how the certificate can be defined.

The proposal in the last draft (draft-ietf-pkix-ocspv2-02.txt) was fine:

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 }

In addition, RFC 2560 includes a serviceLocator request extension, which
is nice when an OCSP service is supported in the background. However, it
does not include any extension when a CRL is supported in the background.
This means that the OCSP server cannot know in general where the CRL to be
used is located. 

:-(

One way would be to send the whole certificate (this is NOT possible with
RFC 2560) so that the CDP can be extracted by the receiving OCSP responder,
but another possibility would be to use an extension where the CDP
information present in the certificate would copied and pasted in that
extension. Then, using issuerSerial, the OCSP responder can perform the CRL
check and to transform it into an OCSP response.

Such extension would look like:

===========================================================================
8.X     CRL Locator

An OCSP server may be operated in a mode whereby the server receives a
request and fetches the CRL which authoritative for the identified
certificate. The crlLocator request extension is defined for this purpose.  
This extension is included as one of the singleRequestExtensions in
requests.

   id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

   CrlLocator ::= CRLDistributionPoints
 
The value for this field is obtained from the corresponding field in the 
subject certificate.

===========================================================================

So my proposal would be to issue a new OCSP v2 draft, only including these 
two changes. Anything else I forgot ?  

Regards,

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8C2mkg00752 for ietf-pkix-bks; Wed, 11 Sep 2002 19:48:46 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8C2mjk00748 for <[e-mail]>; Wed, 11 Sep 2002 19:48:45 -0700 (PDT)
Received: from MMyersLapTop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by mail.coastside.net  with SMTP id g8C2mcKY004016; Wed, 11 Sep 2002 19:48:39 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Wed, 11 Sep 2002 19:44:52 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [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>

> -----Original Message-----
> From: Denis Pinkas
> Sent: Wednesday, September 11, 2002 8:44 AM
> 
> I do not care about OCSP v2: some documents die.


I agree.  Drafts expire.  Needs do not.

Mike


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BMWmY10147 for ietf-pkix-bks; Wed, 11 Sep 2002 15:32:48 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BMWlk10143 for <[e-mail]>; Wed, 11 Sep 2002 15:32:47 -0700 (PDT)
Received: from [10.0.170.56] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23229; Wed, 11 Sep 2002 18:32:31 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p0510030cb9a572455eb9@[10.0.170.56]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 11 Sep 2002 18:23:48 -0400
To: "Hallam-Baker, Phillip" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [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>

At 3:04 PM -0700 9/11/02, Hallam-Baker, Phillip wrote:
>  > Extensions can dramatically alter the semantics, functionality, and
>>  security of a base protocol or data structure.
>
>Agreed, that is why I don't want random extensions that do not have
>vendor or developer support to be accorded the same status as the
>PKIX profile that does have vendor and developer support.

I think we basically agree, expect that I would phrase it in terms of 
having the same WG approve the extensions as approved the original 
document.

>
>
>>  Todd's most recent effort was directed at removing me as chair of the
>>  PKIX WG, by persuading someone to take my place, or create a new WG
>>  for which I was not the chair, or to persuade the IESG or IAB that
>>  PKIX was broken and needed to be fixed, and then, ultimately, to
>>  convince the IAB & IESG that the IETF was broken and needed to be
>>  fixed.
>
>And you foiled the plot by putting a fake timestamp on the moment
>at which the IESG and IAB were convinced?

I have no comment on that heinous accusation at this time, or at that 
other time, whenever it was, or may yet be, or ....


Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BMWNw10131 for ietf-pkix-bks; Wed, 11 Sep 2002 15:32:23 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BMWLk10127 for <[e-mail]>; Wed, 11 Sep 2002 15:32:21 -0700 (PDT)
Received: from [10.0.170.56] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23232; Wed, 11 Sep 2002 18:32:32 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p0510030db9a5731d9184@[10.0.170.56]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 11 Sep 2002 18:33:13 -0400
To: Peter Williams <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
Cc: "'[e-mail] '" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [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>

At 3:16 PM -0700 9/11/02, Peter Williams wrote:
>
>Extensions can alter the semantics of a security protocol. In
>IETF we allow private organizations to create new extensions
>for both certificates and OCSP, note. We know that cert politcy
>qualifiers alter the impact of using (not processing) cert
>chains dramatically, for example, as intended by ISO.

Well, I think we all agree that vendor-specified extensions to these 
protocols or data structures can cause trouble, and thus I personally 
am not a fan of such things. Ambarish later recalled that I warned 
him about the problems that extensions to OCSP might engender, and he 
agreed that they had come to cause problems.

>Its not sensible to argue that WG-ratified extensions have
>to be controlled (against unwarranted changes to PKIX semantics)
>whilst we allow others to perform independently peform such
>change of semantics. If we are to accept Steve's logic, we should
>alter OCSP to require (non-experimental) extension registration,
>with IANA, to preseve IETF process input. Registered Extensions
>would have to through a WG process then, logically PKIX  - while
>PKIX WG exists.

Extensions that do not carry the imprimatur of a standards body often 
see less widespread deployment (depending on the vendor, of course) 
and thus pose less of a risk than extensions that are approved by a 
standards body. So, on that basis I do think it appropriate to try to 
maintain WG control over extensions to the extent possible.

And yes, I would prefer extensions to be approved by a WG (PKIX in 
this case) before being assigned an OID bu IANA.  Other WGs have 
adopted that tactic for registration for analogous values.


>
>OCSP has no significant IETF-defined compliance rules, note.

Yor are right. We could have done better.

>-----
>
>I think another valid question is, what do we do with the
>SCVP id. Authors?

I don't think the WG gets to do anything to authors in general :-). 
And, I'm sorry, but I lost track here. I thought we were discussing 
OCSPv2, not SCVP. If someone, you for example, want to assume 
responsibility for OCSPv2, and if the WG is convinced that there is 
good reason to publish a new version, e.g., to fix some problems with 
the old version that require a versin # change, then we can proceed.

Steve

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BMGR308663 for ietf-pkix-bks; Wed, 11 Sep 2002 15:16:27 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BMGPk08657 for <[e-mail]>; Wed, 11 Sep 2002 15:16:25 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 11 Sep 2002 15:05:54 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 11 Sep 2002 15:05:53 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <SVDG6PRT>; Wed, 11 Sep 2002 15:16:10 -0700
Content-return: allowed
Date: Wed, 11 Sep 2002 15:16:00 -0700
From: Peter Williams <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
To: "'Stephen Kent '" <[e-mail]>
Cc: "'Hallam-Baker, Phillip '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_cW0Gsl5TbKkX8HKoVr9iuw)"
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [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>

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

--Boundary_(ID_cW0Gsl5TbKkX8HKoVr9iuw)
Content-type: text/plain

 
Extensions can alter the semantics of a security protocol. In 
IETF we allow private organizations to create new extensions
for both certificates and OCSP, note. We know that cert politcy
qualifiers alter the impact of using (not processing) cert 
chains dramatically, for example, as intended by ISO.

Its not sensible to argue that WG-ratified extensions have
to be controlled (against unwarranted changes to PKIX semantics)
whilst we allow others to perform independently peform such
change of semantics. If we are to accept Steve's logic, we should
alter OCSP to require (non-experimental) extension registration, 
with IANA, to preseve IETF process input. Registered Extensions 
would have to through a WG process then, logically PKIX  - while
PKIX WG exists.

OCSP has no significant IETF-defined compliance rules, note.

-----

I think another valid question is, what do we do with the
SCVP id. Authors?

Peter.



-----Original Message-----
From: Stephen Kent
To: Hallam-Baker, Phillip
Cc: Hallam-Baker, Phillip; [e-mail]
Sent: 9/11/02 2:30 PM
Subject: RE: What happened to the OCSPv2 draft?


At 1:27 PM -0700 9/11/02, Hallam-Baker, Phillip wrote:
>  > By my count, that's two messages in a row from you on the theme of
>>  "let's kill off the PKIX WG."
>
>Congratulations, you spotted the hiddern pattern. Actually the wrong
>one. I have been arguing that the group should split off an extensions
>group and close the main group once all the milestones are complete.

Extensions can dramatically alter the semantics, functionality, and 
security of a base protocol or data structure. So I don't see the 
justification for having a different WG deal with extensions to 
previously developed PKIX standards. If one believed that was an 
appropriate path, then we should have changed WGs going from v1 
certs, to v2 certs, to v3 certs ...


>  > The future of OCSPv2 and its relevance to to the question of the
>>  future of this WG is equally silly.
>
>Why is it silly to ask whether the group should continue to progress
>a draft when the authors and much of the audience appear to have lost
>interest?

I didn't suggest that what you said above was a silly question. I 
suggested it was silly to use the question of extensions to OCSP as a 
basis for creating a new WG, consistent with my comments above. I 
agree with your question, i.e., unless there are supporters for an 
ID, it will not progress. If the authors loose interest then other 
authors have to take over, or the ID dies.  No disagreement there.

>  > Have you been hanging out with Todd?
>
>I was under the impression that Todd was arguing to take on more work
>rather than the reverse.

Todd's most recent effort was directed at removing me as chair of the 
PKIX WG, by persuading someone to take my place, or create a new WG 
for which I was not the chair, or to persuade the IESG or IAB that 
PKIX was broken and needed to be fixed, and then, ultimately, to 
convince the IAB & IESG that the IETF was broken and needed to be 
fixed.

Steve

--Boundary_(ID_cW0Gsl5TbKkX8HKoVr9iuw)
Content-type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: What happened to the OCSPv2 draft?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>Extensions can alter the semantics of a security protocol. In </FONT>
<BR><FONT SIZE=2>IETF we allow private organizations to create new extensions</FONT>
<BR><FONT SIZE=2>for both certificates and OCSP, note. We know that cert politcy</FONT>
<BR><FONT SIZE=2>qualifiers alter the impact of using (not processing) cert </FONT>
<BR><FONT SIZE=2>chains dramatically, for example, as intended by ISO.</FONT>
</P>

<P><FONT SIZE=2>Its not sensible to argue that WG-ratified extensions have</FONT>
<BR><FONT SIZE=2>to be controlled (against unwarranted changes to PKIX semantics)</FONT>
<BR><FONT SIZE=2>whilst we allow others to perform independently peform such</FONT>
<BR><FONT SIZE=2>change of semantics. If we are to accept Steve's logic, we should</FONT>
<BR><FONT SIZE=2>alter OCSP to require (non-experimental) extension registration, </FONT>
<BR><FONT SIZE=2>with IANA, to preseve IETF process input. Registered Extensions </FONT>
<BR><FONT SIZE=2>would have to through a WG process then, logically PKIX&nbsp; - while</FONT>
<BR><FONT SIZE=2>PKIX WG exists.</FONT>
</P>

<P><FONT SIZE=2>OCSP has no significant IETF-defined compliance rules, note.</FONT>
</P>

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

<P><FONT SIZE=2>I think another valid question is, what do we do with the</FONT>
<BR><FONT SIZE=2>SCVP id. Authors?</FONT>
</P>

<P><FONT SIZE=2>Peter.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Stephen Kent</FONT>
<BR><FONT SIZE=2>To: Hallam-Baker, Phillip</FONT>
<BR><FONT SIZE=2>Cc: Hallam-Baker, Phillip; [e-mail]</FONT>
<BR><FONT SIZE=2>Sent: 9/11/02 2:30 PM</FONT>
<BR><FONT SIZE=2>Subject: RE: What happened to the OCSPv2 draft?</FONT>
</P>
<BR>

<P><FONT SIZE=2>At 1:27 PM -0700 9/11/02, Hallam-Baker, Phillip wrote:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; By my count, that's two messages in a row from you on the theme of</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp; &quot;let's kill off the PKIX WG.&quot;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Congratulations, you spotted the hiddern pattern. Actually the wrong</FONT>
<BR><FONT SIZE=2>&gt;one. I have been arguing that the group should split off an extensions</FONT>
<BR><FONT SIZE=2>&gt;group and close the main group once all the milestones are complete.</FONT>
</P>

<P><FONT SIZE=2>Extensions can dramatically alter the semantics, functionality, and </FONT>
<BR><FONT SIZE=2>security of a base protocol or data structure. So I don't see the </FONT>
<BR><FONT SIZE=2>justification for having a different WG deal with extensions to </FONT>
<BR><FONT SIZE=2>previously developed PKIX standards. If one believed that was an </FONT>
<BR><FONT SIZE=2>appropriate path, then we should have changed WGs going from v1 </FONT>
<BR><FONT SIZE=2>certs, to v2 certs, to v3 certs ...</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt;&nbsp; &gt; The future of OCSPv2 and its relevance to to the question of the</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp; future of this WG is equally silly.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Why is it silly to ask whether the group should continue to progress</FONT>
<BR><FONT SIZE=2>&gt;a draft when the authors and much of the audience appear to have lost</FONT>
<BR><FONT SIZE=2>&gt;interest?</FONT>
</P>

<P><FONT SIZE=2>I didn't suggest that what you said above was a silly question. I </FONT>
<BR><FONT SIZE=2>suggested it was silly to use the question of extensions to OCSP as a </FONT>
<BR><FONT SIZE=2>basis for creating a new WG, consistent with my comments above. I </FONT>
<BR><FONT SIZE=2>agree with your question, i.e., unless there are supporters for an </FONT>
<BR><FONT SIZE=2>ID, it will not progress. If the authors loose interest then other </FONT>
<BR><FONT SIZE=2>authors have to take over, or the ID dies.&nbsp; No disagreement there.</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp; &gt; Have you been hanging out with Todd?</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I was under the impression that Todd was arguing to take on more work</FONT>
<BR><FONT SIZE=2>&gt;rather than the reverse.</FONT>
</P>

<P><FONT SIZE=2>Todd's most recent effort was directed at removing me as chair of the </FONT>
<BR><FONT SIZE=2>PKIX WG, by persuading someone to take my place, or create a new WG </FONT>
<BR><FONT SIZE=2>for which I was not the chair, or to persuade the IESG or IAB that </FONT>
<BR><FONT SIZE=2>PKIX was broken and needed to be fixed, and then, ultimately, to </FONT>
<BR><FONT SIZE=2>convince the IAB &amp; IESG that the IETF was broken and needed to be </FONT>
<BR><FONT SIZE=2>fixed.</FONT>
</P>

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

</BODY>
</HTML>

--Boundary_(ID_cW0Gsl5TbKkX8HKoVr9iuw)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BM2Rb07161 for ietf-pkix-bks; Wed, 11 Sep 2002 15:02:27 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BM2Pk07154 for <[e-mail]>; Wed, 11 Sep 2002 15:02:25 -0700 (PDT)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8BM2MXA002159; Wed, 11 Sep 2002 15:02:22 -0700 (PDT)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <SLC3Q1NV>; Wed, 11 Sep 2002 15:04:15 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: "Hallam-Baker, Phillip" <[e-mail]>, [e-mail]
Subject: RE: What happened to the OCSPv2 draft?
Date: Wed, 11 Sep 2002 15:04:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

> Extensions can dramatically alter the semantics, functionality, and 
> security of a base protocol or data structure.

Agreed, that is why I don't want random extensions that do not have
vendor or developer support to be accorded the same status as the 
PKIX profile that does have vendor and developer support.


> Todd's most recent effort was directed at removing me as chair of the 
> PKIX WG, by persuading someone to take my place, or create a new WG 
> for which I was not the chair, or to persuade the IESG or IAB that 
> PKIX was broken and needed to be fixed, and then, ultimately, to 
> convince the IAB & IESG that the IETF was broken and needed to be 
> fixed.

And you foiled the plot by putting a fake timestamp on the moment 
at which the IESG and IAB were convinced?


		Phill


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BLVVN05468 for ietf-pkix-bks; Wed, 11 Sep 2002 14:31:31 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BLVKk05461 for <[e-mail]>; Wed, 11 Sep 2002 14:31:30 -0700 (PDT)
Received: from [10.0.170.56] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06319; Wed, 11 Sep 2002 17:31:03 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05100309b9a5648c2561@[10.0.170.56]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 11 Sep 2002 17:30:23 -0400
To: "Hallam-Baker, Phillip" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
Cc: "Hallam-Baker, Phillip"	 <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [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>

At 1:27 PM -0700 9/11/02, Hallam-Baker, Phillip wrote:
>  > By my count, that's two messages in a row from you on the theme of
>>  "let's kill off the PKIX WG."
>
>Congratulations, you spotted the hiddern pattern. Actually the wrong
>one. I have been arguing that the group should split off an extensions
>group and close the main group once all the milestones are complete.

Extensions can dramatically alter the semantics, functionality, and 
security of a base protocol or data structure. So I don't see the 
justification for having a different WG deal with extensions to 
previously developed PKIX standards. If one believed that was an 
appropriate path, then we should have changed WGs going from v1 
certs, to v2 certs, to v3 certs ...


>  > The future of OCSPv2 and its relevance to to the question of the
>>  future of this WG is equally silly.
>
>Why is it silly to ask whether the group should continue to progress
>a draft when the authors and much of the audience appear to have lost
>interest?

I didn't suggest that what you said above was a silly question. I 
suggested it was silly to use the question of extensions to OCSP as a 
basis for creating a new WG, consistent with my comments above. I 
agree with your question, i.e., unless there are supporters for an 
ID, it will not progress. If the authors loose interest then other 
authors have to take over, or the ID dies.  No disagreement there.

>  > Have you been hanging out with Todd?
>
>I was under the impression that Todd was arguing to take on more work
>rather than the reverse.

Todd's most recent effort was directed at removing me as chair of the 
PKIX WG, by persuading someone to take my place, or create a new WG 
for which I was not the chair, or to persuade the IESG or IAB that 
PKIX was broken and needed to be fixed, and then, ultimately, to 
convince the IAB & IESG that the IETF was broken and needed to be 
fixed.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BKPwt02240 for ietf-pkix-bks; Wed, 11 Sep 2002 13:25:58 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BKPrk02235 for <[e-mail]>; Wed, 11 Sep 2002 13:25:53 -0700 (PDT)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8BKPoXA013307; Wed, 11 Sep 2002 13:25:50 -0700 (PDT)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <SLC3P7L4>; Wed, 11 Sep 2002 13:27:42 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: [e-mail]
Subject: RE: What happened to the OCSPv2 draft?
Date: Wed, 11 Sep 2002 13:27:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

> By my count, that's two messages in a row from you on the theme of 
> "let's kill off the PKIX WG." 

Congratulations, you spotted the hiddern pattern. Actually the wrong 
one. I have been arguing that the group should split off an extensions 
group and close the main group once all the milestones are complete.

> The future of OCSPv2 and its relevance to to the question of the 
> future of this WG is equally silly.

Why is it silly to ask whether the group should continue to progress
a draft when the authors and much of the audience appear to have lost
interest?

> Have you been hanging out with Todd?

I was under the impression that Todd was arguing to take on more work
rather than the reverse.


		Phill


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BItJl29183 for ietf-pkix-bks; Wed, 11 Sep 2002 11:55:19 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BItHk29179 for <[e-mail]>; Wed, 11 Sep 2002 11:55:17 -0700 (PDT)
Received: from [10.0.170.56] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11802; Wed, 11 Sep 2002 14:55:05 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05100302b9a540aab75d@[10.0.170.56]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 11 Sep 2002 14:55:01 -0400
To: "Hallam-Baker, Phillip" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: What happened to the OCSPv2 draft?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [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>

At 11:25 AM -0700 9/11/02, Hallam-Baker, Phillip wrote:
>The premise of the original OCSP redesign was to make it extensible.
>Ambarish was the main advocate of the modifications.
>
>Now that people are saying that extending OCSP is not the way to support
>related certificate status and validity type functions and Ambarish has
>proposed creating yet another protocol. Those of us who had the extension
>mechanism forced on us have the right to form a judgement on the matter.
>
>This type of thing is only one example of the sort of never-ending tinkering
>that will happen if a group continues after all its milestones have been
>achieved. It is time for this group to declare victory and close. I do not
>believe that further work in this forum is going to result in any
>improvement of the drafts and is most likely to make things worse.
>
>Give the authors of the various drafts a couple of months to get the best
>efforts in and then have a humm poll at the spring IETF on which ones
>crossed the line in terms of being acceptably complete. Anything that fails
>to meet the deadline has to persuade the IESG to let them form a new working
>group or submit the idea as an X.509 defect report.
>
>		Phill
>

By my count, that's two messages in a row from you on the theme of 
"let's kill off the PKIX WG."  Your first message claimed that we are 
pursuing standardization of any protocol that uses ASN.1. All the 
work we have pursued is PKI-based, including the warranty extension, 
DPV/DPD, proxy certs, time stamp policies, etc.  So, that comment is 
patently false.

The future of OCSPv2 and its relevance to to the question of the 
future of this WG is equally silly.

Have you been hanging out with Todd?

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BINux27997 for ietf-pkix-bks; Wed, 11 Sep 2002 11:23:56 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BINsk27990 for <[e-mail]>; Wed, 11 Sep 2002 11:23:54 -0700 (PDT)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8BINuXA021209; Wed, 11 Sep 2002 11:23:56 -0700 (PDT)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <SLC3PQSW>; Wed, 11 Sep 2002 11:25:49 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: What happened to the OCSPv2 draft?
Date: Wed, 11 Sep 2002 11:25:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

The premise of the original OCSP redesign was to make it extensible.
Ambarish was the main advocate of the modifications.

Now that people are saying that extending OCSP is not the way to support
related certificate status and validity type functions and Ambarish has
proposed creating yet another protocol. Those of us who had the extension
mechanism forced on us have the right to form a judgement on the matter.

This type of thing is only one example of the sort of never-ending tinkering
that will happen if a group continues after all its milestones have been
achieved. It is time for this group to declare victory and close. I do not
believe that further work in this forum is going to result in any
improvement of the drafts and is most likely to make things worse.

Give the authors of the various drafts a couple of months to get the best
efforts in and then have a humm poll at the spring IETF on which ones
crossed the line in terms of being acceptably complete. Anything that fails
to meet the deadline has to persuade the IESG to let them form a new working
group or submit the idea as an X.509 defect report.

		Phill 


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 8:09 AM
> To: [e-mail]
> Subject: What happened to the OCSPv2 draft?
> 
> 
> 
> This seems to have died at -02, there are hints of a -03 but 
> no copies remain,
> and the -02 draft is 1 1/2 years old.
> 
> (The reason I'd like to get a later version is that the -02 
> draft mixes up
>  explicit and implicit tagging, and I'd like to see whether a 
> newer version
>  includes an ASN.1 module which clarifies what's actually 
> being used.  The
>  -02 draft doesn't).
> 
> Peter.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BFhue16893 for ietf-pkix-bks; Wed, 11 Sep 2002 08:43:56 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BFhtk16883 for <[e-mail]>; Wed, 11 Sep 2002 08:43:55 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA22120; Wed, 11 Sep 2002 17:48:54 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002091117434886:709 ; Wed, 11 Sep 2002 17:43:48 +0200 
Message-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 17:43:44 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: What happened to the OCSPv2 draft?
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 11/09/2002 17:43:49, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 11/09/2002 17:43:50, Serialize complete at 11/09/2002 17:43:50
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Peter,

I do not care about OCSP v2: some documents die.

However, I care with OCSP(v1)bis. The Yokohama meeting report states:

"Roadmap, OCSP(v1)bis and PI documents in IESG queue."

The document is available at: http://www.imc.org/draft-ietf-pkix-rfc2560bis

Maybe you have the answer to your question in that document ?

Denis

> This seems to have died at -02, there are hints of a -03 but no copies remain,
> and the -02 draft is 1 1/2 years old.
> 
> (The reason I'd like to get a later version is that the -02 draft mixes up
>  explicit and implicit tagging, and I'd like to see whether a newer version
>  includes an ASN.1 module which clarifies what's actually being used.  The
>  -02 draft doesn't).
> 
> Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BF9Uu14775 for ietf-pkix-bks; Wed, 11 Sep 2002 08:09:30 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BF9Rk14771 for <[e-mail]>; Wed, 11 Sep 2002 08:09:28 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8BF9NI5019823 for <[e-mail]>; Thu, 12 Sep 2002 03:09:23 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id DAA329712 for [e-mail]; Thu, 12 Sep 2002 03:09:22 +1200 (NZST) (sender [e-mail])
Date: Thu, 12 Sep 2002 03:09:22 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: What happened to the OCSPv2 draft?
Sender: [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>

This seems to have died at -02, there are hints of a -03 but no copies remain,
and the -02 draft is 1 1/2 years old.

(The reason I'd like to get a later version is that the -02 draft mixes up
 explicit and implicit tagging, and I'd like to see whether a newer version
 includes an ASN.1 module which clarifies what's actually being used.  The
 -02 draft doesn't).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8ALHWF23376 for ietf-pkix-bks; Tue, 10 Sep 2002 14:17:32 -0700 (PDT)
Received: from OHTHREE.jjj-i.com (homer.ntru.com [208.252.42.180]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ALHVk23372 for <[e-mail]>; Tue, 10 Sep 2002 14:17:32 -0700 (PDT)
Received: by OHTHREE.jjj-i.com with Internet Mail Service (5.5.2650.21) id <S3PAJ556>; Tue, 10 Sep 2002 17:17:28 -0400
Message-ID: <[e-mail]>
From: "Singer, Ari" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated sig natures
Date: Tue, 10 Sep 2002 17:17:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

Hi, Terry and Russ.

This won't answer the question of the "official" source for the SHA-xxx
OIDs, but I will follow up with Tim to make sure that these are the correct
OIDs and include them (along with the new RSA OIDs that use them) in the
next draft of the supplemental algorithms draft as imported OIDs.  That
should suffice for the PKIX working group, at least.  The new draft will be
available before the Atlanta meeting.

Best regards,
Ari

Ari Singer, Principal Engineer
NTRU
5 Burlington Woods
Burlington, MA 01803
Main: [phone]
Personal: [phone]
Fax: [phone]


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Tuesday, September 10, 2002 12:52 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
> signatures
> 
> 
> 
> Terry:
> 
> It is my understanding from Tim Polk that these OIDs are 
> official.  I do 
> not know the method that will be used to publish them.
> 
> Russ
> 
> At 05:25 PM 9/9/2002 -0700, Terry Hayes wrote:
> >Thanks Russ for the pointers to the new RSA values.  I 
> hadn't noticed the 
> >June update to PKCS #1.
> >
> >I see that the latest PKCS #1 update, the lastest S/MIME 
> RSAES-OAEP draft 
> >and the latest PKIX supplimental algorithms draft all refer 
> to the new 
> >hash algorithms using the OIDs that I had seen previously.
> >
> >Is there any timetable for an official publication of these 
> OIDs, perhaps 
> >on the CSOR page at NIST 
> >(<http://csrc.nist.gov/csor/algorithms.htm>http://csrc.nist.g
> ov/csor/algorithms.htm)?
> >
> >Terry
> >
> >Housley, Russ wrote:
> >
> >>Terry:
> >>
> >>The most recent PKCS#1 ASN.1 module includes:
> >>
> >>    --
> >>    -- When the following OIDs are used in an 
> AlgorithmIdentifier the
> >>    -- parameters MUST be present and MUST be NULL.
> >>    --
> >>    md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
> >>    md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
> >>    sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
> >>    sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
> >>    sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
> >>    sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }
> >>
> >>
> >>Russ
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: <mailto:[e-mail]>[e-mail]
> >>To: <mailto:[e-mail]>[e-mail]
> >>Sent: 9/9/02 6:42 PM
> >>Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
> >>signatures
> >>
> >>Now that FIPS 180-2 will be effective in Feburary 2003, it's time to
> >>implement them in cryptographic libraries and in protocol
> >>implementations. However I have not been able to find official
> >>definitions of the OID values for these new algorithms.
> >>
> >>I've seen the following values proposed as the OIDs for the new SHA
> >>variants:
> >>
> >>     SHA-256:    2.16.840.1.101.3.4.2.1
> >>     SHA-384:    2.16.840.1.101.3.4.2.2
> >>     SHA-512:    2.16.840.1.101.3.4.2.3
> >>
> >>My source for these called these values "provisional."  Is there an
> >>official definition somewhere?
> >>
> >>In addition to OIDs for the hash functions themselves, 
> additional OIDs
> >>need to be defined for other operations that use them.  In 
> particular, a
> >>value for sha-256WithRSAEncryption should be defined as soon as
> >>possible.  I expect that this algorithm will become popular fairly
> >>quickly, replacing sha-1WithRSAEncryption in deployments 
> that want an
> >>effective security level of 128 bits.  
> sha-256WithRSAEncryption should
> >>also be added to the PKIX algorithms RFC (probably as a 
> SHOULD) at the
> >>next opportunity.
> >>
> >>Who will be defining sha-256WithRSAEncryption?
> >>
> >>Terry Hayes
> >><mailto:[e-mail]>[e-mail] 
<mailto:[e-mail]>
>>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8AGql708736 for ietf-pkix-bks; Tue, 10 Sep 2002 09:52:47 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8AGqjk08732 for <[e-mail]>; Tue, 10 Sep 2002 09:52:45 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Sep 2002 16:52:47 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA06985 for <[e-mail]>; Tue, 10 Sep 2002 12:52:46 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g8AGoRO28394 for <[e-mail]>; Tue, 10 Sep 2002 12:50:27 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVSG20>; Tue, 10 Sep 2002 12:52:45 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.16]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVSG29; Tue, 10 Sep 2002 12:52:39 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 10 Sep 2002 12:52:15 -0400
Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated signatures
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Terry:

It is my understanding from Tim Polk that these OIDs are official.  I do 
not know the method that will be used to publish them.

Russ

At 05:25 PM 9/9/2002 -0700, Terry Hayes wrote:
>Thanks Russ for the pointers to the new RSA values.  I hadn't noticed the 
>June update to PKCS #1.
>
>I see that the latest PKCS #1 update, the lastest S/MIME RSAES-OAEP draft 
>and the latest PKIX supplimental algorithms draft all refer to the new 
>hash algorithms using the OIDs that I had seen previously.
>
>Is there any timetable for an official publication of these OIDs, perhaps 
>on the CSOR page at NIST 
>(<http://csrc.nist.gov/csor/algorithms.htm>http://csrc.nist.gov/csor/algorithms.htm)?
>
>Terry
>
>Housley, Russ wrote:
>
>>Terry:
>>
>>The most recent PKCS#1 ASN.1 module includes:
>>
>>    --
>>    -- When the following OIDs are used in an AlgorithmIdentifier the
>>    -- parameters MUST be present and MUST be NULL.
>>    --
>>    md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
>>    md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
>>    sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
>>    sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
>>    sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
>>    sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }
>>
>>
>>Russ
>>
>>
>>
>>-----Original Message-----
>>From: <mailto:[e-mail]>[e-mail]
>>To: <mailto:[e-mail]>[e-mail]
>>Sent: 9/9/02 6:42 PM
>>Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
>>signatures
>>
>>Now that FIPS 180-2 will be effective in Feburary 2003, it's time to
>>implement them in cryptographic libraries and in protocol
>>implementations. However I have not been able to find official
>>definitions of the OID values for these new algorithms.
>>
>>I've seen the following values proposed as the OIDs for the new SHA
>>variants:
>>
>>     SHA-256:    2.16.840.1.101.3.4.2.1
>>     SHA-384:    2.16.840.1.101.3.4.2.2
>>     SHA-512:    2.16.840.1.101.3.4.2.3
>>
>>My source for these called these values "provisional."  Is there an
>>official definition somewhere?
>>
>>In addition to OIDs for the hash functions themselves, additional OIDs
>>need to be defined for other operations that use them.  In particular, a
>>value for sha-256WithRSAEncryption should be defined as soon as
>>possible.  I expect that this algorithm will become popular fairly
>>quickly, replacing sha-1WithRSAEncryption in deployments that want an
>>effective security level of 128 bits.  sha-256WithRSAEncryption should
>>also be added to the PKIX algorithms RFC (probably as a SHOULD) at the
>>next opportunity.
>>
>>Who will be defining sha-256WithRSAEncryption?
>>
>>Terry Hayes
>><mailto:[e-mail]>[e-mail] <mailto:[e-mail]>
>>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8AF0Oa29985 for ietf-pkix-bks; Tue, 10 Sep 2002 08:00:24 -0700 (PDT)
Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AF0Nk29981 for <[e-mail]>; Tue, 10 Sep 2002 08:00:23 -0700 (PDT)
Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <[e-mail]> for [e-mail]; Tue, 10 Sep 2002 10:00:24 -0500 (CDT)
Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.11.6+Sun/8.11.6) with ESMTP id g8AF0NC17557; Tue, 10 Sep 2002 10:00:23 -0500 (CDT)
Date: Tue, 10 Sep 2002 10:00:23 -0500
From: Matt Crawford <[e-mail]>
Subject: OID for a Kerberos principal name in an X509 subject DN?
To: [e-mail], [e-mail]
Message-id: <[e-mail]>
Sender: [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>

Is there a correct OID to use for including a Kerberos principal name
in a DN?  Is it one of

	1.2.840.113554.1.2.2.1 - gss-krb5-nt-principal-name
		(...mit infosys gssapi krb5 krb5_name)
or
	1.3.6.1.5.6.4 - gss-api-exported-name

or something completely different?


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8A22sh00986 for ietf-pkix-bks; Mon, 9 Sep 2002 19:02:54 -0700 (PDT)
Received: from mailout.zetnet.co.uk ([e-mail] [194.247.47.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8A22rk00982 for <[e-mail]>; Mon, 9 Sep 2002 19:02:53 -0700 (PDT)
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by mailout.zetnet.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 17oaMY-0002Qp-00 for <[e-mail]>; Tue, 10 Sep 2002 03:02:46 +0100
Received: from zetnet.co.uk (bts-1005.dialup.zetnet.co.uk [194.247.51.237]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g8A22Yb15117 for <[e-mail]>; Tue, 10 Sep 2002 03:02:34 +0100
Message-ID: <[e-mail]>
Date: Tue, 10 Sep 2002 02:52:28 +0000
From: David Hopwood <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated signatures
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

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

Terry Hayes wrote:
> Now that FIPS 180-2 will be effective in Feburary 2003, it's time to
> implement them in cryptographic libraries and in protocol implementations.
> However I have not been able to find official definitions of the OID values
> for these new algorithms.
> 
> I've seen the following values proposed as the OIDs for the new SHA variants:
> 
>     SHA-256:    2.16.840.1.101.3.4.2.1
>     SHA-384:    2.16.840.1.101.3.4.2.2
>     SHA-512:    2.16.840.1.101.3.4.2.3
> 
> My source for these called these values "provisional."

That was probably me (see <http://www.users.zetnet.co.uk/hopwood/crypto/scan/>),
so I should say where I got those OIDs from. They come from two sources that
agree with each other:

 - decoding the DER given in the description of the EMSA3 encoding method in
   P1363a (since at least draft 7, I believe, but certainly in section 12.1.3
   of draft 10.5).

 - PKCS#1 v2.1 draft 2, section B.1, which says:

     id-SHA256 OBJECT IDENTIFIER ::=
       {joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3)
        nistalgorithm(4) hashalgs(2) 1 }

     id-SHA384 OBJECT IDENTIFIER ::=
       {joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3)
        nistalgorithm(4) hashalgs(2) 2 }

     id-SHA512 OBJECT IDENTIFIER ::=
       {joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3)
        nistalgorithm(4) hashalgs(2) 3 }

They *should* also be documented at <http://csrc.nist.gov/csor/algorithms.htm>,
but aren't. I got no response the last time I emailed NIST about this, although
that was some time ago.

The OIDs for the hash functions are of course different from the OIDs for the
corresponding RSA signature schemes, which are what Russ Housley posted.

The Google search <http://www.google.com/search?q=2.16.840.1.101.3.4.2.1>
seems to imply that some people have already been including these OIDs in
libraries and protocol drafts (e.g. the OpenPGP / RFC2440bis draft).

- -- 
David Hopwood <[e-mail]>

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


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPX1eDDkCAxeYt5gVAQE6OggAjqFx+bGKdwz9x01HeT+OuOTAy59/Qivi
MdaTUnnIGw9sU/PvzplDqvS7TXdw7wh9CvRDIZ0Ew8JiUV8QCoWyq6oLOk6gZuyj
cFXgC7oyxVFRYilqAhLowVmlL6JhevJ1DS+3V+2iXG/+wx8McwNKKU/039pYMfOA
IQX9iqHpdRP5lRq2kdsJFMI6YCFVu119fQQEqZweQ7/TdrQNXvMwYxBKpyKGW28Y
jpwpNy1C2qIvB8zadr4Gepqsu4oqSd0WcHmlahMpZwwEat8dTXbGMvcbU38Brx8h
BHO8N+AqjoyqCPJMKmNum7LBWPqJwz6Xm0jicCZwySFU0tV2vzuRyg==
=95vm
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8A0PNk28606 for ietf-pkix-bks; Mon, 9 Sep 2002 17:25:23 -0700 (PDT)
Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8A0PLk28602 for <[e-mail]>; Mon, 9 Sep 2002 17:25:21 -0700 (PDT)
Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id g89NZim11618 for <[e-mail]>; Mon, 9 Sep 2002 16:35:45 -0700 (PDT)
Received: from h-10-169-25-78.nscp.aoltw.net ([10.169.25.78]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H2755Q02.9RG; Mon, 9 Sep 2002 17:25:02 -0700 
Date: Mon, 9 Sep 2002 17:25:19 -0700
From: [e-mail] (Terry Hayes)
Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated sig	natures
To: [e-mail], Russ <[e-mail]>
cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Mailer: Netscape Messenger M8 (powered by Photon [20020909.2])
Organization: Netscape Communications Corp.
MIME-Version: 1.0
Content-Type: TEXT/HTML; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: [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>

Thanks Russ for the pointers to the new RSA values. =A0I hadn't noticed the
June update to PKCS #1.<br>
<br>
I see that the latest PKCS #1 update, the lastest S/MIME RSAES-OAEP draft
and the latest PKIX supplimental algorithms draft all refer to the new hash
algorithms using the OIDs that I had seen previously.<br>
<br>
Is there any timetable for an official publication of these OIDs, perhaps
on the CSOR page at NIST (<a class=3D"moz-txt-link-freetext" href=3D"http:/=
/csrc.nist.gov/csor/algorithms.htm">http://csrc.nist.gov/csor/algorithms.ht=
m</a>)?<br>
<br>
Terry<br>
<br>
Housley, Russ wrote:<br>
=20
<p> </p>
<blockquote type=3D"cite"
 style=3D"border-left: thin solid blue; padding-left: 10px; margin-left: 0p=
t;">=20
  <tt> Terry: <br>
 <br>
 The most recent PKCS#1 ASN.1 module includes: <br>
 <br>
 =A0=A0 -- <br>
 =A0=A0 -- When the following OIDs are used in an AlgorithmIdentifier the <=
br>
 =A0=A0 -- parameters MUST be present and MUST be NULL. <br>
 =A0=A0 -- <br>
 =A0=A0 md2WithRSAEncryption=A0=A0=A0=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pk=
cs-1 2 } <br>
 =A0=A0 md5WithRSAEncryption=A0=A0=A0=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pk=
cs-1 4 } <br>
 =A0=A0 sha1WithRSAEncryption=A0=A0=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pkcs=
-1 5 } <br>
 =A0=A0 sha256WithRSAEncryption=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pkcs-1 1=
1 } <br>
 =A0=A0 sha384WithRSAEncryption=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pkcs-1 1=
2 } <br>
 =A0=A0 sha512WithRSAEncryption=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pkcs-1 1=
3 } <br>
 =A0=A0 <br>
 <br>
 Russ <br>
 <br>
  <br>
 <br>
 -----Original Message----- <br>
 From: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:thayes@netscape=
.com">[e-mail]</a> <br>
 To: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[e-mail]=
">[e-mail]</a> <br>
 Sent: 9/9/02 6:42 PM <br>
 Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated <br>
 signatures <br>
 <br>
 Now that FIPS 180-2 will be effective in Feburary 2003, it's time to <br>
 implement them in cryptographic libraries and in protocol <br>
 implementations. However I have not been able to find official <br>
 definitions of the OID values for these new algorithms. <br>
 <br>
 I've seen the following values proposed as the OIDs for the new SHA <br>
 variants: <br>
 <br>
 =A0=A0=A0 SHA-256:=A0=A0=A0 2.16.840.1.101.3.4.2.1 <br>
 =A0=A0=A0 SHA-384:=A0=A0=A0 2.16.840.1.101.3.4.2.2 <br>
 =A0=A0=A0 SHA-512:=A0=A0=A0 2.16.840.1.101.3.4.2.3 <br>
 <br>
 My source for these called these values "provisional."=A0 Is there an <br>
 official definition somewhere? <br>
 <br>
 In addition to OIDs for the hash functions themselves, additional OIDs <br=
>
 need to be defined for other operations that use them.=A0 In particular, a=
=20
  <br>
 value for sha-256WithRSAEncryption should be defined as soon as <br>
 possible.=A0 I expect that this algorithm will become popular fairly <br>
 quickly, replacing sha-1WithRSAEncryption in deployments that want an <br>
 effective security level of 128 bits.=A0 sha-256WithRSAEncryption should <=
br>
 also be added to the PKIX algorithms RFC (probably as a SHOULD) at the <br=
>
 next opportunity. <br>
 <br>
 Who will be defining sha-256WithRSAEncryption? <br>
 <br>
 Terry Hayes <br>
 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[e-mail]">=
[e-mail]</a> &lt;<a href=3D"mailto:[e-mail]">mailto:t=
[e-mail]</a>&gt;
  <br>
 <br>
 <br>
 </tt> </blockquote>



Received: by above.proper.com (8.11.6/8.11.3) id g89NTtZ27738 for ietf-pkix-bks; Mon, 9 Sep 2002 16:29:55 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g89NTrk27732 for <[e-mail]>; Mon, 9 Sep 2002 16:29:53 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 Sep 2002 23:29:57 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id TAA28944; Mon, 9 Sep 2002 19:29:56 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g89NRbm00956; Mon, 9 Sep 2002 19:27:37 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVR71D>; Mon, 9 Sep 2002 19:29:54 -0400
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated sig natures
Date: Mon, 9 Sep 2002 19:29:27 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

Terry:

The most recent PKCS#1 ASN.1 module includes:

   --
   -- When the following OIDs are used in an AlgorithmIdentifier the
   -- parameters MUST be present and MUST be NULL.
   --
   md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
   md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
   sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
   sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
   sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
   sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }
   

Russ

 

-----Original Message-----
From: [e-mail]
To: [e-mail]
Sent: 9/9/02 6:42 PM
Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
signatures

Now that FIPS 180-2 will be effective in Feburary 2003, it's time to
implement them in cryptographic libraries and in protocol
implementations. However I have not been able to find official
definitions of the OID values for these new algorithms.

I've seen the following values proposed as the OIDs for the new SHA
variants:

    SHA-256:    2.16.840.1.101.3.4.2.1
    SHA-384:    2.16.840.1.101.3.4.2.2
    SHA-512:    2.16.840.1.101.3.4.2.3

My source for these called these values "provisional."  Is there an
official definition somewhere?

In addition to OIDs for the hash functions themselves, additional OIDs
need to be defined for other operations that use them.  In particular, a
value for sha-256WithRSAEncryption should be defined as soon as
possible.  I expect that this algorithm will become popular fairly
quickly, replacing sha-1WithRSAEncryption in deployments that want an
effective security level of 128 bits.  sha-256WithRSAEncryption should
also be added to the PKIX algorithms RFC (probably as a SHOULD) at the
next opportunity.

Who will be defining sha-256WithRSAEncryption?

Terry Hayes
[e-mail] <mailto:[e-mail]> 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g89Mh0926954 for ietf-pkix-bks; Mon, 9 Sep 2002 15:43:00 -0700 (PDT)
Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g89Mgwk26949 for <[e-mail]>; Mon, 9 Sep 2002 15:42:58 -0700 (PDT)
Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id g89Lr8m01772 for <[e-mail]>; Mon, 9 Sep 2002 14:53:11 -0700 (PDT)
Received: from h-10-169-25-78.nscp.aoltw.net ([10.169.25.78]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H270EQ03.5R1 for <[e-mail]>; Mon, 9 Sep 2002 15:42:26 -0700 
Date: Mon, 9 Sep 2002 15:42:43 -0700
From: [e-mail] (Terry Hayes)
Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated signatures
To: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: Netscape Messenger M8 (powered by Photon [20020830.1])
Organization: Netscape Communications Corp.
MIME-Version: 1.0
Content-Type: TEXT/HTML; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: [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>

Now that FIPS 180-2 will be effective in Feburary 2003, it's time to implem=
ent
them in cryptographic libraries and in protocol implementations. However
I have not been able to find official definitions of the OID values for the=
se
new algorithms.<br>
<br>
I've seen the following values proposed as the OIDs for the new SHA variant=
s:<br>
<br>
=A0=A0=A0 SHA-256:=A0=A0=A0 2.16.840.1.101.3.4.2.1<br>
=A0=A0=A0 SHA-384:=A0=A0=A0 2.16.840.1.101.3.4.2.2<br>
=A0=A0=A0 SHA-512:=A0=A0=A0 2.16.840.1.101.3.4.2.3<br>
<br>
My source for these called these values "provisional." =A0Is there an offic=
ial
definition somewhere?<br>
<br>
In addition to OIDs for the hash functions themselves, additional OIDs need
to be defined for other operations that use them. =A0In particular, a value
for sha-256WithRSAEncryption should be defined as soon as possible. =A0I ex=
pect
that this algorithm will become popular fairly quickly, replacing sha-1With=
RSAEncryption
in deployments that want an effective security level of 128 bits. =A0sha-25=
6WithRSAEncryption
should also be added to the PKIX algorithms RFC (probably as a SHOULD) at
the next opportunity.<br>
<br>
Who will be defining sha-256WithRSAEncryption?<br>
<br>
Terry Hayes<br>
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[e-mail]">t=
[e-mail]</a><br>
<br>



Received: by above.proper.com (8.11.6/8.11.3) id g89IdQ921019 for ietf-pkix-bks; Mon, 9 Sep 2002 11:39:26 -0700 (PDT)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g89IdOk21015 for <[e-mail]>; Mon, 9 Sep 2002 11:39:24 -0700 (PDT)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g89IdMeD021469; Mon, 9 Sep 2002 11:39:22 -0700 (PDT)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id <S2QKAZRC>; Mon, 9 Sep 2002 11:41:14 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, Steve Tuecke <[e-mail]>
Cc: [e-mail]
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Mon, 9 Sep 2002 11:41:05 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [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>

Answer: Start a new group

PKIX was formed to do one thing and has become a standing committee that
will do anything, provided it is in ASN.1 syntax. That is a bad thing. 

I would much prefer to see the group split into two. Continuing PKIX would
be tasked with simply moving the current RFCs through the standards track to
Draft and Standard. PKIX-EXT would be tasked with developing extensions to
PKIX where necessary.


		Phill 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g89IOLJ20580 for ietf-pkix-bks; Mon, 9 Sep 2002 11:24:21 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g89IOFk20573 for <[e-mail]>; Mon, 9 Sep 2002 11:24:15 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 9 Sep 2002 11:13:59 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 09 Sep 2002 11:13:58 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <R3KYDW31>; Mon, 09 Sep 2002 11:23:58 -0700
Content-return: allowed
Date: Mon, 09 Sep 2002 11:23:57 -0700
From: Peter Williams <[e-mail]>
Subject: RE: draft-ietf-pkix-warranty-ext-01
To: "'Denis Pinkas '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Cc: "'Anders Rundgren '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_5b881ouBlaerftQXl7K/Sg)"
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [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>

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

--Boundary_(ID_5b881ouBlaerftQXl7K/Sg)
Content-type: text/plain

 
I helped review the first warranty program, for Michael
Baum's Public Certification Service concept. Whilst I dont 
believe its useful for IETF to focus on
warranties, I do believe clarifiation of just
what a CP-based warranty is is useful.

I dont expect users to ever really understand the
difference in the legal model between certification, 
representation, warranty, insurance, reliance, etc.

What they do need to understand however is

1. The common notion of first-come-first-served 
payout-limits (which means they may get a shock when multiple 
parties all claim for the limited cash)

2. Warranty execlusions are often structured such that
few can ever make a valid claim. These warranties
are just marketing gimics, to puff trustworthiness.
Valuable warranties are transactional, by banks or
Japanese trading houses like Mitsui. They really
dont function as an adjunt to authentication.

Conclusion: If IETF proceeds, the result should be at most
an informational RFC.

N.B.

My comments - as a practitioner - may sound harsh on public 
CAs. Warranties are appropriate - they just dont have in practice 
the direct  benefits that are marketed. The costs of the 
protection plans' insurance is essentially just 
an indirect tax on providing core trustworthiness of
a TTP-grade CA.

-----Original Message-----
From: Denis Pinkas
To: [e-mail]
Cc: Anders Rundgren; [e-mail]; [e-mail]
Sent: 9/2/02 3:50 AM
Subject: Re: draft-ietf-pkix-warranty-ext-01


Alice,

I concur with many of the arguments raised by Anders. It is very scarce,
but
this time it happened, thanks to your draft. :-) 

I believe that sufficient arguments have been raised against the
progression
of this draft, as it stands, which does not even explicitly states, for
a
naive reader, what the warranty is about.

The warranty is concerned with the liability of the CA, more precisely,
only 
errors made by the CA personal or attributed to the CA during the
management
of the certificate, e.g. at the time of registration of the subject,
when
issuing the certificate, when handling revocation requests or when
making
available revocation status information.

Regards,

Denis

> Alice,
> 
> >Lynn observed that the world of financial risk management is moving
past
> >per-transaction model.  The proposed extension offers an aggregate
model.
> >Also Lynn wrote: "and any migration to an offline paradigm with
> >> both support for per transaction as well as aggregation risk/limits
> >> obsoletes the requirement for the certificate."
> >That's true; that's why the extension is useful.  If total risk,
i.e.,
> >aggregated transactions, is the primary worry of the insurance
industry then
> >the aggregate model would be appropriate.
> 
> This sounds pretty dangerous as it gives no value to an RP which may
be just
> one of several thousands of RPs which just received a purchase order
> from a company that is on the edge of filing for bankruptcy.
> 
> If it is of no value to RPs, the only purpose left for the
warranty-extension
> is for a CA to insert its liability limit in a machine-readable
> format.  Is this really interesting as any liability above zero is
likely
> to be accompanied by a non-machine-interpretable agreement?
> 
> Is the intent, that the moment a transaction is received that exceeds
> the liability limit, an alert is to be sent to the legal department?
> Depending on the liability agreement this may be too late
> as lower-amount transactions may be equally uncovered.
> 
> Actually it would IMO better be a part of the CA-certificate to
> declare what it stands for in terms of liability.
> 
> Regarding warranted purchase orders, I have serious problems
> understanding what a CA-issued warranty could possibly cover except
> for a liability for having certified the wrong entity which is now
making
> fake orders.  But IMHO such a warranty is equally applicable to
> authentications, as incorrect such are even worse as you cannot
> "rollback" authentication events.
> 
> For pure financial transactions, there are already solutions in place
> since ages ago, like bank-warranties, remburses and pre-paid orders.
> 
> cheers,
> Anders

--Boundary_(ID_5b881ouBlaerftQXl7K/Sg)
Content-type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: draft-ietf-pkix-warranty-ext-01</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>I helped review the first warranty program, for Michael</FONT>
<BR><FONT SIZE=2>Baum's Public Certification Service concept. Whilst I dont </FONT>
<BR><FONT SIZE=2>believe its useful for IETF to focus on</FONT>
<BR><FONT SIZE=2>warranties, I do believe clarifiation of just</FONT>
<BR><FONT SIZE=2>what a CP-based warranty is is useful.</FONT>
</P>

<P><FONT SIZE=2>I dont expect users to ever really understand the</FONT>
<BR><FONT SIZE=2>difference in the legal model between certification, </FONT>
<BR><FONT SIZE=2>representation, warranty, insurance, reliance, etc.</FONT>
</P>

<P><FONT SIZE=2>What they do need to understand however is</FONT>
</P>

<P><FONT SIZE=2>1. The common notion of first-come-first-served </FONT>
<BR><FONT SIZE=2>payout-limits (which means they may get a shock when multiple </FONT>
<BR><FONT SIZE=2>parties all claim for the limited cash)</FONT>
</P>

<P><FONT SIZE=2>2. Warranty execlusions are often structured such that</FONT>
<BR><FONT SIZE=2>few can ever make a valid claim. These warranties</FONT>
<BR><FONT SIZE=2>are just marketing gimics, to puff trustworthiness.</FONT>
<BR><FONT SIZE=2>Valuable warranties are transactional, by banks or</FONT>
<BR><FONT SIZE=2>Japanese trading houses like Mitsui. They really</FONT>
<BR><FONT SIZE=2>dont function as an adjunt to authentication.</FONT>
</P>

<P><FONT SIZE=2>Conclusion: If IETF proceeds, the result should be at most</FONT>
<BR><FONT SIZE=2>an informational RFC.</FONT>
</P>

<P><FONT SIZE=2>N.B.</FONT>
</P>

<P><FONT SIZE=2>My comments - as a practitioner - may sound harsh on public </FONT>
<BR><FONT SIZE=2>CAs. Warranties are appropriate - they just dont have in practice </FONT>
<BR><FONT SIZE=2>the direct&nbsp; benefits that are marketed. The costs of the </FONT>
<BR><FONT SIZE=2>protection plans' insurance is essentially just </FONT>
<BR><FONT SIZE=2>an indirect tax on providing core trustworthiness of</FONT>
<BR><FONT SIZE=2>a TTP-grade CA.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Denis Pinkas</FONT>
<BR><FONT SIZE=2>To: [e-mail]</FONT>
<BR><FONT SIZE=2>Cc: Anders Rundgren; [e-mail]; [e-mail]</FONT>
<BR><FONT SIZE=2>Sent: 9/2/02 3:50 AM</FONT>
<BR><FONT SIZE=2>Subject: Re: draft-ietf-pkix-warranty-ext-01</FONT>
</P>
<BR>

<P><FONT SIZE=2>Alice,</FONT>
</P>

<P><FONT SIZE=2>I concur with many of the arguments raised by Anders. It is very scarce,</FONT>
<BR><FONT SIZE=2>but</FONT>
<BR><FONT SIZE=2>this time it happened, thanks to your draft. :-) </FONT>
</P>

<P><FONT SIZE=2>I believe that sufficient arguments have been raised against the</FONT>
<BR><FONT SIZE=2>progression</FONT>
<BR><FONT SIZE=2>of this draft, as it stands, which does not even explicitly states, for</FONT>
<BR><FONT SIZE=2>a</FONT>
<BR><FONT SIZE=2>naive reader, what the warranty is about.</FONT>
</P>

<P><FONT SIZE=2>The warranty is concerned with the liability of the CA, more precisely,</FONT>
<BR><FONT SIZE=2>only </FONT>
<BR><FONT SIZE=2>errors made by the CA personal or attributed to the CA during the</FONT>
<BR><FONT SIZE=2>management</FONT>
<BR><FONT SIZE=2>of the certificate, e.g. at the time of registration of the subject,</FONT>
<BR><FONT SIZE=2>when</FONT>
<BR><FONT SIZE=2>issuing the certificate, when handling revocation requests or when</FONT>
<BR><FONT SIZE=2>making</FONT>
<BR><FONT SIZE=2>available revocation status information.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

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

<P><FONT SIZE=2>&gt; Alice,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;Lynn observed that the world of financial risk management is moving</FONT>
<BR><FONT SIZE=2>past</FONT>
<BR><FONT SIZE=2>&gt; &gt;per-transaction model.&nbsp; The proposed extension offers an aggregate</FONT>
<BR><FONT SIZE=2>model.</FONT>
<BR><FONT SIZE=2>&gt; &gt;Also Lynn wrote: &quot;and any migration to an offline paradigm with</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; both support for per transaction as well as aggregation risk/limits</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; obsoletes the requirement for the certificate.&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt;That's true; that's why the extension is useful.&nbsp; If total risk,</FONT>
<BR><FONT SIZE=2>i.e.,</FONT>
<BR><FONT SIZE=2>&gt; &gt;aggregated transactions, is the primary worry of the insurance</FONT>
<BR><FONT SIZE=2>industry then</FONT>
<BR><FONT SIZE=2>&gt; &gt;the aggregate model would be appropriate.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This sounds pretty dangerous as it gives no value to an RP which may</FONT>
<BR><FONT SIZE=2>be just</FONT>
<BR><FONT SIZE=2>&gt; one of several thousands of RPs which just received a purchase order</FONT>
<BR><FONT SIZE=2>&gt; from a company that is on the edge of filing for bankruptcy.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If it is of no value to RPs, the only purpose left for the</FONT>
<BR><FONT SIZE=2>warranty-extension</FONT>
<BR><FONT SIZE=2>&gt; is for a CA to insert its liability limit in a machine-readable</FONT>
<BR><FONT SIZE=2>&gt; format.&nbsp; Is this really interesting as any liability above zero is</FONT>
<BR><FONT SIZE=2>likely</FONT>
<BR><FONT SIZE=2>&gt; to be accompanied by a non-machine-interpretable agreement?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Is the intent, that the moment a transaction is received that exceeds</FONT>
<BR><FONT SIZE=2>&gt; the liability limit, an alert is to be sent to the legal department?</FONT>
<BR><FONT SIZE=2>&gt; Depending on the liability agreement this may be too late</FONT>
<BR><FONT SIZE=2>&gt; as lower-amount transactions may be equally uncovered.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Actually it would IMO better be a part of the CA-certificate to</FONT>
<BR><FONT SIZE=2>&gt; declare what it stands for in terms of liability.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regarding warranted purchase orders, I have serious problems</FONT>
<BR><FONT SIZE=2>&gt; understanding what a CA-issued warranty could possibly cover except</FONT>
<BR><FONT SIZE=2>&gt; for a liability for having certified the wrong entity which is now</FONT>
<BR><FONT SIZE=2>making</FONT>
<BR><FONT SIZE=2>&gt; fake orders.&nbsp; But IMHO such a warranty is equally applicable to</FONT>
<BR><FONT SIZE=2>&gt; authentications, as incorrect such are even worse as you cannot</FONT>
<BR><FONT SIZE=2>&gt; &quot;rollback&quot; authentication events.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; For pure financial transactions, there are already solutions in place</FONT>
<BR><FONT SIZE=2>&gt; since ages ago, like bank-warranties, remburses and pre-paid orders.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; cheers,</FONT>
<BR><FONT SIZE=2>&gt; Anders</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_5b881ouBlaerftQXl7K/Sg)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g89H9Ql17686 for ietf-pkix-bks; Mon, 9 Sep 2002 10:09:26 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g89H9Ok17682 for <[e-mail]>; Mon, 9 Sep 2002 10:09:24 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 9 Sep 2002 09:58:58 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 09 Sep 2002 09:58:58 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <R3KYDW1F>; Mon, 09 Sep 2002 10:08:58 -0700
Content-return: allowed
Date: Mon, 09 Sep 2002 10:08:57 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Timestamping + Cert revocation + revocation question
To: "'Michael Fritscher '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_sW3MjDDmlKqps04t00xbcQ)"
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [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>

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

--Boundary_(ID_sW3MjDDmlKqps04t00xbcQ)
Content-type: text/plain

The various signature laws are written with the assumption
that a seperate record management infrastructure keeps the
assurnace of strong authentication uptodate.

Attmepting to remove the obligation to manage records from 
digital signature frameworks, using technical tricks, is 
really going against the legal framework now in place.

I cant the community that got the legal frameworks established 
reformulating their model.

Its much easier (and this is what counts for the American
market) for users to manage a cheap, trusted message store and
storage medium, then solve a global infrastructure and policy 
problem. Auditors require users to maintain records, anyway.

At ValiCert, we never see any real demand for OCSP features
that provided for historical validation, for example. Folks
do integrate the trusted audit log however, signing the
log files of the validation server as evidence of 
proper authentication. Cheap, easy, natural.

BTW, VISA has a patent on some of this area, based on
work we did in root key handling during the SET committe work
in 1995. SET had specific rules on private and public key 
verification periods, and these rules were important
to the proof-of-possesion (card present) service.


-----Original Message-----
From: Michael Fritscher

As I have seen it till now, the only way to be able to verify a
signature is to have some valid (at the time of verification)
certificate for the private key that was used to sign a time-stamp on
another timestamp (or signature combined with a timestamp) valid at
the time of timestamping and so on... This way you get a chain of
trust over time and keep the signatures verifyable.
 

--Boundary_(ID_sW3MjDDmlKqps04t00xbcQ)
Content-type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Timestamping + Cert revocation + revocation question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>The various signature laws are written with the assumption</FONT>
<BR><FONT SIZE=2>that a seperate record management infrastructure keeps the</FONT>
<BR><FONT SIZE=2>assurnace of strong authentication uptodate.</FONT>
</P>

<P><FONT SIZE=2>Attmepting to remove the obligation to manage records from </FONT>
<BR><FONT SIZE=2>digital signature frameworks, using technical tricks, is </FONT>
<BR><FONT SIZE=2>really going against the legal framework now in place.</FONT>
</P>

<P><FONT SIZE=2>I cant the community that got the legal frameworks established </FONT>
<BR><FONT SIZE=2>reformulating their model.</FONT>
</P>

<P><FONT SIZE=2>Its much easier (and this is what counts for the American</FONT>
<BR><FONT SIZE=2>market) for users to manage a cheap, trusted message store and</FONT>
<BR><FONT SIZE=2>storage medium, then solve a global infrastructure and policy </FONT>
<BR><FONT SIZE=2>problem. Auditors require users to maintain records, anyway.</FONT>
</P>

<P><FONT SIZE=2>At ValiCert, we never see any real demand for OCSP features</FONT>
<BR><FONT SIZE=2>that provided for historical validation, for example. Folks</FONT>
<BR><FONT SIZE=2>do integrate the trusted audit log however, signing the</FONT>
<BR><FONT SIZE=2>log files of the validation server as evidence of </FONT>
<BR><FONT SIZE=2>proper authentication. Cheap, easy, natural.</FONT>
</P>

<P><FONT SIZE=2>BTW, VISA has a patent on some of this area, based on</FONT>
<BR><FONT SIZE=2>work we did in root key handling during the SET committe work</FONT>
<BR><FONT SIZE=2>in 1995. SET had specific rules on private and public key </FONT>
<BR><FONT SIZE=2>verification periods, and these rules were important</FONT>
<BR><FONT SIZE=2>to the proof-of-possesion (card present) service.</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Michael Fritscher</FONT>
</P>

<P><FONT SIZE=2>As I have seen it till now, the only way to be able to verify a</FONT>
<BR><FONT SIZE=2>signature is to have some valid (at the time of verification)</FONT>
<BR><FONT SIZE=2>certificate for the private key that was used to sign a time-stamp on</FONT>
<BR><FONT SIZE=2>another timestamp (or signature combined with a timestamp) valid at</FONT>
<BR><FONT SIZE=2>the time of timestamping and so on... This way you get a chain of</FONT>
<BR><FONT SIZE=2>trust over time and keep the signatures verifyable.</FONT>
<BR><FONT SIZE=2></FONT>&nbsp;
</P>

</BODY>
</HTML>

--Boundary_(ID_sW3MjDDmlKqps04t00xbcQ)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g89E0Gn11876 for ietf-pkix-bks; Mon, 9 Sep 2002 07:00:16 -0700 (PDT)
Received: from isis.wu-wien.ac.at (isis.wu-wien.ac.at [137.208.3.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g89E0Ek11870 for <[e-mail]>; Mon, 9 Sep 2002 07:00:14 -0700 (PDT)
Received: from wu-wien.ac.at (monk.wu-wien.ac.at [137.208.8.75]) by isis.wu-wien.ac.at (8.8.7/8.8.7) with ESMTP id PAA24650 for <[e-mail]>; emf [e-mail]; Mon, 9 Sep 2002 15:59:53 +0200
Message-Id: <[e-mail]>
Date: Mon, 09 Sep 2002 15:59:53 +0200
From: Michael Fritscher <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Subject: Re: Timestamping + Cert revocation + revocation question
User-Agent: IMHO/0.98.3 (Webmail for Roxen)
Content-Transfer-Encoding: 8bit
Sender: [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>

I am working on a thesis on signatures that can be validated over a
long period (similar to the 20 to 30 years mentioned here before).

I now went through the whole thread and got the impression that the
point behind the problems discussed in this thread is that you want to
have different validity periods for the use of the private key and the
use of the public key (correct me if I got that wrong).

IMHO there is no "technical" reason for having different validity
periods. If you can afford to extend the validity period for the
public key (in order to be able to verify a signature/certificate
after the certificate has expired), I see no reason why you could not
extend the validity period of the private key as well.

As I have seen it till now, the only way to be able to verify a
signature is to have some valid (at the time of verification)
certificate for the private key that was used to sign a time-stamp on
another timestamp (or signature combined with a timestamp) valid at
the time of timestamping and so on... This way you get a chain of
trust over time and keep the signatures verifyable.

Michael Fritscher
Any way, at least one valid signature over the rest is necessary.

I am aware of the fact that a chain of trust over time does not
address the problem of handling the verification of signatures whose
private key has been revoked after the signing time.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g89DhGv11389 for ietf-pkix-bks; Mon, 9 Sep 2002 06:43:16 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g89DhDk11384 for <[e-mail]>; Mon, 9 Sep 2002 06:43:14 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA11350; Mon, 9 Sep 2002 15:48:08 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002090915430479:181 ; Mon, 9 Sep 2002 15:43:04 +0200 
Message-ID: <[e-mail]>
Date: Mon, 09 Sep 2002 15:42:57 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: David Hopwood <[e-mail]>
CC: [e-mail]
Subject: Re: Timestamping + Cert revocation + revocation question
References: <001801c25338$76a03500$2308a8c0@MJDeskproEN> <[e-mail]> <008e01c2542a$cabd5300$2308a8c0@MJDeskproEN> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 09/09/2002 15:43:04, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 09/09/2002 15:43:06, Serialize complete at 09/09/2002 15:43:06
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

David,

> > Marc,
> > > I effectivelly think that for qualified cert and signature with a legal
> > > value, CRL should be maintain during the same period than the validity
> > > period of signatures.
> >
> > This sentence may be quite confusing. CRLs shall be kept by a verifier
> > during the same period than the validity period of the signature. However,
> > the CA is not concerned with any archiving of CRLs during such a time frame.
> >
> > > Thus archiving CRL for 20-30 years it not really enough, we should also
> > > maintain them during this period: we should be able to 'revoke' certs
> > > after expiration.
> >
> > At most, during a reasonable cautionary period, e.g. one month.
> 
> How long revocation needs to be possible for depends on the meaning of the
> certification. For example, in the case of code signing, a certificate carries
> the implication that (someone says that) the principal should be trusted to
> sign only secure code - that is, code that cannot be exploited, as well as not
> being itself malicious. The fact that a principal has been signing flawed code
> (intentionally or not) can discovered at *any* time. The certificate should
> therefore be able to be revoked at *any* point in its lifetime, independent of
> the use of timestamping.

Revocation is independant from timestamping.
 
Any certificate is revokabled at *any* point in its lifetime.

When time-stamping is used, signatures done prior to the revocation time
continue to be valid, if the time-stamp token was applied before the
revocation time.

When time-stamping is *not* used, signatures done prior to the revocation
have to be considered as invalid, unless ther timeliness can be demonstrated 
using other means.

Regards,

Denis

> Some people might argue that the revocation mechanism was never intended
> to be able to handle anything other than the compromise of private keys.
> Regardless, revocation is assumed in many protocols to be a way of
> "taking back" a certification for any reason at all.
> 
> - --
> David Hopwood <[e-mail]>
> 
> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
> Nothing in this message is intended to be legally binding. If I revoke a
> public key but refuse to specify why, it is because the private key has been
> seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
> 
> iQEVAwUBPXe5uTkCAxeYt5gVAQEWGgf/VteAjKGLOFc0o9TlR+NGjU7FC6JPuUKs
> Co3lm3OtzsHGdQIdNFtDAGZE0VfmpVvjXgKTxbLoDBYOtn80nMfLR7qnNL6jHRyb
> YiCJYE3sCQViP4K+rgAhDMnwoV1yA7dc7RrkQ8i5shlD5721rWnmL+D80TY/M9X6
> 4dUskeyjWfB+7jv8pqeFGNXJIOSBMvStAESDjm4MgMcwdkvLAUqSdrc0pUXLqe+1
> YfhJHsNlmi/shu0ezLFJ2iHQ5fJ9zUMDgjXcgviqSD5Yej5wJy/6DoX3236iSYfC
> wnvst5rYOJlXo3AludfjuuCIJwungn5U4Q8a5mIB76FqRyNqL6whsw==
> =T2ae
> -----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g86LZ1U29040 for ietf-pkix-bks; Fri, 6 Sep 2002 14:35:01 -0700 (PDT)
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g86LYwk29036 for <[e-mail]>; Fri, 6 Sep 2002 14:34:58 -0700 (PDT)
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g86LYNvI022502; Fri, 6 Sep 2002 17:34:24 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g86LYKiu040760; Fri, 6 Sep 2002 17:34:20 -0400
Importance: Normal
Sensitivity: 
Subject: Re: Timestamping + Cert revocation + revocation question
To: Denis Pinkas <[e-mail]>
Cc: Marc Jadoul <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 6 Sep 2002 17:34:13 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11  |July 29, 2002) at 09/06/2002 05:34:22 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [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>

      Actually, there is no reason to mandate PKU Period in general, just
to recommend it on NR certificates (and probably CA and CRL certificates as
well).  Like Peter, I have never understood why that extension was
deprecated.

            Tom Gindin

Denis Pinkas <[e-mail]>@mail.imc.org on 09/05/2002 09:19:29 AM

Sent by:    [e-mail]


To:    Marc Jadoul <[e-mail]>
cc:    [e-mail]
Subject:    Re: Timestamping + Cert revocation + revocation question



Marc,

(...)

> > > I effectivelly think that for qualified cert and signature with a
legal
> > > value, CRL should be maintain during the same period than the
validity
> > > period of signatures.

> > This sentence may be quite confusing. CRLs shall be kept by a verifier
> > during the same period than the validity period of the signature.
However,
> > the CA is not concerned with any archiving of CRLs during such a time
> frame.

> I am not a legal guy and yes I am probably mixing several issues. But, I
> know that ETSI TS 101 456 v1.2.1 require the CA to archive a lot of
> information. See point 7.4.11 e) saying that "Recording concerning
qualified
> certificates shall be held for a period of time as appropriate for
providing
> necessary legal evidence in support of electronic signature."

> I thought that this would imply that CRLs need to be archived for a very
> long time.

 ... but they will not be accessible to the public.

(...)

> > In order to solve nicely this issue, there is a need to add extra
> > information "somewhere".

> > 1) One possibilty is to use the private key usage period extension
> >    in a public key certificate.

> > 2) Another possibility would be to use the Archive Cutoff extension
> >    defined in RFC 2560 (OCSP) in section 4.4.4. The only problem
> >    is that we do not have the equivalent for CRLs.

> > Since the later solution would not increase the size of the
certificate,
> > this would have my preference.

> > In RFC 2560, Archive Cutoff is introduced as follows:

> >    An OCSP responder MAY choose to retain revocation information beyond
> >    a certificate's expiration.

> > For CRLs, it would be introduced as follows:

> >    A CRL Issuer MAY choose to retain revocation information beyond
> >    a certificate's expiration.

> I removed the rest of the discussion.

> I agree with you and James Manger that the "private key usage period
> extension" is a response to my concern.

> I agree with Peter Gutmann that I do not understand why it is recommanded
to
> not use it (yet or anymore?) in PKIX.

> I disagree with your second proposition, as I prefer an extension in the
> certificate than in the OCPS response or CRL. If you look at traffic,
OCSP
> and CRLs are downloaded from a few points in the network while
certificate
> eventually follow the signature. CRLs and OCSP traffic can become really
> large if you talk about CAs of more than 10000000 users.

This is not an argument since CRLs or OCSP responses are needed anyway.

> If you take into account the fact that you might need to archive CRLs for
20
> years, you will prefer to have them small, right?

Compared to the size of the CRL, the addition will not be noticeable.

> So this extension could be
> OK for OCSP but please do not add too much to CRLs which might need to be
> reissued every 6 hours and archived for 20 years!
> Additionnally, as a CA we would propose OCSP but still issue CRLs. Thus
> again duplication of the info!

> One more argument: the private key usage period extension is really a
> property of the key/certificate, not of the revocation. You want to
> implement in client application the logic for not using the key anymore
> after it expire, you won't use OCSP to check that.
> One last argument: it exist already, we just could make it a PKIX
standard.

The solution would be technically correct, but it would mandate the
presence
of the private key usage period extension.

:-(

Also it would not mimic current situations with credit cards, where a new
credit card is received one month before the expiration of the current one,
but during that month any of them can be used.

There is anyway a solution to this problem which does not require any
extension. Under a given CP, a CA may say that its CRL Issuers continue to
handle revocation one month after the end of the certificate validity
period. This does not scale worldwide, but it works as soon as the CPs to
be
accepted are known by verifiers, which is mostly the case.

An extension in the CRL would make it scalable. Now, if in practice every
CA is fixing the time after which revocation continues to be handled to
6 weeks, is that extension in a CRL really needed ?

Finally, if a CA is only using OCSP responders, the solution already
exists.

Regards,

Denis

> Hope I was readable....
>
> Best regards,
>
> Marc







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g86KIoe23763 for ietf-pkix-bks; Fri, 6 Sep 2002 13:18:50 -0700 (PDT)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g86KInk23758 for <[e-mail]>; Fri, 6 Sep 2002 13:18:49 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26509; Fri, 6 Sep 2002 13:18:46 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id QAA15269; Fri, 6 Sep 2002 16:18:43 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 06 Sep 2002 16:13:47 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'Housley, Russ'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: rfc822name Name Constraints question
References: <003801c2547e$fb7cfc80$e500a8c0@Chokhani>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

Santosh Chokhani wrote:
> X.509 requires that the name constraints be enforced on hierarchical
> names only. I do not remember the RFC-822 chapter and verse, but I
> thought items to the right of "@" are hierarchical and can be
> enforced. I thought items to the left of "@" is a single address
> string.

That's right. An rfc822Name is an RFC 822 addr-spec. To the
left of "@" is the local-part, which is a string with no
standard structure. To the right of "@" is the domain, which
has a hierarchical structure. These days, the domain is
generally a DNS domain name.

The domain has a hierarchical structure, so it makes sense for
RFC 3280 to allow you to specify only the uppermost portions
of the domain in a name constraint. The local-part has no
standard structure (although local domains could establish
their own structure). So it's good that RFC 3280 (at least, as
I read it) doesn't provide any way to specify a portion
of the local-part in a name constraint.

> In short, RFC 3280 should enforce hierarchical aspects of
> RFC 822 names.

Agreed.

-Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g861vY103009 for ietf-pkix-bks; Thu, 5 Sep 2002 18:57:34 -0700 (PDT)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g861vXc03004 for <[e-mail]>; Thu, 5 Sep 2002 18:57:33 -0700 (PDT)
Received: from rwcrwbc57 ([204.127.198.46]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020906015720.SHIT22980.rwcrmhc52.attbi.com@rwcrwbc57>; Fri, 6 Sep 2002 01:57:20 +0000
Received: from [67.118.240.18] by rwcrwbc57; Fri, 06 Sep 2002 01:57:20 +0000
From: [e-mail]
To: <[e-mail]>
Cc: "Alice Sturgeon" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Anders Rundgren" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-warranty-ext-01
Date: Fri, 06 Sep 2002 01:57:20 +0000
X-Mailer: AT&T Message Center Version 1 (Aug 12 2002)
Message-Id: <20020906015720.SHIT22980.rwcrmhc52.attbi.com@rwcrwbc57>
Sender: [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>

Alice,

Some points/suggestions:

1.)  There is a minor typo on page 5, para 2, line 1.

The ‘if’ in the line (copied below) should probably 
be 'of'.

 "CurrencyAmount is a SEQUENCE if three integers.  
Together the integers..."
 
2.) The draft says:
"The extension definition supports two alternatives: 
aggregated and per-transaction." 

Often, it is desirable to limit both the per transaction 
liability as well as the aggregated liability.  e.g. 
$100.00 max per transaction with a $500.00 max for the 
life of the certificate.  I would recommend that this be 
accommodated.

3.) I recall hearing some noise in the past about a 
Certco patent on issuing ANY kind of warranty where a RP 
uses a certificate to determine the warranty.  ...or 
something along those lines.  Do you know if this ID is 
(or is not) hampered by this patent? 

Others on the list have questioned whether this ID is 
really a necessary thing.  I happen to think that such 
an extension can be put to good use and may facilitate 
automated validation of an electronic transaction in 
some cases.  It certainly does no harm.   That said, 
there will be situations where the requirements are too 
complex to be handled by such an extension to any degree 
of usefulness. (like Identrus - which had a multi-
currency, cross jurisdiction, per transaction setting of 
warranty cost and value based on dynamic lookups of caps 
and collateral, etc) For such complex systems, the best 
place to handle warranty statements is the CP or some 
related document and not a certificate extension.  

Khaja

> 
> Denis and Anders, I appreciate your comments; they are 
helpful in keeping to
> the right path.
> 
> One point that I took issue with was Denis' to the 
effect that the intent of
> the I-D is not clear.  It is in fact stated in the 
first couple of
> paragraphs and I would have thought it quite clear. It 
is to provide a
> degree of confidence to RPs in e-business and 
electronic transactions. PKI
> is seriously not yet understood; there exists some 
mistrust amongst
> potential users about the mechanisms, not necessarily 
the security
> mechanisms per se because these are relatively 
transparent to a user, but
> generally in electronic exchanges involving some value.
> 
> I also have a problem with Anders' statement that you 
cannot "roll-back"
> authentication events.  True technically (actually, 
technically either true
> or false depending on mechanisms); in a legal or 
policy context isn't this
> what non-repudiation prohibits? That is, without non-
repudiation, you can
> "undo" an authentication event (the authentication can 
be repudiated, or
> 'undone').
> 
> I'm looking forward to being able to discuss issues 
about the I-D at the
> Atlanta IETF meeting.  I'm sure others will as well, 
since there have been a
> number of respondents to the I-D posting.  Just FYI, 
my unaudited (but
> trustworthy : - )) count shows 5 supporters, 3 
objectors, 2 abstainers, and
> 2 still considering and undecided.
> 
> 
> Alice
> 
> P.S. Denis, I'm happy to have been the source of 
bringing you and Anders to
> like thinking!
> 
> Alice Sturgeon
> Chair
> Canadian Advisory Committee - Information Technology 
Security
> ISO/IEC JTC1 SC 27
> and
> System Policy Architect
> SPYRUS
> Phone:     [phone]
> Cell:         613-291-0331
> 
> 
> 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: September 2, 2002 6:50 AM
> To: [e-mail]
> Cc: Anders Rundgren; [e-mail]; ietf-
[e-mail]
> Subject: Re: draft-ietf-pkix-warranty-ext-01
> 
> Alice,
> 
> I concur with many of the arguments raised by Anders. 
It is very scarce, but
> this time it happened, thanks to your draft. :-)
> 
> I believe that sufficient arguments have been raised 
against the progression
> of this draft, as it stands, which does not even 
explicitly states, for a
> naive reader, what the warranty is about.
> 
> The warranty is concerned with the liability of the 
CA, more precisely, only
> errors made by the CA personal or attributed to the CA 
during the management
> of the certificate, e.g. at the time of registration 
of the subject, when
> issuing the certificate, when handling revocation 
requests or when making
> available revocation status information.
> 
> Regards,
> 
> Denis
> 
> > Alice,
> >
> > >Lynn observed that the world of financial risk 
management is moving past
> > >per-transaction model.  The proposed extension 
offers an aggregate model.
> > >Also Lynn wrote: "and any migration to an offline 
paradigm with
> > >> both support for per transaction as well as 
aggregation risk/limits
> > >> obsoletes the requirement for the certificate."
> > >That's true; that's why the extension is useful.  
If total risk, i.e.,
> > >aggregated transactions, is the primary worry of 
the insurance industry
> then
> > >the aggregate model would be appropriate.
> >
> > This sounds pretty dangerous as it gives no value to 
an RP which may be
> just
> > one of several thousands of RPs which just received 
a purchase order
> > from a company that is on the edge of filing for 
bankruptcy.
> >
> > If it is of no value to RPs, the only purpose left 
for the
> warranty-extension
> > is for a CA to insert its liability limit in a 
machine-readable
> > format.  Is this really interesting as any liability 
above zero is likely
> > to be accompanied by a non-machine-interpretable 
agreement?
> >
> > Is the intent, that the moment a transaction is 
received that exceeds
> > the liability limit, an alert is to be sent to the 
legal department?
> > Depending on the liability agreement this may be too 
late
> > as lower-amount transactions may be equally 
uncovered.
> >
> > Actually it would IMO better be a part of the CA-
certificate to
> > declare what it stands for in terms of liability.
> >
> > Regarding warranted purchase orders, I have serious 
problems
> > understanding what a CA-issued warranty could 
possibly cover except
> > for a liability for having certified the wrong 
entity which is now making
> > fake orders.  But IMHO such a warranty is equally 
applicable to
> > authentications, as incorrect such are even worse as 
you cannot
> > "rollback" authentication events.
> >
> > For pure financial transactions, there are already 
solutions in place
> > since ages ago, like bank-warranties, remburses and 
pre-paid orders.
> >
> > cheers,
> > Anders
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85L7LI18381 for ietf-pkix-bks; Thu, 5 Sep 2002 14:07:21 -0700 (PDT)
Received: from mx4.magma.ca (mx4.magma.ca [206.191.0.253]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85L7K218376 for <[e-mail]>; Thu, 5 Sep 2002 14:07:20 -0700 (PDT)
Received: from mail1.magma.ca (mail1.magma.ca [206.191.0.252]) by mx4.magma.ca (Magma's Mail Server) with ESMTP id g85L6sgX004805; Thu, 5 Sep 2002 17:07:04 -0400
Received: from asturgeonpc (jiofis-pc5.spyrus.com [207.212.34.151]) by mail1.magma.ca (Magma's Mail Server) with SMTP id g85L6qSF016526; Thu, 5 Sep 2002 17:06:53 -0400 (EDT)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-warranty-ext-01
Date: Thu, 5 Sep 2002 17:12:38 -0400
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]>
Sender: [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>

Denis and Anders, I appreciate your comments; they are helpful in keeping to
the right path.

One point that I took issue with was Denis' to the effect that the intent of
the I-D is not clear.  It is in fact stated in the first couple of
paragraphs and I would have thought it quite clear. It is to provide a
degree of confidence to RPs in e-business and electronic transactions. PKI
is seriously not yet understood; there exists some mistrust amongst
potential users about the mechanisms, not necessarily the security
mechanisms per se because these are relatively transparent to a user, but
generally in electronic exchanges involving some value.

I also have a problem with Anders' statement that you cannot "roll-back"
authentication events.  True technically (actually, technically either true
or false depending on mechanisms); in a legal or policy context isn't this
what non-repudiation prohibits? That is, without non-repudiation, you can
"undo" an authentication event (the authentication can be repudiated, or
'undone').

I'm looking forward to being able to discuss issues about the I-D at the
Atlanta IETF meeting.  I'm sure others will as well, since there have been a
number of respondents to the I-D posting.  Just FYI, my unaudited (but
trustworthy : - )) count shows 5 supporters, 3 objectors, 2 abstainers, and
2 still considering and undecided.


Alice

P.S. Denis, I'm happy to have been the source of bringing you and Anders to
like thinking!

Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331




-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: September 2, 2002 6:50 AM
To: [e-mail]
Cc: Anders Rundgren; [e-mail]; [e-mail]
Subject: Re: draft-ietf-pkix-warranty-ext-01

Alice,

I concur with many of the arguments raised by Anders. It is very scarce, but
this time it happened, thanks to your draft. :-)

I believe that sufficient arguments have been raised against the progression
of this draft, as it stands, which does not even explicitly states, for a
naive reader, what the warranty is about.

The warranty is concerned with the liability of the CA, more precisely, only
errors made by the CA personal or attributed to the CA during the management
of the certificate, e.g. at the time of registration of the subject, when
issuing the certificate, when handling revocation requests or when making
available revocation status information.

Regards,

Denis

> Alice,
>
> >Lynn observed that the world of financial risk management is moving past
> >per-transaction model.  The proposed extension offers an aggregate model.
> >Also Lynn wrote: "and any migration to an offline paradigm with
> >> both support for per transaction as well as aggregation risk/limits
> >> obsoletes the requirement for the certificate."
> >That's true; that's why the extension is useful.  If total risk, i.e.,
> >aggregated transactions, is the primary worry of the insurance industry
then
> >the aggregate model would be appropriate.
>
> This sounds pretty dangerous as it gives no value to an RP which may be
just
> one of several thousands of RPs which just received a purchase order
> from a company that is on the edge of filing for bankruptcy.
>
> If it is of no value to RPs, the only purpose left for the
warranty-extension
> is for a CA to insert its liability limit in a machine-readable
> format.  Is this really interesting as any liability above zero is likely
> to be accompanied by a non-machine-interpretable agreement?
>
> Is the intent, that the moment a transaction is received that exceeds
> the liability limit, an alert is to be sent to the legal department?
> Depending on the liability agreement this may be too late
> as lower-amount transactions may be equally uncovered.
>
> Actually it would IMO better be a part of the CA-certificate to
> declare what it stands for in terms of liability.
>
> Regarding warranted purchase orders, I have serious problems
> understanding what a CA-issued warranty could possibly cover except
> for a liability for having certified the wrong entity which is now making
> fake orders.  But IMHO such a warranty is equally applicable to
> authentications, as incorrect such are even worse as you cannot
> "rollback" authentication events.
>
> For pure financial transactions, there are already solutions in place
> since ages ago, like bank-warranties, remburses and pre-paid orders.
>
> cheers,
> Anders



Received: by above.proper.com (8.11.6/8.11.3) id g85JE7m11040 for ietf-pkix-bks; Thu, 5 Sep 2002 12:14:07 -0700 (PDT)
Received: from mailout.zetnet.co.uk ([e-mail] [194.247.47.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85JE5211035 for <[e-mail]>; Thu, 5 Sep 2002 12:14:05 -0700 (PDT)
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by mailout.zetnet.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 17n24i-0007Pq-00 for <[e-mail]>; Thu, 05 Sep 2002 20:13:56 +0100
Received: from zetnet.co.uk (bts-0490.dialup.zetnet.co.uk [194.247.49.234]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g85JDiE31483 for <[e-mail]>; Thu, 5 Sep 2002 20:13:44 +0100
Message-ID: <[e-mail]>
Date: Thu, 05 Sep 2002 20:09:19 +0000
From: David Hopwood <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Timestamping + Cert revocation + revocation question
References: <001801c25338$76a03500$2308a8c0@MJDeskproEN> <[e-mail]> <008e01c2542a$cabd5300$2308a8c0@MJDeskproEN> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

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

Denis Pinkas wrote:
> Marc,
> > I effectivelly think that for qualified cert and signature with a legal
> > value, CRL should be maintain during the same period than the validity
> > period of signatures.
> 
> This sentence may be quite confusing. CRLs shall be kept by a verifier
> during the same period than the validity period of the signature. However,
> the CA is not concerned with any archiving of CRLs during such a time frame.
> 
> > Thus archiving CRL for 20-30 years it not really enough, we should also
> > maintain them during this period: we should be able to 'revoke' certs
> > after expiration.
> 
> At most, during a reasonable cautionary period, e.g. one month.

How long revocation needs to be possible for depends on the meaning of the
certification. For example, in the case of code signing, a certificate carries
the implication that (someone says that) the principal should be trusted to
sign only secure code - that is, code that cannot be exploited, as well as not
being itself malicious. The fact that a principal has been signing flawed code
(intentionally or not) can discovered at *any* time. The certificate should
therefore be able to be revoked at *any* point in its lifetime, independent of
the use of timestamping.

Some people might argue that the revocation mechanism was never intended
to be able to handle anything other than the compromise of private keys.
Regardless, revocation is assumed in many protocols to be a way of
"taking back" a certification for any reason at all.

- -- 
David Hopwood <[e-mail]>

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


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPXe5uTkCAxeYt5gVAQEWGgf/VteAjKGLOFc0o9TlR+NGjU7FC6JPuUKs
Co3lm3OtzsHGdQIdNFtDAGZE0VfmpVvjXgKTxbLoDBYOtn80nMfLR7qnNL6jHRyb
YiCJYE3sCQViP4K+rgAhDMnwoV1yA7dc7RrkQ8i5shlD5721rWnmL+D80TY/M9X6
4dUskeyjWfB+7jv8pqeFGNXJIOSBMvStAESDjm4MgMcwdkvLAUqSdrc0pUXLqe+1
YfhJHsNlmi/shu0ezLFJ2iHQ5fJ9zUMDgjXcgviqSD5Yej5wJy/6DoX3236iSYfC
wnvst5rYOJlXo3AludfjuuCIJwungn5U4Q8a5mIB76FqRyNqL6whsw==
=T2ae
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85Fg6I00184 for ietf-pkix-bks; Thu, 5 Sep 2002 08:42:06 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85Fg5200180 for <[e-mail]>; Thu, 5 Sep 2002 08:42:05 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA15730; Thu, 5 Sep 2002 17:47:04 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002090517420338:182 ; Thu, 5 Sep 2002 17:42:03 +0200 
Message-ID: <[e-mail]>
Date: Thu, 05 Sep 2002 17:42:02 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Marc Jadoul <[e-mail]>
CC: [e-mail]
Subject: Re: Timestamping + Cert revocation + revocation question
References: <001801c25338$76a03500$2308a8c0@MJDeskproEN> <[e-mail]> <008e01c2542a$cabd5300$2308a8c0@MJDeskproEN> <[e-mail]> <003f01c254c1$71f8b060$2308a8c0@MJDeskproEN> <[e-mail]> <008801c254ee$46557330$2308a8c0@MJDeskproEN>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/09/2002 17:42:03, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/09/2002 17:42:05, Serialize complete at 05/09/2002 17:42:05
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Marc,

> Hello Denis,
> 
> I do not know if the problem of the credit card is the same as the one of
> legally valid signature and qualified certificates I was tinking about.
> 
> (...)
> 
> >  ... but they (archived CRLs)  will not be accessible to the public.
 
> We are still talking about TByte of CRL's data to archive and Gbit/s of
> bandwidth for relying party to download the last CRL. In fact, do you intent
> to add the extension as a CRL entry extension or a global CRL extension? 

A global CRL extension. Look at the definition archive cutoff in RFC 2560.

> For me the private key validity period depend of the lenght of the private 
> key of the user and thus is probably a CRL entry extension. That mean that 
> you might have an CRL entry which is 50% bigger. Instead of having 1TB you 
> would need 1.5TB of storage and same caculation can be done for needed 
> bandwidth.

We are not talking of a private key validity period, and we are not
discussing key length strengths for a period of one month.
 
> (...)
> 
> > This is not an argument since CRLs or OCSP responses are needed anyway.
> 
> See above. I would like to minimize the bandwidth/storage needed for a CA,
> thus price/certificate.
> 
> (...)
> 
> > Compared to the size of the CRL, the addition will not be noticeable.
> 
> See above: depend if you talk about a CRL Entry Extension or a CRL
> Extension.
> 
> (...)
> 
> > Also it would not mimic current situations with credit cards, where a new
> > credit card is received one month before the expiration of the current
> > one, but during that month any of them can be used.
> 
> I do not completly understand this. Couldn't you have the new private key
> valid 1 month before the old private key expire?

Yes, but during this period the signer could use any of them.

> Obviously, you are talking of maintaining the CRL for 1 additional month
> after expiration of a private key himself usable for (5 years + 1 month)
> (credit card model) 

Yes.

> while I think in term of qualified certificates with a
> private key usable during (5 years + 1 month) and maintaining revocation
> info for 20 years for instance.

Revocation information needs to be captured close to the time the signature
is issued to make sure that the signature is valid. The intent is NOT to ask
the CRL issuer to keep that information for 20 years.
 
> > There is anyway a solution to this problem which does not require any
> > extension. Under a given CP, a CA may say that its CRL Issuers continue to
> > handle revocation one month after the end of the certificate validity
> > period. This does not scale worldwide, but it works as soon as the CPs to
> > be accepted are known by verifiers, which is mostly the case.
> >
> > An extension in the CRL would make it scalable. Now, if in practice every
> > CA is fixing the time after which revocation continues to be handled to
> > 6 weeks, is that extension in a CRL really needed ?
> >
> > Finally, if a CA is only using OCSP responders, the solution already
> > exists.
> 
> May be like nice technical solutions too much.

Let us wait for the opinion of others.

Regards,

Denis
 
> Kind regards,
> 
> Marc


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85F6tR28247 for ietf-pkix-bks; Thu, 5 Sep 2002 08:06:55 -0700 (PDT)
Received: from mail.belbone.be (mail.belbone.be [195.13.1.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85F6q228241 for <[e-mail]>; Thu, 5 Sep 2002 08:06:53 -0700 (PDT)
Received: from MJDeskproEN ([192.168.8.35]) by mail.belbone.be (8.12.5/8.12.5) with SMTP id g85F6pNa012966; Thu, 5 Sep 2002 17:06:51 +0200 (MET DST)
Message-ID: <008801c254ee$46557330$2308a8c0@MJDeskproEN>
From: "Marc Jadoul" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <001801c25338$76a03500$2308a8c0@MJDeskproEN> <[e-mail]> <008e01c2542a$cabd5300$2308a8c0@MJDeskproEN> <[e-mail]> <003f01c254c1$71f8b060$2308a8c0@MJDeskproEN> <[e-mail]>
Subject: Re: Timestamping + Cert revocation + revocation question
Date: Thu, 5 Sep 2002 17:09:47 +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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [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>

Hello Denis,

I do not know if the problem of the credit card is the same as the one of
legally valid signature and qualified certificates I was tinking about.

(...)

>  ... but they (archived CRLs)  will not be accessible to the public.

We are still talking about TByte of CRL's data to archive and Gbit/s of
bandwidth for relying party to download the last CRL. In fact, do you intent
to add the extension as a CRL entry extension or a global CRL extension? For
me the private key validity period depend of the lenght of the private key
of the user and thus is probably a CRL entry extension. That mean that you
might have an CRL entry which is 50% bigger. Instead of having 1TB you would
need 1.5TB of storage and same caculation can be done for needed bandwidth.

(...)

> This is not an argument since CRLs or OCSP responses are needed anyway.

See above. I would like to minimize the bandwidth/storage needed for a CA,
thus price/certificate.

(...)

> Compared to the size of the CRL, the addition will not be noticeable.

See above: depend if you talk about a CRL Entry Extension or a CRL
Extension.

(...)

> Also it would not mimic current situations with credit cards, where a new
> credit card is received one month before the expiration of the current
one,
> but during that month any of them can be used.

I do not completly understand this. Couldn't you have the new private key
valid 1 month before the old private key expire?
Obviously, you are talking of maintaining the CRL for 1 additional month
after expiration of a private key himself usable for (5 years + 1 month)
(credit card model) while I think in term of qualified certificates with a
private key usable during (5 years + 1 month) and maintaining revocation
info for 20 years for instance.

> There is anyway a solution to this problem which does not require any
> extension. Under a given CP, a CA may say that its CRL Issuers continue to
> handle revocation one month after the end of the certificate validity
> period. This does not scale worldwide, but it works as soon as the CPs to
be
> accepted are known by verifiers, which is mostly the case.
>
> An extension in the CRL would make it scalable. Now, if in practice every
> CA is fixing the time after which revocation continues to be handled to
> 6 weeks, is that extension in a CRL really needed ?
>
> Finally, if a CA is only using OCSP responders, the solution already
exists.

May be like nice technical solutions too much.

Kind regards,

Marc



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85DJZl22525 for ietf-pkix-bks; Thu, 5 Sep 2002 06:19:35 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85DJX222519 for <[e-mail]>; Thu, 5 Sep 2002 06:19:34 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA25558; Thu, 5 Sep 2002 15:24:32 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002090515193094:133 ; Thu, 5 Sep 2002 15:19:30 +0200 
Message-ID: <[e-mail]>
Date: Thu, 05 Sep 2002 15:19:29 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Marc Jadoul <[e-mail]>
CC: [e-mail]
Subject: Re: Timestamping + Cert revocation + revocation question
References: <001801c25338$76a03500$2308a8c0@MJDeskproEN> <[e-mail]> <008e01c2542a$cabd5300$2308a8c0@MJDeskproEN> <[e-mail]> <003f01c254c1$71f8b060$2308a8c0@MJDeskproEN>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/09/2002 15:19:30, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/09/2002 15:19:33, Serialize complete at 05/09/2002 15:19:33
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Marc,

(...)

> > > I effectivelly think that for qualified cert and signature with a legal
> > > value, CRL should be maintain during the same period than the validity
> > > period of signatures.

> > This sentence may be quite confusing. CRLs shall be kept by a verifier
> > during the same period than the validity period of the signature. However,
> > the CA is not concerned with any archiving of CRLs during such a time
> frame.
 
> I am not a legal guy and yes I am probably mixing several issues. But, I
> know that ETSI TS 101 456 v1.2.1 require the CA to archive a lot of
> information. See point 7.4.11 e) saying that "Recording concerning qualified
> certificates shall be held for a period of time as appropriate for providing
> necessary legal evidence in support of electronic signature."

> I thought that this would imply that CRLs need to be archived for a very
> long time.

 ... but they will not be accessible to the public.

(...) 

> > In order to solve nicely this issue, there is a need to add extra
> > information "somewhere".

> > 1) One possibilty is to use the private key usage period extension
> >    in a public key certificate.

> > 2) Another possibility would be to use the Archive Cutoff extension
> >    defined in RFC 2560 (OCSP) in section 4.4.4. The only problem 
> >    is that we do not have the equivalent for CRLs.

> > Since the later solution would not increase the size of the certificate,
> > this would have my preference.

> > In RFC 2560, Archive Cutoff is introduced as follows:

> >    An OCSP responder MAY choose to retain revocation information beyond
> >    a certificate's expiration.

> > For CRLs, it would be introduced as follows:

> >    A CRL Issuer MAY choose to retain revocation information beyond
> >    a certificate's expiration.
 
> I removed the rest of the discussion.

> I agree with you and James Manger that the "private key usage period
> extension" is a response to my concern.

> I agree with Peter Gutmann that I do not understand why it is recommanded to
> not use it (yet or anymore?) in PKIX.

> I disagree with your second proposition, as I prefer an extension in the
> certificate than in the OCPS response or CRL. If you look at traffic, OCSP
> and CRLs are downloaded from a few points in the network while certificate
> eventually follow the signature. CRLs and OCSP traffic can become really
> large if you talk about CAs of more than 10000000 users.

This is not an argument since CRLs or OCSP responses are needed anyway. 

> If you take into account the fact that you might need to archive CRLs for 20
> years, you will prefer to have them small, right? 

Compared to the size of the CRL, the addition will not be noticeable.

> So this extension could be
> OK for OCSP but please do not add too much to CRLs which might need to be
> reissued every 6 hours and archived for 20 years!
> Additionnally, as a CA we would propose OCSP but still issue CRLs. Thus
> again duplication of the info!

> One more argument: the private key usage period extension is really a
> property of the key/certificate, not of the revocation. You want to
> implement in client application the logic for not using the key anymore
> after it expire, you won't use OCSP to check that.
> One last argument: it exist already, we just could make it a PKIX standard.

The solution would be technically correct, but it would mandate the presence
of the private key usage period extension. 

:-(

Also it would not mimic current situations with credit cards, where a new
credit card is received one month before the expiration of the current one,
but during that month any of them can be used.

There is anyway a solution to this problem which does not require any
extension. Under a given CP, a CA may say that its CRL Issuers continue to
handle revocation one month after the end of the certificate validity
period. This does not scale worldwide, but it works as soon as the CPs to be
accepted are known by verifiers, which is mostly the case.

An extension in the CRL would make it scalable. Now, if in practice every 
CA is fixing the time after which revocation continues to be handled to 
6 weeks, is that extension in a CRL really needed ? 

Finally, if a CA is only using OCSP responders, the solution already exists.

Regards,

Denis
 
> Hope I was readable....
> 
> Best regards,
> 
> Marc


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85Cjdi20070 for ietf-pkix-bks; Thu, 5 Sep 2002 05:45:39 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85Cjb220066 for <[e-mail]>; Thu, 5 Sep 2002 05:45:37 -0700 (PDT)
Received: from Santesson ([192.168.101.139]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 5 Sep 2002 14:45:16 +0200
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "pkix" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-04.txt
Date: Thu, 5 Sep 2002 14:45:16 +0200
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Importance: Normal
X-OriginalArrivalTime: 05 Sep 2002 12:45:16.0825 (UTC) FILETIME=[15FC3890:01C254DA]
Sender: [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>

Denis,

Sorry for the date mix-up. It's my fault.
The Majority of the draft was written during the Yokohama meeting but
vacations took it longer to get it out of our computers.

Regarding the community logotype I slightly disagree with your text
proposal.
This is a technical standard and this is not the place to dictate what it
takes to have the right to use a certain logotype,
which is a separate and complicated legal issue solved on a business basis.

The only thing we can say for sure is that the presence of a community
logotype is a statement by the issuer that it claims to have the right to
use this logotype according to whatever rules the owner of the logotype has
set up for its legitimate use.

I'm not sure that it's always right to say that the issuer needs to be a
"member" of that community. The thing that matters is that the issuer has
obtained the right for the particular certificate in question. But that
depends on what meaning you attach to "member" and I'm not sure if that word
has a defined legal meaning that limits the scope beyond what we want to
dictate.

/Stefan

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Thursday, September 05, 2002 12:23 PM
> To: pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-04.txt
>
>
>
> > 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 Logotypes in
> >                           X.509 certificates
> >         Author(s)       : S. Santesson, R. Housley, T. Freeman
> >         Filename        : draft-ietf-pkix-logotypes-04.txt
> >         Pages           : 19
> >         Date            : 2002-9-3
>
> On the top page the document is marked: June 2002.
> On the next pages it is marked: July 2002.
> The document has been issued in September 2002.
>
> :-(
>
> The current definition of a community logotype is as follows:
>
>    The community logotype - is the general mark for a community. It
>    identifies a service concept for entity identification and
>    certificate issuance. Many issuers may use a community logotype to
>    co-brand with a global community in order to gain global recognition
>    of its local service provision. This type of community branding is
>    very common in the credit card business where local independent card
>    issuers include a globally recognized brand (such as VISA and
>    MasterCard).
>
> I would propose to rephrase it the following way, so that it is more
> apparent that the community logotype relates to the issuer.
>
>    The community logotype - is a logotype representing the
>    community or communities to which the certificate issuer belongs to.
>    This general mark for a community may only be used when the issuer
>    has satisfied all the conditions required by that community. These
>    conditions generally include rules for entity identification and
>    revocation requests as well as technical standards to be supported
>    for certificate issuance and certificate revocation status
> availability.
>    Many issuers may use a community logotype to co-brand with a global
>    community in order to gain global recognition of its local service
>    provision. This type of community branding is very common in the
>    credit card business where local independent card issuers include
>    a globally recognized brand (such as VISA and MasterCard).
>
>
> Denis
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85AMcp09590 for ietf-pkix-bks; Thu, 5 Sep 2002 03:22:38 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85AMa209586 for <[e-mail]>; Thu, 5 Sep 2002 03:22:36 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA19798 for <[e-mail]>; Thu, 5 Sep 2002 12:27:35 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002090512223517:89 ; Thu, 5 Sep 2002 12:22:35 +0200 
Message-ID: <[e-mail]>
Date: Thu, 05 Sep 2002 12:22:33 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-04.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/09/2002 12:22:35, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/09/2002 12:22:36, Serialize complete at 05/09/2002 12:22:36
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

> 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 Logotypes in
>                           X.509 certificates
>         Author(s)       : S. Santesson, R. Housley, T. Freeman
>         Filename        : draft-ietf-pkix-logotypes-04.txt
>         Pages           : 19
>         Date            : 2002-9-3

On the top page the document is marked: June 2002.
On the next pages it is marked: July 2002.
The document has been issued in September 2002.

:-(

The current definition of a community logotype is as follows:

   The community logotype - is the general mark for a community. It
   identifies a service concept for entity identification and
   certificate issuance. Many issuers may use a community logotype to
   co-brand with a global community in order to gain global recognition
   of its local service provision. This type of community branding is
   very common in the credit card business where local independent card
   issuers include a globally recognized brand (such as VISA and
   MasterCard).

I would propose to rephrase it the following way, so that it is more
apparent that the community logotype relates to the issuer. 

   The community logotype - is a logotype representing the
   community or communities to which the certificate issuer belongs to.
   This general mark for a community may only be used when the issuer 
   has satisfied all the conditions required by that community. These 
   conditions generally include rules for entity identification and 
   revocation requests as well as technical standards to be supported 
   for certificate issuance and certificate revocation status availability. 
   Many issuers may use a community logotype to co-brand with a global 
   community in order to gain global recognition of its local service 
   provision. This type of community branding is very common in the 
   credit card business where local independent card issuers include 
   a globally recognized brand (such as VISA and MasterCard).


Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g859k0I07108 for ietf-pkix-bks; Thu, 5 Sep 2002 02:46:00 -0700 (PDT)
Received: from mail.belbone.be (mail.belbone.be [195.13.1.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g859jx207100 for <[e-mail]>; Thu, 5 Sep 2002 02:45:59 -0700 (PDT)
Received: from MJDeskproEN ([192.168.8.35]) by mail.belbone.be (8.12.5/8.12.5) with SMTP id g859jvNa027609; Thu, 5 Sep 2002 11:45:57 +0200 (MET DST)
Message-ID: <003f01c254c1$71f8b060$2308a8c0@MJDeskproEN>
From: "Marc Jadoul" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <001801c25338$76a03500$2308a8c0@MJDeskproEN> <[e-mail]> <008e01c2542a$cabd5300$2308a8c0@MJDeskproEN> <[e-mail]>
Subject: Re: Timestamping + Cert revocation + revocation question
Date: Thu, 5 Sep 2002 11:48:53 +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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [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>

Thanks to you all for your responses.
I put all my comment in this email instead of responding to Peter Gutmann,
James Manger and you in 3 emails.

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "Marc Jadoul" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, September 05, 2002 9:31 AM
Subject: Re: Timestamping + Cert revocation + revocation question


> Marc,
>
> > Thanks Denis.
>
> > It is interresting.
>
> > I effectivelly think that for qualified cert and signature with a legal
> > value, CRL should be maintain during the same period than the validity
> > period of signatures.
>
> This sentence may be quite confusing. CRLs shall be kept by a verifier
> during the same period than the validity period of the signature. However,
> the CA is not concerned with any archiving of CRLs during such a time
frame.

I am not a legal guy and yes I am probably mixing several issues. But, I
know that ETSI TS 101 456 v1.2.1 require the CA to archive a lot of
information. See point 7.4.11 e) saying that "Recording concerning qualified
certificates shall be held for a period of time as appropriate for providing
necessary legal evidence in support of electronic signature."
I thought that this would imply that CRLs need to be archived for a very
long time.

> > Thus archiving CRL for 20-30 years it not really enought, we should also
> > maintain them during this period: we should be able to 'revoke' certs
> > after expiration.
>
> At most, during a reasonable cautionary period, e.g. one month.

Humm...

> > By adding Timestamping to PKI that was originaly foreseen for realtime
> > authentication, we add additional complexity and the original PKI design
> > show their limits. The Validity Period in a certificate means originally
> > that the certificate could be accepted in realtime during this Validity
> > Period. Thus it was logical to maintain CRLs only during this period.
But
> > know that a certificate could be accepted long after his expiration,
> > revocation information should be maintain during the whole life of the
> > certificate.

... cut ...

> We have this in X.509, but not in RFC 3280. This is the private key usage
> period extension.
>
> Using it, would mean that the period of use of the private key would be,
let
> us say, one month shorter than the period of use of the public key. So the
> digital signature would then need to be time-stamped before the end of the
> private key period. In this way revocation will still be handled one month
> after.
>
> Whatever way we are looking to this problem, revocation needs to be
handled
> a few weeks after the use of the private key. Since it is impossible to
know
> exactly when the private key has been used, an upper limit is used instead
> by using the date included in a time-stamp token over the digital
signature.
>
> > Revocation Info should be maintain during the 2nd Validity Period and
not the first as today.
>
> This is one possibility, as explained in details above.
>
> In order to solve nicely this issue, there is a need to add extra
> information "somewhere".
>
> 1) One possibilty is to use the private key usage period extension
>    in a public key certificate.
>
> 2) Another possibility would be to use the Archive Cutoff extension
defined
>    in RFC 2560 (OCSP) in section 4.4.4. The only problem is that we do not
>    have the equivalent for CRLs.
>
> Since the later solution would not increase the size of the certificate,
> this would have my preference.
>
> In RFC 2560, Archive Cutoff is introduced as follows:
>
>    An OCSP responder MAY choose to retain revocation information beyond
>    a certificate's expiration.
>
> For CRLs, it would be introduced as follows:
>
>    A CRL Issuer MAY choose to retain revocation information beyond
>    a certificate's expiration.

I removed the rest of the discussion.
I agree with you and James Manger that the "private key usage period
extension" is a response to my concern.
I agree with Peter Gutmann that I do not understand why it is recommanded to
not use it (yet or anymore?) in PKIX.
I disagree with your second proposition, as I prefer an extension in the
certificate than in the OCPS response or CRL. If you look at traffic, OCSP
and CRLs are downloaded from a few points in the network while certificate
eventually follow the signature. CRLs and OCSP traffic can become really
large if you talk about CAs of more than 10000000 users.
If you take into account the fact that you might need to archive CRLs for 20
years, you will prefer to have them small, right? So this extension could be
OK for OCSP but please do not add too much to CRLs which might need to be
reissued every 6 hours and archived for 20 years!
Additionnally, as a CA we would propose OCSP but still issue CRLs. Thus
again duplication of the info!
One more argument: the private key usage period extension is really a
property of the key/certificate, not of the revocation. You want to
implement in client application the logic for not using the key anymore
after it expire, you won't use OCSP to check that.
One last argument: it exist already, we just could make it a PKIX standard.

Hope I was readable....

Best regards,

Marc





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g859SMh05787 for ietf-pkix-bks; Thu, 5 Sep 2002 02:28:22 -0700 (PDT)
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g859SK205783 for <[e-mail]>; Thu, 5 Sep 2002 02:28:20 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id TAA07236 for <[e-mail]>; Thu, 5 Sep 2002 19:28:14 +1000 (EST)
Received: from webi.vtcif.telstra.com.au(202.12.142.19) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0zUba9; Thu Sep  5 19:27:47 2002
Received: (from uucp@localhost) by webi.vtcif.telstra.com.au (8.8.2/8.6.9) id TAA19620 for <[e-mail]>; Thu, 5 Sep 2002 19:25:55 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdgmaWpM; Thu Sep  5 19:25:27 2002
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 TAA26361 for <[e-mail]>; Thu, 5 Sep 2002 19:27:16 +1000 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2655.55) id <SHRP351C>; Thu, 5 Sep 2002 19:27:21 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: Logos: 04: ~editorial comments
Date: Thu, 5 Sep 2002 19:27:18 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: [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>

1.
The URI fields (imageURI, audioURI and refStructURI) are all a SEQUENCE OF
IA5String.  There is no mention about why multiple URIs can be included or
how they should be handled.  I am guessing that they are supposed to be
alternative URIs for exactly the same item.  Consequently, a client can use
any URI from the sequence.  If a URI fails, the client should try another.
If so, a sentence to that affect would help.

2.
Renaming the imageFormat and audioFormat fields to imageSubtype and
audioSubtype should make it clearer (in code, not just an ASN.1 comment)
that the fields hold MIME subtypes.

3.
Community, issuer, subject & loyalty types tell you what a logo is related
to.  Whether a logo can be used as a background image is a different style
of information.  Instead of defining id-logo-background, how about including
a flag in LogotypeImageInfo.
	LogotypeImageInfo ::= SEQUENCE {
		...
		background	BOOLEAN DEFAULT FALSE }

	If background is true it indicates that the image is appropriate
	for use as a background image for other certificate details, in
which case
	it MUST allow black text placed over the image to be clearly
readable.

4.
That logos can - to some degree - circumvent name constraints is understood
and explained in the Security considerations section.  A client can take
steps to minimise this risk by, for instance, consistently displaying logos
in a separate, clearly delineated, section of the screen -- so at least a
careful user would not be fooled.  Using a logo as a background image seems
to make this much harder -- now the client would need to, say, make the logo
wobble for a careful user to be able to distinguish what come from the logo
and what is generated by the (trusted) client.  Perhaps background images
should not be supported.


> ----------
> From:	[e-mail] [SMTP:[e-mail]]
> Sent:	Wednesday, 4 September 2002 9:57 pm
> 
> 	Title		: Internet X.509 Public Key Infrastructure Logotypes
> in X.509 certificates
> 	Author(s)	: S. Santesson, R. Housley, T. Freeman
> 	Filename	: draft-ietf-pkix-logotypes-04.txt
> 	Pages		: 19
> 	Date		: 2002-9-3
> 	
> This document specifies a certificate extension for including logotypes in
> public key certificates and attribute certificates.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-04.txt
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g857VDZ19365 for ietf-pkix-bks; Thu, 5 Sep 2002 00:31:13 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g857VB219356 for <[e-mail]>; Thu, 5 Sep 2002 00:31:11 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA13656; Thu, 5 Sep 2002 09:36:08 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002090509310740:28 ; Thu, 5 Sep 2002 09:31:07 +0200 
Message-ID: <[e-mail]>
Date: Thu, 05 Sep 2002 09:31:06 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Marc Jadoul <[e-mail]>
CC: [e-mail]
Subject: Re: Timestamping + Cert revocation + revocation question
References: <001801c25338$76a03500$2308a8c0@MJDeskproEN> <[e-mail]> <008e01c2542a$cabd5300$2308a8c0@MJDeskproEN>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/09/2002 09:31:07, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/09/2002 09:31:09, Serialize complete at 05/09/2002 09:31:09
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Marc,

> Thanks Denis.

> It is interresting.

> I effectivelly think that for qualified cert and signature with a legal
> value, CRL should be maintain during the same period than the validity
> period of signatures. 

This sentence may be quite confusing. CRLs shall be kept by a verifier
during the same period than the validity period of the signature. However,
the CA is not concerned with any archiving of CRLs during such a time frame.

> Thus archiving CRL for 20-30 years it not really enought, we should also 
> maintain them during this period: we should be able to 'revoke' certs 
> after expiration.

At most, during a reasonable cautionary period, e.g. one month.

> By adding Timestamping to PKI that was originaly foreseen for realtime
> authentication, we add additional complexity and the original PKI design
> show their limits. The Validity Period in a certificate means originally
> that the certificate could be accepted in realtime during this Validity
> Period. Thus it was logical to maintain CRLs only during this period. But
> know that a certificate could be accepted long after his expiration,
> revocation information should be maintain during the whole life of the
> certificate. 

No. See above.

> And the Validity Period of the certificate only concern the
> time where the action is done, not anymore the time where the action is
> verified.

No.

> May be we should have 2 Validity Period in the certificate: one for when the
> cert can be used to sign and the other when the cert can be used for
> verifying. 

We have this in X.509, but not in RFC 3280. This is the private key usage
period extension.

Using it, would mean that the period of use of the private key would be, let
us say, one month shorter than the period of use of the public key. So the
digital signature would then need to be time-stamped before the end of the
private key period. In this way revocation will still be handled one month
after.

Whatever way we are looking to this problem, revocation needs to be handled
a few weeks after the use of the private key. Since it is impossible to know
exactly when the private key has been used, an upper limit is used instead
by using the date included in a time-stamp token over the digital signature.

> Revocation Info should be maintain during the 2nd Validity Period and not the first as today.

This is one possibility, as explained in details above.

In order to solve nicely this issue, there is a need to add extra
information "somewhere".

1) One possibilty is to use the private key usage period extension 
   in a public key certificate.

2) Another possibility would be to use the Archive Cutoff extension defined 
   in RFC 2560 (OCSP) in section 4.4.4. The only problem is that we do not 
   have the equivalent for CRLs.

Since the later solution would not increase the size of the certificate, 
this would have my preference.

In RFC 2560, Archive Cutoff is introduced as follows:
 
   An OCSP responder MAY choose to retain revocation information beyond
   a certificate's expiration. 

For CRLs, it would be introduced as follows:

   A CRL Issuer MAY choose to retain revocation information beyond
   a certificate's expiration. 

Regards,

Denis


> Best Regards,
> Marc
> 
> ----- Original Message -----
> From: "Denis Pinkas" <[e-mail]>
> To: "Marc Jadoul" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, September 04, 2002 2:46 PM
> Subject: Re: Timestamping + Cert revocation + revocation question
> 
> >
> > Marc,
> >
> > [Next time, please use text editing, instead of HTML editing]
> >
> > > Hi, I probably misunderstood something and I have a small question about
> > > how to 'invalidate' a certificate that has already expired.
> >
> > Quite a strange formulation.
> >
> > > Here is a simple scenario:
> >
> > > User A get controle on a certificate certifying User B. It
> > > create a signature in the name of user B. It then timestamp this
> > > signature.Now User B do not know this. The certificate expire and it is
> > > not possible to revoke it anymore (right?).
> >
> > RFC 3280 states:
> >
> >    An entry MUST NOT be removed from the CRL until it appears on one
> >    regularly scheduled CRL issued beyond the revoked certificate's
> >    validity period.
> >
> > This is a minimum condition.
> >
> > RFC 3125 states:
> >
> > B.8.3  Timing Constraints - Caution Period
> >
> >    Before an electronic signature may really be valid, the verifier has
> >    to be sure that the holder of the private key was really the only one
> >    in possession of key at the time of signing.  However, there is an
> >    inevitable delay between a compromise or loss of key being noted, and
> >    a report of revocation being distributed.  To allow greater
> >    confidence in the validity of a signature, a "cautionary period" may
> >    be identified before a signature may be said to be valid with high
> >    confidence.  A verifier may revalidate a signature after this
> >    cautionary signature, or wait for this period before validating a
> >    signature. The validation policy may specify such a cautionary period.
> >
> > This would mean that the CA should continue, at least, to make available
> > the revocation status information until the end of the cautionnary period.
> > However, there are two problems:
> >
> >   1) the CA is ignorant about the duration of the various cautionary
> >      periods from the various signature/validation policies.
> >
> >   2) unless using the CPS, the CA has no way to indicate how long after
> >      the end of the certificate validity period, it will maintain the
> >      revocation status information ... and the CPS is not directly machine
> >      processable.
> >
> > > The time-stamped signature is
> > > thus valid and I do not know any mean to communicate that the
> certificate
> > > was wrong from the begining. Any relying party will continue to accept
> the
> > > time-stamped signature, even if User B and the CA now know the there was
> a
> > > problem with the certificate at the time of the signature.
> >
> > Whether or not the certificate has expired, a user who does not know that
> > his private key has been compromised may be issuing "valid" signatures
> > without knowing it.
> >
> > In a CRL, it is possible to include an invalidity date that provides the
> > date on which it is known or suspected that the private key was
> compromised.
> > This date may be earlier than the revocation date in the CRL entry.
> >
> > However, any CRL fetched soon after the cautionary period is sufficient to
> > prove that the signature was valid. So a fresher CRL would not
> > help to declare the signature invalid if it is issued after the end of the
> > cautionary period. The only advantage would be that the CA would have an
> > information about a user declaration of an invalidity date, maybe sooner
> > than the time included in the time-stamp token.
> >
> > > Does it exist
> > > some way to communicate that a certificate was invalid from a specific
> > > date, even if it is known only after expiration of the certificate? How
> to
> > > invalidate a timestamped signature?
> >
> > You seem to be looking for a user declaration of an invalidity date and
> > since the CA will not care about an expired certificate, you wonder where
> > and how this declaration could be done.
> >
> > There are two possible answers to your question:
> >
> > 1) Extend the time period during which the revocation information is
> >    both handled and maintained and indicate the end of that period using
> >    a new (non-critical) CRL extension. That time should be superior to the
> >    cautionary period from the signature policy or the validation policy.
> >    This would cover the cautionary period.
> >
> > 2) Beyond the end of the cautionary period, since anyway this declaration
> >    will not be "visible" in the CRL used to validate the signature
> >    (and picked during the cautionary period), it does not matter where
> that
> >    declaration will be made. Today someone having his car robbed will make
> >    a declaration of robbery to the police. The same happens with door
> keys.
> >    Maybe, in the future, some people will make a declaration of loss for
> >    a private key to the police.
> >
> > Regards,
> >
> > Denis
> >
> > > In the real world you would destroy it but here, it can perfectly be
> duplicated.
> >
> > > Marc Jadoul
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8535VD27173 for ietf-pkix-bks; Wed, 4 Sep 2002 20:05:31 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8535T227169 for <[e-mail]>; Wed, 4 Sep 2002 20:05:29 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8535RaD031000; Thu, 5 Sep 2002 15:05:27 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA152810; Thu, 5 Sep 2002 15:05:26 +1200 (NZST) (sender [e-mail])
Date: Thu, 5 Sep 2002 15:05:26 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Timestamping + Cert revocation + revocation question
Sender: [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>

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

>This is already supported -- see X.509 (2000) section 8.2.2.5 Private key
>usage period extension (or section 4.2.1.4 of RFC 3280].

Isn't that deprecated though (or at least it was in 2459)?  I've never
understood why, it seemed like a marvellously useful extension to me.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g851qSm25106 for ietf-pkix-bks; Wed, 4 Sep 2002 18:52:28 -0700 (PDT)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g851qR225102 for <[e-mail]>; Wed, 4 Sep 2002 18:52:27 -0700 (PDT)
Received: from Chokhani ([12.91.134.8]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020905015215.SULI11091.mtiwmhc22.worldnet.att.net@Chokhani>; Thu, 5 Sep 2002 01:52:15 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: rfc822name Name Constraints question
Date: Wed, 4 Sep 2002 21:53:07 -0400
Message-ID: <003801c2547e$fb7cfc80$e500a8c0@Chokhani>
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, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [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>

Steve and Russ:

X.509 requires that the name constraints be enforced on hierarchical
names only. I do not remember the RFC-822 chapter and verse, but I
thought items to the right of "@" are hierarchical and can be enforced.
I thought items to the left of "@" is a single address string.

In short, RFC 3280 should enforce hierarchical aspects of RFC 822 names.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Steve Hanna
Sent: Wednesday, September 04, 2002 3:40 PM
To: Housley, Russ
Cc: [e-mail]; [e-mail]
Subject: Re: rfc822name Name Constraints question



"Housley, Russ" wrote:
> The email address name constraint contains the right-hand part. So, 
> any email address that exactly matches the right-hand part in the name

> constraint is valid.
> 
> >RFC3280 describes how name constraints for "Internet mail addresses" 
> >may be specified, but is unclear on a few points:
> >
> >1. If the NameConstraint is "[e-mail]", does that include
> >    "[e-mail]"?
> 
> Yes.  The email address "[e-mail]" does satisfy the 
> "[e-mail]" constraint.

I was surprised to see this answer. Here's the relevant text from RFC
3280 (section 4.2.1.11):

   A name constraint for Internet mail addresses MAY specify a
   particular mailbox, all addresses at a particular host, or all
   mailboxes in a domain.  To indicate a particular mailbox, the
   constraint is the complete mail address.  For example, "[e-mail]"
   indicates the root mailbox on the host "xyz.com".  To indicate all
   Internet mail addresses on a particular host, the constraint is
   specified as the host name.  For example, the constraint "xyz.com" is
   satisfied by any mail address at the host "xyz.com".  To specify any
   address within a domain, the constraint is specified with a leading
   period (as with URIs).  For example, ".xyz.com" indicates all the
   Internet mail addresses in the domain "xyz.com", but not Internet
   mail addresses on the host "xyz.com".

I see no indication here that a constraint of "[e-mail]" would be
satisfied by the address "[e-mail]". It seems that the RFC
describes three cases:

1) If the constraint is a complete mail address, then it is
   only satisfied by that mail address.

2) If the constraint is a host name, then it is satisfied by any
   mail address at that host.

3) If the constraint is a host name with a leading period, it is
   satisfied by any address within that domain.

If my analysis is correct, a constraint of "[e-mail]" is only
satisfied by "[e-mail]" (or anything that matches using
case-insensitive matching, since email addresses are case-insensitive).
There's no way to specify a constraint that would match exactly the set
of all email addresses that end in "[e-mail]".

The text of the RFC doesn't seem to support your assertion: "The email
address name constraint contains the right-hand part. So, any email
address that exactly matches the right-hand part in the name constraint
is valid."

> >2. Can "@xyz.com" be used to match all mail addresses at
> >    "xyz.com" but not addresses at "abc.xyz.com?
> 
> Yes.  The constraint "@xyz.com" would only be satisfied by mailboxes 
> (or .forward entries) on the host xyz.com.

Looking at the RFC, the interpretation of the mail address constraint
"@xyz.com" is not defined. It is neither a complete mail address, a host
name, nor a host name with a leading period. However, the constraint
"xyz.com" would accomplish Anne's goal here (matching all mail addresses
at the xyz.com but not addresses at abc.xyz.com).

> >3. The paragraph says the constraint "xyz.com" is satisfied by
> >    "any mail address at the host "xyz.com", and ".xyz.com" is
> >    satisfied by an address within the domain xyz.com, but not
> >    xyz.com itself.  How then do I specify all addresses in the
> >    domain xyz.com AND xyz.com itself?
> 
> The constraint "xyz.com" permits "[e-mail]" and "[e-mail]"

Not according to the RFC as I read it. The constraint "xyz.com" only
permits "[e-mail]" and "[e-mail]", not "[e-mail]". If
you want to specify a constraint that matches all of and only all of the
mail addresses on host xyz.com and all of the mail addresses in the
domain xyz.com, then you'd need to specify two constraint, one being
"xyz.com" and the other being ".xyz.com".

Please explain to me how your interpretation of the RFC is supported by
the text. I don't want to make a federal case out of this, but I also
don't want people to be confused by an erroneous interpretation of the
RFC. And if I'm wrong (or the RFC is wrong), I'd like to know about it.

Thanks,

Steve Hanna

P.S. Anne did not ask me about her question before sending it, in case
you were wondering. I was on vacation last week.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85055R19397 for ietf-pkix-bks; Wed, 4 Sep 2002 17:05:05 -0700 (PDT)
Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85053219393 for <[e-mail]>; Wed, 4 Sep 2002 17:05:04 -0700 (PDT)
Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA29054 for <[e-mail]>; Thu, 5 Sep 2002 10:05:01 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpd0.5Qzb; Thu Sep  5 10:04:32 2002
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA19180 for <[e-mail]>; Thu, 5 Sep 2002 10:04:32 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdUjPyq_; Thu Sep  5 10:03:49 2002
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 KAA19349 for <[e-mail]>; Thu, 5 Sep 2002 10:03:49 +1000 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2655.55) id <SHRPM1K4>; Thu, 5 Sep 2002 10:03:53 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: RE: Timestamping + Cert revocation + revocation question
Date: Thu, 5 Sep 2002 10:03:47 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: [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>

	> May be we should have 2 Validity Period in the certificate: one
for when the
	cert can be used to sign and the other when the cert can be used for
	verifying. Revocation Info should be maintain during the 2nd
Validity Period
	and not the first as today.


This is already supported -- see X.509 (2000) section 8.2.2.5 Private key
usage period extension (or section 4.2.1.4 of RFC 3280].

The private key usage period extension (privateKeyUsagePeriod) indicates the
period of valid use of the private key.

The validity field "is the time interval during which the CA warrants that
it will maintain information about the status of the certificate" [X.509,
section 7].

Revocation info is maintained today for what you call the "2nd Validity
Period", it is just that the first is rarely specified.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84LXpH13251 for ietf-pkix-bks; Wed, 4 Sep 2002 14:33:51 -0700 (PDT)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84LXn213247 for <[e-mail]>; Wed, 4 Sep 2002 14:33:49 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25223 for <[e-mail]>; Wed, 4 Sep 2002 14:33:46 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id RAA29571; Wed, 4 Sep 2002 17:33:44 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Sep 2002 17:28:59 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Standard for Name Constraints for X500Names
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

Anne Anderson wrote:
> In RFC3280, I do not find an algorithm or reference for how
> X500Name NameConstraints are compared.  I know that the empty
> string is the root of the X500 name space, but..
> 
> If A is constrained by B,
> - must A include all RDNs in B as its most general RDNs?
> - is there any sub-matching within a given RDN?  e.g.
>    CN="* Anderson" matching "CN="Anne Anderson", or some other
>    syntax for such partial matches?
> 
> Is there a standard for such comparisons?  An X500 ordering-rule
> or something?

X.509 (2000) says in section 8.4.2.2:

   If present, the permittedSubtrees and excludedSubtrees
   components each specify one or more naming subtrees, each
   defined by the name of the root of the subtree and, optionally,
   within that subtree, an area that is bounded by upper and/or
   lower levels. If permittedSubtrees is present, of all the
   certificates issued by the subject CA and subsequent CAs in the
   certification path, only those certificates with subject names
   within these subtrees are acceptable. If excludedSubtrees is
   present, any certificate issued by the subject CA or subsequent
   CAs in the certification path that has a subject name within
   these subtrees is unacceptable.

So, as you say, "A include all RDNs in B as its most general RDNs".

How are RDNs matched? X.520 has lots of information about that,
but RFC 3280 says you can do something much simpler:

   At a minimum, implementations MUST perform the DN comparison
   rules specified in Section 4.1.2.4.  CAs issuing certificates
   with a restriction of the form directoryName SHOULD NOT rely
   on implementation of the full ISO DN name comparison algorithm.

Neither X.520 nor section 4.1.2.4 of RFC 3280 provide for
wild-card matching within an attribute value, at least not
for any of the attributes normally included in a DN in a
certificate (those mentioned in section 4.1.2.4).

The name matching algorithm defined in section 4.1.2.4 of
RFC 3280 doesn't require any intelligent handling of Unicode
characters. X.520 doesn't do much better. There is an effort
underway to define better handling for such characters. But
at this point, section 4.1.2.4 is the rule for RFC 3280.

I hope that helps!

Steve Hanna


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84JiL507033 for ietf-pkix-bks; Wed, 4 Sep 2002 12:44:21 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84JiJ207026 for <[e-mail]>; Wed, 4 Sep 2002 12:44:19 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20352; Wed, 4 Sep 2002 13:44:21 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id PAA14489; Wed, 4 Sep 2002 15:44:20 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Sep 2002 15:39:34 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: rfc822name Name Constraints question
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

"Housley, Russ" wrote:
> The email address name constraint contains the right-hand part.
> So, any email address that exactly matches the right-hand part
> in the name constraint is valid.
> 
> >RFC3280 describes how name constraints for "Internet mail
> >addresses" may be specified, but is unclear on a few points:
> >
> >1. If the NameConstraint is "[e-mail]", does that include
> >    "[e-mail]"?
> 
> Yes.  The email address "[e-mail]" does satisfy the "[e-mail]"
> constraint.

I was surprised to see this answer. Here's the relevant text
from RFC 3280 (section 4.2.1.11):

   A name constraint for Internet mail addresses MAY specify a
   particular mailbox, all addresses at a particular host, or all
   mailboxes in a domain.  To indicate a particular mailbox, the
   constraint is the complete mail address.  For example, "[e-mail]"
   indicates the root mailbox on the host "xyz.com".  To indicate all
   Internet mail addresses on a particular host, the constraint is
   specified as the host name.  For example, the constraint "xyz.com" is
   satisfied by any mail address at the host "xyz.com".  To specify any
   address within a domain, the constraint is specified with a leading
   period (as with URIs).  For example, ".xyz.com" indicates all the
   Internet mail addresses in the domain "xyz.com", but not Internet
   mail addresses on the host "xyz.com".

I see no indication here that a constraint of "[e-mail]"
would be satisfied by the address "[e-mail]". It seems
that the RFC describes three cases:

1) If the constraint is a complete mail address, then it is
   only satisfied by that mail address.

2) If the constraint is a host name, then it is satisfied by any
   mail address at that host.

3) If the constraint is a host name with a leading period, it is
   satisfied by any address within that domain.

If my analysis is correct, a constraint of "[e-mail]" is only
satisfied by "[e-mail]" (or anything that matches using
case-insensitive matching, since email addresses are case-insensitive).
There's no way to specify a constraint that would match exactly the set
of all email addresses that end in "[e-mail]".

The text of the RFC doesn't seem to support your assertion:
"The email address name constraint contains the right-hand part.
So, any email address that exactly matches the right-hand part in
the name constraint is valid."

> >2. Can "@xyz.com" be used to match all mail addresses at
> >    "xyz.com" but not addresses at "abc.xyz.com?
> 
> Yes.  The constraint "@xyz.com" would only be satisfied by mailboxes (or
> .forward entries) on the host xyz.com.

Looking at the RFC, the interpretation of the mail address constraint
"@xyz.com" is not defined. It is neither a complete mail address, a
host name, nor a host name with a leading period. However, the constraint
"xyz.com" would accomplish Anne's goal here (matching all mail addresses
at the xyz.com but not addresses at abc.xyz.com).

> >3. The paragraph says the constraint "xyz.com" is satisfied by
> >    "any mail address at the host "xyz.com", and ".xyz.com" is
> >    satisfied by an address within the domain xyz.com, but not
> >    xyz.com itself.  How then do I specify all addresses in the
> >    domain xyz.com AND xyz.com itself?
> 
> The constraint "xyz.com" permits "[e-mail]" and "[e-mail]"

Not according to the RFC as I read it. The constraint "xyz.com"
only permits "[e-mail]" and "[e-mail]", not "[e-mail]".
If you want to specify a constraint that matches all of and only all of
the mail addresses on host xyz.com and all of the mail addresses in
the domain xyz.com, then you'd need to specify two constraint, one
being "xyz.com" and the other being ".xyz.com".

Please explain to me how your interpretation of the RFC is supported
by the text. I don't want to make a federal case out of this, but I
also don't want people to be confused by an erroneous interpretation
of the RFC. And if I'm wrong (or the RFC is wrong), I'd like to know
about it.

Thanks,

Steve Hanna

P.S. Anne did not ask me about her question before sending it, in case
you were wondering. I was on vacation last week.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84I2sE02792 for ietf-pkix-bks; Wed, 4 Sep 2002 11:02:54 -0700 (PDT)
Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84I2p202788; Wed, 4 Sep 2002 11:02:51 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05111a28b99bfb216d94@[165.227.249.18]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 4 Sep 2002 11:02:59 -0700
To: carol <[e-mail]>, "[e-mail]" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: BMP and UTF8
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [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>

At 11:14 AM +0800 8/23/02, carol wrote:
>    
>Hello everybody,
>
>    I'm looking for some Chinese characters that do not fall into BMP 
>but fall into UTF8.
>    Is there anyone who know such characters?

Please see the Unicode 3.1 or 3.2 standard. There are literally tens 
of thousands.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84FlXT25024 for ietf-pkix-bks; Wed, 4 Sep 2002 08:47:33 -0700 (PDT)
Received: from mail.belbone.be (mail.belbone.be [195.13.1.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84FlU225019 for <[e-mail]>; Wed, 4 Sep 2002 08:47:31 -0700 (PDT)
Received: from MJDeskproEN ([192.168.8.35]) by mail.belbone.be (8.12.5/8.12.5) with SMTP id g84FlUNa010200; Wed, 4 Sep 2002 17:47:30 +0200 (MET DST)
Message-ID: <008e01c2542a$cabd5300$2308a8c0@MJDeskproEN>
From: "Marc Jadoul" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <001801c25338$76a03500$2308a8c0@MJDeskproEN> <[e-mail]>
Subject: Re: Timestamping + Cert revocation + revocation question
Date: Wed, 4 Sep 2002 17:50:28 +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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [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>

Thanks Denis.
It is interresting.
I effectivelly think that for qualified cert and signature with a legal
value, CRL should be maintain during the same period than the validity
period of signatures. Thus archiving CRL for 20-30 years it not really
enought, we should also maintain them during this period: we should be able
to 'revoke' certs after expiration.
By adding Timestamping to PKI that was originaly foreseen for realtime
authentication, we add additional complexity and the original PKI design
show their limits. The Validity Period in a certificate means originally
that the certificate could be accepted in realtime during this Validity
Period. Thus it was logical to maintain CRLs only during this period. But
know that a certificate could be accepted long after his expiration,
revocation information should be maintain during the whole life of the
certificate. And the Validity Period of the certificate only concern the
time where the action is done, not anymore the time where the action is
verified.
May be we should have 2 Validity Period in the certificate: one for when the
cert can be used to sign and the other when the cert can be used for
verifying. Revocation Info should be maintain during the 2nd Validity Period
and not the first as today.
Best Regards,
Marc

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "Marc Jadoul" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 04, 2002 2:46 PM
Subject: Re: Timestamping + Cert revocation + revocation question


>
> Marc,
>
> [Next time, please use text editing, instead of HTML editing]
>
> > Hi, I probably misunderstood something and I have a small question about
> > how to 'invalidate' a certificate that has already expired.
>
> Quite a strange formulation.
>
> > Here is a simple scenario:
>
> > User A get controle on a certificate certifying User B. It
> > create a signature in the name of user B. It then timestamp this
> > signature.Now User B do not know this. The certificate expire and it is
> > not possible to revoke it anymore (right?).
>
> RFC 3280 states:
>
>    An entry MUST NOT be removed from the CRL until it appears on one
>    regularly scheduled CRL issued beyond the revoked certificate's
>    validity period.
>
> This is a minimum condition.
>
> RFC 3125 states:
>
> B.8.3  Timing Constraints - Caution Period
>
>    Before an electronic signature may really be valid, the verifier has
>    to be sure that the holder of the private key was really the only one
>    in possession of key at the time of signing.  However, there is an
>    inevitable delay between a compromise or loss of key being noted, and
>    a report of revocation being distributed.  To allow greater
>    confidence in the validity of a signature, a "cautionary period" may
>    be identified before a signature may be said to be valid with high
>    confidence.  A verifier may revalidate a signature after this
>    cautionary signature, or wait for this period before validating a
>    signature. The validation policy may specify such a cautionary period.
>
> This would mean that the CA should continue, at least, to make available
> the revocation status information until the end of the cautionnary period.
> However, there are two problems:
>
>   1) the CA is ignorant about the duration of the various cautionary
>      periods from the various signature/validation policies.
>
>   2) unless using the CPS, the CA has no way to indicate how long after
>      the end of the certificate validity period, it will maintain the
>      revocation status information ... and the CPS is not directly machine
>      processable.
>
> > The time-stamped signature is
> > thus valid and I do not know any mean to communicate that the
certificate
> > was wrong from the begining. Any relying party will continue to accept
the
> > time-stamped signature, even if User B and the CA now know the there was
a
> > problem with the certificate at the time of the signature.
>
> Whether or not the certificate has expired, a user who does not know that
> his private key has been compromised may be issuing "valid" signatures
> without knowing it.
>
> In a CRL, it is possible to include an invalidity date that provides the
> date on which it is known or suspected that the private key was
compromised.
> This date may be earlier than the revocation date in the CRL entry.
>
> However, any CRL fetched soon after the cautionary period is sufficient to
> prove that the signature was valid. So a fresher CRL would not
> help to declare the signature invalid if it is issued after the end of the
> cautionary period. The only advantage would be that the CA would have an
> information about a user declaration of an invalidity date, maybe sooner
> than the time included in the time-stamp token.
>
> > Does it exist
> > some way to communicate that a certificate was invalid from a specific
> > date, even if it is known only after expiration of the certificate? How
to
> > invalidate a timestamped signature?
>
> You seem to be looking for a user declaration of an invalidity date and
> since the CA will not care about an expired certificate, you wonder where
> and how this declaration could be done.
>
> There are two possible answers to your question:
>
> 1) Extend the time period during which the revocation information is
>    both handled and maintained and indicate the end of that period using
>    a new (non-critical) CRL extension. That time should be superior to the
>    cautionary period from the signature policy or the validation policy.
>    This would cover the cautionary period.
>
> 2) Beyond the end of the cautionary period, since anyway this declaration
>    will not be "visible" in the CRL used to validate the signature
>    (and picked during the cautionary period), it does not matter where
that
>    declaration will be made. Today someone having his car robbed will make
>    a declaration of robbery to the police. The same happens with door
keys.
>    Maybe, in the future, some people will make a declaration of loss for
>    a private key to the police.
>
> Regards,
>
> Denis
>
> > In the real world you would destroy it but here, it can perfectly be
duplicated.
>
> > Marc Jadoul
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84DCMK16545 for ietf-pkix-bks; Wed, 4 Sep 2002 06:12:22 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84DCH216538 for <[e-mail]>; Wed, 4 Sep 2002 06:12:17 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA24442; Wed, 4 Sep 2002 15:17:13 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002090415121356:830 ; Wed, 4 Sep 2002 15:12:13 +0200 
Message-ID: <[e-mail]>
Date: Wed, 04 Sep 2002 15:12:12 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Steve Tuecke <[e-mail]>
CC: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
References: <[e-mail] .com> <4.3.2.7.2.20020827135204.01a7b630@localhost> <[e-mail] .com> <4.3.2.7.2.20020827102404.01a755a8@localhost> <[e-mail]> <4.3.2.7.2.20020830094400.00b2cc60@localhost>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/09/2002 15:12:13, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/09/2002 15:12:15, Serialize complete at 04/09/2002 15:12:15
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Steve,

> Denis,

Since my first name appears at the top of this very loooong e-mail, 
I feel forced to reply.

> PKIX has already influenced the content of the proxy cert profile
> substantially.  I realized after my last email that "languished" was
> perhaps a poor choice of words.  In fact, the document has progressed
> substantially since its initial submission, based in part upon discussions
> with several PKIX participants.  It would perhaps be better to describe it
> as "languishing" (present tense), as it seems that changes have reached a
> plateau, with no clear path or energy to move it forward in PKIX.  (Though
> maybe this discussion will change that.)
> 
> The document is definitely still influenceable, if people are willing to
> expend the effort to attempt to influence it in the near future.  

Fine. This clarifies the issue that I raised.

> The
> document has evolved substantially during the year and a half it has been
> out there, such that the authors are now pretty happy with it.  But
> frankly, there really is not all that much to this profile. (See
> below.)  If there is acceptance of the fundamental approach of having a
> proxy cert signed by an end-entity cert or another proxy cert, then I think
> reaching consensus on the details should not be hard or take very long
> given the progress we have already made.
> 
> But that is where I see that the problem lies.  As I mentioned in my
> previous emails, we have also had conversations with PKIX people that led
> to my belief that there may we irreconcilable differences of opinion about
> this approach.  There are those who apparently believe that the approach is
> fundamentally at odds with X.509 and PKIX world views, and should not be
> sanctioned.
> 
> Perhaps this is the straw poll that needs to be taken...

I do not have that kind of problem as long as the draft is using everywhere
"proxy certificate" and is NOT using the terminology "public key
certificate".

RFC 3280 is about a public key certificate, as mentioned in some text
extracted from RFC 3280 below:

   Users of a public key require confidence that the associated private
   key is owned by the correct remote subject (person or system) with
   which an encryption or digital signature mechanism will be used.
   This confidence is obtained through the use of public key
   certificates, which are data structures that bind public key values
   to subjects.  The binding is asserted by having a trusted CA
   digitally sign each certificate.  

As far as ASN.1 is concerned since the issuer field identifies "the entity
who has signed and issued the certificate", there is no problem as well.  

> Should PKIX sanction the advancement of a proxy cert draft based on the
> current fundamental approach?  We can argue about the details more later,
> but the fundamental approach at issue is whether it is reasonable to use
> end-entity public key certificates to sign proxy certificates. Possible
> answers are:
>    1) No.
>    2) Yes, but only as Informational Track.
>    3) Yes, as Standards Track.
> 
> In order better inform voters, it is perhaps useful for me to summarize the
> approach, and some of the discussions that have occurred.  Note that I have
> purposely omitted names in the following text.  As none of the referenced
> discussions with PKIX people happened in a public forum, I don't want to
> drag them into a public debate against their will.  But of course, I'm
> happy if they jump in and take credit for (and argue for) the suggestions
> and critiques describe below.
> 
> A proxy cert is denoted by the presence of the proxyCertInfo extension,
> which must be marked critical.  

Compliant software SHALL then reject such a certificate, if that extension
is present and they do not know how to process it. 

> A proxy cert is signed/issued by either an end-entity cert, 

Fine.
 
> or by another proxy cert.  

This may be much more complicated to handle.

> The subject of the proxy cert
> is derived from that of its issuer, by taking the issuer DN and appending a
> common name whose value should be unique amongst all proxy certs issued by
> a particular issuer.  

> The subjectAltName must be empty, and there are rules
> for what is allowed in the proxy cert's key usage and extended key usage
> relative to its issuer.
 
> The proxyCertInfo extension carries three things: a version number, so more
> info can be added to it in a subsequent revision, if desired; a
> pCPathLenConstraint to limit the proxy path length; and a proxyPolicy that
> is just a 2-tuple containing an OID of a policy language, and a policy blob
> expressed in that language.  There are two simple policies defined in the
> draft: one that states that the proxy cert is allowed to impersonate its
> issuer (that is, it inherits all rights that the issuer has), and one that
> states that the proxy cert is independent of its issuer (that is, it
> inherits no rights from its issuer).  Other policy languages can be defined
> that allow for finer grain inheritance of rights from the issuer.

My own belief is that impersonation only is VERY dangerous and thus I see
little value for that draft, unless the target(s) where the proxy
certificate can be used can be restricted. So I am NOT talking about a finer 
grain inheritance of rights from the issuer (which would be useful as well) 
but about a finer grain of usage of the rights from the issuer (which may 
simply be its identity).
 
> Changes are required to the path validation algorithm, in order to verify
> that the proxy subject is properly derived from the subject of its issuer,
> to verify the key usage and extended key usage are correctly derived from
> the issuer, and to check the pCPathLenConstraint.

Maybe this is where we have a problem. This is not a *change* in the path
validation algorithm, but this should be an *addition* to the basic path
validation algorithm to say how to process the proxy certificate(s).

> That's about it.
> 
> The biggest change to the draft came with the -02 version.  Based on
> discussions and suggestions from PKIX members, we changed the way subject
> names were handled in proxies, in order to make them work better with
> attribute certificates.  Prior to that version, we went to some length to
> avoid providing a useful proxy subject, so that a proxy really just
> inherited its name from its issuing end-entity cert.  In other words, it
> was more of a straight impersonation approach -- in essence, we were
> basically just binding temporary keys to an existing end-entity
> subject.  This changed to the approach described above, in which each proxy
> cert is given a unique subject DN, derived from that of its issuer.  This
> allows a proxy cert to be the holder of an attribute cert.

 ... but this complicates even more the design.

> The concern that has been expressed by various PKIX people is that we are
> using end-entity certs to issue proxy certs.  The argument is that we are
> using the end-entity cert like a CA cert, which violates the fundamental
> X.509 and PKIX world view.

Not really. If there is no basic constraints extension field in the proxy
certificate, then there cannot be any violation. 
 
> At some conceptual level, this is obviously true -- we are creating a key
> pair, creating a unique subject name, and then using the end-entity cert to
> sign a certificate containing the public key, name, and other information
> including the proxyCertInfo.  However:
> 
>    1) A proxy certificate is not an end-entity certificate -- a proxy
> cert's reason for existing is quite different from an end-entity cert.  The
> whole point of proxy certs is to allow for relatively short-lived entities,
> which are dynamically created and destroyed, to be given an authenticatable
> identity, optionally accompanied with some delegated rights from the
> issuer.  Issuing certificates using a traditional CA model is not practical
> or efficient for such entities.
> 
>    2) Existing code that does not implement proxy cert path validation will
> reject a proxy cert that is presented to it for 2 reasons: (1) the
> BasicConstraints.cA bit of the issuing end-entity is false, and (2) the
> proxyCertInfo extension is marked critical.  So unless existing code is
> horribly mis-implemented (even these most basic checks are not done in its
> path validation), there should be no concern about problems that proxy
> certs can cause to existing implementations.
> 
>    3) Code that properly implements proxy cert path validation cannot
> confuse an end-entity cert with a proxy cert.  The proxy cert path
> validation will reject an end-entity cert signed by a proxy cert, or a
> proxy cert that tries to spoof some subject name that is not properly
> derived from that of the issuing end-entity.  So in new code that
> implements proxy cert's, there is clear delineation between the two.
> 
> So while at some level an end-entity and proxy cert look a lot alike, they
> are really distinct things, used for distinct purposes, and cannot be
> confused with each other either by an existing implementation that does not
> implement the proxy cert profile, or by a new implementation that properly
> implements the proxy cert profile.
> 
> The only alternative approaches that were suggested were:
> 
>    A) Have existing CAs issue end-entity certificates with the
> BasicConstraints.cA bit set to true, 

No. This violates X.509.

> and name constraints set to restrict
> the subjects of any certs signed by that end-entity.  In other words,
> instead of issuing end-entity certs, issue subordinate CA certs.  An
> advantage to this approach is that it lives within the current X.509/PKIX
> model.  But I believe this approach has a few problems.  First, of the CA
> operators I have talked to, none of them would issue "end-entity" certs
> with the cA bit set to true, as they found that even more counter to the
> X.509/PKIX world view than the introduction of proxy certs.  Second, many
> existing implementations do not implement name constraints, which not only
> means new code would need to be rolled out anyway (just like it does for
> proxies), but that existing code could easily be spoofed by an end-entity
> that signs another end-entity subject.  On this last point, an advantage to
> the current proxy cert profile is that code that has not been explicitly
> coded to accept proxies will reject them due to the existing fundamental
> path validation rules.
> 
>    B) Create an CA which automatically issues new end-entity certs on
> demand for the dynamically created entities.  

No. This violates X.509.

> The primary problem with this
> approach is scalability, particularly in a large, widely distributed system
> with lots of dynamically created entities (which is exactly what we are
> building today in various Grid applications using proxy certs).  The
> advantage of the current proxy cert profile is that a proxy can be
> unilaterally created by an existing entity (the holder of an end-entity
> cert or existing proxy cert), with no need for centralization.
> 
>    C) Forget X.509, and just use raw keys for what we are trying to
> do.  But the reason we went down the proxy cert path in the first place was
> so that they could drop into existing code base (e.g. SSL/TLS libraries)
> with little modification.  

Once again, this is where the issue lies. What would be "existing code base
with little modification" ? You could *add* some code to handle proxy
certificates. 

> Technical details aside, I also found this
> argument to be curious coming from a PKIX person -- given that PKIX
> specifications as they exist today do not meet our needs, does it make more
> sense to augment the current PKIX specifications as we have done, or is it
> better to just bail on X.509 entirely?

The middle issue is to use existing code for public key certificates and 
*add* to it the handling of proxy certificates. Would this be infeasible ?

Denis

PS: Thank you for this very detailed and very clear summary, but next time,
try to make the e-mail shorter.

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84Ckix14486 for ietf-pkix-bks; Wed, 4 Sep 2002 05:46:44 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84Ckh214481 for <[e-mail]>; Wed, 4 Sep 2002 05:46:43 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA11184; Wed, 4 Sep 2002 14:51:40 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002090414464071:812 ; Wed, 4 Sep 2002 14:46:40 +0200 
Message-ID: <[e-mail]>
Date: Wed, 04 Sep 2002 14:46:39 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Marc Jadoul <[e-mail]>
CC: [e-mail]
Subject: Re: Timestamping + Cert revocation + revocation question
References: <001801c25338$76a03500$2308a8c0@MJDeskproEN>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/09/2002 14:46:40, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/09/2002 14:46:42, Serialize complete at 04/09/2002 14:46:42
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Marc,

[Next time, please use text editing, instead of HTML editing]

> Hi, I probably misunderstood something and I have a small question about
> how to 'invalidate' a certificate that has already expired.

Quite a strange formulation.

> Here is a simple scenario:

> User A get controle on a certificate certifying User B. It
> create a signature in the name of user B. It then timestamp this
> signature.Now User B do not know this. The certificate expire and it is
> not possible to revoke it anymore (right?).

RFC 3280 states:

   An entry MUST NOT be removed from the CRL until it appears on one 
   regularly scheduled CRL issued beyond the revoked certificate's 
   validity period.

This is a minimum condition. 

RFC 3125 states:

B.8.3  Timing Constraints - Caution Period

   Before an electronic signature may really be valid, the verifier has
   to be sure that the holder of the private key was really the only one
   in possession of key at the time of signing.  However, there is an
   inevitable delay between a compromise or loss of key being noted, and
   a report of revocation being distributed.  To allow greater
   confidence in the validity of a signature, a "cautionary period" may
   be identified before a signature may be said to be valid with high
   confidence.  A verifier may revalidate a signature after this
   cautionary signature, or wait for this period before validating a
   signature. The validation policy may specify such a cautionary period.

This would mean that the CA should continue, at least, to make available
the revocation status information until the end of the cautionnary period.
However, there are two problems:

  1) the CA is ignorant about the duration of the various cautionary
     periods from the various signature/validation policies.  
  
  2) unless using the CPS, the CA has no way to indicate how long after 
     the end of the certificate validity period, it will maintain the 
     revocation status information ... and the CPS is not directly machine 
     processable.

> The time-stamped signature is
> thus valid and I do not know any mean to communicate that the certificate
> was wrong from the begining. Any relying party will continue to accept the
> time-stamped signature, even if User B and the CA now know the there was a
> problem with the certificate at the time of the signature.

Whether or not the certificate has expired, a user who does not know that
his private key has been compromised may be issuing "valid" signatures
without knowing it.

In a CRL, it is possible to include an invalidity date that provides the
date on which it is known or suspected that the private key was compromised.
This date may be earlier than the revocation date in the CRL entry.
 
However, any CRL fetched soon after the cautionary period is sufficient to
prove that the signature was valid. So a fresher CRL would not
help to declare the signature invalid if it is issued after the end of the
cautionary period. The only advantage would be that the CA would have an
information about a user declaration of an invalidity date, maybe sooner
than the time included in the time-stamp token.

> Does it exist
> some way to communicate that a certificate was invalid from a specific
> date, even if it is known only after expiration of the certificate? How to
> invalidate a timestamped signature? 

You seem to be looking for a user declaration of an invalidity date and
since the CA will not care about an expired certificate, you wonder where
and how this declaration could be done.

There are two possible answers to your question:

1) Extend the time period during which the revocation information is
   both handled and maintained and indicate the end of that period using 
   a new (non-critical) CRL extension. That time should be superior to the 
   cautionary period from the signature policy or the validation policy. 
   This would cover the cautionary period.

2) Beyond the end of the cautionary period, since anyway this declaration 
   will not be "visible" in the CRL used to validate the signature 
   (and picked during the cautionary period), it does not matter where that 
   declaration will be made. Today someone having his car robbed will make 
   a declaration of robbery to the police. The same happens with door keys. 
   Maybe, in the future, some people will make a declaration of loss for 
   a private key to the police.

Regards,

Denis

> In the real world you would destroy it but here, it can perfectly be duplicated. 

> Marc Jadoul


Received: by above.proper.com (8.11.6/8.11.3) id g84CapV14254 for ietf-pkix-bks; Wed, 4 Sep 2002 05:36:51 -0700 (PDT)
Received: from mail.belbone.be (mail.belbone.be [195.13.1.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84Can214250 for <[e-mail]>; Wed, 4 Sep 2002 05:36:49 -0700 (PDT)
Received: from MJDeskproEN ([192.168.8.35]) by mail.belbone.be (8.12.5/8.12.5) with SMTP id g84CamNa000462; Wed, 4 Sep 2002 14:36:48 +0200 (MET DST)
Message-ID: <002401c25410$264f8230$2308a8c0@MJDeskproEN>
From: "Marc Jadoul" <[e-mail]>
To: "Esposito Alfredo" <[e-mail]>
Cc: <[e-mail]>
References: <001801c25338$76a03500$2308a8c0@MJDeskproEN> <[e-mail]>
Subject: Re: Timestamping + Cert revocation + revocation question
Date: Wed, 4 Sep 2002 14:39:45 +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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [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>

Hi,

Yes I agree with you, User B can apply to the court. He might win, and the
court might decide that any signature made with this key/cert after a
defined date is invalid.
But what seems wrong to me is that there is no technical way (like CRL for
expired certs) to communicate to any third party this fact and any one will
continue to accept signature made with this key/cert because the (expired)
cert can not be revoked anymore.

Marc Jadoul
----- Original Message -----
From: "Esposito Alfredo" <[e-mail]>
To: "Marc Jadoul" <[e-mail]>
Sent: Wednesday, September 04, 2002 11:22 AM
Subject: Re: Timestamping + Cert revocation + revocation question


> Hi
> that is something weird in your scenario. In order to sign a document
> user A should control the private key of user B. The certificate alone
> is not enough to sign anything. In the legal system of  the countries
> introducing digital signature, the revocation status applies after the
> publication of a CRL. Before this publication user B can not repudiate
> his signature. Of course, User B can apply to the court. Depending on
> the kind of storing the private key (smart card, floppy, hard disk...)
> and all the other factors, the court will decide about the legal
> effects of the claimed forged signature.
>
> Alfredo Esposito
> InfoCamere SCpA
> Digital Signature
> Via Morgagni 30H
> 00161 Roma
> Italy
>
>
> Marc Jadoul wrote:
>
> > Hi,
> >
> >
> >
> > I probably misunderstood something and I have a small question about
> > how to 'invalidate' a certificate that has already expired.
> >
> > Here is a simple scenario:
> >
> > User A get controle on a certificate certifying User B. It create a
> > signature in the name of user B. It then timestamp this signature.
> >
> > Now User B do not know this. The certificate expire and it is not
> > possible to revoke it anymore (right?).
> >
> > The time-stamped signature is thus valid and I do not know any mean to
> > communicate that the certificate was wrong from the begining. Any
> > relying party will continue to accept the time-stamped signature, even
> > if User B and the CA now know the there was a problem with the
> > certificate at the time of the signature.
> >
> > Does it exist some way to communicate that a certificate was invalid
> > from a specific date, even if it is known only after expiration of the
> > certificate?
> >
> >
> >
> > How to invalidate a timestamped signature? In the real world you would
> > destroy it but here, it can perfectly be duplicated.
> >
> >
> >
> > Marc Jadoul
> >
>
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84Bwsg11908 for ietf-pkix-bks; Wed, 4 Sep 2002 04:58:54 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84Bwr211904 for <[e-mail]>; Wed, 4 Sep 2002 04:58:53 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23586; Wed, 4 Sep 2002 07:57:18 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-04.txt
Date: Wed, 04 Sep 2002 07:57:18 -0400
Sender: [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>

--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 Logotypes in 
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-04.txt
	Pages		: 19
	Date		: 2002-9-3
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [e-mail]
mailing list.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-logotypes-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-logotypes-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-logotypes-04.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g843FCh21383 for ietf-pkix-bks; Tue, 3 Sep 2002 20:15:12 -0700 (PDT)
Received: from usermail.chinacomm.com.cn ([211.157.102.9]) by above.proper.com (8.11.6/8.11.3) with SMTP id g843F9221376 for <[e-mail]>; Tue, 3 Sep 2002 20:15:10 -0700 (PDT)
Message-Id: <[e-mail]>
Received: (qmail 11013 invoked from network); 4 Sep 2002 03:26:31 -0000
Received: from unknown (HELO ccit-carol) (61.48.8.181) by 0 with SMTP; 4 Sep 2002 03:26:31 -0000
Date: Fri, 23 Aug 2002 11:14:42 +0800
From: carol <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: BMP and UTF8
X-mailer: FoxMail 4.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id g843FA221378
Sender: [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>

    
Hello everybody,

   I'm looking for some Chinese characters that do not fall into BMP but fall into UTF8.
   Is there anyone who know such characters?

   Thanks a lot for any answer.

carol


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83HVcO21610 for ietf-pkix-bks; Tue, 3 Sep 2002 10:31:38 -0700 (PDT)
Received: from mailout.zetnet.co.uk ([e-mail] [194.247.47.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83HVa221605 for <[e-mail]>; Tue, 3 Sep 2002 10:31:36 -0700 (PDT)
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk ident=root) by mailout.zetnet.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 17mHWb-0004u8-00 for <[e-mail]>; Tue, 03 Sep 2002 18:31:37 +0100
Received: from zetnet.co.uk (bts-0221.dialup.zetnet.co.uk [194.247.48.221]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g83HVP811888 for <[e-mail]>; Tue, 3 Sep 2002 18:31:25 +0100
Message-ID: <[e-mail]>
Date: Tue, 03 Sep 2002 18:31:11 +0000
From: David Hopwood <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
References: <[e-mail] .com> <4.3.2.7.2.20020827135204.01a7b630@localhost> <[e-mail] .com> <4.3.2.7.2.20020827102404.01a755a8@localhost> <[e-mail]> <4.3.2.7.2.20020830094400.00b2cc60@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [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>

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

Steve Tuecke wrote:
>    2) Existing code that does not implement proxy cert path validation will
> reject a proxy cert that is presented to it for 2 reasons: (1) the
> BasicConstraints.cA bit of the issuing end-entity is false, and (2) the
> proxyCertInfo extension is marked critical.  So unless existing code is
> horribly mis-implemented (even these most basic checks are not done in its
> path validation), there should be no concern about problems that proxy
> certs can cause to existing implementations.

But remember that MSIE's certificate checking *is* horribly mis-implemented.
Of course this doesn't lead to a security problem that is not already present
in MSIE, but it could lead to significant user confusion (because a proxy cert
looks to the user exactly like an attempted exploit of the BasicConstraints
checking bug).

Would the critical proxyCertInfo extension cause MSIE to reject proxy certs?

- -- 
David Hopwood <[e-mail]>

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


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPXT/wjkCAxeYt5gVAQGDBwf/Y9J1UvMiwRImLwJMb1qlDuTwF8Tly6yj
fazL/Ru8Yvskb1oiXeUu8ZBt9eoqeS+zxR/MFv7QV7s9MgpVzc2ayKPRBar72BjU
3ieSa8QD9Voz4MIsQqAMrYYQcH1P8Ua3SPsAYqFY8mo2TIr61EKDrwaa0H8rfa/e
LHrqQKbquBLu1hfECE2MdSgDe4G4bGs/p3NMGX5II+THd7y0eFwGdWGp/TKaTBlI
JUtexH/ltBXaANEuXkmTjdOzmwbOlf1WY5SHXm7QHF8Uj4DltSNYdBmwsJskeBmq
CR+NthqpnmkikH5WheuED0SKz74cMAFbxUxyP8hK8LrnQUSrgoKH8w==
=WaLa
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83Dxx503954 for ietf-pkix-bks; Tue, 3 Sep 2002 06:59:59 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g83Dxv203948 for <[e-mail]>; Tue, 3 Sep 2002 06:59:57 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Sep 2002 13:59:58 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA23019 for <[e-mail]>; Tue, 3 Sep 2002 09:59:57 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g83Dvdk02995 for <[e-mail]>; Tue, 3 Sep 2002 09:57:39 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVP1VG>; Tue, 3 Sep 2002 09:59:55 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.3]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVP1VA; Tue, 3 Sep 2002 09:59:49 -0400
From: "Housley, Russ" <[e-mail]>
To: Steve Tuecke <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 03 Sep 2002 09:54:00 -0400
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
In-Reply-To: <4.3.2.7.2.20020830094400.00b2cc60@localhost>
References: <[e-mail]> <[e-mail] .com> <4.3.2.7.2.20020827135204.01a7b630@localhost> <[e-mail] .com> <4.3.2.7.2.20020827102404.01a755a8@localhost> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Steve:

>Should PKIX sanction the advancement of a proxy cert draft based on the 
>current fundamental approach?  We can argue about the details more later, 
>but the fundamental approach at issue is whether it is reasonable to use 
>end-entity public key certificates to sign proxy certificates. Possible 
>answers are:
>   1) No.
>   2) Yes, but only as Informational Track.
>   3) Yes, as Standards Track.

I would vote for 3.  I think that the inclusion of a critical extension in 
proxy certificates is key.  This extension keeps proxy certificates from 
being confused with other CA certificates.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83DKp101783 for ietf-pkix-bks; Tue, 3 Sep 2002 06:20:51 -0700 (PDT)
Received: from mail.belbone.be (mail.belbone.be [195.13.1.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83DKo201778 for <[e-mail]>; Tue, 3 Sep 2002 06:20:50 -0700 (PDT)
Received: from MJDeskproEN ([192.168.8.35]) by mail.belbone.be (8.12.5/8.12.5) with SMTP id g83DKnNa023053 for <[e-mail]>; Tue, 3 Sep 2002 15:20:49 +0200 (MET DST)
Message-ID: <003101c2534d$21650150$2308a8c0@MJDeskproEN>
From: "Marc Jadoul" <[e-mail]>
To: <[e-mail]>
References: <001801c25338$76a03500$2308a8c0@MJDeskproEN>
Subject: Timestamping -> Cert expiration -> Cert 'revocation' ??
Date: Tue, 3 Sep 2002 15:23:45 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C2535D.E4932E30"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [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>

This is a multi-part message in MIME format.

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

Sorry to annoy everybody. The original subject was wrong, and I suppose =
that I need to correct it if I want a response :-/
Marc
  ----- Original Message -----=20
  From: Marc Jadoul=20
  To: [e-mail]=20
  Sent: Tuesday, September 03, 2002 12:55 PM
  Subject: Timestamping + Cert revocation + revocation question


  Hi,

  I probably misunderstood something and I have a small question about =
how to 'invalidate' a certificate that has already expired.
  Here is a simple scenario:
  User A get controle on a certificate certifying User B. It create a =
signature in the name of user B. It then timestamp this signature.
  Now User B do not know this. The certificate expire and it is not =
possible to revoke it anymore (right?).
  The time-stamped signature is thus valid and I do not know any mean to =
communicate that the certificate was wrong from the begining. Any =
relying party will continue to accept the time-stamped signature, even =
if User B and the CA now know the there was a problem with the =
certificate at the time of the signature.
  Does it exist some way to communicate that a certificate was invalid =
from a specific date, even if it is known only after expiration of the =
certificate?

  How to invalidate a timestamped signature? In the real world you would =
destroy it but here, it can perfectly be duplicated.

  Marc Jadoul

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Sorry to annoy everybody. The original=20
subject&nbsp;was wrong, and&nbsp;I suppose that&nbsp;I need to correct =
it=20
if&nbsp;I want a response :-/</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Marc</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]">Marc=20
  Jadoul</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> Tuesday, September 03, =
2002 12:55=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Timestamping + Cert =
revocation +=20
  revocation question</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I probably misunderstood something =
and I have a=20
  small question about how to 'invalidate' a certificate that has =
already=20
  expired.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Here is a simple =
scenario:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>User A get controle on a certificate =
certifying=20
  User B. It create a signature in the name of user B. It then timestamp =
this=20
  signature.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Now User&nbsp;B&nbsp;do not&nbsp;know =
this. The=20
  certificate expire and it is not possible to revoke it anymore=20
  (right?).</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>The time-stamped signature is thus =
valid=20
  and&nbsp;I do not know any mean to communicate that the certificate =
was wrong=20
  from the begining. Any relying party will continue to accept the =
time-stamped=20
  signature, even if User B and the CA now know the there was a problem =
with the=20
  certificate at the time of the signature.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Does it&nbsp;exist some way to =
communicate that a=20
  certificate was invalid from a specific date, even if it is&nbsp;known =

  only&nbsp;after expiration of the certificate?</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>How to invalidate a timestamped =
signature? In the=20
  real world you would destroy it but here, it can perfectly be=20
  duplicated.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Marc =
Jadoul</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_002E_01C2535D.E4932E30--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83D9oO01090 for ietf-pkix-bks; Tue, 3 Sep 2002 06:09:50 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83D9n201085 for <[e-mail]>; Tue, 3 Sep 2002 06:09:49 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 3 Sep 2002 05:59:51 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Tue, 03 Sep 2002 05:59:50 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <R3KYDBCP>; Tue, 03 Sep 2002 06:09:27 -0700
Content-return: allowed
Date: Tue, 03 Sep 2002 06:09:19 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
To: "'Steve Tuecke '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_ClkxhhEQPd5BoP616Vl8Og)"
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [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>

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

--Boundary_(ID_ClkxhhEQPd5BoP616Vl8Og)
Content-type: text/plain

 
Linn and Kent directed IETF towards an Internet PKI
based on organizational affiliation; records show that
considerable effort since 1987 has been put into denying 
users (in  PEM/PKIX worlds) the ability to act as certificate 
issuers.

Read RFC 1040/1113, and its clear that Steve at least
concedes that X.509 permits users to be CAs. The documents
are clear that part of the (old) motivation for
the limitations PEM/PKIX still places on the X.509
model were to do with the historical need to 
to flow revenues to a patent licensee, per-certificate. 
Organizational certification supported that goal, which
was important to the Internet PKI at the time. Its very
hard to deny the legitimacy of either model, note: 1040 
re-emerged as the wildy successful VeriSign Onsite, and 
1422's ON model is still in vouge in  US/CA military 
messaging infrastructures.

In terms of consensus, I doubt we can obtain any
on this issue in IETF. There are simply two worlds: the world
of the philosophy of PKIX, and reality of actual needs and 
legacy support. Both world views are convincing and laudable; convergence is
unlikely. Matters of policy and application really
dont need PKIX WG involvement, however. All the commodity
software out there is entirely customisable in the
field, and vendor-working groups are probably a better
forum than PKIX - which properly concentrates on leading,
if not fulfilling, the long term infrastructure vision.

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

But that is where I see that the problem lies.  As I mentioned in my 
previous emails, we have also had conversations with PKIX people that
led 
to my belief that there may we irreconcilable differences of opinion
about 
this approach.  There are those who apparently believe that the approach
is 
fundamentally at odds with X.509 and PKIX world views, and should not be

sanctioned.
 

--Boundary_(ID_ClkxhhEQPd5BoP616Vl8Og)
Content-type: text/html
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Withdrawl of Proxy Cert Profile draft from PKIX</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Linn and Kent directed IETF towards an Internet =
PKI</FONT>
<BR><FONT SIZE=3D2>based on organizational affiliation; records show =
that</FONT>
<BR><FONT SIZE=3D2>considerable effort since 1987 has been put into =
denying </FONT>
<BR><FONT SIZE=3D2>users (in&nbsp; PEM/PKIX worlds) the ability to act =
as certificate </FONT>
<BR><FONT SIZE=3D2>issuers.</FONT>
</P>

<P><FONT SIZE=3D2>Read RFC 1040/1113, and its clear that Steve at =
least</FONT>
<BR><FONT SIZE=3D2>concedes that X.509 permits users to be CAs. The =
documents</FONT>
<BR><FONT SIZE=3D2>are clear that part of the (old) motivation =
for</FONT>
<BR><FONT SIZE=3D2>the limitations PEM/PKIX still places on the =
X.509</FONT>
<BR><FONT SIZE=3D2>model were to do with the historical need to </FONT>
<BR><FONT SIZE=3D2>to flow revenues to a patent licensee, =
per-certificate. </FONT>
<BR><FONT SIZE=3D2>Organizational certification supported that goal, =
which</FONT>
<BR><FONT SIZE=3D2>was important to the Internet PKI at the time. Its =
very</FONT>
<BR><FONT SIZE=3D2>hard to deny the legitimacy of either model, note: =
1040 </FONT>
<BR><FONT SIZE=3D2>re-emerged as the wildy successful VeriSign Onsite, =
and </FONT>
<BR><FONT SIZE=3D2>1422's ON model is still in vouge in&nbsp; US/CA =
military </FONT>
<BR><FONT SIZE=3D2>messaging infrastructures.</FONT>
</P>

<P><FONT SIZE=3D2>In terms of consensus, I doubt we can obtain =
any</FONT>
<BR><FONT SIZE=3D2>on this issue in IETF. There are simply two worlds: =
the world</FONT>
<BR><FONT SIZE=3D2>of the philosophy of PKIX, and reality of actual =
needs and </FONT>
<BR><FONT SIZE=3D2>legacy support. Both world views are convincing and =
laudable; convergence is&nbsp; unlikely. Matters of policy and =
application really</FONT></P>

<P><FONT SIZE=3D2>dont need PKIX WG involvement, however. All the =
commodity</FONT>
<BR><FONT SIZE=3D2>software out there is entirely customisable in =
the</FONT>
<BR><FONT SIZE=3D2>field, and vendor-working groups are probably a =
better</FONT>
<BR><FONT SIZE=3D2>forum than PKIX - which properly concentrates on =
leading,</FONT>
<BR><FONT SIZE=3D2>if not fulfilling, the long term infrastructure =
vision.</FONT>
</P>

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

<P><FONT SIZE=3D2>But that is where I see that the problem lies.&nbsp; =
As I mentioned in my </FONT>
<BR><FONT SIZE=3D2>previous emails, we have also had conversations with =
PKIX people that</FONT>
<BR><FONT SIZE=3D2>led </FONT>
<BR><FONT SIZE=3D2>to my belief that there may we irreconcilable =
differences of opinion</FONT>
<BR><FONT SIZE=3D2>about </FONT>
<BR><FONT SIZE=3D2>this approach.&nbsp; There are those who apparently =
believe that the approach</FONT>
<BR><FONT SIZE=3D2>is </FONT>
<BR><FONT SIZE=3D2>fundamentally at odds with X.509 and PKIX world =
views, and should not be</FONT>
</P>

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

</BODY>
</HTML>

--Boundary_(ID_ClkxhhEQPd5BoP616Vl8Og)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83D8xs01046 for ietf-pkix-bks; Tue, 3 Sep 2002 06:08:59 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83D8w201041 for <[e-mail]>; Tue, 3 Sep 2002 06:08:58 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 3 Sep 2002 05:58:50 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Tue, 03 Sep 2002 05:58:49 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <R3KYDBCM>; Tue, 03 Sep 2002 06:08:26 -0700
Content-return: allowed
Date: Tue, 03 Sep 2002 06:08:23 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
To: "'Steve Tuecke '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_M6moA8kprXHxZzeES9hMUQ)"
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [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>

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

--Boundary_(ID_M6moA8kprXHxZzeES9hMUQ)
Content-type: text/plain

Linn and Kent directed IETF towards an Internet PKI
based on organizational affiliation; records show that
considerable effort since 1987 has been put into denying 
users (in  PEM/PKIX worlds) the ability to act as certificate 
issuers.

Read RFC 1040/1113, and its clear that Steve at least
concedes that X.509 permits users to be CAs. The documents
are clear that part of the (old) motivation for
the limitations PEM/PKIX still places on the X.509
model were to do with the historical need to 
to flow revenues to a patent licensee, per-certificate. 
Organizational certification supported that goal, which
was important to the Internet PKI at the time. Its very
hard to deny the legitimacy of either model, note: 1040 
re-emerged as the wildy successful VeriSign Onsite, and 
1422's ON model is still in vouge in  US/CA military 
messaging infrastructures.

In terms of consensus, I doubt we can obtain any
on this issue in IETF. There are simply two worlds: the world
of the philosophy of PKIX, and reality of actual needs and 
legacy support. Both world views are convincing and laudable; convergence is
unlikely. Matters of policy and application really
dont need PKIX WG involvement, however. All the commodity
software out there is entirely customisable in the
field, and vendor-working groups are probably a better
forum than PKIX - which properly concentrates on leading,
if not fulfilling, the long term infrastructure vision.

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

But that is where I see that the problem lies.  As I mentioned in my 
previous emails, we have also had conversations with PKIX people that
led 
to my belief that there may we irreconcilable differences of opinion
about 
this approach.  There are those who apparently believe that the approach
is 
fundamentally at odds with X.509 and PKIX world views, and should not be

sanctioned.
 

--Boundary_(ID_M6moA8kprXHxZzeES9hMUQ)
Content-type: text/html
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Withdrawl of Proxy Cert Profile draft from PKIX</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Linn and Kent directed IETF towards an Internet =
PKI</FONT>
<BR><FONT SIZE=3D2>based on organizational affiliation; records show =
that</FONT>
<BR><FONT SIZE=3D2>considerable effort since 1987 has been put into =
denying </FONT>
<BR><FONT SIZE=3D2>users (in&nbsp; PEM/PKIX worlds) the ability to act =
as certificate </FONT>
<BR><FONT SIZE=3D2>issuers.</FONT>
</P>

<P><FONT SIZE=3D2>Read RFC 1040/1113, and its clear that Steve at =
least</FONT>
<BR><FONT SIZE=3D2>concedes that X.509 permits users to be CAs. The =
documents</FONT>
<BR><FONT SIZE=3D2>are clear that part of the (old) motivation =
for</FONT>
<BR><FONT SIZE=3D2>the limitations PEM/PKIX still places on the =
X.509</FONT>
<BR><FONT SIZE=3D2>model were to do with the historical need to </FONT>
<BR><FONT SIZE=3D2>to flow revenues to a patent licensee, =
per-certificate. </FONT>
<BR><FONT SIZE=3D2>Organizational certification supported that goal, =
which</FONT>
<BR><FONT SIZE=3D2>was important to the Internet PKI at the time. Its =
very</FONT>
<BR><FONT SIZE=3D2>hard to deny the legitimacy of either model, note: =
1040 </FONT>
<BR><FONT SIZE=3D2>re-emerged as the wildy successful VeriSign Onsite, =
and </FONT>
<BR><FONT SIZE=3D2>1422's ON model is still in vouge in&nbsp; US/CA =
military </FONT>
<BR><FONT SIZE=3D2>messaging infrastructures.</FONT>
</P>

<P><FONT SIZE=3D2>In terms of consensus, I doubt we can obtain =
any</FONT>
<BR><FONT SIZE=3D2>on this issue in IETF. There are simply two worlds: =
the world</FONT>
<BR><FONT SIZE=3D2>of the philosophy of PKIX, and reality of actual =
needs and </FONT>
<BR><FONT SIZE=3D2>legacy support. Both world views are convincing and =
laudable; convergence is&nbsp; unlikely. Matters of policy and =
application really</FONT></P>

<P><FONT SIZE=3D2>dont need PKIX WG involvement, however. All the =
commodity</FONT>
<BR><FONT SIZE=3D2>software out there is entirely customisable in =
the</FONT>
<BR><FONT SIZE=3D2>field, and vendor-working groups are probably a =
better</FONT>
<BR><FONT SIZE=3D2>forum than PKIX - which properly concentrates on =
leading,</FONT>
<BR><FONT SIZE=3D2>if not fulfilling, the long term infrastructure =
vision.</FONT>
</P>

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

<P><FONT SIZE=3D2>But that is where I see that the problem lies.&nbsp; =
As I mentioned in my </FONT>
<BR><FONT SIZE=3D2>previous emails, we have also had conversations with =
PKIX people that</FONT>
<BR><FONT SIZE=3D2>led </FONT>
<BR><FONT SIZE=3D2>to my belief that there may we irreconcilable =
differences of opinion</FONT>
<BR><FONT SIZE=3D2>about </FONT>
<BR><FONT SIZE=3D2>this approach.&nbsp; There are those who apparently =
believe that the approach</FONT>
<BR><FONT SIZE=3D2>is </FONT>
<BR><FONT SIZE=3D2>fundamentally at odds with X.509 and PKIX world =
views, and should not be</FONT>
</P>

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

</BODY>
</HTML>

--Boundary_(ID_M6moA8kprXHxZzeES9hMUQ)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83AqtI19448 for ietf-pkix-bks; Tue, 3 Sep 2002 03:52:55 -0700 (PDT)
Received: from mail.belbone.be (mail.belbone.be [195.13.1.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83Aqr219441 for <[e-mail]>; Tue, 3 Sep 2002 03:52:54 -0700 (PDT)
Received: from MJDeskproEN ([192.168.8.35]) by mail.belbone.be (8.12.5/8.12.5) with SMTP id g83AqrNa016358 for <[e-mail]>; Tue, 3 Sep 2002 12:52:54 +0200 (MET DST)
Message-ID: <001801c25338$76a03500$2308a8c0@MJDeskproEN>
From: "Marc Jadoul" <[e-mail]>
To: <[e-mail]>
Subject: Timestamping + Cert revocation + revocation question
Date: Tue, 3 Sep 2002 12:55:48 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C25349.39BDC010"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [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>

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01C25349.39BDC010
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I probably misunderstood something and I have a small question about how =
to 'invalidate' a certificate that has already expired.
Here is a simple scenario:
User A get controle on a certificate certifying User B. It create a =
signature in the name of user B. It then timestamp this signature.
Now User B do not know this. The certificate expire and it is not =
possible to revoke it anymore (right?).
The time-stamped signature is thus valid and I do not know any mean to =
communicate that the certificate was wrong from the begining. Any =
relying party will continue to accept the time-stamped signature, even =
if User B and the CA now know the there was a problem with the =
certificate at the time of the signature.
Does it exist some way to communicate that a certificate was invalid =
from a specific date, even if it is known only after expiration of the =
certificate?

How to invalidate a timestamped signature? In the real world you would =
destroy it but here, it can perfectly be duplicated.

Marc Jadoul

------=_NextPart_000_0015_01C25349.39BDC010
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I probably misunderstood something and =
I have a=20
small question about how to 'invalidate' a certificate that has already=20
expired.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Here is a simple scenario:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>User A get controle on a certificate =
certifying=20
User B. It create a signature in the name of user B. It then timestamp =
this=20
signature.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Now User&nbsp;B&nbsp;do not&nbsp;know =
this. The=20
certificate expire and it is not possible to revoke it anymore=20
(right?).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The time-stamped signature is thus =
valid and&nbsp;I=20
do not know any mean to communicate that the certificate was wrong from =
the=20
begining. Any relying party will continue to accept the time-stamped =
signature,=20
even if User B and the CA now know the there was a problem with the =
certificate=20
at the time of the signature.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Does it&nbsp;exist some way to =
communicate that a=20
certificate was invalid from a specific date, even if it is&nbsp;known=20
only&nbsp;after expiration of the certificate?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>How to invalidate a timestamped =
signature? In the=20
real world you would destroy it but here, it can perfectly be=20
duplicated.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Marc Jadoul</FONT></DIV></BODY></HTML>

------=_NextPart_000_0015_01C25349.39BDC010--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g832kSD02570 for ietf-pkix-bks; Mon, 2 Sep 2002 19:46:28 -0700 (PDT)
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g832kQ202565 for <[e-mail]>; Mon, 2 Sep 2002 19:46:26 -0700 (PDT)
Received: from monkeyboy2001.mcs.anl.gov (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id VAA126034; Mon, 2 Sep 2002 21:45:52 -0500
Message-Id: <4.3.2.7.2.20020830094400.00b2cc60@localhost>
X-Sender: tuecke@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 02 Sep 2002 21:43:58 -0500
To: Denis Pinkas <[e-mail]>
From: Steve Tuecke <[e-mail]>
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail] .com> <4.3.2.7.2.20020827135204.01a7b630@localhost> <[e-mail] .com> <4.3.2.7.2.20020827102404.01a755a8@localhost> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Denis,

PKIX has already influenced the content of the proxy cert profile 
substantially.  I realized after my last email that "languished" was 
perhaps a poor choice of words.  In fact, the document has progressed 
substantially since its initial submission, based in part upon discussions 
with several PKIX participants.  It would perhaps be better to describe it 
as "languishing" (present tense), as it seems that changes have reached a 
plateau, with no clear path or energy to move it forward in PKIX.  (Though 
maybe this discussion will change that.)

The document is definitely still influenceable, if people are willing to 
expend the effort to attempt to influence it in the near future.  The 
document has evolved substantially during the year and a half it has been 
out there, such that the authors are now pretty happy with it.  But 
frankly, there really is not all that much to this profile. (See 
below.)  If there is acceptance of the fundamental approach of having a 
proxy cert signed by an end-entity cert or another proxy cert, then I think 
reaching consensus on the details should not be hard or take very long 
given the progress we have already made.

But that is where I see that the problem lies.  As I mentioned in my 
previous emails, we have also had conversations with PKIX people that led 
to my belief that there may we irreconcilable differences of opinion about 
this approach.  There are those who apparently believe that the approach is 
fundamentally at odds with X.509 and PKIX world views, and should not be 
sanctioned.

Perhaps this is the straw poll that needs to be taken...

Should PKIX sanction the advancement of a proxy cert draft based on the 
current fundamental approach?  We can argue about the details more later, 
but the fundamental approach at issue is whether it is reasonable to use 
end-entity public key certificates to sign proxy certificates. Possible 
answers are:
   1) No.
   2) Yes, but only as Informational Track.
   3) Yes, as Standards Track.

In order better inform voters, it is perhaps useful for me to summarize the 
approach, and some of the discussions that have occurred.  Note that I have 
purposely omitted names in the following text.  As none of the referenced 
discussions with PKIX people happened in a public forum, I don't want to 
drag them into a public debate against their will.  But of course, I'm 
happy if they jump in and take credit for (and argue for) the suggestions 
and critiques describe below.

A proxy cert is denoted by the presence of the proxyCertInfo extension, 
which must be marked critical.  A proxy cert is signed/issued by either an 
end-entity cert, or by another proxy cert.  The subject of the proxy cert 
is derived from that of its issuer, by taking the issuer DN and appending a 
common name whose value should be unique amongst all proxy certs issued by 
a particular issuer.  The subjectAltName must be empty, and there are rules 
for what is allowed in the proxy cert's key usage and extended key usage 
relative to its issuer.

The proxyCertInfo extension carries three things: a version number, so more 
info can be added to it in a subsequent revision, if desired; a 
pCPathLenConstraint to limit the proxy path length; and a proxyPolicy that 
is just a 2-tuple containing an OID of a policy language, and a policy blob 
expressed in that language.  There are two simple policies defined in the 
draft: one that states that the proxy cert is allowed to impersonate its 
issuer (that is, it inherits all rights that the issuer has), and one that 
states that the proxy cert is independent of its issuer (that is, it 
inherits no rights from its issuer).  Other policy languages can be defined 
that allow for finer grain inheritance of rights from the issuer.

Changes are required to the path validation algorithm, in order to verify 
that the proxy subject is properly derived from the subject of its issuer, 
to verify the key usage and extended key usage are correctly derived from 
the issuer, and to check the pCPathLenConstraint.

That's about it.

The biggest change to the draft came with the -02 version.  Based on 
discussions and suggestions from PKIX members, we changed the way subject 
names were handled in proxies, in order to make them work better with 
attribute certificates.  Prior to that version, we went to some length to 
avoid providing a useful proxy subject, so that a proxy really just 
inherited its name from its issuing end-entity cert.  In other words, it 
was more of a straight impersonation approach -- in essence, we were 
basically just binding temporary keys to an existing end-entity 
subject.  This changed to the approach described above, in which each proxy 
cert is given a unique subject DN, derived from that of its issuer.  This 
allows a proxy cert to be the holder of an attribute cert.

The concern that has been expressed by various PKIX people is that we are 
using end-entity certs to issue proxy certs.  The argument is that we are 
using the end-entity cert like a CA cert, which violates the fundamental 
X.509 and PKIX world view.

At some conceptual level, this is obviously true -- we are creating a key 
pair, creating a unique subject name, and then using the end-entity cert to 
sign a certificate containing the public key, name, and other information 
including the proxyCertInfo.  However:

   1) A proxy certificate is not an end-entity certificate -- a proxy 
cert's reason for existing is quite different from an end-entity cert.  The 
whole point of proxy certs is to allow for relatively short-lived entities, 
which are dynamically created and destroyed, to be given an authenticatable 
identity, optionally accompanied with some delegated rights from the 
issuer.  Issuing certificates using a traditional CA model is not practical 
or efficient for such entities.

   2) Existing code that does not implement proxy cert path validation will 
reject a proxy cert that is presented to it for 2 reasons: (1) the 
BasicConstraints.cA bit of the issuing end-entity is false, and (2) the 
proxyCertInfo extension is marked critical.  So unless existing code is 
horribly mis-implemented (even these most basic checks are not done in its 
path validation), there should be no concern about problems that proxy 
certs can cause to existing implementations.

   3) Code that properly implements proxy cert path validation cannot 
confuse an end-entity cert with a proxy cert.  The proxy cert path 
validation will reject an end-entity cert signed by a proxy cert, or a 
proxy cert that tries to spoof some subject name that is not properly 
derived from that of the issuing end-entity.  So in new code that 
implements proxy cert's, there is clear delineation between the two.

So while at some level an end-entity and proxy cert look a lot alike, they 
are really distinct things, used for distinct purposes, and cannot be 
confused with each other either by an existing implementation that does not 
implement the proxy cert profile, or by a new implementation that properly 
implements the proxy cert profile.

The only alternative approaches that were suggested were:

   A) Have existing CAs issue end-entity certificates with the 
BasicConstraints.cA bit set to true, and name constraints set to restrict 
the subjects of any certs signed by that end-entity.  In other words, 
instead of issuing end-entity certs, issue subordinate CA certs.  An 
advantage to this approach is that it lives within the current X.509/PKIX 
model.  But I believe this approach has a few problems.  First, of the CA 
operators I have talked to, none of them would issue "end-entity" certs 
with the cA bit set to true, as they found that even more counter to the 
X.509/PKIX world view than the introduction of proxy certs.  Second, many 
existing implementations do not implement name constraints, which not only 
means new code would need to be rolled out anyway (just like it does for 
proxies), but that existing code could easily be spoofed by an end-entity 
that signs another end-entity subject.  On this last point, an advantage to 
the current proxy cert profile is that code that has not been explicitly 
coded to accept proxies will reject them due to the existing fundamental 
path validation rules.

   B) Create an CA which automatically issues new end-entity certs on 
demand for the dynamically created entities.  The primary problem with this 
approach is scalability, particularly in a large, widely distributed system 
with lots of dynamically created entities (which is exactly what we are 
building today in various Grid applications using proxy certs).  The 
advantage of the current proxy cert profile is that a proxy can be 
unilaterally created by an existing entity (the holder of an end-entity 
cert or existing proxy cert), with no need for centralization.

   C) Forget X.509, and just use raw keys for what we are trying to 
do.  But the reason we went down the proxy cert path in the first place was 
so that they could drop into existing code base (e.g. SSL/TLS libraries) 
with little modification.  Technical details aside, I also found this 
argument to be curious coming from a PKIX person -- given that PKIX 
specifications as they exist today do not meet our needs, does it make more 
sense to augment the current PKIX specifications as we have done, or is it 
better to just bail on X.509 entirely?

-Steve

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



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g82JekA12160 for ietf-pkix-bks; Mon, 2 Sep 2002 12:40:46 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g82Jej212156 for <[e-mail]>; Mon, 2 Sep 2002 12:40:45 -0700 (PDT)
Subject: Re: draft-ietf-pkix-warranty-ext-01
To: Denis Pinkas <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 2 Sep 2002 13:38:54 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 09/02/2002 03:36:23 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [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>

In addtion to insurance premiums proportional to risk
http://www.garlic.com/~lynn/aadsm12.htm#20" draft-ietf-pkix-warranty-ext-01
There are actually a couple of issues:

a) security/insurance proportional to risk. in the online world ... the
RP/merchant may get a surcharge per transaction that pays for insurance on
per transaction basis. they may also have one-time disaster insurance ...
that is sort of independent of the number of transactions ... but
represents some total value that is at risk

b)  the entity at risk pays for the insurance. typically the business
arrangement is between the CA and the entity being certified. if it is a
merchant certificate then the CA can charge a little bit more for the
insurance to cover damages where the merchant might get sued. if it is a
consumer certificate .... the consumer is being charge but typically the
merchant is still the one at risk; not the consumer (this is because there
are special provisions favoring consumers in retail transactions .... this
wouldn't apply between two equal parties in commercial transactions).
Ignoring for a moment the issue of whether (offline paradigm) certificates
are needed in the online world, there is a separate issue that the entity
primarily at risk is not party to the CA/consumer business transaction.
There is nominally no direct business relationship between the CA & the
merchant in the case of consumer certificates .... so it is difficult for a
merchant to establish liability (possibility other civil legal issues)
against the CA.  Difficult for a merchant to sue a consumer because of CA
liability to the consumer.

CAs either have to

1) convince consumers that certificates are good for something that
consumers have at risk (say identity theft) for which the CA can justify
charging the consumer extra to cover the cost of doing business as well as
ancillary things like  insurance  ... or

2) CAs have to revamp the business model so that there is a contractual
relationship between the CA and the RP ... and be able to charge on the
basis of that   ... or

3) get gov. to pass mandated certificate requirements.

now ... if

1) if consumers (or any party) aren't at risk ... it is hard to get them to
(directly) pay anything

2) if a contractual relationship between CAs and RPs can be fabricated ....
then you are likely to have relying-party-only certificates .... the RPs
pay either directly or indirectly (so that there is a contractual
relationship with the CA on which money flow can be based) ...  the RPs
will pass on the cost for relying-party-only certificates to the consumer
.... but it is a business solution to match the money flow with who is at
risk and the contractual relationships. The downside here is that it is
trivially possible to show that relying-party-only certificates in an
online, transaction world are redundant and superfluous. This establishes
some basis for civil litigation.

3) if you can get a gov. to pass bills mandating something ... then you can
eliminate any civil liability issues with the contractual relationships and
money flow not matching parties at risk.

I believe there has been lots of past discussions regarding the difficulty
in the commercial world of establish money flow & risk with the RP in a
standard CADS paradigm (the RP being at risk but original CADS business
model had no contractual relationship between the CA and the RP). I believe
the FED GSA PKI stuff has tried to resolve this by contorting the business
model that the contractual relationship is between GSA and the CAs .... and
that the CAs are providing (relying-party) certificates to end-users. CAs
may levy a surcharge on the end-users for the certificate issuing ... but
the business relationship is not between the CA and the end-user .... it is
between the CA and GSA (the relying party). Note that since the business
relationship is between the CA and the GSA, the contract(s) call out the
warranties and liabilities.  In this case, certificates would be considered
a service provided and independent of the contract documents and the
specifications of T&Cs, warranties, liabilities and things like insurance.

The next step would be to get some kind of legislative bill passed that
mandates such certificates .... even when it can be proven that they are
redundant and superfluous in an online world.

random refs on relying party certificates:
http://www.garlic.com/~lynn/subtopic.html#rpo



[e-mail] wrote:

Alice,

I concur with many of the arguments raised by Anders. It is very scarce,
but
this time it happened, thanks to your draft. :-)

I believe that sufficient arguments have been raised against the
progression
of this draft, as it stands, which does not even explicitly states, for a
naive reader, what the warranty is about.

The warranty is concerned with the liability of the CA, more precisely,
only
errors made by the CA personal or attributed to the CA during the
management
of the certificate, e.g. at the time of registration of the subject, when
issuing the certificate, when handling revocation requests or when making
available revocation status information.

Regards,

Denis





Received: by above.proper.com (8.11.6/8.11.3) id g82FRLM00938 for ietf-pkix-bks; Mon, 2 Sep 2002 08:27:21 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g82FRI200934 for <[e-mail]>; Mon, 2 Sep 2002 08:27:18 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Sep 2002 15:27:20 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA04030 for <[e-mail]>; Mon, 2 Sep 2002 11:27:19 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g82FP3c26271 for <[e-mail]>; Mon, 2 Sep 2002 11:25:03 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPV38XA>; Mon, 2 Sep 2002 11:27:17 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.1]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPV38W0; Mon, 2 Sep 2002 11:27:15 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 02 Sep 2002 11:26:19 -0400
Subject: Re: rfc822name Name Constraints question
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [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>

Anne:

The email address name constraint contains the right-hand part.  So, any 
email address that exactly matches the right-hand part in the name 
constraint is valid.

>RFC3280 describes how name constraints for "Internet mail
>addresses" may be specified, but is unclear on a few points:
>
>1. If the NameConstraint is "[e-mail]", does that include
>    "[e-mail]"?

Yes.  The email address "[e-mail]" does satisfy the "[e-mail]" 
constraint.

>2. Can "@xyz.com" be used to match all mail addresses at
>    "xyz.com" but not addresses at "abc.xyz.com?

Yes.  The constraint "@xyz.com" would only be satisfied by mailboxes (or 
.forward entries) on the host xyz.com.

>3. The paragraph says the constraint "xyz.com" is satisfied by
>    "any mail address at the host "xyz.com", and ".xyz.com" is
>    satisfied by an address within the domain xyz.com, but not
>    xyz.com itself.  How then do I specify all addresses in the
>    domain xyz.com AND xyz.com itself?

The constraint "xyz.com" permits "[e-mail]" and "[e-mail]"

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g82AoUE15246 for ietf-pkix-bks; Mon, 2 Sep 2002 03:50:30 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g82AoS215237 for <[e-mail]>; Mon, 2 Sep 2002 03:50:28 -0700 (PDT)
Received: from cln-m002.frcl.bull.fr (cln-m002.frcl.bull.fr [129.182.91.41]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA12842; Mon, 2 Sep 2002 12:55:06 +0200
Received: from bull.net ([129.182.108.120]) by cln-m002.frcl.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002090212500880:386 ; Mon, 2 Sep 2002 12:50:08 +0200 
Message-ID: <[e-mail]>
Date: Mon, 02 Sep 2002 12:50:08 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: Anders Rundgren <[e-mail]>, [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-warranty-ext-01
References: <[e-mail]> <007701c251cf$1298f750$0500a8c0@arport>
X-MIMETrack: Itemize by SMTP Server on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 02/09/2002 12:50:09, Serialize by Router on CLN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 02/09/2002 12:50:13, Serialize complete at 02/09/2002 12:50:13
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [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>

Alice,

I concur with many of the arguments raised by Anders. It is very scarce, but
this time it happened, thanks to your draft. :-) 

I believe that sufficient arguments have been raised against the progression
of this draft, as it stands, which does not even explicitly states, for a
naive reader, what the warranty is about.

The warranty is concerned with the liability of the CA, more precisely, only 
errors made by the CA personal or attributed to the CA during the management
of the certificate, e.g. at the time of registration of the subject, when
issuing the certificate, when handling revocation requests or when making
available revocation status information.

Regards,

Denis

> Alice,
> 
> >Lynn observed that the world of financial risk management is moving past
> >per-transaction model.  The proposed extension offers an aggregate model.
> >Also Lynn wrote: "and any migration to an offline paradigm with
> >> both support for per transaction as well as aggregation risk/limits
> >> obsoletes the requirement for the certificate."
> >That's true; that's why the extension is useful.  If total risk, i.e.,
> >aggregated transactions, is the primary worry of the insurance industry then
> >the aggregate model would be appropriate.
> 
> This sounds pretty dangerous as it gives no value to an RP which may be just
> one of several thousands of RPs which just received a purchase order
> from a company that is on the edge of filing for bankruptcy.
> 
> If it is of no value to RPs, the only purpose left for the warranty-extension
> is for a CA to insert its liability limit in a machine-readable
> format.  Is this really interesting as any liability above zero is likely
> to be accompanied by a non-machine-interpretable agreement?
> 
> Is the intent, that the moment a transaction is received that exceeds
> the liability limit, an alert is to be sent to the legal department?
> Depending on the liability agreement this may be too late
> as lower-amount transactions may be equally uncovered.
> 
> Actually it would IMO better be a part of the CA-certificate to
> declare what it stands for in terms of liability.
> 
> Regarding warranted purchase orders, I have serious problems
> understanding what a CA-issued warranty could possibly cover except
> for a liability for having certified the wrong entity which is now making
> fake orders.  But IMHO such a warranty is equally applicable to
> authentications, as incorrect such are even worse as you cannot
> "rollback" authentication events.
> 
> For pure financial transactions, there are already solutions in place
> since ages ago, like bank-warranties, remburses and pre-paid orders.
> 
> cheers,
> Anders


Received: by above.proper.com (8.11.6/8.11.3) id g81JvdI02801 for ietf-pkix-bks; Sun, 1 Sep 2002 12:57:39 -0700 (PDT)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g81Jvb202795 for <[e-mail]>; Sun, 1 Sep 2002 12:57:37 -0700 (PDT)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g81JvUkC087383; Sun, 1 Sep 2002 19:57:30 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020901124930.034bdbd8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 01 Sep 2002 12:57:08 -0700
To: [e-mail], [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: Wildcard certificates
Cc: EKR <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [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>

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

Most LDAP implementations do this... per RFC 2830, Section 3.6.

Kurt



Received: by above.proper.com (8.11.6/8.11.3) id g81Ft0j16774 for ietf-pkix-bks; Sun, 1 Sep 2002 08:55:00 -0700 (PDT)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g81Fsx216770 for <[e-mail]>; Sun, 1 Sep 2002 08:54:59 -0700 (PDT)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id g81Fsugu016288; Sun, 1 Sep 2002 17:54:56 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <007701c251cf$1298f750$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Denis Pinkas" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: draft-ietf-pkix-warranty-ext-01
Date: Sun, 1 Sep 2002 17:48:51 +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
Sender: [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>

Alice,

>Lynn observed that the world of financial risk management is moving past
>per-transaction model.  The proposed extension offers an aggregate model.
>Also Lynn wrote: "and any migration to an offline paradigm with
>> both support for per transaction as well as aggregation risk/limits
>> obsoletes the requirement for the certificate."
>That's true; that's why the extension is useful.  If total risk, i.e.,
>aggregated transactions, is the primary worry of the insurance industry then
>the aggregate model would be appropriate.

This sounds pretty dangerous as it gives no value to an RP which may be just
one of several thousands of RPs which just received a purchase order
from a company that is on the edge of filing for bankruptcy.

If it is of no value to RPs, the only purpose left for the warranty-extension
is for a CA to insert its liability limit in a machine-readable
format.  Is this really interesting as any liability above zero is likely
to be accompanied by a non-machine-interpretable agreement?

Is the intent, that the moment a transaction is received that exceeds
the liability limit, an alert is to be sent to the legal department?
Depending on the liability agreement this may be too late
as lower-amount transactions may be equally uncovered.

Actually it would IMO better be a part of the CA-certificate to
declare what it stands for in terms of liability.

Regarding warranted purchase orders, I have serious problems
understanding what a CA-issued warranty could possibly cover except
for a liability for having certified the wrong entity which is now making
fake orders.  But IMHO such a warranty is equally applicable to
authentications, as incorrect such are even worse as you cannot
"rollback" authentication events.

For pure financial transactions, there are already solutions in place
since ages ago, like bank-warranties, remburses and pre-paid orders.

cheers,
Anders





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g81BhbB28199 for ietf-pkix-bks; Sun, 1 Sep 2002 04:43:37 -0700 (PDT)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g81Bha228194 for <[e-mail]>; Sun, 1 Sep 2002 04:43:36 -0700 (PDT)
Received: from mail6.magma.ca (mail6 [206.191.0.248]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id g81BhZng008472; Sun, 1 Sep 2002 07:43:35 -0400 (EDT)
Received: from asturgeonpc (ottawa-dial-64-26-139-166.d-ip.magma.ca [64.26.139.166]) by mail6.magma.ca (Magma's Mail Server) with SMTP id g81BhXRZ004044; Sun, 1 Sep 2002 07:43:34 -0400 (EDT)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-warranty-ext-01
Date: Sun, 1 Sep 2002 07:49:11 -0400
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]>
Sender: [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>

Denis, Lynn, and others,

Denis, you wrote: "While, as you say, the basic intent of
the proposed extension is building confidence in e-business, in reality it
would build a FALSE confidence in e-busines, then doing more harm that
benefits. I disagree that processing only the amount field allows to build
confidence."

This seems to be the crux of our disagreement. I do believe that the
extension will add confidence in e-business. Its presence alone provides
some modicum of assurance that the matter of warranty for transactions has
been addressed. This in and of itself gives any RP confidence in the
transaction.

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

You're right that this is not the purpose of the extension. Checking
afterwards is not necessary to fulfill the purpose of the extension which is
to show that some kind of warranty does exist for the transaction and/or the
certificate in use.  That in itself is sufficient.  It can also be easily
processed by the asn.1 syntax.

Lynn observed that the world of financial risk management is moving past
per-transaction model.  The proposed extension offers an aggregate model.
Also Lynn wrote: "and any migration to an offline paradigm with
> both support for per transaction as well as aggregation risk/limits
> obsoletes the requirement for the certificate."
That's true; that's why the extension is useful.  If total risk, i.e.,
aggregated transactions, is the primary worry of the insurance industry then
the aggregate model would be appropriate.



Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331