Subject: Summary RE: Last Call: Qualified Certificates

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 19 Dec 2003 14:40:33 -0000

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
> 

From: "Anders Rundgren" <[email-masked]>
To: "Marc Poulaud" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: IDPKC
Date: Tue, 30 Dec 2003 11:21:25 +0100
Sender: [email-masked]

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" <[email-masked]>
To: "Marc Poulaud" <[email-masked]>
Cc: <[email-masked]>
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

Date: Mon, 29 Dec 2003 17:45:26 -0500
To: "Marc Poulaud" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: IDPKC
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 23 Dec 2003 15:44:17 -0500
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: RFC3039bis last call ?
Cc: [email-masked]
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-proxy-10.txt
Date: Tue, 23 Dec 2003 15:35:28 -0500
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-proxy-10.txt
Date: Tue, 23 Dec 2003 15:35:34 -0500
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: RFC3039bis last call ?
Date: Tue, 23 Dec 2003 19:57:39 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

In-line.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 23 december 2003 16:18
> To: Stefan Santesson
> Cc: [email-masked]
> 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: [email-masked]
> >
> > [mailto:[email-masked]]
> >
> >>On Behalf Of Denis Pinkas
> >>Sent: den 4 december 2003 21:08
> >>To: [email-masked]
> >>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
> >>
> >>
> >>
> >
> >
> >
> 

Content-class: urn:content-classes:message
Subject: RE: Summary RE: Last Call: Qualified Certificates
Date: Tue, 23 Dec 2003 19:29:50 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]
> 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:[email-masked]]
> >>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
> >
> >
> >
> 

Date: Tue, 23 Dec 2003 10:55:54 -0500
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Summary RE: Last Call: Qualified Certificates
Cc: Stefan Santesson <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 23 Dec 2003 16:26:01 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>, pkix <[email-masked]>
Subject: Re: Summary RE: Last Call: Qualified Certificates
Sender: [email-masked]

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:[email-masked]]
>>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
> 
> 
> 

Date: Tue, 23 Dec 2003 16:17:40 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: Re: RFC3039bis last call ?
Sender: [email-masked]

> 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: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 4 december 2003 21:08
>>To: [email-masked]
>>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
>>
>>
>>
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: RFC3039bis last call ?
Date: Tue, 23 Dec 2003 10:01:45 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 4 december 2003 21:08
> To: [email-masked]
> 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
> 
> 
> 

Content-class: urn:content-classes:message
Subject: Summary RE: Last Call: Qualified Certificates
Date: Fri, 19 Dec 2003 14:40:33 -0000
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>, "Tim Polk" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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
> 

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Nystrom, Magnus'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: RE: Last Call: Qualified Certificates
Date: Thu, 18 Dec 2003 13:19:10 -0800
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
> Sent: Thursday, December 18, 2003 12:51 AM
> To: [email-masked]
> Cc: [email-masked]; '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:[email-masked]]
> > > Sent: Thursday, December 18, 2003 12:33 AM
> > > To: [email-masked]
> > > Cc: [email-masked]; '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: [email-masked] 
> > > > > [mailto:[email-masked]] 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
> > >
> >
> 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sha244-02.txt
Date: Thu, 18 Dec 2003 15:31:04 -0500
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 18 Dec 2003 12:48:14 -0700
To: [email-masked]
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: Re: non repudiation
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 18 Dec 2003 17:57:06 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: non repudiation
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 18 Dec 2003 08:59:33 -0500
To: "Manger, James H" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: WG Last Call: Additional Algorithms for RSA cryptography
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
>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:[email-masked]]
>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:[email-masked]]
>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.

From: "Nystrom, Magnus" <[email-masked]>
Reply-To: "Nystrom, Magnus" <[email-masked]>
To: [email-masked]
Cc: [email-masked], "'Stefan Santesson'" <[email-masked]>
Date: Thu, 18 Dec 2003 09:51:10 +0100 (W. Europe Standard Time)
Subject: RE: Last Call: Qualified Certificates
Sender: [email-masked]

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:[email-masked]]
> > Sent: Thursday, December 18, 2003 12:33 AM
> > To: [email-masked]
> > Cc: [email-masked]; '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: [email-masked]
> > > > [mailto:[email-masked]] 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
> >
>

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Nystrom, Magnus'" <[email-masked]>
Cc: <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: RE: Last Call: Qualified Certificates
Date: Thu, 18 Dec 2003 00:47:59 -0800
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
> Sent: Thursday, December 18, 2003 12:33 AM
> To: [email-masked]
> Cc: [email-masked]; '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: [email-masked] 
> > > [mailto:[email-masked]] 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
> 

From: "Nystrom, Magnus" <[email-masked]>
Reply-To: "Nystrom, Magnus" <[email-masked]>
To: [email-masked]
Cc: [email-masked], "'Stefan Santesson'" <[email-masked]>
Date: Thu, 18 Dec 2003 09:32:37 +0100 (W. Europe Standard Time)
Subject: RE: Last Call: Qualified Certificates
Sender: [email-masked]

Jim,

Please find my reply below.

On Wed, 17 Dec 2003, Jim Schaad wrote:

> Magnus,
>
> Only one issue left....
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] 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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Nystrom, Magnus'" <[email-masked]>
Cc: <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: RE: Last Call: Qualified Certificates
Date: Wed, 17 Dec 2003 20:17:28 -0800
Importance: Normal
Sender: [email-masked]

Magnus,

Only one issue left....

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Manger, James H'" <[email-masked]>, <[email-masked]>
Subject: RE: WG Last Call: Additional Algorithms for RSA cryptography
Date: Wed, 17 Dec 2003 20:13:10 -0800
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Manger, James H
> Sent: Wednesday, December 17, 2003 6:29 PM
> To: [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> 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:[email-masked]]
> 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:[email-masked]]
> 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.
> 

content-class: urn:content-classes:message
Subject: RE: WG Last Call: Additional Algorithms for RSA cryptography
Date: Thu, 18 Dec 2003 12:29:21 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
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:[email-masked]]
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:[email-masked]]
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.

From: "Michael Myers" <[email-masked]>
To: "Nystrom, Magnus" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: RE: Last Call: Qualified Certificates
Date: Wed, 17 Dec 2003 17:30:58 -0700
Importance: Normal
Sender: [email-masked]

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

From: "Nystrom, Magnus" <[email-masked]>
Reply-To: "Nystrom, Magnus" <[email-masked]>
To: [email-masked]
Cc: [email-masked], "'Stefan Santesson'" <[email-masked]>
Date: Wed, 17 Dec 2003 23:06:06 +0100 (W. Europe Standard Time)
Subject: RE: Last Call: Qualified Certificates
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Nystrom, Magnus'" <[email-masked]>, <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>
Subject: RE: Last Call: Qualified Certificates
Date: Wed, 17 Dec 2003 11:58:15 -0800
Importance: Normal
Sender: [email-masked]

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

