ID draft-ietf-krb-wg-ocsp-for-pkinit-05

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Larry Zhu

I would like to present two changes for this ID.

1) The PADATA number 17 was taken by PKINIT, so we would like to bump it
up to 18.

2) Based on MS OSCSP-for-PKINIT implementations in Longhorn release, we
found it is very difficult to locate the OCSP response for the signer's
certificate when there is more than one OCSP response. This is because a
complete RFC2560 OCSP response can contain the responses for a
collection of certificates. In order to simplify implementation and
ensure compliant clients work with off-the-shelf OCSP responders, -05 is
updated to say that the first OcspResponse MUST contain the OCSP
response for the signer's certificate.

Here is a link to the updated -05:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-ocsp-for-pkinit-05
.txt.

Thanks, -- Larry


Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Jeffrey Hutzelman


On Tuesday, May 31, 2005 11:09:42 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> 1) The PADATA number 17 was taken by PKINIT, so we would like to bump it
> up to 18.

I'm not sure how we ended up with this overlap, but I'll ask Cliff to check
on the number allocations and make sure the numbers we are using in this
document and in PKINIT are properly allocated so we don't end up with any
more problems.


> 2) Based on MS OSCSP-for-PKINIT implementations in Longhorn release, we
> found it is very difficult to locate the OCSP response for the signer's
> certificate when there is more than one OCSP response. This is because a
> complete RFC2560 OCSP response can contain the responses for a
> collection of certificates. In order to simplify implementation and
> ensure compliant clients work with off-the-shelf OCSP responders, -05 is
> updated to say that the first OcspResponse MUST contain the OCSP
> response for the signer's certificate.

Note that this document has already passed last call and been given to Sam
to take to the IESG.  He's been holding it until PKINIT is done, so it's
not too late to make this update, but it does require a consensus call.
So, I'll make that call now -- please send any comments for or against
Larry's text by the end of next week or so.  The exact changes are the
differences between ocsp-for-pkinit-04 and -05.

-- Jeff


Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Chaskiel Grundman-3
In reply to this post by Larry Zhu
--On Tuesday, May 31, 2005 23:09:42 -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> In order to simplify implementation and
> ensure compliant clients work with off-the-shelf OCSP responders, -05 is
> updated to say that the first OcspResponse MUST contain the OCSP
> response for the signer's certificate.

1) who is the 'signer'? the kdc? something else? the word 'signer' doesn't
appear anywhere else in this document or pkinit, and in 2560, it refers to
the ocsp responder. However, it doesn't make sense for there to be an ocsp
response for the ocsp signer itself.
2) it seems like this will force the kerberos implementation to understand
ocsp and not just pass data in and out of a CMS library. That seems
unfortunate.



attachment0 (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Larry Zhu
In reply to this post by Larry Zhu
Chaskiel M Grundman wrote:
> who is the 'signer'?
The "signer" means the KDC for AS_REP, and the client for the AS_REQ.

I can clarify this.

> 2) it seems like this will force the Kerberos implementation to
understand

> ocsp and not just pass data in and out of a CMS library. That seems
> unfortunate.

This is correct. The OCSP is sent outside of the CMS message in this
case.

-- Larry


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Chaskiel M
Grundman
Sent: Wednesday, June 01, 2005 2:01 PM
To: [hidden email]
Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

--On Tuesday, May 31, 2005 23:09:42 -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> In order to simplify implementation and
> ensure compliant clients work with off-the-shelf OCSP responders, -05
is
> updated to say that the first OcspResponse MUST contain the OCSP
> response for the signer's certificate.

1) who is the 'signer'? the kdc? something else? the word 'signer'
doesn't
appear anywhere else in this document or pkinit, and in 2560, it refers
to
the ocsp responder. However, it doesn't make sense for there to be an
ocsp
response for the ocsp signer itself.
2) it seems like this will force the kerberos implementation to
understand
ocsp and not just pass data in and out of a CMS library. That seems
unfortunate.




Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Nicolas Williams
On Wed, Jun 01, 2005 at 02:38:59PM -0700, Liqiang(Larry) Zhu wrote:

