Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

["Piyush Jain" <[e-mail]>]

> -----Original Message-----
> From: Martin Rex [mailto:[e-mail]]
> Sent: Wednesday, October 24, 2012 3:41 PM
> To: Piyush Jain
> Cc: 'Stefan Santesson'; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell';
'Peter
> Rybar'; [e-mail]
> Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
> 
> Piyush Jain wrote:
> >
> > The people who are convinced that this is the way to go have not
> > addressed the issues raised in this WG. The little extension does not
> > hurt anyone but it does not provide any value in general except to a
> > few implementations which are compromised. But it does take you down a
> > slippery slope when you start promising that an OCSP responder can do
> > much more than it is supposed to.
> >
> > I don't think that it is unreasonable for a smart implementer to stop
> > signature checking if his responder claims that it checks issuance.
> 
> 
> I completely fail to follow your argument here.
[Piyush]  I think your comments below indicate that you understand the
argument.
> 
> When you say "stop signature checking", do you mean checking the CA
> signature on the certificate for which you perform the OCSP request?
[Piyush] Yes.
> 
> In the exceptional case that
>   - you exclusively use a securely preconfigured local OCSP responder,
>   - this securely preconfigured local OCSP responder uses the optional
>     cert hash extension in his responses and the hash returned with
>     a good response matches the cert in question
>   - you fully trust that securely preconfigured local OCSP responder
>     to issue any cert it pleases like an omnipotent universal CA
> 
> then you may omit the signature check on the certificate in question.

[Piyush] And this is the only exceptional case where the cert hash extension
and returning revoked for not-issued has any value. In every other scenario
it's just a hack providing no additional security. 

> 
> In all other situations, you MUST verify the CA signature of the
certificate
> before using any OCSP AIA in that cert to query its status -- or you
> misunderstand the X.509 security architecture and why it is vitally
important
> that (a) (1) is the very first step in the certificate processing
specified in
> PKIX/rfc5280:
> 
>    http://tools.ietf.org/html/rfc5280#section-6.1.3
> 
[Piyush]  And yet you are arguing for an extension which enables responders
to say that certificate can be non-issued even though the RP has verified
that the CA issued it by performing signature verification.
All this extension does is creates a paradox. If signature on the payload
certificate verifies certificate is issued. If you cannot trust this
cryptographic binding, you cannot trust the cryptographic binding on the
responder's cert because the responder cert is also issued by the same CA.

If the little extension benefits a small number of people who obviously do
not have too much confidence in the security of their CA deployments, they
can publish an informational RFC to accommodate this. Putting it in the
standard just adds overhead for majority of vendors out there who at the
minimum need to justify the reason for not including this feature in their
implementation.


> 
> -Martin