From: "Marco Casassa Mont" <[email-masked]>
To: <[email-masked]>
Subject: RE: IDPKC
Date: Wed, 17 Dec 2003 16:29:19 -0000
Importance: Normal
Sender: [email-masked]

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:  +44 117 312 8794 (direct)           ++++  _/  _/  _/_/_/   ++++
 Telnet: 312 8794                            +++++        _/       +++++
 Fax:    +44 117 312 9250                    +++++++     _/      +++++++
 Email:  [email-masked]           +++++++++++++++++++++++++++
========================================================================
=
        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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marc Poulaud
> Sent: 16 December 2003 16:29
> To: [email-masked]
> 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.
> 

Date: Wed, 17 Dec 2003 10:45:42 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: DN Encoding by UTF8String
Cc: [email-masked]
Sender: [email-masked]

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?

From: "Nystrom, Magnus" <[email-masked]>
Reply-To: "Nystrom, Magnus" <[email-masked]>
To: [email-masked]
Cc: Stefan Santesson <[email-masked]>
Date: Wed, 17 Dec 2003 10:19:24 +0100 (W. Europe Standard Time)
Subject: RE: Last Call: Qualified Certificates
Sender: [email-masked]

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

Date: Wed, 17 Dec 2003 11:39:48 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: Tim Polk <[email-masked]>
Subject: Re[2]: DN Encoding by UTF8String
Cc: Richard Levitte - VMS Whacker <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

From: The IESG <[email-masked]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, <[email-masked]>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure:  Logotypes in X.509 certificates' to Proposed Standard 
Date: Tue, 16 Dec 2003 16:35:45 -0500
Sender: [email-masked]

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.

From: "Ambarish Malpani" <[email-masked]>
To: "'Marc Poulaud'" <[email-masked]>, <[email-masked]>
Subject: RE: IDPKC
Date: Tue, 16 Dec 2003 11:58:33 -0800
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marc Poulaud
> Sent: Tuesday, December 16, 2003 8:29 AM
> To: [email-masked]
> 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.
> 

Date: Tue, 16 Dec 2003 14:30:56 -0500
From: [email-masked]
To: [email-masked]
Cc: "'Stephen Kent'" <[email-masked]>, [email-masked], Jim Schaad <[email-masked]>, Russ Housley <[email-masked]>, Burt Kaliski <[email-masked]>
Subject: WG Last Call: Additional Algorithms for RSA cryptography
Sender: [email-masked]

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

From: "Marc Poulaud" <[email-masked]>
To: <[email-masked]>
Subject: IDPKC
Date: Tue, 16 Dec 2003 16:29:19 -0000
Importance: Normal
Sender: [email-masked]

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"

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

Date: Tue, 16 Dec 2003 01:21:18 +0000
From: Dr Stephen Henson <[email-masked]>
To: [email-masked]
Subject: Re: DN Encoding by UTF8String
Sender: [email-masked]

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

Richard Levitte - VMS Whacker wrote:

