Subject: [pkix] 2560bis

From: Scott Rea <[email-masked]>
Date: Tue, 27 Mar 2012 01:32:03 -0600

If the issue with the responder cert is not clear in respect to CA 
rollover, and it really is expected to follow existing path processing 
from 5280, I am not sure that the proposed text presented just now 
accomplishes that...
why would we just not say that the responder cert should be issued by 
the same trust anchor that the subject cert of the OCSP request chains 
to. Hence if the EE cert now chains to a rolled over CA cert, then the 
responder cert should be issued by that same rolled over CA cert - yes?
Regards,

-- 
Scott Rea

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 27 Mar 2012 09:32:39 -0400

There is a difference of opinion on this one.

In my reading 2560 is reasonably clear that the same CA Signing private key must be used to sign the Responder certificate as the certificate in question.  This offers the crypto binding and provides all three: high degree of security, reduced software complexity for the OCSP client, and reduced computational complexity for the OCSP client.  Now, when do you get all three?

I do not buy the text in draft bis 2560.  That is taking liberty with the intent of 2560 and reducing security and/or adding complexity.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Rea
Sent: Tuesday, March 27, 2012 3:32 AM
To: [email-masked]
Subject: [pkix] 2560bis

If the issue with the responder cert is not clear in respect to CA rollover, and it really is expected to follow existing path processing from 5280, I am not sure that the proposed text presented just now accomplishes that...
why would we just not say that the responder cert should be issued by the same trust anchor that the subject cert of the OCSP request chains to. Hence if the EE cert now chains to a rolled over CA cert, then the responder cert should be issued by that same rolled over CA cert - yes?
Regards,

--
Scott Rea

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

---

From: Michael Myers <[email-masked]>
Date: Tue, 27 Mar 2012 06:54:00 -0700

On Mar 27, 2012, at 6:32 AM, Santosh Chokhani wrote:

> In my reading 2560 is reasonably clear that the same CA Signing  
> private key must be used to sign the Responder certificate as the  
> certificate in question.

No, not "must".  N.B. section '2.2  Response':

-- a Trusted Responder whose public key is trusted by the requester

Mike

---

From: [email-masked]
Date: Tue, 27 Mar 2012 16:04:00 +0200

Santosh,

We are on the same track. This is one of the issues I presented this 
morning at the meeting. 
There are some other issues. 

Please, take a look at the slides: 
http://www.ietf.org/proceedings/83/slides/slides-83-pkix-4.pdf

Denis

De :    Santosh Chokhani <[email-masked]>
A :     Scott Rea <[email-masked]>, "[email-masked]" <[email-masked]>
Date :  27/03/2012 15:33
Objet : Re: [pkix] 2560bis
Envoyé par :    [email-masked]

In my reading 2560 is reasonably clear that the same CA Signing private 
key must be used to sign the Responder certificate as the certificate in 
question.  This offers the crypto binding and provides all three: high 
degree of security, reduced software complexity for the OCSP client, and 
reduced computational complexity for the OCSP client.  Now, when do you 
get all three?

I do not buy the text in draft bis 2560.  That is taking liberty with the 
intent of 2560 and reducing security and/or adding complexity.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Scott Rea
Sent: Tuesday, March 27, 2012 3:32 AM
To: [email-masked]
Subject: [pkix] 2560bis

If the issue with the responder cert is not clear in respect to CA 
rollover, and it really is expected to follow existing path processing 
from 5280, I am not sure that the proposed text presented just now 
accomplishes that...
why would we just not say that the responder cert should be issued by the 
same trust anchor that the subject cert of the OCSP request chains to. 
Hence if the EE cert now chains to a rolled over CA cert, then the 
responder cert should be issued by that same rolled over CA cert - yes?
Regards,

--
Scott Rea

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 27 Mar 2012 10:04:12 -0400

Mike,

My comment was in the context of one of the three models: Delegated/Designated.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2012 9:54 AM
To: Santosh Chokhani
Cc: Scott Rea; [email-masked]
Subject: Re: [pkix] 2560bis

Mike

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 27 Mar 2012 16:31:35 +0100

I'm in agreement with you Santosh.

I think we seen enough rough consensus on this list and in the meeting
today to change the current text in rfc2560bis to reflect what you say.

/Stefan

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 27 Mar 2012 17:15:14 +0200

Bonjour,

Reading your slides, I think I found an error on page 8, "Comparison with
CRLs".

On this slide, you wrote
  "*When there is no delegation, the key that signs the CRL
  is the same key that issued the certificate, whether that has
  already been a CA key rollover or not.*"

This is wrong. A CA can have 2 keys, one for certificate signature and one
for CRL signature.

2012/3/27 <[email-masked]>

-- 
Erwann.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 27 Mar 2012 12:50:36 -0400

Denis,

Thanks.

I am willing to be little more liberal say that Appendix E scenarios are valid and acceptable as long as 2560 bis requires in the normative part of the RFC the client to verify that key/certificate relationships as stipulated in the Appendix or the proposal I made in 2004 regarding matching the certificate certification path and revocation information certification path.

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 27, 2012 10:04 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: [pkix] 2560bis

Santosh,

We are on the same track. This is one of the issues I presented this morning at the meeting.
There are some other issues.

Please, take a look at the slides: http://www.ietf.org/proceedings/83/slides/slides-83-pkix-4.pdf

Denis

De :        Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
A :        Scott Rea <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date :        27/03/2012 15:33
Objet :        Re: [pkix] 2560bis
Envoyé par :        [email-masked]<mailto:[email-masked]>
________________________________

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Scott Rea
Sent: Tuesday, March 27, 2012 3:32 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [pkix] 2560bis

--
Scott Rea

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

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 28 Mar 2012 12:41:25 +0100

Based on the meeting yesterday and the discussions on the list I will make
an overhaul of the current draft.
Therefore I will allow the current draft to expire until the new draft is
ready.

/Stefan

From:  Santosh Chokhani <[email-masked]>
Date:  Tue, 27 Mar 2012 12:50:36 -0400
To:  "[email-masked]" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [pkix] 2560bis

> Denis,
>  
> Thanks.
>  
> I am willing to be little more liberal say that Appendix E scenarios are valid
> and acceptable as long as 2560 bis requires in the normative part of the RFC
> the client to verify that key/certificate relationships as stipulated in the
> Appendix or the proposal I made in 2004 regarding matching the certificate
> certification path and revocation information certification path.
>  
> <http://www.ietf.org/proceedings/83/slides/slides-83-pkix-4.pdf>
> 
> Denis 
> 
> 
> 
> 
> In my reading 2560 is reasonably clear that the same CA Signing private key
> must be used to sign the Responder certificate as the certificate in question.
> This offers the crypto binding and provides all three: high degree of
> security, reduced software complexity for the OCSP client, and reduced
> computational complexity for the OCSP client.  Now, when do you get all three?
> 
> From: [email-masked] [mailto:[email-masked]
> <mailto:[email-masked]> ] On Behalf Of Scott Rea
> If the issue with the responder cert is not clear in respect to CA rollover,
> and it really is expected to follow existing path processing from 5280, I am
> not sure that the proposed text presented just now accomplishes that...
> why would we just not say that the responder cert should be issued by the same
> trust anchor that the subject cert of the OCSP request chains to. Hence if the
> EE cert now chains to a rolled over CA cert, then the responder cert should be
> issued by that same rolled over CA cert - yes?
> Regards,
> 
> --
> Scott Rea
> 
> <https://www.ietf.org/mailman/listinfo/pkix>
> <https://www.ietf.org/mailman/listinfo/pkix>
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix