Subject: Re: [pkix] new text for 5280bis, Section 3.2

From: [email-masked] (Martin Rex)
Date: Wed, 1 Aug 2012 22:22:42 +0200 (CEST)

Santosh Chokhani wrote:
>
> How about the following:
> 
> Consistent with Section 3.4.61 of X.509 (11/2008) we note that use of
> self-issued certificates and self-signed certificates when issued by
> entities other than CAs are outside the scope of this specification.
> Thus, for example, a web server or client might generate a self-signed
> certificate to identity itself. These certificates, and how a relying
> party uses them to authenticate asserted identities, are both outside
> the scope of RFC 5280.

OT:

>From the parallel discussion thread about OCSP 2560bis, I noticed
a throroughly confusing example in Appendix E.3
Locally Trusted OCSP Responder at the end of -04 document:

  http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-04#page-42

which uses a self-signed certificate of a non-CA entity.

This is outside of PKIX/rfc5280 and an option not listed under 2.3.5.2:

  http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-04#section-2.3.5.2

and looks to _me_ like a bad idea in general.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 1 Aug 2012 17:02:29 -0400

Martin,

I do not follow what you are saying.

Are you saying what Steve drafted is fine or my edits are fine or neither is fine?

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2012 4:23 PM
To: Santosh Chokhani
Cc: Stephen Kent; pkix
Subject: Re: [pkix] new text for 5280bis, Section 3.2

OT:

>From the parallel discussion thread about OCSP 2560bis, I noticed a throroughly confusing example in Appendix E.3 Locally Trusted OCSP Responder at the end of -04 document:

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 1 Aug 2012 23:33:40 +0200 (CEST)

> Are you saying what Steve drafted is fine or my edits are fine or neither is fine?

I'm sorry for the confusion.

The text works for me (the leading text about BasicConstraints was
confusing, but is not longer part of your proposal).

I intended to indicate with "OT:" ("off-topic") that this comment
was not about the proposed text itself (topic of this discussion thread)
but related to it.

Primarily I wanted to point out that the example usage scenario
for a local OCSP responder, that is depicted in Appendix E.3 of the
rfc2560bis-04 document, a self-signed cert that is issued by a
non-CA is used.

To me it looks very odd that the only usage scenario described
for a local OCSP responder is implicitly out-of-scope for rfc5280
and will be explicitly out-of-scope for rfc5280bis.

-Martin

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 2 Aug 2012 10:45:14 -0400

Martin,

I don't know why you find the example "thoroughly confusing" or "a bad 
idea in general," but if you think this is such a bad example, what 
would you propose as a good example of a locally trusted OCSP responder?

Dave

---

From: [email-masked] (Martin Rex)
Date: Mon, 20 Aug 2012 23:19:15 +0200 (CEST)

> would you propose as a good example of a locally trusted OCSP responder?

It is completely out-of-scope for PKIX/rfc5280 how to handle
a locally trusted OCSP responder cert that is a self-signed non-CA cert
with respect to validating that cert, revoking such a cert and
(re-)distributing an update to such a cert.

I believe that creating an example, which is out-of-scope for PKIX
in so many ways, to be a bad idea in general.

Personally, I believe that a local OCSP responder is an idea that is
not well thought out, because it does not appear to fit with PKIX
(in-scope) protocol features at all.

How to identify whether a signer is a "trusted local OCSP signer",
and how to configure for which CAs it is trusted to provide
revocation info looks quite complicated to me.  Is it documented
somewhere how you would configure this for e.g. Microsoft Windows?

-Martin

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 20 Aug 2012 18:17:53 -0400

This just seems to be a long-winded way of saying that you don't have a 
good example of a locally trusted OCSP responder because you don't like 
the idea.

Well, whether you like it or not, locally trusted OCSP responders are 
explicitly permitted by RFC 2560.  I also totally disagree with your 
implication that it is unacceptable to include an example of a locally 
trusted OCSP responder in which the responder's key is distributed in 
the form of a self-signed certificate.  The 5280 update document states 
that self-signed certificates that are issued by other than CAs are 
outside the scope of RFC 5280 (not PKIX).  It does not say that such 
certificates cannot be used as an example in a PKIX document.