> In message <[email-masked]> on Tue, 16 Dec 2003 00:22:09 +1300, [email-masked] (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: [email-masked], PGP key: via homepage.

Date: Tue, 16 Dec 2003 00:43:38 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: DN Encoding by UTF8String
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Tue, 16 Dec 2003 00:22:09 +1300, [email-masked] (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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Mon, 15 Dec 2003 18:15:48 -0500
To: Richard Levitte - VMS Whacker <[email-masked]>, [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: DN Encoding by UTF8String
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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 <[email-masked]> on Tue, 16 Dec 
>2003 00:22:09 +1300, [email-masked] (Peter Gutmann) said:
>
>pgut001> Richard Levitte - VMS Whacker <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"

From: "Deacon, Alex" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, "Deacon, Alex" <[email-masked]>, Tom Gindin <[email-masked]>
Cc: [email-masked]
Subject: RE: DISCUSS:  MUST reject in OCSPv1
Date: Mon, 15 Dec 2003 09:56:04 -0800
Sender: [email-masked]

Mike,

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]] 
> Sent: Monday, December 15, 2003 9:54 AM
> To: Deacon, Alex; Tom Gindin
> Cc: [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> > -----Original Message-----
> > From: Deacon, Alex [mailto:[email-masked]]
> > 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

From: "Michael Myers" <[email-masked]>
To: "Deacon, Alex" <[email-masked]>, "Tom Gindin" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DISCUSS:  MUST reject in OCSPv1
Date: Mon, 15 Dec 2003 10:54:10 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Deacon, Alex [mailto:[email-masked]]
> 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

From: "Deacon, Alex" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, Tom Gindin <[email-masked]>
Cc: [email-masked]
Subject: RE: DISCUSS:  MUST reject in OCSPv1
Date: Mon, 15 Dec 2003 09:20:48 -0800
Sender: [email-masked]

Mike,

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]] 
[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

Date: Mon, 15 Dec 2003 12:43:54 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: DN Encoding by UTF8String
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Tue, 16 Dec 2003 00:22:09 +1300, [email-masked] (Peter Gutmann) said:

pgut001> Richard Levitte - VMS Whacker <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Tue, 16 Dec 2003 00:22:09 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: DN Encoding by UTF8String
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Richard Levitte - VMS Whacker <[email-masked]> 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.

Date: Mon, 15 Dec 2003 11:02:40 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: DN Encoding by UTF8String
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Mon, 15 Dec 2003 20:36:21 +1300, [email-masked] (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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Mon, 15 Dec 2003 20:36:21 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: DN Encoding by UTF8String
Sender: [email-masked]

Jean-Marc Desperrier <[email-masked]> 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.

From: "Michael Myers" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DISCUSS:  MUST reject in OCSPv1
Date: Fri, 12 Dec 2003 17:04:44 -0700
Importance: Normal
Sender: [email-masked]

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

To: "Michael Myers" <[email-masked]>
Cc: [email-masked]
Subject: Re: DISCUSS:  MUST reject in OCSPv1
From: Tom Gindin <[email-masked]>
Date: Fri, 12 Dec 2003 17:57:45 -0500
Sender: [email-masked]

        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" <[email-masked]>
Sent by: [email-masked]
12/11/2003 11:01 PM

        To:     <[email-masked]>
        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.

To: <[email-masked]>
Cc: "Michael Myers" <[email-masked]>
Subject: Re: POLL:   MUST  reject in OCSPv1
From: Tom Gindin <[email-masked]>
Date: Fri, 12 Dec 2003 17:43:58 -0500
Sender: [email-masked]

        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" <[email-masked]>
Sent by: [email-masked]
12/08/2003 01:46 PM

        To:     <[email-masked]>
        cc:     "Carlisle Adams" <[email-masked]>
        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

Date: Fri, 12 Dec 2003 19:25:55 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: DN Encoding by UTF8String
Sender: [email-masked]

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.

Date: Fri, 12 Dec 2003 18:33:06 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Web-PKI Keygen/Certreq Questions
Sender: [email-masked]

Peter Gutmann wrote:

>Jean-Marc Desperrier <[email-masked]> 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.

From: "Blake Ramsdell" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Re[2]: DN Encoding by UTF8String
Date: Fri, 12 Dec 2003 09:27:53 -0800
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: Friday, December 12, 2003 1:53 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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

Date: Fri, 12 Dec 2003 14:44:02 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: DN Encoding by UTF8String
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Fri, 12 Dec 2003 22:52:46 +1300, [email-masked] (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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Fri, 12 Dec 2003 12:53:08 +0000
From: Dr Stephen Henson <[email-masked]>
To: [email-masked]
Subject: Re: DN Encoding by UTF8String
Sender: [email-masked]

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: [email-masked], PGP key: via homepage.

Date: Sat, 13 Dec 2003 00:37:58 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Web-PKI Keygen/Certreq Questions
Sender: [email-masked]

Jean-Marc Desperrier <[email-masked]> 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.

From: "Wen-Cheng Wang" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Re[2]: DN Encoding by UTF8String
Date: Fri, 12 Dec 2003 19:03:55 +0800
Sender: [email-masked]

Peter Gutmann" <[email-masked]> writes:
> 
> Masaki SHIMAOKA <[email-masked]> 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

Date: Fri, 12 Dec 2003 11:59:03 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Web-PKI Keygen/Certreq Questions
Sender: [email-masked]

Peter Gutmann wrote:

>"James Jing" <[email-masked]> 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.

Date: Fri, 12 Dec 2003 22:52:46 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Re[2]: DN Encoding by UTF8String
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Masaki SHIMAOKA <[email-masked]> 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.

Date: Fri, 12 Dec 2003 20:28:13 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Web-PKI Keygen/Certreq Questions
Sender: [email-masked]

"James Jing" <[email-masked]> 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.

content-class: urn:content-classes:message
Subject: RE: Web-PKI Keygen/Certreq Questions
Date: Fri, 12 Dec 2003 15:45:51 +1100
From: "James Jing" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, 27 November 2003 3:59 AM
Cc: [email-masked]
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
> 

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: DISCUSS:  MUST reject in OCSPv1
Date: Thu, 11 Dec 2003 21:01:14 -0700
Importance: Normal
Sender: [email-masked]

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

Subject: RE: Cached OCSP responses vs. single entry CRLs
From: "Ryan M. Hurst" <[email-masked]>
To: Santosh Chokhani <[email-masked]>, <[email-masked]>
Date: Wed, 10 Dec 2003 13:58:34 -0800
Sender: [email-masked]

--------------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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Ryan M. Hurst
Sent: Tuesday, December 09, 2003 10:02 PM
To: Jean-Marc Desperrier; [email-masked]
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: [email-masked]
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> [email-masked]<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=
[email-masked] [mailto:[email-masked]] <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; [email-masked]<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> [email-masked]<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--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Wed, 10 Dec 2003 14:41:27 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Ströder
Sent: Wednesday, December 10, 2003 11:15 AM
To: Jean-Marc Desperrier
Cc: [email-masked]
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.

Date: Wed, 10 Dec 2003 09:07:39 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: OCSP in TLS handshake
Sender: [email-masked]

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

--------------ms070804020701030109090807--

Date: Wed, 10 Dec 2003 17:14:58 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>
Cc: [email-masked]
Subject: Re: Cached OCSP responses vs. single entry CRLs
Sender: [email-masked]

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.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Wed, 10 Dec 2003 08:28:13 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Ryan M. Hurst
Sent: Tuesday, December 09, 2003 10:02 PM
To: Jean-Marc Desperrier; [email-masked]
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: [email-masked]
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
  [email-masked] [mailto:[email-masked]] =
<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; =
[email-masked]<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> [email-masked]<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--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Tue, 9 Dec 2003 23:45:32 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Tuesday, December 09, 2003 3:00 PM
To: [email-masked]
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.

Subject: RE: Cached OCSP responses vs. single entry CRLs
From: "Ryan M. Hurst" <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>, <[email-masked]>
Date: Tue, 9 Dec 2003 19:01:40 -0800
Sender: [email-masked]

--------------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: [email-masked]
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> [email-masked]<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--

From: "Carl Wallace" <[email-masked]>
To: "'Jean-Marc Desperrier'" <[email-masked]>, <[email-masked]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Tue, 9 Dec 2003 18:19:44 -0500
Importance: Normal
Sender: [email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] 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.

Date: Tue, 09 Dec 2003 21:19:49 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Cached OCSP responses vs. single entry CRLs
Sender: [email-masked]

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.

Date: Tue, 09 Dec 2003 20:59:41 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Cached OCSP responses vs. single entry CRLs
Sender: [email-masked]

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.

Date: Tue, 09 Dec 2003 09:32:55 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: OCSP in TLS handshake
Sender: [email-masked]

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

--------------ms070106080909070505070600--

From: "Deacon, Alex" <[email-masked]>
To: "'Marc Branchaud'" <[email-masked]>, [email-masked]
Subject: RE: OCSP in TLS handshake
Date: Tue, 9 Dec 2003 09:21:37 -0800 
Sender: [email-masked]

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:[email-masked]] 
> Sent: Monday, December 08, 2003 3:59 PM
> To: [email-masked]
> 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"

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

Date: Mon, 8 Dec 2003 21:21:18 -0500
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Cc: "'Ryan M. Hurst'" <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, "'David Engberg'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 09 Dec 2003 09:47:43 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: Harald Tveit Alvestrand <[email-masked]>
Subject: Re[2]: DN Encoding by UTF8String
Cc: Russ Housley <[email-masked]>, [email-masked]
Sender: [email-masked]

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 <[email-masked]> 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 <[email-masked]> 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 <[email-masked]>
> > To:      Tim Polk <[email-masked]>, Stephen Kent <[email-masked]>,
> > [email-masked], [email-masked], [email-masked]
> > 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: +81 422 91 8498 (ext.3605)
> > Fax: +81 422 45 0536
> > e-mail: [email-masked]
> >
> >
> >
> 
> 
> 
> 

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

Date: Mon, 08 Dec 2003 15:58:32 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: OCSP in TLS handshake
Sender: [email-masked]

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

--------------ms040306020106010305050005--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Mon, 8 Dec 2003 18:04:28 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Ryan M. Hurst
Sent: Monday, December 08, 2003 3:05 PM
To: Carl Wallace; Deacon, Alex; [email-masked]
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:[email-masked]]
Sent: Mon 12/8/2003 5:39 AM
To: 'Deacon, Alex'; Ryan M. Hurst; [email-masked]
Subject: RE: Cached OCSP responses vs. single entry CRLs

Response to following two comments below...

> From: [email-masked]
> [mailto:[email-masked]] 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:[email-masked]]
> 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> [email-masked]=20
[mailto:[email-masked]] <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; [email-masked]<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:[email-masked]]<BR><B>Sent:</B> Mon 12/8/2003 5:39=20
  AM<BR><B>To:</B> 'Deacon, Alex'; Ryan M. Hurst;=20
  [email-masked]<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
  [email-masked]<BR>&gt; [<A=20
  =
href=3D"mailto:[email-masked]">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:[email-masked]">mailto:[email-masked]=
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--

content-class: urn:content-classes:message
Subject: RE: POLL:   MUST  reject in OCSPv1
Date: Tue, 9 Dec 2003 08:56:11 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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. 

Date: Mon, 8 Dec 2003 14:16:23 -0800
From: "Terry Hayes" <[email-masked]>
Subject: RE: POLL:   MUST  reject in OCSPv1
To: [email-masked]
cc: [email-masked]
Organization: AOL
Sender: [email-masked]

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:[email-masked]] 
> > 
> > . . . 
> > 
> > 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 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: POLL:   MUST  reject in OCSPv1
Date: Mon, 8 Dec 2003 15:56:47 -0500
Importance: Normal
Sender: [email-masked]

