Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 12 Nov 2006 15:35:35 -0800

Mike,

What is the error case?  And, why is it more important than the other
issues?

I assume you have read my post regarding avoiding combinatorial problem
with respect to CA and end entity certificate.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Sunday, November 12, 2006 5:28 PM
To: Santosh Chokhani; Russ Housley; Dave Engberg
Cc: [email-masked]; Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh,

I prefer to just clarify this error case.

Mike

---

From: "Michael Myers" <[email-masked]>
Date: Sun, 12 Nov 2006 15:52:29 -0800

Responders unable to produce or acquire a definitive response MUST return <a
TBD error>.

As to your other points Santosh, that is something I prefer the chairs
consider.

> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Sunday, November 12, 2006 3:36 PM
>
> Mike,
>
> What is the error case?
>
> . . .

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Nov 2006 11:45:45 -0500

Mike:

I think it is not that simple.  I think you need to say that support 
for one certificate MUST be supported, and that support for more than 
one certificate is OPTIONAL.  Then, the error is am indication that 
the requestor has selected an unimplemented OPTION.

Russ

---

From: "Price, Bill" <[email-masked]>
Date: Mon, 13 Nov 2006 14:46:35 -0500

I'd suggest focusing on understanding where responses to the keyed and
keyless responders inherently differ. I am aware of two general cases:

1) The request asks for the status of multiple certificates that have
not been included in a single presigned response. Russ's example fits
into this case. The keyed responder handles, but the keyless will fail
for the general case. Some responders respond with the presigned
response that includes one of the certificates (usually the first) in
the request. A common situation is to ask for the status of
certificates in a chain. Santosh points out some keyless responders
anticipate this and bundle responses accordingly.

2) The request is "well-formed" but asks for the status of a
certificate for which the keyless responder has not prepared a
response.  This situation will occur if:

    a) The request is for status of a certificate from a supported CA
but with a serial number for which there is no pre-signed response.
Assuming presigned responses exist for all certificates that would be
valid based on their validity intervals, this would occur if the
certificate had expired or was yet to be issued (I am aware the keyless
responders generally produce responses for certificates likely to be
issued before the next generation of presigned responses). The keyed
responder would give a signed "good" response. My understanding is that
the keyless responder under the draft lightweight OCSP responds with an
unsigned "unauthorized" error code.  

    b) The request is for the status of a certificate from an
unsupported (or non-existent) CA. The keyed responder would respond
with a signed "unknown" response while under the draft, the keyless
would again respond with the unsigned "unauthorized" error  code.

Some might argue with some grounds that these differences are unusual,
unlikely, and insignificant.

I personally consider the behavior in 2 of responding with the
"unauthorized" error to be misleading. "Internal error" sounds more
appropriate if I were constrained to the current error codes.
"Malformed request" might be OK. However, the actual situation does not
match well with any of these errors as they are described in 2560.

If 2560 is supposed to encompass keyless responders, I'd recommend
identifying the unavoidable differences and/or adding 2 TBD error codes
for the above cases (assuming they are the only differences). The first
error can be worked around by breaking the request for status of
multiples into multiple requests for status of one cert. 

We've also seen some problems with client apps that can't handle
presigned responses that commonly contain the status of several (e.g.,
15-25) certs. The apps inquired for the status of a single cert and
apparently expected a response for a single certificate. I'd suggest
that some "must" or "should" words address clients' ability to handle
the situation of a response covering multiple certificates.

Bill Price 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Monday, November 13, 2006 11:46 AM
To: Michael Myers; Dave Engberg
Cc: [email-masked]; Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Mike:

Russ

---

From: "Ogle Ron" <[email-masked]>
Date: Mon, 13 Nov 2006 16:56:46 -0500

I would like to know if the PKIX working group would be interested in
shepherding a new rfc concerning PEM file formats?  I've recently
discovered that there is no definitive standard for how a PEM's headers
and footers are defined for a private key.  I've searched the RFCs, and
ISO standards without any luck.

The issue that I discovered was when I was working with PEM files for
PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For
PKCS1, both expect "BEGIN RSA PRIVATE KEY".

I contacted the people at IAIK about this, and they agree that there is
an issue.  However, there is no "standard".  Also, other implementations
such as MSIE and Mozilla may behave differently.

If I've overlooked a standard, then please point me in the right
direction.  If there is no standard, then is PKIX the correct place to
start one?

Thanks
Ron Ogle
Thomson

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Nov 2006 17:08:29 -0500

I prefer an error that tells the client to ask for the certificate 
one at a time.

Russ

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 13 Nov 2006 22:46:07 +0000

> direction.  If there is no standard, then is PKIX the correct place to

I'd be interested in contributing to or co-authoring such a standard,
I'm not aware of an existing one.

With one exception the PEM formats I've used in OpenSSL have already
existed in one form or another either through adoption from its SSLeay
roots or through test files we wished to interop with.

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.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Nov 2006 18:44:32 -0500

>ISO standards without any luck.

PEM formats were defined for e-mail messages, not files per se. I 
think RFC 1421 defines the last of the formats (we had a few 
iterations) for PEM.

>PKCS1, both expect "BEGIN RSA PRIVATE KEY".

it looks like folks made this up!  PEM describes how to transfer a 
symmetric key encrypted under a public (RSA) key in a message, in 
1421.  It does not describe how to transfer a private key, because 
one would not do that via an e-mail message.