> Chaskiel M Grundman wrote:
> > who is the 'signer'?
> The "signer" means the KDC for AS_REP, and the client for the AS_REQ.
>
> I can clarify this.
>
> > 2) it seems like this will force the Kerberos implementation to
> understand
>
> > ocsp and not just pass data in and out of a CMS library. That seems
> > unfortunate.
>
> This is correct. The OCSP is sent outside of the CMS message in this
> case.

I'm assuming -- and correct me if I'm wrong, please -- that APIs for
obtaining OCSP Responses will allow the caller to specify one or more
certs for which to get an OCSP Response.  It seems like the OCSP
protocol should map fairly cleanly onto an API, as long as developers
understand that OCSP Responses are useufl as tokens that can be
exchanged by peers there should be no problem.

Nico
--


Reply | Threaded
Open this post in threaded view
|

RE: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Larry Zhu
In reply to this post by Larry Zhu
Nicolas.Williams wrote:
> I'm assuming -- and correct me if I'm wrong, please -- that APIs for
> obtaining OCSP Responses will allow the caller to specify one or more
> certs for which to get an OCSP Response.  It seems like the OCSP
protocol
> should map fairly cleanly onto an API, as long as developers
understand
> that OCSP Responses are useufl as tokens that can be exchanged by
peers >
> there should be no problem.

You are correct. But the information is lost when we send the OCSP
responses over the wire.

-----Original Message-----
From: Nicolas Williams [mailto:[hidden email]]
Sent: Wednesday, June 01, 2005 3:30 PM
To: Liqiang(Larry) Zhu
Cc: Chaskiel M Grundman; [hidden email]
Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

On Wed, Jun 01, 2005 at 02:38:59PM -0700, Liqiang(Larry) Zhu wrote:

> Chaskiel M Grundman wrote:
> > who is the 'signer'?
> The "signer" means the KDC for AS_REP, and the client for the AS_REQ.
>
> I can clarify this.
>
> > 2) it seems like this will force the Kerberos implementation to
> understand
>
> > ocsp and not just pass data in and out of a CMS library. That seems
> > unfortunate.
>
> This is correct. The OCSP is sent outside of the CMS message in this
> case.

I'm assuming -- and correct me if I'm wrong, please -- that APIs for
obtaining OCSP Responses will allow the caller to specify one or more
certs for which to get an OCSP Response.  It seems like the OCSP
protocol should map fairly cleanly onto an API, as long as developers
understand that OCSP Responses are useufl as tokens that can be
exchanged by peers there should be no problem.

Nico
--


Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Nicolas Williams
On Wed, Jun 01, 2005 at 03:36:22PM -0700, Liqiang(Larry) Zhu wrote:

> Nicolas.Williams wrote:
> > I'm assuming -- and correct me if I'm wrong, please -- that APIs for
> > obtaining OCSP Responses will allow the caller to specify one or more
> > certs for which to get an OCSP Response.  It seems like the OCSP
> protocol
> > should map fairly cleanly onto an API, as long as developers
> understand
> > that OCSP Responses are useufl as tokens that can be exchanged by
> peers >
> > there should be no problem.
>
> You are correct. But the information is lost when we send the OCSP
> responses over the wire.

What information is lost?


Reply | Threaded
Open this post in threaded view
|

RE: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Larry Zhu
In reply to this post by Larry Zhu
The information how the OCSP was obtained (for which certificate) is
lost.

-----Original Message-----
From: Nicolas Williams [mailto:[hidden email]]
Sent: Wednesday, June 01, 2005 3:43 PM
To: Liqiang(Larry) Zhu
Cc: Chaskiel M Grundman; [hidden email]
Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

On Wed, Jun 01, 2005 at 03:36:22PM -0700, Liqiang(Larry) Zhu wrote:
> Nicolas.Williams wrote:
> > I'm assuming -- and correct me if I'm wrong, please -- that APIs for

> > obtaining OCSP Responses will allow the caller to specify one or
more

> > certs for which to get an OCSP Response.  It seems like the OCSP
> protocol
> > should map fairly cleanly onto an API, as long as developers
> understand
> > that OCSP Responses are useufl as tokens that can be exchanged by
> peers >
> > there should be no problem.
>
> You are correct. But the information is lost when we send the OCSP
> responses over the wire.

What information is lost?


Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Nicolas Williams
On Wed, Jun 01, 2005 at 03:44:21PM -0700, Liqiang(Larry) Zhu wrote:
> The information how the OCSP was obtained (for which certificate) is
> lost.