AGREE

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Myers
Sent: Monday, December 08, 2003 1:46 PM
To: [email-masked]
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

From: "Michael Myers" <[email-masked]>
To: "Terry Hayes" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: POLL:   MUST  reject in OCSPv1
Date: Mon, 8 Dec 2003 13:42:01 -0700
Importance: Normal
Sender: [email-masked]

> From: Terry Hayes [mailto:[email-masked]]
>
> . . .
>
> 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

Date: Mon, 8 Dec 2003 12:29:38 -0800
From: "Terry Hayes" <[email-masked]>
Subject: Re: POLL:   MUST  reject in OCSPv1
To: [email-masked]
cc: [email-masked], [email-masked]
Organization: AOL
Sender: [email-masked]

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 

Date: Mon, 8 Dec 2003 15:24:34 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Policy Standardization
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 3:18 +1300 12/6/03, Peter Gutmann wrote:
>Stephen Kent <[email-masked]> 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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sha244-01.txt
Date: Mon, 08 Dec 2003 15:23:37 -0500
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Mon, 8 Dec 2003 12:04:46 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Carl Wallace" <[email-masked]>, "Deacon, Alex" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Sent: Mon 12/8/2003 5:39 AM
To: 'Deacon, Alex'; Ryan M. Hurst; [email-masked]
Subject: RE: Cached OCSP responses vs. single entry CRLs

Response to following two comments below...

> From: [email-masked]
> [mailto:[email-masked]] 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:[email-masked]]
> 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:[email-masked]]<BR><B>Sent:</B> Mon 12/8/2003 5:39 =0A=
AM<BR><B>To:</B> 'Deacon, Alex'; Ryan M. Hurst; =0A=
[email-masked]<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=
[email-masked]<BR>&gt; [<A =0A=
href=3D"mailto:[email-masked]">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:[email-masked]">mailto:[email-masked]=
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--

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: "Carlisle Adams" <[email-masked]>
Subject: POLL:   MUST  reject in OCSPv1
Date: Mon, 8 Dec 2003 11:46:03 -0700
Importance: Normal
Sender: [email-masked]

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

From: "Deacon, Alex" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, "Deacon, Alex" <[email-masked]>, "Ryan M. Hurst" <[email-masked]>, [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Mon, 8 Dec 2003 09:17:45 -0800 
Sender: [email-masked]

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:[email-masked]] 
> Sent: Friday, December 05, 2003 5:22 PM
> To: Deacon, Alex; Ryan M. Hurst; [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Alex,
> 
> Comments embedded below.
> 
> Mike
> 
> > -----Original Message-----
> > From: Deacon, Alex [mailto:[email-masked]]
> > Sent: Friday, December 05, 2003 4:59 PM
> > To: 'Michael Myers'; Ryan M. Hurst; [email-masked]
> > 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.
> 
> 
> 
> 
> 

Date: Sun, 07 Dec 2003 23:51:59 -0800
From: Harald Tveit Alvestrand <[email-masked]>
To: Russ Housley <[email-masked]>, [email-masked], [email-masked]
Subject: Re: DN Encoding by UTF8String
Sender: [email-masked]

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 <[email-masked]> 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 <[email-masked]>
> To:      Tim Polk <[email-masked]>, Stephen Kent <[email-masked]>,
> [email-masked], [email-masked], [email-masked]
> 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: +81 422 91 8498 (ext.3605)
> Fax: +81 422 45 0536
> e-mail: [email-masked]
>
>
>

From: "Carl Wallace" <[email-masked]>
To: "'David Engberg'" <[email-masked]>
Cc: "'Deacon, Alex'" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, <[email-masked]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Mon, 8 Dec 2003 10:28:55 -0500
Importance: Normal
Sender: [email-masked]

> From: David Engberg [mailto:[email-masked]] 
> 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".

Date: Mon, 08 Dec 2003 09:55:36 -0500
From: David Engberg <[email-masked]>
To: Carl Wallace <[email-masked]>
CC: "'Deacon, Alex'" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, [email-masked]
Subject: Re: Cached OCSP responses vs. single entry CRLs
Sender: [email-masked]

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

From: "Carl Wallace" <[email-masked]>
To: "'Deacon, Alex'" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, <[email-masked]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Mon, 8 Dec 2003 08:39:22 -0500
Importance: Normal
Sender: [email-masked]

Response to following two comments below...

> From: [email-masked] 
> [mailto:[email-masked]] 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:[email-masked]] 
> 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.

Date: Sat, 06 Dec 2003 13:29:28 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: DN Encoding by UTF8String
Cc: [email-masked]
Sender: [email-masked]

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 <[email-masked]>
To:      Tim Polk <[email-masked]>, Stephen Kent <[email-masked]>, 
[email-masked], [email-masked], [email-masked]
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: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

Date: Sun, 7 Dec 2003 17:44:54 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Certificate Policy Standardization
Sender: [email-masked]

"Hans Nilsson" <[email-masked]> 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.

From: "Ambarish Malpani" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Sat, 6 Dec 2003 19:57:52 -0800
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Myers
> Sent: Friday, December 05, 2003 10:47 AM
> To: Ryan M. Hurst; [email-masked]
> 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
> 
> 

From: "Florian Oelmaier" <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Sat, 6 Dec 2003 23:14:29 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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

From: "Ambarish Malpani" <[email-masked]>
To: <[email-masked]>, "'David Engberg'" <[email-masked]>
Cc: "'Ryan M. Hurst'" <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 17:52:08 -0800
Importance: Normal
Sender: [email-masked]

I agree completely with Liaquat.

Ambarish

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Liaquat Khan
> Sent: Friday, December 05, 2003 4:43 AM
> To: 'David Engberg'
> Cc: 'Ryan M. Hurst'; 'Florian Oelmaier'; [email-masked]
> 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:[email-masked]] 
> Sent: 05 December 2003 12:15
> To: [email-masked]
> Cc: 'Ryan M. Hurst'; 'Florian Oelmaier'; [email-masked]
> 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.
> >
> >  
> >
> 
> 
> 
> 