The term "PEM file" with regard to PKCS #8 is a misnomer, relative to 
IETF standards. Since PKCS #8 defines a format for private keys, it 
is not relevant to PEM, period.

Given that PKIX is a WG that focuses on X.509-based standards, it is 
not immediately clear that a document on how to use base-64 encoding 
and MIME-style headers to represent private keys is within our scope.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 13 Nov 2006 23:54:09 +0000

I'm not sure the case described is a realistic one.

Section 2.2
   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

Since the request is on certificates issued by 2 different CA:s trust option 1 is invalid.
Trust option 3 is valid in theory but in practice it requires that the OCSP responder provide multiple validation paths in the response, one for each issuing CA. Somehow I doubt that this is implemented by anyone.

Trust option 2 is not generic and is only valid as a result of a local configuration.

So I don't think this is a problem only for key-less responders.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 13 november 2006 14:08
> To: Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Nov 2006 00:30:20 +0000

I've been taking a close look at this and I've come to the conclusion that we are fine. That is, I can't find any support for that provision of pre-produced responses handed out by a key-less responder is violating RFC 2560 in any way.

RFC 2560 does not require the responder to return a successful response for all possible legitimate requests. It only require the responder to support the basic response format when it chooses to return a response. As I read RFC 2560, it may fail responding to a request for any reason as long as it returns a legitimate error.

There is no place where RFC 2560 requires the render to successfully handle a composite request. It only specifies how it should be done.

On the contrary, support for pre-produced responses is explicitly supported in 2.5. And as such it is obvious that such responder can't respond to all possible requests.

Of the error codes listed, I find that "unauthorized" is the most appropriate one for unsupported requests as it indicates that "the client is not authorized to make this query to this server". The description may not be 100% perfect but it is sufficiently good and the response is definitive and avoids repetition.

The response "internalError" would be misleading as it "indicates that the OCSP responder reached an inconsistent internal state. The query should be retried, potentially with another responder", which may cause the requester to keep retrying the request.

My conclusion is that no update to RFC 2560 is needed to progress the informational profile for lightweight OCSP.

Stefan Santesson
Senior Program Manager

---

From: "Ogle Ron" <[email-masked]>
Date: Mon, 13 Nov 2006 20:18:29 -0500

I agree that the original PEM meaning is as you state.  I have no idea
as to how it got skewed with these new meanings for public/private keys
and certificates.  However, it does now exist.

As for the relevance with PKIX, the "PEM" format also describes the base
64 encoding with MIME headers for x509 certificates.  Also, many S/MIME,
SSL, IPsec, and other cryptographic standards that use x509 also
recognize PEM formatted certificates/key pairs.  This is how I
discovered the problem in the first place.

If not PKIX, then where?

Thanks
Ron Ogle

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, November 13, 2006 6:45 PM
To: Ogle Ron
Cc: [email-masked]; Dieter Bratko
Subject: Re: PEM file format rfc draft request

Steve

---

From: "Dieter Bratko" <[email-masked]>
Date: Tue, 14 Nov 2006 15:29:01 +0100

> that use x509 also recognize PEM formatted certificates/key pairs.
> This is how I discovered the problem in the first place.
>
> If not PKIX, then where?

I agree with Ron that PKIX would be the right place. PEM as email
security format is not widely used. However, base64 encoded
keys/certificates/certificate requests/crls,... with PEM-style
headers/footers are an inherent part of almost any (X.509 based)
PKI environment.
When implementing en- and decoding of keys and other PKI
objects for our Java crypto toolkit, we first searched for a specification
telling us which headers and footers shall be used. Since no such
specification is available we tried to implement it in a way to be
interoperable with other appliacations. However, each application may
use its own interpretation and some applications are very restrictive and
only accept their own interpretation. The only solution is to provide
additional API methods allowing the user to explicitly set the PEM headers;
however, this only moves the decision to the user (and is not applicable
for final applications).
For that reason a standard giving some recommendations
for the usage of PEM headers would be very useful. It should not
only cover keys, but also certificates, crls, requests,... (for instance,
some applications use -----BEGIN CERTIFICATE REQUEST-----.
and some use -----BEGIN NEW CERTIFICATE REQUEST-----,
and some may use  -----BEGIN PKCS10 REQUEST---- or something
other for encoding a certificate request). We should try to find and setup
a common base from already existing PKI applications.
Since Steve Henson announced that he would help to write
the specification, we already would have the contribution of
one of the most widely used crypto libraries, OpenSSL.

Regards,
Dieter

---------
Dieter Bratko, SIC/IAIK - Graz University of Technology
IAIK, Inffeldgasse 16a, 8010 Graz, Austria, http://jce.iaik.tugraz.at/
----- Original Message ----- 
From: Ogle Ron
To: Stephen Kent
Cc: [email-masked] ; Dieter Bratko
Sent: Tuesday, November 14, 2006 2:18 AM
Subject: RE: PEM file format rfc draft request

If not PKIX, then where?

Thanks
Ron Ogle

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, November 13, 2006 6:45 PM
To: Ogle Ron
Cc: [email-masked]; Dieter Bratko
Subject: Re: PEM file format rfc draft request

Steve

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 15 Nov 2006 05:25:14 +1300

"Ogle Ron" <[email-masked]> writes:

>The issue that I discovered was when I was working with PEM files for PKCS1
>and PKCS8 formatted private keys under OpenSSL and some Java toolkits using
>an IAIK implementation.  OpenSSL expects PKCS8 PEM files to have "BEGIN
>PRIVATE KEY" as the header while IAIK uses "BEGIN RSA PRIVATE KEY" for RSA
>keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For PKCS1, both expect "BEGIN
>RSA PRIVATE KEY".