It's not.

The API roughly should be like this:

getOCSPResponse(Cert) -> OCSPResponse
getOCSPResponse(Cert, ...) -> SEQUENCE OF OCSPResponse
getOCSPResponsesForChain(Cert) -> SEQUENCE OF OCSPResponse
getOCSPResponsesForChains(Cert, ...) -> SEQUENCE OF OCSPResponse

verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN
verifyWithOCSPResponses(Cert, SEQUENCE OF OCSPResponse) -> BOOLEAN

Whereas an API like this:

verifyWithOCSP(Cert) -> BOOLEAN

is clearly not useful in this case.

Nico
--


Reply | Threaded
Open this post in threaded view
|

RE: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Larry Zhu
In reply to this post by Larry Zhu
[hidden email] wrote:
> verifyWithOCSP(Cert) -> BOOLEAN
This is what we have; it is clearly more efficient than the other you
proposed.


-----Original Message-----
From: Nicolas Williams [mailto:[hidden email]]
Sent: Wednesday, June 01, 2005 3:50 PM
To: Liqiang(Larry) Zhu
Cc: Chaskiel M Grundman; [hidden email]
Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

On Wed, Jun 01, 2005 at 03:44:21PM -0700, Liqiang(Larry) Zhu wrote:
> The information how the OCSP was obtained (for which certificate) is
> lost.

It's not.

The API roughly should be like this:

getOCSPResponse(Cert) -> OCSPResponse
getOCSPResponse(Cert, ...) -> SEQUENCE OF OCSPResponse
getOCSPResponsesForChain(Cert) -> SEQUENCE OF OCSPResponse
getOCSPResponsesForChains(Cert, ...) -> SEQUENCE OF OCSPResponse

verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN
verifyWithOCSPResponses(Cert, SEQUENCE OF OCSPResponse) -> BOOLEAN

Whereas an API like this:

verifyWithOCSP(Cert) -> BOOLEAN

is clearly not useful in this case.

Nico
--


Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Nicolas Williams
On Wed, Jun 01, 2005 at 04:21:11PM -0700, Liqiang(Larry) Zhu wrote:
> [hidden email] wrote:
> > verifyWithOCSP(Cert) -> BOOLEAN
> This is what we have; it is clearly more efficient than the other you
> proposed.

It clearly does not match the model of this I-D though.

Good luck,

Nico
--


Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Jeffrey Altman
In reply to this post by Larry Zhu
Larry:

What does your

  verifyWithOCSP(Cert) -> BOOLEAN

function do?   That looks to me as if it will perform its own OSCP
request.   Is this being executed by the PKINIT client or the KDC?

Jeffrey Altman


Liqiang(Larry) Zhu wrote:

> [hidden email] wrote:
>
>>verifyWithOCSP(Cert) -> BOOLEAN
>
> This is what we have; it is clearly more efficient than the other you
> proposed.
>
>
> -----Original Message-----
> From: Nicolas Williams [mailto:[hidden email]]
> Sent: Wednesday, June 01, 2005 3:50 PM
> To: Liqiang(Larry) Zhu
> Cc: Chaskiel M Grundman; [hidden email]
> Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05
>
> On Wed, Jun 01, 2005 at 03:44:21PM -0700, Liqiang(Larry) Zhu wrote:
>
>>The information how the OCSP was obtained (for which certificate) is
>>lost.
>
>
> It's not.
>
> The API roughly should be like this:
>
> getOCSPResponse(Cert) -> OCSPResponse
> getOCSPResponse(Cert, ...) -> SEQUENCE OF OCSPResponse
> getOCSPResponsesForChain(Cert) -> SEQUENCE OF OCSPResponse
> getOCSPResponsesForChains(Cert, ...) -> SEQUENCE OF OCSPResponse
>
> verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN
> verifyWithOCSPResponses(Cert, SEQUENCE OF OCSPResponse) -> BOOLEAN
>
> Whereas an API like this:
>
> verifyWithOCSP(Cert) -> BOOLEAN
>
> is clearly not useful in this case.
>
> Nico

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Larry Zhu
In reply to this post by Larry Zhu
I think I meant

  verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN

instead.