From: "Michael Myers" <[email-masked]>
To: "Deacon, Alex" <[email-masked]>, "Ryan M. Hurst" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 18:22:21 -0700
Importance: Normal
Sender: [email-masked]

Alex,

Comments embedded below.

Mike

> -----Original Message-----
> From: Deacon, Alex [mailto:[email-masked]]
> Sent: Friday, December 05, 2003 4:59 PM
> To: 'Michael Myers'; Ryan M. Hurst; [email-masked]
> 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.

Date: Sat, 6 Dec 2003 14:11:52 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Cached OCSP responses vs. single entry CRLs
Sender: [email-masked]

"Carl Wallace" <[email-masked]> 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.

From: "Deacon, Alex" <[email-masked]>
To: "'Carl Wallace'" <[email-masked]>, [email-masked]
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Fri, 5 Dec 2003 16:04:46 -0800 
Sender: [email-masked]

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:[email-masked]] 
> Sent: Friday, December 05, 2003 1:09 PM
> To: [email-masked]
> 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.).
> 

From: "Deacon, Alex" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, "Ryan M. Hurst" <[email-masked]>, [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 15:58:47 -0800 
Sender: [email-masked]

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:[email-masked]] 
> Sent: Friday, December 05, 2003 10:47 AM
> To: Ryan M. Hurst; [email-masked]
> 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
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Fri, 5 Dec 2003 15:30:21 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Carl Wallace" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Carl Wallace
Sent: Friday, December 05, 2003 1:09 PM
To: [email-masked]
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.).

Content-class: urn:content-classes:message
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 14:27:22 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Michael Myers" <[email-masked]>, "David Engberg" <[email-masked]>
Cc: <[email-masked]>, "Florian Oelmaier" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Comments in-line

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Friday, December 05, 2003 12:52 PM
To: Ryan M. Hurst; David Engberg
Cc: [email-masked]; 'Florian Oelmaier'; [email-masked]
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

From: "Michael Myers" <[email-masked]>
To: "Carl Wallace" <[email-masked]>, <[email-masked]>
Subject: RE: Cached OCSP responses vs. single entry CRLs
Date: Fri, 5 Dec 2003 15:28:11 -0700
Importance: Normal
Sender: [email-masked]

> 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

Content-class: urn:content-classes:message
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 14:10:45 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>, "Florian Oelmaier" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Comments in line

-----Original Message-----
From: David Engberg [mailto:[email-masked]] 
Sent: Friday, December 05, 2003 12:01 PM
To: Ryan M. Hurst
Cc: [email-masked]; 'Florian Oelmaier'; [email-masked]
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:* [email-masked]; 'Florian Oelmaier'; [email-masked]
> *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?

From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: Cached OCSP responses vs. single entry CRLs
Date: Fri, 5 Dec 2003 16:09:01 -0500
Importance: Normal
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: "Ryan M. Hurst" <[email-masked]>, "David Engberg" <[email-masked]>
Cc: <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 13:51:36 -0700
Importance: Normal
Sender: [email-masked]

> 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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sha244-00.txt
Date: Fri, 05 Dec 2003 15:29:40 -0500
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 05 Dec 2003 15:01:28 -0500
From: David Engberg <[email-masked]>
To: "Ryan M. Hurst" <[email-masked]>
CC: [email-masked], "'Florian Oelmaier'" <[email-masked]>, [email-masked]
Subject: Re: DISCUSS: MUST reject in OCSPv1
Sender: [email-masked]

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:* [email-masked]; 'Florian Oelmaier'; [email-masked]
> *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?
>
>
>
>  
>

Subject: RE: DISCUSS: MUST reject in OCSPv1
From: "Ryan M. Hurst" <[email-masked]>
To: David Engberg <[email-masked]>
Cc: <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, <[email-masked]>
Date: Fri, 5 Dec 2003 11:24:51 -0800
Sender: [email-masked]

--------------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: [email-masked]; 'Florian Oelmaier'; [email-masked]
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'; [email-masked]<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--

Date: Fri, 05 Dec 2003 14:17:46 -0500
From: David Engberg <[email-masked]>
To: "Ryan M. Hurst" <[email-masked]>
CC: [email-masked], "'Florian Oelmaier'" <[email-masked]>, [email-masked]
Subject: Re: DISCUSS: MUST reject in OCSPv1
Sender: [email-masked]

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?

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, "'David Engberg'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 19:14:51 -0000
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
Sent: 05 December 2003 17:16
To: [email-masked]; 'Florian Oelmaier'; 'David Engberg';
[email-masked]
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';
[email-masked]
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: +44(0)1784 497 321, fax: +44(0)1784 497301, mobile: +44 (0)7776
308766
website: www.ascertia.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [email-masked]
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: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [email-masked]
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:[email-masked]">
<link rel=3DEdit-Time-Data href=3D"cid:[email-masked]">
<!--[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:[email-masked]] <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> =
[email-masked];
'Florian Oelmaier'; 'David Engberg'; [email-masked]<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'; [email-masked]<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: +44(0)1784 497 321, fax: +44(0)1784 =
497301, mobile: +44 (0)7776<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: [email-masked] =
[mailto:[email-masked]]<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; =
[email-masked]<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: [email-masked] =
[mailto:[email-masked]]<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; =
[email-masked]<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--

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, "'David Engberg'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 19:13:40 -0000
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
Sent: 05 December 2003 17:16
To: [email-masked]; 'Florian Oelmaier'; 'David Engberg';
[email-masked]
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';
[email-masked]
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: +44(0)1784 497 321, fax: +44(0)1784 497301, mobile: +44 (0)7776
308766
website: www.ascertia.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [email-masked]
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: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [email-masked]
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:[email-masked]">
<link rel=3DEdit-Time-Data href=3D"cid:[email-masked]">
<!--[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:[email-masked]] <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> =
[email-masked];
'Florian Oelmaier'; 'David Engberg'; [email-masked]<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'; [email-masked]<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: +44(0)1784 497 321, fax: +44(0)1784 =
497301, mobile: +44 (0)7776<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: [email-masked] =
[mailto:[email-masked]]<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; =
[email-masked]<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: [email-masked] =
[mailto:[email-masked]]<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; =
[email-masked]<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--