Uhh, given that it's probably about 10-15 years too late to try and fix this,
is it worth even doing this?  Most implementations get around it by reading
the lowest common denominator of all the formats they know of (for example my
code looks for '----' + 'BEGIN' + 'PRIVATE', which seems to handle all
possibilities).  Even if you could decide on one particular interpretation I
can't imagine anyone's going to change code that's been in the field for 10+
years.  I think the best you could do is create an kind of FYI RFC that
documents all of the possible formats (I started this in my X.509 style guide
some years ago), or maybe document a regexp that'll recognise all possible
formats.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 15 Nov 2006 05:27:56 +1300

>If not PKIX, then where?

A web page somewhere where Google can find it.  Given that this is such a
moving target, I'm not sure that an RFC is the best way to document this even
if you could find a WG that would adopt it.

Peter.

---

From: "Ogle Ron" <[email-masked]>
Date: Tue, 14 Nov 2006 13:11:23 -0500

Well, it did surprise me why there wasn't a standard since there were so
many implementations.  I think one of the reasons why there hasn't been
much call for it in the past is that one stayed within a single
PKI/crypto system implementation.  This issue came up for me because I'm
trying to interoperate between crypto systems (OpenSSL and Entrust).  In
this case Entrust uses the IAIK implementation.

Now with people using the AIA extension and extending the CDP extension
to include URIs, I see more and more use of the PEM formatted CRLs and
certificates.  I also see people building PKI applications out of
toolkits (like myself) who are expecting the keys and certificates to be
in the same format regardless of which crypto system created them.

Granted maybe the best advice a RFC can give is to use the proper regex,
but shouldn't it exist?  Isn't PKIX about interoperability?  I guess
that I could make the RFC informational, but I thought that it should be
given a bit more due care by interested parties.

Would the PKIX group still be interested in reviewing the informational
RFC?

Ron Ogle 

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 11:25 AM
To: [email-masked]; Ogle Ron
Cc: [email-masked]
Subject: Re: PEM file format rfc draft request

>The issue that I discovered was when I was working with PEM files for
PKCS1
>keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For PKCS1, both expect
"BEGIN

Uhh, given that it's probably about 10-15 years too late to try and fix
this,
is it worth even doing this?  Most implementations get around it by
reading
the lowest common denominator of all the formats they know of (for
example my
code looks for '----' + 'BEGIN' + 'PRIVATE', which seems to handle all
possibilities).  Even if you could decide on one particular
interpretation I
can't imagine anyone's going to change code that's been in the field for
10+
years.  I think the best you could do is create an kind of FYI RFC that
documents all of the possible formats (I started this in my X.509 style
guide
some years ago), or maybe document a regexp that'll recognise all
possible
formats.

Peter.

---

From: "Price, Bill" <[email-masked]>
Date: Tue, 14 Nov 2006 13:56:07 -0500

Fine perhaps from the viewpoint of a standards lawyer but I wouldn't
want to defend fine to client developers, integrators, support staff,
and users. I don't know that they would think it is "fine" that:

1) a "successful" answer only has a partial answer when the responder
actually knew the status of all of the certs in a "multiple" request.
(See note below).

2) an "unauthorized error" has nothing to do with access controls and
authorizations at the responder. The error resulted because the
responder was not internally capable of producing a "successful" answer
to a "well-formed" request. Another (e.g., keyed) responder could
produce a successful response. The real problem was that the request
was probably ill-conceived because it involved non-existent or unknown
CA or an expired or unissued cert.

Although the situations for the "unauthorized error" are the result of
requests that should not normally occur, I have some first hand
experience that they can occur because of bugs in software or
misconfigurations. A fair amount of time was wasted with help-desk and
support people investigating why access to the server was
"unauthorized" before encountering someone who knew that the
"unauthorized error" was the response given when the keyless responder
didn't have an appropriate presigned response.

Note:  1) above assumes that the response contains status for some but
not all certs in a multiple request. This is the way some keyless
responders behave. Your response and the standard seem to indicate that
an error should result since the response does not contain "responses
for each of the certificates in a request". An error might be more
appropriate than a "successful" partial answer. 

Bottom line: From a client developer, integrator, support staff, and
user viewpoint, 2560 compliant behavior due to differences between
keyed and keyless responders may be unclear and misleading in some "out
of the mainstream" cases. However, these cases may occur in the real
world because client developers, integrators, support staff, and users
may not know and/or may not be able to control (e.g., because of load
balancing) the type of responder that receives their requests. Addition
of a few words and error codes might change the situation for the
better. 

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Monday, November 13, 2006 7:30 PM
To: Russ Housley; Price, Bill; [email-masked]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

I've been taking a close look at this and I've come to the conclusion
that we are fine. That is, I can't find any support for that provision
of pre-produced responses handed out by a key-less responder is
violating RFC 2560 in any way.

RFC 2560 does not require the responder to return a successful response
for all possible legitimate requests. It only require the responder to
support the basic response format when it chooses to return a response.
As I read RFC 2560, it may fail responding to a request for any reason
as long as it returns a legitimate error.

There is no place where RFC 2560 requires the render to successfully
handle a composite request. It only specifies how it should be done.

On the contrary, support for pre-produced responses is explicitly
supported in 2.5. And as such it is obvious that such responder can't
respond to all possible requests.

