Summary RE: Last Call: Qualified Certificates

["Stefan Santesson" <[e-mail]>]

I try to summarize the issues and their resolution to see if we all can
live with this. I exclude the typo remarks.

Issue 1: use of term "Private extensions"
Resolution: We will change and just talk about extensions

Issue 2: Exclude ASN.1 other than ASN.1 in 1988 syntax.
Resolution: We will keep the 1997 syntax as informative, as approved by
Russ.

Issue 3: New section stating changes from RFC 3039
Resolution: Section will be added


Issue 4: Defining granularity of Date of birth

Resolution: We conclude that the best solution would have been if we
just defined a raw text format from the beginning, independent of
GenerelizedTime. That is to late now though, since this attribute
already in use. The problem is that display of a date specified in this
format may be changed to another date due to adjustments for timezones.
The only time that will cause the same date display regardless of
timezone is 12.00.00 GMT. We will therefore recommend the time to be set
to 12.00.00 including second. We also recommend that clients parsing
this attribute should ignore any time data and display just the date
without any adjustment for local time zone.


Issue 5: countryOfResidence and countryOfCitizenship. Multi valued
attributes or Multipple occurance of single valued attributes or
requirement to include just 1 value in a certificate.

Resolution: We don't want to restrict to 1 country value for any of
these attributes. Neither do we want to forbid any variant to include
multiple countries. We do however want to RECOMMEND attribute values to
be repeated as multiple occurrences of single valued attributes, if more
than one value is to be included.


Issue 6: What is hashed in a graphic picture of biometric info?
Resolution: The whole file should be hashed. We will use the same
wording as the new logotype RFC but we will not enhance or change the
ASN.1 structure since this extension is being deployed.


Issue 7: Updating the qcStatement-1 for the new RFC
Resolution: Yes we should define a new OID for compliance with V2 of
this standard, which then also will help indicate the updated/clarified
semantics of the subject Directory attributes.

Issue 8: Optional absence of statementInfo of qcStatament for the
predefined statement
Resolution: We think this is syntactically defined in 3.2.5 but we are
willing to add a clarifying sentence in 3.2.5.1 as well.

Issue 9: Changing the pretty name of the ASN.1 module.
Resolution: We want to follow the praxis of other RFC:s in this area and
keep the name with a new OID. Why wouldn't that work for this standard
when it works for RFC 3280?


I hope this is OK for everyone
If so we will issue a new draft with these changes ASAP.

/Stefan

> 
> 3.  New section 1.1 is required to be added stating the differences
> between this document and 3039
> 
> 4.  Section 2, para 2:
>  	The text "where the certificate meet some qualification
> requirements" should be imported to either "certificates meet" or
> "certificate meets"
> 
> 5.  Section 2, bullet item 3:  Suggest new text of
>  	"-  Definition of usage for the key usage extension in Qualified
>       Certificates.."
> 
> 6.  Section 3.2.1 - DateOfBirth SHOULD state the proper encoding to be
> used.  I.E. are we looking for seconds, minutes or hours or just DATE
in
> the GeneralTime field?
> 
> 7.  Section 3.2.1 - countryOfResidence and countryOfCitizenship - If
you
> have multiple countrys to be listed, should this be a multi-value item
> or should there be two distinct attributes? (Alternatively should this
> be restricted back to a single attribute with a single value - i.e you
> can only list one of your countries of citizenship.)
> 
> 8.  Section 3.2.4 - This is something that I have no experence with.
If
> you look at a jpeg, bitmap or other type if image, who defines what is
> considred to be a label and what is considered to be the image data?
> What is done in this case about different sized images?
> 
> 9.  Section 3.2.5.1 - I would like to know the reason that
qcstatement-1
> has not been updated to a new OID.  This is a new draft document with
> some different semantics than 3039.  Are these changes all suffiently
> small that a new policy is not needed?
> 
> 10. Sectin 3.2.5.1 - I have decided to put the predefined statement
into
> my QC.  After reading this document I understand that what I want
> stearts as follows:
> 
> 	EXTENSION { id-pe-qcStatements,
> 			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> In this case I don't have asemanticsIdentifier created by the
document,
> so I must be incoluding the NameRegistrationAuthorities otion.
However
> I don't know if what goes here is the pkix working group name or some
> other value.
> 
> 11.  Sectin A.1 - I suggest changing the pretty name to
> PKIXqualified88-03 to distinquish from rfc3039.
> 
> 
> 
> jim
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUAQZib052433 for <[e-mail]>; Tue, 30 Dec 2003 02:26:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBUAQZim052432 for ietf-pkix-bks; Tue, 30 Dec 2003 02:26:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUAQXib052427 for <[e-mail]>; Tue, 30 Dec 2003 02:26:34 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t12o913p34.telia.com [213.64.28.154]) by smtp1.fre.skanova.net (8.12.10/8.12.10) with SMTP id hBUAQBYT019607; Tue, 30 Dec 2003 11:26:17 +0100 (CET)
Message-ID: <004501c3cebe$b4db12b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Marc Poulaud" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <p06020404bc1653dc01c8@[128.89.89.75]>
Subject: Re: IDPKC
Date: Tue, 30 Dec 2003 11:21:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
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>

Steve,
That was a truly brilliant analysis of IDPKC!

It would however be nice to get a similarly educated analysis of
PKI in the form you have more faith in.  Like how you actually can
build shrink-wrapped, reliable, and user-friendly RP software based
on standards having the following characteristics:

      "RFC3280 [6] when taken to its extreme by exploring all possible
       valid uses, allows each EE certificate to be an entirely unique
       object with no relationship to other EE certificates belonging
       to the same PKI hierarchy, except for sharing a common trust
       anchor.  That is, a single CA may vouch for an arbitrary number
       of different certificate policies.  CAs conforming to RFC3280
       may also deploy subject DNs that may only be locally unique for
       the CA, potentially creating name space conflicts between
       different CAs.  In spite of the availability of X.509 policy
       extensions, limited efforts have been made to establish a common
       set of certificate policy identifiers, further complicating the
       handling of multiple CAs by relying parties"

Hoping for a better 2004 with more mutual understanding

Anders R

----- Original Message ----- 
From: "Stephen Kent" <[e-mail]>
To: "Marc Poulaud" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, December 29, 2003 23:45
Subject: Re: IDPKC



At 16:29 +0000 12/16/03, Marc Poulaud wrote:
>Hi,
>
>Appreciating this a PKI group, I wanted to know if there is any knowledge
>of, or experience in IDPKC vs PKI. My intention is not to start a
>religious war, but just understand if there is anything approaching a
>consensus view. Also, does anybody know of any real/serious
>implementations of IDPKC. I'll take private emails, if people feel it's
>off topic.
>
>Marc.
>iSolve Ltd.

Marc,

Pardon this belated response.

One should put identity-based PKC (IDPKC) in perspective. The concept 
dates back to the mid-1980's when Adi Shamir first proposed the 
problem of deriving a key pair from an identifier, e.g., an e-mail 
address.  Several methods of doing this were developed over the next 
15 years, the most recent work is by Dan Boneh and his colleagues. It 
is arguably the most sophisticated from a crypto perspective, and the 
commercial, e-mail product based on their work also is the best in 
terms of solving some of the problems present in previous work. 
However, there are some limitations in all of these approaches, which 
I comment upon below.

First, in any large environment characterized by multiple 
administrative "domains," there is a need to have multiple CAs. No 
one CA will suffice to issue certs for all users. All IDPKC 
mechanisms rely on the ability of the sender of a message (I'll use 
the e-mail example here) to acquire some public values that are 
unique to the CA that serves the user to whom the mail is being sent. 
So, there has to be a way to securely acquire these public 
parameters, and to know which CA serves which users. This is 
generally equivalent to the problem of acquiring the right CA cert 
for the user. Only if the CAs align EXACTLY with the name space for 
the users would the problem be easier in the  IDPKC context. 
(Personally I would prefer such alignment, but in practice it rarely 
happens!) Note that this characteristic is essential, because  if one 
uses the wrong parameters, the e-mail will be decipherable by the CA 
whose parameters were used! So, in this part of the problem, it is 
not clear that IDPKC is a big win, because it would seem necessary, 
in general, to have some cert-like mechanism to securely distribute 
the CA public values, and to somehow bind each user to the CA that 
serves him/her.

Once one has the right set of parameters for the user in question, 
one can input the name of the user, e.g., his e-mail address, and 
generate the user's public key. but, this simple model does not work 
well, because it implies a need to change one's e-mail address to 
deal with compromise! So, IDPKC schemes have to add some parameter to 
the key generation process to accommodate the desire to keep the 
e-mail address constant while changing the key pair. The best 
solution I've seen for this problem (thanks for Boneh, et al.) is to 
use the current date as an additional input to the key generation 
process. This provides a very reasonable window for revocation, 
analogous to what one gets with daily CRL distribution, but without 
the need to push the CRLs or to contact OCSP servers on a daily basis.

Of course, there is no free lunch. The implication of the daily key 
pair change is that the users of a CA must receive new private keys 
from the CA on a daily basis, in order to be able to decipher 
incoming e-mail. One can argue about the magnitude of this problem, 
vs. the CRL and cert distribution problem. In the IDPKC case, one has 
to deliver private keys to all users served by a given CA daily, or 
allow these users to fetch the keys (for the current day and some set 
of prior days). These are private keys, so they need to be encrypted 
independently for each user. In a PKI, a CA has to make the certs and 
CRLs for its clients available to everyone who wants to communicate 
with the clients, presumably a much larger population.  But, the 
certs are generally fairly static (e.g., annual or biannual renewal) 
and the certs and CRLs are signed public info that can be stored 
anywhere. So it is hard to say which problem is easier to solve, and 
there may not be one answer for all contexts.

The CAs in an IDPKC act as key escrow agents, implicitly, and may 
have to hold onto private keys for at least a moderate period of 
time, to allow users to retrieve and decrypt mail that arrived when 
the users were away or otherwise unable to acquire new keys. In 
contrast, in a traditional PKI, a user may generate a key pair and 
never disclose the private key to anyone, even his CA. So there are 
significant differences in the security offered for private keys in 
these two models, especially if the PKI makes use of hardware crypto 
tokens that generate their own key pairs.

Finally, what about signatures? I have not looked at what Boneh 
proposed for signatures, but in general signature 
generation/validation pose opposite problems from 
encryption/decryption. A sender needs his private signature key to 
sign each message, and the receiver needs to be able to verify that 
the key is authentic and not-revoked. IDPKC does not seem to be so 
well suited to the signature verification problem. if signature keys 
are managed the same way as encryption keys, then every recipient of 
a signed message needs to acquire the current, public signature key 
for the sender, which imposes a serious burden on distributing these 
keys if one does not use certs. Also, if a signature key is 
discovered to have been compromised AFTER a recipient retrieved it, 
how does the recipient learn of this? With CRLs a CA can add an entry 
when a "late discovery compromise" occurs, and depending on when the 
signed data is processed, this late entry might suffice to warn the 
receiver.

So, overall, I am not convinced that IDPKC is a significant, 
practical technology, at least as it has been described so far.  It 
might prove useful in some contexts, but these contexts need to be 
carefully defined to permit a valid comparison with PKI technology.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTMlTib017667 for <[e-mail]>; Mon, 29 Dec 2003 14:47:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTMlTAL017666 for ietf-pkix-bks; Mon, 29 Dec 2003 14:47:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com ([128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTMlNib017649 for <[e-mail]>; Mon, 29 Dec 2003 14:47:23 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hBTMkfM9022305; Mon, 29 Dec 2003 17:46:42 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020404bc1653dc01c8@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 29 Dec 2003 17:45:26 -0500
To: "Marc Poulaud" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: IDPKC
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 16:29 +0000 12/16/03, Marc Poulaud wrote:
>Hi,
>
>Appreciating this a PKI group, I wanted to know if there is any knowledge
>of, or experience in IDPKC vs PKI. My intention is not to start a
>religious war, but just understand if there is anything approaching a
>consensus view. Also, does anybody know of any real/serious
>implementations of IDPKC. I'll take private emails, if people feel it's
>off topic.
>
>Marc.
>iSolve Ltd.

Marc,

Pardon this belated response.

One should put identity-based PKC (IDPKC) in perspective. The concept 
dates back to the mid-1980's when Adi Shamir first proposed the 
problem of deriving a key pair from an identifier, e.g., an e-mail 
address.  Several methods of doing this were developed over the next 
15 years, the most recent work is by Dan Boneh and his colleagues. It 
is arguably the most sophisticated from a crypto perspective, and the 
commercial, e-mail product based on their work also is the best in 
terms of solving some of the problems present in previous work. 
However, there are some limitations in all of these approaches, which 
I comment upon below.

First, in any large environment characterized by multiple 
administrative "domains," there is a need to have multiple CAs. No 
one CA will suffice to issue certs for all users. All IDPKC 
mechanisms rely on the ability of the sender of a message (I'll use 
the e-mail example here) to acquire some public values that are 
unique to the CA that serves the user to whom the mail is being sent. 
So, there has to be a way to securely acquire these public 
parameters, and to know which CA serves which users. This is 
generally equivalent to the problem of acquiring the right CA cert 
for the user. Only if the CAs align EXACTLY with the name space for 
the users would the problem be easier in the  IDPKC context. 
(Personally I would prefer such alignment, but in practice it rarely 
happens!) Note that this characteristic is essential, because  if one 
uses the wrong parameters, the e-mail will be decipherable by the CA 
whose parameters were used! So, in this part of the problem, it is 
not clear that IDPKC is a big win, because it would seem necessary, 
in general, to have some cert-like mechanism to securely distribute 
the CA public values, and to somehow bind each user to the CA that 
serves him/her.

Once one has the right set of parameters for the user in question, 
one can input the name of the user, e.g., his e-mail address, and 
generate the user's public key. but, this simple model does not work 
well, because it implies a need to change one's e-mail address to 
deal with compromise! So, IDPKC schemes have to add some parameter to 
the key generation process to accommodate the desire to keep the 
e-mail address constant while changing the key pair. The best 
solution I've seen for this problem (thanks for Boneh, et al.) is to 
use the current date as an additional input to the key generation 
process. This provides a very reasonable window for revocation, 
analogous to what one gets with daily CRL distribution, but without 
the need to push the CRLs or to contact OCSP servers on a daily basis.

Of course, there is no free lunch. The implication of the daily key 
pair change is that the users of a CA must receive new private keys 
from the CA on a daily basis, in order to be able to decipher 
incoming e-mail. One can argue about the magnitude of this problem, 
vs. the CRL and cert distribution problem. In the IDPKC case, one has 
to deliver private keys to all users served by a given CA daily, or 
allow these users to fetch the keys (for the current day and some set 
of prior days). These are private keys, so they need to be encrypted 
independently for each user. In a PKI, a CA has to make the certs and 
CRLs for its clients available to everyone who wants to communicate 
with the clients, presumably a much larger population.  But, the 
certs are generally fairly static (e.g., annual or biannual renewal) 
and the certs and CRLs are signed public info that can be stored 
anywhere. So it is hard to say which problem is easier to solve, and 
there may not be one answer for all contexts.

The CAs in an IDPKC act as key escrow agents, implicitly, and may 
have to hold onto private keys for at least a moderate period of 
time, to allow users to retrieve and decrypt mail that arrived when 
the users were away or otherwise unable to acquire new keys. In 
contrast, in a traditional PKI, a user may generate a key pair and 
never disclose the private key to anyone, even his CA. So there are 
significant differences in the security offered for private keys in 
these two models, especially if the PKI makes use of hardware crypto 
tokens that generate their own key pairs.

Finally, what about signatures? I have not looked at what Boneh 
proposed for signatures, but in general signature 
generation/validation pose opposite problems from 
encryption/decryption. A sender needs his private signature key to 
sign each message, and the receiver needs to be able to verify that 
the key is authentic and not-revoked. IDPKC does not seem to be so 
well suited to the signature verification problem. if signature keys 
are managed the same way as encryption keys, then every recipient of 
a signed message needs to acquire the current, public signature key 
for the sender, which imposes a serious burden on distributing these 
keys if one does not use certs. Also, if a signature key is 
discovered to have been compromised AFTER a recipient retrieved it, 
how does the recipient learn of this? With CRLs a CA can add an entry 
when a "late discovery compromise" occurs, and depending on when the 
signed data is processed, this late entry might suffice to warn the 
receiver.

So, overall, I am not convinced that IDPKC is a significant, 
practical technology, at least as it has been described so far.  It 
might prove useful in some contexts, but these contexts need to be 
carefully defined to permit a valid comparison with PKI technology.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNKiXib054876 for <[e-mail]>; Tue, 23 Dec 2003 12:44:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNKiXox054875 for ietf-pkix-bks; Tue, 23 Dec 2003 12:44:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBNKiWib054818 for <[e-mail]>; Tue, 23 Dec 2003 12:44:32 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 27668 invoked by uid 0); 23 Dec 2003 20:44:24 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.18.193) by woodstock.binhost.com with SMTP; 23 Dec 2003 20:44:24 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 23 Dec 2003 15:44:17 -0500
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: RFC3039bis last call ?
Cc: [e-mail]
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>

Denis:

>>RFC 3039 is a profile of RFC 3280 so we reference it.
>
>We all know that the key usage section in RFC 3280 has a problem and needs 
>to be fixed.

I guess this discussion will never end.  There has been a very long thread 
on this point, and I take offense at your characterization of that 
thread.  Given the volume of messages on the thread, your statement that 
"we all know" is just plain misleading.

My personal conclusion from that very long thread is that the RFC 3280 text 
has the consensus of the working group.  There is clearly not unanimous 
agreement with it.  We all know that you do not agree with it.

Last June, I posted a message that recommended an update to RFC 3280.  (See 
http://www.imc.org/ietf-pkix/mail-archive/msg06188.html )  One of the three 
reasons for an update is to ensure alignment of the IETF and the ITU-T 
specifications with respect to key usage.  Based on my reading of the most 
recent ITU-T language, I suggest that no changes are needed in this 
area.  The biggest change is the name of the bit, which in my opinion will 
not lead to clarity.  It may, however, help satisfy some issues raised in 
the legal community.

Russ





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNKZqib053932 for <[e-mail]>; Tue, 23 Dec 2003 12:35:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNKZqvP053931 for ietf-pkix-bks; Tue, 23 Dec 2003 12:35:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNKZiib053909 for <[e-mail]>; Tue, 23 Dec 2003 12:35:44 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08070; Tue, 23 Dec 2003 15:35:29 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-10.txt
Date: Tue, 23 Dec 2003 15:35:28 -0500
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 Proxy Certificate Profile
	Author(s)	: S. Tuecke
	Filename	: draft-ietf-pkix-proxy-10.txt
	Pages		: 48
	Date		: 2003-12-23
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 Public Key Infrastructure (PKI) certificates as 
defined in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is derived from, 
and signed by, a normal X.509 Public Key End Entity Certificate or 
by another Proxy Certificate for the purpose of providing 
restricted proxying and delegation within a PKI based 
authentication system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-10.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-proxy-10.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-proxy-10.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-proxy-10.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNKZjib053924 for <[e-mail]>; Tue, 23 Dec 2003 12:35:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNKZjNZ053920 for ietf-pkix-bks; Tue, 23 Dec 2003 12:35:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNKZiib053908 for <[e-mail]>; Tue, 23 Dec 2003 12:35:44 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08086; Tue, 23 Dec 2003 15:35:34 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-10.txt
Date: Tue, 23 Dec 2003 15:35:34 -0500
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 Proxy Certificate Profile
	Author(s)	: S. Tuecke
	Filename	: draft-ietf-pkix-proxy-10.txt
	Pages		: 48
	Date		: 2003-12-23
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 Public Key Infrastructure (PKI) certificates as 
defined in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is derived from, 
and signed by, a normal X.509 Public Key End Entity Certificate or 
by another Proxy Certificate for the purpose of providing 
restricted proxying and delegation within a PKI based 
authentication system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-10.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-proxy-10.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-proxy-10.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-proxy-10.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNJw3ib052363 for <[e-mail]>; Tue, 23 Dec 2003 11:58:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNJw3r9052362 for ietf-pkix-bks; Tue, 23 Dec 2003 11:58:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNJw1ib052354 for <[e-mail]>; Tue, 23 Dec 2003 11:58:01 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Dec 2003 19:57:57 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Dec 2003 19:57:57 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Dec 2003 19:57:57 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RFC3039bis last call ?
Date: Tue, 23 Dec 2003 19:57:39 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC3039bis last call ?
Thread-Index: AcPJdZcQ/iOOnbRtQce1LCfMN+ayGAAFokog
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 23 Dec 2003 19:57:57.0348 (UTC) FILETIME=[0F772A40:01C3C98F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBNJw2ib052358
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-line.

/Stefan
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 23 december 2003 16:18
> To: Stefan Santesson
> Cc: [e-mail]
> Subject: Re: RFC3039bis last call ?
> 
> 
> > Denis,
> >
> > I have replied to these comments before and these were also
discussed at
> > the IETF meeting and concluded.
> >
> > Name:
> > ------
> > The scope is the same but it is just worded a bit different. This
> > profile has never limited itself to just Qualified Certificate, i.e.
> > this profile defines the framework that is considered useful for
> > Qualified Certificate but the use of the profile is not limited to
> > Qualified Certificates. It can be used to create or support also
other
> > type of certificates. This was also clearly stated in RFC 3039.
> 
> "Qualified Certificate" has two meanings. Two meaning for the same
acronym
> is confusing. We should not perpetrate confusion.

The use of the term Qualified Certificates is well defined in RFC 3039.

> 
> > The reason for the wording change in the abstract was that many
readers
> > had missed the fact that this profile can be used to support any
> > ID-certificate, qualified or not. Example of such use could be use
of
> > the bimetricInfo extension for attaching picture.
> >
> > The meeting, the WG chairs and the Security AD agreed that the name
of
> > the document should be kept. I don't feel strongly either way but I
> > respect that decision and think it is the best one.
> 
> I believe that RFC 3039 should be kept as it is.
> 
> If you believe that additions are neeed, then I have no objection in
> principle for a new document.

I guess we have to agree to disagree. We ARE in a process to update this
document. I'm open to hear any input from you in this process. If you
disagree to the process as such then this is an issue between you and WG
chairs.

> 
> > Requirement from ETSI:
> > ----------------------
> > There is a need to harmonize development of ETSI TS 102 280 with RFC
> > 3039. This has also been expressed in circulated ETSI documents, but
> > there are also other reasons to update RFC 3039.
> 
> This is wrong.
> 

I know you think so, but do you have any arguments to present?

> There may be a need to revise ETSI TS 102 280, but there is no need to
> revise RFC 3039, as far as ETSI is concerned.

Revise TS 102 280?? It isn't written yet. 

> 
> > Replacement of RFC 3039:
> > ------------------------
> > As concluded at last IETF it is impossible to update RFC 3039 and
keep
> > RFC 3039. It would cause several extensions to be defined in
multiple
> > RFCs.
> 
> If we keep RFC 3039 as it is and have a new document, I don't see what
the
> problem is. Please elaborate your argumentation.

RFC 3039 defines 2 new extensions and some new attributes. We can't
create e new document that is living in parallel that defines the same
extensions one more time.

> 
> > Reference to RFC 3280
> > ---------------------
> > RFC 3039 is a profile of RFC 3280 so we reference it.
> 
> We all know that the key usage section in RFC 3280 has a problem and
needs
> to be fixed.
> 
> The text of RFC 3039 should stay as it is.

I know you think so, but why.

The only thing is said was that if NR is set it SHOULD be set
exclusively.
This statement has no context in RFC 3039 and is thus bad and prevents
deployment. This has however a context in TS 102280 where it is to be
found instead of here.

Note that RFC 3039 allows both encryption as well as DS to be set.

Note also that it is YOU who promotes a definition of the DS bit that
will force many CAs to issue certificates with both DS and NR set,
because that will be the only way to allow a single signing certificate
to be used for arbitrary signing operations, regardless of purpose.

I argue for a DS bit (according to RFC 3280) that has no limitations of
usage of DS, to allow an environment with a single certificate for
signing to have only DS set. Then we MAY be able to avoid NR+DS
certificates, which actually would be a good thing.

But as it is now, RFC 3039 have no context to say that this is an
invalid combination in general. We could though add a section in the
security considerations section highlighting threats that may arise due
to this combination.

> 
> > If you have any problem with this that is an issue you have to take
up
> > with the WG chairs or Russ as AD. As far as I'm concerned RFC 3039
does
> > not define any meanings of the key usage bits and thus should not be
> > dependent on any resolution of that.
> 
> The current text contains text which should not be deleted.
> 
> > Finally there is nothing in any definition of Qualified Certificates
> > that prevents such certificates from being used for Authentication.
> 
>   ... which is precisely why the text on the key usage section should
be
> kept.

As I said, there is nothing in the old text that prevents or even
recommends against this.

> 
> Denis
> 
> > /Stefan
> >
> >
> >>-----Original Message-----
> >>From: [e-mail]
> >
> > [mailto:[e-mail]]
> >
> >>On Behalf Of Denis Pinkas
> >>Sent: den 4 december 2003 21:08
> >>To: [e-mail]
> >>Subject: RFC3039bis last call ?
> >>
> >>
> >>
> >>I probably missed the e-mail about an RFC3039bis last call, but
since
> >
> > it
> >
> >>is mentioned in the WG minutes that there will be a last call. In
case
> >>it is already going, I would like to reiterate that the concerns I
> >>raised before the Minneapolis meeting are still valid.
> >>
> >>In particular, I would like to reinsist on two points:
> >>
> >>RFC3039 states in the abstract:
> >>
> >>This document forms a certificate profile for Qualified
Certificates,
> >>based on RFC 2459, for use in the Internet. The term Qualified
> >>Certificate is used to describe a certificate with a certain
> >>qualified status within applicable governing law.
> >>
> >>RFC3039bis states in the abstract:
> >>
> >>This document forms a certificate profile, based on RFC 3280, for
> >>identity certificates issued to physical persons.
> >>
> >>It is clear from the abstract that the topic of the two documents
are
> >>different and that the new draft should be renamed: Identity
> >>Certificates Profile.
> >>
> >>As a consequence, this new draft is NOT a replacement for RFC 3039.
> >
> > One
> >
> >>argument has been that ETSI needed changes to RFC 3039. There is not
> >>such a requirement from ETSI.
> >>
> >>Another major issue is that RFC3039bis states:
> >>
> >>Key usage settings SHALL be set in accordance with RFC 3280
> >
> > definitions.
> >
> >>We know that the key usage bit section of RFC 3280 is going to be
> >>changed. However we still don't know what will be the new text.
> >>Discussions are going on within ISO SC6 both to redefine bit 0 in
> >
> > terms
> >
> >>of the security services it may support (instead of saying "all
> >
> > security
> >
> >>services except one security service"), and to rename bit 1. This
> >
> > means
> >
> >>that referencing RFC 3280 is fine, except for the section on the key
> >>usage bits.
> >>
> >>Qualified Certificates are to be used when a signer wants to commit
to
> >>the content of a document, not when a signer wants to authenticate.
As
> >>it is, the new draft would create confusion.
> >>
> >>Denis
> >>
> >>
> >>
> >
> >
> >
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNJUSib051352 for <[e-mail]>; Tue, 23 Dec 2003 11:30:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNJUSDV051351 for ietf-pkix-bks; Tue, 23 Dec 2003 11:30:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-lul.microsoft.com (mail-lul.microsoft.com [212.157.154.44]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNJUPib051343 for <[e-mail]>; Tue, 23 Dec 2003 11:30:26 -0800 (PST) (envelope-from [e-mail])
Received: from lul-imc-01.europe.corp.microsoft.com ([65.53.188.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 23 Dec 2003 20:30:24 +0100
Received: from 65.53.188.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Dec 2003 20:30:24 +0100
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 23 Dec 2003 20:30:24 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Summary RE: Last Call: Qualified Certificates
Date: Tue, 23 Dec 2003 19:29:50 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Summary RE: Last Call: Qualified Certificates
Thread-Index: AcPJdpD6a0UJOjrVTTqHNqmCTkH7hQAFBAeA
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 23 Dec 2003 19:30:24.0617 (UTC) FILETIME=[365C6D90:01C3C98B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBNJUQib051346
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>

Great,

Then we agree to the point that we should keep RFC 3039 as it is with
regard to this extension.

I guess you are free to ask the WG chairs for permission to start a new
work item for those new extensions.

/Stefan
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 23 december 2003 16:26
> To: Stefan Santesson; pkix
> Subject: Re: Summary RE: Last Call: Qualified Certificates
> 
> 
> Stefan,
> 
> > Denis,
> >
> > I understand your request but I don't agree with your conclusion.
> >
> > I can see the possibilities with a scheme with more tight definition
of
> > criticality since it would enable the ability to force acceptance of
a
> > certain statement while another informative statement could be
ignored.
> >
> > However, I think the cost of providing that capability is too high
> > compared to both the benefits and the demand for it. And this is not
the
> > only extension where you have the same type of issue.
> >
> > Similar problem can be associated with:
> > - Subject and issuer alt name
> > - Certificate policies
> > - Extended Key usage
> >
> > All of these may contain multiple instances of OID defined
properties
> > where I may want to assign different "must recognize" properties.
> >
> > This is a generic limitation of X.509 extension structure and not
unique
> > for qcStataments.
> 
> I do not agree with your interpretation.
> 
> The main idea beyond the criticality bit is the following: either it
is
> critical and the RP must understand all the content of the extension,
or
> it
> is non critical and then the RP is free to ignore if it cannot
interpret
> it.
> 
> The QCstatement extension does not allow a mixture on critical and non
> critical individual QCstatements.
> 
> What I am requesting for is :
> 
>   1 - to keep the QCStatement extension in RFC 3039 as it is and,
>   2 - to define in a new document (which does not superseed RFC 3039)
>       two new extensions:
>         a) one which is always critical to include critical
statements,
>            and,
>         b) one which is always non-critical to include non-critical
>            statements.
> 
> Denis
> 
> > /Stefan
> >
> >
> >
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[e-mail]]
> >>Sent: den 22 december 2003 12:19
> >>To: Stefan Santesson
> >>Subject: Re: Summary RE: Last Call: Qualified Certificates
> >>
> >>Stefan,
> >>
> >>I have not yet seen your response to my comments.
> >>Here is an additional comment:
> >>
> >>RFC 3039 states :
> >>
> >>"3.2.5  Qualified Certificate Statements
> >>
> >>(...)
> >>
> >>    This extension may be critical or non-critical.  If the
extension
> >
> > is
> >
> >>    critical, this means that all statements included in the
extension
> >>    are regarded as critical.
> >>
> >>       qcStatements  EXTENSION ::= {
> >>           SYNTAX             QCStatements
> >>           IDENTIFIED BY      id-pe-qcStatements }
> >>
> >>       id-pe-qcStatements     OBJECT IDENTIFIER ::= { id-pe 3 }
> >>
> >>       QCStatements ::= SEQUENCE OF QCStatement "
> >>
> >>
> >>Since at this time this extension has only be used for one
statement,
> >>there
> >>is no problem. However, in the future it is desirable to allow to
> >
> > include
> >
> >>one or more statements, some of them being critical and some other
> >
> > being
> >
> >>non-critical. This extension is unable to support this feature.
> >>
> >>It is impossible to redefine this extension with a new semantics so
> >>thisdefine a  extension has to stay as it is, but there is a need to
> >
> > allow
> >
> >>this flexibility.
> >>
> >>There are two possibilities:
> >>
> >>1) define two extensions, one being always critical and the other
one
> >>being
> >>always non critical. All critical statements would be in the first
> >>extension
> >>while all non critical statements would be in the other one.
> >>
> >>2) define a new extension allowing to mix both critical and non
> >
> > critical
> >
> >>statements. In case this second option is followed, hereafter is how
> >
> > such
> >
> >>a
> >>new extension would look like:
> >>
> >>"Identity Certificate Statements
> >>
> >>    This extension may be critical or non-critical.  If the
extension
> >
> > is
> >
> >>    critical, this means that every statement included in the
> >
> > extension
> >
> >>and
> >>    individually marked critical MUST be understood.
> >>
> >>       icStatements  EXTENSION ::= {
> >>           SYNTAX             QCStatements
> >>           IDENTIFIED BY      id-pe-icStatements }
> >>
> >>       id-pe-icStatements     OBJECT IDENTIFIER ::= { id-pe 4 }
> >>
> >>       ICStatements ::= SEQUENCE OF ICStatement "
> >>
> >>       ICStatement ::= SEQUENCE {
> >>           critical      BOOLEAN DEFAULT FALSE
> >>           statementId   IC-STATEMENT.&Id({SupportedStatements}),
> >>           statementInfo IC-STATEMENT.&Type
> >>           ({SupportedStatements}{@statementId}) OPTIONAL }
> >>
> >>       SupportedStatements IC-STATEMENT ::= { icStatement-1,...} "
> >>
> >>
> >>Once again, it makes sense to define a NEW RFC dedicated to
"Identity
> >>Certificates for physical persons", but it still does not make sense
> >
> > to
> >
> >>replace RFC 3039.
> >>
> >>Denis
> >
> >
> >
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNFxJib020375 for <[e-mail]>; Tue, 23 Dec 2003 07:59:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNFxJhL020373 for ietf-pkix-bks; Tue, 23 Dec 2003 07:59:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com ([128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNFxIib020336 for <[e-mail]>; Tue, 23 Dec 2003 07:59:18 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hBNFwRM9004649; Tue, 23 Dec 2003 10:58:27 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a06020401bc0e159e2196@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References:  <[e-mail].c om> <[e-mail]>
Date: Tue, 23 Dec 2003 10:55:54 -0500
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Summary RE: Last Call: Qualified Certificates
Cc: Stefan Santesson <[e-mail]>, pkix <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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,

I think the WG has endorsed revisions to 3039, not creation of a new 
RFC. So, we can debate issues within the new document, but let's not 
not debate whether the new document replaces 3039.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNFQ2ib016323 for <[e-mail]>; Tue, 23 Dec 2003 07:26:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNFQ2fA016322 for ietf-pkix-bks; Tue, 23 Dec 2003 07:26:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNFQ1ib016306 for <[e-mail]>; Tue, 23 Dec 2003 07:26:01 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA42918; Tue, 23 Dec 2003 16:33:01 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id RAA31199; Tue, 23 Dec 2003 17:20:40 +0100
Message-ID: <[e-mail]>
Date: Tue, 23 Dec 2003 16:26:01 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>, pkix <[e-mail]>
Subject: Re: Summary RE: Last Call: Qualified Certificates
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>

Stefan,

> Denis,
> 
> I understand your request but I don't agree with your conclusion.
> 
> I can see the possibilities with a scheme with more tight definition of
> criticality since it would enable the ability to force acceptance of a
> certain statement while another informative statement could be ignored.
> 
> However, I think the cost of providing that capability is too high
> compared to both the benefits and the demand for it. And this is not the
> only extension where you have the same type of issue.
> 
> Similar problem can be associated with:
> - Subject and issuer alt name
> - Certificate policies
> - Extended Key usage
> 
> All of these may contain multiple instances of OID defined properties
> where I may want to assign different "must recognize" properties.
> 
> This is a generic limitation of X.509 extension structure and not unique
> for qcStataments.

I do not agree with your interpretation.

The main idea beyond the criticality bit is the following: either it is 
critical and the RP must understand all the content of the extension, or it 
is non critical and then the RP is free to ignore if it cannot interpret it.

The QCstatement extension does not allow a mixture on critical and non 
critical individual QCstatements.

What I am requesting for is :

  1 - to keep the QCStatement extension in RFC 3039 as it is and,
  2 - to define in a new document (which does not superseed RFC 3039)
      two new extensions:
        a) one which is always critical to include critical statements,
           and,
        b) one which is always non-critical to include non-critical
           statements.

Denis

> /Stefan
>  
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: den 22 december 2003 12:19
>>To: Stefan Santesson
>>Subject: Re: Summary RE: Last Call: Qualified Certificates
>>
>>Stefan,
>>
>>I have not yet seen your response to my comments.
>>Here is an additional comment:
>>
>>RFC 3039 states :
>>
>>"3.2.5  Qualified Certificate Statements
>>
>>(...)
>>
>>    This extension may be critical or non-critical.  If the extension
> 
> is
> 
>>    critical, this means that all statements included in the extension
>>    are regarded as critical.
>>
>>       qcStatements  EXTENSION ::= {
>>           SYNTAX             QCStatements
>>           IDENTIFIED BY      id-pe-qcStatements }
>>
>>       id-pe-qcStatements     OBJECT IDENTIFIER ::= { id-pe 3 }
>>
>>       QCStatements ::= SEQUENCE OF QCStatement "
>>
>>
>>Since at this time this extension has only be used for one statement,
>>there
>>is no problem. However, in the future it is desirable to allow to
> 
> include
> 
>>one or more statements, some of them being critical and some other
> 
> being
> 
>>non-critical. This extension is unable to support this feature.
>>
>>It is impossible to redefine this extension with a new semantics so
>>thisdefine a  extension has to stay as it is, but there is a need to
> 
> allow
> 
>>this flexibility.
>>
>>There are two possibilities:
>>
>>1) define two extensions, one being always critical and the other one
>>being
>>always non critical. All critical statements would be in the first
>>extension
>>while all non critical statements would be in the other one.
>>
>>2) define a new extension allowing to mix both critical and non
> 
> critical
> 
>>statements. In case this second option is followed, hereafter is how
> 
> such
> 
>>a
>>new extension would look like:
>>
>>"Identity Certificate Statements
>>
>>    This extension may be critical or non-critical.  If the extension
> 
> is
> 
>>    critical, this means that every statement included in the
> 
> extension
> 
>>and
>>    individually marked critical MUST be understood.
>>
>>       icStatements  EXTENSION ::= {
>>           SYNTAX             QCStatements
>>           IDENTIFIED BY      id-pe-icStatements }
>>
>>       id-pe-icStatements     OBJECT IDENTIFIER ::= { id-pe 4 }
>>
>>       ICStatements ::= SEQUENCE OF ICStatement "
>>
>>       ICStatement ::= SEQUENCE {
>>           critical      BOOLEAN DEFAULT FALSE
>>           statementId   IC-STATEMENT.&Id({SupportedStatements}),
>>           statementInfo IC-STATEMENT.&Type
>>           ({SupportedStatements}{@statementId}) OPTIONAL }
>>
>>       SupportedStatements IC-STATEMENT ::= { icStatement-1,...} "
>>
>>
>>Once again, it makes sense to define a NEW RFC dedicated to "Identity
>>Certificates for physical persons", but it still does not make sense
> 
> to
> 
>>replace RFC 3039.
>>
>>Denis
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNFHgib015390 for <[e-mail]>; Tue, 23 Dec 2003 07:17:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNFHgqe015388 for ietf-pkix-bks; Tue, 23 Dec 2003 07:17:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNFHfib015375 for <[e-mail]>; Tue, 23 Dec 2003 07:17:41 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA41100; Tue, 23 Dec 2003 16:24:40 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id RAA31171; Tue, 23 Dec 2003 17:12:20 +0100
Message-ID: <[e-mail]>
Date: Tue, 23 Dec 2003 16:17:40 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: RFC3039bis last call ?
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>

> Denis,
> 
> I have replied to these comments before and these were also discussed at
> the IETF meeting and concluded.
> 
> Name:
> ------
> The scope is the same but it is just worded a bit different. This
> profile has never limited itself to just Qualified Certificate, i.e.
> this profile defines the framework that is considered useful for
> Qualified Certificate but the use of the profile is not limited to
> Qualified Certificates. It can be used to create or support also other
> type of certificates. This was also clearly stated in RFC 3039.

"Qualified Certificate" has two meanings. Two meaning for the same acronym 
is confusing. We should not perpetrate confusion.

> The reason for the wording change in the abstract was that many readers
> had missed the fact that this profile can be used to support any
> ID-certificate, qualified or not. Example of such use could be use of
> the bimetricInfo extension for attaching picture.
> 
> The meeting, the WG chairs and the Security AD agreed that the name of
> the document should be kept. I don't feel strongly either way but I
> respect that decision and think it is the best one.

I believe that RFC 3039 should be kept as it is.

If you believe that additions are neeed, then I have no objection in 
principle for a new document.

> Requirement from ETSI:
> ----------------------
> There is a need to harmonize development of ETSI TS 102 280 with RFC
> 3039. This has also been expressed in circulated ETSI documents, but
> there are also other reasons to update RFC 3039.

This is wrong.

There may be a need to revise ETSI TS 102 280, but there is no need to 
revise RFC 3039, as far as ETSI is concerned.

> Replacement of RFC 3039:
> ------------------------
> As concluded at last IETF it is impossible to update RFC 3039 and keep
> RFC 3039. It would cause several extensions to be defined in multiple
> RFCs.

If we keep RFC 3039 as it is and have a new document, I don't see what the 
problem is. Please elaborate your argumentation.

> Reference to RFC 3280
> ---------------------
> RFC 3039 is a profile of RFC 3280 so we reference it.

We all know that the key usage section in RFC 3280 has a problem and needs 
to be fixed.

The text of RFC 3039 should stay as it is.

> If you have any problem with this that is an issue you have to take up
> with the WG chairs or Russ as AD. As far as I'm concerned RFC 3039 does
> not define any meanings of the key usage bits and thus should not be
> dependent on any resolution of that.

The current text contains text which should not be deleted.

> Finally there is nothing in any definition of Qualified Certificates
> that prevents such certificates from being used for Authentication.

  ... which is precisely why the text on the key usage section should be kept.

Denis

> /Stefan
>  
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 4 december 2003 21:08
>>To: [e-mail]
>>Subject: RFC3039bis last call ?
>>
>>
>>
>>I probably missed the e-mail about an RFC3039bis last call, but since
> 
> it
> 
>>is mentioned in the WG minutes that there will be a last call. In case
>>it is already going, I would like to reiterate that the concerns I
>>raised before the Minneapolis meeting are still valid.
>>
>>In particular, I would like to reinsist on two points:
>>
>>RFC3039 states in the abstract:
>>
>>This document forms a certificate profile for Qualified Certificates,
>>based on RFC 2459, for use in the Internet. The term Qualified
>>Certificate is used to describe a certificate with a certain
>>qualified status within applicable governing law.
>>
>>RFC3039bis states in the abstract:
>>
>>This document forms a certificate profile, based on RFC 3280, for
>>identity certificates issued to physical persons.
>>
>>It is clear from the abstract that the topic of the two documents are
>>different and that the new draft should be renamed: Identity
>>Certificates Profile.
>>
>>As a consequence, this new draft is NOT a replacement for RFC 3039.
> 
> One
> 
>>argument has been that ETSI needed changes to RFC 3039. There is not
>>such a requirement from ETSI.
>>
>>Another major issue is that RFC3039bis states:
>>
>>Key usage settings SHALL be set in accordance with RFC 3280
> 
> definitions.
> 
>>We know that the key usage bit section of RFC 3280 is going to be
>>changed. However we still don't know what will be the new text.
>>Discussions are going on within ISO SC6 both to redefine bit 0 in
> 
> terms
> 
>>of the security services it may support (instead of saying "all
> 
> security
> 
>>services except one security service"), and to rename bit 1. This
> 
> means
> 
>>that referencing RFC 3280 is fine, except for the section on the key
>>usage bits.
>>
>>Qualified Certificates are to be used when a signer wants to commit to
>>the content of a document, not when a signer wants to authenticate. As
>>it is, the new draft would create confusion.
>>
>>Denis
>>
>>
>>
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNA2xib068018 for <[e-mail]>; Tue, 23 Dec 2003 02:02:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNA2xI8068017 for ietf-pkix-bks; Tue, 23 Dec 2003 02:02:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNA2tib067988 for <[e-mail]>; Tue, 23 Dec 2003 02:02:56 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Dec 2003 10:02:46 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Dec 2003 10:02:46 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Dec 2003 10:02:46 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RFC3039bis last call ?
Date: Tue, 23 Dec 2003 10:01:45 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC3039bis last call ?
Thread-Index: AcO6r+1M+hUri19hR46Yubb7EavQlQOiNVOQ
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 23 Dec 2003 10:02:46.0098 (UTC) FILETIME=[E9E6DB20:01C3C93B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBNA2vib068009
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,

I have replied to these comments before and these were also discussed at
the IETF meeting and concluded.

Name:
------
The scope is the same but it is just worded a bit different. This
profile has never limited itself to just Qualified Certificate, i.e.
this profile defines the framework that is considered useful for
Qualified Certificate but the use of the profile is not limited to
Qualified Certificates. It can be used to create or support also other
type of certificates. This was also clearly stated in RFC 3039.

The reason for the wording change in the abstract was that many readers
had missed the fact that this profile can be used to support any
ID-certificate, qualified or not. Example of such use could be use of
the bimetricInfo extension for attaching picture.

The meeting, the WG chairs and the Security AD agreed that the name of
the document should be kept. I don't feel strongly either way but I
respect that decision and think it is the best one.

Requirement from ETSI:
----------------------
There is a need to harmonize development of ETSI TS 102 280 with RFC
3039. This has also been expressed in circulated ETSI documents, but
there are also other reasons to update RFC 3039.

Replacement of RFC 3039:
------------------------
As concluded at last IETF it is impossible to update RFC 3039 and keep
RFC 3039. It would cause several extensions to be defined in multiple
RFCs.

Reference to RFC 3280
---------------------
RFC 3039 is a profile of RFC 3280 so we reference it.
If you have any problem with this that is an issue you have to take up
with the WG chairs or Russ as AD. As far as I'm concerned RFC 3039 does
not define any meanings of the key usage bits and thus should not be
dependent on any resolution of that.

Finally there is nothing in any definition of Qualified Certificates
that prevents such certificates from being used for Authentication.

/Stefan
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 4 december 2003 21:08
> To: [e-mail]
> Subject: RFC3039bis last call ?
> 
> 
> 
> I probably missed the e-mail about an RFC3039bis last call, but since
it
> is mentioned in the WG minutes that there will be a last call. In case
> it is already going, I would like to reiterate that the concerns I
> raised before the Minneapolis meeting are still valid.
> 
> In particular, I would like to reinsist on two points:
> 
> RFC3039 states in the abstract:
> 
> This document forms a certificate profile for Qualified Certificates,
> based on RFC 2459, for use in the Internet. The term Qualified
> Certificate is used to describe a certificate with a certain
> qualified status within applicable governing law.
> 
> RFC3039bis states in the abstract:
> 
> This document forms a certificate profile, based on RFC 3280, for
> identity certificates issued to physical persons.
> 
> It is clear from the abstract that the topic of the two documents are
> different and that the new draft should be renamed: Identity
> Certificates Profile.
> 
> As a consequence, this new draft is NOT a replacement for RFC 3039.
One
> argument has been that ETSI needed changes to RFC 3039. There is not
> such a requirement from ETSI.
> 
> Another major issue is that RFC3039bis states:
> 
> Key usage settings SHALL be set in accordance with RFC 3280
definitions.
> 
> We know that the key usage bit section of RFC 3280 is going to be
> changed. However we still don't know what will be the new text.
> Discussions are going on within ISO SC6 both to redefine bit 0 in
terms
> of the security services it may support (instead of saying "all
security
> services except one security service"), and to rename bit 1. This
means
> that referencing RFC 3280 is fine, except for the section on the key
> usage bits.
> 
> Qualified Certificates are to be used when a signer wants to commit to
> the content of a document, not when a signer wants to authenticate. As
> it is, the new draft would create confusion.
> 
> Denis
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJEejib053080 for <[e-mail]>; Fri, 19 Dec 2003 06:40:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBJEejGP053079 for ietf-pkix-bks; Fri, 19 Dec 2003 06:40:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJEehib053069 for <[e-mail]>; Fri, 19 Dec 2003 06:40:44 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Dec 2003 14:40:39 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 19 Dec 2003 14:40:39 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Dec 2003 14:40:39 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Summary RE: Last Call: Qualified Certificates
Date: Fri, 19 Dec 2003 14:40:33 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Summary RE: Last Call: Qualified Certificates
Thread-Index: AcOpWeAvu40TVwStQ5q0olJdw3pUXAc3EhGQ
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>, "Tim Polk" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 19 Dec 2003 14:40:39.0455 (UTC) FILETIME=[12583AF0:01C3C63E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBJEeiib053074
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 try to summarize the issues and their resolution to see if we all can
live with this. I exclude the typo remarks.

Issue 1: use of term "Private extensions"
Resolution: We will change and just talk about extensions

Issue 2: Exclude ASN.1 other than ASN.1 in 1988 syntax.
Resolution: We will keep the 1997 syntax as informative, as approved by
Russ.

Issue 3: New section stating changes from RFC 3039
Resolution: Section will be added


Issue 4: Defining granularity of Date of birth

Resolution: We conclude that the best solution would have been if we
just defined a raw text format from the beginning, independent of
GenerelizedTime. That is to late now though, since this attribute
already in use. The problem is that display of a date specified in this
format may be changed to another date due to adjustments for timezones.
The only time that will cause the same date display regardless of
timezone is 12.00.00 GMT. We will therefore recommend the time to be set
to 12.00.00 including second. We also recommend that clients parsing
this attribute should ignore any time data and display just the date
without any adjustment for local time zone.


Issue 5: countryOfResidence and countryOfCitizenship. Multi valued
attributes or Multipple occurance of single valued attributes or
requirement to include just 1 value in a certificate.

Resolution: We don't want to restrict to 1 country value for any of
these attributes. Neither do we want to forbid any variant to include
multiple countries. We do however want to RECOMMEND attribute values to
be repeated as multiple occurrences of single valued attributes, if more
than one value is to be included.


Issue 6: What is hashed in a graphic picture of biometric info?
Resolution: The whole file should be hashed. We will use the same
wording as the new logotype RFC but we will not enhance or change the
ASN.1 structure since this extension is being deployed.


Issue 7: Updating the qcStatement-1 for the new RFC
Resolution: Yes we should define a new OID for compliance with V2 of
this standard, which then also will help indicate the updated/clarified
semantics of the subject Directory attributes.

Issue 8: Optional absence of statementInfo of qcStatament for the
predefined statement
Resolution: We think this is syntactically defined in 3.2.5 but we are
willing to add a clarifying sentence in 3.2.5.1 as well.

Issue 9: Changing the pretty name of the ASN.1 module.
Resolution: We want to follow the praxis of other RFC:s in this area and
keep the name with a new OID. Why wouldn't that work for this standard
when it works for RFC 3280?


I hope this is OK for everyone
If so we will issue a new draft with these changes ASAP.

/Stefan

> 
> 3.  New section 1.1 is required to be added stating the differences
> between this document and 3039
> 
> 4.  Section 2, para 2:
>  	The text "where the certificate meet some qualification
> requirements" should be imported to either "certificates meet" or
> "certificate meets"
> 
> 5.  Section 2, bullet item 3:  Suggest new text of
>  	"-  Definition of usage for the key usage extension in Qualified
>       Certificates.."
> 
> 6.  Section 3.2.1 - DateOfBirth SHOULD state the proper encoding to be
> used.  I.E. are we looking for seconds, minutes or hours or just DATE
in
> the GeneralTime field?
> 
> 7.  Section 3.2.1 - countryOfResidence and countryOfCitizenship - If
you
> have multiple countrys to be listed, should this be a multi-value item
> or should there be two distinct attributes? (Alternatively should this
> be restricted back to a single attribute with a single value - i.e you
> can only list one of your countries of citizenship.)
> 
> 8.  Section 3.2.4 - This is something that I have no experence with.
If
> you look at a jpeg, bitmap or other type if image, who defines what is
> considred to be a label and what is considered to be the image data?
> What is done in this case about different sized images?
> 
> 9.  Section 3.2.5.1 - I would like to know the reason that
qcstatement-1
> has not been updated to a new OID.  This is a new draft document with
> some different semantics than 3039.  Are these changes all suffiently
> small that a new policy is not needed?
> 
> 10. Sectin 3.2.5.1 - I have decided to put the predefined statement
into
> my QC.  After reading this document I understand that what I want
> stearts as follows:
> 
> 	EXTENSION { id-pe-qcStatements,
> 			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> In this case I don't have asemanticsIdentifier created by the
document,
> so I must be incoluding the NameRegistrationAuthorities otion.
However
> I don't know if what goes here is the pkix working group name or some
> other value.
> 
> 11.  Sectin A.1 - I suggest changing the pretty name to
> PKIXqualified88-03 to distinquish from rfc3039.
> 
> 
> 
> jim
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIMMTib040103 for <[e-mail]>; Thu, 18 Dec 2003 14:22:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBIMMTAj040102 for ietf-pkix-bks; Thu, 18 Dec 2003 14:22:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIMMSib040097 for <[e-mail]>; Thu, 18 Dec 2003 14:22:28 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 81FBA73B27; Thu, 18 Dec 2003 13:15:36 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Nystrom, Magnus'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Last Call: Qualified Certificates
Date: Thu, 18 Dec 2003 13:19:10 -0800
Message-ID: <007801c3c5ac$949a1ac0$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <Pine.WNT.4.58.0312180947510.888@mnystrom-lap>
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>

Magnus,

My default assumption is that if you define a statementId and an
assoicated statementInfo, the statementInfo must be present for that
statementId unless otherwise documented in the definition of the
statementId.  The text you cite below allows me to create a statementId
and either define the statementInfo as absent or optional.

jim

> -----Original Message-----
> From: Nystrom, Magnus [mailto:[e-mail]] 
> Sent: Thursday, December 18, 2003 12:51 AM
> To: [e-mail]
> Cc: [e-mail]; 'Stefan Santesson'
> Subject: RE: Last Call: Qualified Certificates
> 
> 
> Jim,
> 
> The QCStatement.statementInfo component is optional for any 
> and all statements. It is not specific for qcStatement-1, it 
> is governed by the Type definition for QCStatement. Quoting 
> from the text describing the QCStatement type: "Each 
> statement SHALL include an object identifier for the 
> statement and MAY also include optional qualifying data 
> contained in the statementInfo parameter." Adding a special 
> statement for qcStatement-1 would be confusing, IMO.
> 
> -- Magnus
> 
> On Thu, 18 Dec 2003, Jim Schaad wrote:
> 
> > Magnus,
> >
> > This being the case, please add a textual statement that for 
> > qcStatement-1, the parameters SemanticsInformation is optional.
> >
> > jim
> >
> > > -----Original Message-----
> > > From: Nystrom, Magnus [mailto:[e-mail]]
> > > Sent: Thursday, December 18, 2003 12:33 AM
> > > To: [e-mail]
> > > Cc: [e-mail]; 'Stefan Santesson'
> > > Subject: RE: Last Call: Qualified Certificates
> > >
> > > Jim,
> > >
> > > Please find my reply below.
> > >
> > > On Wed, 17 Dec 2003, Jim Schaad wrote:
> > >
> > > > Magnus,
> > > >
> > > > Only one issue left....
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] 
> > > > > [mailto:[e-mail]] On Behalf Of Nystrom, 
> > > > > Magnus
> > > > >
> > > > > Jim,
> > > > >
> > > > > Thanks for continuing the discussion... Some replies below.
> > > > >
> > > > > On Wed, 17 Dec 2003, Jim Schaad wrote:
> > > > >
> > > > > > > -----Original Message-----
> > > > > > >
> > > > > > > Thanks for your review. I'll respond to a few of your
> > > comments
> > > > > > > here.
> > > > > > > > 10. Sectin 3.2.5.1 - I have decided to put the 
> predefined 
> > > > > > > > statement into my QC.  After reading this document I 
> > > > > > > > understand that what I want stearts as follows:
> > > > > > > >
> > > > > > > > 	EXTENSION { id-pe-qcStatements,
> > > > > > > > 			{ 
> id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> > > > > > > > In this case I don't have asemanticsIdentifier
> > > created by the
> > > > > > > > document, so I must be incoluding the 
> > > > > > > > NameRegistrationAuthorities otion.  However I 
> don't know 
> > > > > > > > if what goes here is the pkix working group 
> name or some 
> > > > > > > > other value.
> > > > > > >
> > > > > > > I am not sure I understand your question Jim, but
> > > values for the
> > > > > > > nameRegistrationAuthorities component has nothing 
> to do with 
> > > > > > > PKIX. It is the OID for the authority responsible for the 
> > > > > > > subject's name (or attributes of the subject's 
> name) as it 
> > > > > > > appears in the certificate. I thought this was clear from 
> > > > > > > 3.2.5.1?  Likewise for the semanticsIdentifier option
> > > - it is to
> > > > > > > be specified by/for that authority.
> > > > > >
> > > > > > LET ME QUOTE:
> > > > > >
> > > > > >    --  This statement identifies conformance with syntax and
> > > > > >    --  semantics defined in this Qualified 
> Certificate profile
> > > > > >    --  (Version 1). The SemanticsInformation may
> > > optionally contain
> > > > > >    --  additional semantics information as specified.
> > > > > >
> > > > > > As I read this statement there should be an OID that 
> > > > > > identifies this DOCUMENT as a name registration authority.
> > > > >
> > > > > No, that was not the intent - this document should 
> not be a name 
> > > > > registration authority.
> > > > >
> > > > > Note the syntax: A QCStatement is a SEQUENCE of a statementID 
> > > > > component (an OID) and an optional statementInfo. For 
> the object 
> > > > > qcStatement-1, the statementInfo component is a value of type 
> > > > > SemanticsInformation. The semantics of qcStatement-1 
> is that the 
> > > > > certificate has been issued in conformance with syntax
> > > and semantics
> > > > > identified in this document. In the case of 
> qcStatement-1, the 
> > > > > statementInfo component (which is of type
> > > SemanticsInformation) "MAY
> > > > > contain a semantics identifier and MAY identify one 
> or more name 
> > > > > registration authorities."  ("MAY" since the components are 
> > > > > optional).
> > > > >
> > > > > As stated in the document, the semanticsIdentifier 
> component of 
> > > > > a SemanticsInformation value contains an OID which defines
> > > semantics
> > > > > for certain attributes and names in basic certificate fields, 
> > > > > and the nameRegistrationAuthorities component contains the
> > > name of one
> > > > > or more authorities responsible for the registration of
> > > attributes
> > > > > or names associated with the subject and the 
> association between 
> > > > > such an authority and present attributes MAY be defined by a 
> > > > > semanticsIdentifier OID.
> > > > >
> > > > > > If I use the fields defined by this document and use
> > > the defined
> > > > > > OID in this document, then I need to be able to
> > > correction encode
> > > > > > this extension in my certificate without reference to
> > > an external
> > > > > > naming authority.  If this is not the case then there is 
> > > > > > absolutely no reason to have section 3.1 or 3.2.1,
> > > 3.2.2, 3.2.3 or
> > > > > > 3.2.4 as they are defining how these fields should be used.
> > > > > >
> > > > > > I need a way to refer to this document as either the 
> > > > > > semanticsIdentifier or the nameRegistrationAuthority.
> > > > >
> > > > > As I see it, you shouldn't. The statementInfo component
> > > is optional.
> > > > > If all you want to say is that you're conformant with 
> syntax and 
> > > > > semantics of this document then you set the statementID to 
> > > > > id-qcs-pkixQCSyntax-v1 and leave out the statementInfo
> > > component. If
> > > > > there is some well-known OID that defines semantics 
> for a set of 
> > > > > attributes and/or names used then include the statementInfo 
> > > > > component, and set the semanticsIdentifier component. If you 
> > > > > just want to name a registration authority then include the
> > > statementInfo
> > > > > component and set its nameRegistrationAuthority component. If 
> > > > > you want to associate a name a registration authority with 
> > > > > semantics for certain attributes then set both 
> components of the 
> > > > > SemanticsInformation.
> > > > >
> > > > > I have tried to capture our thinking above, but I may have 
> > > > > missed something as we wrote this almost four years 
> ago. Stefan,
> > > feel free
> > > > > to correct me if I got something wring.
> > > > >
> > > > > Did this help at all, Jim?
> > > >
> > > > This does and does not help.  I can now understand how you
> > > think that
> > > > I should be encoding this extension.  However in reviewing the 
> > > > document I do not see any statements about the fact that
> > > the presence
> > > > of QCStatements being optional.  This needs to be 
> clarified in the 
> > > > document.
> > >
> > > I think there is some confusion here. QCStatements is not 
> optional. 
> > > But each QCStatement has the syntax
> > >
> > >    QCStatement ::= SEQUENCE {
> > >        statementId   QC-STATEMENT.&Id({SupportedStatements}),
> > >        statementInfo QC-STATEMENT.&Type
> > >        ({SupportedStatements}{@statementId}) OPTIONAL }
> > >
> > > (or in older syntax:
> > >
> > > QCStatement ::= SEQUENCE {
> > >     statementId        OBJECT IDENTIFIER,
> > >     statementInfo      ANY DEFINED BY statementId OPTIONAL}
> > > )
> > >
> > > I.e. the statementInfo component of each QCStatement value is 
> > > OPTIONAL. So, if you use this extension, you can have a 
> QCStatement 
> > > with the statementId value set to the statement OID 
> defined in the 
> > > document, but you don't need to have a statementInfo component 
> > > present.
> > >
> > > > The document does require that either statementInfo or
> > > statementId be
> > > > present within the QCStatement object however.
> > >
> > > (QCStatement is a type, not an object)
> > >
> > > No, it requires that either the semanticsIdentifier or the 
> > > nameRegistrationAuthorities components (or both) be present in a 
> > > value of type SemanticsInformation which is the syntax for the 
> > > qcStatement-1 object. This should not be confused with the 
> > > QCStatement type. If the statementId component of a QCStatement 
> > > value has the value id-qcs-pkixQCSyntax-v1 then the statementInfo 
> > > component is still optional, but if present it must have 
> the syntax 
> > > SemanticsInformation for which it holds that at least one of its 
> > > components must be present.
> > >
> > > > Thus if QCStatements is not OPTIONAL (my reading of your above
> > > > statement) then a statement as to how to encode as using the 
> > > > "conformance and semantics defined in this document" needs
> > > to be made.
> > >
> > > QCStatements is not OPTIONAL, but you don't need to populate 
> > > individual QCStatement's statementInfo components, as described 
> > > above.
> > >
> > > -- Magnus
> > >
> >
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIKVAib034930 for <[e-mail]>; Thu, 18 Dec 2003 12:31:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBIKVAbh034929 for ietf-pkix-bks; Thu, 18 Dec 2003 12:31:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIKV9ib034923 for <[e-mail]>; Thu, 18 Dec 2003 12:31:10 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15222; Thu, 18 Dec 2003 15:31:04 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sha244-02.txt
Date: Thu, 18 Dec 2003 15:31:04 -0500
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		: A 224-bit One-way Hash Function: SHA-224
	Author(s)	: R. Housley
	Filename	: draft-ietf-pkix-sha244-02.txt
	Pages		: 6
	Date		: 2003-12-18
	
This document specifies a 224-bit one-way hash function, called
   SHA-224.  A SHA-224 is based on SHA-256, but it uses an different
   initial value and the result is truncated to 224 bits.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha244-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-sha244-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-sha244-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-sha244-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-sha244-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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIJnEib031949 for <[e-mail]>; Thu, 18 Dec 2003 11:49:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBIJnEvQ031948 for ietf-pkix-bks; Thu, 18 Dec 2003 11:49:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIJnEib031943 for <[e-mail]>; Thu, 18 Dec 2003 11:49:14 -0800 (PST) (envelope-from [e-mail])
Received: from vdsl-130-13-127-251.phnx.uswest.net ([130.13.127.251] helo=[192.168.2.7]) by razorbill.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 1AX495-0005qn-00; Thu, 18 Dec 2003 11:49:15 -0800
Mime-Version: 1.0
X-Sender: [e-mail]@pop.earthlink.net
Message-Id: <a0601021ebc07ae7b7195@[192.168.2.7]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 18 Dec 2003 12:48:14 -0700
To: [e-mail]
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: Re: non repudiation
Cc: [e-mail]
Content-Type: text/html; charset="us-ascii"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d478acf18c6dc3878fd991f4c20b2e9b4f1375b89bcadad4eb3b350badd9bab72f9c350badd9bab72f9c
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>

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: non repudiation</title></head><body>
<div>please note that the DTC states that the original identifier is
not considered invalid but is deprecated. so if the name is an issue,
it is not an error to change it in the modules used to define your
product.</div>
<div><br></div>
<div>i tried to come up with a way to assign different identifiers to
the same list but that seems not to be possible.&nbsp; if someone
comes up with a way to do it, i am more than willing to amend the DTC.
i had intended to post the DTCs a little later to avoid responding to
comments until after the holidays but it looks like that also is not
possible.i'll post several new items today</div>
<div><br></div>
<div>as for changing the name of the bit, much discussion, ballot
comment, and negotiation. this action was not taken lightly. if you
want to see some of the reasons, look at the us ballot comments
in<font face="Lucida Grande" size="-4" color="#000000">
ftp://ftp.bull.com/pub/OSIdirectory/Geneva2003Input/N12408SoVDTC6X509<span
></span>(4th).pdf</font></div>
<div><br></div>
<div>the ballot close date for the DTC is 12 march 2004. potential
ballot comments should go to your national representative. please
forgive me if i am not immediately responsive to comments and
questions until after the next week. i lost a lot of thanksgiving to
preparing this and other documents and i don't intend to lose
christmas</div>
<div><br></div>
<div>&nbsp;&nbsp; hoyt</div>
<div><br></div>
<div><br></div>
<div>At 17:57 +0100 12/18/03, Peter Sylvester wrote:</div>
<blockquote type="cite" cite>There is currently a new proposal to
change again the<br>
meaning of the key usage bit for non repudiation:<br>
<br>
<br>
http://www.pki-page.info/download/N12599.doc<br>
<br>
<br>
My opinion is that changing the name of a bit may<br>
create harm in ASN1 compiler generated structures<br>
used in all kinds of application, examples are<br>
CA software that uses the documented name of bit<br>
may/must be changed to support or not the new<br>
name. if the software is simply compiled with a new<br>
asn1 definition, this may have impacts to<br>
all kinds of scripts, profile definitions etc.<br>
<br>
The text itself says that whether or not the bit<br>
is named in the old or new way, the semantics<br>
is as defined in the proposal, in other words,<br>
why changing at all the name of a bit.<br>
<br>
Having that this does not mean that I have any<br>
particular comment concerning the semantics<br>
of that bit.<br>
<br>
<br>
<br>
Peter</blockquote>
<div><br></div>
</body>
</html>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIGvHib024106 for <[e-mail]>; Thu, 18 Dec 2003 08:57:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBIGvH3D024105 for ietf-pkix-bks; Thu, 18 Dec 2003 08:57:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIGvEib024099 for <[e-mail]>; Thu, 18 Dec 2003 08:57:15 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA02676; Thu, 18 Dec 2003 17:57:08 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 18 Dec 2003 17:57:08 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hBIGv6r12714; Thu, 18 Dec 2003 17:57:06 +0100 (MET)
Date: Thu, 18 Dec 2003 17:57:06 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: non repudiation
Cc: [e-mail]
X-Sun-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>

There is currently a new proposal to change again the
meaning of the key usage bit for non repudiation:


http://www.pki-page.info/download/N12599.doc


My opinion is that changing the name of a bit may
create harm in ASN1 compiler generated structures
used in all kinds of application, examples are
CA software that uses the documented name of bit
may/must be changed to support or not the new
name. if the software is simply compiled with a new
asn1 definition, this may have impacts to
all kinds of scripts, profile definitions etc.

The text itself says that whether or not the bit
is named in the old or new way, the semantics
is as defined in the proposal, in other words,
why changing at all the name of a bit. 

Having that this does not mean that I have any
particular comment concerning the semantics
of that bit.



Peter


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIE6Zib015280 for <[e-mail]>; Thu, 18 Dec 2003 06:06:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBIE6ZoS015279 for ietf-pkix-bks; Thu, 18 Dec 2003 06:06:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBIE6Xib015274 for <[e-mail]>; Thu, 18 Dec 2003 06:06:34 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 24744 invoked by uid 0); 18 Dec 2003 14:06:30 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.214.231) by woodstock.binhost.com with SMTP; 18 Dec 2003 14:06:30 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 18 Dec 2003 08:59:33 -0500
To: "Manger, James H" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: WG Last Call: Additional Algorithms for RSA cryptography
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:

As you know, I generated an ASN.1 module as you suggest.  My co-authors 
have not accepted (or rejected) it yet.

I would prefer to stick to the same ASN.1 documents that are referenced by 
the rest of the PKIX documents.

Russ

At 12:29 PM 12/18/2003 +1000, Manger, James H wrote:

>Are the ASN.1 values going to be reformatted (to include field names)?
>Is the reference to a withdrawn ASN.1 standard going to be changed?
>
>
>----------
>From: [e-mail] [mailto:[e-mail]]
>Sent: Wednesday, 17 December 2003 6:31 AM
>Subject: WG Last Call: Additional Algorithms for RSA cryptography
>
>This message initiates working group Last Call for "Additional Algorithms and
>Identifiers for RSA Cryptography". As a reminder, here is the Abstract:
>
>    This document supplements RFC 3279.  It describes the conventions
>    for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key
>    transport algorithm and additional one-way hash functions with the
>    PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public
>    Key Infrastructure (PKI).  Encoding formats, algorithm identifiers,
>    and parameter formats are specified.
>
>This is a three week Last Call.  That means it will close sometime on or 
>after
>January 9, 2004.   The schedule has been padded with an additional week in
>light of the holidays.
>
>** Do not count on any further extension to Last Call!!! **
>
>I intend to close Last Call promptly on January 9, since an S/MIME WG 
>document
>is blocked on this document.
>
>The URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-01.txt
>
>
>
>
>
>----------
>From: Steven Legg [mailto:[e-mail]]
>Sent: Thursday, 4 December 2003 3:04 PM
>
> > The changes you are claming as non-compliant are not required for the 
> 1988 version.
>
>But they're not disallowed either. Why use a notation from 1988 which is 
>deprecated by later editions of ASN.1 when there is alternative notation 
>that is valid in 1988 and all later editions of ASN.1. ?
>
>----------
>From: Phillip H. Griffin [mailto:[e-mail]]
>Sent: Friday, 5 December 2003 12:26 AM
>
>X.208 and X.209 are no longer merely deprecated. They have been withdrawn 
>as international standards since last year.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI8phib076670 for <[e-mail]>; Thu, 18 Dec 2003 00:51:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBI8pgN0076669 for ietf-pkix-bks; Thu, 18 Dec 2003 00:51:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI8pfib076656 for <[e-mail]>; Thu, 18 Dec 2003 00:51:41 -0800 (PST) (envelope-from [e-mail])
Received: from ebola.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with ESMTP; Thu, 18 Dec 2003 03:51:41 -0500
Received: from sdtihq24.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.12.10/NULL) with ESMTP id hBI8pW1i005177; Thu, 18 Dec 2003 03:51:33 -0500 (EST)
Received: from exrsa01.rsa.com (exrsa01.rsa.com [10.81.217.7]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id hBI8pd8F022352; Thu, 18 Dec 2003 03:51:39 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2657.72) id <W4Q4973S>; Thu, 18 Dec 2003 00:51:39 -0800
Received: from mnystrom-lap (mpilcher-lap.na.rsa.net [10.3.9.2]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id W4Q4973R; Thu, 18 Dec 2003 00:51:36 -0800
From: "Nystrom, Magnus" <[e-mail]>
Reply-To: "Nystrom, Magnus" <[e-mail]>
To: [e-mail]
Cc: [e-mail], "'Stefan Santesson'" <[e-mail]>
Date: Thu, 18 Dec 2003 09:51:10 +0100 (W. Europe Standard Time)
Subject: RE: Last Call: Qualified Certificates
In-Reply-To: <006401c3c543$a469be60$[e-mail]>
Message-ID: <Pine.WNT.4.58.0312180947510.888@mnystrom-lap>
References: <006401c3c543$a469be60$[e-mail]>
X-X-Sender: [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>

Jim,

The QCStatement.statementInfo component is optional for any and all
statements. It is not specific for qcStatement-1, it is governed by the
Type definition for QCStatement. Quoting from the text describing the
QCStatement type: "Each statement SHALL include an object identifier for
the statement and MAY also include optional qualifying data contained in
the statementInfo parameter." Adding a special statement for qcStatement-1
would be confusing, IMO.

-- Magnus

On Thu, 18 Dec 2003, Jim Schaad wrote:

> Magnus,
>
> This being the case, please add a textual statement that for
> qcStatement-1, the parameters SemanticsInformation is optional.
>
> jim
>
> > -----Original Message-----
> > From: Nystrom, Magnus [mailto:[e-mail]]
> > Sent: Thursday, December 18, 2003 12:33 AM
> > To: [e-mail]
> > Cc: [e-mail]; 'Stefan Santesson'
> > Subject: RE: Last Call: Qualified Certificates
> >
> > Jim,
> >
> > Please find my reply below.
> >
> > On Wed, 17 Dec 2003, Jim Schaad wrote:
> >
> > > Magnus,
> > >
> > > Only one issue left....
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Nystrom, Magnus
> > > >
> > > > Jim,
> > > >
> > > > Thanks for continuing the discussion... Some replies below.
> > > >
> > > > On Wed, 17 Dec 2003, Jim Schaad wrote:
> > > >
> > > > > > -----Original Message-----
> > > > > >
> > > > > > Thanks for your review. I'll respond to a few of your
> > comments
> > > > > > here.
> > > > > > > 10. Sectin 3.2.5.1 - I have decided to put the predefined
> > > > > > > statement into my QC.  After reading this document I
> > > > > > > understand that what I want stearts as follows:
> > > > > > >
> > > > > > > 	EXTENSION { id-pe-qcStatements,
> > > > > > > 			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> > > > > > > In this case I don't have asemanticsIdentifier
> > created by the
> > > > > > > document, so I must be incoluding the
> > > > > > > NameRegistrationAuthorities otion.  However I don't know if
> > > > > > > what goes here is the pkix working group name or some other
> > > > > > > value.
> > > > > >
> > > > > > I am not sure I understand your question Jim, but
> > values for the
> > > > > > nameRegistrationAuthorities component has nothing to do with
> > > > > > PKIX. It is the OID for the authority responsible for the
> > > > > > subject's name (or attributes of the subject's name) as it
> > > > > > appears in the certificate. I thought this was clear from
> > > > > > 3.2.5.1?  Likewise for the semanticsIdentifier option
> > - it is to
> > > > > > be specified by/for that authority.
> > > > >
> > > > > LET ME QUOTE:
> > > > >
> > > > >    --  This statement identifies conformance with syntax and
> > > > >    --  semantics defined in this Qualified Certificate profile
> > > > >    --  (Version 1). The SemanticsInformation may
> > optionally contain
> > > > >    --  additional semantics information as specified.
> > > > >
> > > > > As I read this statement there should be an OID that identifies
> > > > > this DOCUMENT as a name registration authority.
> > > >
> > > > No, that was not the intent - this document should not be a name
> > > > registration authority.
> > > >
> > > > Note the syntax: A QCStatement is a SEQUENCE of a statementID
> > > > component (an OID) and an optional statementInfo. For the object
> > > > qcStatement-1, the statementInfo component is a value of type
> > > > SemanticsInformation. The semantics of qcStatement-1 is that the
> > > > certificate has been issued in conformance with syntax
> > and semantics
> > > > identified in this document. In the case of qcStatement-1, the
> > > > statementInfo component (which is of type
> > SemanticsInformation) "MAY
> > > > contain a semantics identifier and MAY identify one or more name
> > > > registration authorities."  ("MAY" since the components are
> > > > optional).
> > > >
> > > > As stated in the document, the semanticsIdentifier component of a
> > > > SemanticsInformation value contains an OID which defines
> > semantics
> > > > for certain attributes and names in basic certificate fields, and
> > > > the nameRegistrationAuthorities component contains the
> > name of one
> > > > or more authorities responsible for the registration of
> > attributes
> > > > or names associated with the subject and the association between
> > > > such an authority and present attributes MAY be defined by a
> > > > semanticsIdentifier OID.
> > > >
> > > > > If I use the fields defined by this document and use
> > the defined
> > > > > OID in this document, then I need to be able to
> > correction encode
> > > > > this extension in my certificate without reference to
> > an external
> > > > > naming authority.  If this is not the case then there is
> > > > > absolutely no reason to have section 3.1 or 3.2.1,
> > 3.2.2, 3.2.3 or
> > > > > 3.2.4 as they are defining how these fields should be used.
> > > > >
> > > > > I need a way to refer to this document as either the
> > > > > semanticsIdentifier or the nameRegistrationAuthority.
> > > >
> > > > As I see it, you shouldn't. The statementInfo component
> > is optional.
> > > > If all you want to say is that you're conformant with syntax and
> > > > semantics of this document then you set the statementID to
> > > > id-qcs-pkixQCSyntax-v1 and leave out the statementInfo
> > component. If
> > > > there is some well-known OID that defines semantics for a set of
> > > > attributes and/or names used then include the statementInfo
> > > > component, and set the semanticsIdentifier component. If you just
> > > > want to name a registration authority then include the
> > statementInfo
> > > > component and set its nameRegistrationAuthority component. If
> > > > you want to associate a name a registration authority with
> > > > semantics for certain attributes then set both components of
> > > > the SemanticsInformation.
> > > >
> > > > I have tried to capture our thinking above, but I may have missed
> > > > something as we wrote this almost four years ago. Stefan,
> > feel free
> > > > to correct me if I got something wring.
> > > >
> > > > Did this help at all, Jim?
> > >
> > > This does and does not help.  I can now understand how you
> > think that
> > > I should be encoding this extension.  However in reviewing the
> > > document I do not see any statements about the fact that
> > the presence
> > > of QCStatements being optional.  This needs to be clarified in the
> > > document.
> >
> > I think there is some confusion here. QCStatements is not
> > optional. But each QCStatement has the syntax
> >
> >    QCStatement ::= SEQUENCE {
> >        statementId   QC-STATEMENT.&Id({SupportedStatements}),
> >        statementInfo QC-STATEMENT.&Type
> >        ({SupportedStatements}{@statementId}) OPTIONAL }
> >
> > (or in older syntax:
> >
> > QCStatement ::= SEQUENCE {
> >     statementId        OBJECT IDENTIFIER,
> >     statementInfo      ANY DEFINED BY statementId OPTIONAL}
> > )
> >
> > I.e. the statementInfo component of each QCStatement value is
> > OPTIONAL. So, if you use this extension, you can have a
> > QCStatement with the statementId value set to the statement
> > OID defined in the document, but you don't need to have a
> > statementInfo component present.
> >
> > > The document does require that either statementInfo or
> > statementId be
> > > present within the QCStatement object however.
> >
> > (QCStatement is a type, not an object)
> >
> > No, it requires that either the semanticsIdentifier or the
> > nameRegistrationAuthorities components (or both) be present
> > in a value of type SemanticsInformation which is the syntax
> > for the qcStatement-1 object. This should not be confused
> > with the QCStatement type. If the statementId component of a
> > QCStatement value has the value id-qcs-pkixQCSyntax-v1 then
> > the statementInfo component is still optional, but if present
> > it must have the syntax SemanticsInformation for which it
> > holds that at least one of its components must be present.
> >
> > > Thus if QCStatements is not OPTIONAL (my reading of your above
> > > statement) then a statement as to how to encode as using the
> > > "conformance and semantics defined in this document" needs
> > to be made.
> >
> > QCStatements is not OPTIONAL, but you don't need to populate
> > individual QCStatement's statementInfo components, as described above.
> >
> > -- Magnus
> >
>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI8iaib074254 for <[e-mail]>; Thu, 18 Dec 2003 00:44:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBI8iaWm074252 for ietf-pkix-bks; Thu, 18 Dec 2003 00:44:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI8iXib074224 for <[e-mail]>; Thu, 18 Dec 2003 00:44:36 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id C610B716AF; Thu, 18 Dec 2003 00:44:25 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Nystrom, Magnus'" <[e-mail]>
Cc: <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Last Call: Qualified Certificates
Date: Thu, 18 Dec 2003 00:47:59 -0800
Message-ID: <006401c3c543$a469be60$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <Pine.WNT.4.58.0312180905300.888@mnystrom-lap>
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>

Magnus,

This being the case, please add a textual statement that for
qcStatement-1, the parameters SemanticsInformation is optional.

jim

> -----Original Message-----
> From: Nystrom, Magnus [mailto:[e-mail]] 
> Sent: Thursday, December 18, 2003 12:33 AM
> To: [e-mail]
> Cc: [e-mail]; 'Stefan Santesson'
> Subject: RE: Last Call: Qualified Certificates
> 
> 
> Jim,
> 
> Please find my reply below.
> 
> On Wed, 17 Dec 2003, Jim Schaad wrote:
> 
> > Magnus,
> >
> > Only one issue left....
> >
> > > -----Original Message-----
> > > From: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of Nystrom, Magnus
> > >
> > > Jim,
> > >
> > > Thanks for continuing the discussion... Some replies below.
> > >
> > > On Wed, 17 Dec 2003, Jim Schaad wrote:
> > >
> > > > > -----Original Message-----
> > > > >
> > > > > Thanks for your review. I'll respond to a few of your 
> comments 
> > > > > here.
> > > > > > 10. Sectin 3.2.5.1 - I have decided to put the predefined 
> > > > > > statement into my QC.  After reading this document I 
> > > > > > understand that what I want stearts as follows:
> > > > > >
> > > > > > 	EXTENSION { id-pe-qcStatements,
> > > > > > 			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> > > > > > In this case I don't have asemanticsIdentifier 
> created by the 
> > > > > > document, so I must be incoluding the 
> > > > > > NameRegistrationAuthorities otion.  However I don't know if 
> > > > > > what goes here is the pkix working group name or some other 
> > > > > > value.
> > > > >
> > > > > I am not sure I understand your question Jim, but 
> values for the 
> > > > > nameRegistrationAuthorities component has nothing to do with 
> > > > > PKIX. It is the OID for the authority responsible for the 
> > > > > subject's name (or attributes of the subject's name) as it 
> > > > > appears in the certificate. I thought this was clear from 
> > > > > 3.2.5.1?  Likewise for the semanticsIdentifier option 
> - it is to 
> > > > > be specified by/for that authority.
> > > >
> > > > LET ME QUOTE:
> > > >
> > > >    --  This statement identifies conformance with syntax and
> > > >    --  semantics defined in this Qualified Certificate profile
> > > >    --  (Version 1). The SemanticsInformation may 
> optionally contain
> > > >    --  additional semantics information as specified.
> > > >
> > > > As I read this statement there should be an OID that identifies 
> > > > this DOCUMENT as a name registration authority.
> > >
> > > No, that was not the intent - this document should not be a name 
> > > registration authority.
> > >
> > > Note the syntax: A QCStatement is a SEQUENCE of a statementID 
> > > component (an OID) and an optional statementInfo. For the object 
> > > qcStatement-1, the statementInfo component is a value of type 
> > > SemanticsInformation. The semantics of qcStatement-1 is that the 
> > > certificate has been issued in conformance with syntax 
> and semantics 
> > > identified in this document. In the case of qcStatement-1, the 
> > > statementInfo component (which is of type 
> SemanticsInformation) "MAY 
> > > contain a semantics identifier and MAY identify one or more name 
> > > registration authorities."  ("MAY" since the components are 
> > > optional).
> > >
> > > As stated in the document, the semanticsIdentifier component of a 
> > > SemanticsInformation value contains an OID which defines 
> semantics 
> > > for certain attributes and names in basic certificate fields, and 
> > > the nameRegistrationAuthorities component contains the 
> name of one 
> > > or more authorities responsible for the registration of 
> attributes 
> > > or names associated with the subject and the association between 
> > > such an authority and present attributes MAY be defined by a 
> > > semanticsIdentifier OID.
> > >
> > > > If I use the fields defined by this document and use 
> the defined 
> > > > OID in this document, then I need to be able to 
> correction encode 
> > > > this extension in my certificate without reference to 
> an external 
> > > > naming authority.  If this is not the case then there is 
> > > > absolutely no reason to have section 3.1 or 3.2.1, 
> 3.2.2, 3.2.3 or 
> > > > 3.2.4 as they are defining how these fields should be used.
> > > >
> > > > I need a way to refer to this document as either the 
> > > > semanticsIdentifier or the nameRegistrationAuthority.
> > >
> > > As I see it, you shouldn't. The statementInfo component 
> is optional. 
> > > If all you want to say is that you're conformant with syntax and 
> > > semantics of this document then you set the statementID to 
> > > id-qcs-pkixQCSyntax-v1 and leave out the statementInfo 
> component. If 
> > > there is some well-known OID that defines semantics for a set of 
> > > attributes and/or names used then include the statementInfo 
> > > component, and set the semanticsIdentifier component. If you just 
> > > want to name a registration authority then include the 
> statementInfo
> > > component and set its nameRegistrationAuthority component. If
> > > you want to associate a name a registration authority with
> > > semantics for certain attributes then set both components of
> > > the SemanticsInformation.
> > >
> > > I have tried to capture our thinking above, but I may have missed 
> > > something as we wrote this almost four years ago. Stefan, 
> feel free 
> > > to correct me if I got something wring.
> > >
> > > Did this help at all, Jim?
> >
> > This does and does not help.  I can now understand how you 
> think that 
> > I should be encoding this extension.  However in reviewing the 
> > document I do not see any statements about the fact that 
> the presence 
> > of QCStatements being optional.  This needs to be clarified in the 
> > document.
> 
> I think there is some confusion here. QCStatements is not 
> optional. But each QCStatement has the syntax
> 
>    QCStatement ::= SEQUENCE {
>        statementId   QC-STATEMENT.&Id({SupportedStatements}),
>        statementInfo QC-STATEMENT.&Type
>        ({SupportedStatements}{@statementId}) OPTIONAL }
> 
> (or in older syntax:
> 
> QCStatement ::= SEQUENCE {
>     statementId        OBJECT IDENTIFIER,
>     statementInfo      ANY DEFINED BY statementId OPTIONAL}
> )
> 
> I.e. the statementInfo component of each QCStatement value is 
> OPTIONAL. So, if you use this extension, you can have a 
> QCStatement with the statementId value set to the statement 
> OID defined in the document, but you don't need to have a 
> statementInfo component present.
> 
> > The document does require that either statementInfo or 
> statementId be 
> > present within the QCStatement object however.
> 
> (QCStatement is a type, not an object)
> 
> No, it requires that either the semanticsIdentifier or the 
> nameRegistrationAuthorities components (or both) be present 
> in a value of type SemanticsInformation which is the syntax 
> for the qcStatement-1 object. This should not be confused 
> with the QCStatement type. If the statementId component of a 
> QCStatement value has the value id-qcs-pkixQCSyntax-v1 then 
> the statementInfo component is still optional, but if present 
> it must have the syntax SemanticsInformation for which it 
> holds that at least one of its components must be present.
> 
> > Thus if QCStatements is not OPTIONAL (my reading of your above
> > statement) then a statement as to how to encode as using the 
> > "conformance and semantics defined in this document" needs 
> to be made.
> 
> QCStatements is not OPTIONAL, but you don't need to populate 
> individual QCStatement's statementInfo components, as described above.
> 
> -- Magnus
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI8XDib070516 for <[e-mail]>; Thu, 18 Dec 2003 00:33:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBI8XDAj070514 for ietf-pkix-bks; Thu, 18 Dec 2003 00:33:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI8XBib070501 for <[e-mail]>; Thu, 18 Dec 2003 00:33:11 -0800 (PST) (envelope-from [e-mail])
Received: from ebola.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with ESMTP; Thu, 18 Dec 2003 03:33:11 -0500
Received: from sdtihq24.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.12.10/NULL) with ESMTP id hBI8X21i004074; Thu, 18 Dec 2003 03:33:02 -0500 (EST)
Received: from exrsa01.rsa.com (exrsa01.rsa.com [10.81.217.7]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id hBI8X98F021677; Thu, 18 Dec 2003 03:33:09 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2657.72) id <W4Q497NS>; Thu, 18 Dec 2003 00:33:09 -0800
Received: from MNYSTROM-LAP ([10.3.9.2]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id W4Q497NR; Thu, 18 Dec 2003 00:33:02 -0800
From: "Nystrom, Magnus" <[e-mail]>
Reply-To: "Nystrom, Magnus" <[e-mail]>
To: [e-mail]
Cc: [e-mail], "'Stefan Santesson'" <[e-mail]>
Date: Thu, 18 Dec 2003 09:32:37 +0100 (W. Europe Standard Time)
Subject: RE: Last Call: Qualified Certificates
In-Reply-To: <005601c3c51d$d9dcb730$[e-mail]>
Message-ID: <Pine.WNT.4.58.0312180905300.888@mnystrom-lap>
References: <005601c3c51d$d9dcb730$[e-mail]>
X-X-Sender: [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>

Jim,

Please find my reply below.

On Wed, 17 Dec 2003, Jim Schaad wrote:

> Magnus,
>
> Only one issue left....
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Nystrom, Magnus
> >
> > Jim,
> >
> > Thanks for continuing the discussion... Some replies below.
> >
> > On Wed, 17 Dec 2003, Jim Schaad wrote:
> >
> > > > -----Original Message-----
> > > >
> > > > Thanks for your review. I'll respond to a few of your comments
> > > > here.
> > > > > 10. Sectin 3.2.5.1 - I have decided to put the predefined
> > > > > statement into my QC.  After reading this document I understand
> > > > > that what I want stearts as follows:
> > > > >
> > > > > 	EXTENSION { id-pe-qcStatements,
> > > > > 			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> > > > > In this case I don't have asemanticsIdentifier created by the
> > > > > document, so I must be incoluding the
> > > > > NameRegistrationAuthorities otion.  However I don't know if what
> > > > > goes here is the pkix working group name or some other value.
> > > >
> > > > I am not sure I understand your question Jim, but values for the
> > > > nameRegistrationAuthorities component has nothing to do with PKIX.
> > > > It is the OID for the authority responsible for the subject's name
> > > > (or attributes of the subject's name) as it appears in the
> > > > certificate. I thought this was clear from 3.2.5.1?  Likewise for
> > > > the semanticsIdentifier option - it is to be specified by/for that
> > > > authority.
> > >
> > > LET ME QUOTE:
> > >
> > >    --  This statement identifies conformance with syntax and
> > >    --  semantics defined in this Qualified Certificate profile
> > >    --  (Version 1). The SemanticsInformation may optionally contain
> > >    --  additional semantics information as specified.
> > >
> > > As I read this statement there should be an OID that identifies this
> > > DOCUMENT as a name registration authority.
> >
> > No, that was not the intent - this document should not be a name
> > registration authority.
> >
> > Note the syntax: A QCStatement is a SEQUENCE of a statementID
> > component (an OID) and an optional statementInfo. For the object
> > qcStatement-1, the statementInfo component is a value of type
> > SemanticsInformation. The semantics of qcStatement-1 is that the
> > certificate has been issued in conformance with syntax and semantics
> > identified in this document. In the case of qcStatement-1, the
> > statementInfo component (which is of type SemanticsInformation) "MAY
> > contain a semantics identifier and MAY identify one or more name
> > registration authorities."  ("MAY" since the components are optional).
> >
> > As stated in the document, the semanticsIdentifier component of a
> > SemanticsInformation value contains an OID which defines semantics for
> > certain attributes and names in basic certificate fields, and the
> > nameRegistrationAuthorities component contains the name of one or more
> > authorities responsible for the registration of attributes or names
> > associated with the subject and the association between such an
> > authority and present attributes MAY be defined by a
> > semanticsIdentifier OID.
> >
> > > If I use the fields defined by this document and use the defined OID
> > > in this document, then I need to be able to correction encode this
> > > extension in my certificate without reference to an external naming
> > > authority.  If this is not the case then there is absolutely no
> > > reason to have section 3.1 or 3.2.1, 3.2.2, 3.2.3 or 3.2.4 as they
> > > are defining how these fields should be used.
> > >
> > > I need a way to refer to this document as either the
> > > semanticsIdentifier or the nameRegistrationAuthority.
> >
> > As I see it, you shouldn't. The statementInfo component is
> > optional. If all you want to say is that you're conformant
> > with syntax and semantics of this document then you set the
> > statementID to id-qcs-pkixQCSyntax-v1 and leave out the
> > statementInfo component. If there is some well-known OID that
> > defines semantics for a set of attributes and/or names used
> > then include the statementInfo component, and set the
> > semanticsIdentifier component. If you just want to name a
> > registration authority then include the statementInfo
> > component and set its nameRegistrationAuthority component. If
> > you want to associate a name a registration authority with
> > semantics for certain attributes then set both components of
> > the SemanticsInformation.
> >
> > I have tried to capture our thinking above, but I may have
> > missed something as we wrote this almost four years ago.
> > Stefan, feel free to correct me if I got something wring.
> >
> > Did this help at all, Jim?
>
> This does and does not help.  I can now understand how you think that I
> should be encoding this extension.  However in reviewing the document I
> do not see any statements about the fact that the presence of
> QCStatements being optional.  This needs to be clarified in the
> document.

I think there is some confusion here. QCStatements is not optional. But
each QCStatement has the syntax

   QCStatement ::= SEQUENCE {
       statementId   QC-STATEMENT.&Id({SupportedStatements}),
       statementInfo QC-STATEMENT.&Type
       ({SupportedStatements}{@statementId}) OPTIONAL }

(or in older syntax:

QCStatement ::= SEQUENCE {
    statementId        OBJECT IDENTIFIER,
    statementInfo      ANY DEFINED BY statementId OPTIONAL}
)

I.e. the statementInfo component of each QCStatement value is OPTIONAL.
So, if you use this extension, you can have a QCStatement with the
statementId value set to the statement OID defined in the document, but
you don't need to have a statementInfo component present.

> The document does require that either statementInfo or statementId be
> present within the QCStatement object however.

(QCStatement is a type, not an object)

No, it requires that either the semanticsIdentifier or the
nameRegistrationAuthorities components (or both) be present in a value of
type SemanticsInformation which is the syntax for the qcStatement-1
object. This should not be confused with the QCStatement type. If the
statementId component of a QCStatement value has the value
id-qcs-pkixQCSyntax-v1 then the statementInfo component is still optional,
but if present it must have the syntax SemanticsInformation for which it
holds that at least one of its components must be present.

> Thus if QCStatements is not OPTIONAL (my reading of your above
> statement) then a statement as to how to encode as using the
> "conformance and semantics defined in this document" needs to be made.

QCStatements is not OPTIONAL, but you don't need to populate individual
QCStatement's statementInfo components, as described above.

-- Magnus


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI4Dsib011735 for <[e-mail]>; Wed, 17 Dec 2003 20:13:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBI4Ds2e011734 for ietf-pkix-bks; Wed, 17 Dec 2003 20:13:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI4Drib011729 for <[e-mail]>; Wed, 17 Dec 2003 20:13:53 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id F3EFD6D9C1; Wed, 17 Dec 2003 20:13:54 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Nystrom, Magnus'" <[e-mail]>
Cc: <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Last Call: Qualified Certificates
Date: Wed, 17 Dec 2003 20:17:28 -0800
Message-ID: <005601c3c51d$d9dcb730$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <Pine.WNT.4.58.0312172217550.1484@mnystrom-lap>
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>

Magnus,

Only one issue left....

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Nystrom, Magnus
> 
> Jim,
> 
> Thanks for continuing the discussion... Some replies below.
> 
> On Wed, 17 Dec 2003, Jim Schaad wrote:
> 
> > > -----Original Message-----
> > >
> > > Thanks for your review. I'll respond to a few of your 
> comments here. 

> > > > 10. Sectin 3.2.5.1 - I have decided to put the predefined 
> > > > statement into my QC.  After reading this document I understand 
> > > > that what I want stearts as follows:
> > > >
> > > > 	EXTENSION { id-pe-qcStatements,
> > > > 			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> > > > In this case I don't have asemanticsIdentifier created by the 
> > > > document, so I must be incoluding the 
> NameRegistrationAuthorities 
> > > > otion.  However I don't know if what goes here is the 
> pkix working 
> > > > group name or some other value.
> > >
> > > I am not sure I understand your question Jim, but values for the 
> > > nameRegistrationAuthorities component has nothing to do 
> with PKIX. 
> > > It is the OID for the authority responsible for the 
> subject's name 
> > > (or attributes of the subject's name) as it appears in the 
> > > certificate. I thought this was clear from 3.2.5.1?  Likewise for 
> > > the semanticsIdentifier option - it is to be specified 
> by/for that 
> > > authority.
> >
> > LET ME QUOTE:
> >
> >    --  This statement identifies conformance with syntax and
> >    --  semantics defined in this Qualified Certificate profile
> >    --  (Version 1). The SemanticsInformation may optionally contain
> >    --  additional semantics information as specified.
> >
> > As I read this statement there should be an OID that 
> identifies this 
> > DOCUMENT as a name registration authority.
> 
> No, that was not the intent - this document should not be a 
> name registration authority.
> 
> Note the syntax: A QCStatement is a SEQUENCE of a statementID 
> component (an OID) and an optional statementInfo. For the 
> object qcStatement-1, the statementInfo component is a value 
> of type SemanticsInformation. The semantics of qcStatement-1 
> is that the certificate has been issued in conformance with 
> syntax and semantics identified in this document. In the case 
> of qcStatement-1, the statementInfo component (which is of type
> SemanticsInformation) "MAY contain a semantics identifier and 
> MAY identify one or more name registration authorities." 
> ("MAY" since the components are optional).
> 
> As stated in the document, the semanticsIdentifier component 
> of a SemanticsInformation value contains an OID which defines 
> semantics for certain attributes and names in basic 
> certificate fields, and the nameRegistrationAuthorities 
> component contains the name of one or more authorities 
> responsible for the registration of attributes or names 
> associated with the subject and the association between such 
> an authority and present attributes MAY be defined by a 
> semanticsIdentifier OID.
> 
> > If I use the fields defined by this document and use the 
> defined OID 
> > in this document, then I need to be able to correction encode this 
> > extension in my certificate without reference to an external naming 
> > authority.  If this is not the case then there is 
> absolutely no reason 
> > to have section 3.1 or 3.2.1, 3.2.2, 3.2.3 or 3.2.4 as they are 
> > defining how these fields should be used.
> >
> > I need a way to refer to this document as either the 
> > semanticsIdentifier or the nameRegistrationAuthority.
> 
> As I see it, you shouldn't. The statementInfo component is 
> optional. If all you want to say is that you're conformant 
> with syntax and semantics of this document then you set the 
> statementID to id-qcs-pkixQCSyntax-v1 and leave out the 
> statementInfo component. If there is some well-known OID that 
> defines semantics for a set of attributes and/or names used 
> then include the statementInfo component, and set the 
> semanticsIdentifier component. If you just want to name a 
> registration authority then include the statementInfo 
> component and set its nameRegistrationAuthority component. If 
> you want to associate a name a registration authority with 
> semantics for certain attributes then set both components of 
> the SemanticsInformation.
> 
> I have tried to capture our thinking above, but I may have 
> missed something as we wrote this almost four years ago. 
> Stefan, feel free to correct me if I got something wring.
> 
> Did this help at all, Jim?

This does and does not help.  I can now understand how you think that I
should be encoding this extension.  However in reviewing the document I
do not see any statements about the fact that the presence of
QCStatements being optional.  This needs to be clarified in the
document.  The document does require that either statementInfo or
statementId be present within the QCStatement object however. Thus if
QCStatements is not OPTIONAL (my reading of your above statement) then a
statement as to how to encode as using the "conformance and semantics
defined in this document" needs to be made.

jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI49qib011580 for <[e-mail]>; Wed, 17 Dec 2003 20:09:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBI49qmN011579 for ietf-pkix-bks; Wed, 17 Dec 2003 20:09:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI49pib011574 for <[e-mail]>; Wed, 17 Dec 2003 20:09:51 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id B07C171255; Wed, 17 Dec 2003 20:09:36 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Manger, James H'" <[e-mail]>, <[e-mail]>
Subject: RE: WG Last Call: Additional Algorithms for RSA cryptography
Date: Wed, 17 Dec 2003 20:13:10 -0800
Message-ID: <005501c3c51d$3fdac050$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

James,

We will be updating the ASN.1 to use the field names.

We will not be changing the reference to the ASN.1 standard.   If you
believe this is an issue then it needs to be discussed by the IESG and
the Area Directors for the Security Area.  They have not indicated that
this is a change that needs to be made.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Manger, James H
> Sent: Wednesday, December 17, 2003 6:29 PM
> To: [e-mail]
> Subject: RE: WG Last Call: Additional Algorithms for RSA cryptography
> 
> 
> 
> Are the ASN.1 values going to be reformatted (to include 
> field names)? Is the reference to a withdrawn ASN.1 standard 
> going to be changed?
> 
> 
> ----------
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, 17 December 2003 6:31 AM
> Subject: WG Last Call: Additional Algorithms for RSA cryptography
> 
> This message initiates working group Last Call for 
> "Additional Algorithms and 
> Identifiers for RSA Cryptography". As a reminder, here is the 
> Abstract:
> 
>    This document supplements RFC 3279.  It describes the conventions 
>    for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key 
>    transport algorithm and additional one-way hash functions with the 
>    PKCS #1 version 1.5 signature algorithm in the Internet 
> X.509 Public 
>    Key Infrastructure (PKI).  Encoding formats, algorithm 
> identifiers, 
>    and parameter formats are specified. 
> 
> This is a three week Last Call.  That means it will close 
> sometime on or after 
> January 9, 2004.   The schedule has been padded with an 
> additional week in 
> light of the holidays. 
> 
> ** Do not count on any further extension to Last Call!!! **
> 
> I intend to close Last Call promptly on January 9, since an 
> S/MIME WG document 
> is blocked on this document.
> 
> The URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft->
ietf-pkix-rsa-pkalgs-01.txt
> 
> 
> 
> 
> 
> ----------
> From: Steven Legg [mailto:[e-mail]]
> Sent: Thursday, 4 December 2003 3:04 PM
> 
> > The changes you are claming as non-compliant are not 
> required for the 
> > 1988 version.
> 
> But they're not disallowed either. Why use a notation from 
> 1988 which is deprecated by later editions of ASN.1 when 
> there is alternative notation that is valid in 1988 and all 
> later editions of ASN.1. ?
> 
> ----------
> From: Phillip H. Griffin [mailto:[e-mail]]
> Sent: Friday, 5 December 2003 12:26 AM
> 
> X.208 and X.209 are no longer merely deprecated. They have 
> been withdrawn as international standards since last year.
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI2Tdib007822 for <[e-mail]>; Wed, 17 Dec 2003 18:29:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBI2Tdgu007821 for ietf-pkix-bks; Wed, 17 Dec 2003 18:29:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.ntcif.telstra.com.au ([202.12.233.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI2Tcib007812 for <[e-mail]>; Wed, 17 Dec 2003 18:29:38 -0800 (PST) (envelope-from [e-mail])
Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailbo.ntcif.telstra.com.au (Postfix) with ESMTP id 95ACB160DA for <[e-mail]>; Thu, 18 Dec 2003 13:29:34 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 1AE7B12983 for <[e-mail]>; Thu, 18 Dec 2003 13:29:34 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA00996 for <[e-mail]>; Thu, 18 Dec 2003 13:29:33 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: WG Last Call: Additional Algorithms for RSA cryptography
Date: Thu, 18 Dec 2003 12:29:21 +1000
Message-ID: <[e-mail]>
Thread-Topic: WG Last Call: Additional Algorithms for RSA cryptography
Thread-Index: AcPEHS2Cz/rATSSxSMCowOsZNGgVIAA8FjZA
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBI2Tdib007817
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>

Are the ASN.1 values going to be reformatted (to include field names)?
Is the reference to a withdrawn ASN.1 standard going to be changed?


----------
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, 17 December 2003 6:31 AM
Subject: WG Last Call: Additional Algorithms for RSA cryptography

This message initiates working group Last Call for "Additional Algorithms and 
Identifiers for RSA Cryptography". As a reminder, here is the Abstract:

   This document supplements RFC 3279.  It describes the conventions 
   for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key 
   transport algorithm and additional one-way hash functions with the 
   PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public 
   Key Infrastructure (PKI).  Encoding formats, algorithm identifiers, 
   and parameter formats are specified. 

This is a three week Last Call.  That means it will close sometime on or after 
January 9, 2004.   The schedule has been padded with an additional week in 
light of the holidays. 

** Do not count on any further extension to Last Call!!! **

I intend to close Last Call promptly on January 9, since an S/MIME WG document 
is blocked on this document.

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





----------
From: Steven Legg [mailto:[e-mail]]
Sent: Thursday, 4 December 2003 3:04 PM

> The changes you are claming as non-compliant are not required for the 1988 version.

But they're not disallowed either. Why use a notation from 1988 which is deprecated by later editions of ASN.1 when there is alternative notation that is valid in 1988 and all later editions of ASN.1. ?

----------
From: Phillip H. Griffin [mailto:[e-mail]]
Sent: Friday, 5 December 2003 12:26 AM

X.208 and X.209 are no longer merely deprecated. They have been withdrawn as international standards since last year.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI0T4ib003234 for <[e-mail]>; Wed, 17 Dec 2003 16:29:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBI0T4Ld003232 for ietf-pkix-bks; Wed, 17 Dec 2003 16:29:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBI0T3ib003227 for <[e-mail]>; Wed, 17 Dec 2003 16:29:03 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hBI0Sxn63713; Wed, 17 Dec 2003 17:28:59 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Nystrom, Magnus" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Last Call: Qualified Certificates
Date: Wed, 17 Dec 2003 17:30:58 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <Pine.WNT.4.58.0312172217550.1484@mnystrom-lap>
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: Nystrom, Magnus
> Sent: Wednesday, December 17, 2003 3:06 PM
>
> Jim Schaad wrote:
>
> > I understand that it is under the private
> > extensions arc.  I belive that the way this
> > arc was named is not clear.  IMHO by
> > publishing this extension in a public
> > document for public consumption it no longer
> > is a private extension.  I see no advantage
> > to having the word private in this location.
>
> Well, it is not important for me. I just wanted to
> follow the example set by 2459/3280.

Magnus, Jim:

FWIW and in the spirit of Last Call, I agree with Jim.  It seems
a rather innocuous point, but issues are made of such stuff.  As
I see it, this is the PKIX/IETF standard means of expressing
this information in an X.509-based certificate.  The fact that
its OID happens to be rooted off id-pe should not be taken as
invitation to revisit the addressed needs with a view towards a
"public" version.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHM6eib098014 for <[e-mail]>; Wed, 17 Dec 2003 14:06:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBHM6eXo098013 for ietf-pkix-bks; Wed, 17 Dec 2003 14:06:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHM6dib098008 for <[e-mail]>; Wed, 17 Dec 2003 14:06:39 -0800 (PST) (envelope-from [e-mail])
Received: from ebola.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with ESMTP; Wed, 17 Dec 2003 17:06:41 -0500
Received: from sdtihq24.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.12.10/NULL) with ESMTP id hBHM6W1i027481; Wed, 17 Dec 2003 17:06:33 -0500 (EST)
Received: from exrsa01.rsa.com (exrsa01.rsa.com [10.81.217.7]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id hBHM6d8F029920; Wed, 17 Dec 2003 17:06:39 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2657.72) id <W4Q496JN>; Wed, 17 Dec 2003 14:06:39 -0800
Received: from MNYSTROM-LAP ([10.3.9.3]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id W4Q496JM; Wed, 17 Dec 2003 14:06:32 -0800
From: "Nystrom, Magnus" <[e-mail]>
Reply-To: "Nystrom, Magnus" <[e-mail]>
To: [e-mail]
Cc: [e-mail], "'Stefan Santesson'" <[e-mail]>
Date: Wed, 17 Dec 2003 23:06:06 +0100 (W. Europe Standard Time)
Subject: RE: Last Call: Qualified Certificates
In-Reply-To: <003a01c3c4d8$1c2ff1b0$[e-mail]>
Message-ID: <Pine.WNT.4.58.0312172217550.1484@mnystrom-lap>
References: <003a01c3c4d8$1c2ff1b0$[e-mail]>
X-X-Sender: [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>

Jim,

Thanks for continuing the discussion... Some replies below.

On Wed, 17 Dec 2003, Jim Schaad wrote:

> > -----Original Message-----
> >
> > Thanks for your review. I'll respond to a few of your comments here.
> > Stefan will address the others.
> >
> > On November 12, Jim Schaad wrote:
> >
> > > Comments on this draft are as follows:
> > >
> > > 1.  Section 1 para 3;  I object to the phrase "private extensions".
> > > This document does not defined private extensions even if they exist
> > > in the id-pe arc.  These are now public extensions. -- Remove the
> > > word private.
> >
> > No, we are using the branch id-pe which specifically is named "arc for
> > private certificate extensions" in RFC 3280. As I see it,
> > private/public refers to presence in X.509 or not.  C.f. section 4.2.2
> > of RFC 3280, whose title even is "Private Internet Extensions"
> > (although the TOC in RFC 3280 lists another name).
>
> I understand that it is under the private extensions arc.  I belive that
> the way this arc was named is not clear.  IMHO by publishing this
> extension in a public document for public consumption it no longer is a
> private extension.  I see no advantage to having the word private in
> this location.

Well, it is not important for me. I just wanted to follow the example set
by 2459/3280.

> > > 6.  Section 3.2.1 - DateOfBirth SHOULD state the proper encoding to
> > > be used.  I.E. are we looking for seconds, minutes or hours or just
> > > DATE in the GeneralTime field?
> >
> > I don't see a need to do this for interoperability reasons.
> > The GeneralizedTime ASN.1 type will always contain a date,
> > and optionally a time down to a precision as specified in ISO
> > 8601. Relying parties will need to parse the type anyway.
> > Some registration authorities may decide to use a more
> > precise measurement than others and I would not want to
> > preclude them from doing so.
>
> In order to do a DER encoding of a GeneralTime field, without other
> restraints being placed on this field, I think (but have not verified)
> that on ewould be required to specify the msecs thus leading to a date
> such as 196012170000000000Z for the DOB.  Even cutting it off at the
> same level as dates in RFC3280 is an improvement.

No - ISO 8825-1 says that you can have any precision when DER-encoding
GeneralizedTime values, but seconds MUST be present (as must the "Z" for
UTC time). Trailing decimal zeros are always removed. I.e. an authority
which only uses dates will have values like:

19601217000000Z

Whereas an authority which does count seconds may have

19601217000022Z

But this would not be allowed:

19601217000022.0Z

Note that, in all cases, the string will consist of at least 15
characters. Any more than that an the authority uses fractional seconds
down to the precision allowed by ISO 8601. I still don't think this needs
to be specified further.

> > > 7.  Section 3.2.1 - countryOfResidence and countryOfCitizenship - If
> > > you have multiple countrys to be listed, should this be a
> > > multi-value item or should there be two distinct attributes?
> > > (Alternatively should this be restricted back to a single attribute
> > > with a single value - i.e you can only list one of your countries of
> > > citizenship.)
> >
> > The attributes (seen as ASN.1 objects) themselves are multi-valued.
> > This follows from PKCS #9 v2.0 where they are fully defined and we
> > have a reference to PKCS #9 in the document about this. But this still
> > allows several distinct attributes each with a single (or multiple)
> > value (values).  As the extension itself only is intended to carry
> > information from a directory about the subject of the certificate and
> > does not disallow multiple instances of the same attribute type it is
> > really up to the issuer and the way it stores information about the
> > subject to populate it. A conformant relying party that relies on
> > information provided in this extension will need to parse the complete
> > extension value anyway, so again I am not sure anything needs to be
> > done.
>
> This makes my code harder to implement as a RP.  I now need to look for
> both multiple values and multiple fields.  It is much simplier to only
> need to look for one (probably from ease of programing it would be
> multiple values).

Right, it is a little harder (but not particularly complex). On this one -
and also to answer Russ comment as to why I would like to allow both
variants - I am concerned about backwards-compatibility. 3039 has been out
for a couple of years now and both patterns may have been used.

> > > 10. Sectin 3.2.5.1 - I have decided to put the predefined statement
> > > into my QC.  After reading this document I understand that what I
> > > want stearts as follows:
> > >
> > > 	EXTENSION { id-pe-qcStatements,
> > > 			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> > > In this case I don't have asemanticsIdentifier created by the
> > > document, so I must be incoluding the NameRegistrationAuthorities
> > > otion.  However I don't know if what goes here is the pkix working
> > > group name or some other value.
> >
> > I am not sure I understand your question Jim, but values for
> > the nameRegistrationAuthorities component has nothing to do
> > with PKIX. It is the OID for the authority responsible for
> > the subject's name (or attributes of the subject's name) as
> > it appears in the certificate. I thought this was clear from
> > 3.2.5.1?  Likewise for the semanticsIdentifier option - it is
> > to be specified by/for that authority.
>
> LET ME QUOTE:
>
>    --  This statement identifies conformance with syntax and
>    --  semantics defined in this Qualified Certificate profile
>    --  (Version 1). The SemanticsInformation may optionally contain
>    --  additional semantics information as specified.
>
> As I read this statement there should be an OID that identifies this
> DOCUMENT as a name registration authority.

No, that was not the intent - this document should not be a name
registration authority.

Note the syntax: A QCStatement is a SEQUENCE of a statementID component
(an OID) and an optional statementInfo. For the object qcStatement-1, the
statementInfo component is a value of type SemanticsInformation. The
semantics of qcStatement-1 is that the certificate has been issued in
conformance with syntax and semantics identified in this document. In the
case of qcStatement-1, the statementInfo component (which is of type
SemanticsInformation) "MAY contain a semantics identifier and MAY identify
one or more name registration authorities." ("MAY" since the components
are optional).

As stated in the document, the semanticsIdentifier component of a
SemanticsInformation value contains an OID which defines semantics for
certain attributes and names in basic certificate fields, and the
nameRegistrationAuthorities component contains the name of one or more
authorities responsible for the registration of attributes or names
associated with the subject and the association between such an authority
and present attributes MAY be defined by a semanticsIdentifier OID.

> If I use the fields defined by this document and use the defined OID in
> this document, then I need to be able to correction encode this
> extension in my certificate without reference to an external naming
> authority.  If this is not the case then there is absolutely no reason
> to have section 3.1 or 3.2.1, 3.2.2, 3.2.3 or 3.2.4 as they are defining
> how these fields should be used.
>
> I need a way to refer to this document as either the semanticsIdentifier
> or the nameRegistrationAuthority.

As I see it, you shouldn't. The statementInfo component is optional. If
all you want to say is that you're conformant with syntax and semantics of
this document then you set the statementID to id-qcs-pkixQCSyntax-v1 and
leave out the statementInfo component. If there is some well-known OID
that defines semantics for a set of attributes and/or names used then
include the statementInfo component, and set the semanticsIdentifier
component. If you just want to name a registration authority then include
the statementInfo component and set its nameRegistrationAuthority
component. If you want to associate a name a registration authority with
semantics for certain attributes then set both components of the
SemanticsInformation.

I have tried to capture our thinking above, but I may have missed
something as we wrote this almost four years ago. Stefan, feel free to
correct me if I got something wring.

Did this help at all, Jim?

-- Magnus


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHJsgib092549 for <[e-mail]>; Wed, 17 Dec 2003 11:54:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBHJsfcl092548 for ietf-pkix-bks; Wed, 17 Dec 2003 11:54:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHJsfib092543 for <[e-mail]>; Wed, 17 Dec 2003 11:54:41 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id 72AC96A481; Wed, 17 Dec 2003 11:54:41 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Nystrom, Magnus'" <[e-mail]>, <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>
Subject: RE: Last Call: Qualified Certificates
Date: Wed, 17 Dec 2003 11:58:15 -0800
Message-ID: <003a01c3c4d8$1c2ff1b0$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <Pine.WNT.4.58.0312171017100.1484@mnystrom-lap>
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-----
> 
> Thanks for your review. I'll respond to a few of your 
> comments here. Stefan will address the others.
> 
> On November 12, Jim Schaad wrote:
> 
> > Comments on this draft are as follows:
> >
> > 1.  Section 1 para 3;  I object to the phrase "private extensions". 
> > This document does not defined private extensions even if 
> they exist 
> > in the id-pe arc.  These are now public extensions. -- 
> Remove the word 
> > private.
> 
> No, we are using the branch id-pe which specifically is named 
> "arc for private certificate extensions" in RFC 3280. As I 
> see it, private/public refers to presence in X.509 or not. 
> C.f. section 4.2.2 of RFC 3280, whose title even is "Private 
> Internet Extensions" (although the TOC in RFC 3280 lists 
> another name).

I understand that it is under the private extensions arc.  I belive that
the way this arc was named is not clear.  IMHO by publishing this
extension in a public document for public consumption it no longer is a
private extension.  I see no advantage to having the word private in
this location.

> 
> > 6.  Section 3.2.1 - DateOfBirth SHOULD state the proper 
> encoding to be 
> > used.  I.E. are we looking for seconds, minutes or hours or 
> just DATE 
> > in the GeneralTime field?
> 
> I don't see a need to do this for interoperability reasons. 
> The GeneralizedTime ASN.1 type will always contain a date, 
> and optionally a time down to a precision as specified in ISO 
> 8601. Relying parties will need to parse the type anyway. 
> Some registration authorities may decide to use a more 
> precise measurement than others and I would not want to 
> preclude them from doing so.

In order to do a DER encoding of a GeneralTime field, without other
restraints being placed on this field, I think (but have not verified)
that on ewould be required to specify the msecs thus leading to a date
such as 196012170000000000Z for the DOB.  Even cutting it off at the
same level as dates in RFC3280 is an improvement.

> 
> > 7.  Section 3.2.1 - countryOfResidence and 
> countryOfCitizenship - If 
> > you have multiple countrys to be listed, should this be a 
> multi-value 
> > item or should there be two distinct attributes? 
> (Alternatively should 
> > this be restricted back to a single attribute with a single value - 
> > i.e you can only list one of your countries of citizenship.)
> 
> The attributes (seen as ASN.1 objects) themselves are 
> multi-valued. This follows from PKCS #9 v2.0 where they are 
> fully defined and we have a reference to PKCS #9 in the 
> document about this. But this still allows several distinct 
> attributes each with a single (or multiple) value (values). 
> As the extension itself only is intended to carry information 
> from a directory about the subject of the certificate and 
> does not disallow multiple instances of the same attribute 
> type it is really up to the issuer and the way it stores 
> information about the subject to populate it. A conformant 
> relying party that relies on information provided in this 
> extension will need to parse the complete extension value 
> anyway, so again I am not sure anything needs to be done.

This makes my code harder to implement as a RP.  I now need to look for
both multiple values and multiple fields.  It is much simplier to only
need to look for one (probably from ease of programing it would be
multiple values).

> > 10. Sectin 3.2.5.1 - I have decided to put the predefined statement 
> > into my QC.  After reading this document I understand that 
> what I want 
> > stearts as follows:
> >
> > 	EXTENSION { id-pe-qcStatements,
> > 			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> > In this case I don't have asemanticsIdentifier created by the 
> > document, so I must be incoluding the NameRegistrationAuthorities 
> > otion.  However I don't know if what goes here is the pkix working 
> > group name or some other value.
> 
> I am not sure I understand your question Jim, but values for 
> the nameRegistrationAuthorities component has nothing to do 
> with PKIX. It is the OID for the authority responsible for 
> the subject's name (or attributes of the subject's name) as 
> it appears in the certificate. I thought this was clear from 
> 3.2.5.1?  Likewise for the semanticsIdentifier option - it is 
> to be specified by/for that authority.

LET ME QUOTE:

   --  This statement identifies conformance with syntax and
   --  semantics defined in this Qualified Certificate profile
   --  (Version 1). The SemanticsInformation may optionally contain
   --  additional semantics information as specified.

As I read this statement there should be an OID that identifies this
DOCUMENT as a name registration authority.  If I use the fields defined
by this document and use the defined OID in this document, then I need
to be able to correction encode this extension in my certificate without
reference to an external naming authority.  If this is not the case then
there is absolutely no reason to have section 3.1 or 3.2.1, 3.2.2, 3.2.3
or 3.2.4 as they are defining how these fields should be used.

I need a way to refer to this document as either the semanticsIdentifier
or the nameRegistrationAuthority.


> 
> > 11.  Sectin A.1 - I suggest changing the pretty name to 
> > PKIXqualified88-03 to distinquish from rfc3039.
> 
> I don't quite see why? Normally you keep the module name but 
> update the number (OID), and there are some reasons for this 
> too. C.f. X.509's "AuthenticationFramework" module whose name 
> has remained the same even though the module OID has changed 
> over the years. I believe the same is true for 
> "PKIX1Explicit88" too, for example.
> 
> -- Magnus
> 

jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHGXJib082369 for <[e-mail]>; Wed, 17 Dec 2003 08:33:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBHGXJrB082368 for ietf-pkix-bks; Wed, 17 Dec 2003 08:33:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [192.6.10.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHGXHib082361 for <[e-mail]>; Wed, 17 Dec 2003 08:33:17 -0800 (PST) (envelope-from [e-mail])
Received: from CASASSAM2 (casassamont-m-2.hpl.hp.com [15.144.26.171]) by hplb.hpl.hp.com (8.12.10/8.12.10) with ESMTP id hBHGTGFT017629 for <[e-mail]>; Wed, 17 Dec 2003 16:29:16 GMT
From: "Marco Casassa Mont" <[e-mail]>
To: <[e-mail]>
Subject: RE: IDPKC
Date: Wed, 17 Dec 2003 16:29:19 -0000
Message-ID: <004d01c3c4ba$ec48c8e0$[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, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
X-HPL-MailScanner-Information: Please contact the helpdesk for more information
X-HPL-MailScanner: Found to be clean
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.

HP Labs in Bristol have been working on IDPKC for the last 2 years. 

We call it identifier-based encryption (IBE). Please find links to HPL
documentation at the end of this e-mail.

HP Labs have a full working (and optimised) implementation of IBE
cryptographic libraries. We ran a trial based on this technology with
the NHS (the UK Health Care Service).

IBE (IDPKC) is a cryptographic schema. We believe it is more appropriate
to compare IBE with public key cryptography rather than PKI (e.g. a
public key infrastructure). 

Keith Harrison is our lead researcher on IBE cryptography: he can
provide more detailed information. Marc, if you want to contact him,
please let me know.

Best Regards,
Marco Casassa Mont

---

1. *** HPL documents about IBE cryptography  follow:
A. HPL-2003-25
Identity based authenticated key agreement protocols from pairings Liqun
Chen and Caroline Kudla
http://www.hpl.hp.com/techreports/2003/HPL-2003-25.html

B. HPL-2003-48
Multiple trusted authorities in identifier based cryptography from
pairings on elliptic curves Liqun Chen and Keith Harrison
http://www.hpl.hp.com/techreports/2003/HPL-2003-48.html

C. HPL-2003-18
Certification of public keys within an identity based system Liqun Chen,
Keith Harrison, Andrew Moss, David Soldera and Nigel Smart
http://www.hpl.hp.com/techreports/2003/HPL-2003-18.html

D. HPL-2003-17
Applications of multiple trust authorities in pairing based
cryptosystems Liqun Chen, Keith Harrison, David Soldera and Nigel Smart
http://www.hpl.hp.com/techreports/2003/HPL-2003-17.html


2. *** Information about the NHS trial can be found at:
A. A Flexible Role-based Secure Messaging Service: Exploiting IBE
Technology in a Health Care Trial 
http://www.hpl.hp.com/research/papers/2003/messaging.html
http://www.hpl.hp.com/techreports/2003/HPL-2003-21.html

B. A presentation that goes into more detail about the trial and the
applied technology  
http://www-uk.hpl.hp.com/people/mcm/Documents/Papers/TrustBus2003-RSM-mc
m.ppt

C. Another one that talks more about the "problem space":
The NHS as a Proving Ground for Cryptosystems 
http://www.hpl.hp.com/techreports/2003/HPL-2003-203.html


3. *** Additional information about IBE applications can be found at: A.
HPL-2002-243  The HP Time Vault Service: Innovating the way confidential
information is disclosed, at the right time - Casassa Mont, 
 Marco; Harrison, Keith; Sadler, Martin 
 http://www.hpl.hp.com/techreports/2002/HPL-2002-243.html

B. HPL-2003-49
Towards Accountable Management of Identity and Privacy:
Sticky Policies and Enforceable Tracing Services - Casassa 
Mont, Marco; Pearson, Siani; Bramhall, Pete 
http://www.hpl.hp.com/techreports/2003/HPL-2003-49.html
 
C. HPL-2003-101
IBE Applied to Privacy and Identity Management - Casassa
Mont, Marco; Bramhall, Pete 
http://www.hpl.hp.com/techreports/2003/HPL-2003-101.html



========================================================================
=
 Marco Casassa Mont
 Trusted Systems Laboratory                  +++++++++++++++++++++++++++
 Hewlett-Packard Laboratories                +++++++   _/        +++++++
 Filton Road, Stoke Gifford                  +++++    _/           +++++
 BRISTOL, BS34 8QZ, UK.                      ++++    _/_/_/  _/_/_/ ++++
                                             +++    _/  _/  _/  _/   +++
 Phone:  [phone] (direct)           ++++  _/  _/  _/_/_/   ++++
 Telnet: 312 8794                            +++++        _/       +++++
 Fax:    [phone]                    +++++++     _/      +++++++
 Email:  [e-mail]           +++++++++++++++++++++++++++
========================================================================
=
        External HomePage: http://www-uk.hpl.hp.com/people/mcm/
========================================================================
=
    'All points of view are my own and not necessarily HP's as well'
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Marc Poulaud
> Sent: 16 December 2003 16:29
> To: [e-mail]
> Subject: IDPKC
> 
> 
> Hi,
> 
> Appreciating this a PKI group, I wanted to know if there is 
> any knowledge of, or experience in IDPKC vs PKI. My intention 
> is not to start a religious war, but just understand if there 
> is anything approaching a consensus view. Also, does anybody 
> know of any real/serious implementations of IDPKC. I'll take 
> private emails, if people feel it's off topic.
> 
> Marc.
> iSolve Ltd.
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHFjkib080067 for <[e-mail]>; Wed, 17 Dec 2003 07:45:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBHFjk0I080065 for ietf-pkix-bks; Wed, 17 Dec 2003 07:45:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBHFjiib080060 for <[e-mail]>; Wed, 17 Dec 2003 07:45:45 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 3787 invoked by uid 0); 17 Dec 2003 15:45:41 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.165.217) by woodstock.binhost.com with SMTP; 17 Dec 2003 15:45:41 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 17 Dec 2003 10:45:42 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: DN Encoding by UTF8String
Cc: [e-mail]
In-Reply-To: <[e-mail]>
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>

It is not clear that a son-of-rfc3280 is needed.  I believe that an update 
addressing this one aspect of the document can be generated much more 
quickly than reopening the whole document.  I believe that speedy 
resolution is desirable for all concerned.

Russ

At 11:39 AM 12/17/2003 +0900, Masaki SHIMAOKA wrote:
>How will son of RFC3280 address this UTF8Sting issue which is described
>at clause 4.1.2.4 in RFC3280?



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBH9Jtib047240 for <[e-mail]>; Wed, 17 Dec 2003 01:19:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBH9Jtlv047239 for ietf-pkix-bks; Wed, 17 Dec 2003 01:19:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBH9Jrib047226 for <[e-mail]>; Wed, 17 Dec 2003 01:19:54 -0800 (PST) (envelope-from [e-mail])
Received: from ebola.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with ESMTP; Wed, 17 Dec 2003 04:19:54 -0500
Received: from sdtihq24.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.12.10/NULL) with ESMTP id hBH9Jj1i018558 for <[e-mail]>; Wed, 17 Dec 2003 04:19:45 -0500 (EST)
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.100.8.217]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id hBH9Jqsj012012 for <[e-mail]>; Wed, 17 Dec 2003 04:19:52 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2657.72) id <W335R1BX>; Wed, 17 Dec 2003 04:19:35 -0500
Received: from olsson-lap.eu.rsa.net (MNYSTROM-LAP [10.129.13.13]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id W4Q49ZWT; Wed, 17 Dec 2003 01:19:48 -0800
From: "Nystrom, Magnus" <[e-mail]>
Reply-To: "Nystrom, Magnus" <[e-mail]>
To: [e-mail]
Cc: Stefan Santesson <[e-mail]>
Date: Wed, 17 Dec 2003 10:19:24 +0100 (W. Europe Standard Time)
Subject: RE: Last Call: Qualified Certificates
Message-ID: <Pine.WNT.4.58.0312171017100.1484@mnystrom-lap>
X-X-Sender: [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>

Jim,

Thanks for your review. I'll respond to a few of your comments here.
Stefan will address the others.

On November 12, Jim Schaad wrote:

> Comments on this draft are as follows:
>
> 1.  Section 1 para 3;  I object to the phrase "private extensions".
> This document does not defined private extensions even if they exist in
> the id-pe arc.  These are now public extensions. -- Remove the word
> private.

No, we are using the branch id-pe which specifically is named "arc for
private certificate extensions" in RFC 3280. As I see it, private/public
refers to presence in X.509 or not. C.f. section 4.2.2 of RFC 3280,
whose title even is "Private Internet Extensions" (although the TOC in
RFC 3280 lists another name).

> 2.  Section 1 para 3: Remove all references to 1993 ASN.1

Russ has approved to keeping it (but, as we already do, keep the 1988
syntax normative). It will be 1997 ASN.1 syntax, BTW.

> 6.  Section 3.2.1 - DateOfBirth SHOULD state the proper encoding to be
> used.  I.E. are we looking for seconds, minutes or hours or just DATE in
> the GeneralTime field?

I don't see a need to do this for interoperability reasons. The
GeneralizedTime ASN.1 type will always contain a date, and optionally
a time down to a precision as specified in ISO 8601. Relying parties
will need to parse the type anyway. Some registration authorities may
decide to use a more precise measurement than others and I would not
want to preclude them from doing so.

> 7.  Section 3.2.1 - countryOfResidence and countryOfCitizenship - If you
> have multiple countrys to be listed, should this be a multi-value item
> or should there be two distinct attributes? (Alternatively should this
> be restricted back to a single attribute with a single value - i.e you
> can only list one of your countries of citizenship.)

The attributes (seen as ASN.1 objects) themselves are
multi-valued. This follows from PKCS #9 v2.0 where they are fully
defined and we have a reference to PKCS #9 in the document about
this. But this still allows several distinct attributes each with a
single (or multiple) value (values). As the extension itself only is
intended to carry information from a directory about the subject of
the certificate and does not disallow multiple instances of the same
attribute type it is really up to the issuer and the way it stores
information about the subject to populate it. A conformant relying
party that relies on information provided in this extension will need
to parse the complete extension value anyway, so again I am not sure
anything needs to be done.

> 9.  Section 3.2.5.1 - I would like to know the reason that qcstatement-1
> has not been updated to a new OID.  This is a new draft document with
> some different semantics than 3039.  Are these changes all suffiently
> small that a new policy is not needed?

Thanks, we have discussed this and intend to assign a new OID.

> 10. Sectin 3.2.5.1 - I have decided to put the predefined statement into
> my QC.  After reading this document I understand that what I want
> stearts as follows:
>
> 	EXTENSION { id-pe-qcStatements,
> 			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> In this case I don't have asemanticsIdentifier created by the document,
> so I must be incoluding the NameRegistrationAuthorities otion.  However
> I don't know if what goes here is the pkix working group name or some
> other value.

I am not sure I understand your question Jim, but values for the
nameRegistrationAuthorities component has nothing to do with PKIX. It is
the OID for the authority responsible for the subject's name (or
attributes of the subject's name) as it appears in the certificate. I
thought this was clear from 3.2.5.1?  Likewise for the semanticsIdentifier
option - it is to be specified by/for that authority.

> 11.  Sectin A.1 - I suggest changing the pretty name to
> PKIXqualified88-03 to distinquish from rfc3039.

I don't quite see why? Normally you keep the module name but update
the number (OID), and there are some reasons for this
too. C.f. X.509's "AuthenticationFramework" module whose name has
remained the same even though the module OID has changed over the
years. I believe the same is true for "PKIX1Explicit88" too, for
example.

-- Magnus


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBH2dnib067304 for <[e-mail]>; Tue, 16 Dec 2003 18:39:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBH2dnM9067303 for ietf-pkix-bks; Tue, 16 Dec 2003 18:39:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan02.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBH2dkib067297 for <[e-mail]>; Tue, 16 Dec 2003 18:39:47 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 21699 invoked by alias); 17 Dec 2003 02:39:47 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 21681 invoked by alias); 17 Dec 2003 02:39:46 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 17 Dec 2003 02:39:46 -0000
Received: (qmail 13586 invoked from network); 17 Dec 2003 02:39:45 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 17 Dec 2003 02:39:45 -0000
Date: Wed, 17 Dec 2003 11:39:48 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: Tim Polk <[e-mail]>
Subject: Re[2]: DN Encoding by UTF8String
Cc: Richard Levitte - VMS Whacker <[e-mail]>, [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
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>

Tim,

> meet."  So we required, at a minimum, support for a straight binary 
> comparison but we permit an implementation to do more...

> RFC 3280 is silent with respect to emailAddress.  RFC 3280 requires space 
> normalization and a case insensitive compare for PrintableString.  For 
> other types, a straight binary comparison is the minimum but more complex 
> name comparison is permitted...

Basically I agree with your simple requirement as binary comparison, but
I do not prefer to permit other implementation.
When we have two implementations, one may make false-positive even
though other makes false-negative.
If we allow to some implementations, we MUST get to keep same result of
name-comparison.

Such my concept consents with your observation below, does not it?

> General observation #1:  implementing additional name comparison should not 
> create *new* problems.  



> I don't think RFC 3280 is too much at odds with the OpenSSL implementation 
> or Peter's guidance.  However, I should note that name comparison for 
> directory strings encoded in UTF8STRING is a task we have been directed to 
> tackle by the IESG.    As the name comparison work progresses in the IETF, 
> the PKIX WG intends to have a document that describes the "right way" to 
> perform such a comparison.

I am pleased that PKIX is tackling such work.

Now I have one question.
How will son of RFC3280 address this UTF8Sting issue which is described
at clause 4.1.2.4 in RFC3280?

Thanks,
-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGLlqib056218 for <[e-mail]>; Tue, 16 Dec 2003 13:47:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBGLlqwf056217 for ietf-pkix-bks; Tue, 16 Dec 2003 13:47:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGLlpib056212 for <[e-mail]>; Tue, 16 Dec 2003 13:47:51 -0800 (PST) (envelope-from [e-mail])
Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AWMr3-0001lu-PC; Tue, 16 Dec 2003 16:35:45 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, <[e-mail]>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure:  Logotypes in X.509 certificates' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Tue, 16 Dec 2003 16:35:45 -0500
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 IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure: Logotypes in X.509 certificates '
   <draft-ietf-pkix-logotypes-13.txt> as a Proposed Standard

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

The IESG contact persons are Steve Bellovin and Russ Housley.

Technical Summary

This document provides for a way to embed visual or audible logos within 
X.509 certificates.

Working Group Summary

There was initially some controversy about whether or not these extensions 
were reasonable.  Eventually, the working group agreed that they were a good 
ida.

Protocol Quality,

This specification has been reviewed for the IESG by Steve Bellovin.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGK0aib051968 for <[e-mail]>; Tue, 16 Dec 2003 12:00:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBGK0a0S051967 for ietf-pkix-bks; Tue, 16 Dec 2003 12:00:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGK0Zib051960 for <[e-mail]>; Tue, 16 Dec 2003 12:00:35 -0800 (PST) (envelope-from [e-mail])
Received: from ambarisht40 (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id hBGJxvOD024481; Tue, 16 Dec 2003 11:59:57 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "'Marc Poulaud'" <[e-mail]>, <[e-mail]>
Subject: RE: IDPKC
Date: Tue, 16 Dec 2003 11:58:33 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

There is a company in the SF Bay Area that is developing
products around it - Voltage Security (www.voltage.com).

Regards,
Ambarish

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Marc Poulaud
> Sent: Tuesday, December 16, 2003 8:29 AM
> To: [e-mail]
> Subject: IDPKC
> 
> 
> Hi,
> 
> Appreciating this a PKI group, I wanted to know if there is 
> any knowledge of, or experience in IDPKC vs PKI. My intention 
> is not to start a religious war, but just understand if there 
> is anything approaching a consensus view. Also, does anybody 
> know of any real/serious implementations of IDPKC. I'll take 
> private emails, if people feel it's off topic.
> 
> Marc.
> iSolve Ltd.
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGJVAib050831 for <[e-mail]>; Tue, 16 Dec 2003 11:31:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBGJVAOD050830 for ietf-pkix-bks; Tue, 16 Dec 2003 11:31:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from real2.localdomain (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGJV7ib050825 for <[e-mail]>; Tue, 16 Dec 2003 11:31:08 -0800 (PST) (envelope-from [e-mail])
Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by real2.localdomain (8.12.8/8.12.8) with ESMTP id hBGJUvqv008227; Tue, 16 Dec 2003 14:30:57 -0500
Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id hBGJUuQc008225; Tue, 16 Dec 2003 14:30:56 -0500
Received: from 142.131.210.159 ([142.131.210.159])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Tue, 16 Dec 2003 14:30:56 -0500
Message-ID: <[e-mail]>
Date: Tue, 16 Dec 2003 14:30:56 -0500
From: [e-mail]
To: [e-mail]
Cc: "'Stephen Kent'" <[e-mail]>, [e-mail], Jim Schaad <[e-mail]>, Russ Housley <[e-mail]>, Burt Kaliski <[e-mail]>
Subject: WG Last Call: Additional Algorithms for RSA cryptography
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 142.131.210.159
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 initiates working group Last Call for "Additional Algorithms and 
Identifiers for RSA Cryptography". As a reminder, here is the Abstract:

   This document supplements RFC 3279.  It describes the conventions 
   for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key 
   transport algorithm and additional one-way hash functions with the 
   PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public 
   Key Infrastructure (PKI).  Encoding formats, algorithm identifiers, 
   and parameter formats are specified. 

This is a three week Last Call.  That means it will close sometime on or after 
January 9, 2004.   The schedule has been padded with an additional week in 
light of the holidays. 

** Do not count on any further extension to Last Call!!! **

I intend to close Last Call promptly on January 9, since an S/MIME WG document 
is blocked on this document.

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

Thanks,

Tim Polk


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGGTsib042996 for <[e-mail]>; Tue, 16 Dec 2003 08:29:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBGGTsUr042995 for ietf-pkix-bks; Tue, 16 Dec 2003 08:29:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGGTqib042986 for <[e-mail]>; Tue, 16 Dec 2003 08:29:53 -0800 (PST) (envelope-from [e-mail])
Received: from f67j40j ([213.106.136.69]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with SMTP id <20031216162942.NWWE14657.mta03-svc.ntlworld.com@f67j40j> for <[e-mail]>; Tue, 16 Dec 2003 16:29:42 +0000
From: "Marc Poulaud" <[e-mail]>
To: <[e-mail]>
Subject: IDPKC
Date: Tue, 16 Dec 2003 16:29:19 -0000
MIME-Version: 1.0
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_009A_01C3C3F1.BE8CD0A0"
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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_009A_01C3C3F1.BE8CD0A0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi,

Appreciating this a PKI group, I wanted to know if there is any knowledge
of, or experience in IDPKC vs PKI. My intention is not to start a
religious war, but just understand if there is anything approaching a
consensus view. Also, does anybody know of any real/serious
implementations of IDPKC. I'll take private emails, if people feel it's
off topic.

Marc.
iSolve Ltd.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKNzCCAj0w
ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH
mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF
4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d
6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix
3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR
cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy
MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL
uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj
zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw
RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD
gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h
U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1
E3LnQDGa07LEq+dWvovj+xUwggSMMIID9aADAgECAhAtlXDAy5i9knYT7IgJAnYKMA0GCSqGSIb3
DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkyOTAwMDAw
MFoXDTA0MTAwNjIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0
b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs
bCBTZXJ2aWNlMRUwEwYDVQQDFAxNYXJjIFBvdWxhdWQxKTAnBgkqhkiG9w0BCQEWGm1hcmMucG91
bGF1ZEBpLXNvbHZlLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBvykQe6DixFIm
woyNNcyuPw4BfYerTnR5n2Oz0dHqZm2/hAibGgMl2CQ0+nHbptHBKawRcpHmnUjHHKSE8QuqBkHn
y2w/hkbTOFMSSYheTDInnSsFHAFzgqgkEl29sgrnjTDeVWPTi3Oq3USCoFMJGEXIwgtptIMkfy1X
eITxjwIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB
ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC
AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm
ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCG
SAGG+EUBBgcEBhYETm9uZTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBACqNEGz/TyikJW9YzH0FIiHycPGhdzkpt20D
N+EGqqqornHRoNT1409BIp18aGktYiQnf9qMOCWbXCdOL2K18ISbDsufYxEDogOeIVq/WU63Bt0A
j0B8IR7PNp+Qsx/BxxNhya123Qd+vwOYvxS+AiFrgOQsXqdnySEODaeAje1ZMYIDVjCCA1ICAQEw
geEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2
aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEC2VcMDLmL2SdhPsiAkCdgow
CQYFKw4DAhoFAKCCAcowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MDMxMjE2MTYyOTE0WjAjBgkqhkiG9w0BCQQxFgQUXhgSorWHE2AqfOobJKbZ6UIw/T8wdgYJKoZI
hvcNAQkPMWkwZzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwBwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwBwYFKw4DAhowBwYFKw4DAhowCgYIKoZIhvcNAgUwCgYIKoZIhvcNAgUw
gfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQ
LZVwwMuYvZJ2E+yICQJ2CjANBgkqhkiG9w0BAQEFAASBgGAGPvjhNlkMkd1Q3AHATlk5QxkRRoO+
k8pjY+spYlyBa0L1kQ4EojlklDIgMugfQukAuZWC44CtEuGgJhnYxqYRjdPt4saIIlmX3U3XO4mV
v6RCsjNkFz2UiCAi+u76f/HbdI7ox9e81XY+GGcvky/sQHEMTQ822/1r7BYA7F7zAAAAAAAA

------=_NextPart_000_009A_01C3C3F1.BE8CD0A0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBG1L5ib028248 for <[e-mail]>; Mon, 15 Dec 2003 17:21:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBG1L5Sc028247 for ietf-pkix-bks; Mon, 15 Dec 2003 17:21:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBG1L3ib028241 for <[e-mail]>; Mon, 15 Dec 2003 17:21:03 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=drh-consultancy.co.uk) by anchor-post-31.mail.demon.net with esmtp (Exim 3.35 #1) id 1AW3tW-000G5S-0V for [e-mail]; Tue, 16 Dec 2003 01:21:03 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Dec 2003 01:21:18 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DN Encoding by UTF8String
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.7.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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>

Since this partly relates to OpenSSLs ASN1 handling I feel compelled to 
reply :-)

Richard Levitte - VMS Whacker wrote:

> In message <[e-mail]> on Tue, 16 Dec 2003 00:22:09 +1300, [e-mail] (Peter Gutmann) said:
> 
> pgut001> Hmm, I don't know if it's a good idea to encourage this sort
> pgut001> of behaviour (that is, apps that generate certs that require
> pgut001> custom code in order to work).  Some years ago (after I
> pgut001> snapped out of my X.520 delusion and switched to memcmp()) a
> pgut001> vendor complained that cryptlib was failing to find a cert
> pgut001> with a canonicalised name.  I told them to try the same thing
> pgut001> with Netscape and MSIE, and fairly soon afterwards (within a
> pgut001> matter of days, I think) they had a service release out that
> pgut001> didn't try and modify names any more.
> 
> I just figured out a specific example where you might need to use
> X.520 comparison rules (or at least the rules outlined by RFC3280).
> At least with OpenSSL, it's possible to restrict what certificates
> 'openssl ca' can issue by configuring some parts of the requested
> subject in the CSR match the same parts of the subject in the signing
> CA certificate.  So to take Tim's example with 'C=MX' vs. 'C=mx', a CA
> that is only allowed to issue certificates with C=MX, and does the
> same kind of enforcement OpenSSL can do, it would have to be able to
> match the country code regardless of case (and provided an encoding
> where the case-insensitive matching rule applies).  I don't really see
> a way out of the possibility of this happening.
> 

Whilst that is true, OpenSSL's normal handling of DNs in the X509_NAME 
structure will preserve the original encoding. SSLeay did this also.

This effectively means that when a DN is copied when a certificate is 
issued the encoding is preserved between the CAs subject name and the 
issued certificates issuer name.

I've only ever come across two obscure certificates (other than in test 
suites) where two matching DNs did not have the same encoding.

IIRC one was a PrintableString case variation which would fit the 
RFC3280 comparison rules. The other changed the string type from 
PrintableString to T61 which would require the X520 comparison. Both 
were horribly broken in that they were supposed to be valid CA 
certificate but they didn't include a basicConstraints extension.

I'd be interested to know how common these (i.e. matching DNs with 
different encodings) are and how many people have come across them.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFNi1ib024364 for <[e-mail]>; Mon, 15 Dec 2003 15:44:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFNi1s0024363 for ietf-pkix-bks; Mon, 15 Dec 2003 15:44:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFNhxib024358 for <[e-mail]>; Mon, 15 Dec 2003 15:44:00 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Tue, 16 Dec 2003 00:43:40 +0100
Date: Tue, 16 Dec 2003 00:43:38 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: DN Encoding by UTF8String
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
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 message <[e-mail]> on Tue, 16 Dec 2003 00:22:09 +1300, [e-mail] (Peter Gutmann) said:

pgut001> Hmm, I don't know if it's a good idea to encourage this sort
pgut001> of behaviour (that is, apps that generate certs that require
pgut001> custom code in order to work).  Some years ago (after I
pgut001> snapped out of my X.520 delusion and switched to memcmp()) a
pgut001> vendor complained that cryptlib was failing to find a cert
pgut001> with a canonicalised name.  I told them to try the same thing
pgut001> with Netscape and MSIE, and fairly soon afterwards (within a
pgut001> matter of days, I think) they had a service release out that
pgut001> didn't try and modify names any more.

I just figured out a specific example where you might need to use
X.520 comparison rules (or at least the rules outlined by RFC3280).
At least with OpenSSL, it's possible to restrict what certificates
'openssl ca' can issue by configuring some parts of the requested
subject in the CSR match the same parts of the subject in the signing
CA certificate.  So to take Tim's example with 'C=MX' vs. 'C=mx', a CA
that is only allowed to issue certificates with C=MX, and does the
same kind of enforcement OpenSSL can do, it would have to be able to
match the country code regardless of case (and provided an encoding
where the case-insensitive matching rule applies).  I don't really see
a way out of the possibility of this happening.

Of course, there's the thought that it's better with a few false
negatives than a few false positives, as Tim pointed out...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFNGBib023611 for <[e-mail]>; Mon, 15 Dec 2003 15:16:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFNGBM6023610 for ietf-pkix-bks; Mon, 15 Dec 2003 15:16:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFNG8ib023602 for <[e-mail]>; Mon, 15 Dec 2003 15:16:08 -0800 (PST) (envelope-from [e-mail])
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id hBFNFUjP021447; Mon, 15 Dec 2003 18:15:31 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Dec 2003 18:15:48 -0500
To: Richard Levitte - VMS Whacker <[e-mail]>, [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: DN Encoding by UTF8String
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

Name comparison is definitely a thorny problem.  The name comparison rules 
in RFC 2459 and 3280 were an attempt to establish a reasonable bar that 
current implementations already met, or could easily meet.

2459 and 3280 require white space compression and case-insensitive match 
for PrintableString because client implementations already met this 
standard.  It is also very easy - strings never get longer and a single 
pass is all one ever needs to prepare for the comparison.  (In fact you 
could probably compare in a single pass, normalizing as you go!)

This functionality is expected to be present, and is reflected by the 
content of existing certificates.  For example, the country code is 
sometimes uppercase and sometimes lower case.  Implementations that only 
performed case sensitive matching would not interpret "C=mx" and "C=MX" as 
equivalent.

On the other hand, normalization for more complex character sets is fraught 
with danger.  Strings can actually grow during this process, several passes 
may be required, etc...  Name comparison for these character sets was *not* 
"a reasonable bar that current implementations already met, or could easily 
meet."  So we required, at a minimum, support for a straight binary 
comparison but we permit an implementation to do more...

Some specific comments:

Peter noted:
 > I found out very quickly that one thing you never, ever do is
 > change the DN encoding once it's been created by the
 > originator

Basically, I would agree.  This is reflected by the RFC 3280 requirement 
that the encoding of an established CA's name be preserved when issuing CA 
certs.  Depending upon clients to perform string normalization accurately 
and consistently is risky.  No matter what they do (or don't) implement, 
preserving the encoding should provide dependable results.

Richard stated:
 > OpenSSL provides a limit set of rules for comparing DNs: it does
 > space normalization and a case insensitive compare for PrintableString,
 > and case insensitive comparison for IA5String if the attribute type is
 > emailAddress from pkcs#9. For all other strings, a straight memcmp()
 > is done. Would you say we're going overkill?

RFC 3280 is silent with respect to emailAddress.  RFC 3280 requires space 
normalization and a case insensitive compare for PrintableString.  For 
other types, a straight binary comparison is the minimum but more complex 
name comparison is permitted...

General observation #1:  implementing additional name comparison should not 
create *new* problems.  I see three cases.   Case 1: If the two strings 
match for binary comparison, then they will match afterwards.  (However, 
you may get the blue screen of death if the strings grow beyond the 
expected size and overwrite something it shouldn't!)  Case 2: Consider two 
strings that are a theoretical match but were encoded in different binary 
forms - if the name comparison rules detect the match, that's great; if not 
well you didn't make the situation worse.  Case 3: Only if two 
theoretically different string get munged by the normalization process and 
become inappropriately equivalent would you have a real problem.  Case 3 
failure seems the less likely than case 2, in my opinion...

General Observation #2:  False positives are more dangerous than false 
negatives... the one place name comparison can result in name 
constraints.  An inappropriate match for permitted subtrees could result in 
a false positive.  An inappropriate non-match for excluded subtrees could 
result in a false positive.  If you buy my theory that case 2 failure is 
more likely than case 3, that says you should use permitted subtrees where 
ever possible.  It also says that for either type of constraint, you should 
respect the encoding of the attributes by the issuer.

I don't think RFC 3280 is too much at odds with the OpenSSL implementation 
or Peter's guidance.  However, I should note that name comparison for 
directory strings encoded in UTF8STRING is a task we have been directed to 
tackle by the IESG.    As the name comparison work progresses in the IETF, 
the PKIX WG intends to have a document that describes the "right way" to 
perform such a comparison.

Thanks,

Tim Polk

At 12:43 PM 12/15/2003 +0100, Richard Levitte - VMS Whacker wrote:

>In message <[e-mail]> on Tue, 16 Dec 
>2003 00:22:09 +1300, [e-mail] (Peter Gutmann) said:
>
>pgut001> Richard Levitte - VMS Whacker <[e-mail]> writes:
>pgut001>
>pgut001> >OpenSSL provides a limit set of rules for comparing DNs: it
>pgut001> >does space normalization and a case insensitive compare for
>pgut001> >PrintableString, and case insensitive comparison for
>pgut001> >IA5String if the attribute type is emailAddress from pkcs#9.
>pgut001> >For all other strings, a straight memcmp() is done.  Would
>pgut001> >you say we're going overkill?
>pgut001>
>pgut001> Hmm, I don't know if it's a good idea to encourage this sort
>pgut001> of behaviour (that is, apps that generate certs that require
>pgut001> custom code in order to work).  Some years ago (after I
>pgut001> snapped out of my X.520 delusion and switched to memcmp()) a
>pgut001> vendor complained that cryptlib was failing to find a cert
>pgut001> with a canonicalised name.  I told them to try the same thing
>pgut001> with Netscape and MSIE, and fairly soon afterwards (within a
>pgut001> matter of days, I think) they had a service release out that
>pgut001> didn't try and modify names any more.
>pgut001>
>pgut001> If cryptlib had still been using the X.520 comparison at that
>pgut001> time, they might have gone ahead and deployed a product that
>pgut001> failed in the field once it was exposed to other
>pgut001> implementations.  Better to be strict and let darwinism do
>pgut001> its work.  If Netscape had been less lenient about accepting
>pgut001> all kinds of broken HTML, it wouldn't have encouraged the
>pgut001> spread of apps that generate the broken HTML.
>
>I understand your thoughts, and I agree that following the KISS
>principle (does anyone need that explained?) is tempting.  However,
>I'd say that your comparison between non-compliance with X.520
>comparison rules and Netscape's boken HTML is flawed.  On one hand,
>from the point of view of X.520, MSIE and Netscape are broken since
>they don't follow the rules, and that's what you want to encourage.
>On the other hand, Netscape's acceptance of some HTML was also broken
>from the point of view of HTML, and you seem to want to discourage
>that.  The conclusion is that you support breaking the rules in some
>cases, while not in others.  That doesn't seem very consistent to
>me...
>
>Now from the point of view of "this makes sense", I can understand
>your views, but I have to ask "from whose point of view?"  Is everyone
>accepting Peter Gutmann as an authority?  I can accept that if that's
>the common rule :-).
>
>pgut001> >I'm not sure about that, since those special cases were
>pgut001> >added fairly recently, after we got some user complaint, and
>pgut001> >possibly after I had a run with the NIST PKI test bunch...
>pgut001>
>pgut001> Are those test certs representative of real-world usage
>pgut001> though?
>
>Considering it's NIST we're talking about, I wouldn't be surprised if
>there are some US gov. examples behind those tests...
>
>-----
>Please consider sponsoring my work on free software.
>See http://www.free.lp.se/sponsoring.html for details.
>You don't have to be rich, a $10 donation is appreciated!
>
>--
>Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
>Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
>T: [phone] |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFHu9ib008773 for <[e-mail]>; Mon, 15 Dec 2003 09:56:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFHu9rA008772 for ietf-pkix-bks; Mon, 15 Dec 2003 09:56:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFHu6ib008763 for <[e-mail]>; Mon, 15 Dec 2003 09:56:08 -0800 (PST) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id hBFHu7G5023906; Mon, 15 Dec 2003 09:56:07 -0800 (PST)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <Y50BZK22>; Mon, 15 Dec 2003 09:56:07 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "Deacon, Alex" <[e-mail]>, Tom Gindin <[e-mail]>
Cc: [e-mail]
Subject: RE: DISCUSS:  MUST reject in OCSPv1
Date: Mon, 15 Dec 2003 09:56:04 -0800
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>

Mike,


> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]] 
> Sent: Monday, December 15, 2003 9:54 AM
> To: Deacon, Alex; Tom Gindin
> Cc: [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> > -----Original Message-----
> > From: Deacon, Alex [mailto:[e-mail]]
> > Sent: Monday, December 15, 2003 10:21 AM
> >
> > As I mentioned earlier, it will be important to
> > clarify this case as clients using piggybacked
> > OCSPResponses (such as those implementing the TLS
> > extension) may receive a response that contains a
> > nonce (the one the server generated) event though
> > they did not send one.
> 
> Alex,
> 
> To be clear, are you referring to server-unilateral nonces?

No.

> 
> Or to the fact that a TLS server may have in cache a nonced 
> response (retained as a consequence of a prior nonced 
> request) that it sends back in the TLS handshake even though 
> the TLS client did not supply a nonce in its embedded OCSP request?

Yes...this is what I was referring to.  

Alex

 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFHqHib008427 for <[e-mail]>; Mon, 15 Dec 2003 09:52:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFHqHjg008426 for ietf-pkix-bks; Mon, 15 Dec 2003 09:52:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFHqGib008420 for <[e-mail]>; Mon, 15 Dec 2003 09:52:16 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hBFHqDn25304; Mon, 15 Dec 2003 10:52:13 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Deacon, Alex" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DISCUSS:  MUST reject in OCSPv1
Date: Mon, 15 Dec 2003 10:54:10 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE 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>

> -----Original Message-----
> From: Deacon, Alex [mailto:[e-mail]]
> Sent: Monday, December 15, 2003 10:21 AM
>
> As I mentioned earlier, it will be important to
> clarify this case as clients using piggybacked
> OCSPResponses (such as those implementing the TLS
> extension) may receive a response that contains a
> nonce (the one the server generated) event though
> they did not send one.

Alex,

To be clear, are you referring to server-unilateral nonces?

Or to the fact that a TLS server may have in cache a nonced
response (retained as a consequence of a prior nonced request)
that it sends back in the TLS handshake even though the TLS
client did not supply a nonce in its embedded OCSP request?

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFHL1ib006231 for <[e-mail]>; Mon, 15 Dec 2003 09:21:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFHL1dC006230 for ietf-pkix-bks; Mon, 15 Dec 2003 09:21:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFHL1ib006225 for <[e-mail]>; Mon, 15 Dec 2003 09:21:01 -0800 (PST) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id hBFHL1G5015616; Mon, 15 Dec 2003 09:21:01 -0800 (PST)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <Y50BZHQ5>; Mon, 15 Dec 2003 09:21:01 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, Tom Gindin <[e-mail]>
Cc: [e-mail]
Subject: RE: DISCUSS:  MUST reject in OCSPv1
Date: Mon, 15 Dec 2003 09:20:48 -0800
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>

Mike,

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]] 
[snip]
> 
> Tom,
> 
> We may be saying the same thing:
> 
> if( req->sent_nonce != rsp->rcvd_nonce )
>    fail( BADNONCE )
> else
>    proceed( rsp );
> 
> The more interesting question along these lines is the one 
> regarding Florian's server-unilateral nonces.  I.e. a client 
> receives a nonce extension in the response even though the 
> client didn't provide a nonce extension in its request.  
> While I'm not yet convinced of this practice's security 
> value, I see no reason to preclude it in our forthcoming 
> clarification regarding nonces.

As I mentioned earlier, it will be important to clarify this case as clients
using piggybacked OCSPResponses (such as those implementing the TLS
extension) may receive a response that contains a nonce (the one the server
generated) eventhough they did not send one.

Alex


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFBi8ib090881 for <[e-mail]>; Mon, 15 Dec 2003 03:44:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFBi8Km090880 for ietf-pkix-bks; Mon, 15 Dec 2003 03:44:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFBi4ib090874 for <[e-mail]>; Mon, 15 Dec 2003 03:44:06 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Mon, 15 Dec 2003 12:43:57 +0100
Date: Mon, 15 Dec 2003 12:43:54 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: DN Encoding by UTF8String
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
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 message <[e-mail]> on Tue, 16 Dec 2003 00:22:09 +1300, [e-mail] (Peter Gutmann) said:

pgut001> Richard Levitte - VMS Whacker <[e-mail]> writes:
pgut001> 
pgut001> >OpenSSL provides a limit set of rules for comparing DNs: it
pgut001> >does space normalization and a case insensitive compare for
pgut001> >PrintableString, and case insensitive comparison for
pgut001> >IA5String if the attribute type is emailAddress from pkcs#9.
pgut001> >For all other strings, a straight memcmp() is done.  Would
pgut001> >you say we're going overkill? 
pgut001> 
pgut001> Hmm, I don't know if it's a good idea to encourage this sort
pgut001> of behaviour (that is, apps that generate certs that require
pgut001> custom code in order to work).  Some years ago (after I
pgut001> snapped out of my X.520 delusion and switched to memcmp()) a
pgut001> vendor complained that cryptlib was failing to find a cert
pgut001> with a canonicalised name.  I told them to try the same thing
pgut001> with Netscape and MSIE, and fairly soon afterwards (within a
pgut001> matter of days, I think) they had a service release out that
pgut001> didn't try and modify names any more.
pgut001> 
pgut001> If cryptlib had still been using the X.520 comparison at that
pgut001> time, they might have gone ahead and deployed a product that
pgut001> failed in the field once it was exposed to other
pgut001> implementations.  Better to be strict and let darwinism do
pgut001> its work.  If Netscape had been less lenient about accepting
pgut001> all kinds of broken HTML, it wouldn't have encouraged the
pgut001> spread of apps that generate the broken HTML.

I understand your thoughts, and I agree that following the KISS
principle (does anyone need that explained?) is tempting.  However,
I'd say that your comparison between non-compliance with X.520
comparison rules and Netscape's boken HTML is flawed.  On one hand,
from the point of view of X.520, MSIE and Netscape are broken since
they don't follow the rules, and that's what you want to encourage.
On the other hand, Netscape's acceptance of some HTML was also broken
from the point of view of HTML, and you seem to want to discourage
that.  The conclusion is that you support breaking the rules in some
cases, while not in others.  That doesn't seem very consistent to
me...

Now from the point of view of "this makes sense", I can understand
your views, but I have to ask "from whose point of view?"  Is everyone
accepting Peter Gutmann as an authority?  I can accept that if that's
the common rule :-).

pgut001> >I'm not sure about that, since those special cases were
pgut001> >added fairly recently, after we got some user complaint, and
pgut001> >possibly after I had a run with the NIST PKI test bunch...
pgut001> 
pgut001> Are those test certs representative of real-world usage
pgut001> though?

Considering it's NIST we're talking about, I wouldn't be surprised if
there are some US gov. examples behind those tests...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFBMFib090106 for <[e-mail]>; Mon, 15 Dec 2003 03:22:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFBMFdl090105 for ietf-pkix-bks; Mon, 15 Dec 2003 03:22:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFBMBib090087 for <[e-mail]>; Mon, 15 Dec 2003 03:22:14 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id A28FB34096; Tue, 16 Dec 2003 00:21:21 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hBFBM9P15024; Tue, 16 Dec 2003 00:22:09 +1300
Date: Tue, 16 Dec 2003 00:22:09 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: DN Encoding by UTF8String
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>

Richard Levitte - VMS Whacker <[e-mail]> writes:

>OpenSSL provides a limit set of rules for comparing DNs: it does space
>normalization and a case insensitive compare for PrintableString, and case
>insensitive comparison for IA5String if the attribute type is emailAddress
>from pkcs#9.  For all other strings, a straight memcmp() is done.  Would you
>say we're going overkill?  

Hmm, I don't know if it's a good idea to encourage this sort of behaviour
(that is, apps that generate certs that require custom code in order to work).
Some years ago (after I snapped out of my X.520 delusion and switched to
memcmp()) a vendor complained that cryptlib was failing to find a cert with a
canonicalised name.  I told them to try the same thing with Netscape and MSIE,
and fairly soon afterwards (within a matter of days, I think) they had a
service release out that didn't try and modify names any more.

If cryptlib had still been using the X.520 comparison at that time, they might
have gone ahead and deployed a product that failed in the field once it was
exposed to other implementations.  Better to be strict and let darwinism do
its work.  If Netscape had been less lenient about accepting all kinds of
broken HTML, it wouldn't have encouraged the spread of apps that generate the
broken HTML.

>I'm not sure about that, since those special cases were added fairly
>recently, after we got some user complaint, and possibly after I had a run
>with the NIST PKI test bunch...

Are those test certs representative of real-world usage though?  There's a
danger of adding all sorts of special-case complexity that nothing (except
some artificial test vectors) ever exercise, which then comes back to bite you
later when there's some exploitable problem in there.  That's why I eventually
removed the X.520 comparison code, it's so complex (and complex in a system-
specific way, since you're dependant on different levels of i18n support on
different systems) that it'd be pretty much impossible to ever guarantee it
worked as required.  Guaranteeing the behaviour of memcmp() is much easier.

You could always enable a NIST-test-vector mode that uses ad-hoc fixups, and a
normal-use mode that uses memcmp().  In other words, make it explicit to the
user, through having to enable it via a #define or use a configure option,
that what they're doing is likely to cause problems down the track.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFA33ib083709 for <[e-mail]>; Mon, 15 Dec 2003 02:03:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFA33an083708 for ietf-pkix-bks; Mon, 15 Dec 2003 02:03:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFA31ib083671 for <[e-mail]>; Mon, 15 Dec 2003 02:03:01 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Mon, 15 Dec 2003 11:02:42 +0100
Date: Mon, 15 Dec 2003 11:02:40 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: DN Encoding by UTF8String
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
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 message <[e-mail]> on Mon, 15 Dec 2003 20:36:21 +1300, [e-mail] (Peter Gutmann) said:

pgut001>   subsequent users use memcpy() to "re-encode" the original
pgut001>     DN, and memcpy() to compare it;

I doubt that :-).

pgut001> In my early naivete about the real state of X.500 I actually
pgut001> tried to implement the X.520 name comparison rules some years
pgut001> ago (that's how the Style Guide entry on this came about).  I
pgut001> found out very quickly that one thing you never, ever do is
pgut001> change the DN encoding once it's been created by the
pgut001> originator (I originally stored the DN in canoncalised form,
pgut001> and had to change my code to cache the original DN so I could
pgut001> "encode" it with memcpy()).  A year or two after changing the
pgut001> encoding to memcpy() I #ifdef'd out the full DN comparison
pgut001> and replaced it with a memcmp() of the encoded form.  A year
pgut001> or two after that, I removed the X.520 comparison code
pgut001> entirely.  All it was was a potential source of trouble
pgut001> anyway, it was far too complex to rely on.  I haven't had any
pgut001> trouble since I switched to memcpy()/memcmp(), and it's been
pgut001> used in some really odd environments with all sorts of
pgut001> non-European character sets (cryptlib seems to be quite
pgut001> popular in Asia for some reason, possibly because it really
pgut001> goes out of its way to handle i18n, which means the i18n
pgut001> support got a lot of stress-testing).  In fact, exactly
pgut001> *because* of memcpy()/memcmp() it will work with absolutely
pgut001> anything: BMPString, T61String, T61String that's actually an
pgut001> 8859-1String, floating diacritics (how much other software
pgut001> can handle those?), UTFString, string types not even dreamed
pgut001> up yet.

Hmm.  OpenSSL provides a limit set of rules for comparing DNs: it does
space normalization and a case insensitive compare for PrintableString,
and case insensitive comparison for IA5String if the attribute type is
emailAddress from pkcs#9.  For all other strings, a straight memcmp()
is done.  Would you say we're going overkill?  I'm not sure about
that, since those special cases were added fairly recently, after we
got some user complaint, and possibly after I had a run with the NIST
PKI test bunch...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBF7aQib038021 for <[e-mail]>; Sun, 14 Dec 2003 23:36:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBF7aQdt038019 for ietf-pkix-bks; Sun, 14 Dec 2003 23:36:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBF7aMib037993 for <[e-mail]>; Sun, 14 Dec 2003 23:36:25 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id BA25434015; Mon, 15 Dec 2003 20:35:34 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hBF7aLJ14015; Mon, 15 Dec 2003 20:36:21 +1300
Date: Mon, 15 Dec 2003 20:36:21 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: DN Encoding by UTF8String
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>

Jean-Marc Desperrier <[e-mail]> writes:

>The problem is *not* for the low level crypto API to support UTF8String.
>Basically all API around do that.

Only newer ones do.  Some (e.g. Netscape 4.x) will not just fail to process
the string but actually crash the application when they encounter a
UTF8String.

>There's is detailled information about how memcpy() to encode and memcmp() to
>compare don't work as soon as anything more complex than printablestring is
>involved. 

Why not?  The encoding rules are:

  DN originator (e.g. client generating a cert request) encodes the DN in any
    way they see fit;
  subsequent users use memcpy() to "re-encode" the original DN, and memcpy()
    to compare it;

OK, that doesn't work for something odd like a directory lookup, but for
normal cert usage where all you care about is locating a cert or checking for
equality based on a DN, it's fine.

>And don't work also if you take into account anything from the full x520
>comparison rules.

... which don't work in practice (see the X.509 Style Guide), so it's not
really relevant.

>But this kind of comparaison being prevalent in application, the only
>solution to avoid problem is for the CA to normalize strictly every name
>before emitting certificates.

How well do you think that'll work in the presence of implementations that use
memcpy() and memcmp()?  Have you ever tried generating a cert request from
(say) IE and sending it to a CA that "strictly normalizes" the DN before
returning it?

(To save you the effort if you haven't done this, it'll be rejected by the
 client.  I'm just using IE as a common, easy-to-get-to example here, you can
 see the same thing with other software when you fiddle with DN encodings.
 Try signing an S/MIME message with the DN in the SignerInfo canonicalised to
 not match the cert DN).

In my early naivete about the real state of X.500 I actually tried to
implement the X.520 name comparison rules some years ago (that's how the Style
Guide entry on this came about).  I found out very quickly that one thing you
never, ever do is change the DN encoding once it's been created by the
originator (I originally stored the DN in canoncalised form, and had to change
my code to cache the original DN so I could "encode" it with memcpy()).  A
year or two after changing the encoding to memcpy() I #ifdef'd out the full DN
comparison and replaced it with a memcmp() of the encoded form.  A year or two
after that, I removed the X.520 comparison code entirely.  All it was was a
potential source of trouble anyway, it was far too complex to rely on.  I
haven't had any trouble since I switched to memcpy()/memcmp(), and it's been
used in some really odd environments with all sorts of non-European character
sets (cryptlib seems to be quite popular in Asia for some reason, possibly
because it really goes out of its way to handle i18n, which means the i18n
support got a lot of stress-testing).  In fact, exactly *because* of memcpy()
/memcmp() it will work with absolutely anything: BMPString, T61String,
T61String that's actually an 8859-1String, floating diacritics (how much other
software can handle those?), UTFString, string types not even dreamed up yet.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBD02nib031922 for <[e-mail]>; Fri, 12 Dec 2003 16:02:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBD02nJY031921 for ietf-pkix-bks; Fri, 12 Dec 2003 16:02:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBD02mib031916 for <[e-mail]>; Fri, 12 Dec 2003 16:02:48 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hBD02gn06195; Fri, 12 Dec 2003 17:02:42 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DISCUSS:  MUST reject in OCSPv1
Date: Fri, 12 Dec 2003 17:04:44 -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>

> -----Original Message-----
> From: Tom Gindin
> Sent: Friday, December 12, 2003 3:58 PM
>
> Mike:
>
> While we're on this subject, do we need to
> include that a client "MUST" reject a response
> containing a nonce which does not match the
> request?

Tom,

We may be saying the same thing:

if( req->sent_nonce != rsp->rcvd_nonce )
   fail( BADNONCE )
else
   proceed( rsp );

The more interesting question along these lines is the one
regarding Florian's server-unilateral nonces.  I.e. a client
receives a nonce extension in the response even though the
client didn't provide a nonce extension in its request.  While
I'm not yet convinced of this practice's security value, I see
no reason to preclude it in our forthcoming clarification
regarding nonces.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCMw0ib029175 for <[e-mail]>; Fri, 12 Dec 2003 14:58:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBCMw06B029174 for ietf-pkix-bks; Fri, 12 Dec 2003 14:58:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCMvwib029165 for <[e-mail]>; Fri, 12 Dec 2003 14:57:58 -0800 (PST) (envelope-from [e-mail])
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hBCMvmd6294770; Fri, 12 Dec 2003 17:57:48 -0500
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hBCMvklh112662; Fri, 12 Dec 2003 17:57:47 -0500
To: "Michael Myers" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: DISCUSS:  MUST reject in OCSPv1
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 12 Dec 2003 17:57:45 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 IGS_HF11|December 1, 2003) at 12/12/2003 17:57:47, Serialize complete at 12/12/2003 17:57:47
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>

        Mike:

        While we're on this subject, do we need to include that a client 
"MUST" reject a response containing a nonce which does not match the 
request?

                Tom Gindin





"Michael Myers" <[e-mail]>
Sent by: [e-mail]
12/11/2003 11:01 PM

 
        To:     <[e-mail]>
        cc: 
        Subject:        DISCUSS:  MUST reject in OCSPv1




-----Original Message-----
From: Carlisle Adams
Sent: Tuesday, December 09, 2003 12:00 PM
To: Michael Myers
Subject: Re: MUST reject in OCSPv1

Hi Mike,

[. . .] you may forward the content of this message to the list
if you
wish.

It's pretty clear to me that clients use a nonce when they want
to guarantee
a fresh response from the other end (the nonce is returned in a
signed
message).  If the client doesn't care about freshness, it has no
reason to
use the nonce since that is the ONLY purpose that the nonce
serves.

So, if a client puts a nonce in its request, the server MUST
return it in
the response.  If the responder requirement is softened to a
SHOULD, then
the client requirement has to be strengthened to "if the
response comes back
without the client's nonce included, the client MUST reject the
message".
Again, if the client doesn't care about freshness, then it MUST
NOT put a
nonce in the request.  If it does put a nonce in the request,
then a
response without it MUST NOT be acceptable.  This only makes
sense:  if you
explicitly ask for a security service on a response
(confidentiality,
authenticity, integrity, freshness, whatever) and the response
shows up
without it, this must be unacceptable.  I don't care so much
whether the
behavioral requirement is on the client or on the responder
(although I
would prefer it to be on the responder), but the result must be
that the
request has not been completed.

Carlisle.








Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCMiEib027905 for <[e-mail]>; Fri, 12 Dec 2003 14:44:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBCMiEEQ027904 for ietf-pkix-bks; Fri, 12 Dec 2003 14:44:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCMiCib027899 for <[e-mail]>; Fri, 12 Dec 2003 14:44:12 -0800 (PST) (envelope-from [e-mail])
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hBCMi09n433292; Fri, 12 Dec 2003 17:44:00 -0500
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hBCMhxlT216946; Fri, 12 Dec 2003 17:44:00 -0500
To: <[e-mail]>
Cc: "Michael Myers" <[e-mail]>
MIME-Version: 1.0
Subject: Re: POLL:   MUST  reject in OCSPv1
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 12 Dec 2003 17:43:58 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 IGS_HF11|December 1, 2003) at 12/12/2003 17:43:59, Serialize complete at 12/12/2003 17:43:59
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>

        AGREE.  I don't care very much about whether point 4 becomes a 
SHOULD or not, as long as the client MUST reject a bad response.  Given 
that MUST in point 3, the difference between the nonceSupported and 
nonceUnsupported proposed extensions doesn't really matter.

                Tom Gindin





"Michael Myers" <[e-mail]>
Sent by: [e-mail]
12/08/2003 01:46 PM

 
        To:     <[e-mail]>
        cc:     "Carlisle Adams" <[e-mail]>
        Subject:        POLL:   MUST  reject in OCSPv1




All,

OK, so let's take a full-up poll on what we were looking at a
couple of weeks ago to see where we stand today.  Please respond
with either YES or NO.  Take discussions to the DISCUSS thread.

This approach preserves installed base functionality and yet
enables a clear and technically complete resolution of the
various perspectives.

To date, on the related DISCUSS thread, six have voiced
agreement to this path forward and two disagree.  From that
record:

AGREE
-----
David Engberg,      Corestreet
Florian Oelmaier,   Sytrust
Ambarish Malpani,   Cenzic
Marc Branchaud,     RSA
Miguel Rodriguez,   SeguriDATA
Frank Balluffi,     Deutsche Bank

DISAGREE
--------
Ryan Hurst,         Microsoft
Alex Deacon,        VeriSign


PROPOSED
--------
The proposed resolution is as follows:

1. Cycle v1 as Proposed Standard.  It was well
   on its way to Draft but we'll pull it back.

2. Define nonceUnsupported extension subject
   to the following semantics.

3. Clients that send a nonce:

   a. MUST reject a non-nonced response if
      that response includes either the value
      "good" or "revoked" AND it fails to
      include the nonceUnsupported extension;

   b. Else, if such response includes the
      nonceUnsupported extension, clients
      MAY accept the response subject to the
      advice in the Security Considerations
      section of this document.

4. Conversely, if a server receives a nonced
   request but is unable to incorporate the
   nonce in its response, the server MUST
   include the nonceUnsupported extension.

We now have clearance to cycle v1 at Proposed so that's no
longer a predicate.

Thank you for your continued patience as we work towards
resolving this issue.

Mike








Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCIOvib017938 for <[e-mail]>; Fri, 12 Dec 2003 10:24:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBCIOvT9017937 for ietf-pkix-bks; Fri, 12 Dec 2003 10:24:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.204]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCIOuib017930 for <[e-mail]>; Fri, 12 Dec 2003 10:24:56 -0800 (PST) (envelope-from [e-mail])
Received: from free.fr (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft5.fr.colt.net with ESMTP id hBCIOlZ03025 for <[e-mail]>; Fri, 12 Dec 2003 19:24:52 +0100
Message-ID: <[e-mail]>
Date: Fri, 12 Dec 2003 19:25:55 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031125
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DN Encoding by UTF8String
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[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>

Dr Stephen Henson wrote:

> Peter Gutmann wrote:
>
>> What we'd really need here is an indication from vendors of how far 
>> UTF-8
>> support goes (or doesn't go) in their products, to determine whether 
>> it's safe
>> to switch it on yet.  The most important one would be Microsoft I 
>> guess.  I'll
>> start the ball rolling by saying that any version of cryptlib that 
>> handles
>> certs will process UTF-8, although none will produce it (at least in 
>> a DN) for
>> the reason given above.
>
> I'll add that the latest releases of OpenSSL (0.9.7c) can handle UTF8 
> strings in certificates too.

I had sent a message earlier on this list resuming the situation for 
this as I see it from the major implementations around.
I also did send a message some time ago to the list raising the same 
issue as Shimaoka, that went completely unanswered.
I'm happy there's a more reaction now.

The problem is *not* for the low level crypto API to support UTF8String.
Basically all API around do that.
All the i18n related problems in the actual implementations are added 
between that layer and the UI layer.
And even the best API can not prevent the implementer to screw the i18n 
implementation.

The japanese document about PKI interoperability also has a long list of 
horror stories at this, but also many other levels.
There's is detailled information about how memcpy() to encode and 
memcmp() to compare don't work as soon as anything more complex than 
printablestring is involved. And don't work also if you take into 
account anything from the full x520 comparison rules.
But this kind of comparaison being prevalent in application, the only 
solution to avoid problem is for the CA to normalize strictly every name 
before emitting certificates.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCHW3ib016152 for <[e-mail]>; Fri, 12 Dec 2003 09:32:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBCHW3JB016151 for ietf-pkix-bks; Fri, 12 Dec 2003 09:32:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCHW1ib016140 for <[e-mail]>; Fri, 12 Dec 2003 09:32:02 -0800 (PST) (envelope-from [e-mail])
Received: from free.fr (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft6.fr.colt.net with ESMTP id hBCHVx422115 for <[e-mail]>; Fri, 12 Dec 2003 18:31:59 +0100
Message-ID: <[e-mail]>
Date: Fri, 12 Dec 2003 18:33:06 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031125
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Web-PKI Keygen/Certreq Questions
References: <[e-mail]>
In-Reply-To: <[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 Gutmann wrote:

>Jean-Marc Desperrier <[e-mail]> writes:
>
>>Have a look at the way CRMF format key request generation are used inside
>>Netscape 7/Mozilla.
>>    
>>
>That's a special case because CRMF was designed to handle this situation.
>  
>
Yes, but I think James was waiting for the correct solution to this 
problem, and it's not to try to customize pkcs#10.

In the direction where I pointed him, he can find an actual 
implementation of the mechanism and the source code, so it should make 
it easy to understand how it really works.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCHS0ib016033 for <[e-mail]>; Fri, 12 Dec 2003 09:28:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBCHS07T016032 for ietf-pkix-bks; Fri, 12 Dec 2003 09:28:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCHRxib016026 for <[e-mail]>; Fri, 12 Dec 2003 09:27:59 -0800 (PST) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Fri, 12 Dec 2003 09:27:53 -0800
From: "Blake Ramsdell" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Re[2]: DN Encoding by UTF8String
Date: Fri, 12 Dec 2003 09:27:53 -0800
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAACoD/[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, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Peter Gutmann
> Sent: Friday, December 12, 2003 1:53 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: Re[2]: DN Encoding by UTF8String
> 
> What we'd really need here is an indication from vendors of 
> how far UTF-8
> support goes (or doesn't go) in their products, to determine 
> whether it's safe
> to switch it on yet.  The most important one would be 
> Microsoft I guess.  I'll
> start the ball rolling by saying that any version of cryptlib 
> that handles
> certs will process UTF-8, although none will produce it (at 
> least in a DN) for
> the reason given above.
> 
> Anyone else?

My understanding is that J2SE 1.4.2 supports it. Not sure about earlier
versions.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCDiYib006699 for <[e-mail]>; Fri, 12 Dec 2003 05:44:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBCDiY9q006698 for ietf-pkix-bks; Fri, 12 Dec 2003 05:44:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCDiWib006693 for <[e-mail]>; Fri, 12 Dec 2003 05:44:33 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Fri, 12 Dec 2003 14:44:03 +0100
Date: Fri, 12 Dec 2003 14:44:02 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: DN Encoding by UTF8String
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.60
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.60 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
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 message <[e-mail]> on Fri, 12 Dec 2003 22:52:46 +1300, [e-mail] (Peter Gutmann) said:

pgut001> (and then there's the all-important 0.000001% of the user
pgut001> base still using Netscape 4.x, which will crash if it hits a
pgut001> UTF-8 string).

Personally, I'd say that's the perfect reason to use UTF-8.
Supporting Netscape 4 has become HARD lately (and that's a discussion
for a completely different forum).

pgut001> It's like the IPv6 upgrade, the first backbone provider to
pgut001> switch to it is going to trigger every IPv6 bug in every
pgut001> implementation every created, so no-one wants to be the
pgut001> guinea pig.

*ahem* Actually, it's happening as we speak.  KTH (The Royal Institute
of Technology in Stockholm) and SUNET (Swedish University NETwork,
which also holds much of the swedish Internet infrastructure) are
going IPv6 native (I think they're almost done).  So if there are bugs
to be triggered, now is the time :-).

pgut001> What we'd really need here is an indication from vendors of
pgut001> how far UTF-8 support goes (or doesn't go) in their products,
pgut001> to determine whether it's safe to switch it on yet.  The most
pgut001> important one would be Microsoft I guess.  I'll start the
pgut001> ball rolling by saying that any version of cryptlib that
pgut001> handles certs will process UTF-8, although none will produce
pgut001> it (at least in a DN) for the reason given above.

OpenSSL handles UTF-8 fine (at least last I checked), and can produce
UTF-8 DNs as well (it's all part of the configuration file).

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCCqnib004794 for <[e-mail]>; Fri, 12 Dec 2003 04:52:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBCCqmIw004793 for ietf-pkix-bks; Fri, 12 Dec 2003 04:52:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCCqkib004788 for <[e-mail]>; Fri, 12 Dec 2003 04:52:47 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=drh-consultancy.co.uk) by anchor-post-33.mail.demon.net with esmtp (Exim 3.35 #1) id 1AUmmi-000Kho-0X for [e-mail]; Fri, 12 Dec 2003 12:52:45 +0000
Message-ID: <[e-mail]>
Date: Fri, 12 Dec 2003 12:53:08 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DN Encoding by UTF8String
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.7.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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 Gutmann wrote:
> 
> What we'd really need here is an indication from vendors of how far UTF-8
> support goes (or doesn't go) in their products, to determine whether it's safe
> to switch it on yet.  The most important one would be Microsoft I guess.  I'll
> start the ball rolling by saying that any version of cryptlib that handles
> certs will process UTF-8, although none will produce it (at least in a DN) for
> the reason given above.
> 

I'll add that the latest releases of OpenSSL (0.9.7c) can handle UTF8 
strings in certificates too.

It can also generate certificates containing UTF8Strings by means of a 
configuration file option, but this is not set by default.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCBc1ib000273 for <[e-mail]>; Fri, 12 Dec 2003 03:38:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBCBc12S000272 for ietf-pkix-bks; Fri, 12 Dec 2003 03:38:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCBc0ib000267 for <[e-mail]>; Fri, 12 Dec 2003 03:38:00 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 6C3FC3400E; Sat, 13 Dec 2003 00:37:19 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hBCBbwQ21091; Sat, 13 Dec 2003 00:37:58 +1300
Date: Sat, 13 Dec 2003 00:37:58 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Web-PKI Keygen/Certreq Questions
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>

Jean-Marc Desperrier <[e-mail]> writes:

>Have a look at the way CRMF format key request generation are used inside
>Netscape 7/Mozilla.

That's a special case because CRMF was designed to handle this situation.
However, most apps (based on traffic in crypto newsgroups/mailing lists) are
still using PKCS #10, which wasn't (it dates back to X.509v1, so you can't
really blame it for that).

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCB6Eib099186 for <[e-mail]>; Fri, 12 Dec 2003 03:06:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBCB6EJ0099185 for ietf-pkix-bks; Fri, 12 Dec 2003 03:06:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCB6Bib099166 for <[e-mail]>; Fri, 12 Dec 2003 03:06:12 -0800 (PST) (envelope-from [e-mail])
Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.12.10/8.12.10) with ESMTP id hBCB5jKM015036; Fri, 12 Dec 2003 19:05:45 +0800
Received: (from root@localhost) by ms21.chttl.com.tw (8.12.10/8.12.10) id hBCB5emX027118; Fri, 12 Dec 2003 19:05:40 +0800
Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.12.10/8.12.10) with SMTP id hBCB5cPc027047; Fri, 12 Dec 2003 19:05:38 +0800
Message-ID: <039a01c3c09f$a2bbb710$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Re[2]: DN Encoding by UTF8String
Date: Fri, 12 Dec 2003 19:03:55 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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" <[e-mail]> writes:
> 
> Masaki SHIMAOKA <[e-mail]> writes:
> 
> >Basically I agree with you, we MUST move to UTF-8 soon. But, still now we are
> >facing to some issues about UTF8string, e.g., name comparison rule, and it
> >seems that hard to solve yet them. AFAIK, there will be a little PKI
> >applications who are compliant with the transition to UTF-8.
> 
> It's not really name comparison rules, the de facto profile of using only
> memcpy() to encode and memcmp() to compare works pretty well at the moment.
> The real problem is that a number of legacy apps don't support UTF-8, and
> people are reluctant to move to it because of that (and then there's the all-
> important 0.000001% of the user base still using Netscape 4.x, which will
> crash if it hits a UTF-8 string).  It's like the IPv6 upgrade, the first
> backbone provider to switch to it is going to trigger every IPv6 bug in every
> implementation every created, so no-one wants to be the guinea pig.
> 
> What we'd really need here is an indication from vendors of how far UTF-8
> support goes (or doesn't go) in their products, to determine whether it's safe
> to switch it on yet.  The most important one would be Microsoft I guess.  I'll
> start the ball rolling by saying that any version of cryptlib that handles
> certs will process UTF-8, although none will produce it (at least in a DN) for
> the reason given above.
> 
> Anyone else?
> 
In Taiwan GPKI (Government PKI), we have already adopted UTF8string in DN
since 2002. We have to use UTF8string because our GPKI CP stipulates
that the DN must contains the offical registered name of the subscriber and
the name is of course in Chinese. One exception is that we do not use
UTF8string for Common Name in SSL certificates because IE (even IE6) running
on Windows 95/98/NT does not support UTF8string.

Wen-Cheng Wang


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCAw7ib098051 for <[e-mail]>; Fri, 12 Dec 2003 02:58:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBCAw7mx098050 for ietf-pkix-bks; Fri, 12 Dec 2003 02:58:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.204]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCAw5ib098044 for <[e-mail]>; Fri, 12 Dec 2003 02:58:06 -0800 (PST) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft5.fr.colt.net with ESMTP id hBCAvtZ13384 for <[e-mail]>; Fri, 12 Dec 2003 11:58:01 +0100
Message-ID: <[e-mail]>
Date: Fri, 12 Dec 2003 11:59:03 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031125
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Web-PKI Keygen/Certreq Questions
References: <[e-mail]>
In-Reply-To: <[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 Gutmann wrote:

>"James Jing" <[e-mail]> writes:
>  
>
>Yup, that's a problem with systems that enforce access/usage controls on
>crypto keys, it makes it impossible to generate PKCS #10 requests if the
>controls are in place.  For example cryptlib employs strict key usage/access
>controls, so in theory you couldn't create a PKCS #10 request, or create one
>for an encryption-only key.  The workaround was to add a dynamic ACL check
>(that is, not a hardcoded rule in the kernel but a callback where object-type-
>specific code can provide additional information to the kernel) that allowed
>special-case use for PKCS #10:
>  
>
>>Are there any solutions addressing such a problem already?
>>    
>>
There is. Have a look at the way CRMF format key request generation are 
used inside Netscape 7/Mozilla.

The solution implemented enables in several different use case to 
authentify an encryption only key without ever requiring them to sign.
Not many PKI can interface with that the way it's required, but at least 
SUN or AOL's CMS can.
It's efficient and it's 100% standard compliant.
The only one dubious aspect is the use of raw CRMF requests in the 
exchange instead of encapsulating them inside CMP or CMC.

Dump PKCS#10. It wasn't designed to handle this, but CRMF was.
Well some vendor hasn't realized yet, still using only PKCS#10 inside 
it's CMC request in the 2003 version of it's tools.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC9qoib090886 for <[e-mail]>; Fri, 12 Dec 2003 01:52:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBC9qonj090884 for ietf-pkix-bks; Fri, 12 Dec 2003 01:52:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC9qmib090869 for <[e-mail]>; Fri, 12 Dec 2003 01:52:48 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id C6EB134056; Fri, 12 Dec 2003 22:52:09 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hBC9qkv20566; Fri, 12 Dec 2003 22:52:46 +1300
Date: Fri, 12 Dec 2003 22:52:46 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Re[2]: DN Encoding by UTF8String
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>

Masaki SHIMAOKA <[e-mail]> writes:

>Basically I agree with you, we MUST move to UTF-8 soon. But, still now we are
>facing to some issues about UTF8string, e.g., name comparison rule, and it
>seems that hard to solve yet them. AFAIK, there will be a little PKI
>applications who are compliant with the transition to UTF-8.

It's not really name comparison rules, the de facto profile of using only
memcpy() to encode and memcmp() to compare works pretty well at the moment.
The real problem is that a number of legacy apps don't support UTF-8, and
people are reluctant to move to it because of that (and then there's the all-
important 0.000001% of the user base still using Netscape 4.x, which will
crash if it hits a UTF-8 string).  It's like the IPv6 upgrade, the first
backbone provider to switch to it is going to trigger every IPv6 bug in every
implementation every created, so no-one wants to be the guinea pig.

What we'd really need here is an indication from vendors of how far UTF-8
support goes (or doesn't go) in their products, to determine whether it's safe
to switch it on yet.  The most important one would be Microsoft I guess.  I'll
start the ball rolling by saying that any version of cryptlib that handles
certs will process UTF-8, although none will produce it (at least in a DN) for
the reason given above.

Anyone else?

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC7SLib046985 for <[e-mail]>; Thu, 11 Dec 2003 23:28:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBC7SLnf046984 for ietf-pkix-bks; Thu, 11 Dec 2003 23:28:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC7SEib046967 for <[e-mail]>; Thu, 11 Dec 2003 23:28:17 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 0A1163400C; Fri, 12 Dec 2003 20:27:36 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hBC7SD820013; Fri, 12 Dec 2003 20:28:13 +1300
Date: Fri, 12 Dec 2003 20:28:13 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Web-PKI Keygen/Certreq Questions
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 Jing" <[e-mail]> writes:

>There is an interesting problem with proof-of-possesion in the key generation
>message which we came across lately. If someone is having another look at it,
>it would be nice if it can be addressed.
>
>The problem is if key-gen is performed on behalf of the end user, we need to
>ensure that nobody can use the private key thus generated. However, PKCS#10
>requires a signature using this newly generated key. The key container (smart
>card) is unable to know that this is for PKCS#10, since it only signs a
>digest. Therefore we are in a catch-22. If we disallow signing, then we
>cannot create the PKCS#10 message. If we do, we don't know that we signed a
>PKCS#10.

Yup, that's a problem with systems that enforce access/usage controls on
crypto keys, it makes it impossible to generate PKCS #10 requests if the
controls are in place.  For example cryptlib employs strict key usage/access
controls, so in theory you couldn't create a PKCS #10 request, or create one
for an encryption-only key.  The workaround was to add a dynamic ACL check
(that is, not a hardcoded rule in the kernel but a callback where object-type-
specific code can provide additional information to the kernel) that allowed
special-case use for PKCS #10:

/* PKCS #10 cert requests are special-case objects in that the key they 
   contain is usable only for signature checking of the self-signature 
   on the object (it can't be used for general-purpose usages, which 
   would make it equivalent to a trusted self-signed cert).  This is 
   problematic because the keyUsage may indicate that the key is valid 
   for other things as well, or not valid for signature checking.  To 
   get around this, we indicate that the key has a single trusted usage, 
   signature checking, and disallow any other usage regardless of what 
   the keyUsage says.  The actual keyUsage usage is only valid once the 
   request has been converted into a cert */

>Are there any solutions addressing such a problem already?

Most apps don't seem to enforce usage controls (for example there was one case
where a CA was using an encryption-only cert for signing messages, and in ~2
years of interop testing with PKI vendors no-one noticed; Windows allows
usage-X-only certs to be used for usage Y as well because it's less confusing
for the user to have a single cert that can do everything; a national smart
card project in Europe didn't realise that the keys they were putting on the
card weren't valid for encryption because nothing enforced the restrictions,
etc etc (there's a long list of these, those are off the top of my head)), so
it's not really a problem in general.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC4kEib010096 for <[e-mail]>; Thu, 11 Dec 2003 20:46:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBC4kET6010095 for ietf-pkix-bks; Thu, 11 Dec 2003 20:46:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from figg.securenet.com.au (ns2.isecure.com.au [202.125.4.72]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC4kAib010066 for <[e-mail]>; Thu, 11 Dec 2003 20:46:13 -0800 (PST) (envelope-from [e-mail])
Received: from iron.securenet.com.au (iron.isecure.com.au [202.125.4.94] (may be forged)) by figg.securenet.com.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBC4jxN5024971 for <[e-mail]>; Fri, 12 Dec 2003 15:45:59 +1100
Received: (from uucp@localhost) by iron.securenet.com.au (8.12.6/8.12.6) id hBC4jxKm006411 for <[e-mail]>; Fri, 12 Dec 2003 15:45:59 +1100 (EST)
Received: from nodnsquery(10.11.3.10) by iron.securenet.com.au via csmap (V6.0) id srcAAAlWaqHm; Fri, 12 Dec 03 15:45:59 +1100
Received: from atlas.securenet.com.au (localhost [127.0.0.1]) by gibbons.securenet.com.au (8.12.3/8.12.3/Debian-7woody) with ESMTP id hBC4jw7j006080 for <[e-mail]>; Fri, 12 Dec 2003 15:45:59 +1100
Received: from AMALTHEA.securenet.com.au ([192.168.100.30]) by atlas.securenet.com.au with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Dec 2003 15:43:58 +1100
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Web-PKI Keygen/Certreq Questions
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Fri, 12 Dec 2003 15:45:51 +1100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Web-PKI Keygen/Certreq Questions
Thread-Index: AcO1oCHAi2lelxxhT8+QOHPVjmdsPwKyJakA
From: "James Jing" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 12 Dec 2003 04:43:58.0125 (UTC) FILETIME=[8E328DD0:01C3C06A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBC4kDib010090
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>

There is an interesting problem with proof-of-possesion in the key generation message which we came across lately. If someone is having another look at it, it would be nice if it can be addressed.

The problem is if key-gen is performed on behalf of the end user, we need to ensure that nobody can use the private key thus generated. However, PKCS#10 requires a signature using this newly generated key. The key container (smart card) is unable to know that this is for PKCS#10, since it only signs a digest. Therefore we are in a catch-22. If we disallow signing, then we cannot create the PKCS#10 message. If we do, we don't know that we signed a PKCS#10.

Are there any solutions addressing such a problem already?

This catch-22 can be broken, for example, if the PKCS#10 signature is unique to PKCS#10, such as allowing the card to add some salt, pad it to the digest and then re-digest it before signing. Something like that will ensure that the key in the initial state cannot be abused by any intermediary. 

James

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Thursday, 27 November 2003 3:59 AM
Cc: [e-mail]
Subject: Re: Web-PKI Keygen/Certreq Questions




Hopefully the consortium is planning to construct its solution by 
profiling: a) attributes to be included in RFC 2797 messages and b) 
transport of those messages over http, rather than inventing something 
from scratch.

Dave



Anders Rundgren wrote:

> Just to set the record straight: Another consortium has indeed
> [also] found the existings keygen/certreq mechanisms largely
> inferior and will publish a draft solution in a couple of months
> or so.  I just talked to one of the architects, and he confirmed that
> it will support the kind of stuff that most of the proprietary solutions
> already do, such as key-container co-signing, passphrase policy
> control, and multi-key generation.
> 
> /a
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC3xCib008487 for <[e-mail]>; Thu, 11 Dec 2003 19:59:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBC3xClG008486 for ietf-pkix-bks; Thu, 11 Dec 2003 19:59:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC3xBib008478 for <[e-mail]>; Thu, 11 Dec 2003 19:59:11 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hBC3xEn37144 for <[e-mail]>; Thu, 11 Dec 2003 20:59:14 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: DISCUSS:  MUST reject in OCSPv1
Date: Thu, 11 Dec 2003 21:01:14 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE 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>

-----Original Message-----
From: Carlisle Adams
Sent: Tuesday, December 09, 2003 12:00 PM
To: Michael Myers
Subject: Re: MUST reject in OCSPv1

Hi Mike,

[. . .] you may forward the content of this message to the list
if you
wish.

It's pretty clear to me that clients use a nonce when they want
to guarantee
a fresh response from the other end (the nonce is returned in a
signed
message).  If the client doesn't care about freshness, it has no
reason to
use the nonce since that is the ONLY purpose that the nonce
serves.

So, if a client puts a nonce in its request, the server MUST
return it in
the response.  If the responder requirement is softened to a
SHOULD, then
the client requirement has to be strengthened to "if the
response comes back
without the client's nonce included, the client MUST reject the
message".
Again, if the client doesn't care about freshness, then it MUST
NOT put a
nonce in the request.  If it does put a nonce in the request,
then a
response without it MUST NOT be acceptable.  This only makes
sense:  if you
explicitly ask for a security service on a response
(confidentiality,
authenticity, integrity, freshness, whatever) and the response
shows up
without it, this must be unacceptable.  I don't care so much
whether the
behavioral requirement is on the client or on the responder
(although I
would prefer it to be on the responder), but the result must be
that the
request has not been completed.

Carlisle.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBALwZib062284 for <[e-mail]>; Wed, 10 Dec 2003 13:58:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBALwZq8062283 for ietf-pkix-bks; Wed, 10 Dec 2003 13:58:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBALwXib062278 for <[e-mail]>; Wed, 10 Dec 2003 13:58:34 -0800 (PST) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Dec 2003 13:59:00 -0800
Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 10 Dec 2003 13:58:36 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Dec 2003 13:58:24 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Dec 2003 13:58:28 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 10 Dec 2003 13:58:28 -0800
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.7122
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.7122
Subject: RE: Cached OCSP responses vs. single entry CRLs
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <004501c3bf21$76361e30$[e-mail]>
References: <061891A2-1490-4A4A-A63E-EA25AB58BD3B@mimectl>, <004501c3bf21$76361e30$[e-mail]>
To: Santosh Chokhani <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: Cached OCSP responses vs. single entry CRLs
Thread-Index: AcO/aMG8VaKHTX6LTQu14jfayV30ow==
Message-ID: <F789EBB9-A679-4B85-A7A5-747B0FE4619B@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.7122.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.7122.0
Date: Wed, 10 Dec 2003 13:58:34 -0800
X-OriginalArrivalTime: 10 Dec 2003 21:58:28.0728 (UTC) FILETIME=[BE556F80:01C3BF68]
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>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0046_01C3BEF7.8D601630"

------=_NextPart_000_0046_01C3BEF7.8D601630
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sure, if the client supports paritioned CRLs and most deployed clients MSFT=
 or otherwise do not; ttp issues want to service as many possible relying p=
arties as possible since this is often a significant factor a subscriber ta=
kes into consideration when choosing a ttp.

Ryan



From: Santosh Chokhani
Sent: Wed 12/10/2003 5:28 AM
To: [e-mail]
Subject: RE: Cached OCSP responses vs. single entry CRLs


Ryan:

Assuming the CA and the client software are working properly, there will be=
 one DP (URL) in the CDP and that will point to the proper partition.  The =
client will get the CRL from that URL.  The DP in the IDP of the CRL will b=
e matched to the DP in the CDP of certificate and all will be well.

If there is a glitch on the network or active adversary, then these won't m=
atch, but in those circumstances there are innumerable (albeit finite) way =
to cause denial of service, CRL partitioning notwithstanding.
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Ryan M. Hurst
Sent: Tuesday, December 09, 2003 10:02 PM
To: Jean-Marc Desperrier; [e-mail]
Subject: RE: Cached OCSP responses vs. single entry CRLs


I have seen engines that do not deal with extension criticality in CRLs, so=
me of the java implementations I have seen in-fact; these would trust these=
 partial CRLs as a full CRL. Now I know folks will say thats a bad implemen=
tation, and I am not arguing that what these clients have done is right but=
 its yet another example of how CRLs fail in this area due to the history o=
f implementations out there.

Another example is where the client does properly deal with critical extens=
ions in the CRL, in this case almost all implementations I have seen would =
show the CRL as bad and fail validation (as it should), I dont know of one =
that would try the next URL in the CDP to see if it was the full CRL. And e=
ven if it did thats extra data to be downloaded to discover its not the rig=
th CRL.

Ryan



From: Jean-Marc Desperrier
Sent: Tue 12/9/2003 12:19 PM
To: [e-mail]
Subject: Re: Cached OCSP responses vs. single entry CRLs


Ryan M. Hurst wrote:

>[...] there is not way to tell from a CDP if the
>data on the other end represents a partitioned CRL or a full one.
> =20
>
But then clean client should check the content of the IDP extension=20
after getting the CRL and check it's distribution point matches the=20
distribution field of the CDP, and if not refuse the CRL, and supposedly=20
try the next crldp inside the cert.
RFC3280 6.3.3 (b)(2)(i)

I'm a bit sceptic it really works, but if the CRL's IDP is marked=20
critical as it should, maybe a good number of client will duly reject=20
the CRL when they can not support that case.

------=_NextPart_000_0046_01C3BEF7.8D601630
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD><TITLE>Message</TITLE></HEAD>
<BODY>
<DIV id=3DidOWAReplyText73816 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Sure, if the cli=
ent supports paritioned CRLs and most deployed clients MSFT or otherwise do=
 not; ttp issues want to service as many possible relying parties as possib=
le since this is often a significant factor a subscriber takes into conside=
ration when choosing a ttp.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Santosh Chokhani<BR><B>Sent:</B> =
Wed 12/10/2003 5:28 AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> R=
E: Cached OCSP responses vs. single entry CRLs<BR></FONT><BR></DIV>
<DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN class=3D005212413-10=
122003>Ryan:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN class=3D005212413-10=
122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN class=3D005212413-10=
122003>Assuming the CA and the client software are working properly, there =
will be one DP (URL) in the CDP and that will point to the proper partition=
.&nbsp; The client will get the CRL from that URL.&nbsp; The DP in the IDP =
of the CRL will be matched to the DP in the CDP of certificate and all will=
 be well.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN class=3D005212413-10=
122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN class=3D005212413-10=
122003>If there is a glitch on the network or active adversary, then these =
won't match, but in those circumstances there are innumerable (albeit finit=
e) way to cause denial of service, CRL partitioning notwithstanding.</SPAN>=
</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft><FONT=
 face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> owner-ie=
[e-mail] [mailto:[e-mail]] <B>On Behalf Of =
</B>Ryan M. Hurst<BR><B>Sent:</B> Tuesday, December 09, 2003 10:02 PM<BR><B=
>To:</B> Jean-Marc Desperrier; [e-mail]<BR><B>Subject:</B> RE: Cac=
hed OCSP responses vs. single entry CRLs<BR><BR></FONT></DIV>
<DIV id=3DidOWAReplyText39006 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I have seen engi=
nes that do not deal with extension criticality in CRLs, some of the java i=
mplementations I have seen in-fact; these would trust these partial CRLs as=
 a full CRL. Now I know folks will say thats a bad implementation, and I am=
 not arguing that what these clients have done is right but its yet another=
 example of how CRLs fail in this area due to the history of implementation=
s out there.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Another example is where the cli=
ent does properly&nbsp;deal with critical extensions in the CRL, in this ca=
se&nbsp;almost all implementations I&nbsp;have&nbsp;seen&nbsp;would show th=
e CRL as bad and fail validation (as it should), I dont know of one that wo=
uld try the next URL in the CDP to see if it was the full CRL. And even if =
it did thats extra data to be downloaded to discover its not the rigth CRL.=
</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Jean-Marc Desperrier<BR><B>Sent:<=
/B> Tue 12/9/2003 12:19 PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</=
B> Re: Cached OCSP responses vs. single entry CRLs<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">Ryan M. Hurst wrote:

&gt;[...] there is not way to tell from a CDP if the
&gt;data on the other end represents a partitioned CRL or a full one.
&gt; =20
&gt;
But then clean client should check the content of the IDP extension=20
after getting the CRL and check it's distribution point matches the=20
distribution field of the CDP, and if not refuse the CRL, and supposedly=20
try the next crldp inside the cert.
RFC3280 6.3.3 (b)(2)(i)

I'm a bit sceptic it really works, but if the CRL's IDP is marked=20
critical as it should, maybe a good number of client will duly reject=20
the CRL when they can not support that case.

</PRE></DIV></BLOCKQUOTE></DIV></BODY></HTML>

------=_NextPart_000_0046_01C3BEF7.8D601630--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAJfWib055941 for <[e-mail]>; Wed, 10 Dec 2003 11:41:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBAJfW8s055940 for ietf-pkix-bks; Wed, 10 Dec 2003 11:41:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from s-utl01-lanoc.stsn.com (p11.n-lapop01.stsn.com [12.129.240.11]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBAJfVic055935 for <[e-mail]>; Wed, 10 Dec 2003 11:41:31 -0800 (PST) (envelope-from [e-mail])
Received: (from wchokhani [10.2.103.170]) by s-utl01-lanoc.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2003121011411315853 for <[e-mail]>; Wed, 10 Dec 2003 11:41:13 -0800
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Wed, 10 Dec 2003 14:41:27 -0500
Message-ID: <006801c3bf55$9a3b9fb0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBAJfVib055936
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:

The standard requires the IDP to be critical and not the CRLDP.  If a client
does not process CRLDP, it will have to rely on a CRL.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Michael Ströder
Sent: Wednesday, December 10, 2003 11:15 AM
To: Jean-Marc Desperrier
Cc: [e-mail]
Subject: Re: Cached OCSP responses vs. single entry CRLs



Jean-Marc Desperrier wrote:
> 
> I'm a bit sceptic it really works,

So am I.

> but if the CRL's IDP is marked
> critical as it should, maybe a good number of client will duly reject 
> the CRL when they can not support that case.

I saw at least one widely-deployed software of a major vendor simply crash 
when CRL IDP was marked critical.

Ciao, Michael.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAHIAib049885 for <[e-mail]>; Wed, 10 Dec 2003 09:18:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBAHIAHR049884 for ietf-pkix-bks; Wed, 10 Dec 2003 09:18:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBAHI8ib049878 for <[e-mail]>; Wed, 10 Dec 2003 09:18:08 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Dec 2003 17:18:10 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hBAHDw6L025308 for <[e-mail]>; Wed, 10 Dec 2003 09:13:58 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hBAHI8Y0007609 for <[e-mail]>; Wed, 10 Dec 2003 09:18:09 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWJCTA; Wed, 10 Dec 2003 09:27:07 -0800
Message-ID: <[e-mail]>
Date: Wed, 10 Dec 2003 09:07:39 -0800
X-Sybari-Trust: 52b771ef 7ddcb5bc fa431d80 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP in TLS handshake
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070804020701030109090807"
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.

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


Marc Branchaud wrote:
> 
> In that case, you're not talking about a real OCSP client

Turns out the TLS client can generate a nonce that the TLS server would 
forward to the OCSP server.

Mea culpa.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIxMDE3MDczOVow
IwYJKoZIhvcNAQkEMRYEFA2f5LYXe6gF0FQX7r1WhUffpozBMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBABwmLxOH59WOCznMvVp6YP5VdIBbxUNtfa66yTqGwt+GC04c
hySVzzJuDCKcgeUxokevKtWjd088ANaIRlSxVjza4ha8HbhCVGC6TWS4GpLNODB4mMUiDBC3
M7NiEboGP2PLVFm9QrnPW+jf/g5YSyTCU32AnOYoPlzpMou5zUTsFRhbCIQRcHK2DlHxFLgY
8oLueRNLdnOt0Wd6PdoisF4My/gJz8GPYE/xau8ePBIrV/yxALeq/gEKIBVfD0G0reygIHR7
wwJjjSfIa9hSzIh//RBi5tMb2ceKC2oRoPyvZyXWEQx3QN1Oe/N81gDvm7FCIcc0MKnOk39n
wkaPNc0AAAAAAAA=
--------------ms070804020701030109090807--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAGFCib045066 for <[e-mail]>; Wed, 10 Dec 2003 08:15:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBAGFC9d045065 for ietf-pkix-bks; Wed, 10 Dec 2003 08:15:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (krl9-d9bb4cbb.pool.mediaWays.net [217.187.76.187]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAGFAib045049 for <[e-mail]>; Wed, 10 Dec 2003 08:15:11 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 6CB4B9D506; Wed, 10 Dec 2003 17:14:59 +0100 (CET)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 92CA36BCAD; Wed, 10 Dec 2003 17:14:58 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 10 Dec 2003 17:14:58 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Jean-Marc Desperrier <[e-mail]>
Cc: [e-mail]
Subject: Re: Cached OCSP responses vs. single entry CRLs
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
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>

Jean-Marc Desperrier wrote:
> 
> I'm a bit sceptic it really works,

So am I.

> but if the CRL's IDP is marked 
> critical as it should, maybe a good number of client will duly reject 
> the CRL when they can not support that case.

I saw at least one widely-deployed software of a major vendor simply crash 
when CRL IDP was marked critical.

Ciao, Michael.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBADSQib036345 for <[e-mail]>; Wed, 10 Dec 2003 05:28:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBADSQ6l036344 for ietf-pkix-bks; Wed, 10 Dec 2003 05:28:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from s-utl01-lanoc.stsn.com (p11.n-lapop01.stsn.com [12.129.240.11]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBADSPic036339 for <[e-mail]>; Wed, 10 Dec 2003 05:28:25 -0800 (PST) (envelope-from [e-mail])
Received: (from wchokhani [10.2.103.170]) by s-utl01-lanoc.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2003121005280410770 for <[e-mail]>; Wed, 10 Dec 2003 05:28:04 -0800
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Wed, 10 Dec 2003 08:28:13 -0500
Message-ID: <004501c3bf21$76361e30$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C3BEF7.8D601630"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <061891A2-1490-4A4A-A63E-EA25AB58BD3B@mimectl>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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_0046_01C3BEF7.8D601630
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ryan:
=20
Assuming the CA and the client software are working properly, there will =
be
one DP (URL) in the CDP and that will point to the proper partition.  =
The
client will get the CRL from that URL.  The DP in the IDP of the CRL =
will be
matched to the DP in the CDP of certificate and all will be well.
=20
If there is a glitch on the network or active adversary, then these =
won't
match, but in those circumstances there are innumerable (albeit finite) =
way
to cause denial of service, CRL partitioning notwithstanding.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On
Behalf Of Ryan M. Hurst
Sent: Tuesday, December 09, 2003 10:02 PM
To: Jean-Marc Desperrier; [e-mail]
Subject: RE: Cached OCSP responses vs. single entry CRLs


I have seen engines that do not deal with extension criticality in CRLs,
some of the java implementations I have seen in-fact; these would trust
these partial CRLs as a full CRL. Now I know folks will say thats a bad
implementation, and I am not arguing that what these clients have done =
is
right but its yet another example of how CRLs fail in this area due to =
the
history of implementations out there.
=20
Another example is where the client does properly deal with critical
extensions in the CRL, in this case almost all implementations I have =
seen
would show the CRL as bad and fail validation (as it should), I dont =
know of
one that would try the next URL in the CDP to see if it was the full =
CRL.
And even if it did thats extra data to be downloaded to discover its not =
the
rigth CRL.
=20
Ryan

  _____ =20

From: Jean-Marc Desperrier
Sent: Tue 12/9/2003 12:19 PM
To: [e-mail]
Subject: Re: Cached OCSP responses vs. single entry CRLs


Ryan M. Hurst wrote:



>[...] there is not way to tell from a CDP if the

>data on the other end represents a partitioned CRL or a full one.

> =20

>

But then clean client should check the content of the IDP extension=20

after getting the CRL and check it's distribution point matches the=20

distribution field of the CDP, and if not refuse the CRL, and supposedly =


try the next crldp inside the cert.

RFC3280 6.3.3 (b)(2)(i)



I'm a bit sceptic it really works, but if the CRL's IDP is marked=20

critical as it should, maybe a good number of client will duly reject=20

the CRL when they can not support that case.




------=_NextPart_000_0046_01C3BEF7.8D601630
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D005212413-10122003>Ryan:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D005212413-10122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D005212413-10122003>Assuming the CA and the client software are =
working=20
properly, there will be one DP (URL) in the CDP and that will point to =
the=20
proper partition.&nbsp; The client will get the CRL from that URL.&nbsp; =
The DP=20
in the IDP of the CRL will be matched to the DP in the CDP of =
certificate and=20
all will be well.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D005212413-10122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D005212413-10122003>If=20
there is a glitch on the network or active adversary, then these won't =
match,=20
but in those circumstances there are innumerable (albeit finite) way to =
cause=20
denial of service, CRL partitioning notwithstanding.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] =
<B>On=20
  Behalf Of </B>Ryan M. Hurst<BR><B>Sent:</B> Tuesday, December 09, 2003 =
10:02=20
  PM<BR><B>To:</B> Jean-Marc Desperrier; =
[e-mail]<BR><B>Subject:</B>=20
  RE: Cached OCSP responses vs. single entry CRLs<BR><BR></FONT></DIV>
  <DIV id=3DidOWAReplyText39006 dir=3Dltr>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I have seen =
engines that do=20
  not deal with extension criticality in CRLs, some of the java =
implementations=20
  I have seen in-fact; these would trust these partial CRLs as a full =
CRL. Now I=20
  know folks will say thats a bad implementation, and I am not arguing =
that what=20
  these clients have done is right but its yet another example of how =
CRLs fail=20
  in this area due to the history of implementations out =
there.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>Another example is where =
the client does=20
  properly&nbsp;deal with critical extensions in the CRL, in this=20
  case&nbsp;almost all implementations I&nbsp;have&nbsp;seen&nbsp;would =
show the=20
  CRL as bad and fail validation (as it should), I dont know of one that =
would=20
  try the next URL in the CDP to see if it was the full CRL. And even if =
it did=20
  thats extra data to be downloaded to discover its not the rigth=20
  CRL.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
  <DIV dir=3Dltr><BR>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Jean-Marc =
Desperrier<BR><B>Sent:</B> Tue=20
  12/9/2003 12:19 PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> =
Re:=20
  Cached OCSP responses vs. single entry CRLs<BR></FONT><BR></DIV>
  <DIV><PRE style=3D"WORD-WRAP: break-word">Ryan M. Hurst wrote:

&gt;[...] there is not way to tell from a CDP if the
&gt;data on the other end represents a partitioned CRL or a full one.
&gt; =20
&gt;
But then clean client should check the content of the IDP extension=20
after getting the CRL and check it's distribution point matches the=20
distribution field of the CDP, and if not refuse the CRL, and supposedly =

try the next crldp inside the cert.
RFC3280 6.3.3 (b)(2)(i)

I'm a bit sceptic it really works, but if the CRL's IDP is marked=20
critical as it should, maybe a good number of client will duly reject=20
the CRL when they can not support that case.

</PRE></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0046_01C3BEF7.8D601630--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA4jaib039052 for <[e-mail]>; Tue, 9 Dec 2003 20:45:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBA4jaNi039051 for ietf-pkix-bks; Tue, 9 Dec 2003 20:45:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from s-utl01-lanoc.stsn.com (p11.n-lapop01.stsn.com [12.129.240.11]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBA4jaic039046 for <[e-mail]>; Tue, 9 Dec 2003 20:45:36 -0800 (PST) (envelope-from [e-mail])
Received: (from wchokhani [10.2.103.170]) by s-utl01-lanoc.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2003120920452108854 for <[e-mail]>; Tue, 09 Dec 2003 20:45:21 -0800
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Tue, 9 Dec 2003 23:45:32 -0500
Message-ID: <000101c3bed8$71e4f6b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBA4jaib039047
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>

Jean-Marc:

To match the DP in the IDP in CRL, you need to match the DP in CDP in the
certificate.  cRLIssuer field needs to come in to play only if there is an
indirect CRL issuer.

If the client does not know how to process a critical extension (which IDP
is) and still uses a PKI object (certificate or CRL), I am sure lots of
other things can go wrong.  Just look at some of the other vulnerabilities
identified and corrected over the last few months.

As to lack of client side support, when did that became a basis for putting
out yet another standard and requiring yet another client side plug-in.  I
am sure adding IDP processing to certificate and CRL processing is lot
easier than defining and adding an OCSP client.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jean-Marc Desperrier
Sent: Tuesday, December 09, 2003 3:00 PM
To: [e-mail]
Subject: Re: Cached OCSP responses vs. single entry CRLs



From: Carl Wallace

>     The responses regarding lack of client side support are somewhat
>     strange.
>     It is not possible that deployed client-side support for
>     partitioned CRLs is
>     less than deployed client-side support for the yet-to-be-defined
>     solution
>     for cached OCSP.
>
Santosh Chokhani wrote:

> The client concern does not seem to cut the mustard since Carl's 
> argument is that we do not seem to have a standard for nonceless 
> client, let alone capability.  For the partitioned CRL, we have 
> well-defined standard.
>  
> As to the response size, I am sure that a partitioned CRL (one CRL for 
> each certificate) will be less than 400 bytes you cited. I think 
> partitioning CRL for individual certificate has plusses in terms of 
> standard and removing the need for client.  It also has directory 
> related plusses in terms of replication.
>  
> I think its minuses are in terms of CA's ability to support it (or 
> requiring delegated CRL issuer, i.e., Indirect CRL Issuer Model) and 
> may be addition and management of entries under the CA branch for the 
> CRL partitions.

You are missing a major minus of partitioning CRL that many/most client 
don't support partitioned CRL, but worst do not properly recognize the 
cRLIssuer part of the CRLDP, and will not be able to match it to the IDP 
inside the crl, so they can be pushed to trust a partionned CRL for a 
cert it doesn't apply too.
*That* is the concern for lack of client side support. In the current 
state of things, partionned CRL is very probably a security hazard for 
many clients.

Meanwhile using cached OCSP without any of the addition discussed here 
is not a problem as long as the client is configured not to require a nonce.
The proposed OCSP change is an optimization, not absolutly required.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA31fib035129 for <[e-mail]>; Tue, 9 Dec 2003 19:01:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBA31fD4035128 for ietf-pkix-bks; Tue, 9 Dec 2003 19:01:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA31eib035119 for <[e-mail]>; Tue, 9 Dec 2003 19:01:40 -0800 (PST) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Dec 2003 19:00:50 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 9 Dec 2003 19:01:46 -0800
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Dec 2003 19:01:19 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Dec 2003 19:01:26 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Dec 2003 19:01:15 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 9 Dec 2003 19:00:31 -0800
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.7122
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.7122
MIME-Version: 1.0
Subject: RE: Cached OCSP responses vs. single entry CRLs
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>, <[e-mail]>
To: Jean-Marc Desperrier <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: Cached OCSP responses vs. single entry CRLs
Thread-Index: AcO+ye7KUVEgoPigRNekqedjOacxaw==
Message-ID: <061891A2-1490-4A4A-A63E-EA25AB58BD3B@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.7122.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.7122.0
Date: Tue, 9 Dec 2003 19:01:40 -0800
X-OriginalArrivalTime: 10 Dec 2003 03:00:31.0725 (UTC) FILETIME=[C61191D0:01C3BEC9]
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>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_495B11F8-C7AB-4592-9668-D86D43FDBC2C_"

--_495B11F8-C7AB-4592-9668-D86D43FDBC2C_
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

I have seen engines that do not deal with extension criticality in CRLs, so=
me of the java implementations I have seen in-fact; these would trust these=
 partial CRLs as a full CRL. Now I know folks will say thats a bad implemen=
tation, and I am not arguing that what these clients have done is right but=
 its yet another example of how CRLs fail in this area due to the history o=
f implementations out there.

Another example is where the client does properly deal with critical extens=
ions in the CRL, in this case almost all implementations I have seen would =
show the CRL as bad and fail validation (as it should), I dont know of one =
that would try the next URL in the CDP to see if it was the full CRL. And e=
ven if it did thats extra data to be downloaded to discover its not the rig=
th CRL.

Ryan



From: Jean-Marc Desperrier
Sent: Tue 12/9/2003 12:19 PM
To: [e-mail]
Subject: Re: Cached OCSP responses vs. single entry CRLs


Ryan M. Hurst wrote:

>[...] there is not way to tell from a CDP if the
>data on the other end represents a partitioned CRL or a full one.
> =20
>
But then clean client should check the content of the IDP extension=20
after getting the CRL and check it's distribution point matches the=20
distribution field of the CDP, and if not refuse the CRL, and supposedly=20
try the next crldp inside the cert.
RFC3280 6.3.3 (b)(2)(i)

I'm a bit sceptic it really works, but if the CRL's IDP is marked=20
critical as it should, maybe a good number of client will duly reject=20
the CRL when they can not support that case.

--_495B11F8-C7AB-4592-9668-D86D43FDBC2C_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText39006 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I have seen engi=
nes that do not deal with extension criticality in CRLs, some of the java i=
mplementations I have seen in-fact; these would trust these partial CRLs as=
 a full CRL. Now I know folks will say thats a bad implementation, and I am=
 not arguing that what these clients have done is right but its yet another=
 example of how CRLs fail in this area due to the history of implementation=
s out there.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Another example is where the cli=
ent does properly&nbsp;deal with critical extensions in the CRL, in this ca=
se&nbsp;almost all implementations I&nbsp;have&nbsp;seen&nbsp;would show th=
e CRL as bad and fail validation (as it should), I dont know of one that wo=
uld try the next URL in the CDP to see if it was the full CRL. And even if =
it did thats extra data to be downloaded to discover its not the rigth CRL.=
</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Jean-Marc Desperrier<BR><B>Sent:<=
/B> Tue 12/9/2003 12:19 PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</=
B> Re: Cached OCSP responses vs. single entry CRLs<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">Ryan M. Hurst wrote:

&gt;[...] there is not way to tell from a CDP if the
&gt;data on the other end represents a partitioned CRL or a full one.
&gt; =20
&gt;
But then clean client should check the content of the IDP extension=20
after getting the CRL and check it's distribution point matches the=20
distribution field of the CDP, and if not refuse the CRL, and supposedly=20
try the next crldp inside the cert.
RFC3280 6.3.3 (b)(2)(i)

I'm a bit sceptic it really works, but if the CRL's IDP is marked=20
critical as it should, maybe a good number of client will duly reject=20
the CRL when they can not support that case.

</PRE></DIV></BODY></HTML>

--_495B11F8-C7AB-4592-9668-D86D43FDBC2C_--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9NJiib028041 for <[e-mail]>; Tue, 9 Dec 2003 15:19:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9NJiGm028040 for ietf-pkix-bks; Tue, 9 Dec 2003 15:19:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9NJhib028034 for <[e-mail]>; Tue, 9 Dec 2003 15:19:44 -0800 (PST) (envelope-from [e-mail])
Received: from wcwallace ([141.156.44.86]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hB9NJioO026020; Tue, 9 Dec 2003 18:19:44 -0500
From: "Carl Wallace" <[e-mail]>
To: "'Jean-Marc Desperrier'" <[e-mail]>, <[e-mail]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Tue, 9 Dec 2003 18:19:44 -0500
Message-ID: <000001c3beaa$ee0bbbd0$[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, Build 10.0.4510
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jean-Marc 
> Desperrier
> Subject: Re: Cached OCSP responses vs. single entry CRLs
> 
> You are missing a major minus of partitioning CRL that 
> many/most client 
> don't support partitioned CRL, but worst do not properly 
> recognize the 
> cRLIssuer part of the CRLDP, and will not be able to match it 
> to the IDP 
> inside the crl, so they can be pushed to trust a partionned CRL for a 
> cert it doesn't apply too.
> *That* is the concern for lack of client side support. In the current 
> state of things, partionned CRL is very probably a security 
> hazard for 
> many clients.
> 
> Meanwhile using cached OCSP without any of the addition 
> discussed here 
> is not a problem as long as the client is configured not to 
> require a nonce. The proposed OCSP change is an optimization, 
> not absolutly required.
> 

As you pointed out in a subsequent post, a client that doesn't support
partitioned CRLs should choke on a critical IDP and (possibly) be unable to
determine the revocation status of the certificate in question.  This is
similar to an OCSP client that uses nonces when interacting with a caching
OCSP responder.  Faulty implementations are a different matter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9KIpib019349 for <[e-mail]>; Tue, 9 Dec 2003 12:18:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9KIpiw019348 for ietf-pkix-bks; Tue, 9 Dec 2003 12:18:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft2.fr.colt.net (smtp-ft2.fr.colt.net [213.41.78.26]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9KInib019334 for <[e-mail]>; Tue, 9 Dec 2003 12:18:49 -0800 (PST) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft2.fr.colt.net with ESMTP id hB9KIfn14787 for <[e-mail]>; Tue, 9 Dec 2003 21:18:46 +0100
Message-ID: <[e-mail]>
Date: Tue, 09 Dec 2003 21:19:49 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031125
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Cached OCSP responses vs. single entry CRLs
References: <[e-mail]>
In-Reply-To: <[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>

Ryan M. Hurst wrote:

>[...] there is not way to tell from a CDP if the
>data on the other end represents a partitioned CRL or a full one.
>  
>
But then clean client should check the content of the IDP extension 
after getting the CRL and check it's distribution point matches the 
distribution field of the CDP, and if not refuse the CRL, and supposedly 
try the next crldp inside the cert.
RFC3280 6.3.3 (b)(2)(i)

I'm a bit sceptic it really works, but if the CRL's IDP is marked 
critical as it should, maybe a good number of client will duly reject 
the CRL when they can not support that case.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9Jwgib018201 for <[e-mail]>; Tue, 9 Dec 2003 11:58:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9Jwgxi018200 for ietf-pkix-bks; Tue, 9 Dec 2003 11:58:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.204]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9Jweib018192 for <[e-mail]>; Tue, 9 Dec 2003 11:58:41 -0800 (PST) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft5.fr.colt.net with ESMTP id hB9JwWZ09858 for <[e-mail]>; Tue, 9 Dec 2003 20:58:37 +0100
Message-ID: <[e-mail]>
Date: Tue, 09 Dec 2003 20:59:41 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031125
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Cached OCSP responses vs. single entry CRLs
References: <004a01c3bddf$a4a72540$[e-mail]>
In-Reply-To: <004a01c3bddf$a4a72540$[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>

From: Carl Wallace

>     The responses regarding lack of client side support are somewhat
>     strange.
>     It is not possible that deployed client-side support for
>     partitioned CRLs is
>     less than deployed client-side support for the yet-to-be-defined
>     solution
>     for cached OCSP.
>
Santosh Chokhani wrote:

> The client concern does not seem to cut the mustard since Carl's 
> argument is that we do not seem to have a standard for nonceless 
> client, let alone capability.  For the partitioned CRL, we have 
> well-defined standard.
>  
> As to the response size, I am sure that a partitioned CRL (one CRL for 
> each certificate) will be less than 400 bytes you cited.
> I think partitioning CRL for individual certificate has plusses in 
> terms of standard and removing the need for client.  It also has 
> directory related plusses in terms of replication.
>  
> I think its minuses are in terms of CA's ability to support it (or 
> requiring delegated CRL issuer, i.e., Indirect CRL Issuer Model) and 
> may be addition and management of entries under the CA branch for the 
> CRL partitions.

You are missing a major minus of partitioning CRL that many/most client 
don't support partitioned CRL, but worst do not properly recognize the 
cRLIssuer part of the CRLDP, and will not be able to match it to the IDP 
inside the crl, so they can be pushed to trust a partionned CRL for a 
cert it doesn't apply too.
*That* is the concern for lack of client side support. In the current 
state of things, partionned CRL is very probably a security hazard for 
many clients.

Meanwhile using cached OCSP without any of the addition discussed here 
is not a problem as long as the client is configured not to require a nonce.
The proposed OCSP change is an optimization, not absolutly required.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HhNib011535 for <[e-mail]>; Tue, 9 Dec 2003 09:43:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9HhNHr011534 for ietf-pkix-bks; Tue, 9 Dec 2003 09:43:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB9HhKib011527 for <[e-mail]>; Tue, 9 Dec 2003 09:43:22 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 Dec 2003 17:43:22 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hB9HdB6L008481 for <[e-mail]>; Tue, 9 Dec 2003 09:39:11 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hB9HhKY0009096 for <[e-mail]>; Tue, 9 Dec 2003 09:43:20 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFW260C; Tue, 9 Dec 2003 09:52:18 -0800
Message-ID: <[e-mail]>
Date: Tue, 09 Dec 2003 09:32:55 -0800
X-Sybari-Trust: 37b98aa9 7ddcb5bc fa431d80 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP in TLS handshake
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070106080909070505070600"
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.

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


Deacon, Alex wrote:
> nonceUnsupported does not preclude the use of OCSP responses in the TLS
> handshake.  My concern was ensuring what ever new text is added to v1
> does not preclude this use case.  In particular a client that receives
> an ocsp response that includes a nonce in a handshake must not reject
> the response because it contains a nonce it didn't generate.  

Thanks, Alex.

In that case, you're not talking about a real OCSP client: the TLS 
client doesn't perform the OCSP protocol.  You say that the (TLS) client 
shouldn't reject the response because of the nonce it didn't generate. 
I agree, but the client never generated an OCSP request, so there was 
never even an opportunity to generate a nonce.  It seems almost obvious 
that the nonce is irrelevant to the TLS client (when the response comes 
from the TLS server embedded in the TLS handshake).

I think it's wrong to equate this TLS client with a regular OCSP client.

Instead of trying to twiddle the OCSP spec to address these sorts of 
issues, I suggest that these (and whatever other) rules be gathered into 
a more general "Offline Processing of OCSP Responses" document.  This 
could be a separate I-D, or a new section in the OCSP (v2?) spec.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIwOTE3MzI1NVow
IwYJKoZIhvcNAQkEMRYEFFTlgT1xhku6u8aO31uLEdun4dA7MFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBALQTwoo/I92GLrPC7bmKFeMat5w3JyljN3eBa30s9dooPYMF
I9HWsGOtdij82pEhiA5epBco0+11kt3P4+jiNC4qXiNfIDA65TpCKSScMxo8pBAAGKOv/pVZ
mtzBGxuKfpHmhXR0iSPheZa3+SarZ+lsmQBfiQnKDO7JU81yfm+OK13bKK+AkBnROhkT1ub/
k3qms8u2IZcWh+E97l2wTdqH4P7K+cTD8FHYb9qN103IenNVFxIlvfpPZ+nKA5Y3hDQ5Ofm5
lVZew2iPjANyxxErmRUzwch6ZqOg6huVSKpB24I7yad75u/meuD3XI7cXYzgaKPrTtM1iu0q
IL2th0YAAAAAAAA=
--------------ms070106080909070505070600--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HLbib010615 for <[e-mail]>; Tue, 9 Dec 2003 09:21:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9HLbXJ010614 for ietf-pkix-bks; Tue, 9 Dec 2003 09:21:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HLbib010608 for <[e-mail]>; Tue, 9 Dec 2003 09:21:37 -0800 (PST) (envelope-from [e-mail])
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.10/) with ESMTP id hB9HLbd3025998 for <[e-mail]>; Tue, 9 Dec 2003 09:21:37 -0800 (PST)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <XLQFP7PD>; Tue, 9 Dec 2003 09:21:37 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Marc Branchaud'" <[e-mail]>, [e-mail]
Subject: RE: OCSP in TLS handshake
Date: Tue, 9 Dec 2003 09:21:37 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0032_01C3BE35.D867A0C0"; micalg=SHA1
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_0032_01C3BE35.D867A0C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


nonceUnsupported does not preclude the use of OCSP responses in the TLS
handshake.  My concern was ensuring what ever new text is added to v1
does not preclude this use case.  In particular a client that receives
an ocsp response that includes a nonce in a handshake must not reject
the response because it contains a nonce it didn't generate.  

Alex


> -----Original Message-----
> From: Marc Branchaud [mailto:[e-mail]] 
> Sent: Monday, December 08, 2003 3:59 PM
> To: [e-mail]
> Subject: Re: OCSP in TLS handshake
> 
> 
> Marc Branchaud wrote:
> > 
> > I'm not trying to be obtuse here (it actually takes very little 
> > effort),
> > but I really need a patient explanation of why nonceUnsupported 
> > precludes the use of OCSP responses in the TLS handshake.
> 
> OK, I'd settle for an impatient explanation...
> 
> 		M.
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXzCCAj0w
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/p9QMQ4fxiqmjCCA8AwggMpoAMCAQIC
EErIAANjYdQVAxbxhjabt80wDQYJKoZIhvcNAQEFBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3Vi
amVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYw
JAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0w
OTAyMjMyMzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xh
c3MgMiBFbXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsI
NvCX+hpUNSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf
6X1OISFh1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN
/n8CAwEAAaOB3zCB3DApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgw
EQYJYIZIAYb4QgEBBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMEQGA1UdIAQ9
MDswOQYLYIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYTA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9WU0NsYXNzMklu
dC5jcmwwDQYJKoZIhvcNAQEFBQADgYEANhj9M2DWF9MEtdhUX1Ia5ZIIKPSiQNrDW4wahpfvrqIV
/mzEzi/IAcozvvJ5WDOXl5JFcFpOKB3d98GIThuHVwI9kyXZfk5yNYlJF7O5dy9tDvmkiCXBznZz
ZWkFk3fn/ZOWGDhNWGx6nejSm+jQ24n9ScJ1BAOXpdSWgdgjQfAwggQPMIIDeKADAgECAhAzLr9g
Nl/Alm5BwDUqJfjZMA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3Qg
dG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UE
AxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw0wMzAyMjQwMDAwMDBaFw0wNDAyMjQy
MzU5NTlaMGUxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBp
ZW50czEuMCwGA1UEAxMlQURlYWNvbiAoRGVhY29uIEFsZXgsIFZlcmlTaWduLCBJbmMuKTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzx3sCPaQpHpxCg1L2vrDWdm9vpNny7aftpAvzfcCcjYn
EFPjODoBoEzqqTadrgD6YehNArWIWBf7STGJfQApFpSxCU5OWECQc+2Ti825B06KhAye00epJwgH
ByGqsDHGK7A+FlkpmqWybsLm2Q5kqdrv9gNFRw2oMRhsA6Ztx5sCAwEAAaOCAXYwggFyMAkGA1Ud
EwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVy
aVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1UdDwQEAwIFoDAcBgNV
HREEFTATgRFhbGV4QHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCB
jjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBW
MBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJl
bmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQW
MBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCD7anMuD4hgW1JGGSf+6Rf
25ZGkg2fjkCC8eh4XpTd5cQOhi+nQ1eUSxiU8r3UZJN1LQ5F9bkGj5G+hCQd+0mKvByk/l2Nwq34
/zZ9jraFBm60xDBF8FI2TfOCwlx6NsQR6xYdTl8IsvUx9oy0J8YBPFZLN3z2Q/JtLf07g/4mojGC
A88wggPLAgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xh
c3MgMiBFbXBsb3llZSBDQQIQMy6/YDZfwJZuQcA1KiX42TAJBgUrDgMCGgUAoIICYzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzEyMDkxNzIxMzZaMCMGCSqGSIb3
DQEJBDEWBBQy0ea5spSCdfys4ym7dcUQshEUuzBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMH
MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAKBggqhkiG
9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQMy6/YDZfwJZuQcA1KiX42TCB1AYLKoZIhvcN
AQkQAgsxgcSggcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln
biBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRw
czovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFz
cyAyIEVtcGxveWVlIENBAhAzLr9gNl/Alm5BwDUqJfjZMA0GCSqGSIb3DQEBAQUABIGAyBe6KJAD
m+eKUVc7sgUxooP92x75binjFipKGaezU91eqAxUs3TD2/8fo2lv0eUxn9GrfCRP1N/FvQkVZ/u1
mYvDiUocIA0Gc5/+nIh9OCb6rOdkaD2/NZGmRMmWkhaZMyym0K84JbtDQCL5Vdxo/kA6ge5t3+9v
/aASnnEN6xQAAAAAAAA=

------=_NextPart_000_0032_01C3BE35.D867A0C0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB92MXib098486 for <[e-mail]>; Mon, 8 Dec 2003 18:22:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB92MWI7098485 for ietf-pkix-bks; Mon, 8 Dec 2003 18:22:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB92MVib098478 for <[e-mail]>; Mon, 8 Dec 2003 18:22:31 -0800 (PST) (envelope-from [e-mail])
Received: from [10.84.130.244] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hB92MF7o006105; Mon, 8 Dec 2003 21:22:15 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06010201bbfaa7eadcc2@[128.89.89.75]>
In-Reply-To: <000c01c3bafc$ae734260$e8a47ad5@LiaquatDELL>
References: <000c01c3bafc$ae734260$e8a47ad5@LiaquatDELL>
Date: Mon, 8 Dec 2003 21:21:18 -0500
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Cc: "'Ryan M. Hurst'" <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, "'David Engberg'" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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:54 +0000 12/5/03, Liaquat Khan wrote:
>Ryan,
>
>We also agree with your viewpoint, particular the point about a nonce
>being a matter for local client policy. 
>
>In the various OCSP clients we have, the option of whether to include
>nonce or not in the request message is left to local policy (i.e. the
>administrator can configure whether or not nonce is included in the
>request message).

Yes, a client decides whether to include a nonce, or not. But, we 
need the standard to clearly indicate what the client will do with a 
response, when a nonce is included in a request. This is fundamental 
to the definition of the protocol.

>If the administrator decides nonces are necessary (to prevent replays)
>then he/she will select these and our OCSP clients will include these in
>the requests.  Now if an OCSP response is received back without a nonce
>it will be rejected by our OCSP clients.

that is an appropriate thing for the client to do, and is consistent 
with the "MUST reject" clarification that Russ articulated at the WG 
meeting.

>=On the other hand, if the administrator feels nonces are not required
>(to allow for cached responses) then he/she will not select to include
>one in outgoing responses.

right.

>The situation "we would like to have nonces in OCSP requests as default,
>but if the server legitimately doesn't support nonces we are happy to
>forgo nonces or we will generate a fresh request without a nonce" is not
>that common in my opinion.  If such a case does exist, local policy will
>probably be also happy to choose to not include a nonce in the OCSP
>request message in the first place.
>
>Regards,
>Liaquat
>

the hard part in all of this is how the client knows what the server 
is capable of doing, which seems not to be part of the discussion 
above.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB90kqib095001 for <[e-mail]>; Mon, 8 Dec 2003 16:46:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB90kq2v095000 for ietf-pkix-bks; Mon, 8 Dec 2003 16:46:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan02.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB90koib094995 for <[e-mail]>; Mon, 8 Dec 2003 16:46:50 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 23832 invoked by alias); 9 Dec 2003 00:46:51 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 23816 invoked by alias); 9 Dec 2003 00:46:50 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 9 Dec 2003 00:46:50 -0000
Received: (qmail 17976 invoked from network); 9 Dec 2003 00:46:50 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 9 Dec 2003 00:46:50 -0000
Date: Tue, 09 Dec 2003 09:47:43 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: Harald Tveit Alvestrand <[e-mail]>
Subject: Re[2]: DN Encoding by UTF8String
Cc: Russ Housley <[e-mail]>, [e-mail]
In-Reply-To: <194813577.1070841119@localhost>
References: <[e-mail]> <194813577.1070841119@localhost>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
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>

Harald,

Thanks for your comment.

> Sooner or later, the industry, IMHO, will have to embrace UTF-8 fully; 
> supporting the mess we've created for ourselves forever is not in the best 
> long term interest of the network.

Basically I agree with you, we MUST move to UTF-8 soon.
But, still now we are facing to some issues about UTF8string, e.g., name
comparison rule, and it seems that hard to solve yet them.
AFAIK, there will be a little PKI applications who are compliant with
the transition to UTF-8.

> As far as I know, there will be nobody coming to punish people issuing 
> non-UTF-8 certificates after Jan 1, 2004 that contain non-UTF8 encoding. 

I believe it;)

> And people will violate the standards to keep their legacy applications 
> running; that is how networks have always operated.

While we cannot solve or address the UTF8String issues, I think such
violations are unavoidable.

> But IMHO, they should be ashamed of themselves when they do so, and strive 
> towards eliminating the need for doing so as soon as possible. Not because 
> I say so, but because it's for the long term good of the Internet.

Sure.

To achieve the transition to UTF8 shortly, we should break the UTF8
issues, then the transition to UTF-8 is the next.
Which do you think should do first?


And one question to authors:
Do you have some plan to update the description in clause 4.1.2.4 of son
of RFC3280?


Regards,
shima

On Sun, 07 Dec 2003 23:51:59 -0800
Harald Tveit Alvestrand <[e-mail]> wrote:

> I must admit that I am not surprised.....
> 
> The encodings supported by older applications are many and various, but 
> nearly all of them share one of two properties:
> 
> - They are US-ASCII compatible
> - When using non-US-ASCII characters, they are violating the X.509 
> standards that they claim conformance to
> 
> If declaring that a number of applications are violating the IETF 
> standards, and not just the ITU standards, on January 1, 2004 will help 
> bring that day closer, I'm all for it.
> 
> Sooner or later, the industry, IMHO, will have to embrace UTF-8 fully; 
> supporting the mess we've created for ourselves forever is not in the best 
> long term interest of the network.
> 
> As far as I know, there will be nobody coming to punish people issuing 
> non-UTF-8 certificates after Jan 1, 2004 that contain non-UTF8 encoding. 
> And people will violate the standards to keep their legacy applications 
> running; that is how networks have always operated.
> 
> But IMHO, they should be ashamed of themselves when they do so, and strive 
> towards eliminating the need for doing so as soon as possible. Not because 
> I say so, but because it's for the long term good of the Internet.
> 
> My opinion.
> 
>                  Harald Alvestrand
> 
> 
> --On 6. desember 2003 13:29 -0500 Russ Housley <[e-mail]> wrote:
> 
> > This was added to RFC 2459, and retained in RFC 3280, based on comments
> > from Harald Alvestrand.   As most of the recipients know, Harald is the
> > Chair of the IETF, and a member of the  IESG.  Tim Polk spent a lot of
> > time on this issue, negotiating the exact words with Harald and any
> > others.  The desire is for certificate issuers to embrace international
> > character sets.
> >
> > Beyond this recap of the history, I will let Harald speak for himself.
> >
> > Russ
> >
> >
> > ----------------------- Original Message -----------------------
> > From:    Masaki SHIMAOKA <[e-mail]>
> > To:      Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>,
> > [e-mail], [e-mail], [e-mail]
> > Date:    Fri, 05 Dec 2003 16:09:10 +0900
> > Subject: DN Encoding by UTF8String
> >
> > Dear Authors and WG Chairs,
> >
> > RFC3280 mentioned that "all certificates issued after Dec 31, 2003 MUST
> > use UTF8String encoding".
> >
> > However, it seems that some applications do not yet support UTF8String
> > respectably and the detail of name comparison rule does not consider
> > UTF8String sufficiently.
> >
> > Therefore, existing CAs using except UTF8String for DN encoding SHOULD
> > do the following actions until solving these UTF8String problem.
> >
> >      An encoding for issuer field of the certificates issued after 2004
> >      SHOULD be same as an encoding for subject field of CA certificate
> >      already issued.
> >
> > Is this correct?
> >
> > Of course, when the UTF8String problem solves, all certificates
> > issuedMUST use UTF8String encoding.
> > I worry that some confused CAs issue wrong certificates using UTF8String
> > encoding forcibly, even though the CA had used another encoding till now.
> >
> > Best regards,
> > -----
> > Masaki SHIMAOKA
> >
> > SECOM Trust.net
> > System Engineering Dpt.
> > Tel: [phone] (ext.3605)
> > Fax: [phone]
> > e-mail: [e-mail]
> >
> >
> >
> 
> 
> 
> 

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB908tib093706 for <[e-mail]>; Mon, 8 Dec 2003 16:08:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB908tx8093705 for ietf-pkix-bks; Mon, 8 Dec 2003 16:08:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB908rib093700 for <[e-mail]>; Mon, 8 Dec 2003 16:08:54 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 Dec 2003 00:08:56 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hB904k6L026537 for <[e-mail]>; Mon, 8 Dec 2003 16:04:46 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hB908sY0025331 for <[e-mail]>; Mon, 8 Dec 2003 16:08:54 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFW25CP; Mon, 8 Dec 2003 16:17:51 -0800
Message-ID: <[e-mail]>
Date: Mon, 08 Dec 2003 15:58:32 -0800
X-Sybari-Trust: 1e45ccf9 64c784fd 8329c9bc 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP in TLS handshake
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040306020106010305050005"
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.

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

Marc Branchaud wrote:
> 
> I'm not trying to be obtuse here (it actually takes very little effort), 
> but I really need a patient explanation of why nonceUnsupported 
> precludes the use of OCSP responses in the TLS handshake.

OK, I'd settle for an impatient explanation...

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIwODIzNTgzMlow
IwYJKoZIhvcNAQkEMRYEFPXXusxTmWE2BOabLIW45rWnBQJxMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBACx17CnmPpmosbsxCmLIhVtwXTrMWhQrBXjaBrLLxNPFF2ve
LR1wFLJbDU03QhqvHm8L7N8NIYELbme7xgY55/Kr98H4/W0Mcx6neoqXQ0hMET+e7ZfmC+8b
7186+wMpXow/lhX9QTHCucgFbRdfGslsoXmmcX/Ei+7POv0qxD15IjyYGPAuQav4/6CZUoCm
xJJ5fed0cUoIk16F03bltsX11DpAAdpQByd3BPi7fjiKTJlRD5nmtmWoMXfI0OPKYvB/Trf1
wn85dklxiv8wTz3p1Ci84vMmV/hNOkpkOShz3l/fO4Mqfz+XxShx64W/xIPAdm4wCNPKx8cF
Ywn1sZwAAAAAAAA=
--------------ms040306020106010305050005--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8N4Wib091241 for <[e-mail]>; Mon, 8 Dec 2003 15:04:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8N4WCf091240 for ietf-pkix-bks; Mon, 8 Dec 2003 15:04:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8N4Vib091235 for <[e-mail]>; Mon, 8 Dec 2003 15:04:31 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hB8N4XoO012653 for <[e-mail]>; Mon, 8 Dec 2003 18:04:33 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Mon, 8 Dec 2003 18:04:28 -0500
Message-ID: <004a01c3bddf$a4a72540$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C3BDB5.BBD11D40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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_004B_01C3BDB5.BBD11D40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ryan:
=20
The client concern does not seem to cut the mustard since Carl's =
argument is
that we do not seem to have a standard for nonceless client, let alone
capability.  For the partitioned CRL, we have well-defined standard.
=20
As to the response size, I am sure that a partitioned CRL (one CRL for =
each
certificate) will be less than 400 bytes you cited.
=20
I think partitioning CRL for individual certificate has plusses in terms =
of
standard and removing the need for client.  It also has directory =
related
plusses in terms of replication.
=20
I think its minuses are in terms of CA's ability to support it (or =
requiring
delegated CRL issuer, i.e., Indirect CRL Issuer Model) and may be =
addition
and management of entries under the CA branch for the CRL partitions.
=20
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On
Behalf Of Ryan M. Hurst
Sent: Monday, December 08, 2003 3:05 PM
To: Carl Wallace; Deacon, Alex; [e-mail]
Subject: RE: Cached OCSP responses vs. single entry CRLs



Carl - These are just a few of the reasons, as for your question =
consider
the scenario of a issuer having to support mixed version/heterogeneous
environments.=20
=20
Although more recent Microsoft clients support partitioned CRLs, that =
does
not mean the ones before this concept existed do, what about clients =
based
on open source implementations, or ones running on other operating =
systems
that do not have support for this concept?=20
=20
TTPs still need to provide their subscribers and their relying parties =
with
revocation information without having to require subscribers to have
different profiled certificates for communication with different
constituents. Today if a CDP pointed to a partitioned CRL these clients
lacking support for this concept would not be able to validate the CDP.
=20
The use of OCSP gets around this issue, as long as we do not introduce =
any
breaking changes into the protocol (and don't forget the RFC did allow =
for
the pre-production concept explicitly).
=20
Beyond the deployability concepts above, OCSP has a number of other =
benefits
as well that make it a very natural fit (400 byte responses for =
example);
also considering there are vendors with products that deal with these
concepts available today OCSP really is the natural solution.=20
=20
Ryan

  _____ =20

From: Carl Wallace [mailto:[e-mail]]
Sent: Mon 12/8/2003 5:39 AM
To: 'Deacon, Alex'; Ryan M. Hurst; [e-mail]
Subject: RE: Cached OCSP responses vs. single entry CRLs



Response to following two comments below...

> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Deacon, Alex
> Sent: Friday, December 05, 2003 7:05 PM
> Subject: RE: Cached OCSP responses vs. single entry CRLs
>
> We looked into this.  The problem is that client support for
> "crl partitioning" (in this case a partition by individual
> serial number) is just about non-existant.
>
> Alex
>

> From: Ryan M. Hurst [mailto:[e-mail]]
> Sent: Friday, December 05, 2003 6:30 PM
> Subject: RE: Cached OCSP responses vs. single entry CRLs
>
> Carl there are a number of reasons, one of the most
> significant being backwards compatibility; many existing
> client implementations do not support partitioned CRLs and
> there is not way to tell from a CDP if the data on the other
> end represents a partitioned CRL or a full one.
>
> Additionally there are commercial OCSP responders out there
> that support this concept, yet very few CAs support the use
> of portioned CRLs to that granularity.
>
> Ryan

The responses regarding lack of client side support are somewhat =
strange.
It is not possible that deployed client-side support for partitioned =
CRLs is
less than deployed client-side support for the yet-to-be-defined =
solution
for cached OCSP.=20

On the other side of the transaction, what is the protocol used to =
populate
the responders that serve pre-produced responses?  Is this something =
that
would need to be standardized too?  There are already standards-based =
means
of replicating directories.





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

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

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D269275922-08122003>Ryan:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D269275922-08122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D269275922-08122003>The=20
client concern does not seem to cut the mustard since Carl's argument is =
that we=20
do not seem to have a standard for nonceless client, let alone =
capability.&nbsp;=20
For the partitioned CRL, we have well-defined =
standard.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D269275922-08122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D269275922-08122003>As to=20
the response size, I am sure that a partitioned CRL (one CRL for each=20
certificate) will be less than 400 bytes you cited.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D269275922-08122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D269275922-08122003>I=20
think partitioning CRL for individual certificate has plusses in terms =
of=20
standard and removing the need for client.&nbsp; It also has directory =
related=20
plusses in terms of replication.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D269275922-08122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D269275922-08122003>I=20
think its minuses are in terms of CA's ability to support it (or =
requiring=20
delegated CRL issuer, i.e., Indirect CRL Issuer Model) and may be =
addition and=20
management of entries under the CA branch for the CRL=20
partitions.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D269275922-08122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D269275922-08122003></SPAN></FONT>
<DIV></DIV><FONT face=3DTahoma><FONT size=3D2>-----Original=20
Message-----<BR><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>Ryan M.=20
Hurst<BR><B>Sent:</B> Monday, December 08, 2003 3:05 PM<BR><B>To:</B> =
Carl=20
Wallace; Deacon, Alex; [e-mail]<BR><B>Subject:</B> RE: Cached =
OCSP=20
responses vs. single entry CRLs<BR><BR></FONT></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV id=3DidOWAReplyText33265 dir=3Dltr>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Carl - =
These are just a few=20
  of the reasons, as for your question consider the scenario of a issuer =
having=20
  to support mixed version/heterogeneous environments. </FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Although =
more=20
  recent&nbsp;Microsoft clients support partitioned CRLs, that&nbsp;does =
not=20
  mean the ones before this concept existed do, what about clients based =
on open=20
  source implementations, or ones running on other operating systems =
that do not=20
  have support for this concept? </FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>TTPs still =
need to provide=20
  their subscribers and their relying parties&nbsp;with revocation =
information=20
  without having to require subscribers to have different profiled =
certificates=20
  for communication with different constituents. Today if a CDP pointed =
to a=20
  partitioned CRL these clients lacking support for this concept would =
not be=20
  able to validate the CDP.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>The use of OCSP gets around =
this issue,=20
  as long as we do not introduce any breaking changes into the protocol =
(and=20
  don't forget the RFC did allow for the pre-production concept=20
  explicitly).</FONT></DIV></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
  size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>Beyond =
the&nbsp;deployability concepts=20
  above, OCSP has a number of other benefits as well that make it a=20
  very&nbsp;natural fit (400 byte responses for example); =
also&nbsp;considering=20
  there are&nbsp;vendors with products that deal with these concepts =
available=20
  today OCSP really is the natural solution.&nbsp;</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>Ryan</FONT></DIV></DIV>
  <DIV dir=3Dltr><BR>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Carl Wallace=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Mon 12/8/2003 5:39=20
  AM<BR><B>To:</B> 'Deacon, Alex'; Ryan M. Hurst;=20
  [e-mail]<BR><B>Subject:</B> RE: Cached OCSP responses vs. =
single=20
  entry CRLs<BR></FONT><BR></DIV>
  <DIV>
  <P><FONT size=3D2>Response to following two comments =
below...<BR><BR>&gt; From:=20
  [e-mail]<BR>&gt; [<A=20
  =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]=20
  On Behalf Of Deacon, Alex<BR>&gt; Sent: Friday, December 05, 2003 7:05 =

  PM<BR>&gt; Subject: RE: Cached OCSP responses vs. single entry=20
  CRLs<BR>&gt;<BR>&gt; We looked into this.&nbsp; The problem is that =
client=20
  support for<BR>&gt; "crl partitioning" (in this case a partition by=20
  individual<BR>&gt; serial number) is just about =
non-existant.<BR>&gt;<BR>&gt;=20
  Alex<BR>&gt;<BR><BR>&gt; From: Ryan M. Hurst [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]=
m</A>]<BR>&gt;=20
  Sent: Friday, December 05, 2003 6:30 PM<BR>&gt; Subject: RE: Cached =
OCSP=20
  responses vs. single entry CRLs<BR>&gt;<BR>&gt; Carl there are a =
number of=20
  reasons, one of the most<BR>&gt; significant being backwards =
compatibility;=20
  many existing<BR>&gt; client implementations do not support =
partitioned CRLs=20
  and<BR>&gt; there is not way to tell from a CDP if the data on the=20
  other<BR>&gt; end represents a partitioned CRL or a full =
one.<BR>&gt;<BR>&gt;=20
  Additionally there are commercial OCSP responders out there<BR>&gt; =
that=20
  support this concept, yet very few CAs support the use<BR>&gt; of =
portioned=20
  CRLs to that granularity.<BR>&gt;<BR>&gt; Ryan<BR><BR>The responses =
regarding=20
  lack of client side support are somewhat strange.<BR>It is not =
possible that=20
  deployed client-side support for partitioned CRLs is<BR>less than =
deployed=20
  client-side support for the yet-to-be-defined solution<BR>for cached=20
  OCSP.&nbsp;<BR><BR>On the other side of the transaction, what is the =
protocol=20
  used to populate<BR>the responders that serve pre-produced =
responses?&nbsp; Is=20
  this something that<BR>would need to be standardized too?&nbsp; There =
are=20
  already standards-based means<BR>of replicating=20
  directories.<BR><BR><BR></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_004B_01C3BDB5.BBD11D40--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8MuZib090600 for <[e-mail]>; Mon, 8 Dec 2003 14:56:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8MuZ1L090599 for ietf-pkix-bks; Mon, 8 Dec 2003 14:56:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.vtcif.telstra.com.au (mailao.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8MuXib090587 for <[e-mail]>; Mon, 8 Dec 2003 14:56:34 -0800 (PST) (envelope-from [e-mail])
Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailao.vtcif.telstra.com.au (Postfix) with ESMTP id 3929E25B49 for <[e-mail]>; Tue,  9 Dec 2003 09:56:28 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 999B522883 for <[e-mail]>; Tue,  9 Dec 2003 09:56:27 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA12586 for <[e-mail]>; Tue, 9 Dec 2003 09:56:27 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: POLL:   MUST  reject in OCSPv1
Date: Tue, 9 Dec 2003 08:56:11 +1000
Message-ID: <[e-mail]>
Thread-Topic: POLL:   MUST  reject in OCSPv1
Thread-Index: AcO92FaEZYKQNVnDTXGqUveRl6QNdgABR/YA
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB8MuYib090595
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>

AGREE


P.S. Terry,  #4 does not really require a server to recognize a particular extension.  Regardless of any extensions in a request, a caching server can simply always include the nonceUnsupported extension.
I would support SHOULD (or MUST) in #4.  Using SHOULD means existing caching servers are not made non-compliant, which (I think) was Ryan's main concern.



> 4. Conversely, if a server receives a nonced 
>    request but is unable to incorporate the 
>    nonce in its response, the server MUST 
>    include the nonceUnsupported extension. 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8MGwib089345 for <[e-mail]>; Mon, 8 Dec 2003 14:16:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8MGw2f089344 for ietf-pkix-bks; Mon, 8 Dec 2003 14:16:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8MGuib089327 for <[e-mail]>; Mon, 8 Dec 2003 14:16:57 -0800 (PST) (envelope-from [e-mail])
Received: from [e-mail] by imo-d04.mx.aol.com (mail_out_v36_r1.1.) id 6.70.35e6b4f5 (16086); Mon, 8 Dec 2003 17:16:08 -0500 (EST)
Received: from  pc655301.nscp.aoltw.net (h-10-169-149-63.nscp.aoltw.net [10.169.149.63]) by air-id10.mx.aol.com (v97.8) with ESMTP id MAILINID103-3ed63fd4f82725b; Mon, 08 Dec 2003 17:16:08 -0500
Date: Mon, 8 Dec 2003 14:16:23 -0800
From: "Terry Hayes" <[e-mail]>
Subject: RE: POLL:   MUST  reject in OCSPv1
To: [e-mail]
cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Mailer: AOL Communicator (20031113.4 Win)
Organization: AOL
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.149.63
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>

Correct!  I would vote YES if #4 was SHOULD.

Terry Hayes



Michael Myers wrote on 12/8/2003, 12:42 PM:
> 
> > From: Terry Hayes [mailto:[e-mail]] 
> > 
> > . . . 
> > 
> > If you remove item 4 from the proposed resolution 
> > (or change it to allow the server to include the 
> > extension), then I change my "vote" to YES. 
> 
> 
> Terry, 
> 
> To be clear, if #4 was SHOULD include nonceUnsupported extension 
> vs. MUST, you'd vote YES, correct? 
> 
> Mike 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8Kuqib075481 for <[e-mail]>; Mon, 8 Dec 2003 12:56:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8KuqlT075480 for ietf-pkix-bks; Mon, 8 Dec 2003 12:56:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8Kupib075474 for <[e-mail]>; Mon, 8 Dec 2003 12:56:51 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hB8KuqoO022755 for <[e-mail]>; Mon, 8 Dec 2003 15:56:53 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: POLL:   MUST  reject in OCSPv1
Date: Mon, 8 Dec 2003 15:56:47 -0500
Message-ID: <001b01c3bdcd$ced58170$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB8Kuqib075475
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>

AGREE

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Michael Myers
Sent: Monday, December 08, 2003 1:46 PM
To: [e-mail]
Cc: Carlisle Adams
Subject: POLL: MUST reject in OCSPv1



All,

OK, so let's take a full-up poll on what we were looking at a couple of
weeks ago to see where we stand today.  Please respond with either YES or
NO.  Take discussions to the DISCUSS thread.

This approach preserves installed base functionality and yet enables a clear
and technically complete resolution of the various perspectives.

To date, on the related DISCUSS thread, six have voiced agreement to this
path forward and two disagree.  From that
record:

AGREE
-----
David Engberg,      Corestreet
Florian Oelmaier,   Sytrust
Ambarish Malpani,   Cenzic
Marc Branchaud,     RSA
Miguel Rodriguez,   SeguriDATA
Frank Balluffi,     Deutsche Bank

DISAGREE
--------
Ryan Hurst,         Microsoft
Alex Deacon,        VeriSign


PROPOSED
--------
The proposed resolution is as follows:

1. Cycle v1 as Proposed Standard.  It was well
   on its way to Draft but we'll pull it back.

2. Define nonceUnsupported extension subject
   to the following semantics.

3. Clients that send a nonce:

   a. MUST reject a non-nonced response if
      that response includes either the value
      "good" or "revoked" AND it fails to
      include the nonceUnsupported extension;

   b. Else, if such response includes the
      nonceUnsupported extension, clients
      MAY accept the response subject to the
      advice in the Security Considerations
      section of this document.

4. Conversely, if a server receives a nonced
   request but is unable to incorporate the
   nonce in its response, the server MUST
   include the nonceUnsupported extension.

We now have clearance to cycle v1 at Proposed so that's no longer a
predicate.

Thank you for your continued patience as we work towards resolving this
issue.

Mike





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8KeAib071986 for <[e-mail]>; Mon, 8 Dec 2003 12:40:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8KeAnU071985 for ietf-pkix-bks; Mon, 8 Dec 2003 12:40:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8Ke8ib071979 for <[e-mail]>; Mon, 8 Dec 2003 12:40:08 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hB8KdxA41555; Mon, 8 Dec 2003 13:39:59 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Terry Hayes" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: POLL:   MUST  reject in OCSPv1
Date: Mon, 8 Dec 2003 13:42:01 -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>

> From: Terry Hayes [mailto:[e-mail]]
>
> . . .
>
> If you remove item 4 from the proposed resolution
> (or change it to allow the server to include the
> extension), then I change my "vote" to YES.


Terry,

To be clear, if #4 was SHOULD include nonceUnsupported extension
vs. MUST, you'd vote YES, correct?

Mike





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8KTdib070146 for <[e-mail]>; Mon, 8 Dec 2003 12:29:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8KTdYP070145 for ietf-pkix-bks; Mon, 8 Dec 2003 12:29:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8KTbib070121 for <[e-mail]>; Mon, 8 Dec 2003 12:29:37 -0800 (PST) (envelope-from [e-mail])
Received: from [e-mail] by imo-d06.mx.aol.com (mail_out_v36_r1.1.) id 6.25.41e09160 (16098); Mon, 8 Dec 2003 15:29:23 -0500 (EST)
Received: from  pc655301.nscp.aoltw.net (h-10-169-149-63.nscp.aoltw.net [10.169.149.63]) by air-id11.mx.aol.com (v97.8) with ESMTP id MAILINID112-3ee23fd4df219f; Mon, 08 Dec 2003 15:29:23 -0500
Date: Mon, 8 Dec 2003 12:29:38 -0800
From: "Terry Hayes" <[e-mail]>
Subject: Re: POLL:   MUST  reject in OCSPv1
To: [e-mail]
cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Mailer: AOL Communicator (20031113.4 Win)
Organization: AOL
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.149.63
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

As I have said many times previously, requiring the server to recognize a particular extension is incompatible with the current OCSP protocol definition.  If you remove item 4 from the proposed resolution (or change it to allow the server to include the extension), then I change my "vote" to YES.

Terry Hayes


Michael Myers wrote on 12/8/2003, 10:46 AM:
> 
> All, 
> 
> OK, so let's take a full-up poll on what we were looking at a 
> couple of weeks ago to see where we stand today.  Please respond 
> with either YES or NO.  Take discussions to the DISCUSS thread. 
> 
> This approach preserves installed base functionality and yet 
> enables a clear and technically complete resolution of the 
> various perspectives. 
> 
> To date, on the related DISCUSS thread, six have voiced 
> agreement to this path forward and two disagree.  From that 
> record: 
> 
> AGREE 
> ----- 
> David Engberg,      Corestreet 
> Florian Oelmaier,   Sytrust 
> Ambarish Malpani,   Cenzic 
> Marc Branchaud,     RSA 
> Miguel Rodriguez,   SeguriDATA 
> Frank Balluffi,     Deutsche Bank 
> 
> DISAGREE 
> -------- 
> Ryan Hurst,         Microsoft 
> Alex Deacon,        VeriSign 
> 
> 
> PROPOSED 
> -------- 
> The proposed resolution is as follows: 
> 
> 1. Cycle v1 as Proposed Standard.  It was well 
>    on its way to Draft but we'll pull it back. 
> 
> 2. Define nonceUnsupported extension subject 
>    to the following semantics. 
> 
> 3. Clients that send a nonce: 
> 
>    a. MUST reject a non-nonced response if 
>       that response includes either the value 
>       "good" or "revoked" AND it fails to 
>       include the nonceUnsupported extension; 
> 
>    b. Else, if such response includes the 
>       nonceUnsupported extension, clients 
>       MAY accept the response subject to the 
>       advice in the Security Considerations 
>       section of this document. 
> 
> 4. Conversely, if a server receives a nonced 
>    request but is unable to incorporate the 
>    nonce in its response, the server MUST 
>    include the nonceUnsupported extension. 
> 
> We now have clearance to cycle v1 at Proposed so that's no 
> longer a predicate. 
> 
> Thank you for your continued patience as we work towards 
> resolving this issue. 
> 
> Mike 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8KPgib069261 for <[e-mail]>; Mon, 8 Dec 2003 12:25:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8KPgi2069259 for ietf-pkix-bks; Mon, 8 Dec 2003 12:25:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8KPfib069220 for <[e-mail]>; Mon, 8 Dec 2003 12:25:41 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hB8KPZ7o019236; Mon, 8 Dec 2003 15:25:36 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06010215bbfa8ac4ef4c@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 8 Dec 2003 15:24:34 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Policy Standardization
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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:18 +1300 12/6/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>Citing the critique from the Counterpane analysis of Ipsec and IKE from 5
>>years ago is a nice touch, but you should be aware that the non-IKE
>>criticisms were largely refuted in messages on the IPsec list.
>
>Well that's a marvellous strawman you've demolished there, but you still
>haven't addressed the original point I made, which is that without a
>rationale, without explanations of difficult-to-understand points, a complex
>standard is in trouble.  In fact you've pretty much agreed with my comments:

I doubt that :-)

>
>   Unfortunately, the folks who performed the analysis were not protocol
>   experts. They made assertions of what was wrong and how it should be fixed,
>   and in most instances THEY were wrong.

What we have here is an example of knowledgeable people in one area, 
critiquing a document in an area that is not within their expertise. 
Most IETF standards are written for developers, not for end users, 
system administrators, etc.

>Without a rationale and implementation notes to guide them, there was no way
>they could understand the spec, so they ended up analysing something that was
>different from whatever it was the spec was trying to describe.  What was
>refuted was the analysis of the way Bruce thought IPsec worked, not the fact
>that the spec is confusing, ambiguous, and contradictory.

Nonsense! The example that prompted my response was the failure of MS 
implementors to do what the standard clearly stated, and what 
essentially ALL other implementors DID manage to get right. Why the 
MS guys failed here is open for debate. But the aspect of IPsec (not 
IKE) that they got wrong was not ambiguous, and it followed the 
practice that is used in essentially ALL other access control list 
systems for 25+ years. Also, as I noted in my initial response, most 
of the Counterpane criticisms were related to IKE, not to IPsec per 
se.

>Your comments do however raise one question: If (as you say) the intent wasn't
>to create an IPsec for dummies, who exactly is the target audience?  It's not
>the average person, it's not techies and sysadmins, it's not cryptographers,
>it's not security researchers, just who *was* this written for anyway?  Your
>first message implied that the only people capable of understanding IPsec are
>people who already understand IPsec before they start.  So the target audience
>for the IPsec spec is "Anyone who's spent the last 5-10 years on the IPsec
>list"?  What happens when an outsider has to implement IPsec?   (Well, I think
>that's obvious from real-world experience with IPsec deployment when 2 or more
>different vendors are involved).  Is everyone who needs a technical question
>on IPsec answered expected to track down IPsec list members and ask them, like
>I did recently when I needed an answer to a simple yes/no question?  What
>happens when the last person who was involved in the IPsec design process
>retires and there's no-one left to ask about all the stuff the spec doesn't
>tell you?

As I noted above, IETF standards are written for developers. Other 
authors typically write books for users, sys admins, CIOs, etc.

>To get back to the original point about including explanations and
>implementation guidance in specs, a spec is difficult now and downright
>dangerous in the future when there's no-one left to explain all the bits the
>authors never bothered writing down.  Consider as a nice counterexample the
>DNS SRV spec.  It starts with the usual MUST/SHOULD/MAY stuff.  All the
>features are clearly explained (not just "It does X" but "It does X because
>Y").  There's advice for administrators.  There's pseudocode for certain
>processes that people might find confusing.  There's a complete worked example
>(I cut & pasted it into a zone file for testing).  You can implement it
>straight out of the spec in about half an hour (OK, it's nowhere near as
>complex as IPsec), and it works the first time.  With every server I could
>find (and that's definitely nothing like IPsec).
>
>The reason why it did that is because the authors didn't start by deciding
>"We're not going to write a DNS for dummies", but because they wrote a spec
>for implementors and users, which is why anyone can pick it up and write a
>fully functional, interoperable DNS SRV implementation from it.  Can you do
>that with IPsec, or PKIX?

2782 seems to be a well written RFC, but it is far from typical. In 
fact, it is very unusual in this respect. If the IESG wants all RFCs 
to be of this form, then they can require a different style of 
documents. However, the trend has not been to call for this style of 
writing, and that's not suprising, since not other standards body 
writes documents in this way either.

So, what's the bottom line? Could IPsec be better documented, yes. Is 
it a bad spec, no, not compared to most others in the IETF, ANSI, 
IEEE, and ITU realms. Did the implementors who screwed up the SPD 
management interface for MS products do so because RFC 2401 does not 
provide rationale for the ordering requirement?  Possible, but 
unlikely, since so many others managed to get this right, and without 
recourse to the authors or the mailing list.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8KNqib068147 for <[e-mail]>; Mon, 8 Dec 2003 12:23:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8KNqE6068146 for ietf-pkix-bks; Mon, 8 Dec 2003 12:23:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8KNpib068131 for <[e-mail]>; Mon, 8 Dec 2003 12:23:51 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29378; Mon, 8 Dec 2003 15:23:37 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sha244-01.txt
Date: Mon, 08 Dec 2003 15:23:37 -0500
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		: A 224-bit One-way Hash Function: SHA-224
	Author(s)	: R. Housley
	Filename	: draft-ietf-pkix-sha244-01.txt
	Pages		: 6
	Date		: 2003-12-8
	
This document specifies a 224-bit one-way hash function, called
SHA-224.  A SHA-224 has value is simply the truncation of the SHA-256
hash value.  SHA-256 is the 256-bit one-way hash function specified
by the National Institute of Standards and Technology (NIST).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha244-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-sha244-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-sha244-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-sha244-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-sha244-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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8K4uib064209 for <[e-mail]>; Mon, 8 Dec 2003 12:04:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8K4uRp064208 for ietf-pkix-bks; Mon, 8 Dec 2003 12:04:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8K4tib064202 for <[e-mail]>; Mon, 8 Dec 2003 12:04:55 -0800 (PST) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 8 Dec 2003 12:04:48 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 8 Dec 2003 12:04:12 -0800
Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Dec 2003 12:05:00 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 8 Dec 2003 12:04:19 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 8 Dec 2003 12:04:39 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 8 Dec 2003 12:04:33 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Mon, 8 Dec 2003 12:04:46 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Cached OCSP responses vs. single entry CRLs
thread-index: AcO9kLtE6c0GOA2vRaW+GKL6F8KkswANBFDu
From: "Ryan M. Hurst" <[e-mail]>
To: "Carl Wallace" <[e-mail]>, "Deacon, Alex" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 08 Dec 2003 20:04:33.0512 (UTC) FILETIME=[7F66BE80:01C3BDC6]
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BDC6.8760B952"

------_=_NextPart_001_01C3BDC6.8760B952
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Carl - These are just a few of the reasons, as for your question =
consider the scenario of a issuer having to support mixed =
version/heterogeneous environments.=20
=20
Although more recent Microsoft clients support partitioned CRLs, that =
does not mean the ones before this concept existed do, what about =
clients based on open source implementations, or ones running on other =
operating systems that do not have support for this concept?=20
=20
TTPs still need to provide their subscribers and their relying parties =
with revocation information without having to require subscribers to =
have different profiled certificates for communication with different =
constituents. Today if a CDP pointed to a partitioned CRL these clients =
lacking support for this concept would not be able to validate the CDP.
=20
The use of OCSP gets around this issue, as long as we do not introduce =
any breaking changes into the protocol (and don't forget the RFC did =
allow for the pre-production concept explicitly).
=20
Beyond the deployability concepts above, OCSP has a number of other =
benefits as well that make it a very natural fit (400 byte responses for =
example); also considering there are vendors with products that deal =
with these concepts available today OCSP really is the natural solution. =

=20
Ryan

________________________________

From: Carl Wallace [mailto:[e-mail]]
Sent: Mon 12/8/2003 5:39 AM
To: 'Deacon, Alex'; Ryan M. Hurst; [e-mail]
Subject: RE: Cached OCSP responses vs. single entry CRLs



Response to following two comments below...

> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Deacon, Alex
> Sent: Friday, December 05, 2003 7:05 PM
> Subject: RE: Cached OCSP responses vs. single entry CRLs
>
> We looked into this.  The problem is that client support for
> "crl partitioning" (in this case a partition by individual
> serial number) is just about non-existant.
>
> Alex
>

> From: Ryan M. Hurst [mailto:[e-mail]]
> Sent: Friday, December 05, 2003 6:30 PM
> Subject: RE: Cached OCSP responses vs. single entry CRLs
>
> Carl there are a number of reasons, one of the most
> significant being backwards compatibility; many existing
> client implementations do not support partitioned CRLs and
> there is not way to tell from a CDP if the data on the other
> end represents a partitioned CRL or a full one.
>
> Additionally there are commercial OCSP responders out there
> that support this concept, yet very few CAs support the use
> of portioned CRLs to that granularity.
>
> Ryan

The responses regarding lack of client side support are somewhat =
strange.
It is not possible that deployed client-side support for partitioned =
CRLs is
less than deployed client-side support for the yet-to-be-defined =
solution
for cached OCSP.=20

On the other side of the transaction, what is the protocol used to =
populate
the responders that serve pre-produced responses?  Is this something =
that
would need to be standardized too?  There are already standards-based =
means
of replicating directories.





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

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7122.0">=0A=
<TITLE>RE: Cached OCSP responses vs. single entry CRLs</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText33265 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Carl - These =
are just a few =0A=
of the reasons, as for your question consider the scenario of a issuer =
having to =0A=
support mixed version/heterogeneous environments. </FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Although more =0A=
recent&nbsp;Microsoft clients support partitioned CRLs, that&nbsp;does =
not mean =0A=
the ones before this concept existed do, what about clients based on =
open source =0A=
implementations, or ones running on other operating systems that do not =
have =0A=
support for this concept? </FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>TTPs still =
need to provide =0A=
their subscribers and their relying parties&nbsp;with revocation =
information =0A=
without having to require subscribers to have different profiled =
certificates =0A=
for communication with different constituents. Today if a CDP pointed to =
a =0A=
partitioned CRL these clients lacking support for this concept would not =
be able =0A=
to validate the CDP.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>The use of OCSP gets around =
this issue, as =0A=
long as we do not introduce any breaking changes into the protocol (and =
don't =0A=
forget the RFC did allow for the pre-production concept =0A=
explicitly).</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =0A=
size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Beyond the&nbsp;deployability =
concepts =0A=
above, OCSP has a number of other benefits as well that make it a =0A=
very&nbsp;natural fit (400 byte responses for example); =
also&nbsp;considering =0A=
there are&nbsp;vendors with products that deal with these concepts =
available =0A=
today OCSP really is the natural solution.&nbsp;</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>Ryan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> Carl Wallace =0A=
[mailto:[e-mail]]<BR><B>Sent:</B> Mon 12/8/2003 5:39 =0A=
AM<BR><B>To:</B> 'Deacon, Alex'; Ryan M. Hurst; =0A=
[e-mail]<BR><B>Subject:</B> RE: Cached OCSP responses vs. =
single entry =0A=
CRLs<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Response to following two comments =
below...<BR><BR>&gt; From: =0A=
[e-mail]<BR>&gt; [<A =0A=
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] =0A=
On Behalf Of Deacon, Alex<BR>&gt; Sent: Friday, December 05, 2003 7:05 =0A=
PM<BR>&gt; Subject: RE: Cached OCSP responses vs. single entry =0A=
CRLs<BR>&gt;<BR>&gt; We looked into this.&nbsp; The problem is that =
client =0A=
support for<BR>&gt; "crl partitioning" (in this case a partition by =0A=
individual<BR>&gt; serial number) is just about =
non-existant.<BR>&gt;<BR>&gt; =0A=
Alex<BR>&gt;<BR><BR>&gt; From: Ryan M. Hurst [<A =0A=
href=3D"mailto:[e-mail]">mailto:[e-mail]=
m</A>]<BR>&gt; =0A=
Sent: Friday, December 05, 2003 6:30 PM<BR>&gt; Subject: RE: Cached OCSP =0A=
responses vs. single entry CRLs<BR>&gt;<BR>&gt; Carl there are a number =
of =0A=
reasons, one of the most<BR>&gt; significant being backwards =
compatibility; many =0A=
existing<BR>&gt; client implementations do not support partitioned CRLs =0A=
and<BR>&gt; there is not way to tell from a CDP if the data on the =
other<BR>&gt; =0A=
end represents a partitioned CRL or a full one.<BR>&gt;<BR>&gt; =
Additionally =0A=
there are commercial OCSP responders out there<BR>&gt; that support this =0A=
concept, yet very few CAs support the use<BR>&gt; of portioned CRLs to =
that =0A=
granularity.<BR>&gt;<BR>&gt; Ryan<BR><BR>The responses regarding lack of =
client =0A=
side support are somewhat strange.<BR>It is not possible that deployed =0A=
client-side support for partitioned CRLs is<BR>less than deployed =
client-side =0A=
support for the yet-to-be-defined solution<BR>for cached =
OCSP.&nbsp;<BR><BR>On =0A=
the other side of the transaction, what is the protocol used to =
populate<BR>the =0A=
responders that serve pre-produced responses?&nbsp; Is this something =0A=
that<BR>would need to be standardized too?&nbsp; There are already =0A=
standards-based means<BR>of replicating =0A=
directories.<BR><BR><BR></FONT></P></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C3BDC6.8760B952--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8Ii1ib043611 for <[e-mail]>; Mon, 8 Dec 2003 10:44:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8Ii1iq043610 for ietf-pkix-bks; Mon, 8 Dec 2003 10:44:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8Ihxib043594 for <[e-mail]>; Mon, 8 Dec 2003 10:43:59 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hB8Ii1A33541; Mon, 8 Dec 2003 11:44:01 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Carlisle Adams" <[e-mail]>
Subject: POLL:   MUST  reject in OCSPv1
Date: Mon, 8 Dec 2003 11:46:03 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE 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>

All,

OK, so let's take a full-up poll on what we were looking at a
couple of weeks ago to see where we stand today.  Please respond
with either YES or NO.  Take discussions to the DISCUSS thread.

This approach preserves installed base functionality and yet
enables a clear and technically complete resolution of the
various perspectives.

To date, on the related DISCUSS thread, six have voiced
agreement to this path forward and two disagree.  From that
record:

AGREE
-----
David Engberg,      Corestreet
Florian Oelmaier,   Sytrust
Ambarish Malpani,   Cenzic
Marc Branchaud,     RSA
Miguel Rodriguez,   SeguriDATA
Frank Balluffi,     Deutsche Bank

DISAGREE
--------
Ryan Hurst,         Microsoft
Alex Deacon,        VeriSign


PROPOSED
--------
The proposed resolution is as follows:

1. Cycle v1 as Proposed Standard.  It was well
   on its way to Draft but we'll pull it back.

2. Define nonceUnsupported extension subject
   to the following semantics.

3. Clients that send a nonce:

   a. MUST reject a non-nonced response if
      that response includes either the value
      "good" or "revoked" AND it fails to
      include the nonceUnsupported extension;

   b. Else, if such response includes the
      nonceUnsupported extension, clients
      MAY accept the response subject to the
      advice in the Security Considerations
      section of this document.

4. Conversely, if a server receives a nonced
   request but is unable to incorporate the
   nonce in its response, the server MUST
   include the nonceUnsupported extension.

We now have clearance to cycle v1 at Proposed so that's no
longer a predicate.

Thank you for your continued patience as we work towards
resolving this issue.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8HHkib011763 for <[e-mail]>; Mon, 8 Dec 2003 09:17:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8HHkUr011762 for ietf-pkix-bks; Mon, 8 Dec 2003 09:17:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8HHkib011757 for <[e-mail]>; Mon, 8 Dec 2003 09:17:46 -0800 (PST) (envelope-from [e-mail])
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.10/) with ESMTP id hB8HHk2u009737; Mon, 8 Dec 2003 09:17:46 -0800 (PST)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <XLQFNPQ8>; Mon, 8 Dec 2003 09:17:46 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "Deacon, Alex" <[e-mail]>, "Ryan M. Hurst" <[e-mail]>, [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Mon, 8 Dec 2003 09:17:45 -0800 
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>

Mike,

Clearly education and interop testing is a large part of the solution (and
one we have spent some time doing).

As for your blunt statement, the issue is when the non-normative statement
"The nonce cryptographically binds a request and a response to prevent
replay attacks." is read in the broader context of the normative statements
regarding extension support, things start to crumble. 

Alex


> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]] 
> Sent: Friday, December 05, 2003 5:22 PM
> To: Deacon, Alex; Ryan M. Hurst; [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Alex,
> 
> Comments embedded below.
> 
> Mike
> 
> > -----Original Message-----
> > From: Deacon, Alex [mailto:[e-mail]]
> > Sent: Friday, December 05, 2003 4:59 PM
> > To: 'Michael Myers'; Ryan M. Hurst; [e-mail]
> > Subject: RE: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> > If I could be ensured that every OCSP client used to
> > hit ocsp.verisign.com would not include a nonce,
> > then I would have no problem with a MUST reject.
> 
> Well, that probably won't happen in the given target 
> environment.  But what you can do is tell them they shouldn't 
> while still providing them the full value of your OCSP 
> services. Given a sufficiently reliable clue, they probably 
> won't do so again.
> 
> > However because this environment receives requests
> > from a heterogeneous population of clients over
> > which we have no administrative control (to
> > paraphrase an earlier email of yours), there will
> > undoubtedly be cases where cert validation will
> > fail....not because the cert has been revoked, but
> > because the response does not include a nonce.
> 
> Not necessarily.  Be up front about it.  Tell them you don't 
> support nonces.  Let them decide IAW local security policy 
> whether to fail path validation process.  Give them a clue.
> 
> > I believe that clients should have the ability to
> > make up their own mind (local policy) in determining
> > if they should reject or accept such a response.
> 
> But to make that decision, they must be able to differentiate 
> between a server/service that chooses not to support nonces 
> and one that is willing to but which service is being blocked 
> by an attacker.
> 
> > A MUST reject would not allow for this or force a
> > client to not be compliant with the spec.
> 
> Apologies in advance for being so blunt about this, but 
> Section 4.4.1 of RFC 2560 opens with the sentence "The nonce 
> cryptographically binds a request and a response to prevent 
> replay attacks."  I remain curious how disregard of a 
> client's nonce nonetheless achieves this intended effect.  I 
> further note that RFC 3546 (TLS) defers to this precise 
> section regarding nonces.
> 
> 
> 
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8FgDib080978 for <[e-mail]>; Mon, 8 Dec 2003 07:42:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8FgDEB080977 for ietf-pkix-bks; Mon, 8 Dec 2003 07:42:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8FgCib080941 for <[e-mail]>; Mon, 8 Dec 2003 07:42:12 -0800 (PST) (envelope-from [e-mail])
Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B622E61B96; Mon,  8 Dec 2003 16:42:10 +0100 (CET)
Date: Sun, 07 Dec 2003 23:51:59 -0800
From: Harald Tveit Alvestrand <[e-mail]>
To: Russ Housley <[e-mail]>, [e-mail], [e-mail]
Subject: Re: DN Encoding by UTF8String
Message-ID: <194813577.1070841119@localhost>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/3.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 must admit that I am not surprised.....

The encodings supported by older applications are many and various, but 
nearly all of them share one of two properties:

- They are US-ASCII compatible
- When using non-US-ASCII characters, they are violating the X.509 
standards that they claim conformance to

If declaring that a number of applications are violating the IETF 
standards, and not just the ITU standards, on January 1, 2004 will help 
bring that day closer, I'm all for it.

Sooner or later, the industry, IMHO, will have to embrace UTF-8 fully; 
supporting the mess we've created for ourselves forever is not in the best 
long term interest of the network.

As far as I know, there will be nobody coming to punish people issuing 
non-UTF-8 certificates after Jan 1, 2004 that contain non-UTF8 encoding. 
And people will violate the standards to keep their legacy applications 
running; that is how networks have always operated.

But IMHO, they should be ashamed of themselves when they do so, and strive 
towards eliminating the need for doing so as soon as possible. Not because 
I say so, but because it's for the long term good of the Internet.

My opinion.

                 Harald Alvestrand


--On 6. desember 2003 13:29 -0500 Russ Housley <[e-mail]> wrote:

> This was added to RFC 2459, and retained in RFC 3280, based on comments
> from Harald Alvestrand.   As most of the recipients know, Harald is the
> Chair of the IETF, and a member of the  IESG.  Tim Polk spent a lot of
> time on this issue, negotiating the exact words with Harald and any
> others.  The desire is for certificate issuers to embrace international
> character sets.
>
> Beyond this recap of the history, I will let Harald speak for himself.
>
> Russ
>
>
> ----------------------- Original Message -----------------------
> From:    Masaki SHIMAOKA <[e-mail]>
> To:      Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>,
> [e-mail], [e-mail], [e-mail]
> Date:    Fri, 05 Dec 2003 16:09:10 +0900
> Subject: DN Encoding by UTF8String
>
> Dear Authors and WG Chairs,
>
> RFC3280 mentioned that "all certificates issued after Dec 31, 2003 MUST
> use UTF8String encoding".
>
> However, it seems that some applications do not yet support UTF8String
> respectably and the detail of name comparison rule does not consider
> UTF8String sufficiently.
>
> Therefore, existing CAs using except UTF8String for DN encoding SHOULD
> do the following actions until solving these UTF8String problem.
>
>      An encoding for issuer field of the certificates issued after 2004
>      SHOULD be same as an encoding for subject field of CA certificate
>      already issued.
>
> Is this correct?
>
> Of course, when the UTF8String problem solves, all certificates
> issuedMUST use UTF8String encoding.
> I worry that some confused CAs issue wrong certificates using UTF8String
> encoding forcibly, even though the CA had used another encoding till now.
>
> Best regards,
> -----
> Masaki SHIMAOKA
>
> SECOM Trust.net
> System Engineering Dpt.
> Tel: [phone] (ext.3605)
> Fax: [phone]
> e-mail: [e-mail]
>
>
>






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8FT3ib079289 for <[e-mail]>; Mon, 8 Dec 2003 07:29:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8FT26l079288 for ietf-pkix-bks; Mon, 8 Dec 2003 07:29:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8FT1ib079276 for <[e-mail]>; Mon, 8 Dec 2003 07:29:02 -0800 (PST) (envelope-from [e-mail])
Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hB8FT0oO011730; Mon, 8 Dec 2003 10:29:00 -0500
From: "Carl Wallace" <[e-mail]>
To: "'David Engberg'" <[e-mail]>
Cc: "'Deacon, Alex'" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, <[e-mail]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Mon, 8 Dec 2003 10:28:55 -0500
Message-ID: <000701c3bda0$01491690$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB8FT2ib079282
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>

> From: David Engberg [mailto:[e-mail]] 
> Subject: Re: Cached OCSP responses vs. single entry CRLs
> 
> In terms of how an implementation produces and distributes 
> pre-generated OCSP responses, there are a large number of mechanisms to do
this 
> (pushing, pulling, rsync, fedex CD-ROMs, etc.).  None of these are 
> visible to the relying parties, so I don't think there needs 
> to be any mandatory implementation in an RFC.
> 

That it is not visible to relying parties does not necessarily remove a need
for standardization.  It's easy to see where non-standardization of the
means of replication would lock folks into a particular vendor's solution.
For what it's worth, I'm not lobbying for additional standardization efforts
in that area.  The point is that there exist today ample standards to deploy
a solution that is more or less functionally equivalent to "cached OCSP" or
"nonce not supported OCSP".




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8Ettib071581 for <[e-mail]>; Mon, 8 Dec 2003 06:55:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8Ettc1071580 for ietf-pkix-bks; Mon, 8 Dec 2003 06:55:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8Etsib071534 for <[e-mail]>; Mon, 8 Dec 2003 06:55:54 -0800 (PST) (envelope-from [e-mail])
Received: from corestreet.com (engberg.corestreet.com [192.168.2.87]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id hB8EtZxH029490; Mon, 8 Dec 2003 09:55:35 -0500
Message-ID: <[e-mail]>
Date: Mon, 08 Dec 2003 09:55:36 -0500
From: David Engberg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Carl Wallace <[e-mail]>
CC: "'Deacon, Alex'" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, [e-mail]
Subject: Re: Cached OCSP responses vs. single entry CRLs
References: <000e01c3bd90$b3a967f0$[e-mail]>
In-Reply-To: <000e01c3bd90$b3a967f0$[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>

"Cached OCSP" is just OCSP.  The standard defines the binary message 
formats between a client and some server, and includes specific language 
around pre-generation.  Any HTTP server that implements the protocol is 
OCSP.  There is an optional extension (nonce) in the protocol that a 
caching-only server will currently ignore, but this is also in 
compliance with the current spec (i.e. without the proposed MUST language).

There are dozens applications (like Netscape) that natively support 
OCSP, as well as a fair number of appliances (Cisco VPN) and devices 
(RIM Blackberry).  Implementing OCSP typically requires no change in the 
CA or certificate issuance.

In terms of how an implementation produces and distributes pre-generated 
OCSP responses, there are a large number of mechanisms to do this 
(pushing, pulling, rsync, fedex CD-ROMs, etc.).  None of these are 
visible to the relying parties, so I don't think there needs to be any 
mandatory implementation in an RFC.


Carl Wallace wrote:
> The responses regarding lack of client side support are somewhat strange.
> It is not possible that deployed client-side support for partitioned CRLs is
> less than deployed client-side support for the yet-to-be-defined solution
> for cached OCSP.  
> 
> On the other side of the transaction, what is the protocol used to populate
> the responders that serve pre-produced responses?  Is this something that
> would need to be standardized too?  There are already standards-based means
> of replicating directories.
> 
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8DdTib046103 for <[e-mail]>; Mon, 8 Dec 2003 05:39:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8DdTDw046102 for ietf-pkix-bks; Mon, 8 Dec 2003 05:39:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8DdSib046087 for <[e-mail]>; Mon, 8 Dec 2003 05:39:28 -0800 (PST) (envelope-from [e-mail])
Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hB8DdRoO025353; Mon, 8 Dec 2003 08:39:28 -0500
From: "Carl Wallace" <[e-mail]>
To: "'Deacon, Alex'" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, <[e-mail]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Mon, 8 Dec 2003 08:39:22 -0500
Message-ID: <000e01c3bd90$b3a967f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB8DdSib046098
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>

Response to following two comments below...

> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Deacon, Alex
> Sent: Friday, December 05, 2003 7:05 PM
> Subject: RE: Cached OCSP responses vs. single entry CRLs
> 
> We looked into this.  The problem is that client support for 
> "crl partitioning" (in this case a partition by individual 
> serial number) is just about non-existant. 
> 
> Alex
> 

> From: Ryan M. Hurst [mailto:[e-mail]] 
> Sent: Friday, December 05, 2003 6:30 PM
> Subject: RE: Cached OCSP responses vs. single entry CRLs
> 
> Carl there are a number of reasons, one of the most 
> significant being backwards compatibility; many existing 
> client implementations do not support partitioned CRLs and 
> there is not way to tell from a CDP if the data on the other 
> end represents a partitioned CRL or a full one.
> 
> Additionally there are commercial OCSP responders out there 
> that support this concept, yet very few CAs support the use 
> of portioned CRLs to that granularity.
> 
> Ryan

The responses regarding lack of client side support are somewhat strange.
It is not possible that deployed client-side support for partitioned CRLs is
less than deployed client-side support for the yet-to-be-defined solution
for cached OCSP.  

On the other side of the transaction, what is the protocol used to populate
the responders that serve pre-produced responses?  Is this something that
would need to be standardized too?  There are already standards-based means
of replicating directories.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB84K2ib068902 for <[e-mail]>; Sun, 7 Dec 2003 20:20:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB84K2qq068901 for ietf-pkix-bks; Sun, 7 Dec 2003 20:20:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB84K0ib068873 for <[e-mail]>; Sun, 7 Dec 2003 20:20:00 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 17146 invoked by uid 0); 8 Dec 2003 04:19:37 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (12.104.90.162) by woodstock.binhost.com with SMTP; 8 Dec 2003 04:19:37 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Sat, 06 Dec 2003 13:29:28 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: DN Encoding by UTF8String
Cc: [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>

This was added to RFC 2459, and retained in RFC 3280, based on comments 
from Harald Alvestrand.   As most of the recipients know, Harald is the 
Chair of the IETF, and a member of the  IESG.  Tim Polk spent a lot of time 
on this issue, negotiating the exact words with Harald and any others.  The 
desire is for certificate issuers to embrace international character sets.

Beyond this recap of the history, I will let Harald speak for himself.

Russ


----------------------- Original Message -----------------------
From:    Masaki SHIMAOKA <[e-mail]>
To:      Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>, 
[e-mail], [e-mail], [e-mail]
Date:    Fri, 05 Dec 2003 16:09:10 +0900
Subject: DN Encoding by UTF8String

Dear Authors and WG Chairs,

RFC3280 mentioned that "all certificates issued after Dec 31, 2003 MUST
use UTF8String encoding".

However, it seems that some applications do not yet support UTF8String
respectably and the detail of name comparison rule does not consider
UTF8String sufficiently.

Therefore, existing CAs using except UTF8String for DN encoding SHOULD
do the following actions until solving these UTF8String problem.

     An encoding for issuer field of the certificates issued after 2004
     SHOULD be same as an encoding for subject field of CA certificate
     already issued.

Is this correct?

Of course, when the UTF8String problem solves, all certificates
issuedMUST use UTF8String encoding.
I worry that some confused CAs issue wrong certificates using UTF8String
encoding forcibly, even though the CA had used another encoding till now.

Best regards,
-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB74iuib022504 for <[e-mail]>; Sat, 6 Dec 2003 20:44:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB74iuHC022503 for ietf-pkix-bks; Sat, 6 Dec 2003 20:44:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB74itib022498 for <[e-mail]>; Sat, 6 Dec 2003 20:44:55 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id C678B34078; Sun,  7 Dec 2003 17:44:34 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hB74isL23080; Sun, 7 Dec 2003 17:44:54 +1300
Date: Sun, 7 Dec 2003 17:44:54 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Certificate Policy Standardization
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>

"Hans Nilsson" <[e-mail]> writes:

>Very funny, as usual, Peter. However, let me just spoil your joke a bit.

It wasn't a joke (maybe you missed the recent discussion, in which case you
may want to check the list archives for earlier posts).  That was a
business/legal analysis of how to best use and apply cert policies.

>>The reason why this is approach is used is that if you changed your OID when
>>your policy changes, you'd have to re-issue all your certs, which no-one
>>wants to do.
>
>Why re-issue?? Old certs with old policy-OID are still fine and valid, but
>from now on the CA just issues new certs according to its new policy, with
>new OID.

No, I think you're confusing the cert with a rent-controlled apartment there.
The T&C for use don't continue to be whatever they were in 1949 when you first
got the thing, they change over time, appropriate cert use is defined by
whatever the T&C currently are, and the cert policy extension tells the user
where they can find the T&C online, just like any (non-cert-based)
alternative.  The intent of the legal analysis was to determine the
appropriate way to use the cert policy (from a business/legal perspective),
and that was to treat it as a standard T&C arrangement.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB73x7ib021094 for <[e-mail]>; Sat, 6 Dec 2003 19:59:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB73x7cv021093 for ietf-pkix-bks; Sat, 6 Dec 2003 19:59:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB73x7ib021087 for <[e-mail]>; Sat, 6 Dec 2003 19:59:07 -0800 (PST) (envelope-from [e-mail])
Received: from ambarisht40 (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id hB73wvOD001889; Sat, 6 Dec 2003 19:58:58 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Sat, 6 Dec 2003 19:57:52 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

Can we break this discussion up into two parts (and maybe even
have a couple of straw polls)?

1. When a server sees a nonce in a request, should the spec
require a server to include the nonce in the response or
return an error (as recommended by Russ) or should the spec
recommend the server include the nonce (as requested by Ryan,
Alex and David and maybe Florian).

2. Does there need to be a way of a server to indicate to a
client that it doesn't support nonces. If there does, I
assume everybody agrees that the way should be a secure
way.

Does this help clarify the issues?

Regards,
Ambarish

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Michael Myers
> Sent: Friday, December 05, 2003 10:47 AM
> To: Ryan M. Hurst; [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> 
> > From: Ryan M. Hurst
> > Sent: Friday, December 05, 2003 10:57 AM
> >
> > [rmh]As I said, I am willing to accept the
> > must reject if that means that others will
> > drop the idea of adding breaking changes to
> > the v1 protocol.
> 
> So now we've come full circle.  A plain MUST reject is where 
> we got started and which principle Russ affirmed in 
> Minneapolis. I'm curious what others think.
> 
> Mike
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB6MEqib010885 for <[e-mail]>; Sat, 6 Dec 2003 14:14:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB6MEqjB010883 for ietf-pkix-bks; Sat, 6 Dec 2003 14:14:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB6MElib010861 for <[e-mail]>; Sat, 6 Dec 2003 14:14:48 -0800 (PST) (envelope-from [e-mail])
Received: from fwd10.aul.t-online.de  by mailout09.sul.t-online.com with smtp  id 1ASkhM-00063V-06; Sat, 06 Dec 2003 23:14:48 +0100
Received: from hagen (TtP7YsZDQeGuyQzTOXJlj5u5+xVI5-V0XecSus6gDLM79h7KxH4sEq@[80.128.90.202]) by fmrl10.sul.t-online.com with esmtp id 1ASkh5-1sBzH60; Sat, 6 Dec 2003 23:14:31 +0100
From: "Florian Oelmaier" <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Sat, 6 Dec 2003 23:14:29 +0100
Organization: SyTrust
Message-ID: <00b501c3bc46$52009b90$4228a8c0@hagen>
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.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
X-Seen: false
X-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>

>  >     OCSPNonce ::= CHOICE {
>  >        nonceValue  OCTET STRING,
>  >        unsupported  NULL }
> 
> Another way may be 
> 
> nonceValue  OCTET STRING OPTIONAL -- unsupported if omitted. 
> 

Hehe. Nice one. Server-generated nonces :) I like that idea. Thats
exactly what CertControl does right now.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB61rRib082049 for <[e-mail]>; Fri, 5 Dec 2003 17:53:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB61rRuR082048 for ietf-pkix-bks; Fri, 5 Dec 2003 17:53:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB61rQib082041 for <[e-mail]>; Fri, 5 Dec 2003 17:53:26 -0800 (PST) (envelope-from [e-mail])
Received: from ambarisht40 (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id hB61rD2B026931; Fri, 5 Dec 2003 17:53:13 -0800
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>, "'David Engberg'" <[e-mail]>
Cc: "'Ryan M. Hurst'" <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 17:52:08 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <003501c3bb2d$65ca8740$e8a47ad5@LiaquatDELL>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

I agree completely with Liaquat.

Ambarish

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Liaquat Khan
> Sent: Friday, December 05, 2003 4:43 AM
> To: 'David Engberg'
> Cc: 'Ryan M. Hurst'; 'Florian Oelmaier'; [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> It's interesting what you say about "one-size-fits-all".  My 
> view is you have to look at things from the RPs point of 
> view, i.e. as a relying party, I only care what's best for 
> me.  Therefore either nonces are important to me or they are 
> not (I don't particularly care whether OCSP responder's 
> support them or not).  
> 
> Therefore from a RP perspective a single security policy is 
> probably want you do want.  Also from a security perspective, 
> you don't want to make special cases unless you think that 
> communication between that particular server is secure 
> against such threats and hence the protection is not required.  
> 
> I think it is sufficient to make OCSP clients configurable on 
> whether to include a nonce or not (since the protocol already 
> identifies it as an optional item) and then leave it up the 
> local administrator to define what suits them according to 
> their local security policy.  I should add though that if you 
> include a nonce in the request you MUST reject a response if 
> it doesn't include a nonce (or a correct one).  
> 
> Regards,
> LK
> 
> 
> -----Original Message-----
> From: David Engberg [mailto:[e-mail]] 
> Sent: 05 December 2003 12:15
> To: [e-mail]
> Cc: 'Ryan M. Hurst'; 'Florian Oelmaier'; [e-mail]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
> 
> 
> I agree that this is not a current problem that many people 
> are seeing, 
> because current OCSP use is primarily limited to small "internal" 
> deployments where a one-size-fits-all security policy isn't an issue. 
>  If I'm only ever hitting one OCSP responder, a "require 
> nonces from all
> 
> servers" policy may be fine.
> 
> On the other hand, when people start using OCSP for real-world 
> interoperability, the nonce-related options in all existing 
> clients will
> 
> likely be too limited.  For example, if ACME Amalgamated 
> installs CAPI 
> clients for its internal PKI users that are configured to "require 
> nonces from every server," this client will immediately act 
> up when apps
> 
> try to verify SSL certs from Verisign if Verisign were to deploy a 
> cache-based infrastructure.
> 
> Without a spec refinement to handle the broader interopability case, 
> most people will probably just turn off nonce support across 
> the board 
> rather than trying to reconcile their internal PKI with external ones 
> that they interoperate with.  Since I think nonces are 
> actually negative
> 
> for security on balance, I'm fine with this result, but I don't think 
> this is the desired goal of everyone involved.
> 
> 
> Liaquat Khan wrote:
> 
> >The situation "we would like to have nonces in OCSP requests as
> default,
> >but if the server legitimately doesn't support nonces we are 
> happy to 
> >forgo nonces or we will generate a fresh request without a nonce" is
> not
> >that common in my opinion.  If such a case does exist, local policy
> will
> >probably be also happy to choose to not include a nonce in the OCSP 
> >request message in the first place.
> >
> >  
> >
> 
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB61KHib080395 for <[e-mail]>; Fri, 5 Dec 2003 17:20:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB61KHvS080394 for ietf-pkix-bks; Fri, 5 Dec 2003 17:20:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB61KGib080389 for <[e-mail]>; Fri, 5 Dec 2003 17:20:16 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hB61KHA32336; Fri, 5 Dec 2003 18:20:17 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Deacon, Alex" <[e-mail]>, "Ryan M. Hurst" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 18:22:21 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE 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>

Alex,

Comments embedded below.

Mike

> -----Original Message-----
> From: Deacon, Alex [mailto:[e-mail]]
> Sent: Friday, December 05, 2003 4:59 PM
> To: 'Michael Myers'; Ryan M. Hurst; [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> If I could be ensured that every OCSP client used to
> hit ocsp.verisign.com would not include a nonce,
> then I would have no problem with a MUST reject.

Well, that probably won't happen in the given target
environment.  But what you can do is tell them they shouldn't
while still providing them the full value of your OCSP services.
Given a sufficiently reliable clue, they probably won't do so
again.

> However because this environment receives requests
> from a heterogeneous population of clients over
> which we have no administrative control (to
> paraphrase an earlier email of yours), there will
> undoubtedly be cases where cert validation will
> fail....not because the cert has been revoked, but
> because the response does not include a nonce.

Not necessarily.  Be up front about it.  Tell them you don't
support nonces.  Let them decide IAW local security policy
whether to fail path validation process.  Give them a clue.

> I believe that clients should have the ability to
> make up their own mind (local policy) in determining
> if they should reject or accept such a response.

But to make that decision, they must be able to differentiate
between a server/service that chooses not to support nonces and
one that is willing to but which service is being blocked by an
attacker.

> A MUST reject would not allow for this or force a
> client to not be compliant with the spec.

Apologies in advance for being so blunt about this, but Section
4.4.1 of RFC 2560 opens with the sentence "The nonce
cryptographically binds a request and a response to prevent
replay attacks."  I remain curious how disregard of a client's
nonce nonetheless achieves this intended effect.  I further note
that RFC 3546 (TLS) defers to this precise section regarding
nonces.







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB61Bpib079868 for <[e-mail]>; Fri, 5 Dec 2003 17:11:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB61BpLs079867 for ietf-pkix-bks; Fri, 5 Dec 2003 17:11:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB61Boib079858 for <[e-mail]>; Fri, 5 Dec 2003 17:11:50 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id CCCAF34003; Sat,  6 Dec 2003 14:11:32 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hB61Bqc09578; Sat, 6 Dec 2003 14:11:52 +1300
Date: Sat, 6 Dec 2003 14:11:52 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Cached OCSP responses vs. single entry CRLs
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>

"Carl Wallace" <[e-mail]> writes:

>Why use OCSP to convey pre-produced revocation information in the way that's
>being discussed?  Why not use single entry CRLs?  The functionality is
>similar and they could be propagated using existing technology (e.g.
>directories, 3280 compliant path processing clients, etc.).

Shhhh!!!  You're not supposed to ask that question.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB604jib077117 for <[e-mail]>; Fri, 5 Dec 2003 16:04:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB604jo8077116 for ietf-pkix-bks; Fri, 5 Dec 2003 16:04:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB604iib077111 for <[e-mail]>; Fri, 5 Dec 2003 16:04:44 -0800 (PST) (envelope-from [e-mail])
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.10/) with ESMTP id hB604kW5028037; Fri, 5 Dec 2003 16:04:46 -0800 (PST)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <XLQFJKZH>; Fri, 5 Dec 2003 16:04:46 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Carl Wallace'" <[e-mail]>, [e-mail]
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Fri, 5 Dec 2003 16:04:46 -0800 
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>

We looked into this.  The problem is that client support for "crl
partitioning" (in this case a partition by individual serial number) is just
about non-existant. 

Alex

> -----Original Message-----
> From: Carl Wallace [mailto:[e-mail]] 
> Sent: Friday, December 05, 2003 1:09 PM
> To: [e-mail]
> Subject: Cached OCSP responses vs. single entry CRLs
> 
> 
> 
> Why use OCSP to convey pre-produced revocation information in 
> the way that's being discussed?  Why not use single entry 
> CRLs?  The functionality is similar and they could be 
> propagated using existing technology (e.g. directories, 3280 
> compliant path processing clients, etc.).
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Nwlib076767 for <[e-mail]>; Fri, 5 Dec 2003 15:58:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5NwlXE076766 for ietf-pkix-bks; Fri, 5 Dec 2003 15:58:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Nwlib076761 for <[e-mail]>; Fri, 5 Dec 2003 15:58:47 -0800 (PST) (envelope-from [e-mail])
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.10/) with ESMTP id hB5NwmW5026810; Fri, 5 Dec 2003 15:58:48 -0800 (PST)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <XLQFJKQN>; Fri, 5 Dec 2003 15:58:48 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "Ryan M. Hurst" <[e-mail]>, [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 15:58:47 -0800 
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 I could be ensured that every OCSP client used to hit ocsp.verisign.com
would not include a nonce, then I would have no problem with a MUST reject.
However because this environment receives requests from a heterogeneous
population of clients over which we have no administrative control (to
paraphrase an earlier email of yours), there will undoubtedly be cases where
cert validation will fail....not because the cert has been revoked, but
because the response does not include a nonce.  

I believe that clients should have the ability to make up their own mind
(local policy) in determining if they should reject or accept such a
response.  A MUST reject would not allow for this or force a client to not
be compliant with the spec.

Alex



> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]] 
> Sent: Friday, December 05, 2003 10:47 AM
> To: Ryan M. Hurst; [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> 
> > From: Ryan M. Hurst
> > Sent: Friday, December 05, 2003 10:57 AM
> >
> > [rmh]As I said, I am willing to accept the
> > must reject if that means that others will
> > drop the idea of adding breaking changes to
> > the v1 protocol.
> 
> So now we've come full circle.  A plain MUST reject is where 
> we got started and which principle Russ affirmed in 
> Minneapolis. I'm curious what others think.
> 
> Mike
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Nk3ib076276 for <[e-mail]>; Fri, 5 Dec 2003 15:46:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5Nk3IB076275 for ietf-pkix-bks; Fri, 5 Dec 2003 15:46:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Nk2ib076269 for <[e-mail]>; Fri, 5 Dec 2003 15:46:02 -0800 (PST) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 5 Dec 2003 15:45:53 -0800
Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Dec 2003 15:30:41 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 15:29:51 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 15:29:23 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 5 Dec 2003 15:29:27 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Fri, 5 Dec 2003 15:30:21 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Cached OCSP responses vs. single entry CRLs
thread-index: AcO7hP1o5LzWA0tlTu2VJOU0Avl1CgAAjQfA
From: "Ryan M. Hurst" <[e-mail]>
To: "Carl Wallace" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 05 Dec 2003 23:29:27.0920 (UTC) FILETIME=[A0334700:01C3BB87]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB5Nk2ib076271
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>

Carl there are a number of reasons, one of the most significant being
backwards compatibility; many existing client implementations do not
support partitioned CRLs and there is not way to tell from a CDP if the
data on the other end represents a partitioned CRL or a full one.

Additionally there are commercial OCSP responders out there that support
this concept, yet very few CAs support the use of portioned CRLs to that
granularity.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Carl Wallace
Sent: Friday, December 05, 2003 1:09 PM
To: [e-mail]
Subject: Cached OCSP responses vs. single entry CRLs


Why use OCSP to convey pre-produced revocation information in the way
that's
being discussed?  Why not use single entry CRLs?  The functionality is
similar and they could be propagated using existing technology (e.g.
directories, 3280 compliant path processing clients, etc.).




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5MRMib072307 for <[e-mail]>; Fri, 5 Dec 2003 14:27:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5MRMiC072306 for ietf-pkix-bks; Fri, 5 Dec 2003 14:27:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5MRLib072279 for <[e-mail]>; Fri, 5 Dec 2003 14:27:21 -0800 (PST) (envelope-from [e-mail])
Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 14:27:23 -0800
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Fri, 5 Dec 2003 14:27:25 -0800
Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Dec 2003 14:27:17 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 14:26:34 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 14:29:04 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 5 Dec 2003 14:26:10 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 14:27:22 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS: MUST reject in OCSPv1
thread-index: AcO7cU1ZyzGswbJfTKS9vATs7lhOWwADUTJg
From: "Ryan M. Hurst" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "David Engberg" <[e-mail]>
Cc: <[e-mail]>, "Florian Oelmaier" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 05 Dec 2003 22:26:10.0408 (UTC) FILETIME=[C8B4EE80:01C3BB7E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB5MRLib072301
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>

Comments in-line

-----Original Message-----
From: Michael Myers [mailto:[e-mail]] 
Sent: Friday, December 05, 2003 12:52 PM
To: Ryan M. Hurst; David Engberg
Cc: [e-mail]; 'Florian Oelmaier'; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1

> From: Ryan M. Hurst
> Sent: Friday, December 05, 2003 12:25 PM
>
> [rmh] But what prevents the nonce unsupported
>       response from being replayed?



While a caveated response can be replayed, it bears with it
unambiguous signed proof that the client's request for
anti-replay would not have been successful in the first place.

[rmh] Once again why does this matter, isn't that what you get by
getting the nonceless response back?

This is substantially different from replay of a nonceless
response captured from a server able and willing to support
nonces, but also able and willing to support non-nonced requests
(hence the capture and replay).
[rmh] But an attacker could just replay a response without this value,
how can this be relied upon?

In the former case, the replay protection is not there to begin
with and the server/service is being forthright about that.  Any
lawyer will tell you, full disclosure is good thing, especially
in the case when one has no contracted relationship with a
relying party.
[rmh] But if no client decision is being made off of this data, why
include it? Why break existing implementations?

In the latter case, anti-replay *is* available but the client is
being blocked from it by an attacker.  This is not so good.

Mike






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5MQ7ib072217 for <[e-mail]>; Fri, 5 Dec 2003 14:26:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5MQ70K072216 for ietf-pkix-bks; Fri, 5 Dec 2003 14:26:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5MQ6ib072211 for <[e-mail]>; Fri, 5 Dec 2003 14:26:06 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hB5MQ6A21025; Fri, 5 Dec 2003 15:26:06 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Carl Wallace" <[e-mail]>, <[e-mail]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Fri, 5 Dec 2003 15:28:11 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <000c01c3bb74$053cb190$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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>

> From: Carl Wallace
> Sent: Friday, December 05, 2003 2:09 PM
>
> Why use OCSP to convey pre-produced revocation
> information in the way that's being discussed?
> Why not use single entry CRLs?  The functionality
> is similar and they could be propagated using
> existing  technology (e.g. directories, 3280
> compliant path processing clients, etc.)



Carl,

Funny you should mention that.  The utility of CRL-based
approaches to the needs addressed by OCSP were amply debated in
the I-D phase of OCSP's development, principally between myself
and Carlisle Adams.  The turning point came when that dialog
yielded the notion of nonces in OCSP.

Mike







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5MAnib071363 for <[e-mail]>; Fri, 5 Dec 2003 14:10:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5MAnaN071361 for ietf-pkix-bks; Fri, 5 Dec 2003 14:10:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5MAlib071349 for <[e-mail]>; Fri, 5 Dec 2003 14:10:47 -0800 (PST) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 14:10:43 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 5 Dec 2003 14:11:36 -0800
Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Dec 2003 14:10:42 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 14:10:47 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 14:12:29 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 5 Dec 2003 14:10:41 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 14:10:45 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS: MUST reject in OCSPv1
thread-index: AcO7apO+ardawLSWT0aM7XnqqbiYgQAEC3Kg
From: "Ryan M. Hurst" <[e-mail]>
To: "David Engberg" <[e-mail]>
Cc: <[e-mail]>, "Florian Oelmaier" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 05 Dec 2003 22:10:41.0806 (UTC) FILETIME=[9F3782E0:01C3BB7C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB5MAmib071356
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>

Comments in line

-----Original Message-----
From: David Engberg [mailto:[e-mail]] 
Sent: Friday, December 05, 2003 12:01 PM
To: Ryan M. Hurst
Cc: [e-mail]; 'Florian Oelmaier'; [e-mail]
Subject: Re: DISCUSS: MUST reject in OCSPv1


The value of 'nonceUnsupported' is to allow a client to distinguish 
between 'a' and 'b' securely if that client cares about the difference 
between the two.  Without this mechanism, the client cannot securely 
tell the difference.

It sounds like the argument is that no client will/should ever care 
about this distinction.  This is an argument about "business case" 
rather than technology/security.
[rmh] I suppose so, I just don't see what the client would do with this
distinction; that's not to say there isn't something useful to be done
with it I just don't see it right now.

I believe that it would be valuable for many clients to make this 
distinction.  It allows a local security policy that permits 
interoperabitliy with certs (e.g. SSL certs) from all sorts of 
environments (e.g. with AIA fields).  I'd say clients would use this to 
implement a "use the security model that the server chooses" policy. 
 Not every client or user would choose this policy, but I believe some 
clients would do so if permitted.
[rmh] Is that useful? How is that any different than saying don't
require nonces from this server?


The presence of a 'nonceSupported' extension doesn't just permit replay,

it encourages it (i.e. caching). The 'nonceSupported' extension may also

indicate that that server is not vulnerable to key compromise or DoS 
attacks, and a client may choose to use that securely-transmitted 
information in its decision making.
[rmh] I see what you're trying to get across here, but there may be
other reasons a responder may not be able to include a nonce; for
example as a mater of configuration it is possible that a responder
still has a key but for performance it still only issues pre-generated
responses. 


Ryan M. Hurst wrote:

> comments in-line
>
>
------------------------------------------------------------------------
> *From:* David Engberg
> *Sent:* Fri 12/5/2003 11:17 AM
> *To:* Ryan M. Hurst
> *Cc:* [e-mail]; 'Florian Oelmaier'; [e-mail]
> *Subject:* Re: DISCUSS: MUST reject in OCSPv1
>
>Unfortunately, I think the anwer to Ryan's specific question is no.  If

>you send a nonce and get back a response without that nonce under the 
>current spec, you know either:
>
>   a)  The server does not support nonces
>   b)  An attacker is replaying a recorded response from a 
>nonce-supporting server
>  
>
>[rmh] This is absolutley true, but in either of these cases if the
client is attempting to protect against replay he would reject responses
in both a and b. And in not he wanted the "replay" (eg he wants caching
wherever he can get it)
>
>I think there needs to be another flag in the response (e.g. 
>nonceUnsupported extension) to securely separate 'a' from 'b'.
>[rmh] But what prevents the nonce unsupported response from being
replayed?
>
>Ryan M. Hurst wrote:
>
>>   1.
>>       What the responder returns if it can not return a nonce
>>   2.
>>       What the client must do when it receives a response to a nonced
>>       request
>>
>...
>
>> My take on #1 is that I don't see why the client needs to know that, 
>> after all if the response to a nonced request does not contain the 
>> same nonce doesn't that mean the server was unable to produce a
nonced 
>> response?
>
>
>
>  
>





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5L99ib067933 for <[e-mail]>; Fri, 5 Dec 2003 13:09:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5L99SO067932 for ietf-pkix-bks; Fri, 5 Dec 2003 13:09:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5L96ib067925 for <[e-mail]>; Fri, 5 Dec 2003 13:09:08 -0800 (PST) (envelope-from [e-mail])
Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hB5L96oO017810 for <[e-mail]>; Fri, 5 Dec 2003 16:09:07 -0500
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Subject: Cached OCSP responses vs. single entry CRLs
Date: Fri, 5 Dec 2003 16:09:01 -0500
Message-ID: <000c01c3bb74$053cb190$[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, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

Why use OCSP to convey pre-produced revocation information in the way that's
being discussed?  Why not use single entry CRLs?  The functionality is
similar and they could be propagated using existing technology (e.g.
directories, 3280 compliant path processing clients, etc.).



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Knbib066290 for <[e-mail]>; Fri, 5 Dec 2003 12:49:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5Knb9i066289 for ietf-pkix-bks; Fri, 5 Dec 2003 12:49:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Knaib066281 for <[e-mail]>; Fri, 5 Dec 2003 12:49:36 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hB5KnUA14645; Fri, 5 Dec 2003 13:49:30 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Ryan M. Hurst" <[e-mail]>, "David Engberg" <[e-mail]>
Cc: <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 13:51:36 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <23D34CEE-B951-4416-81C5-751B16CED60D@mimectl>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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>

> From: Ryan M. Hurst
> Sent: Friday, December 05, 2003 12:25 PM
>
> [rmh] But what prevents the nonce unsupported
>       response from being replayed?



While a caveated response can be replayed, it bears with it
unambiguous signed proof that the client's request for
anti-replay would not have been successful in the first place.

This is substantially different from replay of a nonceless
response captured from a server able and willing to support
nonces, but also able and willing to support non-nonced requests
(hence the capture and replay).

In the former case, the replay protection is not there to begin
with and the server/service is being forthright about that.  Any
lawyer will tell you, full disclosure is good thing, especially
in the case when one has no contracted relationship with a
relying party.

In the latter case, anti-replay *is* available but the client is
being blocked from it by an attacker.  This is not so good.

Mike





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5KTtib064965 for <[e-mail]>; Fri, 5 Dec 2003 12:29:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5KTt0e064964 for ietf-pkix-bks; Fri, 5 Dec 2003 12:29:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5KTrib064959 for <[e-mail]>; Fri, 5 Dec 2003 12:29:54 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23766; Fri, 5 Dec 2003 15:29:40 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sha244-00.txt
Date: Fri, 05 Dec 2003 15:29:40 -0500
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		: A 224-bit One-way Hash Function: SHA-224
	Author(s)	: R. Housley
	Filename	: draft-ietf-pkix-sha244-00.txt
	Pages		: 6
	Date		: 2003-12-5
	
This document specifies a 224-bit one-way hash function, called
SHA-224.  A SHA-224 has value is simply the truncation of the SHA-256
hash value.  SHA-256 is the 256-bit one-way hash function specified
by the National Institute of Standards and Technology (NIST).

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-sha244-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-sha244-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5K1Wib063365 for <[e-mail]>; Fri, 5 Dec 2003 12:01:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5K1Wfe063364 for ietf-pkix-bks; Fri, 5 Dec 2003 12:01:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5K1Wib063358 for <[e-mail]>; Fri, 5 Dec 2003 12:01:32 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc12) with ESMTP id <2003120520011801400dnrene>; Fri, 5 Dec 2003 20:01:18 +0000
Received: from 167.sub-166-156-182.myvzw.com ([166.156.182.167] helo=corestreet.com) by localhost with asmtp (Exim 3.35 #1 (Debian)) id 1ASMAi-0000mM-00; Fri, 05 Dec 2003 15:03:29 -0500
Message-ID: <[e-mail]>
Date: Fri, 05 Dec 2003 15:01:28 -0500
From: David Engberg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Ryan M. Hurst" <[e-mail]>
CC: [e-mail], "'Florian Oelmaier'" <[e-mail]>, [e-mail]
Subject: Re: DISCUSS: MUST reject in OCSPv1
References: <[e-mail]>, <000c01c3bafc$ae734260$e8a47ad5@LiaquatDELL> <1BED1193-1DB5-4E45-8B2E-1B6FD2AFA617@mimectl>, <[e-mail]> <23D34CEE-B951-4416-81C5-751B16CED60D@mimectl>
In-Reply-To: <23D34CEE-B951-4416-81C5-751B16CED60D@mimectl>
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>

The value of 'nonceUnsupported' is to allow a client to distinguish 
between 'a' and 'b' securely if that client cares about the difference 
between the two.  Without this mechanism, the client cannot securely 
tell the difference.

It sounds like the argument is that no client will/should ever care 
about this distinction.  This is an argument about "business case" 
rather than technology/security.

I believe that it would be valuable for many clients to make this 
distinction.  It allows a local security policy that permits 
interoperabitliy with certs (e.g. SSL certs) from all sorts of 
environments (e.g. with AIA fields).  I'd say clients would use this to 
implement a "use the security model that the server chooses" policy. 
 Not every client or user would choose this policy, but I believe some 
clients would do so if permitted.

The presence of a 'nonceSupported' extension doesn't just permit replay, 
it encourages it (i.e. caching). The 'nonceSupported' extension may also 
indicate that that server is not vulnerable to key compromise or DoS 
attacks, and a client may choose to use that securely-transmitted 
information in its decision making.


Ryan M. Hurst wrote:

> comments in-line
>
> ------------------------------------------------------------------------
> *From:* David Engberg
> *Sent:* Fri 12/5/2003 11:17 AM
> *To:* Ryan M. Hurst
> *Cc:* [e-mail]; 'Florian Oelmaier'; [e-mail]
> *Subject:* Re: DISCUSS: MUST reject in OCSPv1
>
>Unfortunately, I think the anwer to Ryan's specific question is no.  If 
>you send a nonce and get back a response without that nonce under the 
>current spec, you know either:
>
>   a)  The server does not support nonces
>   b)  An attacker is replaying a recorded response from a 
>nonce-supporting server
>  
>
>[rmh] This is absolutley true, but in either of these cases if the client is attempting to protect against replay he would reject responses in both a and b. And in not he wanted the "replay" (eg he wants caching wherever he can get it)
>
>I think there needs to be another flag in the response (e.g. 
>nonceUnsupported extension) to securely separate 'a' from 'b'.
>[rmh] But what prevents the nonce unsupported response from being replayed?
>
>Ryan M. Hurst wrote:
>
>>   1.
>>       What the responder returns if it can not return a nonce
>>   2.
>>       What the client must do when it receives a response to a nonced
>>       request
>>
>...
>
>> My take on #1 is that I don't see why the client needs to know that, 
>> after all if the response to a nonced request does not contain the 
>> same nonce doesn't that mean the server was unable to produce a nonced 
>> response?
>
>
>
>  
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5JQuib060659 for <[e-mail]>; Fri, 5 Dec 2003 11:26:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5JQueV060658 for ietf-pkix-bks; Fri, 5 Dec 2003 11:26:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5JQtib060645 for <[e-mail]>; Fri, 5 Dec 2003 11:26:55 -0800 (PST) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 11:26:54 -0800
Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Dec 2003 11:26:51 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 11:23:11 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 11:26:47 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 5 Dec 2003 11:26:49 -0800
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.150 157.54.0.150 via HTTP with MS-WebStorage 6.5.7122
Received: 157.54.0.150 157.54.0.150 from 157.54.1.70 157.54.1.70 via HTTP with MS-WebStorage 6.5.7122
MIME-Version: 1.0
Subject: RE: DISCUSS: MUST reject in OCSPv1
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>, <000c01c3bafc$ae734260$e8a47ad5@LiaquatDELL> <1BED1193-1DB5-4E45-8B2E-1B6FD2AFA617@mimectl>, <[e-mail]>
To: David Engberg <[e-mail]>
Cc: <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: DISCUSS: MUST reject in OCSPv1
Thread-Index: AcO7ZXRvCeXhVpn0TyqjvzhxfkhO+w==
Message-ID: <23D34CEE-B951-4416-81C5-751B16CED60D@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.7122.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.7122.0
Date: Fri, 5 Dec 2003 11:24:51 -0800
X-OriginalArrivalTime: 05 Dec 2003 19:26:49.0228 (UTC) FILETIME=[BA8B2CC0:01C3BB65]
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>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_D7C207C0-CE9F-4DAF-9159-B5884580B364_"

--_D7C207C0-CE9F-4DAF-9159-B5884580B364_
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

comments in-line



From: David Engberg
Sent: Fri 12/5/2003 11:17 AM
To: Ryan M. Hurst
Cc: [e-mail]; 'Florian Oelmaier'; [e-mail]
Subject: Re: DISCUSS: MUST reject in OCSPv1


Unfortunately, I think the anwer to Ryan's specific question is no.  If=20
you send a nonce and get back a response without that nonce under the=20
current spec, you know either:

   a)  The server does not support nonces
   b)  An attacker is replaying a recorded response from a=20
nonce-supporting server

[rmh] This is absolutley true, but in either of these cases if the client i=
s attempting to protect against replay he would reject responses in both a =
and b. And in not he wanted the "replay" (eg he wants caching wherever he c=
an get it)
I think there needs to be another flag in the response (e.g.=20
nonceUnsupported extension) to securely separate 'a' from 'b'.
[rmh] But what prevents the nonce unsupported response from being replayed?

Ryan M. Hurst wrote:

>   1.
>       What the responder returns if it can not return a nonce
>   2.
>       What the client must do when it receives a response to a nonced
>       request
>
...

> My take on #1 is that I don't see why the client needs to know that,=20
> after all if the response to a nonced request does not contain the=20
> same nonce doesn't that mean the server was unable to produce a nonced=20
> response?

--_D7C207C0-CE9F-4DAF-9159-B5884580B364_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText63919 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>comments in-line=
</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> David Engberg<BR><B>Sent:</B> Fri=
 12/5/2003 11:17 AM<BR><B>To:</B> Ryan M. Hurst<BR><B>Cc:</B> liaquat.khan@=
ascertia.com; 'Florian Oelmaier'; [e-mail]<BR><B>Subject:</B> Re: =
DISCUSS: MUST reject in OCSPv1<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">Unfortunately, I think the anwer =
to Ryan's specific question is no.  If=20
you send a nonce and get back a response without that nonce under the=20
current spec, you know either:

   a)  The server does not support nonces
   b)  An attacker is replaying a recorded response from a=20
nonce-supporting server
</PRE><PRE style=3D"WORD-WRAP: break-word">[rmh] This is absolutley true, b=
ut in either of these cases if the client is attempting to protect against =
replay he would reject responses in both a and b. And in not he wanted the =
"replay" (eg he wants caching wherever he can get it)</PRE><PRE style=3D"WO=
RD-WRAP: break-word">I think there needs to be another flag in the response=
 (e.g.=20
nonceUnsupported extension) to securely separate 'a' from 'b'.
[rmh] But what prevents the nonce unsupported response from being replayed?

Ryan M. Hurst wrote:

&gt;   1.
&gt;       What the responder returns if it can not return a nonce
&gt;   2.
&gt;       What the client must do when it receives a response to a nonced
&gt;       request
&gt;
...

&gt; My take on #1 is that I don't see why the client needs to know that,=20
&gt; after all if the response to a nonced request does not contain the=20
&gt; same nonce doesn't that mean the server was unable to produce a nonced=
=20
&gt; response?



</PRE></DIV></BODY></HTML>

--_D7C207C0-CE9F-4DAF-9159-B5884580B364_--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5JHZib059843 for <[e-mail]>; Fri, 5 Dec 2003 11:17:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5JHZNG059842 for ietf-pkix-bks; Fri, 5 Dec 2003 11:17:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5JHZib059836 for <[e-mail]>; Fri, 5 Dec 2003 11:17:35 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc11) with ESMTP id <2003120519173101300muinve>; Fri, 5 Dec 2003 19:17:31 +0000
Received: from 30.sub-166-156-165.myvzw.com ([166.156.165.30] helo=corestreet.com) by localhost with asmtp (Exim 3.35 #1 (Debian)) id 1ASLUP-0000ln-00; Fri, 05 Dec 2003 14:19:46 -0500
Message-ID: <[e-mail]>
Date: Fri, 05 Dec 2003 14:17:46 -0500
From: David Engberg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Ryan M. Hurst" <[e-mail]>
CC: [e-mail], "'Florian Oelmaier'" <[e-mail]>, [e-mail]
Subject: Re: DISCUSS: MUST reject in OCSPv1
References: <[e-mail]>, <000c01c3bafc$ae734260$e8a47ad5@LiaquatDELL> <1BED1193-1DB5-4E45-8B2E-1B6FD2AFA617@mimectl>
In-Reply-To: <1BED1193-1DB5-4E45-8B2E-1B6FD2AFA617@mimectl>
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>

Unfortunately, I think the anwer to Ryan's specific question is no.  If 
you send a nonce and get back a response without that nonce under the 
current spec, you know either:

   a)  The server does not support nonces
   b)  An attacker is replaying a recorded response from a 
nonce-supporting server

I think there needs to be another flag in the response (e.g. 
nonceUnsupported extension) to securely separate 'a' from 'b'.


Ryan M. Hurst wrote:

>   1.
>       What the responder returns if it can not return a nonce
>   2.
>       What the client must do when it receives a response to a nonced
>       request
>
...

> My take on #1 is that I don't see why the client needs to know that, 
> after all if the response to a nonced request does not contain the 
> same nonce doesn't that mean the server was unable to produce a nonced 
> response?





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5JFBib059687 for <[e-mail]>; Fri, 5 Dec 2003 11:15:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5JFBNk059686 for ietf-pkix-bks; Fri, 5 Dec 2003 11:15:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5JF9ib059679 for <[e-mail]>; Fri, 5 Dec 2003 11:15:09 -0800 (PST) (envelope-from [e-mail])
Received: from dial81-135-74-253.in-addr.btopenworld.com ([81.135.74.253] helo=LiaquatDELL) by rhenium.btinternet.com with esmtp (Exim 3.22 #25) id 1ASLPq-0001fa-00; Fri, 05 Dec 2003 19:15:02 +0000
Reply-To: <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, "'David Engberg'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 19:14:51 -0000
Message-ID: <003201c3bb64$130dc8a0$fd4a8751@LiaquatDELL>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C3BB64.130DC8A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <1BED1193-1DB5-4E45-8B2E-1B6FD2AFA617@mimectl>
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_0033_01C3BB64.130DC8A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

See my comments inline.  
 
Regards,
LK
 
-----Original Message-----
From: Ryan M. Hurst [mailto:[e-mail]] 
Sent: 05 December 2003 17:16
To: [e-mail]; 'Florian Oelmaier'; 'David Engberg';
[e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
 
Liaquat - I don't think there is any disagreement on weather it is up to
the client or not on including the nonce, there is however disagreement
on:
1.     What the responder returns if it can not return a nonce
2.     What the client must do when it receives a response to a nonced
request
For #1 my stance has been that the server should always return a
authoritative response.
 
LK: I agree (precisely for the reason you give for #2, i.e. this replay
protection was requested by the client, so let the client decide whether
or not it wants to go ahead and accept a nonce-less response.  Our ARP
client will currently reject such nonce-less responses, if it included a
nonce in the outgoing message.)  
 
For #2 my stance has been that just like the decision to include the
nonce in the first place its up to the client to decide what to do with
it when he gets it back, and that clients wanting replay protection
SHOULD reject responses that do not contain the nonce from their
request.
 
That being said others believe:
 
For #1 that the server needs to return a special response indicating it
is not capable of supporting nonces
 
For #2 that the client has no choice on what to do with the nonce in the
response if he included a nonce in the request.
 
My take on #1 is that I don't see why the client needs to know that,
after all if the response to a nonced request does not contain the same
nonce doesn't that mean the server was unable to produce a nonced
response? 
 
LK: I assume the others believe that if you can indicate in a special
way that a nonce-less response is still "trustworthy".i.e. the only
reason it doesn't contain a nonce is because it's coming from a keyless
responder otherwise it's trustworthy.   Rather than a normal nonce-less
response which may be coming from a keyless responder or may be a
replay!  Assuming my understanding is correct, I still think this is
unnecessary complication.   Even in this case the final decision will
still remain with the client on what to do next.i.e. the client may
accept the response or reject it depending on local policy..so what are
you gaining??
 
Changing the protocol by adjusting the ASN.1 of the nonce, adding a new
extension or error code, or adding special semantics to the value of the
nonce will break the existing implementations out there and its not
clear to me why this is needed (especialy in v1).
 
My take on #2 is that its a matter of policy of the client to the
client, but if accepting the MUST reject text here gets us out of #1
which will break clients I will accept it.
 
Ryan 
 
  _____  

From: Liaquat Khan
Sent: Thu 12/4/2003 10:54 PM
To: 'Ryan M. Hurst'; 'Florian Oelmaier'; 'David Engberg';
[e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
Ryan,
 
We also agree with your viewpoint, particular the point about a nonce
being a matter for local client policy.  
 
In the various OCSP clients we have, the option of whether to include
nonce or not in the request message is left to local policy (i.e. the
administrator can configure whether or not nonce is included in the
request message). 
 
If the administrator decides nonces are necessary (to prevent replays)
then he/she will select these and our OCSP clients will include these in
the requests.  Now if an OCSP response is received back without a nonce
it will be rejected by our OCSP clients.
 
On the other hand, if the administrator feels nonces are not required
(to allow for cached responses) then he/she will not select to include
one in outgoing responses. 
 
The situation "we would like to have nonces in OCSP requests as default,
but if the server legitimately doesn't support nonces we are happy to
forgo nonces or we will generate a fresh request without a nonce" is not
that common in my opinion.  If such a case does exist, local policy will
probably be also happy to choose to not include a nonce in the OCSP
request message in the first place.
 
Regards,
Liaquat
 
Ascertia Limited, Orchard Building, Royal Holloway, Egham, Surrey, TW20
OEX
tel: [phone], fax: [phone], mobile: [phone]
308766
website: www.ascertia.com
 
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
 
 
I am concerned with the idea of making any change to the standard that
"changes the 5 year old protocol".
 
This is particularly true since I don't see anyone on the list saying
this NonceUnsupported is needed, just that they would accept it.
 
I still think what is done with the nonce is a matter of local (client)
policy, and that if replay protection is desired responses not
containing the requested nonce MUST be rejected.
 
But since I appear to be odd man out on this, I would rather see us fall
back to Russ's original recommendation of MUST reject than break a 5
year old standard. 
 
Ryan
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
 
 
 
> I like the elegance of Russ and Florian's ideas for securely
signalling 
> that a server doesn't support nonces by using a special value for the 
> nonce in replies.  This seems like the "right" place to put this
message 
> to the client.
 
Just for the record: I think you are referring to our server-generated
nonces when you talk about "Florian's idea". And while Russel is
signalling "NonceUnsupported" with a special nonce-value, we are
singalling "NonceSupported" with the inclusion of a nonce into every
request (mirrored from the request or server-generated). Thus we are not
subject to the attack you mention, as this does not need any additional
code in any existing client.
 
Russ proposal is a change in the protocol. Thus we need to update all
the clients and servers out there. Seeing that the proposed change is
needed and recognizing it as a good solution, I would accept this. 
 
-- 
Florian Oelmaier
SyTrust
 
 
 
 

------=_NextPart_000_0033_01C3BB64.130DC8A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C3BB64.0E79C190">
<link rel=3DEdit-Time-Data href=3D"cid:editdata.mso@01C3BB64.0E79C190">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:1627421319 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:613288137;
	mso-list-template-ids:-2079034812;}
@list l0:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>See my comments inline.<span
style=3D'mso-spacerun:yes'>&nbsp; </span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>LK<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Ryan M. Hurst
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 05 December 2003 =
17:16<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[e-mail];
'Florian Oelmaier'; 'David Engberg'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: DISCUSS: =
MUST reject
in OCSPv1</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div id=3DidOWAReplyText48938>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Liaquat
- I don't think there is any disagreement on weather it is up to the =
client or
not on including the nonce, there is however disagreement =
on:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2;tab-stops:list 72.0pt'><![if !supportLists]><font
size=3D3 color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
color:navy'><span style=3D'mso-list:Ignore'>1.<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>What the
responder returns if it can not return a nonce</span></font><font =
color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2;tab-stops:list 72.0pt'><![if !supportLists]><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><span
style=3D'mso-list:Ignore'>2.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>What the
client must do when it receives a response to a nonced =
request</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>For #1 my stance has been =
that the
server should always return a authoritative =
response.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>LK: I agree (precisely for the =
reason you
give for #2, i.e. this replay protection was requested by the client, so =
let
the client decide whether or not it wants to go ahead and accept a =
nonce-less
response.<span style=3D'mso-spacerun:yes'>&nbsp; </span>Our ARP client =
will
currently reject such nonce-less responses, if it included a nonce in =
the
outgoing message.)<span style=3D'mso-spacerun:yes'>&nbsp; =
</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>For #2 my stance has been =
that just
like the decision to include the nonce in the first place its up to the =
client
to decide what to do with it when he gets it back, and that clients =
wanting
replay protection SHOULD reject responses that do not contain the nonce =
from
their request.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>That being said others =
believe:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>For #1 that the server =
needs to
return a special response indicating it is not capable of supporting =
nonces</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>For #2 that the client has =
no choice
on what to do with the nonce in the response if he included a nonce in =
the
request.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>My take on #1 is that I =
don't see
why the client needs to know that, after all if the response to a nonced
request does not contain the same nonce doesn't that mean the server was =
unable
to produce a nonced response? <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>LK: I assume the others believe =
that if
you can indicate in a special way that a nonce-less response is still
&#8220;trustworthy&#8221;&#8230;i.e. the only reason it doesn&#8217;t =
contain a
nonce is because it&#8217;s coming from a keyless responder otherwise
it&#8217;s trustworthy.<span style=3D'mso-spacerun:yes'>&nbsp;&nbsp;
</span>Rather than a normal nonce-less response which may be coming from =
a
keyless responder or may be a replay!<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>Assuming my understanding is correct, I still think this is =
unnecessary
complication.<span style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>Even =
in this
case the final decision will still remain with the client on what to do
next&#8230;i.e. the client may accept the response or reject it =
depending on
local policy&#8230;.so what are you =
gaining??<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Changing the protocol by =
adjusting
the ASN.1 of the nonce, adding a new extension or error code, or adding =
special
semantics to the value of the nonce will break the existing =
implementations out
there and its not clear to me why this is needed (especialy in =
v1).<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>My take on #2 is that its a =
matter
of policy of the client to the client, but if accepting the MUST reject
text&nbsp;here gets us out of #1&nbsp;which will break clients I will =
accept
it.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Ryan</span></font>&nbsp;<o:p=
></o:p></p>

</div>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div style=3D'margin-left:36.0pt'>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D3 width=3D"100%" align=3Dcenter>

</span></font></div>

</div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:
12.0pt;margin-left:36.0pt'><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> Liaquat
Khan<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thu 12/4/2003 10:54 =
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Ryan M. Hurst'; =
'Florian
Oelmaier'; 'David Engberg'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: DISCUSS: =
MUST reject
in OCSPv1</span></font><o:p></o:p></p>

</div>

<div><pre style=3D'margin-left:36.0pt;WORD-WRAP: break-word'><font =
size=3D2
face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Ryan,<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>We also agree with your viewpoint, particular =
the point about a nonce<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>being a matter for local client policy.<span =
style=3D'mso-spacerun:yes'>&nbsp; =
</span><o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>In the various OCSP clients we have, the =
option of whether to include<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>nonce or not in the request message is left =
to local policy (i.e. the<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>administrator can configure whether or not =
nonce is included in the<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>request message). =
<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>If the administrator decides nonces are =
necessary (to prevent replays)<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>then he/she will select these and our OCSP =
clients will include these in<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>the requests.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>Now if an OCSP response is =
received back without a nonce<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>it will be rejected by our OCSP =
clients.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>On the other hand, if the administrator feels =
nonces are not required<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>(to allow for cached responses) then he/she =
will not select to include<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>one in outgoing responses. =
<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>The situation &quot;we would like to have =
nonces in OCSP requests as default,<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>but if the server legitimately doesn't =
support nonces we are happy to<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>forgo nonces or we will generate a fresh =
request without a nonce&quot; is not<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>that common in my opinion.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>If such a case does exist, =
local policy will<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>probably be also happy to choose to not =
include a nonce in the OCSP<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>request message in the first =
place.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Regards,<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Liaquat<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Ascertia Limited, Orchard Building, Royal =
Holloway, Egham, Surrey, TW20<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>OEX<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>tel: [phone], fax: [phone] =
497301, mobile: [phone]<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>308766<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>website: =
www.ascertia.com<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>-----Original =
Message-----<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>From: [e-mail] =
[mailto:[e-mail]]<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>On Behalf Of Ryan M. =
Hurst<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Sent: 05 December 2003 =
01:41<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>To: Florian Oelmaier; David Engberg; =
[e-mail]<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Subject: RE: DISCUSS: MUST reject in =
OCSPv1<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>I am concerned with the idea of making any =
change to the standard that<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&quot;changes the 5 year old =
protocol&quot;.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>This is particularly true since I don't see =
anyone on the list saying<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>this NonceUnsupported is needed, just that =
they would accept it.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>I still think what is done with the nonce is =
a matter of local (client)<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>policy, and that if replay protection is =
desired responses not<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>containing the requested nonce MUST be =
rejected.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>But since I appear to be odd man out on this, =
I would rather see us fall<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>back to Russ's original recommendation of =
MUST reject than break a 5<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>year old standard. =
<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Ryan<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>-----Original =
Message-----<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>From: [e-mail] =
[mailto:[e-mail]]<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>On Behalf Of Florian =
Oelmaier<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Sent: Thursday, December 04, 2003 1:47 =
AM<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>To: David Engberg; =
[e-mail]<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Subject: RE: DISCUSS: MUST reject in =
OCSPv1<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&gt; I like the elegance of Russ and =
Florian's ideas for securely<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>signalling =
<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&gt; that a server doesn't support nonces by =
using a special value for the <o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&gt; nonce in replies.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>This seems like the =
&quot;right&quot; place to put this<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>message <o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&gt; to the =
client.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Just for the record: I think you are =
referring to our server-generated<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>nonces when you talk about &quot;Florian's =
idea&quot;. And while Russel is<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>signalling &quot;NonceUnsupported&quot; with =
a special nonce-value, we are<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>singalling &quot;NonceSupported&quot; with =
the inclusion of a nonce into every<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>request (mirrored from the request or =
server-generated). Thus we are not<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>subject to the attack you mention, as this =
does not need any additional<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>code in any existing =
client.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Russ proposal is a change in the protocol. =
Thus we need to update all<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>the clients and servers out there. Seeing =
that the proposed change is<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>needed and recognizing it as a good solution, =
I would accept this. <o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>-- <o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Florian =
Oelmaier<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>SyTrust<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre></div>

</div>

</body>

</html>

------=_NextPart_000_0033_01C3BB64.130DC8A0--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5JETib059656 for <[e-mail]>; Fri, 5 Dec 2003 11:14:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5JET9h059655 for ietf-pkix-bks; Fri, 5 Dec 2003 11:14:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5JEIib059629 for <[e-mail]>; Fri, 5 Dec 2003 11:14:28 -0800 (PST) (envelope-from [e-mail])
Received: from dial81-135-74-253.in-addr.btopenworld.com ([81.135.74.253] helo=LiaquatDELL) by rhenium.btinternet.com with esmtp (Exim 3.22 #25) id 1ASLOr-0001Ti-00; Fri, 05 Dec 2003 19:14:01 +0000
Reply-To: <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, "'David Engberg'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 19:13:40 -0000
Message-ID: <002601c3bb63$eeaa9920$fd4a8751@LiaquatDELL>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C3BB63.EEAA9920"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <1BED1193-1DB5-4E45-8B2E-1B6FD2AFA617@mimectl>
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_0027_01C3BB63.EEAA9920
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

See my comments inline.  
 
Regards,
LK
 
-----Original Message-----
From: Ryan M. Hurst [mailto:[e-mail]] 
Sent: 05 December 2003 17:16
To: [e-mail]; 'Florian Oelmaier'; 'David Engberg';
[e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
 
Liaquat - I don't think there is any disagreement on weather it is up to
the client or not on including the nonce, there is however disagreement
on:
1.     What the responder returns if it can not return a nonce
2.     What the client must do when it receives a response to a nonced
request
For #1 my stance has been that the server should always return a
authoritative response.
 
LK: I agree (precisely for the reason you give for #2, i.e. this replay
protection was requested by the client, so let the client decide whether
or not it wants to go ahead and accept a nonce-less response.  Our ARP
client will currently reject such nonce-less responses, if it included a
nonce in the outgoing message.)  
 
For #2 my stance has been that just like the decision to include the
nonce in the first place its up to the client to decide what to do with
it when he gets it back, and that clients wanting replay protection
SHOULD reject responses that do not contain the nonce from their
request.
 
That being said others believe:
 
For #1 that the server needs to return a special response indicating it
is not capable of supporting nonces
 
For #2 that the client has no choice on what to do with the nonce in the
response if he included a nonce in the request.
 
My take on #1 is that I don't see why the client needs to know that,
after all if the response to a nonced request does not contain the same
nonce doesn't that mean the server was unable to produce a nonced
response? 
 
LK: I assume the others believe that if you can indicate in a special
way that a nonce-less response is still "trustworthy".i.e. the only
reason it doesn't contain a nonce is because it's coming from a keyless
responder otherwise it's trustworthy.   Rather than a normal nonce-less
response which may be coming from a keyless responder or may be a
replay!  Assuming my understanding is correct, I still think this is
unnecessary complication.   Even in this case the final decision will
still remain with the client on what to do next.i.e. the client may
accept the response or reject it depending on local policy..so what are
you gaining??
 
Changing the protocol by adjusting the ASN.1 of the nonce, adding a new
extension or error code, or adding special semantics to the value of the
nonce will break the existing implementations out there and its not
clear to me why this is needed (especialy in v1).
 
My take on #2 is that its a matter of policy of the client to the
client, but if accepting the MUST reject text here gets us out of #1
which will break clients I will accept it.
 
Ryan 
 
  _____  

From: Liaquat Khan
Sent: Thu 12/4/2003 10:54 PM
To: 'Ryan M. Hurst'; 'Florian Oelmaier'; 'David Engberg';
[e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
Ryan,
 
We also agree with your viewpoint, particular the point about a nonce
being a matter for local client policy.  
 
In the various OCSP clients we have, the option of whether to include
nonce or not in the request message is left to local policy (i.e. the
administrator can configure whether or not nonce is included in the
request message). 
 
If the administrator decides nonces are necessary (to prevent replays)
then he/she will select these and our OCSP clients will include these in
the requests.  Now if an OCSP response is received back without a nonce
it will be rejected by our OCSP clients.
 
On the other hand, if the administrator feels nonces are not required
(to allow for cached responses) then he/she will not select to include
one in outgoing responses. 
 
The situation "we would like to have nonces in OCSP requests as default,
but if the server legitimately doesn't support nonces we are happy to
forgo nonces or we will generate a fresh request without a nonce" is not
that common in my opinion.  If such a case does exist, local policy will
probably be also happy to choose to not include a nonce in the OCSP
request message in the first place.
 
Regards,
Liaquat
 
Ascertia Limited, Orchard Building, Royal Holloway, Egham, Surrey, TW20
OEX
tel: [phone], fax: [phone], mobile: [phone]
308766
website: www.ascertia.com
 
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
 
 
I am concerned with the idea of making any change to the standard that
"changes the 5 year old protocol".
 
This is particularly true since I don't see anyone on the list saying
this NonceUnsupported is needed, just that they would accept it.
 
I still think what is done with the nonce is a matter of local (client)
policy, and that if replay protection is desired responses not
containing the requested nonce MUST be rejected.
 
But since I appear to be odd man out on this, I would rather see us fall
back to Russ's original recommendation of MUST reject than break a 5
year old standard. 
 
Ryan
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
 
 
 
> I like the elegance of Russ and Florian's ideas for securely
signalling 
> that a server doesn't support nonces by using a special value for the 
> nonce in replies.  This seems like the "right" place to put this
message 
> to the client.
 
Just for the record: I think you are referring to our server-generated
nonces when you talk about "Florian's idea". And while Russel is
signalling "NonceUnsupported" with a special nonce-value, we are
singalling "NonceSupported" with the inclusion of a nonce into every
request (mirrored from the request or server-generated). Thus we are not
subject to the attack you mention, as this does not need any additional
code in any existing client.
 
Russ proposal is a change in the protocol. Thus we need to update all
the clients and servers out there. Seeing that the proposed change is
needed and recognizing it as a good solution, I would accept this. 
 
-- 
Florian Oelmaier
SyTrust
 
 
 
 

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C3BB63.E3CD8800">
<link rel=3DEdit-Time-Data href=3D"cid:editdata.mso@01C3BB63.E3CD8800">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"time"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"date"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:1627421319 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:613288137;
	mso-list-template-ids:-2079034812;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>See my comments inline.<span
style=3D'mso-spacerun:yes'>&nbsp; </span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>LK<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Ryan M. Hurst
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><st1:date
Month=3D"12" Day=3D"5" Year=3D"2003"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
 10.0pt;font-family:Tahoma'>05 December =
2003</span></font></st1:date><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><st1:time
Hour=3D"17" Minute=3D"16"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
 font-family:Tahoma'>17:16</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[e-mail];
'Florian Oelmaier'; 'David Engberg'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: DISCUSS: =
MUST reject
in OCSPv1</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div id=3DidOWAReplyText48938>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Liaquat
- I don't think there is any disagreement on weather it is up to the =
client or
not on including the nonce, there is however disagreement =
on:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo1;tab-stops:list 72.0pt'><![if !supportLists]><font
size=3D3 color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
color:navy'><span style=3D'mso-list:Ignore'>1.<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>What the
responder returns if it can not return a nonce</span></font><font =
color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo1;tab-stops:list 72.0pt'><![if !supportLists]><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><span
style=3D'mso-list:Ignore'>2.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>What the
client must do when it receives a response to a nonced =
request</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>For #1 my stance has been =
that the
server should always return a authoritative =
response.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>LK: I agree (precisely for the =
reason you
give for #2, i.e. this replay protection was requested by the client, so =
let
the client decide whether or not it wants to go ahead and accept a =
nonce-less
response.<span style=3D'mso-spacerun:yes'>&nbsp; </span>Our ARP client =
will
currently reject such nonce-less responses, if it included a nonce in =
the
outgoing message.) <span =
style=3D'mso-spacerun:yes'>&nbsp;</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>For #2 my stance has been =
that just
like the decision to include the nonce in the first place its up to the =
client
to decide what to do with it when he gets it back, and that clients =
wanting
replay protection SHOULD reject responses that do not contain the nonce =
from
their request.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>That being said others =
believe:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>For #1 that the server =
needs to
return a special response indicating it is not capable of supporting =
nonces</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>For #2 that the client has =
no choice
on what to do with the nonce in the response if he included a nonce in =
the
request.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>My take on #1 is that I =
don't see
why the client needs to know that, after all if the response to a nonced
request does not contain the same nonce doesn't that mean the server was =
unable
to produce a nonced response? <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>LK: I assume the others believe =
that if
you can indicate in a special way that a nonce-less response is still =
&#8220;trustworthy&#8221;&#8230;i.e.
the only reason it doesn&#8217;t contain a nonce is because it&#8217;s =
coming
from a keyless responder otherwise it&#8217;s trustworthy.<span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>Rather than a normal =
nonce-less
response which may be coming from a keyless responder or may be a =
replay!<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Assuming my understanding is =
correct, I
still think this is unnecessary complication. <span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;</span>Even in this case the =
final
decision will still remain with the client on what to do next&#8230;i.e. =
the
client may accept the response or reject it depending on local =
policy&#8230;.so
what are you gaining??<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Changing the protocol by =
adjusting
the ASN.1 of the nonce, adding a new extension or error code, or adding =
special
semantics to the value of the nonce will break the existing =
implementations out
there and its not clear to me why this is needed (especialy in =
v1).<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>My take on #2 is that its a =
matter
of policy of the client to the client, but if accepting the MUST reject
text&nbsp;here gets us out of #1&nbsp;which will break clients I will =
accept
it.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Ryan</span></font>&nbsp;<o:p=
></o:p></p>

</div>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter =
style=3D'margin-left:36.0pt;text-align:center'><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D3 width=3D"100%" align=3Dcenter>

</span></font></div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:
12.0pt;margin-left:36.0pt'><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> Liaquat
Khan<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thu 12/4/2003 10:54 =
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Ryan M. Hurst'; =
'Florian
Oelmaier'; 'David Engberg'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: DISCUSS: =
MUST reject
in OCSPv1</span></font><o:p></o:p></p>

</div>

<div><pre style=3D'margin-left:36.0pt;WORD-WRAP: break-word'><font =
size=3D2
face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Ryan,<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>We also agree with your viewpoint, particular =
the point about a nonce<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>being a matter for local client policy.<span =
style=3D'mso-spacerun:yes'>&nbsp; =
</span><o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>In the various OCSP clients we have, the =
option of whether to include<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>nonce or not in the request message is left =
to local policy (i.e. the<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>administrator can configure whether or not =
nonce is included in the<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>request message). =
<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>If the administrator decides nonces are =
necessary (to prevent replays)<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>then he/she will select these and our OCSP =
clients will include these in<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>the requests.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>Now if an OCSP response is =
received back without a nonce<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>it will be rejected by our OCSP =
clients.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>On the other hand, if the administrator feels =
nonces are not required<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>(to allow for cached responses) then he/she =
will not select to include<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>one in outgoing responses. =
<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>The situation &quot;we would like to have =
nonces in OCSP requests as default,<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>but if the server legitimately doesn't =
support nonces we are happy to<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>forgo nonces or we will generate a fresh =
request without a nonce&quot; is not<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>that common in my opinion.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>If such a case does exist, =
local policy will<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>probably be also happy to choose to not =
include a nonce in the OCSP<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>request message in the first =
place.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Regards,<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Liaquat<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Ascertia Limited, Orchard Building, Royal =
Holloway, Egham, Surrey, TW20<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>OEX<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>tel: [phone], fax: [phone] =
497301, mobile: [phone]<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>308766<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>website: =
www.ascertia.com<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>-----Original =
Message-----<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>From: [e-mail] =
[mailto:[e-mail]]<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>On Behalf Of Ryan M. =
Hurst<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Sent: 05 December 2003 =
01:41<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>To: Florian Oelmaier; David Engberg; =
[e-mail]<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Subject: RE: DISCUSS: MUST reject in =
OCSPv1<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>I am concerned with the idea of making any =
change to the standard that<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&quot;changes the 5 year old =
protocol&quot;.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>This is particularly true since I don't see =
anyone on the list saying<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>this NonceUnsupported is needed, just that =
they would accept it.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>I still think what is done with the nonce is =
a matter of local (client)<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>policy, and that if replay protection is =
desired responses not<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>containing the requested nonce MUST be =
rejected.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>But since I appear to be odd man out on this, =
I would rather see us fall<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>back to Russ's original recommendation of =
MUST reject than break a 5<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>year old standard. =
<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Ryan<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>-----Original =
Message-----<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>From: [e-mail] =
[mailto:[e-mail]]<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>On Behalf Of Florian =
Oelmaier<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Sent: Thursday, December 04, 2003 1:47 =
AM<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>To: David Engberg; =
[e-mail]<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Subject: RE: DISCUSS: MUST reject in =
OCSPv1<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&gt; I like the elegance of Russ and =
Florian's ideas for securely<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>signalling =
<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&gt; that a server doesn't support nonces by =
using a special value for the <o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&gt; nonce in replies.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>This seems like the =
&quot;right&quot; place to put this<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>message <o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&gt; to the =
client.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Just for the record: I think you are =
referring to our server-generated<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>nonces when you talk about &quot;Florian's =
idea&quot;. And while Russel is<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>signalling &quot;NonceUnsupported&quot; with =
a special nonce-value, we are<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>singalling &quot;NonceSupported&quot; with =
the inclusion of a nonce into every<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>request (mirrored from the request or =
server-generated). Thus we are not<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>subject to the attack you mention, as this =
does not need any additional<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>code in any existing =
client.<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Russ proposal is a change in the protocol. =
Thus we need to update all<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>the clients and servers out there. Seeing =
that the proposed change is<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>needed and recognizing it as a good solution, =
I would accept this. <o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>-- <o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Florian =
Oelmaier<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>SyTrust<o:p></o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre
style=3D'margin-left:36.0pt'><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre></div>

</div>

</body>

</html>

------=_NextPart_000_0027_01C3BB63.EEAA9920--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5IjHib057858 for <[e-mail]>; Fri, 5 Dec 2003 10:45:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5IjHMo057857 for ietf-pkix-bks; Fri, 5 Dec 2003 10:45:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5IjFib057852 for <[e-mail]>; Fri, 5 Dec 2003 10:45:15 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hB5IjGA06154; Fri, 5 Dec 2003 11:45:16 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Ryan M. Hurst" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 11:47:20 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <26E2C7F4-0558-4845-A20D-CFAE6E33432C@mimectl>
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>

> From: Ryan M. Hurst
> Sent: Friday, December 05, 2003 10:57 AM
>
> [rmh]As I said, I am willing to accept the
> must reject if that means that others will
> drop the idea of adding breaking changes to
> the v1 protocol.

So now we've come full circle.  A plain MUST reject is where we
got started and which principle Russ affirmed in Minneapolis.
I'm curious what others think.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5HwZib055938 for <[e-mail]>; Fri, 5 Dec 2003 09:58:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5HwZkl055937 for ietf-pkix-bks; Fri, 5 Dec 2003 09:58:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5HwXib055929 for <[e-mail]>; Fri, 5 Dec 2003 09:58:33 -0800 (PST) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 09:58:31 -0800
Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Dec 2003 09:58:29 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 09:54:50 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 09:59:28 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 5 Dec 2003 09:58:31 -0800
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.150 157.54.0.150 via HTTP with MS-WebStorage 6.5.7122
Received: 157.54.0.150 157.54.0.150 from 157.54.1.70 157.54.1.70 via HTTP with MS-WebStorage 6.5.7122
Subject: RE: DISCUSS: MUST reject in OCSPv1
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
To: Michael Myers <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: DISCUSS: MUST reject in OCSPv1
Thread-Index: AcO7WRz4+Sb5JLPURX2ypEzO+Fyf+Q==
Message-ID: <26E2C7F4-0558-4845-A20D-CFAE6E33432C@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.7122.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.7122.0
Date: Fri, 5 Dec 2003 09:56:31 -0800
X-OriginalArrivalTime: 05 Dec 2003 17:58:31.0837 (UTC) FILETIME=[650D74D0:01C3BB59]
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>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_64E2673C-8737-4498-AE9C-D488CBA4CAF1_"

--_64E2673C-8737-4498-AE9C-D488CBA4CAF1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Comments in-line



From: Michael Myers
Sent: Fri 12/5/2003 7:45 AM
To: [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1


The fact still remains that Section 4.4.1 of RFC 2560 opens with
the sentence "The nonce cryptographically binds a request and a
response to prevent replay attacks."  The original intent of
this assertion is self-evident: nonces are to be incorporated by
servers.
[rmh]As I said, I am willing to accept the must reject if that means that o=
thers will drop the idea of adding breaking changes to the v1 protocol.

Yet it is a fair observation that the relationship between
cached responses and nonced requests is underspecified,
particularly in the case of Internet-facing services receiving
requests from a heterogeneous population of clients over which
such services have no administrative control.
[rmh] No argument here!
I chose nonceUnsupported as a candidate means of developing a
compromise solution to this issue based in part on prior list
dialog, including that below:
[rmh]I just dont see what the client gets out of nonce not supported, he ei=
ther knows he needs a nonced response or not, its a matter of local policy.=
 I remember when I did the default configuration for the ValiCert desktop v=
alidator, it just was not possible to make a one-size fits all policy just =
as an example consider the fact that some responders will require signature=
s and some wont, the client already has to deal with this concept.=20

> From: David Engberg
> Sent: Thursday, October 02, 2003 12:23 PM
> Subject: Re: OCSP response pre-production
>
> If adding a new top-level error code is possible
> in v1, and adding a new response extension to
> indicate nonceUnsupported (or similar solution)
> is only possible in v2, then this may be the
> best course of action.

I saw how it was possible by cycling v1 at Proposed to get this
solution into v1 in a way that satisified all perspectives,
including that of the opening sentence, and yet not break the
installed base.  The core notion was that of a "caveated
response".  Looking back, had we addressed this issue during the
I-D phase of OCSP, I suspect we would have come up with
something very similar.

It enables secure on-the-fly client configuration on a
per-server basis while also providing as much OCSP value add as
possible.  Upon receipt of a caveated response, a clever client
could record this fact and not bother sending nonces to that
server again.

As proposed on this thread,
http://www.imc.org/ietf-pkix/mail-archive/msg07210.html
we have six who agree to this path forward and two who disagree.
Perhaps a poll is in order to get conclusive on it.

Yes, sending back a plain nonceless response to a nonced request
is not conformant to this proposal.  But neither is it
conformant in spirit to the above 4.4.1 sentence.  My
expectation is that, no matter what we do here, this will
continue anyway as a de-facto market standard practice until
such time as the market dictates otherwise. e.g. somebody gets
burned.  In which case the official IETF standard will have the
solution in place.  By not taking this action, someone could
otherwise point back to the RFC and claim it is the RFC's fault
for being underspecified in this area.  Which is where we got
started over two months ago.

Mike

--_64E2673C-8737-4498-AE9C-D488CBA4CAF1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText62173 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Comments in-line=
</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Michael Myers<BR><B>Sent:</B> Fri=
 12/5/2003 7:45 AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> RE: D=
ISCUSS: MUST reject in OCSPv1<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">The fact still remains that Secti=
on 4.4.1 of RFC 2560 opens with
the sentence "The nonce cryptographically binds a request and a
response to prevent replay attacks."  The original intent of
this assertion is self-evident: nonces are to be incorporated by
servers.</PRE><PRE style=3D"WORD-WRAP: break-word">[rmh]As I said, I am wil=
ling to accept the must reject if that means that others will drop the idea=
 of adding breaking changes to the v1 protocol.

Yet it is a fair observation that the relationship between
cached responses and nonced requests is underspecified,
particularly in the case of Internet-facing services receiving
requests from a heterogeneous population of clients over which
such services have no administrative control.
[rmh] No argument here!</PRE><PRE style=3D"WORD-WRAP: break-word">I chose n=
onceUnsupported as a candidate means of developing a
compromise solution to this issue based in part on prior list
dialog, including that below:</PRE><PRE style=3D"WORD-WRAP: break-word">[rm=
h]I just dont see what the client gets out of nonce not supported, he eithe=
r knows he needs a nonced response or not, its a matter of local policy. I =
remember when I did the default configuration for the ValiCert desktop vali=
dator, it just was not possible to make a one-size fits all policy just as =
an example consider the fact that some responders will require signatures a=
nd some wont, the client already has to deal with this concept.=20

&gt; From: David Engberg
&gt; Sent: Thursday, October 02, 2003 12:23 PM
&gt; Subject: Re: OCSP response pre-production
&gt;
&gt; If adding a new top-level error code is possible
&gt; in v1, and adding a new response extension to
&gt; indicate nonceUnsupported (or similar solution)
&gt; is only possible in v2, then this may be the
&gt; best course of action.

I saw how it was possible by cycling v1 at Proposed to get this
solution into v1 in a way that satisified all perspectives,
including that of the opening sentence, and yet not break the
installed base.  The core notion was that of a "caveated
response".  Looking back, had we addressed this issue during the
I-D phase of OCSP, I suspect we would have come up with
something very similar.

It enables secure on-the-fly client configuration on a
per-server basis while also providing as much OCSP value add as
possible.  Upon receipt of a caveated response, a clever client
could record this fact and not bother sending nonces to that
server again.

As proposed on this thread,
http://www.imc.org/ietf-pkix/mail-archive/msg07210.html
we have six who agree to this path forward and two who disagree.
Perhaps a poll is in order to get conclusive on it.

Yes, sending back a plain nonceless response to a nonced request
is not conformant to this proposal.  But neither is it
conformant in spirit to the above 4.4.1 sentence.  My
expectation is that, no matter what we do here, this will
continue anyway as a de-facto market standard practice until
such time as the market dictates otherwise. e.g. somebody gets
burned.  In which case the official IETF standard will have the
solution in place.  By not taking this action, someone could
otherwise point back to the RFC and claim it is the RFC's fault
for being underspecified in this area.  Which is where we got
started over two months ago.

Mike


</PRE></DIV></BODY></HTML>

--_64E2673C-8737-4498-AE9C-D488CBA4CAF1_--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5HInib053432 for <[e-mail]>; Fri, 5 Dec 2003 09:18:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5HIn0l053431 for ietf-pkix-bks; Fri, 5 Dec 2003 09:18:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5HIZib053417 for <[e-mail]>; Fri, 5 Dec 2003 09:18:48 -0800 (PST) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 5 Dec 2003 09:18:57 -0800
Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Dec 2003 09:18:31 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 09:18:34 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 09:20:07 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 5 Dec 2003 09:18:23 -0800
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.150 157.54.0.150 via HTTP with MS-WebStorage 6.5.7122
Received: 157.54.0.150 157.54.0.150 from 157.54.1.70 157.54.1.70 via HTTP with MS-WebStorage 6.5.7122
Subject: RE: DISCUSS: MUST reject in OCSPv1
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <000c01c3bafc$ae734260$e8a47ad5@LiaquatDELL>
References:  <[e-mail]>, <000c01c3bafc$ae734260$e8a47ad5@LiaquatDELL>
To: <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, "'David Engberg'" <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: DISCUSS: MUST reject in OCSPv1
Thread-Index: AcO7U4CtzrcXiwHqTYyQxHeStTQzdw==
Message-ID: <1BED1193-1DB5-4E45-8B2E-1B6FD2AFA617@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.7122.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.7122.0
Date: Fri, 5 Dec 2003 09:16:21 -0800
X-OriginalArrivalTime: 05 Dec 2003 17:18:23.0186 (UTC) FILETIME=[C9627B20:01C3BB53]
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>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_E1C02530-570F-453A-A34B-7C5734A6EE62_"

--_E1C02530-570F-453A-A34B-7C5734A6EE62_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Liaquat - I don't think there is any disagreement on weather it is up to th=
e client or not on including the nonce, there is however disagreement on:
What the responder returns if it can not return a nonce
What the client must do when it receives a response to a nonced request
For #1 my stance has been that the server should always return a authoritat=
ive response.

For #2 my stance has been that just like the decision to include the nonce =
in the first place its up to the client to decide what to do with it when h=
e gets it back, and that clients wanting replay protection SHOULD reject re=
sponses that do not contain the nonce from their request.

That being said others believe:

For #1 that the server needs to return a special response indicating it is =
not capable of supporting nonces

For #2 that the client has no choice on what to do with the nonce in the re=
sponse if he included a nonce in the request.

My take on #1 is that I don't see why the client needs to know that, after =
all if the response to a nonced request does not contain the same nonce doe=
sn't that mean the server was unable to produce a nonced response?=20

Changing the protocol by adjusting the ASN.1 of the nonce, adding a new ext=
ension or error code, or adding special semantics to the value of the nonce=
 will break the existing implementations out there and its not clear to me =
why this is needed (especialy in v1).

My take on #2 is that its a matter of policy of the client to the client, b=
ut if accepting the MUST reject text here gets us out of #1 which will brea=
k clients I will accept it.

Ryan=20



From: Liaquat Khan
Sent: Thu 12/4/2003 10:54 PM
To: 'Ryan M. Hurst'; 'Florian Oelmaier'; 'David Engberg'; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1


Ryan,

We also agree with your viewpoint, particular the point about a nonce
being a matter for local client policy. =20

In the various OCSP clients we have, the option of whether to include
nonce or not in the request message is left to local policy (i.e. the
administrator can configure whether or not nonce is included in the
request message).=20

If the administrator decides nonces are necessary (to prevent replays)
then he/she will select these and our OCSP clients will include these in
the requests.  Now if an OCSP response is received back without a nonce
it will be rejected by our OCSP clients.

On the other hand, if the administrator feels nonces are not required
(to allow for cached responses) then he/she will not select to include
one in outgoing responses.=20

The situation "we would like to have nonces in OCSP requests as default,
but if the server legitimately doesn't support nonces we are happy to
forgo nonces or we will generate a fresh request without a nonce" is not
that common in my opinion.  If such a case does exist, local policy will
probably be also happy to choose to not include a nonce in the OCSP
request message in the first place.

Regards,
Liaquat

Ascertia Limited, Orchard Building, Royal Holloway, Egham, Surrey, TW20
OEX
tel: [phone], fax: [phone], mobile: [phone]
308766
website: www.ascertia.com


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1


I am concerned with the idea of making any change to the standard that
"changes the 5 year old protocol".

This is particularly true since I don't see anyone on the list saying
this NonceUnsupported is needed, just that they would accept it.

I still think what is done with the nonce is a matter of local (client)
policy, and that if replay protection is desired responses not
containing the requested nonce MUST be rejected.

But since I appear to be odd man out on this, I would rather see us fall
back to Russ's original recommendation of MUST reject than break a 5
year old standard.=20

Ryan
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1



> I like the elegance of Russ and Florian's ideas for securely
signalling=20
> that a server doesn't support nonces by using a special value for the=20
> nonce in replies.  This seems like the "right" place to put this
message=20
> to the client.

Just for the record: I think you are referring to our server-generated
nonces when you talk about "Florian's idea". And while Russel is
signalling "NonceUnsupported" with a special nonce-value, we are
singalling "NonceSupported" with the inclusion of a nonce into every
request (mirrored from the request or server-generated). Thus we are not
subject to the attack you mention, as this does not need any additional
code in any existing client.

Russ proposal is a change in the protocol. Thus we need to update all
the clients and servers out there. Seeing that the proposed change is
needed and recognizing it as a good solution, I would accept this.=20

--=20
Florian Oelmaier
SyTrust

--_E1C02530-570F-453A-A34B-7C5734A6EE62_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText48938 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Liaquat - I don'=
t think there is any disagreement on weather it is up to the client or not =
on including the nonce, there is however disagreement on:</FONT></DIV>
<OL dir=3Dltr>
<LI>
<DIV><FONT face=3DArial size=3D2>What the responder returns if it can not r=
eturn a nonce</FONT></DIV>
<LI>
<DIV><FONT face=3DArial size=3D2>What the client must do when it receives a=
 response to a nonced request</FONT></DIV></LI></OL>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>For #1 my stance has been that t=
he server should always return a authoritative response.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>For #2 my stance has been that j=
ust like the decision to include the nonce in the first place its up to the=
 client to decide what to do with it when he gets it back, and that clients=
 wanting replay protection SHOULD reject responses that do not contain the =
nonce from their request.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>That being said others believe:<=
/FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>For #1 that the server needs to =
return a special response indicating it is not capable of supporting nonces=
</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>For #2 that the client has no ch=
oice on what to do with the nonce in the response if he included a nonce in=
 the request.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>My take on #1 is that I don't se=
e why the client needs to know that, after all if the response to a nonced =
request does not contain the same nonce doesn't that mean the server was un=
able to produce a nonced response? </FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Changing the protocol by adjusti=
ng the ASN.1 of the nonce, adding a new extension or error code, or adding =
special semantics to the value of the nonce will break the existing impleme=
ntations out there and its not clear to me why this is needed (especialy in=
 v1).</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>My take on #2 is that its a matt=
er of policy of the client to the client, but if accepting the MUST reject =
text&nbsp;here gets us out of #1&nbsp;which will break clients I will accep=
t it.</FONT></DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT>&nbsp;</DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Liaquat Khan<BR><B>Sent:</B> Thu =
12/4/2003 10:54 PM<BR><B>To:</B> 'Ryan M. Hurst'; 'Florian Oelmaier'; 'Davi=
d Engberg'; [e-mail]<BR><B>Subject:</B> RE: DISCUSS: MUST reject i=
n OCSPv1<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">Ryan,

We also agree with your viewpoint, particular the point about a nonce
being a matter for local client policy. =20

In the various OCSP clients we have, the option of whether to include
nonce or not in the request message is left to local policy (i.e. the
administrator can configure whether or not nonce is included in the
request message).=20

If the administrator decides nonces are necessary (to prevent replays)
then he/she will select these and our OCSP clients will include these in
the requests.  Now if an OCSP response is received back without a nonce
it will be rejected by our OCSP clients.

On the other hand, if the administrator feels nonces are not required
(to allow for cached responses) then he/she will not select to include
one in outgoing responses.=20

The situation "we would like to have nonces in OCSP requests as default,
but if the server legitimately doesn't support nonces we are happy to
forgo nonces or we will generate a fresh request without a nonce" is not
that common in my opinion.  If such a case does exist, local policy will
probably be also happy to choose to not include a nonce in the OCSP
request message in the first place.

Regards,
Liaquat

Ascertia Limited, Orchard Building, Royal Holloway, Egham, Surrey, TW20
OEX
tel: [phone], fax: [phone], mobile: [phone]
308766
website: www.ascertia.com


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1


I am concerned with the idea of making any change to the standard that
"changes the 5 year old protocol".

This is particularly true since I don't see anyone on the list saying
this NonceUnsupported is needed, just that they would accept it.

I still think what is done with the nonce is a matter of local (client)
policy, and that if replay protection is desired responses not
containing the requested nonce MUST be rejected.

But since I appear to be odd man out on this, I would rather see us fall
back to Russ's original recommendation of MUST reject than break a 5
year old standard.=20

Ryan
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1



&gt; I like the elegance of Russ and Florian's ideas for securely
signalling=20
&gt; that a server doesn't support nonces by using a special value for the=
=20
&gt; nonce in replies.  This seems like the "right" place to put this
message=20
&gt; to the client.

Just for the record: I think you are referring to our server-generated
nonces when you talk about "Florian's idea". And while Russel is
signalling "NonceUnsupported" with a special nonce-value, we are
singalling "NonceSupported" with the inclusion of a nonce into every
request (mirrored from the request or server-generated). Thus we are not
subject to the attack you mention, as this does not need any additional
code in any existing client.

Russ proposal is a change in the protocol. Thus we need to update all
the clients and servers out there. Seeing that the proposed change is
needed and recognizing it as a good solution, I would accept this.=20

--=20
Florian Oelmaier
SyTrust




</PRE></DIV></BODY></HTML>

--_E1C02530-570F-453A-A34B-7C5734A6EE62_--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Fh8ib048468 for <[e-mail]>; Fri, 5 Dec 2003 07:43:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5Fh8dx048467 for ietf-pkix-bks; Fri, 5 Dec 2003 07:43:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Fh7ib048461 for <[e-mail]>; Fri, 5 Dec 2003 07:43:07 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hB5Fh8A92776 for <[e-mail]>; Fri, 5 Dec 2003 08:43:08 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 08:45:12 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
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>

The fact still remains that Section 4.4.1 of RFC 2560 opens with
the sentence "The nonce cryptographically binds a request and a
response to prevent replay attacks."  The original intent of
this assertion is self-evident: nonces are to be incorporated by
servers.

Yet it is a fair observation that the relationship between
cached responses and nonced requests is underspecified,
particularly in the case of Internet-facing services receiving
requests from a heterogeneous population of clients over which
such services have no administrative control.

I chose nonceUnsupported as a candidate means of developing a
compromise solution to this issue based in part on prior list
dialog, including that below:

> From: David Engberg
> Sent: Thursday, October 02, 2003 12:23 PM
> Subject: Re: OCSP response pre-production
>
> If adding a new top-level error code is possible
> in v1, and adding a new response extension to
> indicate nonceUnsupported (or similar solution)
> is only possible in v2, then this may be the
> best course of action.

I saw how it was possible by cycling v1 at Proposed to get this
solution into v1 in a way that satisified all perspectives,
including that of the opening sentence, and yet not break the
installed base.  The core notion was that of a "caveated
response".  Looking back, had we addressed this issue during the
I-D phase of OCSP, I suspect we would have come up with
something very similar.

It enables secure on-the-fly client configuration on a
per-server basis while also providing as much OCSP value add as
possible.  Upon receipt of a caveated response, a clever client
could record this fact and not bother sending nonces to that
server again.

As proposed on this thread,
http://www.imc.org/ietf-pkix/mail-archive/msg07210.html
we have six who agree to this path forward and two who disagree.
Perhaps a poll is in order to get conclusive on it.

Yes, sending back a plain nonceless response to a nonced request
is not conformant to this proposal.  But neither is it
conformant in spirit to the above 4.4.1 sentence.  My
expectation is that, no matter what we do here, this will
continue anyway as a de-facto market standard practice until
such time as the market dictates otherwise. e.g. somebody gets
burned.  In which case the official IETF standard will have the
solution in place.  By not taking this action, someone could
otherwise point back to the RFC and claim it is the RFC's fault
for being underspecified in this area.  Which is where we got
started over two months ago.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5EqTib045557 for <[e-mail]>; Fri, 5 Dec 2003 06:52:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5EqT1p045556 for ietf-pkix-bks; Fri, 5 Dec 2003 06:52:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.be.ubizen.com (batty.be.ubizen.com [212.113.70.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5EqRib045549 for <[e-mail]>; Fri, 5 Dec 2003 06:52:28 -0800 (PST) (envelope-from [e-mail])
Received: (from local) by mail.be.ubizen.com id hB5EqO2x007356 for <[e-mail]>; Fri, 5 Dec 2003 15:52:24 +0100
Received: from UNKNOWN(10.0.0.108), claiming to be "amaya.be.ubizen.com" via SMTP by batty.netvision.be, id smtpd07338aaa; Fri Dec  5 14:52:09 2003
Received: (qmail 31768 invoked from network); 5 Dec 2003 14:52:08 -0000
Received: from unknown (HELO ubi) (10.0.0.10) by amaya.be.ubizen.com with SMTP; 5 Dec 2003 14:52:06 -0000
Received: from ubizen.com (por017a.be.ubizen.com [10.0.40.67]) by ubi.be.ubizen.com (#####) with ESMTP id <[e-mail]>; Fri, 05 Dec 2003 15:51:09 +0100 (MET)
Date: Fri, 05 Dec 2003 15:54:29 +0100
From: Andreas Mitrakas <[e-mail]>
Subject: Re: Certificate Policy Standardization
To: Peter Gutmann <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <[e-mail]>
X-Sanitizer: Out/BE
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 reckon the underlying question is whether you want legal certainty to be
associated with the certificate or with the CA. By changing the OID to indicate a
new version of the CP, trust is vested in the certificate because the RP has a
better chance to know which terms apply to that specific cert . Else, by sticking
to one single OID for the CA policy lifetime, you assume that the CA will act
dilligently in notifying the RP of applicable changes, post the right version on
the right repository in the little disused lavatory of yours -- let alone posting
the hash of that CP possibly on a third party repository keeping someone else's
leopard busy to guard it.

By changing a policy OID when the policy changes, the issuer might choose to apply
those changes to certificates issued in the future only, which spares the CA from
re-issuing all certs all over again while linking the specific CP terms to certs
issued in the future. This approach seems to be fair for the subscriber because a
subscriber agrees on  one specific set of terms that do not necessarily have to be
unilaterally reviewed and updated during the term of service, at least for no
reason. The result in this case would be that same class certs will be issued at
different CP speeds.

A relying party might have to periodically update his signature policy to include
all new OIDs and reference the certificate polices that govern the certs he
accepts. For the small time RP there seems to be no other specific remedy than
rule nr. 1 in the RP Commandments, that reads: "thou shall always check the CP of
the certs you accept".

Having said that it appears that shifting too much responsibility to the side of
the end user who happens to also be a consumer might be tough to defend. On the
other hand notifying a large population of subscribers on changes say three times
a year might also be challenging. At the end of the day it might be plain simpler
to accept that certs of the same class might be governed by different CPs.

A possible work around to alleviate negative effects would be to determine two
sets of terms of a CP:
- those that are etched in stone and do not change unless somehting extraordinary
happens
- those that are non essential and periodic changes are permitted.

I suppose there is no easy answer to this one and both options have their merits.

andreas


Peter Gutmann wrote:

> I wrote:
>
> >The feeling here was that a ToS-style policy might violate (at least NZ)
> >consumer protection legislation, however since a number of large
> >organisations relied on these types of agreements there would probably be a
> >spirited defence of them in court and/or existing case law upholding them.
>
> I've now checked this with a lawyer to see what the story is.  Disclaimer: Not
> legal advice, merely an informal chat, and since it's been filtered through a
> non-lawyer (me) it's even less legally useful.  Anyway, it pretty much follows
> what I said earlier: It's a grey area (meaning that few have ever tried to
> challenge it so there's not much precedent), but widely used in many parts of
> the world.  For example when you sign up as an Oracle development partner you
> get a short paper document to sign, and that refers you to a much longer
> online document that you're expected to check regularly ("say, once a month,
> although no-one does").  This is probably the closest real-world analogy to
> the cert policy extension and policy URL, and has presumably undergone
> intensive scrutiny by lawyers working for some fairly serious players on both
> sides of the equation.  The one thing you'd have to do (at least to keep a NZ
> court happy) is notify users of changes, for example by sending them email to
> tell them to check the online T&C (terms and conditions), although I forgot to
> ask whether you could get away with a "Our T&C have changed", a "The privacy
> section of our T&C has changed", or a full "These exact changes have been made
> to our T&C".  So my original comments:
>
>   So what you do is define a policy OID that points to whatever the policy is
>   this week, and if you need to change anything you alter your policy, which
>   customers are expected to check by downloading it from an undocumented
>   location in an LDAP directory on a server in a locked filing cabinet in a
>   disused lavatory in the cellar with a sign on the door saying "Beware of the
>   Leopard", as explained in section 43, subsection 18, clause 4(a).13,
>   paragraph 227.a of said policy.  The policy extension seems almost designed
>   for this use, it has provisions for specifying an OID and a means of
>   pointing to the policy of the week, which is just what you need.
>
>   The reason why this is approach is used is that if you changed your OID when
>   your policy changes, you'd have to re-issue all your certs, which no-one
>   wants to do.  So you define your policy to be a mutable object, push
>   responsibility for checking for changes onto the user in the standard
>   manner, and you're set.
>
> still stand, you just need to apply the appropriate amount of legal time to
> get it set up in a satisfactory manner.
>
> Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Elmib045337 for <[e-mail]>; Fri, 5 Dec 2003 06:47:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5Elm8d045336 for ietf-pkix-bks; Fri, 5 Dec 2003 06:47:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Eliib045330 for <[e-mail]>; Fri, 5 Dec 2003 06:47:46 -0800 (PST) (envelope-from [e-mail])
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.11.6p2/8.11.6) with ESMTP id hB5Elih03748 for <[e-mail]>; Fri, 5 Dec 2003 09:47:44 -0500 (EST)
Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1 #40646) id <[e-mail]> for [e-mail]; Fri, 05 Dec 2003 09:47:44 -0500 (EST)
Received: from EMSS03I00.us.lmco.com ([141.240.31.211]) by lmco.com (PMDF V6.1-1 #40646) with ESMTP id <[e-mail]> for [e-mail]; Fri, 05 Dec 2003 09:47:43 -0500 (EST)
Received: from EMSS03M13.us.lmco.com ([141.240.192.68]) by EMSS03I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 05 Dec 2003 09:47:43 -0500
Date: Fri, 05 Dec 2003 09:47:43 -0500
From: "Stoner, Nicholas E" <[e-mail]>
Subject: remove
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1
Content-type: multipart/alternative; boundary="Boundary_(ID_NZx/+sDRMInFEheYk1wJ/w)"
Thread-Topic: remove
Thread-Index: AcO7PtRrZbN6Vv/bTJyB9gHZWb4R+w==
Content-Class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-OriginalArrivalTime: 05 Dec 2003 14:47:43.0192 (UTC) FILETIME=[BD20DD80:01C3BB3E]
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.

--Boundary_(ID_NZx/+sDRMInFEheYk1wJ/w)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

remove

Nick Stoner
ISLDP - Corporate Information Security Office
Lockheed Martin Enterprise Information Systems
Phone: [phone]
Cell: [phone]


--Boundary_(ID_NZx/+sDRMInFEheYk1wJ/w)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT

<!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 6.0.6487.1">
<TITLE>remove</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P ALIGN=LEFT><SPAN LANG="en-us"><FONT SIZE=2 FACE="Arial">remove</FONT></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN></P>

<P ALIGN=LEFT><B><SPAN LANG="en"></SPAN></B><A NAME=""><B><SPAN LANG="en"><FONT COLOR="#000080" FACE="Arial">Nick Stoner</FONT></SPAN></B></A><SPAN LANG="en-us"><B></B></SPAN><B><SPAN LANG="en"></SPAN></B></P>

<P ALIGN=LEFT><SPAN LANG="en"><FONT COLOR="#000000" SIZE=1 FACE="Arial">ISLDP - Corporate Information Security Office</FONT></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en"><FONT COLOR="#000000" SIZE=1 FACE="Arial">Lockheed Martin Enterprise Information Systems</FONT></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en"><FONT COLOR="#000000" SIZE=1 FACE="Arial">Phone: [phone]</FONT></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en"><FONT COLOR="#000000" SIZE=1 FACE="Arial">Cell: [phone]</FONT></SPAN><SPAN LANG="en-us"><B></B></SPAN><SPAN LANG="en-us"><B></B></SPAN><B><SPAN LANG="en"></SPAN></B></P>

<P ALIGN=LEFT><SPAN LANG="en-us"></SPAN></P>

</BODY>
</HTML>

--Boundary_(ID_NZx/+sDRMInFEheYk1wJ/w)--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5EgMib044980 for <[e-mail]>; Fri, 5 Dec 2003 06:42:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5EgMU8044979 for ietf-pkix-bks; Fri, 5 Dec 2003 06:42:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.it-norr.com (mail7.it-norr.com [80.244.64.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5EgHib044963 for <[e-mail]>; Fri, 5 Dec 2003 06:42:20 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from HANSTOSHIBA ([217.211.59.224]) by mail4.it-norr.com (IT-NORR Mail Cluster v2003) with ASMTP id DUA74354 for <[e-mail]>; Fri, 05 Dec 2003 15:42:13 +0100
From: "Hans Nilsson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Certificate Policy Standardization
Date: Fri, 5 Dec 2003 15:42:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Thread-Index: AcO7O5Jk/K68r9dsSmGAto/YkAxYYQAATlWg
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>

Very funny, as usual, Peter. However, let me just spoil your joke a bit.
It's not THAT bad...

1. A well-written CP/CPS should include a description of its change process
and its  distribution. Extract from RFC 3647: 

9.12.1 Procedure for Amendment              8.1
   ------------------------------------------------------
   9.12.2 Notification Mechanism
          and Period                           8.1

So if the original CP/CPS contains your description 
>   customers are expected to check by downloading it from an undocumented
>   location in an LDAP directory on a server in a locked filing cabinet in
a
>   disused lavatory in the cellar with a sign on the door saying "Beware of
the
>   Leopard",
Well, they better beware of the certificates in the first place....

2. You also say:

>   The reason why this is approach is used is that if you changed your OID
when
>   your policy changes, you'd have to re-issue all your certs, which no-one
>   wants to do.  

Why re-issue?? Old certs with old policy-OID are still fine and valid, but
from now on the CA just issues new certs according to its new policy, with
new OID.

Hans Nilsson

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Peter Gutmann
> Sent: Friday, December 05, 2003 2:40 PM
> To: [e-mail]; [e-mail];
[e-mail]
> Subject: Re: Certificate Policy Standardization
> 
> 
> I wrote:
> 
> >The feeling here was that a ToS-style policy might violate (at least NZ)
> >consumer protection legislation, however since a number of large
> >organisations relied on these types of agreements there would probably be
a
> >spirited defence of them in court and/or existing case law upholding
them.
> 
> I've now checked this with a lawyer to see what the story is.  Disclaimer:
Not
> legal advice, merely an informal chat, and since it's been filtered
through a
> non-lawyer (me) it's even less legally useful.  Anyway, it pretty much
follows
> what I said earlier: It's a grey area (meaning that few have ever tried to
> challenge it so there's not much precedent), but widely used in many parts
of
> the world.  For example when you sign up as an Oracle development partner
you
> get a short paper document to sign, and that refers you to a much longer
> online document that you're expected to check regularly ("say, once a
month,
> although no-one does").  This is probably the closest real-world analogy
to
> the cert policy extension and policy URL, and has presumably undergone
> intensive scrutiny by lawyers working for some fairly serious players on
both
> sides of the equation.  The one thing you'd have to do (at least to keep a
NZ
> court happy) is notify users of changes, for example by sending them email
to
> tell them to check the online T&C (terms and conditions), although I
forgot to
> ask whether you could get away with a "Our T&C have changed", a "The
privacy
> section of our T&C has changed", or a full "These exact changes have been
made
> to our T&C".  So my original comments:
> 
>   So what you do is define a policy OID that points to whatever the policy
is
>   this week, and if you need to change anything you alter your policy,
which
>   customers are expected to check by downloading it from an undocumented
>   location in an LDAP directory on a server in a locked filing cabinet in
a
>   disused lavatory in the cellar with a sign on the door saying "Beware of
the
>   Leopard", as explained in section 43, subsection 18, clause 4(a).13,
>   paragraph 227.a of said policy.  The policy extension seems almost
designed
>   for this use, it has provisions for specifying an OID and a means of
>   pointing to the policy of the week, which is just what you need.
> 
>   The reason why this is approach is used is that if you changed your OID
when
>   your policy changes, you'd have to re-issue all your certs, which no-one
>   wants to do.  So you define your policy to be a mutable object, push
>   responsibility for checking for changes onto the user in the standard
>   manner, and you're set.
> 
> still stand, you just need to apply the appropriate amount of legal time
to
> get it set up in a satisfactory manner.
> 
> Peter.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5EIxib043638 for <[e-mail]>; Fri, 5 Dec 2003 06:18:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5EIxHL043637 for ietf-pkix-bks; Fri, 5 Dec 2003 06:18:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5EIvib043630 for <[e-mail]>; Fri, 5 Dec 2003 06:18:58 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 8762A3405A; Sat,  6 Dec 2003 03:18:40 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hB5EIvU06718; Sat, 6 Dec 2003 03:18:57 +1300
Date: Sat, 6 Dec 2003 03:18:57 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
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:

>Citing the critique from the Counterpane analysis of Ipsec and IKE from 5
>years ago is a nice touch, but you should be aware that the non-IKE
>criticisms were largely refuted in messages on the IPsec list.

Well that's a marvellous strawman you've demolished there, but you still
haven't addressed the original point I made, which is that without a
rationale, without explanations of difficult-to-understand points, a complex
standard is in trouble.  In fact you've pretty much agreed with my comments:

  Unfortunately, the folks who performed the analysis were not protocol
  experts. They made assertions of what was wrong and how it should be fixed,
  and in most instances THEY were wrong.

Without a rationale and implementation notes to guide them, there was no way
they could understand the spec, so they ended up analysing something that was
different from whatever it was the spec was trying to describe.  What was
refuted was the analysis of the way Bruce thought IPsec worked, not the fact
that the spec is confusing, ambiguous, and contradictory.

Your comments do however raise one question: If (as you say) the intent wasn't
to create an IPsec for dummies, who exactly is the target audience?  It's not
the average person, it's not techies and sysadmins, it's not cryptographers,
it's not security researchers, just who *was* this written for anyway?  Your
first message implied that the only people capable of understanding IPsec are
people who already understand IPsec before they start.  So the target audience
for the IPsec spec is "Anyone who's spent the last 5-10 years on the IPsec
list"?  What happens when an outsider has to implement IPsec?   (Well, I think
that's obvious from real-world experience with IPsec deployment when 2 or more
different vendors are involved).  Is everyone who needs a technical question
on IPsec answered expected to track down IPsec list members and ask them, like
I did recently when I needed an answer to a simple yes/no question?  What
happens when the last person who was involved in the IPsec design process
retires and there's no-one left to ask about all the stuff the spec doesn't
tell you?

To get back to the original point about including explanations and
implementation guidance in specs, a spec is difficult now and downright
dangerous in the future when there's no-one left to explain all the bits the
authors never bothered writing down.  Consider as a nice counterexample the
DNS SRV spec.  It starts with the usual MUST/SHOULD/MAY stuff.  All the
features are clearly explained (not just "It does X" but "It does X because
Y").  There's advice for administrators.  There's pseudocode for certain
processes that people might find confusing.  There's a complete worked example
(I cut & pasted it into a zone file for testing).  You can implement it
straight out of the spec in about half an hour (OK, it's nowhere near as
complex as IPsec), and it works the first time.  With every server I could
find (and that's definitely nothing like IPsec).

The reason why it did that is because the authors didn't start by deciding
"We're not going to write a DNS for dummies", but because they wrote a spec
for implementors and users, which is why anyone can pick it up and write a
fully functional, interoperable DNS SRV implementation from it.  Can you do 
that with IPsec, or PKIX?

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5De0ib041888 for <[e-mail]>; Fri, 5 Dec 2003 05:40:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5De00U041887 for ietf-pkix-bks; Fri, 5 Dec 2003 05:40:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Ddvib041879 for <[e-mail]>; Fri, 5 Dec 2003 05:39:58 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 2FE713405A; Sat,  6 Dec 2003 02:39:40 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hB5Ddus06553; Sat, 6 Dec 2003 02:39:56 +1300
Date: Sat, 6 Dec 2003 02:39:56 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Certificate Policy Standardization
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 wrote:

>The feeling here was that a ToS-style policy might violate (at least NZ)
>consumer protection legislation, however since a number of large
>organisations relied on these types of agreements there would probably be a
>spirited defence of them in court and/or existing case law upholding them.

I've now checked this with a lawyer to see what the story is.  Disclaimer: Not
legal advice, merely an informal chat, and since it's been filtered through a
non-lawyer (me) it's even less legally useful.  Anyway, it pretty much follows
what I said earlier: It's a grey area (meaning that few have ever tried to
challenge it so there's not much precedent), but widely used in many parts of
the world.  For example when you sign up as an Oracle development partner you
get a short paper document to sign, and that refers you to a much longer
online document that you're expected to check regularly ("say, once a month,
although no-one does").  This is probably the closest real-world analogy to
the cert policy extension and policy URL, and has presumably undergone
intensive scrutiny by lawyers working for some fairly serious players on both
sides of the equation.  The one thing you'd have to do (at least to keep a NZ
court happy) is notify users of changes, for example by sending them email to
tell them to check the online T&C (terms and conditions), although I forgot to
ask whether you could get away with a "Our T&C have changed", a "The privacy
section of our T&C has changed", or a full "These exact changes have been made
to our T&C".  So my original comments:

  So what you do is define a policy OID that points to whatever the policy is
  this week, and if you need to change anything you alter your policy, which
  customers are expected to check by downloading it from an undocumented
  location in an LDAP directory on a server in a locked filing cabinet in a
  disused lavatory in the cellar with a sign on the door saying "Beware of the
  Leopard", as explained in section 43, subsection 18, clause 4(a).13,
  paragraph 227.a of said policy.  The policy extension seems almost designed
  for this use, it has provisions for specifying an OID and a means of
  pointing to the policy of the week, which is just what you need.

  The reason why this is approach is used is that if you changed your OID when
  your policy changes, you'd have to re-issue all your certs, which no-one
  wants to do.  So you define your policy to be a mutable object, push
  responsibility for checking for changes onto the user in the standard
  manner, and you're set.

still stand, you just need to apply the appropriate amount of legal time to
get it set up in a satisfactory manner.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Chlib038856 for <[e-mail]>; Fri, 5 Dec 2003 04:43:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5ChlLg038855 for ietf-pkix-bks; Fri, 5 Dec 2003 04:43:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Chkib038848 for <[e-mail]>; Fri, 5 Dec 2003 04:43:46 -0800 (PST) (envelope-from [e-mail])
Received: from host213-122-69-45.in-addr.btopenworld.com ([213.122.69.45] helo=LiaquatDELL) by rhenium.btinternet.com with esmtp (Exim 3.22 #25) id 1ASFJ4-0001av-00; Fri, 05 Dec 2003 12:43:39 +0000
Reply-To: <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: "'David Engberg'" <[e-mail]>
Cc: "'Ryan M. Hurst'" <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 12:43:27 -0000
Message-ID: <003501c3bb2d$65ca8740$e8a47ad5@LiaquatDELL>
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.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

It's interesting what you say about "one-size-fits-all".  My view is you
have to look at things from the RPs point of view, i.e. as a relying
party, I only care what's best for me.  Therefore either nonces are
important to me or they are not (I don't particularly care whether OCSP
responder's support them or not).  

Therefore from a RP perspective a single security policy is probably
want you do want.  Also from a security perspective, you don't want to
make special cases unless you think that communication between that
particular server is secure against such threats and hence the
protection is not required.  

I think it is sufficient to make OCSP clients configurable on whether to
include a nonce or not (since the protocol already identifies it as an
optional item) and then leave it up the local administrator to define
what suits them according to their local security policy.  I should add
though that if you include a nonce in the request you MUST reject a
response if it doesn't include a nonce (or a correct one).  

Regards,
LK


-----Original Message-----
From: David Engberg [mailto:[e-mail]] 
Sent: 05 December 2003 12:15
To: [e-mail]
Cc: 'Ryan M. Hurst'; 'Florian Oelmaier'; [e-mail]
Subject: Re: DISCUSS: MUST reject in OCSPv1


I agree that this is not a current problem that many people are seeing, 
because current OCSP use is primarily limited to small "internal" 
deployments where a one-size-fits-all security policy isn't an issue. 
 If I'm only ever hitting one OCSP responder, a "require nonces from all

servers" policy may be fine.

On the other hand, when people start using OCSP for real-world 
interoperability, the nonce-related options in all existing clients will

likely be too limited.  For example, if ACME Amalgamated installs CAPI 
clients for its internal PKI users that are configured to "require 
nonces from every server," this client will immediately act up when apps

try to verify SSL certs from Verisign if Verisign were to deploy a 
cache-based infrastructure.

Without a spec refinement to handle the broader interopability case, 
most people will probably just turn off nonce support across the board 
rather than trying to reconcile their internal PKI with external ones 
that they interoperate with.  Since I think nonces are actually negative

for security on balance, I'm fine with this result, but I don't think 
this is the desired goal of everyone involved.


Liaquat Khan wrote:

>The situation "we would like to have nonces in OCSP requests as
default,
>but if the server legitimately doesn't support nonces we are happy to
>forgo nonces or we will generate a fresh request without a nonce" is
not
>that common in my opinion.  If such a case does exist, local policy
will
>probably be also happy to choose to not include a nonce in the OCSP
>request message in the first place.
>
>  
>






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5CFHib037259 for <[e-mail]>; Fri, 5 Dec 2003 04:15:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5CFHxa037258 for ietf-pkix-bks; Fri, 5 Dec 2003 04:15:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5CFGib037249 for <[e-mail]>; Fri, 5 Dec 2003 04:15:17 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (sccrmhc13) with ESMTP id <20031205121511016001hdfme>; Fri, 5 Dec 2003 12:15:12 +0000
Received: from 138.sub-166-156-174.myvzw.com ([166.156.174.138] helo=corestreet.com) by localhost with asmtp (Exim 3.35 #1 (Debian)) id 1ASEtg-0000h2-00; Fri, 05 Dec 2003 07:17:25 -0500
Message-ID: <[e-mail]>
Date: Fri, 05 Dec 2003 07:15:21 -0500
From: David Engberg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: "'Ryan M. Hurst'" <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, [e-mail]
Subject: Re: DISCUSS: MUST reject in OCSPv1
References: <000c01c3bafc$ae734260$e8a47ad5@LiaquatDELL>
In-Reply-To: <000c01c3bafc$ae734260$e8a47ad5@LiaquatDELL>
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>

I agree that this is not a current problem that many people are seeing, 
because current OCSP use is primarily limited to small "internal" 
deployments where a one-size-fits-all security policy isn't an issue. 
 If I'm only ever hitting one OCSP responder, a "require nonces from all 
servers" policy may be fine.

On the other hand, when people start using OCSP for real-world 
interoperability, the nonce-related options in all existing clients will 
likely be too limited.  For example, if ACME Amalgamated installs CAPI 
clients for its internal PKI users that are configured to "require 
nonces from every server," this client will immediately act up when apps 
try to verify SSL certs from Verisign if Verisign were to deploy a 
cache-based infrastructure.

Without a spec refinement to handle the broader interopability case, 
most people will probably just turn off nonce support across the board 
rather than trying to reconcile their internal PKI with external ones 
that they interoperate with.  Since I think nonces are actually negative 
for security on balance, I'm fine with this result, but I don't think 
this is the desired goal of everyone involved.


Liaquat Khan wrote:

>The situation "we would like to have nonces in OCSP requests as default,
>but if the server legitimately doesn't support nonces we are happy to
>forgo nonces or we will generate a fresh request without a nonce" is not
>that common in my opinion.  If such a case does exist, local policy will
>probably be also happy to choose to not include a nonce in the OCSP
>request message in the first place.
>
>  
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5AUUib031179 for <[e-mail]>; Fri, 5 Dec 2003 02:30:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5AUUHn031178 for ietf-pkix-bks; Fri, 5 Dec 2003 02:30:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB5AURib031171 for <[e-mail]>; Fri, 5 Dec 2003 02:30:28 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 8214 invoked by uid 1649); 5 Dec 2003 10:30:22 -0000
Date: 5 Dec 2003 10:30:22 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: [e-mail]
CC: "'David Engberg'" <[e-mail]>, <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.41
X-Sender: [e-mail]
MIME-Version: 1.0
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 am concerned with the idea of making any change to the standard that
> "changes the 5 year old protocol".

I wholeheartly welcome the clarification and the change Russ proposed - but I am also concerned with interoperability issues.

Maybe we can keep the "old" nonce as it is and specify a new extension id for the new nonce? Then we can clarify that the "old" nonce is deprecated and that clients and servers should use the "new" nonce behaviour.

This way we can clarify the situation and simultaneous maintain compatibility.  

-- 
Florian Oelmaier
SyTrust
 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB59CNib015014 for <[e-mail]>; Fri, 5 Dec 2003 01:12:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB59CMfO015010 for ietf-pkix-bks; Fri, 5 Dec 2003 01:12:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB59CDib014924 for <[e-mail]>; Fri, 5 Dec 2003 01:12:14 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 30F7034014; Fri,  5 Dec 2003 22:11:56 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hB59CA205534; Fri, 5 Dec 2003 22:12:10 +1300
Date: Fri, 5 Dec 2003 22:12:10 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: DN Encoding by UTF8String
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>

Masaki SHIMAOKA <[e-mail]> writes:

>Of course, when the UTF8String problem solves, all certificates issuedMUST
>use UTF8String encoding.

I was actually going to save this for 1/1/04 (since I get to ask it before
anyone else does), but as a follow-up to the above I may as well ask it now:

  How many CAs are actually going to switch their certs to UTF8 next month?
  Anyone?

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB58LCib097630 for <[e-mail]>; Fri, 5 Dec 2003 00:21:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB58LCFO097629 for ietf-pkix-bks; Fri, 5 Dec 2003 00:21:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zinc.btinternet.com (zinc.btinternet.com [194.73.73.148]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB58LBib097612 for <[e-mail]>; Fri, 5 Dec 2003 00:21:11 -0800 (PST) (envelope-from [e-mail])
Received: from host213-122-164-232.in-addr.btopenworld.com ([213.122.164.232] helo=LiaquatDELL) by zinc.btinternet.com with esmtp (Exim 3.22 #25) id 1ASBD0-0003IB-00; Fri, 05 Dec 2003 08:21:07 +0000
Reply-To: <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, "'David Engberg'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 08:20:53 -0000
Message-ID: <001701c3bb08$b7923250$e8a47ad5@LiaquatDELL>
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.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <000c01c3bafc$ae734260$e8a47ad5@LiaquatDELL>
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>

Ooops...in 4th paragraph below, I meant to say "outgoing requests"
instead of "outgoing responses".
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Liaquat Khan
Sent: 05 December 2003 06:55
To: 'Ryan M. Hurst'; 'Florian Oelmaier'; 'David Engberg';
[e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1


Ryan,

We also agree with your viewpoint, particular the point about a nonce
being a matter for local client policy.  

In the various OCSP clients we have, the option of whether to include
nonce or not in the request message is left to local policy (i.e. the
administrator can configure whether or not nonce is included in the
request message). 

If the administrator decides nonces are necessary (to prevent replays)
then he/she will select these and our OCSP clients will include these in
the requests.  Now if an OCSP response is received back without a nonce
it will be rejected by our OCSP clients.

On the other hand, if the administrator feels nonces are not required
(to allow for cached responses) then he/she will not select to include
one in outgoing responses. 

The situation "we would like to have nonces in OCSP requests as default,
but if the server legitimately doesn't support nonces we are happy to
forgo nonces or we will generate a fresh request without a nonce" is not
that common in my opinion.  If such a case does exist, local policy will
probably be also happy to choose to not include a nonce in the OCSP
request message in the first place.

Regards,
Liaquat

Ascertia Limited, Orchard Building, Royal Holloway, Egham, Surrey, TW20
OEX
tel: [phone], fax: [phone], mobile: [phone]
308766
website: www.ascertia.com


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1


I am concerned with the idea of making any change to the standard that
"changes the 5 year old protocol".

This is particularly true since I don't see anyone on the list saying
this NonceUnsupported is needed, just that they would accept it.

I still think what is done with the nonce is a matter of local (client)
policy, and that if replay protection is desired responses not
containing the requested nonce MUST be rejected.

But since I appear to be odd man out on this, I would rather see us fall
back to Russ's original recommendation of MUST reject than break a 5
year old standard. 

Ryan
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1



> I like the elegance of Russ and Florian's ideas for securely
signalling 
> that a server doesn't support nonces by using a special value for the 
> nonce in replies.  This seems like the "right" place to put this
message 
> to the client.

Just for the record: I think you are referring to our server-generated
nonces when you talk about "Florian's idea". And while Russel is
signalling "NonceUnsupported" with a special nonce-value, we are
singalling "NonceSupported" with the inclusion of a nonce into every
request (mirrored from the request or server-generated). Thus we are not
subject to the attack you mention, as this does not need any additional
code in any existing client.

Russ proposal is a change in the protocol. Thus we need to update all
the clients and servers out there. Seeing that the proposed change is
needed and recognizing it as a good solution, I would accept this. 

-- 
Florian Oelmaier
SyTrust








Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB578Nib075353 for <[e-mail]>; Thu, 4 Dec 2003 23:08:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB578NMv075352 for ietf-pkix-bks; Thu, 4 Dec 2003 23:08:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan01.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB578Kib075332 for <[e-mail]>; Thu, 4 Dec 2003 23:08:21 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 29813 invoked by alias); 5 Dec 2003 07:08:22 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 29789 invoked by alias); 5 Dec 2003 07:08:21 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 5 Dec 2003 07:08:21 -0000
Received: (qmail 21660 invoked from network); 5 Dec 2003 07:08:20 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 5 Dec 2003 07:08:20 -0000
Date: Fri, 05 Dec 2003 16:09:10 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: DN Encoding by UTF8String
Cc: IETF-PKIX <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
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>

Dear Authors and WG Chairs,

RFC3280 mentioned that "all certificates issued after Dec 31, 2003 MUST
use UTF8String encoding".

However, it seems that some applications do not yet support UTF8String
respectably and the detail of name comparison rule does not consider
UTF8String sufficiently.

Therefore, existing CAs using except UTF8String for DN encoding SHOULD
do the following actions until solving these UTF8String problem.

    An encoding for issuer field of the certificates issued after 2004
    SHOULD be same as an encoding for subject field of CA certificate
    already issued.

Is this correct?

Of course, when the UTF8String problem solves, all certificates
issuedMUST use UTF8String encoding.
I worry that some confused CAs issue wrong certificates using UTF8String
encoding forcibly, even though the CA had used another encoding till now.

Best regards,
-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB56t4ib069094 for <[e-mail]>; Thu, 4 Dec 2003 22:55:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB56t4ht069093 for ietf-pkix-bks; Thu, 4 Dec 2003 22:55:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB56t3ib069044 for <[e-mail]>; Thu, 4 Dec 2003 22:55:03 -0800 (PST) (envelope-from [e-mail])
Received: from host213-122-164-232.in-addr.btopenworld.com ([213.122.164.232] helo=LiaquatDELL) by gadolinium.btinternet.com with esmtp (Exim 3.22 #25) id 1AS9rd-0005hC-00; Fri, 05 Dec 2003 06:54:58 +0000
Reply-To: <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, "'David Engberg'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 06:54:43 -0000
Message-ID: <000c01c3bafc$ae734260$e8a47ad5@LiaquatDELL>
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.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

Ryan,

We also agree with your viewpoint, particular the point about a nonce
being a matter for local client policy.  

In the various OCSP clients we have, the option of whether to include
nonce or not in the request message is left to local policy (i.e. the
administrator can configure whether or not nonce is included in the
request message). 

If the administrator decides nonces are necessary (to prevent replays)
then he/she will select these and our OCSP clients will include these in
the requests.  Now if an OCSP response is received back without a nonce
it will be rejected by our OCSP clients.

On the other hand, if the administrator feels nonces are not required
(to allow for cached responses) then he/she will not select to include
one in outgoing responses. 

The situation "we would like to have nonces in OCSP requests as default,
but if the server legitimately doesn't support nonces we are happy to
forgo nonces or we will generate a fresh request without a nonce" is not
that common in my opinion.  If such a case does exist, local policy will
probably be also happy to choose to not include a nonce in the OCSP
request message in the first place.

Regards,
Liaquat

Ascertia Limited, Orchard Building, Royal Holloway, Egham, Surrey, TW20
OEX
tel: [phone], fax: [phone], mobile: [phone]
308766
website: www.ascertia.com


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1


I am concerned with the idea of making any change to the standard that
"changes the 5 year old protocol".

This is particularly true since I don't see anyone on the list saying
this NonceUnsupported is needed, just that they would accept it.

I still think what is done with the nonce is a matter of local (client)
policy, and that if replay protection is desired responses not
containing the requested nonce MUST be rejected.

But since I appear to be odd man out on this, I would rather see us fall
back to Russ's original recommendation of MUST reject than break a 5
year old standard. 

Ryan
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1



> I like the elegance of Russ and Florian's ideas for securely
signalling 
> that a server doesn't support nonces by using a special value for the 
> nonce in replies.  This seems like the "right" place to put this
message 
> to the client.

Just for the record: I think you are referring to our server-generated
nonces when you talk about "Florian's idea". And while Russel is
signalling "NonceUnsupported" with a special nonce-value, we are
singalling "NonceSupported" with the inclusion of a nonce into every
request (mirrored from the request or server-generated). Thus we are not
subject to the attack you mention, as this does not need any additional
code in any existing client.

Russ proposal is a change in the protocol. Thus we need to update all
the clients and servers out there. Seeing that the proposed change is
needed and recognizing it as a good solution, I would accept this. 

-- 
Florian Oelmaier
SyTrust






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB51f8ib036551 for <[e-mail]>; Thu, 4 Dec 2003 17:41:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB51f8Wi036550 for ietf-pkix-bks; Thu, 4 Dec 2003 17:41:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB51f4ib036500 for <[e-mail]>; Thu, 4 Dec 2003 17:41:04 -0800 (PST) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Dec 2003 17:40:56 -0800
Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 04 Dec 2003 17:41:07 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 4 Dec 2003 17:41:01 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 4 Dec 2003 17:40:51 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 4 Dec 2003 17:41:00 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Thu, 4 Dec 2003 17:40:57 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS: MUST reject in OCSPv1
thread-index: AcO6XCvOonbEzH19QoSp25QLwIWKcwAdCBMQ
From: "Ryan M. Hurst" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "David Engberg" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 05 Dec 2003 01:41:00.0038 (UTC) FILETIME=[D5DB2A60:01C3BAD0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB51f4ib036544
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 concerned with the idea of making any change to the standard that
"changes the 5 year old protocol".

This is particularly true since I don't see anyone on the list saying
this NonceUnsupported is needed, just that they would accept it.

I still think what is done with the nonce is a matter of local (client)
policy, and that if replay protection is desired responses not
containing the requested nonce MUST be rejected.

But since I appear to be odd man out on this, I would rather see us fall
back to Russ's original recommendation of MUST reject than break a 5
year old standard. 

Ryan
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1



> I like the elegance of Russ and Florian's ideas for securely
signalling 
> that a server doesn't support nonces by using a special value for the 
> nonce in replies.  This seems like the "right" place to put this
message 
> to the client.

Just for the record: I think you are referring to our server-generated
nonces when you talk about "Florian's idea". And while Russel is
signalling "NonceUnsupported" with a special nonce-value, we are
singalling "NonceSupported" with the inclusion of a nonce into every
request (mirrored from the request or server-generated). Thus we are not
subject to the attack you mention, as this does not need any additional
code in any existing client.

Russ proposal is a change in the protocol. Thus we need to update all
the clients and servers out there. Seeing that the proposed change is
needed and recognizing it as a good solution, I would accept this. 

-- 
Florian Oelmaier
SyTrust




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4MoZib030094 for <[e-mail]>; Thu, 4 Dec 2003 14:50:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4MoZf6030093 for ietf-pkix-bks; Thu, 4 Dec 2003 14:50:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4MoYib030088 for <[e-mail]>; Thu, 4 Dec 2003 14:50:34 -0800 (PST) (envelope-from [e-mail])
Received: from ebola.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with ESMTP; Thu, 4 Dec 2003 17:50:36 -0500
Received: from sdtihq24.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.12.10/NULL) with ESMTP id hB4MoV1i013486 for <[e-mail]>; Thu, 4 Dec 2003 17:50:31 -0500 (EST)
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.100.8.217]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id hB4MoOsj019616 for <[e-mail]>; Thu, 4 Dec 2003 17:50:34 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2657.72) id <W335KLQY>; Thu, 4 Dec 2003 17:50:12 -0500
Received: from mnystrom-lap ([10.100.100.5]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id W4Q49A59; Thu, 4 Dec 2003 14:50:17 -0800
From: "Nystrom, Magnus" <[e-mail]>
Reply-To: "Nystrom, Magnus" <[e-mail]>
To: [e-mail]
Date: Thu, 4 Dec 2003 17:50:05 -0500 (Eastern Standard Time)
Subject: RE: DISCUSS: MUST reject in OCSPv1
Message-ID: <Pine.WNT.4.58.0312041747260.2572@mnystrom-lap>
X-X-Sender: [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>

Russ wrote:

[...]

> Rather than defining a new extension, called nonceUnsupported, you have
> the opportunity to specify a syntax to go with this OID that does the
> same thing.  Something like:
>
>     OCSPNonce ::= CHOICE {
>        nonceValue  OCTET STRING,
>        unsupported  NULL }

Unfortunately, this would break compatibility with clients supporting RFC
3546 (see Section 3.6 in that document).

-- Magnus


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4KeUib022679 for <[e-mail]>; Thu, 4 Dec 2003 12:40:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4KeUXq022678 for ietf-pkix-bks; Thu, 4 Dec 2003 12:40:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4KeRib022672 for <[e-mail]>; Thu, 4 Dec 2003 12:40:28 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13562; Thu, 4 Dec 2003 15:40:14 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-acpolicies-extn-05.txt
Date: Thu, 04 Dec 2003 15:40:13 -0500
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		: Attribute Certificate Policies extension
	Author(s)	: C. Francis, D. Pinkas
	Filename	: draft-ietf-pkix-acpolicies-extn-05.txt
	Pages		: 10
	Date		: 2003-12-4
	
This document describes one certificate extension to explicitly 
state the Attribute Certificate (AC) policies that apply to a given 
Attribute Certificate.  The goal of this document is to allow relying 
parties to perform an additional test when validating an AC, i.e. to 
assess whether a given AC carrying some attributes can be accepted on 
the basis of references to one or more specific AC policies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-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-acpolicies-extn-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-acpolicies-extn-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-acpolicies-extn-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-acpolicies-extn-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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4K8cib020838 for <[e-mail]>; Thu, 4 Dec 2003 12:08:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4K8cql020837 for ietf-pkix-bks; Thu, 4 Dec 2003 12:08:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4K8aib020830 for <[e-mail]>; Thu, 4 Dec 2003 12:08:37 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id VAA16644 for <[e-mail]>; Thu, 4 Dec 2003 21:15:25 +0100
Received: from bull.net (frclint79.bull.fr [129.181.81.79]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id VAA30540 for <[e-mail]>; Thu, 4 Dec 2003 21:03:57 +0100
Message-ID: <[e-mail]>
Date: Thu, 04 Dec 2003 21:08:18 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: RFC3039bis last call ?
Content-Type: text/plain; charset=windows-1252; format=flowed
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 probably missed the e-mail about an RFC3039bis last call, but since it 
is mentioned in the WG minutes that there will be a last call. In case 
it is already going, I would like to reiterate that the concerns I 
raised before the Minneapolis meeting are still valid.

In particular, I would like to reinsist on two points:

RFC3039 states in the abstract:

This document forms a certificate profile for Qualified Certificates,
based on RFC 2459, for use in the Internet. The term Qualified
Certificate is used to describe a certificate with a certain
qualified status within applicable governing law.

RFC3039bis states in the abstract:

This document forms a certificate profile, based on RFC 3280, for
identity certificates issued to physical persons.

It is clear from the abstract that the topic of the two documents are 
different and that the new draft should be renamed: Identity 
Certificates Profile.

As a consequence, this new draft is NOT a replacement for RFC 3039. One 
argument has been that ETSI needed changes to RFC 3039. There is not 
such a requirement from ETSI.

Another major issue is that RFC3039bis states:

Key usage settings SHALL be set in accordance with RFC 3280 definitions.

We know that the key usage bit section of RFC 3280 is going to be 
changed. However we still don't know what will be the new text. 
Discussions are going on within ISO SC6 both to redefine bit 0 in terms 
of the security services it may support (instead of saying “all security 
services except one security service”), and to rename bit 1. This means 
that referencing RFC 3280 is fine, except for the section on the key 
usage bits.

Qualified Certificates are to be used when a signer wants to commit to 
the content of a document, not when a signer wants to authenticate. As 
it is, the new draft would create confusion.

Denis





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4GUgib010629 for <[e-mail]>; Thu, 4 Dec 2003 08:30:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4GUgGM010628 for ietf-pkix-bks; Thu, 4 Dec 2003 08:30:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB4GUfib010623 for <[e-mail]>; Thu, 4 Dec 2003 08:30:41 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 15157 invoked by uid 0); 4 Dec 2003 16:30:17 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.168.12) by woodstock.binhost.com with SMTP; 4 Dec 2003 16:30:17 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 04 Dec 2003 11:24:28 -0500
To: "Manger, James H" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
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:

I used the SNACC compliler (with the DigitalNet enhancements).

I changed the nullOcetString line to:

    nullOctetString  OCTET STRING (SIZE (0))  ::=  ''H

And, it compiler fine too.  Based on your research, I assume that SNACC is 
being forgiving in this situation.  We will change it in the next version 
of the Internet Draft.

Russ


At 11:18 AM 12/4/2003 +1000, Manger, James H wrote:

>Russ,
>
>I still think I am right.  Does your compiler compile complex values, or 
>just types?
>
>Very early versions of ASN.1 (X.208 1998/1990?) may have allowed the 
>identifier (field name) to be omitted, but subsequent versions (X.680 
>1994/...) corrected this to avoid ambiguities.  Perhaps you have a lenient 
>compiler (nice sometimes, but not when writing standards).
>
>Much of draft-ietf-pkix-rsa-pkalgs-01.txt is based on PKCS #1 v2.1 where 
>the ASN.1 is correct: it includes identifiers & type name and there are no 
>squiggly brackets {} around octet string values.
>
>
>Extracts from sections 24.17, 16.13, 22.3 & 11.12.1 of X.680 ASN.1 (2002):
>
>         SequenceValue ::=
>                   "{" ComponentValueList "}"
>                 | "{" "}"
>
>         ComponentValueList ::=
>                   NamedValue
>                 | ComponentValueList "," NamedValue
>
>         NamedValue = identifier Value
>
>         NOTE- The "identifier" is part of the notation,
>         it does not form part of the value itself.
>         It is used to unambiguously refer to the components
>         of a set type, sequence type or choice type.
>
>         OctetStringValue ::=
>                   bstring
>                 | hstring
>                 | CONTAINING Value
>
>         .. "hstring" ..
>                 EXAMPLE- 'AB0196'H
>
>
>Extracts from sections D.2 of X.681 ASN.1 Information object spec (2002):
>
>         ExampleType ::= SEQUENCE {
>                 openTypeComponent1  EXAMPLE-CLASS.&TypeField,
>                 integerComponent1   EXAMPLE-CLASS.&fixedTypeValueField,
>                 openTypeComponent2  EXAMPLE-CLASS.&variableTypeValueField,
>                 integerComponent2   EXAMPLE-CLASS.&FixedTypeValueSetField,
>                 openTypeComponent3  EXAMPLE-CLASS.&VariableTypeValueSetField
>         }
>         exampleValue ExampleType ::= {
>                 openTypeComponent1      BOOLEAN : TRUE,
>                 integerComponent1               123,
>                 openTypeComponent2      IA5String : "abcdef",
>                 integerComponent2               456,
>                 openTypeComponent3      BIT STRING : '0101010101'B
>         }
>
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Thursday, 4 December 2003 6:05 AM
>To: Manger, James H; [e-mail]
>Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1
>typos
>
>
>James:
>
>After changing:
>        sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 XX }
>to:
>        sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }
>
>The module compiles fine for me.
>
>Russ
>
>At 09:54 AM 12/3/2003 +1000, Manger, James H wrote:
>
> >The ASN.1 module in draft-ietf-pkix-rsa-pkalgs-01.txt has some typos.
> >
> >1.
> >When specifying ASN.1 values the field names must be included.  When
> >specifying open type values the type must be specified.  For instance:
> >
> >WRONG:
> >         sha1Identifier AlgorithmIdentifier ::=
> >                 { id-sha1, NULL }
> >
> >RIGHT:
> >         sha1Identifier AlgorithmIdentifier ::=
> >                 { algorithm id-sha1, parameters NULL:NULL }
> >
> >These errors affect all 31 values of the following types:
> >AlgorithmIdentifier, RSASSA-PSS-params & RSAES-OAEP-params.
> >
> >
> >2.
> >In section 4.1 and in the ASN.1 module:
> >WRONG:  nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
> >RIGHT:  nullOctetString OCTET STRING (SIZE (0)) ::= ''H
> >
> >----------
> >From: [e-mail] [mailto:[e-mail]]
> >Sent: Wednesday, 3 December 2003 7:36 AM
> >
> >         Title           : Additional Algorithms and Identifiers for RSA
> >                           Cryptography for use in the Internet X.509
> >                           Public Key Infrastructure Certificate and
> >                           Certificate Revocation List (CRL) Profile
> >         Author(s)       : R. Housley, B. Kaliski
> >         Filename        : draft-ietf-pkix-rsa-pkalgs-01.txt
> >         Pages           : 22
> >         Date            : 2003-12-2
> >
> >This document supplements RFC 3279.  It describes the conventions for
> >using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport
> >algorithm, and additional one-way hash functions with the PKCS #1 version
> >1.5 signature algorithm in the Internet X.509 Public Key Infrastructure
> >(PKI).  Encoding formats, algorithm identifiers, and parameter formats are
> >specified.
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-01.txt



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4EJPib003959 for <[e-mail]>; Thu, 4 Dec 2003 06:19:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4EJPmw003958 for ietf-pkix-bks; Thu, 4 Dec 2003 06:19:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB4EJNib003950 for <[e-mail]>; Thu, 4 Dec 2003 06:19:23 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 13855 invoked by uid 1649); 4 Dec 2003 14:19:23 -0000
Date: 4 Dec 2003 14:19:23 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: [e-mail]
CC: David Engberg <[e-mail]>
Subject: Re: DISCUSS: MUST reject in OCSPv1
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.41
X-Sender: [e-mail]
MIME-Version: 1.0
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>

> Florian -
> 
> Sorry, my misunderstanding.  I think that your strategy is also good if 
> both the client and server implement it, but it sounds like your clients 
> would have the same backward-compatibility problem if talking to someone 
> else's old servers.  I.e. an attacker could send a nonceless request to 
> an old existing server and record the nonceless response, and then 
> replay that to your client to make you think that that server is 
> securely signalling that it doesn't support nonces.

/agree. Thats completely correct. 

The difference is that our strategy does not require new clients as it does not require anything "new" on the client side. But you are right, if a client talks to an "old" server the attack described is as feasible as with Russ´ proposal. Only "new" servers can prevent this type of attack in both proposals. My bad, sorry.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4DPWib001005 for <[e-mail]>; Thu, 4 Dec 2003 05:25:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4DPWHg001004 for ietf-pkix-bks; Thu, 4 Dec 2003 05:25:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4DPUib000993 for <[e-mail]>; Thu, 4 Dec 2003 05:25:30 -0800 (PST) (envelope-from [e-mail])
Received: from user-10lfcae.cable.mindspring.com ([65.87.177.78] helo=asn-1.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1ARtTx-00032Z-00 for [e-mail]; Thu, 04 Dec 2003 08:25:25 -0500
Message-ID: <[e-mail]>
Date: Thu, 04 Dec 2003 08:25:30 -0500
From: "Phillip H. Griffin" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 (VAUSSU03)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------080700000904010202030503"
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>

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

X.208 and X.209 are no longer merely deprecated. They have been
withdrawn as international standards since last year. From
http://www.itu.int/ITU-T/studygroups/com17/changing-ASN/migration.html

"The term ASN.1:1988/1990 notation is used to refer to that ASN.1
notation specified in CCITT Rec. X.208 which was withdrawn in 2002.

Phil


Manger, James H wrote:

>Russ,
>
>I still think I am right.  Does your compiler compile complex values, or just types?
>
>Very early versions of ASN.1 (X.208 1998/1990?) may have allowed the identifier (field name) to be omitted, but subsequent versions (X.680 1994/...) corrected this to avoid ambiguities.  Perhaps you have a lenient compiler (nice sometimes, but not when writing standards).
>
>Much of draft-ietf-pkix-rsa-pkalgs-01.txt is based on PKCS #1 v2.1 where the ASN.1 is correct: it includes identifiers & type name and there are no squiggly brackets {} around octet string values.
>
>
>Extracts from sections 24.17, 16.13, 22.3 & 11.12.1 of X.680 ASN.1 (2002):
>
>	SequenceValue ::=
>		  "{" ComponentValueList "}"
>		| "{" "}"
>
>	ComponentValueList ::=
>		  NamedValue
>		| ComponentValueList "," NamedValue
>
>	NamedValue = identifier Value
>
>	NOTE- The "identifier" is part of the notation,
>	it does not form part of the value itself.
>	It is used to unambiguously refer to the components
>	of a set type, sequence type or choice type.
>
>	OctetStringValue ::=
>		  bstring
>		| hstring
>		| CONTAINING Value
>
>	.. "hstring" ..
>		EXAMPLE- 'AB0196'H
>
>
>Extracts from sections D.2 of X.681 ASN.1 Information object spec (2002):
>
>	ExampleType ::= SEQUENCE {
>		openTypeComponent1  EXAMPLE-CLASS.&TypeField,
>		integerComponent1   EXAMPLE-CLASS.&fixedTypeValueField,
>		openTypeComponent2  EXAMPLE-CLASS.&variableTypeValueField,
>		integerComponent2   EXAMPLE-CLASS.&FixedTypeValueSetField,
>		openTypeComponent3  EXAMPLE-CLASS.&VariableTypeValueSetField
>	}
>	exampleValue ExampleType ::= {
>		openTypeComponent1	BOOLEAN : TRUE,
>		integerComponent1		123,
>		openTypeComponent2	IA5String : "abcdef",
>		integerComponent2		456,
>		openTypeComponent3	BIT STRING : '0101010101'B
>	}
>
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Thursday, 4 December 2003 6:05 AM
>To: Manger, James H; [e-mail]
>Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1
>typos
>
>
>James:
>
>After changing:
>       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 XX }
>to:
>       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }
>
>The module compiles fine for me.
>
>Russ
>
>At 09:54 AM 12/3/2003 +1000, Manger, James H wrote:
>
>  
>
>>The ASN.1 module in draft-ietf-pkix-rsa-pkalgs-01.txt has some typos.
>>
>>1.
>>When specifying ASN.1 values the field names must be included.  When 
>>specifying open type values the type must be specified.  For instance:
>>
>>WRONG:
>>        sha1Identifier AlgorithmIdentifier ::=
>>                { id-sha1, NULL }
>>
>>RIGHT:
>>        sha1Identifier AlgorithmIdentifier ::=
>>                { algorithm id-sha1, parameters NULL:NULL }
>>
>>These errors affect all 31 values of the following types: 
>>AlgorithmIdentifier, RSASSA-PSS-params & RSAES-OAEP-params.
>>
>>
>>2.
>>In section 4.1 and in the ASN.1 module:
>>WRONG:  nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
>>RIGHT:  nullOctetString OCTET STRING (SIZE (0)) ::= ''H
>>
>>----------
>>From: [e-mail] [mailto:[e-mail]]
>>Sent: Wednesday, 3 December 2003 7:36 AM
>>
>>        Title           : Additional Algorithms and Identifiers for RSA
>>                          Cryptography for use in the Internet X.509
>>                          Public Key Infrastructure Certificate and
>>                          Certificate Revocation List (CRL) Profile
>>        Author(s)       : R. Housley, B. Kaliski
>>        Filename        : draft-ietf-pkix-rsa-pkalgs-01.txt
>>        Pages           : 22
>>        Date            : 2003-12-2
>>
>>This document supplements RFC 3279.  It describes the conventions for 
>>using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport 
>>algorithm, and additional one-way hash functions with the PKCS #1 version 
>>1.5 signature algorithm in the Internet X.509 Public Key Infrastructure 
>>(PKI).  Encoding formats, algorithm identifiers, and parameter formats are 
>>specified.
>>
>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-01.txt
>>    
>>
>
>
>
>
>  
>


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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
X.208 and X.209 are no longer merely deprecated. They have been<br>
withdrawn as international standards since last year. From<br>
<a class="moz-txt-link-freetext" href="http://www.itu.int/ITU-T/studygroups/com17/changing-ASN/migration.html">http://www.itu.int/ITU-T/studygroups/com17/changing-ASN/migration.html</a><br>
<br>
"The term <b>ASN.1:1988/1990 notation</b> is used to refer to that ASN.1
<br>
notation specified in CCITT Rec. X.208 which was withdrawn in 2002.<br>
<br>
Phil<br>
<br>
<br>
Manger, James H wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">Russ,

I still think I am right.  Does your compiler compile complex values, or just types?

Very early versions of ASN.1 (X.208 1998/1990?) may have allowed the identifier (field name) to be omitted, but subsequent versions (X.680 1994/...) corrected this to avoid ambiguities.  Perhaps you have a lenient compiler (nice sometimes, but not when writing standards).

Much of draft-ietf-pkix-rsa-pkalgs-01.txt is based on PKCS #1 v2.1 where the ASN.1 is correct: it includes identifiers &amp; type name and there are no squiggly brackets {} around octet string values.


Extracts from sections 24.17, 16.13, 22.3 &amp; 11.12.1 of X.680 ASN.1 (2002):

	SequenceValue ::=
		  "{" ComponentValueList "}"
		| "{" "}"

	ComponentValueList ::=
		  NamedValue
		| ComponentValueList "," NamedValue

	NamedValue = identifier Value

	NOTE- The "identifier" is part of the notation,
	it does not form part of the value itself.
	It is used to unambiguously refer to the components
	of a set type, sequence type or choice type.

	OctetStringValue ::=
		  bstring
		| hstring
		| CONTAINING Value

	.. "hstring" ..
		EXAMPLE- 'AB0196'H


Extracts from sections D.2 of X.681 ASN.1 Information object spec (2002):

	ExampleType ::= SEQUENCE {
		openTypeComponent1  EXAMPLE-CLASS.&amp;TypeField,
		integerComponent1   EXAMPLE-CLASS.&amp;fixedTypeValueField,
		openTypeComponent2  EXAMPLE-CLASS.&amp;variableTypeValueField,
		integerComponent2   EXAMPLE-CLASS.&amp;FixedTypeValueSetField,
		openTypeComponent3  EXAMPLE-CLASS.&amp;VariableTypeValueSetField
	}
	exampleValue ExampleType ::= {
		openTypeComponent1	BOOLEAN : TRUE,
		integerComponent1		123,
		openTypeComponent2	IA5String : "abcdef",
		integerComponent2		456,
		openTypeComponent3	BIT STRING : '0101010101'B
	}


-----Original Message-----
From: Russ Housley [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
Sent: Thursday, 4 December 2003 6:05 AM
To: Manger, James H; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1
typos


James:

After changing:
       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 XX }
to:
       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }

The module compiles fine for me.

Russ

At 09:54 AM 12/3/2003 +1000, Manger, James H wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">The ASN.1 module in draft-ietf-pkix-rsa-pkalgs-01.txt has some typos.

1.
When specifying ASN.1 values the field names must be included.  When 
specifying open type values the type must be specified.  For instance:

WRONG:
        sha1Identifier AlgorithmIdentifier ::=
                { id-sha1, NULL }

RIGHT:
        sha1Identifier AlgorithmIdentifier ::=
                { algorithm id-sha1, parameters NULL:NULL }

These errors affect all 31 values of the following types: 
AlgorithmIdentifier, RSASSA-PSS-params &amp; RSAES-OAEP-params.


2.
In section 4.1 and in the ASN.1 module:
WRONG:  nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
RIGHT:  nullOctetString OCTET STRING (SIZE (0)) ::= ''H

----------
From: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
Sent: Wednesday, 3 December 2003 7:36 AM

        Title           : Additional Algorithms and Identifiers for RSA
                          Cryptography for use in the Internet X.509
                          Public Key Infrastructure Certificate and
                          Certificate Revocation List (CRL) Profile
        Author(s)       : R. Housley, B. Kaliski
        Filename        : draft-ietf-pkix-rsa-pkalgs-01.txt
        Pages           : 22
        Date            : 2003-12-2

This document supplements RFC 3279.  It describes the conventions for 
using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport 
algorithm, and additional one-way hash functions with the PKCS #1 version 
1.5 signature algorithm in the Internet X.509 Public Key Infrastructure 
(PKI).  Encoding formats, algorithm identifiers, and parameter formats are 
specified.

<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-01.txt</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->



  </pre>
</blockquote>
<br>
</body>
</html>

--------------080700000904010202030503--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4D89ib000454 for <[e-mail]>; Thu, 4 Dec 2003 05:08:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4D89DH000453 for ietf-pkix-bks; Thu, 4 Dec 2003 05:08:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4D88ib000445 for <[e-mail]>; Thu, 4 Dec 2003 05:08:08 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc12) with ESMTP id <2003120413080301400dlu4ne>; Thu, 4 Dec 2003 13:08:03 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1ARtFG-0000Lf-00; Thu, 04 Dec 2003 08:10:14 -0500
Message-ID: <[e-mail]>
Date: Thu, 04 Dec 2003 08:10:13 -0500
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Florian Oelmaier <[e-mail]>
CC: [e-mail]
Subject: Re: DISCUSS: MUST reject in OCSPv1
References: <> <[e-mail]>
In-Reply-To: <[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>

Florian -

Sorry, my misunderstanding.  I think that your strategy is also good if 
both the client and server implement it, but it sounds like your clients 
would have the same backward-compatibility problem if talking to someone 
else's old servers.  I.e. an attacker could send a nonceless request to 
an old existing server and record the nonceless response, and then 
replay that to your client to make you think that that server is 
securely signalling that it doesn't support nonces.

Does that make sense?


Florian Oelmaier wrote:
> Just for the record: I think you are referring to our server-generated nonces when you talk about "Florian's idea". And while Russel is signalling "NonceUnsupported" with a special nonce-value, we are singalling "NonceSupported" with the inclusion of a nonce into every request (mirrored from the request or server-generated). Thus we are not subject to the attack you mention, as this does not need any additional code in any existing client.
> 
> Russ proposal is a change in the protocol. Thus we need to update all the clients and servers out there. Seeing that the proposed change is needed and recognizing it as a good solution, I would accept this. 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4BPgib096216 for <[e-mail]>; Thu, 4 Dec 2003 03:25:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4BPgh0096215 for ietf-pkix-bks; Thu, 4 Dec 2003 03:25:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4BPeib096201 for <[e-mail]>; Thu, 4 Dec 2003 03:25:41 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA02275 for <[e-mail]>; Thu, 4 Dec 2003 12:25:35 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 4 Dec 2003 12:25:35 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id hB4BPYO10465 for [e-mail]; Thu, 4 Dec 2003 12:25:34 +0100 (MET)
Date: Thu, 4 Dec 2003 12:25:34 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
X-Sun-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>

 >     OCSPNonce ::= CHOICE {
 >        nonceValue  OCTET STRING,
 >        unsupported  NULL }

Another way may be 

nonceValue  OCTET STRING OPTIONAL -- unsupported if omitted. 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB49kfib088462 for <[e-mail]>; Thu, 4 Dec 2003 01:46:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB49kfPs088461 for ietf-pkix-bks; Thu, 4 Dec 2003 01:46:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB49kdib088414 for <[e-mail]>; Thu, 4 Dec 2003 01:46:39 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 9633 invoked by uid 1649); 4 Dec 2003 09:46:34 -0000
Date: 4 Dec 2003 09:46:34 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: David Engberg <[e-mail]>, [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.41
X-Sender: [e-mail]
MIME-Version: 1.0
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 like the elegance of Russ and Florian's ideas for securely signalling 
> that a server doesn't support nonces by using a special value for the 
> nonce in replies.  This seems like the "right" place to put this message 
> to the client.

Just for the record: I think you are referring to our server-generated nonces when you talk about "Florian's idea". And while Russel is signalling "NonceUnsupported" with a special nonce-value, we are singalling "NonceSupported" with the inclusion of a nonce into every request (mirrored from the request or server-generated). Thus we are not subject to the attack you mention, as this does not need any additional code in any existing client.

Russ proposal is a change in the protocol. Thus we need to update all the clients and servers out there. Seeing that the proposed change is needed and recognizing it as a good solution, I would accept this. 

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB48v1ib072391 for <[e-mail]>; Thu, 4 Dec 2003 00:57:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB48v1nQ072389 for ietf-pkix-bks; Thu, 4 Dec 2003 00:57:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB48uuib072091 for <[e-mail]>; Thu, 4 Dec 2003 00:57:00 -0800 (PST) (envelope-from [e-mail])
Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 09:55:59 +0100
Received: from francetelecom.com ([10.193.13.109]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 09:55:58 +0100
Message-ID: <[e-mail]>
Date: Thu, 04 Dec 2003 09:55:58 +0100
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom R&D
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Dec 2003 08:55:58.0506 (UTC) FILETIME=[6F5798A0:01C3BA44]
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 wrote:
 >
> ITU-T Recommendations X.208 & X.209 have been deleted
> (see http://www.itu.int/itudoc/itu-t/circ/01-04_1/130_ww9.doc).
> Referencing them in new internet-drafts hardly seems appropriate.
> Perhaps it is time PKIX started using X.680 instead.

Another argument is that the X.680 series can be downloaded for free from:
http://www.itu.int/ITU-T/studygroups/com17/languages/
-- 
Olivier DUBUISSON
france telecom R&D

DTL/TAL - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB444sib001059 for <[e-mail]>; Wed, 3 Dec 2003 20:04:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB444slZ001058 for ietf-pkix-bks; Wed, 3 Dec 2003 20:04:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from adacel.com (gunsmoke.adacel.com.au [210.11.130.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB444qib001046 for <[e-mail]>; Wed, 3 Dec 2003 20:04:53 -0800 (PST) (envelope-from [e-mail])
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id <B0001b701b>; Thu, 04 Dec 2003 14:56:34 +1100
Received: (qmail 13088 invoked from network); 4 Dec 2003 04:03:49 -0000
Received: from unknown (HELO adacel.com.au) (10.32.24.165) by nexus.adacel.com with SMTP; 4 Dec 2003 04:03:49 -0000
Message-ID: <[e-mail]>
Date: Thu, 04 Dec 2003 15:03:48 +1100
From: Steven Legg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3.1) Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: "'Manger, James H'" <[e-mail]>, [e-mail]
Subject: Re: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
References: <006f01c3ba16$80a7e700$[e-mail]>
In-Reply-To: <006f01c3ba16$80a7e700$[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>

Jim,

Jim Schaad wrote:
> James,
> 
> The PKIX working group requires that all ASN.1 be the 1988 version.  The
> changes you are claming as non-compliant are not required for the 1988
> version.

But they're not disallowed either. Why use a notation from 1988 which is
deprecated by later editions of ASN.1 when there is alternative notation
that is valid in 1988 and all later editions of ASN.1. ?

Regards,
Steven

> 
> jim
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Manger, James H
>>Sent: Wednesday, December 03, 2003 5:18 PM
>>To: [e-mail]
>>Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt 
>>- ASN.1 typos
>>
>>
>>
>>Russ,
>>
>>I still think I am right.  Does your compiler compile complex 
>>values, or just types?
>>
>>Very early versions of ASN.1 (X.208 1998/1990?) may have 
>>allowed the identifier (field name) to be omitted, but 
>>subsequent versions (X.680 1994/...) corrected this to avoid 
>>ambiguities.  Perhaps you have a lenient compiler (nice 
>>sometimes, but not when writing standards).
>>
>>Much of draft-ietf-pkix-rsa-pkalgs-01.txt is based on PKCS #1 
>>v2.1 where the ASN.1 is correct: it includes identifiers & 
>>type name and there are no squiggly brackets {} around octet 
>>string values.
>>
>>
>>Extracts from sections 24.17, 16.13, 22.3 & 11.12.1 of X.680 
>>ASN.1 (2002):
>>
>>	SequenceValue ::=
>>		  "{" ComponentValueList "}"
>>		| "{" "}"
>>
>>	ComponentValueList ::=
>>		  NamedValue
>>		| ComponentValueList "," NamedValue
>>
>>	NamedValue = identifier Value
>>
>>	NOTE- The "identifier" is part of the notation,
>>	it does not form part of the value itself.
>>	It is used to unambiguously refer to the components
>>	of a set type, sequence type or choice type.
>>
>>	OctetStringValue ::=
>>		  bstring
>>		| hstring
>>		| CONTAINING Value
>>
>>	.. "hstring" ..
>>		EXAMPLE- 'AB0196'H
>>
>>
>>Extracts from sections D.2 of X.681 ASN.1 Information object 
>>spec (2002):
>>
>>	ExampleType ::= SEQUENCE {
>>		openTypeComponent1  EXAMPLE-CLASS.&TypeField,
>>		integerComponent1   EXAMPLE-CLASS.&fixedTypeValueField,
>>		openTypeComponent2  
>>EXAMPLE-CLASS.&variableTypeValueField,
>>		integerComponent2   
>>EXAMPLE-CLASS.&FixedTypeValueSetField,
>>		openTypeComponent3  
>>EXAMPLE-CLASS.&VariableTypeValueSetField
>>	}
>>	exampleValue ExampleType ::= {
>>		openTypeComponent1	BOOLEAN : TRUE,
>>		integerComponent1		123,
>>		openTypeComponent2	IA5String : "abcdef",
>>		integerComponent2		456,
>>		openTypeComponent3	BIT STRING : '0101010101'B
>>	}
>>
>>
>>-----Original Message-----
>>From: Russ Housley [mailto:[e-mail]]
>>Sent: Thursday, 4 December 2003 6:05 AM
>>To: Manger, James H; [e-mail]
>>Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt 
>>- ASN.1 typos
>>
>>
>>James:
>>
>>After changing:
>>       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 XX }
>>to:
>>       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }
>>
>>The module compiles fine for me.
>>
>>Russ
>>
>>At 09:54 AM 12/3/2003 +1000, Manger, James H wrote:
>>
>>
>>>The ASN.1 module in draft-ietf-pkix-rsa-pkalgs-01.txt has some typos.
>>>
>>>1.
>>>When specifying ASN.1 values the field names must be included.  When
>>>specifying open type values the type must be specified.  For 
>>
>>instance:
>>
>>>WRONG:
>>>        sha1Identifier AlgorithmIdentifier ::=
>>>                { id-sha1, NULL }
>>>
>>>RIGHT:
>>>        sha1Identifier AlgorithmIdentifier ::=
>>>                { algorithm id-sha1, parameters NULL:NULL }
>>>
>>>These errors affect all 31 values of the following types:
>>>AlgorithmIdentifier, RSASSA-PSS-params & RSAES-OAEP-params.
>>>
>>>
>>>2.
>>>In section 4.1 and in the ASN.1 module:
>>>WRONG:  nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
>>>RIGHT:  nullOctetString OCTET STRING (SIZE (0)) ::= ''H
>>>
>>>----------
>>>From: [e-mail] [mailto:[e-mail]]
>>>Sent: Wednesday, 3 December 2003 7:36 AM
>>>
>>>        Title           : Additional Algorithms and 
>>
>>Identifiers for RSA
>>
>>>                          Cryptography for use in the Internet X.509
>>>                          Public Key Infrastructure Certificate and
>>>                          Certificate Revocation List (CRL) Profile
>>>        Author(s)       : R. Housley, B. Kaliski
>>>        Filename        : draft-ietf-pkix-rsa-pkalgs-01.txt
>>>        Pages           : 22
>>>        Date            : 2003-12-2
>>>
>>>This document supplements RFC 3279.  It describes the conventions for
>>>using the RSASSA-PSS signature algorithm, the RSAES-OAEP key 
>>
>>transport 
>>
>>>algorithm, and additional one-way hash functions with the 
>>
>>PKCS #1 version 
>>
>>>1.5 signature algorithm in the Internet X.509 Public Key 
>>
>>Infrastructure 
>>
>>>(PKI).  Encoding formats, algorithm identifiers, and 
>>
>>parameter formats are 
>>
>>>specified.
>>>
>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-01.txt
>>
>>
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB443cib001023 for <[e-mail]>; Wed, 3 Dec 2003 20:03:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB443cVl001022 for ietf-pkix-bks; Wed, 3 Dec 2003 20:03:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB443bib001016 for <[e-mail]>; Wed, 3 Dec 2003 20:03:37 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc13) with ESMTP id <2003120404033401500boae2e>; Thu, 4 Dec 2003 04:03:34 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1ARkkB-0000EM-00 for <[e-mail]>; Wed, 03 Dec 2003 23:05:35 -0500
Message-ID: <[e-mail]>
Date: Wed, 03 Dec 2003 23:05:30 -0500
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1
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>

I like the elegance of Russ and Florian's ideas for securely signalling 
that a server doesn't support nonces by using a special value for the 
nonce in replies.  This seems like the "right" place to put this message 
to the client.

We do have to keep in mind these approaches do still expose a replay 
potential when a "new" client that supports this system communicates 
with any "old" OCSP server that currently supports nonces.

Here's the attack:  Alice makes an OCSP request for her cert in the 
morning (when her cert is valid) with a nonce value of NULL (or whatever 
the special signalling value is).  All existing servers will return a 
response that includes this special value as the nonce, since they all 
just spit back the raw bytes of whatever nonce they receive.  Alice 
records the response.

In the afternoon, Bob makes a request to get the status of her cert, 
after she has been revoked.  Alice intercepts the request, replays the 
cached response, and Bob's new client thinks that the server is 
indicating that it doesn't support nonces, so he accepts the response 
anyway.

Sending the "nonce not supported" message from the server to the client 
through a separate new extension is a little more klunky, but it might 
be worth it to avoid any issues with backward compatibility.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB43uBib000717 for <[e-mail]>; Wed, 3 Dec 2003 19:56:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB43uBUO000716 for ietf-pkix-bks; Wed, 3 Dec 2003 19:56:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.ntcif.telstra.com.au ([202.12.233.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB43u9ib000707 for <[e-mail]>; Wed, 3 Dec 2003 19:56:10 -0800 (PST) (envelope-from [e-mail])
Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailbo.ntcif.telstra.com.au (Postfix) with ESMTP id EEAAC12D2C for <[e-mail]>; Thu,  4 Dec 2003 14:56:05 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 7D0D212983 for <[e-mail]>; Thu,  4 Dec 2003 14:56:05 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA22482 for <[e-mail]>; Thu, 4 Dec 2003 14:56:05 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Date: Thu, 4 Dec 2003 13:55:47 +1000
Message-ID: <[e-mail]>
Thread-Topic: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Thread-Index: AcO6FiRu2xa8xYEoSmyL+k9Lc066PgAA0AWA
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB43uAib000712
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>

ITU-T Recommendations X.208 & X.209 have been deleted
(see http://www.itu.int/itudoc/itu-t/circ/01-04_1/130_ww9.doc).
Referencing them in new internet-drafts hardly seems appropriate.
Perhaps it is time PKIX started using X.680 instead.

----------
From: Jim Schaad [mailto:[e-mail]]
Sent: Thursday, 4 December 2003 2:27 PM
To: Manger, James H; [e-mail]

The PKIX working group requires that all ASN.1 be the 1988 version.  The
changes you are claming as non-compliant are not required for the 1988
version.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB43OTib098743 for <[e-mail]>; Wed, 3 Dec 2003 19:24:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB43OTbe098742 for ietf-pkix-bks; Wed, 3 Dec 2003 19:24:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB43OSib098737 for <[e-mail]>; Wed, 3 Dec 2003 19:24:28 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (ip167.13-173-207.eli-du.nwlink.com [207.173.13.167]) by smtp2.pacifier.net (Postfix) with ESMTP id 7D3B36A9B0; Wed,  3 Dec 2003 19:24:25 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Manger, James H'" <[e-mail]>, <[e-mail]>
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Date: Wed, 3 Dec 2003 19:27:04 -0800
Message-ID: <006f01c3ba16$80a7e700$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

James,

The PKIX working group requires that all ASN.1 be the 1988 version.  The
changes you are claming as non-compliant are not required for the 1988
version.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Manger, James H
> Sent: Wednesday, December 03, 2003 5:18 PM
> To: [e-mail]
> Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt 
> - ASN.1 typos
> 
> 
> 
> Russ,
> 
> I still think I am right.  Does your compiler compile complex 
> values, or just types?
> 
> Very early versions of ASN.1 (X.208 1998/1990?) may have 
> allowed the identifier (field name) to be omitted, but 
> subsequent versions (X.680 1994/...) corrected this to avoid 
> ambiguities.  Perhaps you have a lenient compiler (nice 
> sometimes, but not when writing standards).
> 
> Much of draft-ietf-pkix-rsa-pkalgs-01.txt is based on PKCS #1 
> v2.1 where the ASN.1 is correct: it includes identifiers & 
> type name and there are no squiggly brackets {} around octet 
> string values.
> 
> 
> Extracts from sections 24.17, 16.13, 22.3 & 11.12.1 of X.680 
> ASN.1 (2002):
> 
> 	SequenceValue ::=
> 		  "{" ComponentValueList "}"
> 		| "{" "}"
> 
> 	ComponentValueList ::=
> 		  NamedValue
> 		| ComponentValueList "," NamedValue
> 
> 	NamedValue = identifier Value
> 
> 	NOTE- The "identifier" is part of the notation,
> 	it does not form part of the value itself.
> 	It is used to unambiguously refer to the components
> 	of a set type, sequence type or choice type.
> 
> 	OctetStringValue ::=
> 		  bstring
> 		| hstring
> 		| CONTAINING Value
> 
> 	.. "hstring" ..
> 		EXAMPLE- 'AB0196'H
> 
> 
> Extracts from sections D.2 of X.681 ASN.1 Information object 
> spec (2002):
> 
> 	ExampleType ::= SEQUENCE {
> 		openTypeComponent1  EXAMPLE-CLASS.&TypeField,
> 		integerComponent1   EXAMPLE-CLASS.&fixedTypeValueField,
> 		openTypeComponent2  
> EXAMPLE-CLASS.&variableTypeValueField,
> 		integerComponent2   
> EXAMPLE-CLASS.&FixedTypeValueSetField,
> 		openTypeComponent3  
> EXAMPLE-CLASS.&VariableTypeValueSetField
> 	}
> 	exampleValue ExampleType ::= {
> 		openTypeComponent1	BOOLEAN : TRUE,
> 		integerComponent1		123,
> 		openTypeComponent2	IA5String : "abcdef",
> 		integerComponent2		456,
> 		openTypeComponent3	BIT STRING : '0101010101'B
> 	}
> 
> 
> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Thursday, 4 December 2003 6:05 AM
> To: Manger, James H; [e-mail]
> Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt 
> - ASN.1 typos
> 
> 
> James:
> 
> After changing:
>        sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 XX }
> to:
>        sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }
> 
> The module compiles fine for me.
> 
> Russ
> 
> At 09:54 AM 12/3/2003 +1000, Manger, James H wrote:
> 
> >The ASN.1 module in draft-ietf-pkix-rsa-pkalgs-01.txt has some typos.
> >
> >1.
> >When specifying ASN.1 values the field names must be included.  When
> >specifying open type values the type must be specified.  For 
> instance:
> >
> >WRONG:
> >         sha1Identifier AlgorithmIdentifier ::=
> >                 { id-sha1, NULL }
> >
> >RIGHT:
> >         sha1Identifier AlgorithmIdentifier ::=
> >                 { algorithm id-sha1, parameters NULL:NULL }
> >
> >These errors affect all 31 values of the following types:
> >AlgorithmIdentifier, RSASSA-PSS-params & RSAES-OAEP-params.
> >
> >
> >2.
> >In section 4.1 and in the ASN.1 module:
> >WRONG:  nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
> >RIGHT:  nullOctetString OCTET STRING (SIZE (0)) ::= ''H
> >
> >----------
> >From: [e-mail] [mailto:[e-mail]]
> >Sent: Wednesday, 3 December 2003 7:36 AM
> >
> >         Title           : Additional Algorithms and 
> Identifiers for RSA
> >                           Cryptography for use in the Internet X.509
> >                           Public Key Infrastructure Certificate and
> >                           Certificate Revocation List (CRL) Profile
> >         Author(s)       : R. Housley, B. Kaliski
> >         Filename        : draft-ietf-pkix-rsa-pkalgs-01.txt
> >         Pages           : 22
> >         Date            : 2003-12-2
> >
> >This document supplements RFC 3279.  It describes the conventions for
> >using the RSASSA-PSS signature algorithm, the RSAES-OAEP key 
> transport 
> >algorithm, and additional one-way hash functions with the 
> PKCS #1 version 
> >1.5 signature algorithm in the Internet X.509 Public Key 
> Infrastructure 
> >(PKI).  Encoding formats, algorithm identifiers, and 
> parameter formats are 
> >specified.
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-01.txt
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB41Iwib092886 for <[e-mail]>; Wed, 3 Dec 2003 17:18:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB41IwSE092885 for ietf-pkix-bks; Wed, 3 Dec 2003 17:18:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB41Iqib092878 for <[e-mail]>; Wed, 3 Dec 2003 17:18:57 -0800 (PST) (envelope-from [e-mail])
Received: from mailai.vtcif.telstra.com.au (mailai.vtcif.telstra.com.au [202.12.142.17]) by mailbo.vtcif.telstra.com.au (Postfix) with ESMTP id 4224A22FBD for <[e-mail]>; Thu,  4 Dec 2003 12:18:40 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 73F7F22883 for <[e-mail]>; Thu,  4 Dec 2003 12:18:39 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA07484 for <[e-mail]>; Thu, 4 Dec 2003 12:18:39 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Date: Thu, 4 Dec 2003 11:18:18 +1000
Message-ID: <[e-mail]>
Thread-Topic: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Thread-Index: AcO50HAxAiv5pohGQcCLUUblq5sWQgAJ3LOw
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB41Ivib092881
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,

I still think I am right.  Does your compiler compile complex values, or just types?

Very early versions of ASN.1 (X.208 1998/1990?) may have allowed the identifier (field name) to be omitted, but subsequent versions (X.680 1994/...) corrected this to avoid ambiguities.  Perhaps you have a lenient compiler (nice sometimes, but not when writing standards).

Much of draft-ietf-pkix-rsa-pkalgs-01.txt is based on PKCS #1 v2.1 where the ASN.1 is correct: it includes identifiers & type name and there are no squiggly brackets {} around octet string values.


Extracts from sections 24.17, 16.13, 22.3 & 11.12.1 of X.680 ASN.1 (2002):

	SequenceValue ::=
		  "{" ComponentValueList "}"
		| "{" "}"

	ComponentValueList ::=
		  NamedValue
		| ComponentValueList "," NamedValue

	NamedValue = identifier Value

	NOTE- The "identifier" is part of the notation,
	it does not form part of the value itself.
	It is used to unambiguously refer to the components
	of a set type, sequence type or choice type.

	OctetStringValue ::=
		  bstring
		| hstring
		| CONTAINING Value

	.. "hstring" ..
		EXAMPLE- 'AB0196'H


Extracts from sections D.2 of X.681 ASN.1 Information object spec (2002):

	ExampleType ::= SEQUENCE {
		openTypeComponent1  EXAMPLE-CLASS.&TypeField,
		integerComponent1   EXAMPLE-CLASS.&fixedTypeValueField,
		openTypeComponent2  EXAMPLE-CLASS.&variableTypeValueField,
		integerComponent2   EXAMPLE-CLASS.&FixedTypeValueSetField,
		openTypeComponent3  EXAMPLE-CLASS.&VariableTypeValueSetField
	}
	exampleValue ExampleType ::= {
		openTypeComponent1	BOOLEAN : TRUE,
		integerComponent1		123,
		openTypeComponent2	IA5String : "abcdef",
		integerComponent2		456,
		openTypeComponent3	BIT STRING : '0101010101'B
	}


-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Thursday, 4 December 2003 6:05 AM
To: Manger, James H; [e-mail]
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1
typos


James:

After changing:
       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 XX }
to:
       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }

The module compiles fine for me.

Russ

At 09:54 AM 12/3/2003 +1000, Manger, James H wrote:

>The ASN.1 module in draft-ietf-pkix-rsa-pkalgs-01.txt has some typos.
>
>1.
>When specifying ASN.1 values the field names must be included.  When 
>specifying open type values the type must be specified.  For instance:
>
>WRONG:
>         sha1Identifier AlgorithmIdentifier ::=
>                 { id-sha1, NULL }
>
>RIGHT:
>         sha1Identifier AlgorithmIdentifier ::=
>                 { algorithm id-sha1, parameters NULL:NULL }
>
>These errors affect all 31 values of the following types: 
>AlgorithmIdentifier, RSASSA-PSS-params & RSAES-OAEP-params.
>
>
>2.
>In section 4.1 and in the ASN.1 module:
>WRONG:  nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
>RIGHT:  nullOctetString OCTET STRING (SIZE (0)) ::= ''H
>
>----------
>From: [e-mail] [mailto:[e-mail]]
>Sent: Wednesday, 3 December 2003 7:36 AM
>
>         Title           : Additional Algorithms and Identifiers for RSA
>                           Cryptography for use in the Internet X.509
>                           Public Key Infrastructure Certificate and
>                           Certificate Revocation List (CRL) Profile
>         Author(s)       : R. Housley, B. Kaliski
>         Filename        : draft-ietf-pkix-rsa-pkalgs-01.txt
>         Pages           : 22
>         Date            : 2003-12-2
>
>This document supplements RFC 3279.  It describes the conventions for 
>using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport 
>algorithm, and additional one-way hash functions with the PKCS #1 version 
>1.5 signature algorithm in the Internet X.509 Public Key Infrastructure 
>(PKI).  Encoding formats, algorithm identifiers, and parameter formats are 
>specified.
>
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-01.txt




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3KTZib079989 for <[e-mail]>; Wed, 3 Dec 2003 12:29:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3KTZ4G079988 for ietf-pkix-bks; Wed, 3 Dec 2003 12:29:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3KTXib079983 for <[e-mail]>; Wed, 3 Dec 2003 12:29:34 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04052; Wed, 3 Dec 2003 15:29:19 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-13.txt
Date: Wed, 03 Dec 2003 15:29:19 -0500
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-13.txt
	Pages		: 23
	Date		: 2003-12-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-13.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-13.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-13.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-13.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3J5Wib076478 for <[e-mail]>; Wed, 3 Dec 2003 11:05:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3J5WJU076477 for ietf-pkix-bks; Wed, 3 Dec 2003 11:05:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB3J5Vib076472 for <[e-mail]>; Wed, 3 Dec 2003 11:05:31 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 18593 invoked by uid 0); 3 Dec 2003 19:05:09 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (156.80.127.154) by woodstock.binhost.com with SMTP; 3 Dec 2003 19:05:09 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 03 Dec 2003 14:05:18 -0500
To: "Manger, James H" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1 typos
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:

After changing:
       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 XX }
to:
       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }

The module compiles fine for me.

Russ

At 09:54 AM 12/3/2003 +1000, Manger, James H wrote:

>The ASN.1 module in draft-ietf-pkix-rsa-pkalgs-01.txt has some typos.
>
>1.
>When specifying ASN.1 values the field names must be included.  When 
>specifying open type values the type must be specified.  For instance:
>
>WRONG:
>         sha1Identifier AlgorithmIdentifier ::=
>                 { id-sha1, NULL }
>
>RIGHT:
>         sha1Identifier AlgorithmIdentifier ::=
>                 { algorithm id-sha1, parameters NULL:NULL }
>
>These errors affect all 31 values of the following types: 
>AlgorithmIdentifier, RSASSA-PSS-params & RSAES-OAEP-params.
>
>
>2.
>In section 4.1 and in the ASN.1 module:
>WRONG:  nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
>RIGHT:  nullOctetString OCTET STRING (SIZE (0)) ::= ''H
>
>----------
>From: [e-mail] [mailto:[e-mail]]
>Sent: Wednesday, 3 December 2003 7:36 AM
>
>         Title           : Additional Algorithms and Identifiers for RSA
>                           Cryptography for use in the Internet X.509
>                           Public Key Infrastructure Certificate and
>                           Certificate Revocation List (CRL) Profile
>         Author(s)       : R. Housley, B. Kaliski
>         Filename        : draft-ietf-pkix-rsa-pkalgs-01.txt
>         Pages           : 22
>         Date            : 2003-12-2
>
>This document supplements RFC 3279.  It describes the conventions for 
>using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport 
>algorithm, and additional one-way hash functions with the PKCS #1 version 
>1.5 signature algorithm in the Internet X.509 Public Key Infrastructure 
>(PKI).  Encoding formats, algorithm identifiers, and parameter formats are 
>specified.
>
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-01.txt



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3GVdib068058 for <[e-mail]>; Wed, 3 Dec 2003 08:31:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3GVdwa068057 for ietf-pkix-bks; Wed, 3 Dec 2003 08:31:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3GVcib068045 for <[e-mail]>; Wed, 3 Dec 2003 08:31:38 -0800 (PST) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Dec 2003 08:31:16 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 3 Dec 2003 08:31:31 -0800
Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Dec 2003 08:31:33 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Dec 2003 08:31:24 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 3 Dec 2003 08:31:26 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 3 Dec 2003 08:31:32 -0800
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.150 157.54.0.150 via HTTP with MS-WebStorage 6.5.7122
Received: 157.54.0.150 157.54.0.150 from 157.54.1.70 157.54.1.70 via HTTP with MS-WebStorage 6.5.7122
MIME-Version: 1.0
Subject: RE: Lightweight OCSP Profile for high volume environments...
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <000401c3b99a$5c93fb50$[e-mail]>, <[e-mail]>
To: Denis Pinkas <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: Lightweight OCSP Profile for high volume environments...
Thread-Index: AcO5uqCTO09Nh7X9QAqYi9ayc9X3Rw==
Message-ID: <15110045-2BF8-4F32-8BD1-AD1C92E50BC9@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.7122.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.7122.0
Date: Wed, 3 Dec 2003 08:29:30 -0800
X-OriginalArrivalTime: 03 Dec 2003 16:31:32.0329 (UTC) FILETIME=[E9283D90:01C3B9BA]
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>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_C2844197-57EA-48E7-B3AB-92311F72770E_"

--_C2844197-57EA-48E7-B3AB-92311F72770E_
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Thats a good point Denis, but it is a very common practice on that has its =
purpose and its costs.

Ryan



From: Denis Pinkas
Sent: Wed 12/3/2003 6:23 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Lightweight OCSP Profile for high volume environments...


Santosh,

> Ryan:  Thanks.  I understand.  But, given that network delays and clock=20
> synchronization issues are still there, you still need the same delta. =20
> Since nextUpdate was designed to serve this purpose, the response=20
> generator should put nextUpdate by which the response will be available.
> =20
> However, I do know if some PKI implementations where nextUpdate for CRL=20
> is well ahead (say a week) and actual issuance is daily or every two=20
> days.=20

  ... and in such a case in case of an attack, these daily CRLs will
      not be seen. :-(

Denis

> In those scenarios, I can see nextUpdate being a week ahead, but=20
> nextPublish could be day or two days ahead.
>=20
>     -----Original Message-----
>     From: Ryan M. Hurst [mailto:[e-mail]]
>     Sent: Tuesday, December 02, 2003 10:15 PM
>     To: Santosh Chokhani; [e-mail]
>     Subject: RE: Lightweight OCSP Profile for high volume environments...
>=20
>     Santosh -
>     =20
>     One of the things we have been discussing is how a client can
>     retrieve data from the responder before it expressly needed without
>     abusing the responder.
>     =20
>     This is needed so that clients do not need to interrupt their
>     transaction to wait for a OCSP response, this is particularly
>     interesting in the TLSEXT case where the webserver server is likely
>     to maintain a cache of responses it provides to clients as part of
>     the TLS negotiation.=20
>     =20
>     Typically nextUpdate (plus or minus some) is used by clients as the
>     expiration of the response, the responder also typically will have
>     some overlap in the responses they produce, in the case of a
>     pre-production responder there is also going to be a delay between
>     when the responses were produced, and when they become generally
>     available.
>     =20
>     Without this value clients will simply guess at a value which may
>     not be accurate for that particular responder resulting in
>     un-necessary network traffic to the responder and delays for the clie=
nt.
>     =20
>     Ryan
>=20
>     ---------------------------------------------------------------------=
---
>     From: Santosh Chokhani
>     Sent: Tue 12/2/2003 5:10 PM
>     To: [e-mail]
>     Subject: RE: Lightweight OCSP Profile for high volume environments...
>=20
>=20
>     Alex:
>=20
>     I think I understand what you are trying to say, but I fail to see mu=
ch
>     added utility of nextPublish over nextUpdate.=20
>=20
>     -----Original Message-----
>     From: [e-mail]
>     [mailto:[e-mail]] On
>     Behalf Of Deacon, Alex
>     Sent: Tuesday, December 02, 2003 2:43 PM
>     To: [e-mail]
>     Subject: Lightweight OCSP Profile for high volume environments...
>=20
>=20
>=20
>=20
>     All,
>=20
>     On a related topic, we (Ryan and myself) have recently submitted an
>     informational internet-draft which describes a lightweight profile
>     of OCSP
>     (RFC 2560) for use in very large PKI deployments such as SSL/TLS, cod=
e
>     signing and secure messaging. (i.e. environments where pre-produced a=
nd
>     distributed responses may be desirable).=20
>=20
>     http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-pro=
file-00
>     .txt
>=20
>     Alex
>=20
>=20

--_C2844197-57EA-48E7-B3AB-92311F72770E_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText40219 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Thats a good poi=
nt Denis, but it is a very common practice on that has its purpose and its =
costs.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Denis Pinkas<BR><B>Sent:</B> Wed =
12/3/2003 6:23 AM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B> ietf-pkix@im=
c.org<BR><B>Subject:</B> Re: Lightweight OCSP Profile for high volume envir=
onments...<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">Santosh,

&gt; Ryan:  Thanks.  I understand.  But, given that network delays and cloc=
k=20
&gt; synchronization issues are still there, you still need the same delta.=
 =20
&gt; Since nextUpdate was designed to serve this purpose, the response=20
&gt; generator should put nextUpdate by which the response will be availabl=
e.
&gt; =20
&gt; However, I do know if some PKI implementations where nextUpdate for CR=
L=20
&gt; is well ahead (say a week) and actual issuance is daily or every two=20
&gt; days.=20

  ... and in such a case in case of an attack, these daily CRLs will
      not be seen. :-(

Denis

&gt; In those scenarios, I can see nextUpdate being a week ahead, but=20
&gt; nextPublish could be day or two days ahead.
&gt;=20
&gt;     -----Original Message-----
&gt;     From: Ryan M. Hurst [mailto:[e-mail]]
&gt;     Sent: Tuesday, December 02, 2003 10:15 PM
&gt;     To: Santosh Chokhani; [e-mail]
&gt;     Subject: RE: Lightweight OCSP Profile for high volume environments=
...
&gt;=20
&gt;     Santosh -
&gt;     =20
&gt;     One of the things we have been discussing is how a client can
&gt;     retrieve data from the responder before it expressly needed withou=
t
&gt;     abusing the responder.
&gt;     =20
&gt;     This is needed so that clients do not need to interrupt their
&gt;     transaction to wait for a OCSP response, this is particularly
&gt;     interesting in the TLSEXT case where the webserver server is likel=
y
&gt;     to maintain a cache of responses it provides to clients as part of
&gt;     the TLS negotiation.=20
&gt;     =20
&gt;     Typically nextUpdate (plus or minus some) is used by clients as th=
e
&gt;     expiration of the response, the responder also typically will have
&gt;     some overlap in the responses they produce, in the case of a
&gt;     pre-production responder there is also going to be a delay between
&gt;     when the responses were produced, and when they become generally
&gt;     available.
&gt;     =20
&gt;     Without this value clients will simply guess at a value which may
&gt;     not be accurate for that particular responder resulting in
&gt;     un-necessary network traffic to the responder and delays for the c=
lient.
&gt;     =20
&gt;     Ryan
&gt;=20
&gt;     ------------------------------------------------------------------=
------
&gt;     From: Santosh Chokhani
&gt;     Sent: Tue 12/2/2003 5:10 PM
&gt;     To: [e-mail]
&gt;     Subject: RE: Lightweight OCSP Profile for high volume environments=
...
&gt;=20
&gt;=20
&gt;     Alex:
&gt;=20
&gt;     I think I understand what you are trying to say, but I fail to see=
 much
&gt;     added utility of nextPublish over nextUpdate.=20
&gt;=20
&gt;     -----Original Message-----
&gt;     From: [e-mail]
&gt;     [mailto:[e-mail]] On
&gt;     Behalf Of Deacon, Alex
&gt;     Sent: Tuesday, December 02, 2003 2:43 PM
&gt;     To: [e-mail]
&gt;     Subject: Lightweight OCSP Profile for high volume environments...
&gt;=20
&gt;=20
&gt;=20
&gt;=20
&gt;     All,
&gt;=20
&gt;     On a related topic, we (Ryan and myself) have recently submitted a=
n
&gt;     informational internet-draft which describes a lightweight profile
&gt;     of OCSP
&gt;     (RFC 2560) for use in very large PKI deployments such as SSL/TLS, =
code
&gt;     signing and secure messaging. (i.e. environments where pre-produce=
d and
&gt;     distributed responses may be desirable).=20
&gt;=20
&gt;     http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-=
profile-00
&gt;     .txt
&gt;=20
&gt;     Alex
&gt;=20
&gt;=20


</PRE></DIV></BODY></HTML>

--_C2844197-57EA-48E7-B3AB-92311F72770E_--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3GTwib068002 for <[e-mail]>; Wed, 3 Dec 2003 08:29:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3GTwws068001 for ietf-pkix-bks; Wed, 3 Dec 2003 08:29:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3GTvib067991 for <[e-mail]>; Wed, 3 Dec 2003 08:29:57 -0800 (PST) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Dec 2003 08:29:36 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 3 Dec 2003 08:29:50 -0800
Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Dec 2003 08:29:52 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Dec 2003 08:30:00 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Dec 2003 08:29:47 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 3 Dec 2003 08:30:07 -0800
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.150 157.54.0.150 via HTTP with MS-WebStorage 6.5.7122
Received: 157.54.0.150 157.54.0.150 from 157.54.1.70 157.54.1.70 via HTTP with MS-WebStorage 6.5.7122
Subject: RE: Lightweight OCSP Profile for high volume environments...
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <000401c3b99a$5c93fb50$[e-mail]>
References: <8C6C8548-FE43-4112-9B1C-EA3C8DE7FB68@mimectl>, <000401c3b99a$5c93fb50$[e-mail]>
To: Santosh Chokhani <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: Lightweight OCSP Profile for high volume environments...
Thread-Index: AcO5umJDHpJR3qW7QTCp/uftZIzVvg==
Message-ID: <36B36FF6-F540-49BD-8DA8-810B7F6D46D1@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.7122.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.7122.0
Date: Wed, 3 Dec 2003 08:27:46 -0800
X-OriginalArrivalTime: 03 Dec 2003 16:30:07.0695 (UTC) FILETIME=[B6B61DF0:01C3B9BA]
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>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0005_01C3B970.73BF79F0"

------=_NextPart_000_0005_01C3B970.73BF79F0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Santosh - Yes, clients will still have to have some padding to accommodate =
for time skew but that's not what this is about.=20

Most clients out there treat nextUpdate as a expiration, I know that's not =
what the RFC stated but that is what the common interpretation of this valu=
e ended up as being.

Given this interpretation, new data is needed on the client no later than n=
extUpdate; typically when issuers produce revocation information there is a=
 overlap of validity (I have seen values in the range of hours, and some in=
 days).=20

NextPublish value allows the responder to communicate this window explicitl=
y to the client, thus allowing the client to make intelligent decisions on =
when it can pre-fetching of this data.

Ryan



From: Santosh Chokhani
Sent: Wed 12/3/2003 4:38 AM
To: [e-mail]
Subject: RE: Lightweight OCSP Profile for high volume environments...


Ryan:  Thanks.  I understand.  But, given that network delays and clock syn=
chronization issues are still there, you still need the same delta.  Since =
nextUpdate was designed to serve this purpose, the response generator shoul=
d put nextUpdate by which the response will be available.

However, I do know if some PKI implementations where nextUpdate for CRL is =
well ahead (say a week) and actual issuance is daily or every two days.  In=
 those scenarios, I can see nextUpdate being a week ahead, but nextPublish =
could be day or two days ahead.
-----Original Message-----
From: Ryan M. Hurst [mailto:[e-mail]]=20
Sent: Tuesday, December 02, 2003 10:15 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: Lightweight OCSP Profile for high volume environments...


Santosh -

One of the things we have been discussing is how a client can retrieve data=
 from the responder before it expressly needed without abusing the responde=
r.

This is needed so that clients do not need to interrupt their transaction t=
o wait for a OCSP response, this is particularly interesting in the TLSEXT =
case where the webserver server is likely to maintain a cache of responses =
it provides to clients as part of the TLS negotiation.=20

Typically nextUpdate (plus or minus some) is used by clients as the expirat=
ion of the response, the responder also typically will have some overlap in=
 the responses they produce, in the case of a pre-production responder ther=
e is also going to be a delay between when the responses were produced, and=
 when they become generally available.

Without this value clients will simply guess at a value which may not be ac=
curate for that particular responder resulting in un-necessary network traf=
fic to the responder and delays for the client.

Ryan



From: Santosh Chokhani
Sent: Tue 12/2/2003 5:10 PM
To: [e-mail]
Subject: RE: Lightweight OCSP Profile for high volume environments...




Alex:

I think I understand what you are trying to say, but I fail to see much
added utility of nextPublish over nextUpdate.=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Deacon, Alex
Sent: Tuesday, December 02, 2003 2:43 PM
To: [e-mail]
Subject: Lightweight OCSP Profile for high volume environments...




All,

On a related topic, we (Ryan and myself) have recently submitted an
informational internet-draft which describes a lightweight profile of OCSP
(RFC 2560) for use in very large PKI deployments such as SSL/TLS, code
signing and secure messaging. (i.e. environments where pre-produced and
distributed responses may be desirable).=20

http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile-0=
0
.txt

Alex

------=_NextPart_000_0005_01C3B970.73BF79F0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD><TITLE>Message</TITLE></HEAD>
<BODY>
<DIV id=3DidOWAReplyText36706 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Santosh - Yes, c=
lients will still have to have some padding to accommodate for time skew bu=
t that's not what this is about. </FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Most clients out there treat nex=
tUpdate as a expiration, I know that's not what the RFC stated but that is =
what the common interpretation of this value ended up as being.</FONT></DIV=
>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Given this interpretation, new d=
ata is needed on the client no later than nextUpdate; typically when issuer=
s produce revocation information there is a overlap of validity (I have see=
n values in the range of hours, and some in days). </FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>NextPublish&nbsp;value allows th=
e responder to communicate&nbsp;this window&nbsp;explicitly to the client, =
thus allowing the client to make intelligent decisions on when it can pre-f=
etching of this data.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Santosh Chokhani<BR><B>Sent:</B> =
Wed 12/3/2003 4:38 AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> RE=
: Lightweight OCSP Profile for high volume environments...<BR></FONT><BR></=
DIV>
<DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN class=3D096253112-03=
122003>Ryan:&nbsp; Thanks.&nbsp; I understand.&nbsp; But, given that networ=
k delays and clock synchronization issues are still there, you still need t=
he same delta.&nbsp; Since nextUpdate was designed to&nbsp;serve this purpo=
se, the response generator should put nextUpdate by which the response will=
 be available.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN class=3D096253112-03=
122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN class=3D096253112-03=
122003>However, I do know if some PKI implementations where nextUpdate for =
CRL is well ahead (say a week) and actual issuance is daily or every two da=
ys.&nbsp; In those scenarios, I can see nextUpdate being a week ahead, but =
nextPublish could be day or two days ahead.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft><FONT=
 face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Ryan M. =
Hurst [mailto:[e-mail]] <BR><B>Sent:</B> Tuesday, December=
 02, 2003 10:15 PM<BR><B>To:</B> Santosh Chokhani; [e-mail]<BR><B>=
Subject:</B> RE: Lightweight OCSP Profile for high volume environments...<B=
R><BR></FONT></DIV>
<DIV id=3DidOWAReplyText56089 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Santosh -</FONT>=
</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>One of the things we have been d=
iscussing is how a client can retrieve data from the responder before it ex=
pressly needed without abusing the responder.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>This is needed so that clients d=
o not need to interrupt their transaction to wait for a OCSP response, this=
 is particularly interesting in the TLSEXT case where the webserver server =
is likely to maintain a cache of responses it provides to&nbsp;clients as p=
art of the TLS negotiation.&nbsp;</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Typically&nbsp;nextUpdate (plus =
or minus some) is used by clients as the expiration of the response, the re=
sponder also typically will have some overlap in the responses they produce=
, in the case of a pre-production responder there is&nbsp;also going to be =
a delay&nbsp;between when the responses were produced, and when they become=
 generally available.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</D=
IV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Without this value&nbsp;clients =
will simply guess at a value which may not be accurate for that particular =
responder resulting in un-necessary network traffic to the responder and de=
lays for the client.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Santosh Chokhani<BR><B>Sent:</B> =
Tue 12/2/2003 5:10 PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> RE=
: Lightweight OCSP Profile for high volume environments...<BR></FONT><BR></=
DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR>
<P><FONT size=3D2>Alex:<BR><BR>I think I understand what you are trying to =
say, but I fail to see much<BR>added utility of nextPublish over nextUpdate=
.&nbsp;<BR><BR>-----Original Message-----<BR>From: [e-mail]=
.org [<A href=3D"mailto:[e-mail]" target=3D_blank>mailt=
o:[e-mail]</A>] On<BR>Behalf Of Deacon, Alex<BR>Sent: T=
uesday, December 02, 2003 2:43 PM<BR>To: [e-mail]<BR>Subject: Ligh=
tweight OCSP Profile for high volume environments...<BR><BR><BR><BR><BR>All=
,<BR><BR>On a related topic, we (Ryan and myself) have recently submitted a=
n<BR>informational internet-draft which describes a lightweight profile of =
OCSP<BR>(RFC 2560) for use in very large PKI deployments such as SSL/TLS, c=
ode<BR>signing and secure messaging. (i.e. environments where pre-produced =
and<BR>distributed responses may be desirable).&nbsp;<BR><BR><A href=3D"htt=
p://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile-00" =
target=3D_blank>http://www.ietf.org/internet-drafts/draft-deacon-lightweigh=
t-ocsp-profile-00</A><BR>.txt<BR><BR>Alex<BR><BR><BR></FONT></P></DIV></BLO=
CKQUOTE></DIV></BODY></HTML>

------=_NextPart_000_0005_01C3B970.73BF79F0--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3G2Bib066590 for <[e-mail]>; Wed, 3 Dec 2003 08:02:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3G2Brj066589 for ietf-pkix-bks; Wed, 3 Dec 2003 08:02:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3G29ib066582 for <[e-mail]>; Wed, 3 Dec 2003 08:02:10 -0800 (PST) (envelope-from [e-mail])
Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by mclean-vscan1.bah.com (8.11.0/8.11.0) with SMTP id hB3G1Z314137 for <[e-mail]>; Wed, 3 Dec 2003 11:01:36 -0500 (EST)
Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan1.bah.com (NAVGW 2.5.2.12) with SMTP id M2003120311013021450 for <[e-mail]>; Wed, 03 Dec 2003 11:01:31 -0500
Received: from wchokhani ([156.80.127.186]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HPBTU300.C0W for <[e-mail]>; Wed, 3 Dec 2003 11:01:15 -0500 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Lightweight OCSP Profile for high volume environments...
Date: Wed, 3 Dec 2003 11:01:09 -0500
Message-ID: <004101c3b9b6$adfc85e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB3G2Aib066585
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:

I agree and the organizations do recognize that the CRL replay attack window
is determined by nextUpdate and not the issuance frequency.

The point I was making to Ryan is that in nextPublish can be useful when the
revocation information is published more frequently than implied by the
nextUpdate.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Wednesday, December 03, 2003 9:24 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Lightweight OCSP Profile for high volume environments...


Santosh,

> Ryan:  Thanks.  I understand.  But, given that network delays and 
> clock
> synchronization issues are still there, you still need the same delta.  
> Since nextUpdate was designed to serve this purpose, the response 
> generator should put nextUpdate by which the response will be available.
>  
> However, I do know if some PKI implementations where nextUpdate for 
> CRL
> is well ahead (say a week) and actual issuance is daily or every two 
> days. 

  ... and in such a case in case of an attack, these daily CRLs will
      not be seen. :-(

Denis

> In those scenarios, I can see nextUpdate being a week ahead, but
> nextPublish could be day or two days ahead.
> 
>     -----Original Message-----
>     From: Ryan M. Hurst [mailto:[e-mail]]
>     Sent: Tuesday, December 02, 2003 10:15 PM
>     To: Santosh Chokhani; [e-mail]
>     Subject: RE: Lightweight OCSP Profile for high volume 
> environments...
> 
>     Santosh -
>      
>     One of the things we have been discussing is how a client can
>     retrieve data from the responder before it expressly needed without
>     abusing the responder.
>      
>     This is needed so that clients do not need to interrupt their
>     transaction to wait for a OCSP response, this is particularly
>     interesting in the TLSEXT case where the webserver server is likely
>     to maintain a cache of responses it provides to clients as part of
>     the TLS negotiation.
>      
>     Typically nextUpdate (plus or minus some) is used by clients as the
>     expiration of the response, the responder also typically will have
>     some overlap in the responses they produce, in the case of a
>     pre-production responder there is also going to be a delay between
>     when the responses were produced, and when they become generally
>     available.
>      
>     Without this value clients will simply guess at a value which may
>     not be accurate for that particular responder resulting in
>     un-necessary network traffic to the responder and delays for the 
> client.
>      
>     Ryan
> 
>
------------------------------------------------------------------------
>     From: Santosh Chokhani
>     Sent: Tue 12/2/2003 5:10 PM
>     To: [e-mail]
>     Subject: RE: Lightweight OCSP Profile for high volume 
> environments...
> 
> 
>     Alex:
> 
>     I think I understand what you are trying to say, but I fail to see
much
>     added utility of nextPublish over nextUpdate.
> 
>     -----Original Message-----
>     From: [e-mail]
>     [mailto:[e-mail]] On
>     Behalf Of Deacon, Alex
>     Sent: Tuesday, December 02, 2003 2:43 PM
>     To: [e-mail]
>     Subject: Lightweight OCSP Profile for high volume environments...
> 
> 
> 
> 
>     All,
> 
>     On a related topic, we (Ryan and myself) have recently submitted an
>     informational internet-draft which describes a lightweight profile
>     of OCSP
>     (RFC 2560) for use in very large PKI deployments such as SSL/TLS, code
>     signing and secure messaging. (i.e. environments where pre-produced
and
>     distributed responses may be desirable).
> 
>
http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile-00
>     .txt
> 
>     Alex
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3ENcib063144 for <[e-mail]>; Wed, 3 Dec 2003 06:23:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3ENcKM063143 for ietf-pkix-bks; Wed, 3 Dec 2003 06:23:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3ENaib063138 for <[e-mail]>; Wed, 3 Dec 2003 06:23:37 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA30850; Wed, 3 Dec 2003 15:30:23 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA21080; Wed, 3 Dec 2003 15:18:56 +0100
Message-ID: <[e-mail]>
Date: Wed, 03 Dec 2003 15:23:35 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Lightweight OCSP Profile for high volume environments...
References: <000401c3b99a$5c93fb50$[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>

Santosh,

> Ryan:  Thanks.  I understand.  But, given that network delays and clock 
> synchronization issues are still there, you still need the same delta.  
> Since nextUpdate was designed to serve this purpose, the response 
> generator should put nextUpdate by which the response will be available.
>  
> However, I do know if some PKI implementations where nextUpdate for CRL 
> is well ahead (say a week) and actual issuance is daily or every two 
> days. 

  ... and in such a case in case of an attack, these daily CRLs will
      not be seen. :-(

Denis

> In those scenarios, I can see nextUpdate being a week ahead, but 
> nextPublish could be day or two days ahead.
> 
>     -----Original Message-----
>     From: Ryan M. Hurst [mailto:[e-mail]]
>     Sent: Tuesday, December 02, 2003 10:15 PM
>     To: Santosh Chokhani; [e-mail]
>     Subject: RE: Lightweight OCSP Profile for high volume environments...
> 
>     Santosh -
>      
>     One of the things we have been discussing is how a client can
>     retrieve data from the responder before it expressly needed without
>     abusing the responder.
>      
>     This is needed so that clients do not need to interrupt their
>     transaction to wait for a OCSP response, this is particularly
>     interesting in the TLSEXT case where the webserver server is likely
>     to maintain a cache of responses it provides to clients as part of
>     the TLS negotiation. 
>      
>     Typically nextUpdate (plus or minus some) is used by clients as the
>     expiration of the response, the responder also typically will have
>     some overlap in the responses they produce, in the case of a
>     pre-production responder there is also going to be a delay between
>     when the responses were produced, and when they become generally
>     available.
>      
>     Without this value clients will simply guess at a value which may
>     not be accurate for that particular responder resulting in
>     un-necessary network traffic to the responder and delays for the client.
>      
>     Ryan
> 
>     ------------------------------------------------------------------------
>     From: Santosh Chokhani
>     Sent: Tue 12/2/2003 5:10 PM
>     To: [e-mail]
>     Subject: RE: Lightweight OCSP Profile for high volume environments...
> 
> 
>     Alex:
> 
>     I think I understand what you are trying to say, but I fail to see much
>     added utility of nextPublish over nextUpdate. 
> 
>     -----Original Message-----
>     From: [e-mail]
>     [mailto:[e-mail]] On
>     Behalf Of Deacon, Alex
>     Sent: Tuesday, December 02, 2003 2:43 PM
>     To: [e-mail]
>     Subject: Lightweight OCSP Profile for high volume environments...
> 
> 
> 
> 
>     All,
> 
>     On a related topic, we (Ryan and myself) have recently submitted an
>     informational internet-draft which describes a lightweight profile
>     of OCSP
>     (RFC 2560) for use in very large PKI deployments such as SSL/TLS, code
>     signing and secure messaging. (i.e. environments where pre-produced and
>     distributed responses may be desirable). 
> 
>     http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile-00
>     .txt
> 
>     Alex
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3CdDib059288 for <[e-mail]>; Wed, 3 Dec 2003 04:39:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3CdDi9059287 for ietf-pkix-bks; Wed, 3 Dec 2003 04:39:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3CdCib059259 for <[e-mail]>; Wed, 3 Dec 2003 04:39:12 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (41.washington-42rh15-16rt.dc.dial-access.att.net[12.77.64.41]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003120312390311100jbslle>; Wed, 3 Dec 2003 12:39:04 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Lightweight OCSP Profile for high volume environments...
Date: Wed, 3 Dec 2003 07:38:31 -0500
Message-ID: <000401c3b99a$5c93fb50$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C3B970.73BF79F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <8C6C8548-FE43-4112-9B1C-EA3C8DE7FB68@mimectl>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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_0005_01C3B970.73BF79F0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Ryan:  Thanks.  I understand.  But, given that network delays and clock
synchronization issues are still there, you still need the same delta.
Since nextUpdate was designed to serve this purpose, the response =
generator
should put nextUpdate by which the response will be available.
=20
However, I do know if some PKI implementations where nextUpdate for CRL =
is
well ahead (say a week) and actual issuance is daily or every two days.  =
In
those scenarios, I can see nextUpdate being a week ahead, but =
nextPublish
could be day or two days ahead.

-----Original Message-----
From: Ryan M. Hurst [mailto:[e-mail]]=20
Sent: Tuesday, December 02, 2003 10:15 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: Lightweight OCSP Profile for high volume environments...


Santosh -
=20
One of the things we have been discussing is how a client can retrieve =
data
from the responder before it expressly needed without abusing the =
responder.
=20
This is needed so that clients do not need to interrupt their =
transaction to
wait for a OCSP response, this is particularly interesting in the TLSEXT
case where the webserver server is likely to maintain a cache of =
responses
it provides to clients as part of the TLS negotiation.=20
=20
Typically nextUpdate (plus or minus some) is used by clients as the
expiration of the response, the responder also typically will have some
overlap in the responses they produce, in the case of a pre-production
responder there is also going to be a delay between when the responses =
were
produced, and when they become generally available.
=20
Without this value clients will simply guess at a value which may not be
accurate for that particular responder resulting in un-necessary network
traffic to the responder and delays for the client.
=20
Ryan

  _____ =20

From: Santosh Chokhani
Sent: Tue 12/2/2003 5:10 PM
To: [e-mail]
Subject: RE: Lightweight OCSP Profile for high volume environments...





Alex:

I think I understand what you are trying to say, but I fail to see much
added utility of nextPublish over nextUpdate.=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On
Behalf Of Deacon, Alex
Sent: Tuesday, December 02, 2003 2:43 PM
To: [e-mail]
Subject: Lightweight OCSP Profile for high volume environments...




All,

On a related topic, we (Ryan and myself) have recently submitted an
informational internet-draft which describes a lightweight profile of =
OCSP
(RFC 2560) for use in very large PKI deployments such as SSL/TLS, code
signing and secure messaging. (i.e. environments where pre-produced and
distributed responses may be desirable).=20

http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile=
-00
.txt

Alex





------=_NextPart_000_0005_01C3B970.73BF79F0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D096253112-03122003>Ryan:&nbsp; Thanks.&nbsp; I understand.&nbsp; =
But,=20
given that network delays and clock synchronization issues are still =
there, you=20
still need the same delta.&nbsp; Since nextUpdate was designed =
to&nbsp;serve=20
this purpose, the response generator should put nextUpdate by which the =
response=20
will be available.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D096253112-03122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D096253112-03122003>However, I do know if some PKI =
implementations where=20
nextUpdate for CRL is well ahead (say a week) and actual issuance is =
daily or=20
every two days.&nbsp; In those scenarios, I can see nextUpdate being a =
week=20
ahead, but nextPublish could be day or two days =
ahead.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Ryan =
M. Hurst=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Tuesday, December =
02, 2003=20
  10:15 PM<BR><B>To:</B> Santosh Chokhani; =
[e-mail]<BR><B>Subject:</B>=20
  RE: Lightweight OCSP Profile for high volume=20
  environments...<BR><BR></FONT></DIV>
  <DIV id=3DidOWAReplyText56089 dir=3Dltr>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Santosh =
-</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>One of the things we have =
been discussing=20
  is how a client can retrieve data from the responder before it =
expressly=20
  needed without abusing the responder.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>This is needed so that =
clients do not=20
  need to interrupt their transaction to wait for a OCSP response, this =
is=20
  particularly interesting in the TLSEXT case where the webserver server =
is=20
  likely to maintain a cache of responses it provides to&nbsp;clients as =
part of=20
  the TLS negotiation.&nbsp;</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>Typically&nbsp;nextUpdate =
(plus or minus=20
  some) is used by clients as the expiration of the response, the =
responder also=20
  typically will have some overlap in the responses they produce, in the =
case of=20
  a pre-production responder there is&nbsp;also going to be a =
delay&nbsp;between=20
  when the responses were produced, and when they become generally=20
  available.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>Without this =
value&nbsp;clients will=20
  simply guess at a value which may not be accurate for that particular=20
  responder resulting in un-necessary network traffic to the responder =
and=20
  delays for the client.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
  <DIV dir=3Dltr><BR>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Santosh =
Chokhani<BR><B>Sent:</B> Tue=20
  12/2/2003 5:10 PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> =
RE:=20
  Lightweight OCSP Profile for high volume =
environments...<BR></FONT><BR></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR>
  <P><FONT size=3D2>Alex:<BR><BR>I think I understand what you are =
trying to say,=20
  but I fail to see much<BR>added utility of nextPublish over=20
  nextUpdate.&nbsp;<BR><BR>-----Original Message-----<BR>From:=20
  [e-mail] [<A =
href=3D"mailto:[e-mail]"=20
  target=3D_blank>mailto:[e-mail]</A>] On<BR>Behalf =
Of Deacon,=20
  Alex<BR>Sent: Tuesday, December 02, 2003 2:43 PM<BR>To:=20
  [e-mail]<BR>Subject: Lightweight OCSP Profile for high volume =

  environments...<BR><BR><BR><BR><BR>All,<BR><BR>On a related topic, we =
(Ryan=20
  and myself) have recently submitted an<BR>informational internet-draft =
which=20
  describes a lightweight profile of OCSP<BR>(RFC 2560) for use in very =
large=20
  PKI deployments such as SSL/TLS, code<BR>signing and secure messaging. =
(i.e.=20
  environments where pre-produced and<BR>distributed responses may be=20
  desirable).&nbsp;<BR><BR><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp=
-profile-00"=20
  =
target=3D_blank>http://www.ietf.org/internet-drafts/draft-deacon-lightwei=
ght-ocsp-profile-00</A><BR>.txt<BR><BR>Alex<BR><BR><BR></FONT></P></DIV><=
/BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0005_01C3B970.73BF79F0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3AOJib054053 for <[e-mail]>; Wed, 3 Dec 2003 02:24:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB3AOJBR054052 for ietf-pkix-bks; Wed, 3 Dec 2003 02:24:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB3AOFib054046 for <[e-mail]>; Wed, 3 Dec 2003 02:24:17 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA31512 for <[e-mail]>; Wed, 3 Dec 2003 11:31:01 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id LAA19091 for <[e-mail]>; Wed, 3 Dec 2003 11:19:34 +0100
Message-ID: <[e-mail]>
Date: Wed, 03 Dec 2003 11:24:13 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certpathbuild-02.txt
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>

A few comments about sections 6.4 and 6.2.

The text in section 6.4 is lacking guidance on what to do when using the CRL 
DP, in particular what kind of verifications are necessary when the CRL 
Issuer is not the CA.

    Therefore, implementations may wish to provide support for decoding
    the CRLDP extension and using the information to retrieve CRLs.
    Support for CRLDP is optional and [RFC 3280] compliant implementations
    need not populate the CRLDP extension.

Then what to do if the CRLDP is not present ?

Similar guidance is misssing in section 6.2 about the use of the authority 
information access (AIA) extension which contains an accessMethod defined 
with the id-ad-caIssuers OID, i.e. what kind of verifications are necessary 
when the OCSP responder is not the CA.

BTW, the following sentence extracted for the document is not correct:

    If a certificate with an AIA extension contains an accessMethod defined
    with the id-ad-caIssuers OID, the AIA may be used to retrieve one or
    more certificates for entities that issued the certificate containing
    the AIA extension.

Denis


> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 	Title		: Internet X.509 Public Key Infrastructure:       
> 			  Certification Path Building
> 	Author(s)	: M. Cooper, Y. Dzambasow
> 	Filename	: draft-ietf-pkix-certpathbuild-02.txt
> 	Pages		: 70
> 	Date		: 2003-12-2
> 	
> This document was written to provide guidance and recommendations to 
> developers building X.509 public-key certification paths within their 
> applications.  By following the guidance and recommendations defined 
> in this document, an application developer is more likely to develop 
> a robust X.509 certificate enabled application that can build valid 
> certification paths across a wide range of PKI environments.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-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-certpathbuild-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-certpathbuild-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.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB33H5ib066611 for <[e-mail]>; Tue, 2 Dec 2003 19:17:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB33H5QP066610 for ietf-pkix-bks; Tue, 2 Dec 2003 19:17:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB33H4ib066605 for <[e-mail]>; Tue, 2 Dec 2003 19:17:04 -0800 (PST) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 2 Dec 2003 19:17:06 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 2 Dec 2003 19:16:49 -0800
Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Dec 2003 19:17:00 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Dec 2003 19:17:08 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Dec 2003 19:16:55 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 2 Dec 2003 19:17:05 -0800
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.150 157.54.0.150 via HTTP with MS-WebStorage 6.5.7122
Received: 157.54.0.150 157.54.0.150 from 157.54.1.70 157.54.1.70 via HTTP with MS-WebStorage 6.5.7122
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Lightweight OCSP Profile for high volume environments...
Thread-Topic: Lightweight OCSP Profile for high volume environments...
Thread-Index: AcO5SYjLpOV5N27+SxaYhsDRJo31OgAAhh6E
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <000501c3b93a$4d8a5920$[e-mail]>
References:  <[e-mail]>, <000501c3b93a$4d8a5920$[e-mail]>
To: Santosh Chokhani <[e-mail]>, <[e-mail]>
Message-ID: <8C6C8548-FE43-4112-9B1C-EA3C8DE7FB68@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.7122.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.7122.0
Date: Tue, 2 Dec 2003 19:14:57 -0800
X-OriginalArrivalTime: 03 Dec 2003 03:17:05.0102 (UTC) FILETIME=[ED469EE0:01C3B94B]
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>

<HTML><HEAD><TITLE>RE: Lightweight OCSP Profile for high volume environment=
s...</TITLE></HEAD>
<BODY>
<DIV id=3DidOWAReplyText56089 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Santosh -</FONT>=
</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>One of the things we have been d=
iscussing is how a client can retrieve data from the responder before it ex=
pressly needed without abusing the responder.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>This is needed so that clients d=
o not need to interrupt their transaction to wait for a OCSP response, this=
 is particularly interesting in the TLSEXT case where the webserver server =
is likely to maintain a cache of responses it provides to&nbsp;clients as p=
art of the TLS negotiation.&nbsp;</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Typically&nbsp;nextUpdate (plus =
or minus some) is used by clients as the expiration of the response, the re=
sponder also typically will have some overlap in the responses they produce=
, in the case of a pre-production responder there is&nbsp;also going to be =
a delay&nbsp;between when the responses were produced, and when they become=
 generally available.</FONT></DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Without this value&nbsp;clients =
will simply guess at a value which may not be accurate for that particular =
responder resulting in un-necessary network traffic to the responder and de=
lays for the client.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Santosh Chokhani<BR><B>Sent:</B> =
Tue 12/2/2003 5:10 PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> RE=
: Lightweight OCSP Profile for high volume environments...<BR></FONT><BR></=
DIV>
<DIV><BR>
<P><FONT size=3D2>Alex:<BR><BR>I think I understand what you are trying to =
say, but I fail to see much<BR>added utility of nextPublish over nextUpdate=
.&nbsp;<BR><BR>-----Original Message-----<BR>From: [e-mail]=
.org [<A href=3D"mailto:[e-mail]" target=3D_blank>mailt=
o:[e-mail]</A>] On<BR>Behalf Of Deacon, Alex<BR>Sent: T=
uesday, December 02, 2003 2:43 PM<BR>To: [e-mail]<BR>Subject: Ligh=
tweight OCSP Profile for high volume environments...<BR><BR><BR><BR><BR>All=
,<BR><BR>On a related topic, we (Ryan and myself) have recently submitted a=
n<BR>informational internet-draft which describes a lightweight profile of =
OCSP<BR>(RFC 2560) for use in very large PKI deployments such as SSL/TLS, c=
ode<BR>signing and secure messaging. (i.e. environments where pre-produced =
and<BR>distributed responses may be desirable).&nbsp;<BR><BR><A href=3D"htt=
p://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile-00" =
target=3D_blank>http://www.ietf.org/internet-drafts/draft-deacon-lightweigh=
t-ocsp-profile-00</A><BR>.txt<BR><BR>Alex<BR><BR><BR></FONT></P></DIV></BOD=
Y></HTML>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB31BGib062664 for <[e-mail]>; Tue, 2 Dec 2003 17:11:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB31BGsI062663 for ietf-pkix-bks; Tue, 2 Dec 2003 17:11:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB31BFib062656 for <[e-mail]>; Tue, 2 Dec 2003 17:11:15 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (160.washington-27rh16rt-28rh15rt.dc.dial-access.att.net[12.77.42.160]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003120301105611100jdjp8e>; Wed, 3 Dec 2003 01:10:56 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Lightweight OCSP Profile for high volume environments...
Date: Tue, 2 Dec 2003 20:10:54 -0500
Message-ID: <000501c3b93a$4d8a5920$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB31BFib062658
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>

Alex:

I think I understand what you are trying to say, but I fail to see much
added utility of nextPublish over nextUpdate.  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Deacon, Alex
Sent: Tuesday, December 02, 2003 2:43 PM
To: [e-mail]
Subject: Lightweight OCSP Profile for high volume environments...




All,

On a related topic, we (Ryan and myself) have recently submitted an
informational internet-draft which describes a lightweight profile of OCSP
(RFC 2560) for use in very large PKI deployments such as SSL/TLS, code
signing and secure messaging. (i.e. environments where pre-produced and
distributed responses may be desirable).  

http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile-00
.txt

Alex




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2Nu2ib060134 for <[e-mail]>; Tue, 2 Dec 2003 15:56:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2Nu2N3060133 for ietf-pkix-bks; Tue, 2 Dec 2003 15:56:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.vtcif.telstra.com.au (mailao.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2Nu1ib060116 for <[e-mail]>; Tue, 2 Dec 2003 15:56:01 -0800 (PST) (envelope-from [e-mail])
Received: from mailai.vtcif.telstra.com.au (mailai.vtcif.telstra.com.au [202.12.142.17]) by mailao.vtcif.telstra.com.au (Postfix) with ESMTP id 8C33222BBD for <[e-mail]>; Wed,  3 Dec 2003 10:55:55 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id D40D822883 for <[e-mail]>; Wed,  3 Dec 2003 10:55:54 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA26646 for <[e-mail]>; Wed, 3 Dec 2003 10:55:54 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1 typos
Date: Wed, 3 Dec 2003 09:54:07 +1000
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-ietf-pkix-rsa-pkalgs-01.txt
Thread-Index: AcO5IqQvqcxpifSTSPut5LxNENfd/AACgzzw
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB2Nu2ib060129
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 ASN.1 module in draft-ietf-pkix-rsa-pkalgs-01.txt has some typos.

1.
When specifying ASN.1 values the field names must be included.  When specifying open type values the type must be specified.  For instance:

WRONG:
	sha1Identifier AlgorithmIdentifier ::=
		{ id-sha1, NULL }

RIGHT:
	sha1Identifier AlgorithmIdentifier ::=
		{ algorithm id-sha1, parameters NULL:NULL }

These errors affect all 31 values of the following types: AlgorithmIdentifier, RSASSA-PSS-params & RSAES-OAEP-params.


2.
In section 4.1 and in the ASN.1 module:
WRONG:	nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
RIGHT:	nullOctetString OCTET STRING (SIZE (0)) ::= ''H

----------
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, 3 December 2003 7:36 AM

	Title		: Additional Algorithms and Identifiers for RSA 
			  Cryptography for use in the Internet X.509 
			  Public Key Infrastructure Certificate and 
			  Certificate Revocation List (CRL) Profile
	Author(s)	: R. Housley, B. Kaliski
	Filename	: draft-ietf-pkix-rsa-pkalgs-01.txt
	Pages		: 22
	Date		: 2003-12-2
	
This document supplements RFC 3279.  It describes the conventions for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport algorithm, and additional one-way hash functions with the PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI).  Encoding formats, algorithm identifiers, and parameter formats are specified.

http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-01.txt



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2MkLib057728 for <[e-mail]>; Tue, 2 Dec 2003 14:46:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2MkLZB057727 for ietf-pkix-bks; Tue, 2 Dec 2003 14:46:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.ntcif.telstra.com.au ([202.12.233.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2MkJib057719 for <[e-mail]>; Tue, 2 Dec 2003 14:46:20 -0800 (PST) (envelope-from [e-mail])
Received: from mailbi.ntcif.telstra.com.au (mailbi.ntcif.telstra.com.au [202.12.162.19]) by mailbo.ntcif.telstra.com.au (Postfix) with ESMTP id 7448312D47 for <[e-mail]>; Wed,  3 Dec 2003 09:46:15 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id E8FB01298F for <[e-mail]>; Wed,  3 Dec 2003 09:46:14 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA12394 for <[e-mail]>; Wed, 3 Dec 2003 09:46:14 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 3 Dec 2003 08:45:38 +1000
Message-ID: <[e-mail]>
Thread-Topic: DISCUSS:  MUST  reject in OCSPv1
Thread-Index: AcO46mJm8STtUnXqSkWrDMOYomDKVAANzZWw
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB2MkKib057723
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 Russ's syntax will break compatibility and a new extension is deemed unnecessary, the functionality could be achieved by designating a specific nonce value as a "special" value to indicate that a server does not support nonces.  An empty octet string (04 00) would be a sensible candidate.


With this idea an extra restriction must be placed on servers that can use nonces so that they never issue a response with a empty octet string for the nonce, even if a (malicious) client included this nonce value in a request.  The fact that existing servers are unlikely to implement this rule would allow an attacker to make them appear to be caching-only servers.



-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Wednesday, 3 December 2003 12:42 AM
To: [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1



I am not very happy with the way that this discussion is going.  I am not 
convinced that a new extension is the best compromise.

...

    OCSPNonce ::= CHOICE {
       nonceValue  OCTET STRING,
       unsupported  NULL }




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2LWUib053419 for <[e-mail]>; Tue, 2 Dec 2003 13:32:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2LWUp9053418 for ietf-pkix-bks; Tue, 2 Dec 2003 13:32:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB2LWSib053413 for <[e-mail]>; Tue, 2 Dec 2003 13:32:29 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 16264 invoked by uid 0); 2 Dec 2003 21:32:07 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.240.131) by woodstock.binhost.com with SMTP; 2 Dec 2003 21:32:07 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 02 Dec 2003 16:32:28 -0500
To: "Ambarish Malpani" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
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>

Ambarish:

This lack of interoperability is a result of the under specification of the 
nonce extension.  I do not see a way to specify the return of the same 
random blob that was received or a specific flag to indicate the 
unsupported nonce response.

Russ


At 07:48 AM 12/2/2003 -0800, Ambarish Malpani wrote:

>Hi Russ,
>     This would *definitely* break compatibility with exisiting
>software.
>
>Currently, some folks put in some random bytes as the value of
>the nonce extension, while others put in an OCTET STRING, whose value is
>the random bytes.
>
>The only check the clients do, is verify that the request contains
>the same set of bytes.
>
>Servers that include the nonce in the response include the bytes
>they got in the request in the response.
>
>The solution suggested by Mike would allow current servers and clients
>to work as they do, and allow a way for smarter servers/clients to
>work together where a server wanted to provide a response without the
>nonce.
>
>If we wanted to break compatibility, it would make more sense to use the
>criticality bit in extensions (as suggested by others on the list).
>
>Regards,
>Ambarish
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Russ Housley
> > Sent: Tuesday, December 02, 2003 5:42 AM
> > To: [e-mail]
> > Subject: RE: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> > I am not very happy with the way that this discussion is going.  I am not
> > convinced that a new extension is the best compromise.
> >
> > I have just reread the nonce-related portions of RFC 2560.  I
> > must say, it
> > is quite under specified.  It does not even provide a syntax for a
> > nonce.  It really only provides the OID to identify the nonce
> > extension and
> > which extension location in which it is carried.
> >
> > It says:
> >
> >     The nonce cryptographically binds a request and a response to prevent
> >     replay attacks. The nonce is included as one of the requestExtensions
> >     in requests, while in responses it would be included as one of the
> >     responseExtensions. In both the request and the response, the nonce
> >     will be identified by the object identifier id-pkix-ocsp-nonce, while
> >     the extnValue is the value of the nonce.
> >
> >     id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
> >
> > Rather than defining a new extension, called nonceUnsupported,
> > you have the
> > opportunity to specify a syntax to go with this OID that does the same
> > thing.  Something like:
> >
> >     OCSPNonce ::= CHOICE {
> >        nonceValue  OCTET STRING,
> >        unsupported  NULL }
> >
> > Text that goes with the syntax definition ought to make it
> > illegal for the
> > request to use the NULL.  That is, it is only allowed in the response.
> >
> > I still prefer the "MUST reject" approach, but this seems like a cleaner
> > solution than a new extension.
> >
> > Russ
> >
> >
> > Ambarish wrote:
> >
> > >Hi Florian,
> > >    The reason for including a nonce in the request is to enable a
> > >client that doesn't have a very precise knowledge of time to still
> > >be sure the response he got from the server was generated for this
> > >specific request.
> > >
> > >While I do agree with Mark and think that the "right" way would be
> > >to require the client to require the nonce in the response, in the
> > >interests of moving ahead, I vote to accept Mike's compromise
> > >proposal that a client MUST require the nonce in the response
> > >unless it is accompanied by a nonceUnsupported extension in
> > >the response and the client is willing to accept a response w/o
> > >a nonce. This preserves the semantics for current clients and
> > >still allows caching servers to supply responses to clients
> > >who will take them.
> > >
> > >Regards,
> > >Ambarish
> >



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2LU1ib053268 for <[e-mail]>; Tue, 2 Dec 2003 13:30:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2LU1kn053267 for ietf-pkix-bks; Tue, 2 Dec 2003 13:30:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB2LU0ib053262 for <[e-mail]>; Tue, 2 Dec 2003 13:30:00 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 15873 invoked by uid 0); 2 Dec 2003 21:29:38 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.240.131) by woodstock.binhost.com with SMTP; 2 Dec 2003 21:29:38 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 02 Dec 2003 16:29:59 -0500
To: "Michael Myers" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
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>

Yes, that is my compromise proposal.

At 08:33 AM 12/2/2003 -0700, Michael Myers wrote:
>Russ,
>
>So if I'm reading this correctly, a server that receives a
>request containing a value for nonceValue MAY ignore the nonce
>and return NULL?
>
>By the way, Ambarish and I had already planned to clarify nonce
>syntax as OCTET STRING as 2560 goes from Proposed to Draft.
>
>Mike
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Russ Housley
> > Sent: Tuesday, December 02, 2003 6:42 AM
> > To: [e-mail]
> > Subject: RE: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> > I am not very happy with the way that this discussion
> > is going.  I am not
> > convinced that a new extension is the best compromise.
> >
> > I have just reread the nonce-related portions of RFC
> > 2560.  I must say, it
> > is quite under specified.  It does not even provide a
> > syntax for a
> > nonce.  It really only provides the OID to identify
> > the nonce extension and
> > which extension location in which it is carried.
> >
> > It says:
> >
> >     The nonce cryptographically binds a request and a
> > response to prevent
> >     replay attacks. The nonce is included as one of
> > the requestExtensions
> >     in requests, while in responses it would be
> > included as one of the
> >     responseExtensions. In both the request and the
> > response, the nonce
> >     will be identified by the object identifier
> > id-pkix-ocsp-nonce, while
> >     the extnValue is the value of the nonce.
> >
> >     id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= {
> > id-pkix-ocsp 2 }
> >
> > Rather than defining a new extension, called
> > nonceUnsupported, you have the
> > opportunity to specify a syntax to go with this OID
> > that does the same
> > thing.  Something like:
> >
> >     OCSPNonce ::= CHOICE {
> >        nonceValue  OCTET STRING,
> >        unsupported  NULL }
> >
> > Text that goes with the syntax definition ought to
> > make it illegal for the
> > request to use the NULL.  That is, it is only allowed
> > in the response.
> >
> > I still prefer the "MUST reject" approach, but this
> > seems like a cleaner
> > solution than a new extension.
> >
> > Russ
> >
> >
> > Ambarish wrote:
> >
> > >Hi Florian,
> > >    The reason for including a nonce in the request
> > is to enable a
> > >client that doesn't have a very precise knowledge of
> > time to still
> > >be sure the response he got from the server was
> > generated for this
> > >specific request.
> > >
> > >While I do agree with Mark and think that the
> > "right" way would be
> > >to require the client to require the nonce in the
> > response, in the
> > >interests of moving ahead, I vote to accept Mike's compromise
> > >proposal that a client MUST require the nonce in the response
> > >unless it is accompanied by a nonceUnsupported extension in
> > >the response and the client is willing to accept a
> > response w/o
> > >a nonce. This preserves the semantics for current clients and
> > >still allows caching servers to supply responses to clients
> > >who will take them.
> > >
> > >Regards,
> > >Ambarish
> >



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2LJiib052756 for <[e-mail]>; Tue, 2 Dec 2003 13:19:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2LJiiR052755 for ietf-pkix-bks; Tue, 2 Dec 2003 13:19:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2LJgib052750 for <[e-mail]>; Tue, 2 Dec 2003 13:19:43 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hB2LJiau009271 for <[e-mail]>; Tue, 2 Dec 2003 16:19:44 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 16:19:39 -0500
Message-ID: <00a601c3b91a$01cb3a10$[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, Build 10.0.4510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

David:

I agree.  There is no need for the added complexity.

-----Original Message-----
From: David Engberg [mailto:[e-mail]] 
Sent: Tuesday, December 02, 2003 3:37 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: DISCUSS: MUST reject in OCSPv1



Santosh -

Would it be possible to achieve this same result using the existing 
"nextUpdate" mechanism instead of adding a new nonce-related expiration 
time ("supportedAt")?

If I have a caching-only responder that plans to support nonces in 4 
hours, I could pre-generate the OCSP responses with a "nextUpdate" for 
that scheduled time.  These responses will automatically be rejected by 
any OCSP software (backward compatible) in 4 hours when nonces are 
supported.

(Going the other direction from nonce to nonceUnsupported isn't a 
problem, obviously.)

Thanks,
Dave


Santosh Chokhani wrote:

> 3.  It will nice for the servers to be able to declare when they will 
> start supporting nonce.  In that case, ASN.1 could be revised as 
> follows:
> 
> OCSPNonce ::= CHOICE {
>         nonceValue  OCTET STRING,
>         unsupported  NULL,
>         supportedAt  GENERALIZED TIME }
> 
> Option 3 does not commit the server to start supporting nonce's.  It 
> requires the server to start producing nonce's at that time or produce 
> new responses at that client.  A client SHOULD reject responses when 
> the current time is past the supportedAt time.
> 
> Option 3 reduces the temporal window of replay attack.
> 
> If there is a desire for option 3, the ASN.1 can be further compacted 
> by using 99991231235959Z in place of NULL for unsupported.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2KbQib045230 for <[e-mail]>; Tue, 2 Dec 2003 12:37:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2KbQ5c045229 for ietf-pkix-bks; Tue, 2 Dec 2003 12:37:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2KbMib045194 for <[e-mail]>; Tue, 2 Dec 2003 12:37:22 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08889; Tue, 2 Dec 2003 15:36:15 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rsa-pkalgs-01.txt
Date: Tue, 02 Dec 2003 15:36:15 -0500
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		: Additional Algorithms and Identifiers for RSA 
			  Cryptography for use in the Internet X.509 
			  Public Key Infrastructure Certificate and 
			  Certificate Revocation List (CRL) Profile
	Author(s)	: R. Housley, B. Kaliski
	Filename	: draft-ietf-pkix-rsa-pkalgs-01.txt
	Pages		: 22
	Date		: 2003-12-2
	
This document supplements RFC 3279.  It describes the conventions for
using the RSASSA-PSS signature algorithm, the RSAES-OAEP key
transport algorithm, and additional one-way hash functions with the
PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public
Key Infrastructure (PKI).  Encoding formats, algorithm identifiers,
and parameter formats are specified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-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-rsa-pkalgs-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-rsa-pkalgs-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-rsa-pkalgs-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rsa-pkalgs-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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2KbOib045219 for <[e-mail]>; Tue, 2 Dec 2003 12:37:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2KbOEI045217 for ietf-pkix-bks; Tue, 2 Dec 2003 12:37:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2KbMib045195 for <[e-mail]>; Tue, 2 Dec 2003 12:37:22 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08902; Tue, 2 Dec 2003 15:36:21 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-02.txt
Date: Tue, 02 Dec 2003 15:36:20 -0500
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:       
			  Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow
	Filename	: draft-ietf-pkix-certpathbuild-02.txt
	Pages		: 70
	Date		: 2003-12-2
	
This document was written to provide guidance and recommendations to 
developers building X.509 public-key certification paths within their 
applications.  By following the guidance and recommendations defined 
in this document, an application developer is more likely to develop 
a robust X.509 certificate enabled application that can build valid 
certification paths across a wide range of PKI environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-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-certpathbuild-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-certpathbuild-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-certpathbuild-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-certpathbuild-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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2Kb9ib045132 for <[e-mail]>; Tue, 2 Dec 2003 12:37:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2Kb9uH045131 for ietf-pkix-bks; Tue, 2 Dec 2003 12:37:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2Kb7ib045098 for <[e-mail]>; Tue, 2 Dec 2003 12:37:08 -0800 (PST) (envelope-from [e-mail])
Received: from corestreet.com (engberg.corestreet.com [192.168.2.87]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id hB2KalEj023977; Tue, 2 Dec 2003 15:36:48 -0500
Message-ID: <[e-mail]>
Date: Tue, 02 Dec 2003 15:36:48 -0500
From: David Engberg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
References: <004e01c3b90e$2fad8ed0$[e-mail]>
In-Reply-To: <004e01c3b90e$2fad8ed0$[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>

Santosh -

Would it be possible to achieve this same result using the existing 
"nextUpdate" mechanism instead of adding a new nonce-related expiration 
time ("supportedAt")?

If I have a caching-only responder that plans to support nonces in 4 
hours, I could pre-generate the OCSP responses with a "nextUpdate" for 
that scheduled time.  These responses will automatically be rejected by 
any OCSP software (backward compatible) in 4 hours when nonces are 
supported.

(Going the other direction from nonce to nonceUnsupported isn't a 
problem, obviously.)

Thanks,
Dave


Santosh Chokhani wrote:

> 3.  It will nice for the servers to be able to declare when they will start
> supporting nonce.  In that case, ASN.1 could be revised as follows: 
> 
> OCSPNonce ::= CHOICE {
>         nonceValue  OCTET STRING,
>         unsupported  NULL,
>         supportedAt  GENERALIZED TIME }
> 
> Option 3 does not commit the server to start supporting nonce's.  It
> requires the server to start producing nonce's at that time or produce new
> responses at that client.  A client SHOULD reject responses when the current
> time is past the supportedAt time.
> 
> Option 3 reduces the temporal window of replay attack. 
> 
> If there is a desire for option 3, the ASN.1 can be further compacted by
> using 99991231235959Z in place of NULL for unsupported.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2JtKib037524 for <[e-mail]>; Tue, 2 Dec 2003 11:55:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2JtKu8037523 for ietf-pkix-bks; Tue, 2 Dec 2003 11:55:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2JtJib037514 for <[e-mail]>; Tue, 2 Dec 2003 11:55:19 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id hB2Jstau024008 for <[e-mail]>; Tue, 2 Dec 2003 14:55:08 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 14:54:49 -0500
Message-ID: <004e01c3b90e$2fad8ed0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hB2JtKib037518
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>

Mike and Russ:

One topic that has not been discussed is what if the server switches back
and forth from nonce supported and "not supported".  May be server supports
nonce during working hours and not during non-working hours.

Seems like we have the following options:

1.  Servers shall not switch.  If that is the case, the RFC should state
that.

2.  Servers can do this ad hoc.  Clients need not be notified.  In that
case, no change is required.

3.  It will nice for the servers to be able to declare when they will start
supporting nonce.  In that case, ASN.1 could be revised as follows: 

OCSPNonce ::= CHOICE {
        nonceValue  OCTET STRING,
        unsupported  NULL,
        supportedAt  GENERALIZED TIME }

Option 3 does not commit the server to start supporting nonce's.  It
requires the server to start producing nonce's at that time or produce new
responses at that client.  A client SHOULD reject responses when the current
time is past the supportedAt time.

Option 3 reduces the temporal window of replay attack. 

If there is a desire for option 3, the ASN.1 can be further compacted by
using 99991231235959Z in place of NULL for unsupported.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Michael Myers
Sent: Tuesday, December 02, 2003 11:08 AM
To: Russ Housley; [e-mail]
Subject: RE: DISCUSS: MUST reject in OCSPv1



> -----Original Message-----
> From: Russ Housley
> Sent: Tuesday, December 02, 2003 6:42 AM
>
>
>     OCSPNonce ::= CHOICE {
>        nonceValue  OCTET STRING,
>        unsupported  NULL }

Russ,

More precisely, based on the prior proposal, we have:

1. Cycle v1 at Proposed with the above
   amendment to nonce value syntax and
   the following semantics.

2. Clients that send a nonce:

   a. SHALL use the nonceValue CHOICE of
      OCSPNonce value syntax.

   b. MUST reject a response that fails
      to include the nonce extension
      (errors notwithstanding);

   c. Else, if such response includes a
      nonce extension with a value of
      "unsupported", clients MAY accept the
      response subject to the advice in the
      Security Considerations section of
      this document.

4. Conversely, if a server receives a nonced
   request but is unable to incorporate the
   nonce in its response, the server MUST
   include a nonce extension with the value
   "unsupported" for OCSPNonce.

So basically, it is pretty much the same semantics as previously proposed,
only using the "unsupported" CHOICE for OCSPNonce as the caveat instead of
an extension-based OID of "unsupported".

Is this what you had in mind?  Note that we still have a "MUST reject" for
plain responses.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2Jgeib036947 for <[e-mail]>; Tue, 2 Dec 2003 11:42:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2Jgebp036945 for ietf-pkix-bks; Tue, 2 Dec 2003 11:42:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2Jgeib036940 for <[e-mail]>; Tue, 2 Dec 2003 11:42:40 -0800 (PST) (envelope-from [e-mail])
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.10/) with ESMTP id hB2Jggrc006079 for <[e-mail]>; Tue, 2 Dec 2003 11:42:42 -0800 (PST)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <XLQFBR77>; Tue, 2 Dec 2003 11:42:41 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: [e-mail]
Subject: Lightweight OCSP Profile for high volume environments...
Date: Tue, 2 Dec 2003 11:42:34 -0800 
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>

All,

On a related topic, we (Ryan and myself) have recently submitted an
informational internet-draft which describes a lightweight profile of OCSP
(RFC 2560) for use in very large PKI deployments such as SSL/TLS, code
signing and secure messaging. (i.e. environments where pre-produced and
distributed responses may be desirable).  

http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile-00
.txt

Alex


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2JXJib036528 for <[e-mail]>; Tue, 2 Dec 2003 11:33:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2JXJBt036527 for ietf-pkix-bks; Tue, 2 Dec 2003 11:33:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2JXIib036522 for <[e-mail]>; Tue, 2 Dec 2003 11:33:18 -0800 (PST) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id hB2JXIq6009271; Tue, 2 Dec 2003 11:33:18 -0800 (PST)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <XHBNDL3V>; Tue, 2 Dec 2003 11:33:18 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 11:33:15 -0800 
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>

But doesn't this ASN.1 additon make the interop issues with the existing
deployed client/server base even worse?  Its still not clear how we can
justify making such a large normative change to v1 at this point in the
process.  This spec has been at proposed for almost 4.5 years (!) now.

Alex




 

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]] 
> Sent: Tuesday, December 02, 2003 8:08 AM
> To: Russ Housley; [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> > -----Original Message-----
> > From: Russ Housley
> > Sent: Tuesday, December 02, 2003 6:42 AM
> >
> >
> >     OCSPNonce ::= CHOICE {
> >        nonceValue  OCTET STRING,
> >        unsupported  NULL }
> 
> Russ,
> 
> More precisely, based on the prior proposal, we have:
> 
> 1. Cycle v1 at Proposed with the above
>    amendment to nonce value syntax and
>    the following semantics.
> 
> 2. Clients that send a nonce:
> 
>    a. SHALL use the nonceValue CHOICE of
>       OCSPNonce value syntax.
> 
>    b. MUST reject a response that fails
>       to include the nonce extension
>       (errors notwithstanding);
> 
>    c. Else, if such response includes a
>       nonce extension with a value of
>       "unsupported", clients MAY accept the
>       response subject to the advice in the
>       Security Considerations section of
>       this document.
> 
> 4. Conversely, if a server receives a nonced
>    request but is unable to incorporate the
>    nonce in its response, the server MUST
>    include a nonce extension with the value
>    "unsupported" for OCSPNonce.
> 
> So basically, it is pretty much the same semantics as 
> previously proposed, only using the "unsupported" CHOICE for 
> OCSPNonce as the caveat instead of an extension-based OID of 
> "unsupported".
> 
> Is this what you had in mind?  Note that we still have a 
> "MUST reject" for plain responses.
> 
> Mike
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2J18ib034297 for <[e-mail]>; Tue, 2 Dec 2003 11:01:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2J18xs034296 for ietf-pkix-bks; Tue, 2 Dec 2003 11:01:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sigurd.x509.com ([199.175.155.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB2J17ib034291 for <[e-mail]>; Tue, 2 Dec 2003 11:01:07 -0800 (PST) (envelope-from [e-mail])
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Dec 2003 19:01:09 UT
Received: from crack.x509.com (localhost [127.0.0.1]) by nebula.x509.com (8.12.10/NULL) with ESMTP id hB2Iv66L016507 for <[e-mail]>; Tue, 2 Dec 2003 10:57:07 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.12.10/8.12.10) with ESMTP id hB2J17Y0013952 for <[e-mail]>; Tue, 2 Dec 2003 11:01:07 -0800 (PST)
Received: from rsasecurity.com (mbranchaud2.eng.x509.com [10.7.33.48]) by exvan01.x509.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VQFWHT7J; Tue, 2 Dec 2003 11:10:01 -0800
Message-ID: <[e-mail]>
Date: Tue, 02 Dec 2003 10:51:11 -0800
X-Sybari-Trust: d5f3b416 64c784fd 5697006d 00000139
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: OCSP in TLS handshake
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050108080502020100020109"
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.

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

Deacon, Alex wrote:
> 
> As for the nonceUnsupported proposal, it does have it merits. However
> I have to agree with Ryan by objecting to its standardization in v1
> for two reasons.  First, doing so will not allow for the "TLS 
> Extension" use case where OCSP responses are included in protocol 
> exchanges.

I'm not trying to be obtuse here (it actually takes very little effort), 
but I really need a patient explanation of why nonceUnsupported 
precludes the use of OCSP responses in the TLS handshake.

		M.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISqTCC
AtcwggJAoAMCAQICEFgUQCxch7Sxp7XFFauIqpwwDQYJKoZIhvcNAQEFBQAwbDEaMBgGA1UE
ChMRUlNBIFNlY3VyaXR5IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEu
MCwGCSqGSIb3DQEJARYfcnNha2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTAeFw0wMjA5
MDYxNDEzNTJaFw0wNzA5MDYxNDEzNTJaMIGCMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5j
LjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMRYwFAYDVQQDEw1SU0EgQ29ycG9yYXRlMRAwDgYD
VQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqnOw876lPpMTkSqrqzpEON/609PDLEhmWX4tkC19
AHneDaoetL277GtYYXBCggP2E+s66MN1ccWXyApfWjCZkIHepPC08NVI1JRcbViW3kwLzDD2
w5T9QJcyL5V1pN/LQdxahM56TiLeXlPiJekdmTdJoo+5Pw4bQU+MxTqURk8CAwEAAaNjMGEw
HwYDVR0jBBgwFoAU9UwxelEDPyzXi5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvah
HSJwJp8KrxaSMA8GA1UdEwQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEB
BQUAA4GBAHiSe1a79hnPr16PuBwUTBWbuNQ4GJNsyfrCXzAswIT2A2WtGZ1Hp1jEAWi9OfAX
IYAdy52Jyv9N87wAEbLUgVmsFEIlYM5mi6ag7YIRGp8JP5UhLAN9O5YHrR9FsrGK4WmSl3sY
W1qAPOXubFcfhTgUDIYzM30izZBP4nwO07FpMIIC+DCCAmGgAwIBAgIQeuiOriTayCwjwpmR
gmdIUjANBgkqhkiG9w0BAQUFADCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTAT
BgNVBAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMH
QmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDIwOTIz
MTkxMzAzWhcNMDYwOTIzMTUxMzAzWjCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4x
FTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYT
AlVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkR9yiabyRo6+NwC3Sl8wPuUiBD3rP
sENNjXvzSbTAyXA8pDDndnlAa1nLUhSMgvn8g1sYMd0Bp+C1/mI5PFUZ8jukUK95yt+TK26L
hM/M5RUq/EINdDDdWzg9je498K6oGfyWR6ETSJbIrDe5qQcLCABs9E2gVKb7Z/FwFo3C9QID
AQABo2MwYTAPBgNVHRMECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBTt
kQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y3iHyn6cwDQYJ
KoZIhvcNAQEFBQADgYEAcdRHBjq8GfdDoutUTJPtSzQd7XsdsQh2KBbu8utl92VQHuI0J5wc
Rc817G8YbmTtCt/xqAzrr6k7fdaoDBr/kBuVHA5FEJ94foPgrOlbT3zdziMATXh5ESSDLMx6
p8ITIsTJNmwszIG5P9AAKJCW48gu1ZZmLXhFbHcYJGf99pwwggMFMIICbqADAgECAhEAvhyf
0s21hKaAc2Nm1WX4LTANBgkqhkiG9w0BAQUFADCBuzEkMCIGA1UEBxMbVmFsaUNlcnQgVmFs
aWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFs
aUNlcnQgQ2xhc3MgMyBQb2xpY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0
dHA6Ly93d3cudmFsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5j
b20wHhcNMDIwNDMwMTUzMDE5WhcNMTkwNDMwMDkyMTU1WjBsMRowGAYDVQQKExFSU0EgU2Vj
dXJpdHkgSW5jLjEeMBwGA1UEAxMVUlNBIFB1YmxpYyBSb290IENBIHYxMS4wLAYJKoZIhvcN
AQkBFh9yc2FrZW9ucm9vdHNpZ25AcnNhc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQC0dSVa2EQ740GxqiIKsHATT4f8XYwUU23pzRe5W6IVpt4jkwDWkgnvTcP6
M8PD4OfK6Imal4hAH/c3K/dUIH7YyQZRGAE5Y27G5klZYKidcFlrfautgVES170MLKFmJqym
2FWAfVOibXatRcw7B0S+mP9404jID/MaIpRXkH5JjwIDAQABo1cwVTAMBgNVHRMEBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATAdBgNVHQ4EFgQU9Uwx
elEDPyzXi5eZb6hxkKt4PZswDQYJKoZIhvcNAQEFBQADgYEAKsviXBc1FeBT2hIwyWuGwnPZ
J9ctjrsO7NbVLjsx/EYclFFGwo+pphiwdUTml9yd7fXzfk0D+7LOs9ZA5xhiHVrGusV4OW4i
7hx2KVILkYlcXCN5tDltKwa5+BkGUuvZdyAoIhpyf61h7uKCFguhaJ+VOiNB4DPtsmxI+KxO
E6YwggTYMIIEQaADAgECAhBgzHl9dAoZGu0JMqXovSgdMA0GCSqGSIb3DQEBBQUAMIGMMRow
GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYD
VQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UE
CBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODEzWhcNMDQwNzA3
MjMwODEzWjCBvjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3JzYXNl
Y3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGggQW1l
cmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDk1hcmMgQnJhbmNoYXVkMScw
JQYJKoZIhvcNAQkBFhhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDg2xoRr+a/dtnuFG+oTHa+tGtzeObFazNhYV2iSLNED4fHRu86
tknBYFgXggcHW5gsyjfkCtVMzP2tCivmbJgvISo36vsCsmAJH6LRnJf8HsvfmWZaD9tzhDpL
QVsBHr88J0ZMdVniRc7MQoYeu/3hYtUBeGO9bGA6T8vTrnXYonnFtVoTqE62SFqPZZk7HpCS
X1n+dM3zSym2ylMFYE14nukF4I9vAhsQVzk3QNpghmzGj8uoEy9xpf3k0o5+neneAGvcSkwo
r1mH5tSqhrEQaZp7vuSA2bvXaZEnjZzZiTpPDzs1oMpn3guzYhU7wMKz6xvwvgEYyAAV+P5n
FWM/AgMBAAGjggGBMIIBfTCBkgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwIwdzAuBggrBgEF
BQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5
MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMCAQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJl
bmNlMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBDAjBgNVHREE
HDAagRhtYXJjbmFyY0Byc2FzZWN1cml0eS5jb20wDgYDVR0PAQH/BAQDAgeAMEYGA1UdHwQ/
MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNv
bmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQ1
yQ/UrvKb563LjzHqJzBzrZp/ejANBgkqhkiG9w0BAQUFAAOBgQCV82oGGnglQQzklKg/wKhy
evNeJ6FNBZFhLlmZRNlKgqvPFmBcxygfBGpHqIhsHcrt2/AjhJuzAj7UdW1vTVCY5MkZw8P9
6+J6aTc3bNlGbk0jvcvVgDhmM4xYJLwMZKEw92HlRhfuMnj7ah9DTqbKSewmyAyOc+FLpGfd
lu6CgTCCBOkwggRSoAMCAQICEQDqxAXqre9Mr+FeYw3+MQhsMA0GCSqGSIb3DQEBBQUAMIGM
MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAw
HgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQG
A1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMDMwNzA3MjMwODI4WhcNMDQw
NzA3MjMwODEzWjCBwjETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC3Jz
YXNlY3VyaXR5MRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEWMBQGA1UECxMNTm9ydGgg
QW1lcmljYTEUMBIGA1UECxMLRW5naW5lZXJpbmcxGzAZBgNVBAMTEk1hcmMgQnJhbmNoYXVk
LUVuYzEnMCUGCSqGSIb3DQEJARYYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBjNaHTwtCXpdJg+iDxYMkWjuZIF0ic2fRLymZe+
BnZYWPnik0dFmTulx+V8slsLEtBllcc5o1yfIYfeHPinwRxv86kCUSlgfGGXKjJZaIeURgbo
bUbIfDTPlvRUZuiZvTR4C8tEY88Lle66n62B7wjUvDbiwK4EjzlXOkjpcYXLH7FbaFaRLDBB
PlFD5ydDRhQ67t6fjUeS7p7o/l/VHmPC5LFLXZkjEhjGd5pknbQIAbUGACL5UET85NUFPowD
3F47g0GCKEnuOsk2Ra+WHu7honhIxqmOwGnu85V6tW5xscf4dTofWZONQeaD3gSxv8+hcfKN
k9cwjpnUG2xGzwIDAQABo4IBjTCCAYkwNQYDVR0lBC4wLAYKKwYBBAGCNxQCAgYIKwYBBQUH
AwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHAjB3
MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsG
AQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBi
eSByZWZlcmVuY2UwIwYDVR0RBBwwGoEYbWFyY25hcmNAcnNhc2VjdXJpdHkuY29tMEYGA1Ud
HwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQW
BBT/OiMCyY8CPnNBySW1ijJOYhj7ejAOBgNVHQ8BAf8EBAMCAzgwDQYJKoZIhvcNAQEFBQAD
gYEAlchAObA9eVmeiLu0nTU985Fch6v+EZKodUhZUN7dILgd05HorHN9jxBH6XI4/b9ZVvub
Pkpicdc112YbcLYTD2NumVksyNDI7fDaqiszgk1zluXtZJ+HsCt+GIAKCDfOVLECclpGyizq
VjZFEK4Pt9FxPGTnUJEvIKJcAQ24EvgxggPsMIID6AIBATCBoTCBjDEaMBgGA1UEChMRUlNB
IFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENs
YXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1
c2V0dHMxCzAJBgNVBAYTAlVTAhBgzHl9dAoZGu0JMqXovSgdMAkGBSsOAwIaBQCgggIfMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIwMjE4NTExMVow
IwYJKoZIhvcNAQkEMRYEFK+xFsYPqCdYU8ZveuaekyrrwRlUMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAy
IFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MQswCQYDVQQGEwJVUwIRAOrEBeqt70yv4V5jDf4xCGwwgbUGCyqGSIb3DQEJEAILMYGloIGi
MIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2Vz
MSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEQDqxAXqre9Mr+FeYw3+MQhs
MA0GCSqGSIb3DQEBAQUABIIBAE1IR5Hg2FgcegPp8Aq5d2U5N7/tQQmp1wYFQflDuAA63lMg
lUKflBxw+lmOzgL1Ex0IUoYNde2RpFe6t3JELxQX00EfpXile15hDrads0xmihzl5wrS/XBn
pPJzlSvvZCUc50spdGm88Cr2eqUp0k9Kd/umkAqdKwGH2JIRQLVZRr/Jd3PNa9I0nyJ1K9h4
UTtzSCrC++04PMuH/TT91v4AbO5cbEw1AZHdZr7lrWd8wOa81OfkPTHDD4wlhT1/REhv0DvO
ZaFtl6SEshuJ1aYeulArVacawCybNskpNIPJ7ilmf2tWPcXsJNS7ovFRO3OTRU6zmHe75jfx
IDoD3ykAAAAAAAA=
--------------ms050108080502020100020109--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2G5Vib025549 for <[e-mail]>; Tue, 2 Dec 2003 08:05:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2G5VRr025547 for ietf-pkix-bks; Tue, 2 Dec 2003 08:05:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2G5Uib025542 for <[e-mail]>; Tue, 2 Dec 2003 08:05:30 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hB2G5UA03955; Tue, 2 Dec 2003 09:05:30 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 09:07:38 -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>

> -----Original Message-----
> From: Russ Housley
> Sent: Tuesday, December 02, 2003 6:42 AM
>
>
>     OCSPNonce ::= CHOICE {
>        nonceValue  OCTET STRING,
>        unsupported  NULL }

Russ,

More precisely, based on the prior proposal, we have:

1. Cycle v1 at Proposed with the above
   amendment to nonce value syntax and
   the following semantics.

2. Clients that send a nonce:

   a. SHALL use the nonceValue CHOICE of
      OCSPNonce value syntax.

   b. MUST reject a response that fails
      to include the nonce extension
      (errors notwithstanding);

   c. Else, if such response includes a
      nonce extension with a value of
      "unsupported", clients MAY accept the
      response subject to the advice in the
      Security Considerations section of
      this document.

4. Conversely, if a server receives a nonced
   request but is unable to incorporate the
   nonce in its response, the server MUST
   include a nonce extension with the value
   "unsupported" for OCSPNonce.

So basically, it is pretty much the same semantics as previously
proposed, only using the "unsupported" CHOICE for OCSPNonce as
the caveat instead of an extension-based OID of "unsupported".

Is this what you had in mind?  Note that we still have a "MUST
reject" for plain responses.

Mike



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2Fg2ib024669 for <[e-mail]>; Tue, 2 Dec 2003 07:42:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2Fg2U5024668 for ietf-pkix-bks; Tue, 2 Dec 2003 07:42:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2Fg2ib024656 for <[e-mail]>; Tue, 2 Dec 2003 07:42:02 -0800 (PST) (envelope-from [e-mail])
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id hB2Fft2B024430; Tue, 2 Dec 2003 07:41:55 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 07:48:03 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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 Russ,
    This would *definitely* break compatibility with exisiting
software.

Currently, some folks put in some random bytes as the value of
the nonce extension, while others put in an OCTET STRING, whose value is
the random bytes.

The only check the clients do, is verify that the request contains
the same set of bytes.

Servers that include the nonce in the response include the bytes
they got in the request in the response.

The solution suggested by Mike would allow current servers and clients
to work as they do, and allow a way for smarter servers/clients to
work together where a server wanted to provide a response without the
nonce.

If we wanted to break compatibility, it would make more sense to use the
criticality bit in extensions (as suggested by others on the list).

Regards,
Ambarish

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Russ Housley
> Sent: Tuesday, December 02, 2003 5:42 AM
> To: [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> I am not very happy with the way that this discussion is going.  I am not
> convinced that a new extension is the best compromise.
>
> I have just reread the nonce-related portions of RFC 2560.  I
> must say, it
> is quite under specified.  It does not even provide a syntax for a
> nonce.  It really only provides the OID to identify the nonce
> extension and
> which extension location in which it is carried.
>
> It says:
>
>     The nonce cryptographically binds a request and a response to prevent
>     replay attacks. The nonce is included as one of the requestExtensions
>     in requests, while in responses it would be included as one of the
>     responseExtensions. In both the request and the response, the nonce
>     will be identified by the object identifier id-pkix-ocsp-nonce, while
>     the extnValue is the value of the nonce.
>
>     id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
>
> Rather than defining a new extension, called nonceUnsupported,
> you have the
> opportunity to specify a syntax to go with this OID that does the same
> thing.  Something like:
>
>     OCSPNonce ::= CHOICE {
>        nonceValue  OCTET STRING,
>        unsupported  NULL }
>
> Text that goes with the syntax definition ought to make it
> illegal for the
> request to use the NULL.  That is, it is only allowed in the response.
>
> I still prefer the "MUST reject" approach, but this seems like a cleaner
> solution than a new extension.
>
> Russ
>
>
> Ambarish wrote:
>
> >Hi Florian,
> >    The reason for including a nonce in the request is to enable a
> >client that doesn't have a very precise knowledge of time to still
> >be sure the response he got from the server was generated for this
> >specific request.
> >
> >While I do agree with Mark and think that the "right" way would be
> >to require the client to require the nonce in the response, in the
> >interests of moving ahead, I vote to accept Mike's compromise
> >proposal that a client MUST require the nonce in the response
> >unless it is accompanied by a nonceUnsupported extension in
> >the response and the client is willing to accept a response w/o
> >a nonce. This preserves the semantics for current clients and
> >still allows caching servers to supply responses to clients
> >who will take them.
> >
> >Regards,
> >Ambarish
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2FVIib023904 for <[e-mail]>; Tue, 2 Dec 2003 07:31:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2FVIgW023903 for ietf-pkix-bks; Tue, 2 Dec 2003 07:31:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2FVHib023898 for <[e-mail]>; Tue, 2 Dec 2003 07:31:17 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id hB2FVGA01602; Tue, 2 Dec 2003 08:31:17 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 08:33:24 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
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>

Russ,

So if I'm reading this correctly, a server that receives a
request containing a value for nonceValue MAY ignore the nonce
and return NULL?

By the way, Ambarish and I had already planned to clarify nonce
syntax as OCTET STRING as 2560 goes from Proposed to Draft.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Russ Housley
> Sent: Tuesday, December 02, 2003 6:42 AM
> To: [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> I am not very happy with the way that this discussion
> is going.  I am not
> convinced that a new extension is the best compromise.
>
> I have just reread the nonce-related portions of RFC
> 2560.  I must say, it
> is quite under specified.  It does not even provide a
> syntax for a
> nonce.  It really only provides the OID to identify
> the nonce extension and
> which extension location in which it is carried.
>
> It says:
>
>     The nonce cryptographically binds a request and a
> response to prevent
>     replay attacks. The nonce is included as one of
> the requestExtensions
>     in requests, while in responses it would be
> included as one of the
>     responseExtensions. In both the request and the
> response, the nonce
>     will be identified by the object identifier
> id-pkix-ocsp-nonce, while
>     the extnValue is the value of the nonce.
>
>     id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= {
> id-pkix-ocsp 2 }
>
> Rather than defining a new extension, called
> nonceUnsupported, you have the
> opportunity to specify a syntax to go with this OID
> that does the same
> thing.  Something like:
>
>     OCSPNonce ::= CHOICE {
>        nonceValue  OCTET STRING,
>        unsupported  NULL }
>
> Text that goes with the syntax definition ought to
> make it illegal for the
> request to use the NULL.  That is, it is only allowed
> in the response.
>
> I still prefer the "MUST reject" approach, but this
> seems like a cleaner
> solution than a new extension.
>
> Russ
>
>
> Ambarish wrote:
>
> >Hi Florian,
> >    The reason for including a nonce in the request
> is to enable a
> >client that doesn't have a very precise knowledge of
> time to still
> >be sure the response he got from the server was
> generated for this
> >specific request.
> >
> >While I do agree with Mark and think that the
> "right" way would be
> >to require the client to require the nonce in the
> response, in the
> >interests of moving ahead, I vote to accept Mike's compromise
> >proposal that a client MUST require the nonce in the response
> >unless it is accompanied by a nonceUnsupported extension in
> >the response and the client is willing to accept a
> response w/o
> >a nonce. This preserves the semantics for current clients and
> >still allows caching servers to supply responses to clients
> >who will take them.
> >
> >Regards,
> >Ambarish
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2Dh3ib019077 for <[e-mail]>; Tue, 2 Dec 2003 05:43:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB2Dh38s019076 for ietf-pkix-bks; Tue, 2 Dec 2003 05:43:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB2Dh2ib019068 for <[e-mail]>; Tue, 2 Dec 2003 05:43:02 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 31492 invoked by uid 0); 2 Dec 2003 13:42:23 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.95.142) by woodstock.binhost.com with SMTP; 2 Dec 2003 13:42:23 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 02 Dec 2003 08:42:27 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
In-Reply-To: <OF86404AF5.A8C6A80E-ON85256DEF.0066D6ED-85256DEF.0066F0EF@ db.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>

I am not very happy with the way that this discussion is going.  I am not 
convinced that a new extension is the best compromise.

I have just reread the nonce-related portions of RFC 2560.  I must say, it 
is quite under specified.  It does not even provide a syntax for a 
nonce.  It really only provides the OID to identify the nonce extension and 
which extension location in which it is carried.

It says:

    The nonce cryptographically binds a request and a response to prevent
    replay attacks. The nonce is included as one of the requestExtensions
    in requests, while in responses it would be included as one of the
    responseExtensions. In both the request and the response, the nonce
    will be identified by the object identifier id-pkix-ocsp-nonce, while
    the extnValue is the value of the nonce.

    id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

Rather than defining a new extension, called nonceUnsupported, you have the 
opportunity to specify a syntax to go with this OID that does the same 
thing.  Something like:

    OCSPNonce ::= CHOICE {
       nonceValue  OCTET STRING,
       unsupported  NULL }

Text that goes with the syntax definition ought to make it illegal for the 
request to use the NULL.  That is, it is only allowed in the response.

I still prefer the "MUST reject" approach, but this seems like a cleaner 
solution than a new extension.

Russ


Ambarish wrote:

>Hi Florian,
>    The reason for including a nonce in the request is to enable a
>client that doesn't have a very precise knowledge of time to still
>be sure the response he got from the server was generated for this
>specific request.
>
>While I do agree with Mark and think that the "right" way would be
>to require the client to require the nonce in the response, in the
>interests of moving ahead, I vote to accept Mike's compromise
>proposal that a client MUST require the nonce in the response
>unless it is accompanied by a nonceUnsupported extension in
>the response and the client is willing to accept a response w/o
>a nonce. This preserves the semantics for current clients and
>still allows caching servers to supply responses to clients
>who will take them.
>
>Regards,
>Ambarish



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB28gaib084774 for <[e-mail]>; Tue, 2 Dec 2003 00:42:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB28gaTw084773 for ietf-pkix-bks; Tue, 2 Dec 2003 00:42:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ddba033.netstream.ch (ddba033.netstream.ch [62.65.128.33]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB28gVib084724 for <[e-mail]>; Tue, 2 Dec 2003 00:42:34 -0800 (PST) (envelope-from [e-mail])
Received: from [62.65.151.222] (helo=swisssign.com) by ddba033.netstream.ch with esmtp (Exim 4.10) id 1AR66z-00097v-00; Tue, 02 Dec 2003 09:42:25 +0100
Message-ID: <[e-mail]>
Date: Tue, 02 Dec 2003 09:42:06 +0100
From: Joseph Doekbrijder <[e-mail]>
Organization: SwissSign AG
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-ch, en-us, en, fr-ch
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: An advice to a commercial CA
References: <01fc01c3b366$8707d760$[e-mail]> <002601c3b3fc$1d25e8a0$0500a8c0@arport> <p06010203bbea6ed9a3e9@[128.89.89.75]> <006601c3b44f$66f98330$0500a8c0@arport> <[e-mail]> <00e201c3b4de$2ab65e40$0500a8c0@arport>
In-Reply-To: <00e201c3b4de$2ab65e40$0500a8c0@arport>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060907010202070508090502"
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.

--------------ms060907010202070508090502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

A root key always deserves the lowest level of trust since whatever it 
signs is accepted by the RP.
The clue of the matter is that the RP should not just accept the root, 
but instead the issuing CA as trusted issuing party.
an example

tree / liability
-----/ -----
root / 0
signs  
bronze / 0
signs
silver / 1'000
signs
gold / 10'000
signs
platinum / 100'000
signs
qualified /  1'000'000

with this hierarchy an RP can say "my application (ex: web shop) 
requires silver or better" and thus accept the silver CA. If an RP 
decides to only accept gold level certs (for whatever reason, maybe 
liability) he should never accept the Root key.

This way a CA can decide to provide requesters with a certain level of 
certificate, meant for certain types of transactions (buying a CD vs 
booking hollidays vs or e-voting). And thus fullfill a business case.
The requesters can choose to purchase a cert of a certain quality 
allowing for certain types of transactions independent from the provider 
of these certs.
The RP can look at the cert and base his sell or no-sell decission on 
the cert quality. Also becomming independent of the issuing party.

All this requires, is a verifyable definition of Bronze, Silver, Gold, 
Platinum, Qualified. All issuing parties that are able to offer certs of 
a certain level get "audited" regularly and published to provide 
subscribers and RP's a decission aid. Issuing parties no longer being 
able to offer a certain quality loose their "quality seal" and probably 
their subscribers

regarding the the two different "expensive" issuances.
Here in detail it actually looks like this

signs
silver
signs
silver P(ersonal) and silver S(ervices) and X(xxx)..... and
Gold

Silver, with its sub CA's becomes a level having certain characteristics 
like liability. Thus organisations can choose for a certain level and 
then outsource their entire PKI realizing that registration, liability 
and whatever other elements are important, fit their requirements. This 
is very attractive for an industry that thus becomes independent of CA's 
while determining the minimum requirements of the certs they are willing 
to work with.

RP's actually like this. All they have to decide on is what level of 
certs they are willing to accept. if the cert is of the right level the 
root key of the issuing party no longer matters! trust is based on cert 
quality.

:-)

Looking forward to any feedback

Josh



Anders Rundgren wrote:

>Doesn't your scheme make an RP trusting the "expensive" CA
>also trust the "cheap" CA as they share a common root?
>
>And there could also be just two different "expensive" issuances
>that are incompatible like server-side SSL certs and certs for
>individuals.
>
>It looks to me that you move potential problems to the RP SW.
>Mathematically OK? For sure.  Standards-compliant?  For sure.
>But working?  Under strictly monitored conditions only.  Such
>conditions are unlikely to be met when you start to count RPs
>in the thousands and up.
>
>Anyway. several other folks on the list seem to agree that
>such schemes (including policy OID-enhanced path validation)
>only work in "managed" or "community" based PKIs.
>
>In my opinion the need for standards is much more evident
>in "unmanaged" spaces.
>
>Anders
>
>----- Original Message -----
>From: "Joseph Doekbrijder" <[e-mail]>
>To: "Anders Rundgren" <[e-mail]>
>Cc: "Stephen Kent" <[e-mail]>; <[e-mail]>
>Sent: Thursday, November 27, 2003 10:43
>Subject: Re: Straw poll: An advice to a commercial CA
>
>
>Only logical thing to do is a single root, signing the cheap CA which in
>its turn signs the expensive CA.
>Mathematically correct, includes trust logic, liability levels etc, etc...
>
>This is how we do it. :-)
>
>Cheers
>
>Josh
>
>
>Anders Rundgren wrote:
>
>  
>
>>Well,
>>Since the list is close to "vibrant" with emotions, why not
>>put RFC3280 through the litmus test?
>>
>>Assume that you as PKI professionals would advice a commercial
>>TTP CA on how to configure their issuance for the following:
>>1. Free e-mail roundtrip-verification certficates.  Low insurance level
>>2. Expensive (high insurance level) multi-usage certificates for individuals
>>using strong verification procedures.
>>
>>Note: the service is to be launched ASAP and has the only
>>objective, making money by serving its subscribers well.
>>
>>Indicate your advice by the word in uppercase.
>>
>>SINGLE: A single root + possibly some CP OIDs to spice things up
>>MULTIPLE: Different roots
>>
>>Lets rock!
>>
>>
>>
>>    
>>
>--
>Joseph A. Doekbrijder
>--------------------------------------------------
>SwissSign AG
>Löwenstrasse 1, CH-8001 Zürich
>Tel: [phone] Mobil: [phone]
>www.swisssign.com
>--------------------------------------------------
>
>
>  
>

-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: [phone] Mobil: [phone]
www.swisssign.com
--------------------------------------------------


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXbDCC
A6kwggKRoAMCAQICCFyxMno/hKJgMA0GCSqGSIb3DQEBBQUAMGQxHDAaBgNVBAMTE1N3aXNz
U2lnbiBTaWx2ZXIgQ0ExIzAhBgkqhkiG9w0BCQEWFHNpbHZlckBzd2lzc3NpZ24uY29tMRIw
EAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMB4XDTAzMTAxMjExMzgyMloXDTE1MTAw
NjEzMzY1N1owYDEaMBgGA1UEAxMRU3dpc3NTaWduIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEW
EmdvbGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALLSn8w7oFQMQut0IZfPgpKO0yo4dGjJ
bOqNImHzxOi1PY0RxkRNhchKCOPtxIKLTSFRF+xjk7UFC92Ec5CeeU/7q8zbVg3mnXraJDca
B9Sq2Dm8SLhXksnqRDf0CnDXnZYjasBhd8D6ighp2ueeEHsleOKUYbzR9/oRS9zM902s39sL
ZhP3rfyUgBRVD1n0qq7oFERNRtpGgfaNrbfwRbRI7JUg+NQ/YO53sY74Bw8kSrKGNxaBB3sV
f7bbxWTcxiSezS8IAvOCbwnS4t0bzchn4lp6pI7kXUDqIQLFjSXI5+2qJLAecvyKawY7Ir7W
PywWEO86vknPL/vG3909Zc8CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFLRs9TBBLMA8kYw0J2P6Vbz857Q/MB8GA1UdIwQYMBaAFBL6DIFb
/3/RJdgeczA1D0YYNrJ1MA0GCSqGSIb3DQEBBQUAA4IBAQAxtKZakF6f0gCYxSWGsatUfty2
g4XhEdSIF2iHpvp6H8HAWgrxD/r5FpBLgcBW7yPe7SpTuqGNVrVZSR25Hx13L0QIr7PFvRG7
kJVyfYNSfmSiW5yPypk8LDWLx4+TwXvfj8LwNaGcEyQxBAUmlHHTsWjcN3HpGu6E3XVl3wFl
IRlw5ktztskx1aL1KxQLIZmBM/a+GEb21M5CmHD9dszrtlJnawjs0lrmthDrkopizLHtNCDi
U5YSTHy/pcujvBtTAO8E6ipEoJw21XtF7DEGJkiWolakpERiFGBO5r5avWCgoLgWdX6Zrqzt
AXlr5s2cWU/+1QY3HzM8EtbWeAngMIIDrjCCApagAwIBAgIIEEgLDERrLUUwDQYJKoZIhvcN
AQEFBQAwYDEaMBgGA1UEAxMRU3dpc3NTaWduIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdv
bGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDAeFw0w
MzEwMTIxMTU4MjJaFw0wNjEwMTIxMTU4MjJaMGkxIzAhBgNVBAMTGlN3aXNzU2lnbiBQZXJz
b25hbCBHb2xkIENBMSEwHwYJKoZIhvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5jb20xEjAQBgNV
BAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDGZp1oXB5kPBmQfvbqGcm/i5qlKmEVli+r0hcFjEkHbZ+2jE9M1SNTd+8tiCzefyrq
xud0qJ8YDH8KrMYHQ94yO+8sicLDdGjHQQ6LXC/qV0iapQtYKQ7FR7TCMkLOT6mE8WN7lCVW
wREXISxS7/9lSdIgRl4NNPZcjVVC2vVRXBvxdlBd+GK2pzlgVuDkkKMH9ZCWDV6+AHioaS5z
Yb99P33SDEa4ocoEAj2jCdJ0ABLgVWxUnzlED7zAwwcGCgvsjJHJuUFoJ1RlwHsqwMe5PPqy
j3zW2Kp8ni/WgJ8lDJGJuhbVLGjOSOhzViWOt4H6qj3qaxbqIGTWNUcKtpjTAgMBAAGjYzBh
MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTyNobPvaTWed8y
mYzQWWkdBZUshjAfBgNVHSMEGDAWgBS0bPUwQSzAPJGMNCdj+lW8/Oe0PzANBgkqhkiG9w0B
AQUFAAOCAQEArhxiYfa9i4inp2LgOCJotU2dGFlQdKNin6Ohw9wj2cGr8j814koTNNDxiKF/
27Pit+j2I9uBOoHae/AeIc6jz+ducFGqQ8v1l/J7q/F263HRMH31svgps+fd2p+18ohZdfMC
AxixpKRqcLTPyYrtkC1LoIVOxIdP4ukdfqFDyxfcGHAdHqGJwwStClhb0xFpCwFmGxeOT1eL
bAV1iPlE0AQfd64HY0GyTcUr+yv5CwEGP5lrPXxdo6eF/PlDLYZtvE5BxO1QKJNJnTGvcd19
WazA5m94o5FMcCYRXsHpYPbzGXXF1B43s8OSfNy+SPGgUJnyiBywxINl1XEFITIvwTCCA8Aw
ggKooAMCAQICCQDo8h6mwbv3LjANBgkqhkiG9w0BAQUFADB2MQswCQYDVQQGEwJDSDESMBAG
A1UEChMJU3dpc3NTaWduMTIwMAYDVQQDEylTd2lzc1NpZ24gQ0EgKFJTQSBJSyBNYXkgNiAx
OTk5IDE4OjAwOjU4KTEfMB0GCSqGSIb3DQEJARYQY2FAU3dpc3NTaWduLmNvbTAeFw0wMzEw
MDYxMzM2NTdaFw0xNTEwMDYxMzM2NTdaMGQxHDAaBgNVBAMTE1N3aXNzU2lnbiBCcm9uemUg
Q0ExIzAhBgkqhkiG9w0BCQEWFGJyb256ZUBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lz
c1NpZ24xCzAJBgNVBAYTAkNIMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwNE7
xmO7xNmdlODqLZd7W+gGTeEj00zeh2DMsy/Tnils5TH58CahM7+Mo5BTHGkra5skTjzJMCxF
nHdxYmsSgZq9Hgjfcm4GboSr0sWH2qnDOUAID6iusgNlkPrIFgFJRB+D3YQlGHfOKnjpbMM8
67W4IFVkLG4fy6E+3nTngSZQ4iB7n5pl05eV+6bBSCJpFiW53oHe34nYUblMTCRdFy3AP/Vm
ic2Q2UphjjUUj/ljs5TP6OMbp4z8CKAlikiKPTTFrSdvWs9Nf03C3oacjI0IO2vjyd8hbZeT
20tuSZu1vSKKSEjTxmM7nIziFSmKPQUORd9pRp/DSZeNfMjbbQIDAQABo2MwYTAOBgNVHQ8B
Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUcoCI7Z4LPa+pqGtPWhfi1KGO
ZSQwHwYDVR0jBBgwFoAUltdxzTkq1PyIsYqrU3hp749HfhYwDQYJKoZIhvcNAQEFBQADggEB
AKRX2YzRnkOzrcQjyN5iNa4xdoG8TEzLTHiXmsR9kEibK73CkUNvb9MMwyzJnihUfHdwfDw4
fGqsNiBs9V9xXCJ+wlE3aDrxQhrltEqXbys4Ld0VTqaeBxXHzCupsbm0hwgVen+ugFMsWyvk
r+0acJ9wWegGJ3TM2DBJOiKwL67qyM+odg068BDt6B9RikaWJY5XKIfpihJ72Yrem7xjXC6S
0zGTXvtHZSs8NbhzSPYKrXjap/warpzAwKj3AV+LmdHpuz/2SfPkgAp7M/evkeTElRHqBalk
KEUAMTYI1F08tMWGuHBkanl7Uzv7N5ioAwVpLQhV1NH9JG9CECAZhqgwggP4MIIC4KADAgEC
AgkA3pgncg3bHVUwDQYJKoZIhvcNAQEFBQAwZDEcMBoGA1UEAxMTU3dpc3NTaWduIEJyb256
ZSBDQTEjMCEGCSqGSIb3DQEJARYUYnJvbnplQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoTCVN3
aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMDEyMTEzNjMyWhcNMTUxMDA2MTMzNjU3WjBk
MRwwGgYDVQQDExNTd2lzc1NpZ24gU2lsdmVyIENBMSMwIQYJKoZIhvcNAQkBFhRzaWx2ZXJA
c3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMz3QXwh/nvpMabdHEk5CptaSV13UQjSfJq27Dab
l9jtvdKc89XRBewyhQh/pPW5vGKo9SoMoSq7eyaDRlB1vN7FPvI462Bv2T637rAh/uIolWXI
gQrz3TNbdKrz2b1qylWHSG/t7fGkM/Pi9PMxS3ZMRuPTPuHDFubKxAj8uGCd5Cc1a2sK1wTA
HIar4jJ4LMlrisOaleRQPaad+sA7LpiLaGVy9wTrDLFNpYd8/zi4Q6VwOQ/N5oBDlkW6pH0l
smk9ZXCLqDGf1zHU/GoVPtxlp2fDvbUBYNP/0n65U92bKex4cdFxLbLiCkGU67FB40M0fm5P
UZSi890suZ8T0UUCAwEAAaOBrDCBqTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB
/zAdBgNVHQ4EFgQUEvoMgVv/f9El2B5zMDUPRhg2snUwHwYDVR0jBBgwFoAUcoCI7Z4LPa+p
qGtPWhfi1KGOZSQwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cHM6Ly9zd2lzc3NpZ24ubmV0L2Nn
aS1iaW4vYXV0aG9yaXR5L2NybD9jYT1Ccm9uemUwDQYJKoZIhvcNAQEFBQADggEBAKmlVsVY
uuOGs5sWDTYJZEVQOaRbFN8zeM3qWK4xJmphYBkTrDSmAsH9OnBgx17CcsWc5MxTxhU0ef6U
S6A1pxLhYH5vmulwPak1HnLp/vdPQ5M/BGzZPyrFmhhBvh8TI8J7rHLY3loTt9q0R/gFiVvV
YTUfoIG5BsG1WnUQpWO9+fQoaFk8JMklm9oY02VNwTp6gDmCdkDyoljKxjgzfSaPePoX8XA+
qNPGpOSmP+Qc2uBBC/7G0v6roaAmbIPEwQ+Pinl4G1alPV5Tx5P4KtUU8uPUj5kZEJYMBUr0
EUQA/+aEF92SsYVwFbBGB8hr6grBb11imoLpW+TYzXQ9KckwggP/MIIC56ADAgECAghxv+3S
3YlILDANBgkqhkiG9w0BAQUFADBpMSMwIQYDVQQDExpTd2lzc1NpZ24gUGVyc29uYWwgR29s
ZCBDQTEhMB8GCSqGSIb3DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lz
c1NpZ24xCzAJBgNVBAYTAkNIMB4XDTAzMTAzMDEwNDAyN1oXDTA0MTAzMDEwNDAyN1owbzEb
MBkGA1UEAxMSSm9zZXBoIERvZWticmlqZGVyMS8wLQYJKoZIhvcNAQkBFiBqb3NlcGguZG9l
a2JyaWpkZXJAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJD
SDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANxqYj3gyEv57yU1uWzgJ45nMp3C
XPEcnoyT5z1rX9BM35qRMjxqnjOXHTSCi3Jt32WrwKs/mN5ZjVcbEwYCme90FcFSqs8of9I3
5o3WzDc1KlhyF1iyahUBQhU2Ckg2wEsgiEgUmSEjuSPjoCa2ggqI8FkGEwTVbDpgANA+9HSi
mzy33s/6kf38npd2ZlBfw3B9A/+hX28THS+JkvcaF3vQ0fAJ7xjanAjOGLbnJ/n0tT1gzI7Z
cMwrdZqSS5O92DPbNyB+iGyVDhE24C9lGaJNkwMYtCHFc2JIuHW0AhmunTUs6YFN/MIoIFqQ
8y95vAdt25eK/ECCt8aYABnLbrECAwEAAaOBpDCBoTAfBgNVHSMEGDAWgBTyNobPvaTWed8y
mYzQWWkdBZUshjBNBgNVHR8ERjBEMEKgQKA+hjxodHRwczovL3N3aXNzc2lnbi5uZXQvY2dp
LWJpbi9hdXRob3JpdHkvY3JsP2NhPVBlcnNvbmFsK0dvbGQwDgYDVR0PAQH/BAQDAgQwMB8G
A1UdJQQYMBYGCisGAQQBgjcKAwQGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQAE4D7D
QYdUJeZlOJIsLuqtVe6UV9qdBnWP0xtpGP6UNEtsbUlLxsQcUn3yTKT1pS5wXnIPXP6q7Nka
klClJGaqTiUqzgDgvzFZEAE/yn/hJW3FAh1fMI/8mg6TjUGZp9EfRuTRN95Vpx8Fplajj0gb
eq3LCmMhonTBkBDC8xC7MQNeMoNfwMwWV2CwYv/nYd4xQPJV+M6gbosQu8IkLZCwS1At/DGo
ZVIMT2oG9Dod42+BLoSo00hVBf7ZVYWu1kRKGW1Fpo9GKRz950e5wXyioqOsubTl3MawYc9R
5ruN2UpfyieybVgELxFJWctrxUMCbZt40TSU9BKagtPYpmOoMIIERjCCAy6gAwIBAgIJAKmI
07nX+nqHMA0GCSqGSIb3DQEBBQUAMGkxIzAhBgNVBAMTGlN3aXNzU2lnbiBQZXJzb25hbCBH
b2xkIENBMSEwHwYJKoZIhvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoTCVN3
aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMDMwMTQ0MzE2WhcNMDQxMDMwMTQ0MzE2WjBv
MRswGQYDVQQDExJKb3NlcGggRG9la2JyaWpkZXIxLzAtBgkqhkiG9w0BCQEWIGpvc2VwaC5k
b2VrYnJpamRlckBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYT
AkNIMIIBITANBgkqhkiG9w0BAQEFAAOCAQ4AMIIBCQKCAQBtmISHM5pmxmB3GrD4n8ZfA82r
tfHgSAl14N3NV9YT6jsiaav2K/k4n5Hn0ije8gGNhZFP+8Q9edYN0rQ1HR22+YfU27J7qm9C
EyY9saO55F36I9yPj4h57PUu6SWgwgwrcOv1ocAbbdKKB8VRFNr9DhwtcXM5pXYC1yHVGpVc
WKy87qv7401vKtftkB5VaC2cE9H14J/7eMExb1NRDUprj96+THgHU4APqDLiU6DphS+MwBwC
v8P2k3BXn9mD91MHMqrPmI+88bTz/MOXw+ynXD8nIgxKFjh2XajOjMUNxKB3tAVosuh0ny51
vpAQiA7AzOkwUDCtNL2vcNHly0dRAgMBAAGjgeswgegwHwYDVR0jBBgwFoAU8jaGz72k1nnf
MpmM0FlpHQWVLIYwTQYDVR0fBEYwRDBCoECgPoY8aHR0cHM6Ly9zd2lzc3NpZ24ubmV0L2Nn
aS1iaW4vYXV0aG9yaXR5L2NybD9jYT1QZXJzb25hbCtHb2xkMA4GA1UdDwEB/wQEAwIDyDAp
BgNVHSUEIjAgBggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcUAgIwOwYDVR0RBDQwMqAw
BgorBgEEAYI3FAIDoCIMIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMA0GCSqG
SIb3DQEBBQUAA4IBAQAlCsDvsCrsE47twAYZFVAaZ078L3JzZxtK8b4TnwTZp7miqrtD7+sZ
Q0JNkerghgZWhAR9oKo6jdnxAf9KTSFDtQPQhTEU/Pp+17mQAzKPvKCMmfGjr3hxEq5i71TW
bUEvQpwPmIYjQ+bcu+vAQiD9CcQjesOOGRi5gspiP+GVNmUQWYg/DHBpaJj5BkCfmisXsTmY
0i9AlOQc2IPUHw/xUUlnFYfoTkqENjEXIUOkxww2wPUs5Jz0ZL2J15u/TJ0w1eKbQJPQo8zM
qZJpQYJVeJq731+5grJ2WN1BGy0/k8x4mOttUC5SMSseIndd/uLjiqIBkx7PcHjpDLXJ9cxj
MYIDYjCCA14CAQEwdjBpMSMwIQYDVQQDExpTd2lzc1NpZ24gUGVyc29uYWwgR29sZCBDQTEh
MB8GCSqGSIb3DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24x
CzAJBgNVBAYTAkNIAgkAqYjTudf6eocwCQYFKw4DAhoFAKCCAcEwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMxMjAyMDg0MjIwWjAjBgkqhkiG9w0BCQQx
FgQU5VxC7K1Gg+9ZocMu76WIDYii9NYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
gYQGCSsGAQQBgjcQBDF3MHUwaTEjMCEGA1UEAxMaU3dpc3NTaWduIFBlcnNvbmFsIEdvbGQg
Q0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NT
aWduMQswCQYDVQQGEwJDSAIIcb/t0t2JSCwwgYYGCyqGSIb3DQEJEAILMXegdTBpMSMwIQYD
VQQDExpTd2lzc1NpZ24gUGVyc29uYWwgR29sZCBDQTEhMB8GCSqGSIb3DQEJARYSZ29sZEBz
d2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIAghxv+3S3YlI
LDANBgkqhkiG9w0BAQEFAASCAQAvCSxpM4U31/QgEOsb0gKJXmB9LpXODWOGLY0vZxxU/PM+
nz4mIWLnfP0ZHbdcK6dzWDdpMpxkP3+3P0/T6dQkuNqjjpNxQI8wKfR2/Pw3+g0joYDiCI73
EtixJjGV2wgZ0SVhGkJ13rBCufLBYES26D0UvWxY7tYBZWDdCBdPNq6AFXgGExu06OzUfj1C
5NchfUyE5fQ9pq0PBSlfprtRxACgZ0TnYNRbIqtPFY+iklfNEcywJ7kwinFB0tD7XB5ZLbWb
svzPB+OAlO8vK2W364yXrWVZnnoU+3QrdKCo7crz/6u2813NkVYoRFaMMS1EkaEAP6oeOH1x
3VIdx9JMAAAAAAAA
--------------ms060907010202070508090502--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Ngvib013110 for <[e-mail]>; Mon, 1 Dec 2003 15:42:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1NgvQV013109 for ietf-pkix-bks; Mon, 1 Dec 2003 15:42:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Ngsib013103 for <[e-mail]>; Mon, 1 Dec 2003 15:42:56 -0800 (PST) (envelope-from [e-mail])
Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.10/) with ESMTP id hB1Ngtq1015443 for <[e-mail]>; Mon, 1 Dec 2003 15:42:55 -0800 (PST)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <XZHCCDMY>; Mon, 1 Dec 2003 15:42:55 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: [e-mail]
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Mon, 1 Dec 2003 15:42:53 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0205_01C3B821.C86F6140"; micalg=SHA1
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_0205_01C3B821.C86F6140
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


It looks like I've missed most of the fun, but here are my thoughts in
any case...

For the record, I would object to any v1 addition that would mandate a
"MUST reject" clause.

As for the nonceUnsupported proposal, it does have it merits.  However I
have to agree with Ryan by objecting to its standardization in v1 for
two reasons.  First, doing so will not allow for the "TLS Extension" use
case where OCSP responses are included in protocol exchanges.  Second,
it will make currently conformant clients, non-conformant.  I'm also
worried that such a large change to v1 now will break some
implementations.  

I'm happy to have discussions on these issue in the context of a v2
protocol.  But would suggest we leave v1 as it is.  

Alex
 





 









> -----Original Message-----
> From: Marc Branchaud [mailto:[e-mail]] 
> Sent: Friday, November 28, 2003 2:23 PM
> To: [e-mail]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Mike just gave me an offline whack to the head.
> 
> I have no objection to the original nonceUnsupported proposal, as 
> described in
> 	http://www.imc.org/ietf-pkix/mail-archive/msg07210.html
> including David's "return an error" addition in
> 	http://www.imc.org/ietf-pkix/mail-archive/msg07214.html
> 
> Having clarified my earlier clarification, I wish to reset the 
> conversation...
> 
> Florian: As we both support the proposal, we may be in danger 
> of violent 
> agreement.
> 
> Ryan: Your arguments have failed to convince me that the 
> proposal is bad.
> 
> Apologies to all for the churn.
> 
> 		M.
> 
> 
> Michael Myers wrote:
> > Marc,
> > 
> > The proposal is to cycle *v1* at Proposed to address this one issue.
> > We would also take the opportunity to clarify encoding of nonce
> > as OCTET STRING, which was going to happen anyway as v1 went
> > from
> > Proposed to Draft.
> > 
> > I take it then you have no objection to the core technical 
> aspects of 
> > the proposed resolution?
> > 
> > Mike
> > 
> > 
> >>-----Original Message-----
> >>From: [e-mail] 
> >>[mailto:[e-mail]]On Behalf Of Marc Branchaud
> >>Sent: Friday, November 28, 2003 10:28 AM
> >>To: [e-mail]
> >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> >>
> >>
> >>
> >>Michael Myers wrote:
> >>
> >>>Marc, your response was ambiguous.
> >>
> >>Just to clarify, then:
> >>
> >>The resolution started with a "big if": Cycling at
> >>proposed.  I have no
> >>objection to cycling at Proposed and issuing an
> >>OCSPv2 that works all
> >>this out.
> >>
> >>It's the "then" I am objecting to.  The proposed
> >>"then" is bad.
> >>
> >>		M.
> >>
> > 
> > 
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXzCCAj0w
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/p9QMQ4fxiqmjCCA8AwggMpoAMCAQIC
EErIAANjYdQVAxbxhjabt80wDQYJKoZIhvcNAQEFBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3Vi
amVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYw
JAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0w
OTAyMjMyMzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xh
c3MgMiBFbXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsI
NvCX+hpUNSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf
6X1OISFh1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN
/n8CAwEAAaOB3zCB3DApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgw
EQYJYIZIAYb4QgEBBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMEQGA1UdIAQ9
MDswOQYLYIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYTA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9WU0NsYXNzMklu
dC5jcmwwDQYJKoZIhvcNAQEFBQADgYEANhj9M2DWF9MEtdhUX1Ia5ZIIKPSiQNrDW4wahpfvrqIV
/mzEzi/IAcozvvJ5WDOXl5JFcFpOKB3d98GIThuHVwI9kyXZfk5yNYlJF7O5dy9tDvmkiCXBznZz
ZWkFk3fn/ZOWGDhNWGx6nejSm+jQ24n9ScJ1BAOXpdSWgdgjQfAwggQPMIIDeKADAgECAhAzLr9g
Nl/Alm5BwDUqJfjZMA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3Qg
dG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UE
AxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw0wMzAyMjQwMDAwMDBaFw0wNDAyMjQy
MzU5NTlaMGUxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBp
ZW50czEuMCwGA1UEAxMlQURlYWNvbiAoRGVhY29uIEFsZXgsIFZlcmlTaWduLCBJbmMuKTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzx3sCPaQpHpxCg1L2vrDWdm9vpNny7aftpAvzfcCcjYn
EFPjODoBoEzqqTadrgD6YehNArWIWBf7STGJfQApFpSxCU5OWECQc+2Ti825B06KhAye00epJwgH
ByGqsDHGK7A+FlkpmqWybsLm2Q5kqdrv9gNFRw2oMRhsA6Ztx5sCAwEAAaOCAXYwggFyMAkGA1Ud
EwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVy
aVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1UdDwQEAwIFoDAcBgNV
HREEFTATgRFhbGV4QHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCB
jjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBW
MBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJl
bmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQW
MBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCD7anMuD4hgW1JGGSf+6Rf
25ZGkg2fjkCC8eh4XpTd5cQOhi+nQ1eUSxiU8r3UZJN1LQ5F9bkGj5G+hCQd+0mKvByk/l2Nwq34
/zZ9jraFBm60xDBF8FI2TfOCwlx6NsQR6xYdTl8IsvUx9oy0J8YBPFZLN3z2Q/JtLf07g/4mojGC
A88wggPLAgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xh
c3MgMiBFbXBsb3llZSBDQQIQMy6/YDZfwJZuQcA1KiX42TAJBgUrDgMCGgUAoIICYzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzEyMDEyMzQyNTNaMCMGCSqGSIb3
DQEJBDEWBBRK6YovR5jsEA4WsMR7tnetS+zBsjBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMH
MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAKBggqhkiG
9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQMy6/YDZfwJZuQcA1KiX42TCB1AYLKoZIhvcN
AQkQAgsxgcSggcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln
biBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRw
czovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFz
cyAyIEVtcGxveWVlIENBAhAzLr9gNl/Alm5BwDUqJfjZMA0GCSqGSIb3DQEBAQUABIGAITOhvkjv
Q17OtiPtbQfeeN3e658Cb+6FOnpEKjH4nXxZzDNBK/W3STatdIyyFQO1fUm6v4M+s4raQ8TnWMvg
mDeFxtqqG7Bhk6eQHQtXuc8fv9AjuHPnKy1OXmtg7JGXDde3yGVL6rP6A3zlb7MCF+PDYxORmPWD
GuQotJOVlAIAAAAAAAA=

------=_NextPart_000_0205_01C3B821.C86F6140--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1MfJib011126 for <[e-mail]>; Mon, 1 Dec 2003 14:41:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1MfJlT011125 for ietf-pkix-bks; Mon, 1 Dec 2003 14:41:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1MfGib011114 for <[e-mail]>; Mon, 1 Dec 2003 14:41:16 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 01 Dec 2003 17:41:08 -0500
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Straw poll: An advice to a commercial CA
References: <4.3.2.7.2.20031128140532.02a3dea0@localhost>
In-Reply-To: <4.3.2.7.2.20031128140532.02a3dea0@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>

Absolutely correct.  "Typical users", and their user agent software, 
have no threat model against which to apply any sort of security policy, 
and therefore have no reason to demand certificates containing policy 
OIDs or configuration interfaces more complex than the "Whatever" button.

Typically only organizations have security policies, and therefore 
organizations are the only relying parties with a need to configure the 
strength of authentication they are willing to accept.  If there were a 
standardized set of certificate policies (analogous to gasoline octanes, 
or USDA beef grades Choice and Select), then users could select among 
competing commercial CAs providing a certain grade of product.  But 
unless banks or other e-businesses start requiring users to have Choice 
(but not Select) third-party certificates to access their accounts, 
users have no reason to obtain such certificates or to care how much 
assurance they provide.

Dave



Christine Karman wrote:
> At 12:27 11-27-03, Peter Gutmann wrote:
> 
>> To answer an earlier question about support for policy restrictions, 
>> cryptlib
>> supports these (policy constraints with all its weird variations).  If
>> cryptlib finds constraints in a CA cert it'll apply them down the 
>> chain, but
>> there's no way for a user to configure the behaviour.  The reason for 
>> this is
>> that no-one has ever asked for this [0], so I can't even begin to 
>> imagine what
>> sort of interface it'd require to manage things.  Do users type in a 
>> list of
>> OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
>> policies advertised by this CA"?
> 
> 
> Typical users hardly know what a CA is. They don't know what kind of 
> policies you are talking about. So a GUI would assume a most probable 
> strategy, and then prompt the user with "I recommend you adopt policy 
> xyz for this certificate. Press 'OK', or press 'advanced' to change". On 
> a company level, a system administrator would force a certain behavior 
> of the GUI, which cannot be changed by individual users.
> Having said this, the GUI would probably make the choice by itself, 
> because user interaction suggests that the user makes a decision on the 
> subject, while in reality the user just presses a button that may as 
> well read "Whatever".
> I agree, this is not what the world should be like. But it is.
> 
> dagdag
> Christine
> -- 
> Izecom BV
> Secure e-mail and digital signatures
> www.izecom.com



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1IiQib001212 for <[e-mail]>; Mon, 1 Dec 2003 10:44:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1IiQkS001211 for ietf-pkix-bks; Mon, 1 Dec 2003 10:44:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imr6.us.db.com (imr6.us.db.com [160.83.65.199]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1IiOib001206 for <[e-mail]>; Mon, 1 Dec 2003 10:44:25 -0800 (PST) (envelope-from [e-mail])
Received: from sdbo1005.db.com by imr6.us.db.com  id hB1IiOuD018908; Mon, 1 Dec 2003 13:44:25 -0500 (EST)
To: [e-mail]
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <[e-mail]>
From: "Frank Balluffi" <[e-mail]>
Date: Mon, 1 Dec 2003 13:44:22 -0500
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(5012HF330 | August 01, 2003) at 12/01/2003 01:44:25 PM, Serialize complete at 12/01/2003 01:44:25 PM
Content-Type: multipart/alternative; boundary="=_alternative 0066F0EA85256DEF_="
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 0066F0EA85256DEF_=
Content-Type: text/plain; charset="us-ascii"

I agree with Ambarish.

Frank





"Ambarish Malpani" <[e-mail]>
Sent by: [e-mail]
11/28/2003 05:00 PM

 
        To:     "Florian Oelmaier" <[e-mail]>, "'Marc Branchaud'" 
<[e-mail]>, <[e-mail]>
        cc: 
        Subject:        RE: DISCUSS:  MUST  reject in OCSPv1




Hi Florian,
    The reason for including a nonce in the request is to enable a
client that doesn't have a very precise knowledge of time to still
be sure the response he got from the server was generated for this
specific request.

While I do agree with Mark and think that the "right" way would be
to require the client to require the nonce in the response, in the
interests of moving ahead, I vote to accept Mike's compromise
proposal that a client MUST require the nonce in the response
unless it is accompanied by a nonceUnsupported extension in
the response and the client is willing to accept a response w/o
a nonce. This preserves the semantics for current clients and
still allows caching servers to supply responses to clients
who will take them.

Regards,
Ambarish



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Florian Oelmaier
> Sent: Thursday, November 27, 2003 4:15 PM
> To: 'Marc Branchaud'; [e-mail]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Your argument is "nonces are only for replay protection". Thats true.
> 
> Now lets discuss WHY a client wants to get replay protection. Seeing
> that we have the three times in the response with a clear semantic, the
> client is not harmed by a replay. So why should a client include a nonce
> into the request?
> 
> There are different reasons for that, but the main reason is: the client
> wants a "fresh" response. Following that path Ryans arguments apply as
> he presented it in his previous replies. A client will include a nonce
> into the request to ask for a "fresh" response. If the client does not
> need a fresh response, then replaying is not a problem (then it is a
> feature called "caching").
> 
> So if a responder gets a request with a nonce, it not only means "the
> client wants replay protection" - it also means "the client would like
> to get a fresh response". Because otherwise replay attacks would not
> matter.
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
> 



--=_alternative 0066F0EA85256DEF_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">I agree with Ambarish.</font>
<br>
<br><font size=2 face="sans-serif">Frank</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Ambarish Malpani&quot; &lt;[e-mail]&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: [e-mail]</font>
<p><font size=1 face="sans-serif">11/28/2003 05:00 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&quot;Florian Oelmaier&quot; &lt;[e-mail]&gt;, &quot;'Marc Branchaud'&quot; &lt;[e-mail]&gt;, &lt;[e-mail]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: DISCUSS: &nbsp;MUST &nbsp;reject in OCSPv1</font></table>
<br>
<br>
<br><font size=2 face="Courier New"><br>
<br>
Hi Florian,<br>
 &nbsp; &nbsp;The reason for including a nonce in the request is to enable a<br>
client that doesn't have a very precise knowledge of time to still<br>
be sure the response he got from the server was generated for this<br>
specific request.<br>
<br>
While I do agree with Mark and think that the &quot;right&quot; way would be<br>
to require the client to require the nonce in the response, in the<br>
interests of moving ahead, I vote to accept Mike's compromise<br>
proposal that a client MUST require the nonce in the response<br>
unless it is accompanied by a nonceUnsupported extension in<br>
the response and the client is willing to accept a response w/o<br>
a nonce. This preserves the semantics for current clients and<br>
still allows caching servers to supply responses to clients<br>
who will take them.<br>
<br>
Regards,<br>
Ambarish<br>
<br>
<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: [e-mail]<br>
&gt; [mailto:[e-mail]]On Behalf Of Florian Oelmaier<br>
&gt; Sent: Thursday, November 27, 2003 4:15 PM<br>
&gt; To: 'Marc Branchaud'; [e-mail]<br>
&gt; Subject: RE: DISCUSS: MUST reject in OCSPv1<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Your argument is &quot;nonces are only for replay protection&quot;. Thats true.<br>
&gt; <br>
&gt; Now lets discuss WHY a client wants to get replay protection. Seeing<br>
&gt; that we have the three times in the response with a clear semantic, the<br>
&gt; client is not harmed by a replay. So why should a client include a nonce<br>
&gt; into the request?<br>
&gt; <br>
&gt; There are different reasons for that, but the main reason is: the client<br>
&gt; wants a &quot;fresh&quot; response. Following that path Ryans arguments apply as<br>
&gt; he presented it in his previous replies. A client will include a nonce<br>
&gt; into the request to ask for a &quot;fresh&quot; response. If the client does not<br>
&gt; need a fresh response, then replaying is not a problem (then it is a<br>
&gt; feature called &quot;caching&quot;).<br>
&gt; <br>
&gt; So if a responder gets a request with a nonce, it not only means &quot;the<br>
&gt; client wants replay protection&quot; - it also means &quot;the client would like<br>
&gt; to get a fresh response&quot;. Because otherwise replay attacks would not<br>
&gt; matter.<br>
&gt; <br>
&gt; -- <br>
&gt; Florian Oelmaier<br>
&gt; SyTrust<br>
&gt; <br>
&gt; <br>
</font>
<br>
<br>
--=_alternative 0066F0EA85256DEF_=--