From: "Michael Myers" <[email-masked]>
To: "Ryan M. Hurst" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 11:47:20 -0700
Importance: Normal
Sender: [email-masked]

> 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

Subject: RE: DISCUSS: MUST reject in OCSPv1
From: "Ryan M. Hurst" <[email-masked]>
To: Michael Myers <[email-masked]>, <[email-masked]>
Date: Fri, 5 Dec 2003 09:56:31 -0800
Sender: [email-masked]

--------------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: [email-masked]
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> [email-masked]<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--

Subject: RE: DISCUSS: MUST reject in OCSPv1
From: "Ryan M. Hurst" <[email-masked]>
To: <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, "'David Engberg'" <[email-masked]>, <[email-masked]>
Date: Fri, 5 Dec 2003 09:16:21 -0800
Sender: [email-masked]

--------------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'; [email-masked]
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: +44(0)1784 497 321, fax: +44(0)1784 497301, mobile: +44 (0)7776
308766
website: www.ascertia.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [email-masked]
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: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [email-masked]
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'; [email-masked]<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: +44(0)1784 497 321, fax: +44(0)1784 497301, mobile: +44 (0)7776
308766
website: www.ascertia.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [email-masked]
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: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [email-masked]
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--

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 08:45:12 -0700
Importance: Normal
Sender: [email-masked]

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

Date: Fri, 05 Dec 2003 15:54:29 +0100
From: Andreas Mitrakas <[email-masked]>
Subject: Re: Certificate Policy Standardization
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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.

Date: Fri, 05 Dec 2003 09:47:43 -0500
From: "Stoner, Nicholas E" <[email-masked]>
Subject: remove
To: [email-masked]
Content-Class: urn:content-classes:message
Sender: [email-masked]

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: (407) 306-2908
Cell: (407) 808-5757

--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: (407) 306-2908</FONT></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en"><FONT COLOR="#000000" SIZE=1 FACE="Arial">Cell: (407) 808-5757</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)--

From: "Hans Nilsson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Certificate Policy Standardization
Date: Fri, 5 Dec 2003 15:42:09 +0100
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Peter Gutmann
> Sent: Friday, December 05, 2003 2:40 PM
> To: [email-masked]; [email-masked];
[email-masked]
> 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.

Date: Sat, 6 Dec 2003 03:18:57 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Cc: [email-masked]
Sender: [email-masked]

Stephen Kent <[email-masked]> 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.

Date: Sat, 6 Dec 2003 02:39:56 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Certificate Policy Standardization
Sender: [email-masked]

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.

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'David Engberg'" <[email-masked]>
Cc: "'Ryan M. Hurst'" <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 12:43:27 -0000
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
Sent: 05 December 2003 12:15
To: [email-masked]
Cc: 'Ryan M. Hurst'; 'Florian Oelmaier'; [email-masked]
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.
>
>  
>

Date: Fri, 05 Dec 2003 07:15:21 -0500
From: David Engberg <[email-masked]>
To: [email-masked]
CC: "'Ryan M. Hurst'" <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, [email-masked]
Subject: Re: DISCUSS: MUST reject in OCSPv1
Sender: [email-masked]

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

Date: 5 Dec 2003 10:30:22 -0000
From: "Florian Oelmaier" <[email-masked]>
To: [email-masked]
CC: "'David Engberg'" <[email-masked]>, <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Sender: [email-masked]

> 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

Date: Fri, 5 Dec 2003 22:12:10 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: DN Encoding by UTF8String
Cc: [email-masked]
Sender: [email-masked]

Masaki SHIMAOKA <[email-masked]> 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.

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, "'David Engberg'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 08:20:53 -0000
Importance: Normal
Sender: [email-masked]

Ooops...in 4th paragraph below, I meant to say "outgoing requests"
instead of "outgoing responses".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Liaquat Khan
Sent: 05 December 2003 06:55
To: 'Ryan M. Hurst'; 'Florian Oelmaier'; 'David Engberg';
[email-masked]
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: +44(0)1784 497 321, fax: +44(0)1784 497301, mobile: +44 (0)7776
308766
website: www.ascertia.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [email-masked]
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: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [email-masked]
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

Date: Fri, 05 Dec 2003 16:09:10 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: Tim Polk <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: DN Encoding by UTF8String
Cc: IETF-PKIX <[email-masked]>
Sender: [email-masked]

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: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, "'David Engberg'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Fri, 5 Dec 2003 06:54:43 -0000
Importance: Normal
Sender: [email-masked]

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: +44(0)1784 497 321, fax: +44(0)1784 497301, mobile: +44 (0)7776
308766
website: www.ascertia.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [email-masked]
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: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [email-masked]
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

Content-class: urn:content-classes:message
Subject: RE: DISCUSS: MUST reject in OCSPv1
Date: Thu, 4 Dec 2003 17:40:57 -0800
From: "Ryan M. Hurst" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "David Engberg" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [email-masked]
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

From: "Nystrom, Magnus" <[email-masked]>
Reply-To: "Nystrom, Magnus" <[email-masked]>
To: [email-masked]
Date: Thu, 4 Dec 2003 17:50:05 -0500 (Eastern Standard Time)
Subject: RE: DISCUSS: MUST reject in OCSPv1
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-acpolicies-extn-05.txt
Date: Thu, 04 Dec 2003 15:40:13 -0500
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 04 Dec 2003 21:08:18 +0100
From: Denis Pinkas <[email-masked]>
To: [email-masked]
Subject: RFC3039bis last call ?
Sender: [email-masked]

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

Date: Thu, 04 Dec 2003 11:24:28 -0500
To: "Manger, James H" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Sender: [email-masked]

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:[email-masked]]
>Sent: Thursday, 4 December 2003 6:05 AM
>To: Manger, James H; [email-masked]
>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: [email-masked] [mailto:[email-masked]]
> >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

Date: 4 Dec 2003 14:19:23 -0000
From: "Florian Oelmaier" <[email-masked]>
To: [email-masked]
CC: David Engberg <[email-masked]>
Subject: Re: DISCUSS: MUST reject in OCSPv1
Sender: [email-masked]

> 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

Date: Thu, 04 Dec 2003 08:25:30 -0500
From: "Phillip H. Griffin" <[email-masked]>
To: [email-masked]
Subject: Re: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Sender: [email-masked]

--------------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:[email-masked]]
>Sent: Thursday, 4 December 2003 6:05 AM
>To: Manger, James H; [email-masked]
>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: [email-masked] [mailto:[email-masked]]
>>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="[email-masked]">
  <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:[email-masked]">mailto:[email-masked]</a>]