Of the error codes listed, I find that "unauthorized" is the most
appropriate one for unsupported requests as it indicates that "the
client is not authorized to make this query to this server". The
description may not be 100% perfect but it is sufficiently good and the
response is definitive and avoids repetition.

The response "internalError" would be misleading as it "indicates that
the OCSP responder reached an inconsistent internal state. The query
should be retried, potentially with another responder", which may cause
the requester to keep retrying the request.

My conclusion is that no update to RFC 2560 is needed to progress the
informational profile for lightweight OCSP.

Stefan Santesson
Senior Program Manager

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Nov 2006 13:21:11 -0500

>and certificates.  However, it does now exist.

No debate about its existence, just whether it is an appropriate 
topic for this WG.

>discovered the problem in the first place.

The base64 encoding we developed for PEM, while I chaired the PSRG, 
has been adopted in a wide range of contexts, in large part because 
it became a standard MIME encoding. Most of the examples you cite 
above are instances where a WG developing a security protocol 
standard has chosen to define multiple encodings for transmission of 
public keys and/or certs, etc.  I don't think these WGs generally 
have defined private key encodings, because private keys are not 
transferred over the net and thus are not critical for 
interoperability. The WG in which this might have been relevant was 
SACRED, but I believe they choose to deal with private key transfer 
using XML (with base64 as the underlying mechanism) encoding.

>If not PKIX, then where?

An individual draft can be submitted on the topic.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 14 Nov 2006 14:42:50 -0500

Ogle Ron wrote:
> certificates.
Why is there need to base64 encode everything?  It made sense in PEM due 
to the limitations of email, but what is the benefit of base64 encoding 
in other situations?

As for the scenarios mentioned above, 3280bis specifically states that 
the data pointed to by an HTTP or FTP URI must in the AIA, SIA, or CDP 
extension must be BER or DER encoded (DER for certificates and CRLs; BER 
or DER for "certs-only" CMS messages).  Is there a reason that people 
are pointing to PEM formatted certificates and CRLs rather than just the 
certificates and CRLs without the base64 encoding?

Dave

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Nov 2006 21:11:50 +0000

Taking on the moderator hat I would like to structure this discussion before it takes off in too many directions.

1) The primary issue at hand is if the current Lightweight profile can progress to informational without first updating rfc2560.

2) Secondary is a growing discussion if RFC 2560 needs to be updated for other reasons than accommodating the lightweight profile.

On issue number 1) it is my belief that the lightweight profile should be allowed to progress without updating RFC 2560. I have seen no requirements in RFC 2560 that requires a keyed responder, even if it is clear that a non-keyed responder can only respond to a subset of all valid requests. If the lightweight OCSP profile is allowed to progress, it MUST live within the current restrictions of OCSP with respect to error codes.

On issue number 2) I welcome a debate on a separate thread.

Stefan Santesson
Senior Program Manager

---

From: Sam Hartman <[email-masked]>
Date: Tue, 14 Nov 2006 17:22:51 -0500

>>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:

    Stefan> On issue number 1) it is my belief that the lightweight
    Stefan> profile should be allowed to progress without updating RFC
    Stefan> 2560. I have seen no requirements in RFC 2560 that
    Stefan> requires a keyed responder, even if it is clear that a
    Stefan> non-keyed responder can only respond to a subset of all
    Stefan> valid requests. If the lightweight OCSP profile is allowed
    Stefan> to progress, it MUST live within the current restrictions
    Stefan> of OCSP with respect to error codes.

Speaking as an holding a discuss, I cannot agree to allow the
lightweight profile to progress without a standards-track
clarification to 2560.

Your reading of 2560 would not meet the interoperability requirements
that the IETF has established that in general, all clients of a
protocol be able to work with all servers of a protocol.  In order to
meet that requirement RFC 2560 needs to be normatively changed in
order to require that clients be able to send a request including only
one certificate.

Unless I see new arguments I have not seen so far, my discuss stands.

---

From: Russ Housley <[email-masked]>
Date: Tue, 14 Nov 2006 15:32:31 -0500

I think there is value in publishing the format of "PEM" files.  I do 
not think it needs to be done in the PKIX WG, or any WG for that 
matter.  I would be willing to shepherd an Informational RFC through 
the approval process, which would include a 4-week IETF Last Call.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Nov 2006 22:56:38 +0000

Sam,

Could you point us to the applicable interoperability requirements IETF has established in general that would require such clarification of RFC 2560.

What is ironic in this situation is that this a cases where the industry has been able to achieve interoperability (to a fairly high degree at least), also with respect to keyless responders. I don't think we serve the industry by denying publication of an informational document describing how keyless responders has been implemented.

Creating an RFC 2560bis may take considerable time.

Stefan Santesson
Senior Program Manager

> From: Sam Hartman [mailto:[email-masked]]
> Sent: den 14 november 2006 14:23
> To: Stefan Santesson
> Cc: [email-masked]; Michael Myers; Dave Engberg; Russ Housley;
> Price, Bill
> Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 14 Nov 2006 18:16:52 -0500

>handle a composite request. It only specifies how it should be done.

It does not say one way or the other.  That is the problem.  It 
specifies the syntax, without telling the reader whether some or all 
of it is mandatory to implement.  This is the crux of Sam's discuss 
position.  Nothing in the text leads the reader to believe that 
responding to a multi-certificate query is OPTIONAL.