Currently it is for the KDC cert and this is verified by the client.

-- larry



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey Altman
Sent: Thursday, June 02, 2005 9:33 AM
To: [hidden email]
Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Larry:

What does your

  verifyWithOCSP(Cert) -> BOOLEAN

function do?   That looks to me as if it will perform its own OSCP
request.   Is this being executed by the PKINIT client or the KDC?

Jeffrey Altman


Liqiang(Larry) Zhu wrote:

> [hidden email] wrote:
>
>>verifyWithOCSP(Cert) -> BOOLEAN
>
> This is what we have; it is clearly more efficient than the other you
> proposed.
>
>
> -----Original Message-----
> From: Nicolas Williams [mailto:[hidden email]]
> Sent: Wednesday, June 01, 2005 3:50 PM
> To: Liqiang(Larry) Zhu
> Cc: Chaskiel M Grundman; [hidden email]
> Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05
>
> On Wed, Jun 01, 2005 at 03:44:21PM -0700, Liqiang(Larry) Zhu wrote:
>
>>The information how the OCSP was obtained (for which certificate) is
>>lost.
>
>
> It's not.
>
> The API roughly should be like this:
>
> getOCSPResponse(Cert) -> OCSPResponse
> getOCSPResponse(Cert, ...) -> SEQUENCE OF OCSPResponse
> getOCSPResponsesForChain(Cert) -> SEQUENCE OF OCSPResponse
> getOCSPResponsesForChains(Cert, ...) -> SEQUENCE OF OCSPResponse
>
> verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN
> verifyWithOCSPResponses(Cert, SEQUENCE OF OCSPResponse) -> BOOLEAN
>
> Whereas an API like this:
>
> verifyWithOCSP(Cert) -> BOOLEAN
>
> is clearly not useful in this case.
>
> Nico


Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Jeffrey Altman
Larry:

Thanks for that clarification.  Why does this function require
a special ordering in the OCSPResponse?

Jeffrey Altman


Liqiang(Larry) Zhu wrote:

> I think I meant
>
>   verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN
>
> instead.
>
> Currently it is for the KDC cert and this is verified by the client.
>
> -- larry
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Jeffrey Altman
> Sent: Thursday, June 02, 2005 9:33 AM
> To: [hidden email]
> Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05
>
> Larry:
>
> What does your
>
>   verifyWithOCSP(Cert) -> BOOLEAN
>
> function do?   That looks to me as if it will perform its own OSCP
> request.   Is this being executed by the PKINIT client or the KDC?
>
> Jeffrey Altman
>
>
> Liqiang(Larry) Zhu wrote:
>
>
>>[hidden email] wrote:
>>
>>
>>>verifyWithOCSP(Cert) -> BOOLEAN
>>
>>This is what we have; it is clearly more efficient than the other you
>>proposed.
>>
>>
>>-----Original Message-----
>>From: Nicolas Williams [mailto:[hidden email]]
>>Sent: Wednesday, June 01, 2005 3:50 PM
>>To: Liqiang(Larry) Zhu
>>Cc: Chaskiel M Grundman; [hidden email]
>>Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05
>>
>>On Wed, Jun 01, 2005 at 03:44:21PM -0700, Liqiang(Larry) Zhu wrote:
>>
>>
>>>The information how the OCSP was obtained (for which certificate) is
>>>lost.
>>
>>
>>It's not.
>>
>>The API roughly should be like this:
>>
>>getOCSPResponse(Cert) -> OCSPResponse
>>getOCSPResponse(Cert, ...) -> SEQUENCE OF OCSPResponse
>>getOCSPResponsesForChain(Cert) -> SEQUENCE OF OCSPResponse
>>getOCSPResponsesForChains(Cert, ...) -> SEQUENCE OF OCSPResponse
>>
>>verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN
>>verifyWithOCSPResponses(Cert, SEQUENCE OF OCSPResponse) -> BOOLEAN
>>
>>Whereas an API like this:
>>
>>verifyWithOCSP(Cert) -> BOOLEAN
>>
>>is clearly not useful in this case.
>>
>>Nico

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Nicolas Williams
On Thu, Jun 02, 2005 at 01:24:18PM -0400, Jeffrey Altman wrote:

> Larry:
>
> Thanks for that clarification.  Why does this function require
> a special ordering in the OCSPResponse?
>
> Jeffrey Altman
>
>
> Liqiang(Larry) Zhu wrote:
> > I think I meant
> >
> >   verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN
> >
> > instead.
> >
> > Currently it is for the KDC cert and this is verified by the client.

Oh good, so you were lucky then :)

Nico
--


Reply | Threaded
Open this post in threaded view
|

RE: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Larry Zhu
In reply to this post by Larry Zhu
It does not require the order in general, but it requires that the
RFC2560 OCSPResponse contains the revocation status information for the
specified cert. a mis-match will cause this API to fail.

-- Larry

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey Altman
Sent: Thursday, June 02, 2005 10:24 AM
To: [hidden email]
Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Larry:

Thanks for that clarification.  Why does this function require
a special ordering in the OCSPResponse?

Jeffrey Altman


Liqiang(Larry) Zhu wrote:

> I think I meant
>
>   verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN
>
> instead.
>
> Currently it is for the KDC cert and this is verified by the client.
>
> -- larry
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Jeffrey
Altman

> Sent: Thursday, June 02, 2005 9:33 AM
> To: [hidden email]
> Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05
>
> Larry:
>
> What does your
>
>   verifyWithOCSP(Cert) -> BOOLEAN
>
> function do?   That looks to me as if it will perform its own OSCP
> request.   Is this being executed by the PKINIT client or the KDC?
>
> Jeffrey Altman
>
>
> Liqiang(Larry) Zhu wrote:
>
>
>>[hidden email] wrote:
>>
>>
>>>verifyWithOCSP(Cert) -> BOOLEAN
>>
>>This is what we have; it is clearly more efficient than the other you
>>proposed.
>>
>>
>>-----Original Message-----
>>From: Nicolas Williams [mailto:[hidden email]]
>>Sent: Wednesday, June 01, 2005 3:50 PM
>>To: Liqiang(Larry) Zhu
>>Cc: Chaskiel M Grundman; [hidden email]
>>Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05
>>
>>On Wed, Jun 01, 2005 at 03:44:21PM -0700, Liqiang(Larry) Zhu wrote:
>>
>>
>>>The information how the OCSP was obtained (for which certificate) is
>>>lost.
>>
>>
>>It's not.
>>
>>The API roughly should be like this:
>>
>>getOCSPResponse(Cert) -> OCSPResponse
>>getOCSPResponse(Cert, ...) -> SEQUENCE OF OCSPResponse
>>getOCSPResponsesForChain(Cert) -> SEQUENCE OF OCSPResponse
>>getOCSPResponsesForChains(Cert, ...) -> SEQUENCE OF OCSPResponse
>>
>>verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN
>>verifyWithOCSPResponses(Cert, SEQUENCE OF OCSPResponse) -> BOOLEAN
>>
>>Whereas an API like this:
>>
>>verifyWithOCSP(Cert) -> BOOLEAN
>>
>>is clearly not useful in this case.
>>
>>Nico


Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Jeffrey Altman
I agree that if you pass in the wrong OCSPResponse you will get a
failure.   Why would the client be given the wrong OCSPResponse by
the KDC?

Jeffrey Altman


Liqiang(Larry) Zhu wrote:

> It does not require the order in general, but it requires that the
> RFC2560 OCSPResponse contains the revocation status information for the
> specified cert. a mis-match will cause this API to fail.
>
> -- Larry
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Jeffrey Altman
> Sent: Thursday, June 02, 2005 10:24 AM
> To: [hidden email]
> Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05
>
> Larry:
>
> Thanks for that clarification.  Why does this function require
> a special ordering in the OCSPResponse?
>
> Jeffrey Altman
>
>
> Liqiang(Larry) Zhu wrote:
>
>>I think I meant
>>
>>  verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN
>>
>>instead.
>>
>>Currently it is for the KDC cert and this is verified by the client.
>>
>>-- larry
>>
>>
>>
>>-----Original Message-----
>>From: [hidden email]
>>[mailto:[hidden email]] On Behalf Of Jeffrey
>
> Altman
>
>>Sent: Thursday, June 02, 2005 9:33 AM
>>To: [hidden email]
>>Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05
>>
>>Larry:
>>
>>What does your
>>
>>  verifyWithOCSP(Cert) -> BOOLEAN
>>
>>function do?   That looks to me as if it will perform its own OSCP
>>request.   Is this being executed by the PKINIT client or the KDC?
>>
>>Jeffrey Altman
>>
>>
>>Liqiang(Larry) Zhu wrote:
>>
>>
>>
>>>[hidden email] wrote:
>>>
>>>
>>>
>>>>verifyWithOCSP(Cert) -> BOOLEAN
>>>
>>>This is what we have; it is clearly more efficient than the other you
>>>proposed.
>>>
>>>
>>>-----Original Message-----
>>>From: Nicolas Williams [mailto:[hidden email]]
>>>Sent: Wednesday, June 01, 2005 3:50 PM
>>>To: Liqiang(Larry) Zhu
>>>Cc: Chaskiel M Grundman; [hidden email]
>>>Subject: Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05
>>>
>>>On Wed, Jun 01, 2005 at 03:44:21PM -0700, Liqiang(Larry) Zhu wrote:
>>>
>>>
>>>
>>>>The information how the OCSP was obtained (for which certificate) is
>>>>lost.
>>>
>>>
>>>It's not.
>>>
>>>The API roughly should be like this:
>>>
>>>getOCSPResponse(Cert) -> OCSPResponse
>>>getOCSPResponse(Cert, ...) -> SEQUENCE OF OCSPResponse
>>>getOCSPResponsesForChain(Cert) -> SEQUENCE OF OCSPResponse
>>>getOCSPResponsesForChains(Cert, ...) -> SEQUENCE OF OCSPResponse
>>>
>>>verifyWithOCSPResponse(Cert, OCSPResponse) -> BOOLEAN
>>>verifyWithOCSPResponses(Cert, SEQUENCE OF OCSPResponse) -> BOOLEAN
>>>
>>>Whereas an API like this:
>>>
>>>verifyWithOCSP(Cert) -> BOOLEAN
>>>
>>>is clearly not useful in this case.
>>>
>>>Nico

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Nicolas Williams
On Thu, Jun 02, 2005 at 02:17:00PM -0400, Jeffrey Altman wrote:
> I agree that if you pass in the wrong OCSPResponse you will get a
> failure.   Why would the client be given the wrong OCSPResponse by
> the KDC?

We have SEQUENCE OF OcspResponse so we can have an OCSP Response for
each cert in the chain.

Nico
--


Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Jeffrey Hutzelman


On Thursday, June 02, 2005 01:46:23 PM -0500 Nicolas Williams
<[hidden email]> wrote:

> On Thu, Jun 02, 2005 at 02:17:00PM -0400, Jeffrey Altman wrote:
>> I agree that if you pass in the wrong OCSPResponse you will get a
>> failure.   Why would the client be given the wrong OCSPResponse by
>> the KDC?
>
> We have SEQUENCE OF OcspResponse so we can have an OCSP Response for
> each cert in the chain.

Right, and as I understand it, Larry's proposed change is to require the
response for the KDC's own cert to be the first one in that SEQUENCE, so it
is easy to find.

-- Jeff


Reply | Threaded
Open this post in threaded view
|

Re: ID draft-ietf-krb-wg-ocsp-for-pkinit-05

Nicolas Williams
On Thu, Jun 02, 2005 at 03:03:05PM -0400, Jeffrey Hutzelman wrote:

>
>
> On Thursday, June 02, 2005 01:46:23 PM -0500 Nicolas Williams
> <[hidden email]> wrote:
>
> >On Thu, Jun 02, 2005 at 02:17:00PM -0400, Jeffrey Altman wrote:
> >>I agree that if you pass in the wrong OCSPResponse you will get a
> >>failure.   Why would the client be given the wrong OCSPResponse by
> >>the KDC?
> >
> >We have SEQUENCE OF OcspResponse so we can have an OCSP Response for
> >each cert in the chain.
>
> Right, and as I understand it, Larry's proposed change is to require the
> response for the KDC's own cert to be the first one in that SEQUENCE, so it
> is easy to find.

Right.  It's easy for the sender to order the OCSP Responses for its
cert and chain to match the cert chain.

It's harder for the receipient to efficiently deal with an un-ordered
sequence or set of OCSP Responses.


12