Sent: Thursday, 4 December 2003 6:05 AM
To: Manger, James H; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</a> [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</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--

Date: Thu, 04 Dec 2003 08:10:13 -0500
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Florian Oelmaier <[email-masked]>
CC: [email-masked]
Subject: Re: DISCUSS: MUST reject in OCSPv1
Sender: [email-masked]

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

Date: Thu, 4 Dec 2003 12:25:34 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

 >     OCSPNonce ::= CHOICE {
 >        nonceValue  OCTET STRING,
 >        unsupported  NULL }

Another way may be 

nonceValue  OCTET STRING OPTIONAL -- unsupported if omitted. 

Date: 4 Dec 2003 09:46:34 -0000
From: "Florian Oelmaier" <[email-masked]>
To: David Engberg <[email-masked]>, [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1
Sender: [email-masked]

> 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

Date: Thu, 04 Dec 2003 09:55:58 +0100
From: Olivier Dubuisson <[email-masked]>
Organization: France Telecom R&D
To: [email-masked]
Subject: Re: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Sender: [email-masked]

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: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

Date: Thu, 04 Dec 2003 15:03:48 +1100
From: Steven Legg <[email-masked]>
To: [email-masked]
CC: "'Manger, James H'" <[email-masked]>, [email-masked]
Subject: Re: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Sender: [email-masked]

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: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Manger, James H
>>Sent: Wednesday, December 03, 2003 5:18 PM
>>To: [email-masked]
>>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:[email-masked]]
>>Sent: Thursday, 4 December 2003 6:05 AM
>>To: Manger, James H; [email-masked]
>>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: [email-masked] [mailto:[email-masked]]
>>>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
>>
>>
> 
> 
> 

Date: Wed, 03 Dec 2003 23:05:30 -0500
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1
Sender: [email-masked]

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.

content-class: urn:content-classes:message
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Date: Thu, 4 Dec 2003 13:55:47 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, 4 December 2003 2:27 PM
To: Manger, James H; [email-masked]

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.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Manger, James H'" <[email-masked]>, <[email-masked]>
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Date: Wed, 3 Dec 2003 19:27:04 -0800
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Manger, James H
> Sent: Wednesday, December 03, 2003 5:18 PM
> To: [email-masked]
> 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:[email-masked]]
> Sent: Thursday, 4 December 2003 6:05 AM
> To: Manger, James H; [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> >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
> 
> 

content-class: urn:content-classes:message
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1  typos
Date: Thu, 4 Dec 2003 11:18:18 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, 4 December 2003 6:05 AM
To: Manger, James H; [email-masked]
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: [email-masked] [mailto:[email-masked]]
>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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-13.txt
Date: Wed, 03 Dec 2003 15:29:19 -0500
Sender: [email-masked]

--NextPart

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

	Title		: 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 [email-masked]
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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 03 Dec 2003 14:05:18 -0500
To: "Manger, James H" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1 typos
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
>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

Subject: RE: Lightweight OCSP Profile for high volume environments...
From: "Ryan M. Hurst" <[email-masked]>
To: Denis Pinkas <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: <[email-masked]>
Date: Wed, 3 Dec 2003 08:29:30 -0800
Sender: [email-masked]

--------------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: [email-masked]
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:[email-masked]]
>     Sent: Tuesday, December 02, 2003 10:15 PM
>     To: Santosh Chokhani; [email-masked]
>     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: [email-masked]
>     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: [email-masked]
>     [mailto:[email-masked]] On
>     Behalf Of Deacon, Alex
>     Sent: Tuesday, December 02, 2003 2:43 PM
>     To: [email-masked]
>     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:[email-masked]]
&gt;     Sent: Tuesday, December 02, 2003 10:15 PM
&gt;     To: Santosh Chokhani; [email-masked]
&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: [email-masked]
&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: [email-masked]
&gt;     [mailto:[email-masked]] On
&gt;     Behalf Of Deacon, Alex
&gt;     Sent: Tuesday, December 02, 2003 2:43 PM
&gt;     To: [email-masked]
&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--

Subject: RE: Lightweight OCSP Profile for high volume environments...
From: "Ryan M. Hurst" <[email-masked]>
To: Santosh Chokhani <[email-masked]>, <[email-masked]>
Date: Wed, 3 Dec 2003 08:27:46 -0800
Sender: [email-masked]

--------------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: [email-masked]
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:[email-masked]]=20
Sent: Tuesday, December 02, 2003 10:15 PM
To: Santosh Chokhani; [email-masked]
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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Deacon, Alex
Sent: Tuesday, December 02, 2003 2:43 PM
To: [email-masked]
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> [email-masked]<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:[email-masked]] <BR><B>Sent:</B> Tuesday, December=
 02, 2003 10:15 PM<BR><B>To:</B> Santosh Chokhani; [email-masked]<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> [email-masked]<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: [email-masked]=
.org [<A href=3D"mailto:[email-masked]" target=3D_blank>mailt=
o:[email-masked]</A>] On<BR>Behalf Of Deacon, Alex<BR>Sent: T=
uesday, December 02, 2003 2:43 PM<BR>To: [email-masked]<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--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Lightweight OCSP Profile for high volume environments...
Date: Wed, 3 Dec 2003 11:01:09 -0500
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
Sent: Wednesday, December 03, 2003 9:24 AM
To: Santosh Chokhani
Cc: [email-masked]
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:[email-masked]]
>     Sent: Tuesday, December 02, 2003 10:15 PM
>     To: Santosh Chokhani; [email-masked]
>     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: [email-masked]
>     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: [email-masked]
>     [mailto:[email-masked]] On
>     Behalf Of Deacon, Alex
>     Sent: Tuesday, December 02, 2003 2:43 PM
>     To: [email-masked]
>     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

Date: Wed, 03 Dec 2003 15:23:35 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: Lightweight OCSP Profile for high volume environments...
Sender: [email-masked]

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:[email-masked]]
>     Sent: Tuesday, December 02, 2003 10:15 PM
>     To: Santosh Chokhani; [email-masked]
>     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: [email-masked]
>     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: [email-masked]
>     [mailto:[email-masked]] On
>     Behalf Of Deacon, Alex
>     Sent: Tuesday, December 02, 2003 2:43 PM
>     To: [email-masked]
>     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
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Lightweight OCSP Profile for high volume environments...
Date: Wed, 3 Dec 2003 07:38:31 -0500
Importance: Normal
Sender: [email-masked]

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:[email-masked]]=20
Sent: Tuesday, December 02, 2003 10:15 PM
To: Santosh Chokhani; [email-masked]
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: [email-masked]
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: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Deacon, Alex
Sent: Tuesday, December 02, 2003 2:43 PM
To: [email-masked]
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:[email-masked]] <BR><B>Sent:</B> Tuesday, December =
02, 2003=20
  10:15 PM<BR><B>To:</B> Santosh Chokhani; =