I find the use of "unauthorized" to indicate that a client cannot 
make a multi-certificate request unacceptable.  To me, that implies 
that some other client would be authorized to make such a request.

I also find the use of "internalError" to indicate that a client 
cannot make a multi-certificate request unacceptable.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 14 Nov 2006 18:12:36 -0500

It is not a problem for OCSP Responders that can relay the request to 
a server with a key.  That server can build the signed response for 
the arbitrary collection of certificates.

Russ

At 06:54 PM 11/13/2006, Stefan Santesson wrote:
>Trust option 3 is valid in theory but in practice it requires that 
>the OCSP responder provide multiple validation paths in the 
>response, one for each issuing CA. Somehow I doubt that this is 
>implemented by anyone.
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Nov 2006 16:06:33 -0800

At 5:25 AM +1300 11/15/06, Peter Gutmann wrote:
>I think the best you could do is create an kind of FYI RFC that

Yes.

>if you could find a WG that would adopt it.

Even better.

At 2:42 PM -0500 11/14/06, David A. Cooper wrote:
>Why is there need to base64 encode everything?  It made sense in PEM 
>due to the limitations of email, but what is the benefit of base64 
>encoding in other situations?

Copy and paste text. This is *commonly* used in IPsec UIs for cert 
issuance, and sometimes for trust anchor passing.

--Paul Hoffman, Director
--VPN Consortium

---

From: Sam Hartman <[email-masked]>
Date: Tue, 14 Nov 2006 22:21:18 -0500

>>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:

    Stefan> Sam, Could you point us to the applicable interoperability
    Stefan> requirements IETF has established in general that would
    Stefan> require such clarification of RFC 2560.

Sure.  Take a look at section 3.1 of
draft-carpenter-protocol-extensions (an approved BCP).  That BCP is
new, but the requirements in that section come from a long list of
RFCs that are quite old.  Brian included a list of RFCs discussing
interoperability in the recent atompub appeal response on HTTP
mandatory authentication.

A central principle of this interoperability is that there is an
interoperable protocol set where I can exchange one product for
another.

In other words I need to be able to set up my OCSP clients and servers
so that I can take vendor A's implementation and exchange it with
vendor B's implementation and have things still work.

The liberal interpretation of 2560 for servers is that they need to be
able to respond to any request.  However that's operationally
undesirable.  So, we need to modify the requirements of the protocol.
Really, we're fixing a spec bug: 2560 is way too unclear on this
issue.

Now, we've passed clarifications documents in the past.  That is
informational documents that describe errors in specs.  But that's not
what this profile is.  The profile is a protocol that specifies
requirements for clients and servers.  That's not something I can be
comfortable with unless it is clearly consistent with the spec.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 16 Nov 2006 01:24:46 +1300

Stephen Kent <[email-masked]> writes:

>I don't think these WGs generally have defined private key encodings, because
>private keys are not transferred over the net and thus are not critical for
>interoperability.

What you mean are "private keys shouldn't be transferred over the net but
frequently are".  The standard format for this is PKCS #12, but that's usually
wrapped up in MIME, not as PEM-format data.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 16 Nov 2006 01:21:46 +1300

"Dieter Bratko" <[email-masked]> writes:

>For that reason a standard giving some recommendations for the usage of PEM
>headers would be very useful. It should not only cover keys, but also
>certificates, crls, requests,... (for instance, some applications use -----
>BEGIN CERTIFICATE REQUEST-----. and some use -----BEGIN NEW CERTIFICATE
>REQUEST-----, and some may use  -----BEGIN PKCS10 REQUEST---- or something
>other for encoding a certificate request).

That's why I suggested that a regexp is the only way to handle this.  You also
need to take into account usage in other environments like PGP and SSH, which
also use the PEM format.  From memory my code's workflow is something like:

  look for '----';
  look for either another '-' or a ' ';
  look for 'BEGIN';

This handles the common PEM start.  Then:

  if the remaining text contains 'SSH' it's an SSH public key;
    goto SSH-processing;
  if the remaining text contains 'PGP' it's a PGP public key;
    goto PGP-processing;
  // Default: It's something X.509-ish
  if the remaining text contains 'REQUEST' or 'PKCS10' it's a PKCS #10 cert request;
  if the remainig text contains 'PRIVATE' it's a private key;
  otherwise it's a cert of some form;

This should handle pretty much everything out there.

Peter.

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Nov 2006 10:29:37 -0500

I believe that this paragraph from RFC 2026 is the reason that Sam is 
willing to permit the document to progress as a Proposed Standard:

    A Proposed Standard should have no known technical omissions with
    respect to the requirements placed upon it.  However, the IESG may
    waive this requirement in order to allow a specification to advance
    to the Proposed Standard state when it is considered to be useful and
    necessary (and timely) even with known technical omissions.

Russ

At 05:56 PM 11/14/2006, Stefan Santesson wrote:

>Sam,
>
>Could you point us to the applicable interoperability requirements 
>IETF has established in general that would require such 
>clarification of RFC 2560.
>
>What is ironic in this situation is that this a cases where the 
>industry has been able to achieve interoperability (to a fairly high 
>degree at least), also with respect to keyless responders. I don't 
>think we serve the industry by denying publication of an 
>informational document describing how keyless responders has been implemented.
>

---

From: "Peter Lipp" <[email-masked]>
Date: Wed, 15 Nov 2006 16:49:43 +0100

> This should handle pretty much everything out there.
Sure. With a heavy machine your are always able to pick up all sorts of junk
that you find on the floor.... :-)