Furthermore, the example that you disagree with does not specify "how to 
handle" the self-signed certificate, it simply indicates in the figure 
that the responder's public key appears in a self-signed certificate.  
Neither does the example provide any details about how to configure a 
client to work with a locally trusted OCSP responder.

On 08/20/2012 05:19 PM, Martin Rex wrote:
> .

---

From: [email-masked] (Martin Rex)
Date: Tue, 21 Aug 2012 01:01:01 +0200 (CEST)

> good example of a locally trusted OCSP responder because you don't like 

I'm not aware of any reasonable local OCSP responder scenario, any
I have serious doubts that it exists at all.  Prove me wrong.

> explicitly permitted by RFC 2560.

I agree that they're mentioned.  But they're so extremely underspecified,
that I violently disagree that rfc2560 supports "local OCSP responders"
in any remotely meaningful fashion (read: in a fashion that allows
independent interoperable implementations).

>
>                                     I also totally disagree with your 
> the form of a self-signed certificate.

rfc2560 contains a paragraph that is extremely explicit that it might
be dangerous to have an OCSP signer cert for ONE SINGLE CA that is
non-revocable:

http://tools.ietf.org/html/rfc2560#section-4.2.2.2.1

   - A CA may specify that an OCSP client can trust a responder for the
   lifetime of the responder's certificate. The CA does so by including
   the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical
   extension. The value of the extension should be NULL. CAs issuing
   such a certificate should realized that a compromise of the
   responder's key, is as serious as the compromise of a CA key used to
   sign CRLs, at least for the validity period of this certificate. CA's
   may choose to issue this type of certificate with a very short
   lifetime and renew it frequently.

a self-signed local OCSP signer cert is a non-revocable, lifetime-unlimited,
OCSP signer cert valid for *ALL* CAs.  On my scorecards, this makes it the
most irresponsible fashion to configure rfc2560, because it is the
most extreme opposite of what is suggested in the paragraph quoted above.

Therefore I'm stronly opposed to add to the spec an example of a local OCSP
responder using a self-signed non-CA cert.

>
>                                      The 5280 update document states 
> outside the scope of RFC 5280 (not PKIX).

I'm unfamiliar to the definition of the term "PKIX" that you're using.

Self-signed certificates from non-CA entities are outside of scope
for both, ITU-T X.509 and the "PKIX Certificate and CRL Profile"

http://tools.ietf.org/html/rfc5280#section-3

   Following is a simplified view of the architectural model assumed by
   the Public-Key Infrastructure using X.509 (PKIX) specifications.

>
>                                      It does not say that such 

I'm sorry, but I find it somewhat strange that an example description
for how to use an OCSP protocol feature for PKIX is completely out
of scope for PKIX.  Either there is a way to create a reasonable,
comparatively simple and fully in-scope example usage for a local
OCSP responder, or that feature should be pruned from the protocol.

That is what is _supposed_ to happen when a document progresses on
the maturity level of IETF standards.  

-Martin

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 21 Aug 2012 10:34:52 +0200

> I have serious doubts that it exists at all.  Prove me wrong.
an application delegates all validation to a
dedicated validation authority which is managed
by a security staff. a local ocsp responder implements
company wide or personal trust policies and allows to
manage them independently from applications.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 21 Aug 2012 13:28:32 +0000

+1.

Doesn't corporate IT staff retain (at least in principle) the authority to accept OS and application updates from manufacturers, vet them for compatibility with the local environment, and only then push them to the desktop?  In some cases it may just be a rubber stamp (who has the time to keep up with the flood), but the ability is there.