[email-masked]<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> [email-masked]<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
  [email-masked] [<A =
href=3D"mailto:[email-masked]"=20
  target=3D_blank>mailto:[email-masked]</A>] On<BR>Behalf =
Of Deacon,=20
  Alex<BR>Sent: Tuesday, December 02, 2003 2:43 PM<BR>To:=20
  [email-masked]<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--

Date: Wed, 03 Dec 2003 11:24:13 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certpathbuild-02.txt
Sender: [email-masked]

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:
> 	[email-masked].
> 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.

Subject: RE: Lightweight OCSP Profile for high volume environments...
From: "Ryan M. Hurst" <[email-masked]>
To: Santosh Chokhani <[email-masked]>, <[email-masked]>
Date: Tue, 2 Dec 2003 19:14:57 -0800
Sender: [email-masked]

<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> [email-masked]<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: [email-masked]=
.org [<A href=3D"mailto:[email-masked]" target=3D_blank>mailt=
o:[email-masked]</A>] On<BR>Behalf Of Deacon, Alex<BR>Sent: T=
uesday, December 02, 2003 2:43 PM<BR>To: [email-masked]<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>

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Lightweight OCSP Profile for high volume environments...
Date: Tue, 2 Dec 2003 20:10:54 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Deacon, Alex
Sent: Tuesday, December 02, 2003 2:43 PM
To: [email-masked]
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

content-class: urn:content-classes:message
Subject: RE: RSA Algs: 01: draft-ietf-pkix-rsa-pkalgs-01.txt - ASN.1 typos
Date: Wed, 3 Dec 2003 09:54:07 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
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

content-class: urn:content-classes:message
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Wed, 3 Dec 2003 08:45:38 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Sent: Wednesday, 3 December 2003 12:42 AM
To: [email-masked]
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 }

Date: Tue, 02 Dec 2003 16:32:28 -0500
To: "Ambarish Malpani" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

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: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Russ Housley
> > Sent: Tuesday, December 02, 2003 5:42 AM
> > To: [email-masked]
> > 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
> >

Date: Tue, 02 Dec 2003 16:29:59 -0500
To: "Michael Myers" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

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: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Russ Housley
> > Sent: Tuesday, December 02, 2003 6:42 AM
> > To: [email-masked]
> > 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
> >

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 16:19:39 -0500
Importance: Normal
Sender: [email-masked]

David:

I agree.  There is no need for the added complexity.

-----Original Message-----
From: David Engberg [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2003 3:37 PM
To: [email-masked]
Cc: [email-masked]
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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rsa-pkalgs-01.txt
Date: Tue, 02 Dec 2003 15:36:15 -0500
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-02.txt
Date: Tue, 02 Dec 2003 15:36:20 -0500
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 02 Dec 2003 15:36:48 -0500
From: David Engberg <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

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.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 14:54:49 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Myers
Sent: Tuesday, December 02, 2003 11:08 AM
To: Russ Housley; [email-masked]
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

From: "Deacon, Alex" <[email-masked]>
To: [email-masked]
Subject: Lightweight OCSP Profile for high volume environments...
Date: Tue, 2 Dec 2003 11:42:34 -0800 
Sender: [email-masked]

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

From: "Deacon, Alex" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 11:33:15 -0800 
Sender: [email-masked]

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:[email-masked]] 
> Sent: Tuesday, December 02, 2003 8:08 AM
> To: Russ Housley; [email-masked]
> 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
> 

Date: Tue, 02 Dec 2003 10:51:11 -0800
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: OCSP in TLS handshake
Sender: [email-masked]

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

--------------ms050108080502020100020109--

From: "Michael Myers" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 09:07:38 -0700
Importance: Normal
Sender: [email-masked]

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

From: "Ambarish Malpani" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 07:48:03 -0800
Importance: Normal
Sender: [email-masked]

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Russ Housley
> Sent: Tuesday, December 02, 2003 5:42 AM
> To: [email-masked]
> 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
>

From: "Michael Myers" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Tue, 2 Dec 2003 08:33:24 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Russ Housley
> Sent: Tuesday, December 02, 2003 6:42 AM
> To: [email-masked]
> 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
>

Date: Tue, 02 Dec 2003 08:42:27 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Sender: [email-masked]

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

Date: Tue, 02 Dec 2003 09:42:06 +0100
From: Joseph Doekbrijder <[email-masked]>
Organization: SwissSign AG
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: An advice to a commercial CA
Sender: [email-masked]

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" <[email-masked]>
>To: "Anders Rundgren" <[email-masked]>
>Cc: "Stephen Kent" <[email-masked]>; <[email-masked]>
>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: +41 43 344 88 11 Mobil: +41 79 211 24 46
>www.swisssign.com
>--------------------------------------------------
>
>
>  
>

-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: +41 43 344 88 11 Mobil: +41 79 211 24 46
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

--------------ms060907010202070508090502--

From: "Deacon, Alex" <[email-masked]>
To: [email-masked]
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
Date: Mon, 1 Dec 2003 15:42:53 -0800 
Sender: [email-masked]

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:[email-masked]] 
> Sent: Friday, November 28, 2003 2:23 PM
> To: [email-masked]
> 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: [email-masked] 
> >>[mailto:[email-masked]]On Behalf Of Marc Branchaud
> >>Sent: Friday, November 28, 2003 10:28 AM
> >>To: [email-masked]
> >>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"

------=_NextPart_000_0205_01C3B821.C86F6140--

Date: Mon, 01 Dec 2003 17:41:08 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: Straw poll: An advice to a commercial CA
Sender: [email-masked]

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

To: [email-masked]
Subject: RE: DISCUSS:  MUST  reject in OCSPv1
From: "Frank Balluffi" <[email-masked]>
Date: Mon, 1 Dec 2003 13:44:22 -0500
Sender: [email-masked]

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

I agree with Ambarish.

Frank

"Ambarish Malpani" <[email-masked]>
Sent by: [email-masked]
11/28/2003 05:00 PM

        To:     "Florian Oelmaier" <[email-masked]>, "'Marc Branchaud'" 
<[email-masked]>, <[email-masked]>
        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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Florian Oelmaier
> Sent: Thursday, November 27, 2003 4:15 PM
> To: 'Marc Branchaud'; [email-masked]
> 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;[email-masked]&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</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;[email-masked]&gt;, &quot;'Marc Branchaud'&quot; &lt;[email-masked]&gt;, &lt;[email-masked]&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: [email-masked]<br>
&gt; [mailto:[email-masked]]On Behalf Of Florian Oelmaier<br>
&gt; Sent: Thursday, November 27, 2003 4:15 PM<br>
&gt; To: 'Marc Branchaud'; [email-masked]<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_=--