Our software is basically doing the same, but this not really an argument
for producing all sorts of junk. An official document may at least help
avoiding new incarnations of these things....

Peter

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 15 Nov 2006 17:05:43 +0000

> This should handle pretty much everything out there.

I've seen several variants on that. A far from exhaustive list from
memory...

If it includes 'PKCS7' or 'PKCS#7' then it is a PKCS#7 ContentInfo,
usually but not always certs only.

'X509' is normally a certificate but I've also seen it containing PKCS#7
certs only and something called "Netscape Certificates Sequence".

Contains 'CERTIFICATE' oddly enough a certificate.

Contains 'CRL': CRL.

Is 'ENCRYPTED PRIVATE KEY' is PKCS#8 EncryptedPrivateKeyInfo.

Is 'PRIVATE KEY' (with no mention of algorithm) PKCS#8 PrivateKeyInfo.

Is 'RSA PRIVATE KEY' PKCS#1 RSAPrivateKey.

Is 'DSA PRIVATE KEY' SSLeay compatible DSA private key.

Private key types PKCS#8 related can include encryption parameters in
the headers.

Is 'PUBLIC KEY' SubjectPublicKeyInfo (RFC3280 et al).

Contains 'PARAMETERS': DSA, DH, EC parameters of various types.

Steve.

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 15 Nov 2006 09:12:50 -0800

This problem is not limited to multi-certificate requests, there are a
number of optional items in 2560 where this same problem exists (OCSP
request extensions, multi-cert requests where responders cannot
authoritatively respond to all certificates, etc.); 2560 does not tell
implementers how to deal with these cases at all.

This leaves us with a practical problem, since there were at one point
(I have not been watching products in this space for some time) at least
a dozen interoperable implementations of 2560 we need to ask if it is
appropriate for us to change the 2560 in such a way to break those
implementations?

I would argue that continued interoperability trumps technical purity
here, I don't think anyone would argue against adding additional errors
before this was the case the but cat is out of the bag; now the question
becomes what have the implementations done to achieve the
interoperability that does exist, and should we clarify 2560 to make
that more obvious for the next implementers?

In general I don't see a problem with this question in principal but at
the same time I do not want to see us crack open 2560 as it opens the
door to many other edits that have the potential to break
implementations, but if we must how do we limit these edits to those
that provide clarity and do not break these existing implementations?

I also (selfishly maybe) do not want to see this draft be held up any
further, we have reached the point where there is rough consensus in the
WG and with the implementers, we have working code shipping from
multiple vendors and documenting what these interoperable
implementations do to help others in the future just seems to make
sense; frankly I just don't see how holding the LW OCSP draft up helps
anyone.

What I would like to propose is that we let the LW OCSP draft go forward
since it doesn't conflict with 2560 as it stands today and then begin a
2560bis effort, were I would be willing to work with Mike, Dave, Alex to
identify text that would clarify some of these points without breaking
existing implementations as long as the WG and its chairs will help us
limit the scope of these changes to clarifications and not go down the
path of creating a new version of the protocol.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Tuesday, November 14, 2006 3:17 PM
To: Stefan Santesson; [email-masked]
Cc: Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Nov 2006 09:51:32 -0800

At 6:16 PM -0500 11/14/06, Russ Housley wrote:
>Stefan:
>
>>There is no place where RFC 2560 requires the render to 
>>successfully handle a composite request. It only specifies how it 
>>should be done.
>

Unfortunately, I agree with Russ on this one. We boxed ourselves in 
with the definitions of the response semantics because we did not 
predict this case.

I also do not see how we can handle the problem without changing the 
OCSP version number, but I would really like to be wrong about that.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 15 Nov 2006 16:59:34 +0000

> This should handle pretty much everything out there.

I've seen several variants on that a far from exhaustive list from memory...

Contains 'CRL': CRL.

Steve.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Nov 2006 13:16:04 -0500

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:

    Paul> I also do not see how we can handle the problem without
    Paul> changing the OCSP version number, but I would really like to
    Paul> be wrong about that.

You can decide that the interoperability hit of changing the version
number is worse than changing the meaning of the old version
retroactively.  It is always hard to make that call, and you better be
right if you decide not to change a version number.  But it is a
tradeoff it is valid to consider.

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 15 Nov 2006 10:33:21 -0800

How about we expand the meaning of "unauthorized" to mean EITHER the
requestor is not authorized to ask the responder OR the responder is not
authorized to fulfill the request.  That's not *too* ugly, is it?

Given that, everything else (i.e. MUST support singles, SHOULD support
multiples, else respond with error) falls out pretty clean without impacting
extant deployments.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Sam Hartman
Sent: Wednesday, November 15, 2006 10:16 AM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Nov 2006 13:32:13 -0800

>authorized to fulfill the request.  That's not *too* ugly, is it?

No, it isn't. That's a good idea!

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 15 Nov 2006 22:58:29 +0000

Yes it is a good idea.

I just had a conf call first with the editors, then with Russ and then with the editors again.

This is the outcome and what I propose as the way forward. It is my understanding that this is acceptable to both the Security AD's as well as the editors.

Background and problem statement:
According to the current definitions in RFC 2560, especially the definitions of error responses, there is currently no adequate response defined for some legal requests if the responder has no signing key. In particular this is the case when the responder is limited to just returning pre-produced responses for a subset of all valid requests.