The PKI is responsible for supporting authentication; the local enterprise is responsible for authorization.  In cases where the authorization infrastructure is immature or nonexistent, local managers may wish to revoke the authentication credentials of someone as their desk is being cleaned out and they are escorted out the door, and the PKI may not be able to respond in the desired timeframe.  That may be an extreme example, but there are scenarios where authentication is used as a blunt instrument in lieu of proper authorization.  Local OCSP is a method of implementing that blunt instrument.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Sylvester
Sent: Tuesday, August 21, 2012 4:35 AM
To: [email-masked]
Subject: Re: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2)

On 08/21/2012 01:01 AM, Martin Rex wrote:
> David A. Cooper wrote:
>> This just seems to be a long-winded way of saying that you don't have 
>> a good example of a locally trusted OCSP responder because you don't 
>> like the idea.
> I'm not aware of any reasonable local OCSP responder scenario, any I 
> have serious doubts that it exists at all.  Prove me wrong.
an application delegates all validation to a dedicated validation authority which is managed by a security staff. a local ocsp responder implements company wide or personal trust policies and allows to manage them independently from applications.

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked] (Martin Rex)
Date: Tue, 21 Aug 2012 16:30:33 +0200 (CEST)

> manage them independently from applications.

I know that this theory exists.

But using a self-signed local OCSP signer cert means that there
is no such thing as revocation checking for an omnipotent irrevocable
local OCSP signer.  Rolling/updating that local OCSP signer key is
completely out-of-scope for OCSP/rfc2560 and PKIX/rfc5280.

The bottom line of such a (lack of) security archtecture is that
revocation is merely a second thought, not something with a
solid design.

I would have at least expected the creation of an "local OCSP signer CA"
that issues "local OCSP signer certs", so that the CA cert could be
protected by a procedure that requires manual interaction and the
rolling of the local OCSP signer cert would be based on regular
PKIX mechanisms, rather than being completely out-of-scope.

-Martin

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 21 Aug 2012 10:44:12 -0400

If you create a local CA for the purpose of issuing local OCSP signer 
certificates, how are you going to distribute that CA's public key?  As 
a self-signed certificate?  How are you going to revoke that CA's key if 
it becomes compromised?  PKIs need trust anchors, and those trust 
anchors' keys have to be managed through out-of-band means, whether the 
key is used as a trust anchor for certification path validation or to 
verify OCSP responses.

Are you trying to say that PKIX = RFC 5280?  If that's the case, then 
why does http://datatracker.ietf.org/wg/pkix/ list so many other 
documents?  Any suggestion that the use of a self-signed certificate 
that outside the scope of RFC 5280 cannot be within the scope of another 
document created by the PKIX WG is simply your personal opinion.  And, 
as you would say, I violently disagree with that.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 21 Aug 2012 17:00:10 +0200

On 08/21/2012 04:30 PM, Martin Rex wrote:

> that issues "local OCSP signer certs",

Me 2

---

From: [email-masked] (Martin Rex)
Date: Tue, 21 Aug 2012 19:02:10 +0200 (CEST)

> key is used as a trust anchor for certification path validation or to 

I'm sure there are plenty of resources available that describe the
advantage of _not_ distributing CA certs of online CAs as trust anchors,
but instead create a seperate offline rootCA instance where it is less
of a problem that its cert is not subject to regular revocation checking. 

> as you would say, I violently disagree with that.

By using a local OCSP signer CA to issue local OCSP signer certs
(possibly short-lived, so that revocation checking for that cert
 can be entirely obviated), all involved certs (local OCSP signer CA
and local OCSP signer cert) can be fully PKIX-compliant certs and
PKIX compliant path validation can be performed, rather than doing
out-of-scope certs with out-of-scope key management.

While rfc5280 does not define trust anchor management itself,
it can not exist without trust anchors.  The idea here is to make
new scenarios work exactly like existing scenarios, so that existing
protocols and procedures can be re-used.

Adding certificate revocation checking to a PKI by creating 
an omnipotent irrevocable self-signed OCSP signer entity,
looks extremely odd to me, I'm sorry.

-Martin