Proposed way forward:
In order to resolve this situation, the lightweight profile will have to update/clarify the meaning of error codes, in particular the "unauthorized" error response, so that it updates the definition in RFC 2560 and allows the usage specified in the lightweight profile. To do so, the lightweight profile must be a standards track document.

If this solution is acceptable, the lightweight profile will be returned to the WG to make this update and to go through a new WG last call to acknowledge that rough consensus is not broken by the update.

Is this approach acceptable to the WG?

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 15 november 2006 13:32
> To: Michael Myers; Sam Hartman
> Cc: [email-masked]

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 15 Nov 2006 15:14:15 -0800

Stefan, Steve:

Works for me IF it is understood that:

The LW OCSP I-D does not nor is intended to
update, redefine, obsolete or otherwise diminish
2560 as the base document defining OCSP.

Rather, it maps that protocol onto a specific
context of need.  Among other of its effects it
expands without conflict against original intent
the definition of the "unauthorized" error code
as I proposed below.

Is that the deal?

Mike

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Wednesday, November 15, 2006 2:58 PM
To: Paul Hoffman; Michael Myers; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Yes it is a good idea.

I just had a conf call first with the editors, then with Russ and then with
the editors again.

This is the outcome and what I propose as the way forward. It is my
understanding that this is acceptable to both the Security AD's as well as
the editors.

Background and problem statement:
According to the current definitions in RFC 2560, especially the definitions
of error responses, there is currently no adequate response defined for some
legal requests if the responder has no signing key. In particular this is
the case when the responder is limited to just returning pre-produced
responses for a subset of all valid requests.

Proposed way forward:
In order to resolve this situation, the lightweight profile will have to
update/clarify the meaning of error codes, in particular the "unauthorized"
error response, so that it updates the definition in RFC 2560 and allows the
usage specified in the lightweight profile. To do so, the lightweight
profile must be a standards track document.

If this solution is acceptable, the lightweight profile will be returned to
the WG to make this update and to go through a new WG last call to
acknowledge that rough consensus is not broken by the update.

Stefan Santesson
Senior Program Manager

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Nov 2006 19:54:40 -0500

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    Michael> Stefan, Steve: Works for me IF it is understood that:

    Michael> The LW OCSP I-D does not nor is intended to update,
    Michael> redefine, obsolete or otherwise diminish 2560 as the base
    Michael> document defining OCSP.

What does this paragraph mean?

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 15 Nov 2006 17:05:57 -0800

Sam,

I cannot state the point more precisely.
Let's try this:  What do you think it means?

Mike

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Nov 2006 20:54:32 -0500

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    Michael> Sam, I cannot state the point more precisely.  Let's try
    Michael> this: What do you think it means?

Obselete is clear.  I have no idea why you would care about
diminishing a spec, or what that would mean.

As far as updating and redefining, I don't know whether you consider
the sort of text in the profile that broadens error codes to be an
update/redefinition.

What I think is true is that:

* the profile does not change the behavior of things that do not
  conform to the profile.

* There exist things that do not conform to the profile that will not
  interoperate with the profile.

* Clients that conform to the profile conform to 2560.

* Servers that conform to the profile will conform to 2560bis; it is
  rather unclear whether they conform to 2560.

* It is possible to write a server that conforms both to the profile
  and 2560, but to do so you have to give up some of the advantages of
  the profile.

If those bullet points aren't enough to make you happy, what else
would you need?

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Nov 2006 23:02:40 -0500

>2560 as the base document defining OCSP.

At a minimum, it needs update RFC 2560 to explain the ways that the 
"unauthorized" error code is used.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Nov 2006 22:47:53 -0500

I think that this is the minimum change that is needed in an update 
to RFC 2560.

It can appear in the LW OCSP document if the PKIX WG agrees that the 
LW OCSP document is a standards-track update to RFC 2560.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 16 Nov 2006 06:35:21 -0800

Maybe what makes the most sense is to update 2560 with this definition since
2560 is normatively referenced in other RFCs.  I'm not talking BIS, just a
quick sentence or two.

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Russ

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 16 Nov 2006 14:11:58 -0500

And change the word "unauthorized" to something else, like
"unauthorized/unsupported".

It is incorrect to say that a responder that wasn't designed to
properly handle multiple cert requests is "unauthorized" to
respond to them.

The fact that my 1971 Chevy Vega couldn't do 100 MPH downhill
in a tailwind doesn't mean that it wasn't authorized to go
that fast -- it was simply incapable of doing so.

-----Original Message-----
From: Michael Myers

---

From: Ryan Hurst <[email-masked]>
Date: Thu, 16 Nov 2006 11:57:09 -0800

If that were possible this would be the text I would propose:

The response "unauthorized" is returned in cases where the client is not
authorized to request a response or the server is not capable of
responding authoritatively.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Thursday, November 16, 2006 6:35 AM
To: Russ Housley; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Maybe what makes the most sense is to update 2560 with this definition
since
2560 is normatively referenced in other RFCs.  I'm not talking BIS, just
a
quick sentence or two.

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Russ

---

From: "Price, Bill" <[email-masked]>
Date: Thu, 16 Nov 2006 17:01:23 -0500

I too would like to see a small modification made to the specs to
better explain the error code. However, I think the proposals are "off
the mark." The error message in both its "sound bite" title and the
proposed expanded descriptions sound like there's an error at the
responder (server). The user of a client that got such an error would
likely look for problems at the responder. 

The most likely cause of the "unauthorized" error is an ill-conceived
but syntactically correct request that asks for the status either of a
certificate from a non-supported CA or of an expired or yet-to-be
issued certificate. (The case where a presigned responder didn't have a
presigned response available.) This situation may seem unlikely but it
has happened because of misconfiguration or bugs in homegrown clients. 

I'd recommend some words that the error "can occur when a keyless
responder does not have a presigned response available."  A few words
more could explain that a request as described above would provoke the
unauthorized response.

I recommend fixing the description to be user friendly so that people
who encounter the error know quickly why it happened and where to look
to fix it. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ryan Hurst
Sent: Thursday, November 16, 2006 2:57 PM
To: Michael Myers; Russ Housley; Stefan Santesson; Paul Hoffman; Sam
Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

The response "unauthorized" is returned in cases where the client is
not
authorized to request a response or the server is not capable of
responding authoritatively.

Ryan

-----Original Message-----
[mailto:[email-masked]]

Maybe what makes the most sense is to update 2560 with this definition
since
2560 is normatively referenced in other RFCs.  I'm not talking BIS,
just
a
quick sentence or two.

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Russ

---

From: Ryan Hurst <[email-masked]>
Date: Thu, 16 Nov 2006 14:12:32 -0800

In-line

-----Original Message-----
From: Price, Bill [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 2:01 PM
To: Ryan Hurst; Michael Myers; Russ Housley; Stefan Santesson; Paul
Hoffman; Sam Hartman
Cc: [email-masked]

The most likely cause of the "unauthorized" error is an ill-conceived
but syntactically correct request that asks for the status either of a
certificate from a non-supported CA or of an expired or yet-to-be
issued certificate. (The case where a presigned responder didn't have a
presigned response available.) This situation may seem unlikely but it
has happened because of misconfiguration or bugs in homegrown clients. 
[rmh] Bill this is just once case, what if a client includes a
unsupported extension if the responder was keyed but proxying the
request to a authoritative responder with the intent to re-sign but the
proxy server was not available, or if the client included a unsupported
identifier (byKey vs byname) there are lots of cases where a server is
not able to provide a authoritative responses.

I'd recommend some words that the error "can occur when a keyless
responder does not have a presigned response available."  A few words
more could explain that a request as described above would provoke the
unauthorized response.
[rmh] It needs to be more generic than that unfortunaltey.

I recommend fixing the description to be user friendly so that people
who encounter the error know quickly why it happened and where to look
to fix it. 
[rmh] This is something implementations should deal with as part of
their debugging tools, documentation and logging.

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

Ryan

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

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 17 Nov 2006 11:51:14 +0000

Mike,

I'm not sure which one is best, but we have two options as you say;

1) Update RFC 2560 in the Lightweight (LW) profile, thus making the LW profile a standards document.
2) Creating a separate standards track document, updating just this error code and keep the LW profile as informational.

Sam, can you give any guidance on what you think is most appropriate from your perspective?
If the WG chooses option 2) can the LW document and the update document progress together?

I suppose both options are valid, also considering that many documents reference 2560.

Stefan Santesson
Senior Program Manager

> Sent: den 16 november 2006 15:35
> just a

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 17 Nov 2006 12:06:34 +0000

Could we just define this error response as "Unsupported request". This could describe the case where the server in unable to respond to a syntactically well formed request, either because it requires a non-supported response or the server is unauthorized to respond.

It would provide two important pieces of information

1) The request was well formed, so there was no error in the request; and
2) The responder can't respond to this request, so there is no point in retrying the same request to this responder.

I think this is enough information for client to gracefully handle the situation and move on with other available status validation options such as:

 - Retrying with a simpler request (such as one conforming to the LW profile).
 - Trying another responder
 - Falling back to CRL validation.

Stefan Santesson
Senior Program Manager

> From: Ryan Hurst
> Sent: den 16 november 2006 23:13
> To: Price, Bill; Michael Myers; Russ Housley; Stefan Santesson; Paul
> Hoffman; Sam Hartman
> Cc: [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Nov 2006 09:33:22 -0500

>>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:

    Stefan> Could we just define this error response as "Unsupported
    Stefan> request". This could describe the case where the server in
    Stefan> unable to respond to a syntactically well formed request,
    Stefan> either because it requires a non-supported response or the
    Stefan> server is unauthorized to respond.  It would provide two
    Stefan> important pieces of information

    Stefan> 1) The request was well formed, so there was no error in
    Stefan> the request; and 2) The responder can't respond to this
    Stefan> request, so there is no point in retrying the same request
    Stefan> to this responder.

    Stefan> I think this is enough information for client to
    Stefan> gracefully handle the situation and move on with other
    Stefan> available status validation options such as:

I'm not sure this is quite enough information.  I think that you need
to somehow indicate the mandatory to implement minimal response set so
clients can fall back to that when they get this error.

I.E. if I only know how to use OCSP and I get this error there should
be guidance telling me to retry without a nonce, with one cert and
without options.

Now, in the interests of moving forward, I'm willing to let this slide
especially since the lw profile gives you that guidance and especially
if we're eventually going to do a 2560bis.  2560bis would actually
need to speak to mandatory to implement behavior.

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 17 Nov 2006 13:58:45 -0800

Chairs,

If I drafted a 2560bis along these lines and submitted it to the IETF
editor, would you approve its publication as a PKIX Standards Track work
item?

Mike

> Sent: Friday, November 17, 2006 6:33 AM
>
> . . .
>
>
> in the interests of moving forward, I'm willing to let this slide