Subject: Re: [pkix] RFC2560bis update

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Jul 2012 08:51:58 -0500

Sorry, this mail got stuck in my out box. Resending it way late.

Mike,

Thanks for the input.

I agree that the text is not ideal and could use some wordsmithing.
I just wanted to see if a sentence like this (in some edited form) could do
the job with respect to the expressed lack of clarity of RFC 2560, whether
CA rekeying is part of MUST support for relying parties.

The opinion in the room at last PKIX suggested that it is not.

Pleas feel free to suggest alternative wordings.

/Stefan

From:  Michael Myers <[email-masked]>
Date:  Friday, 20 July, 2012 8:11 PM
To:  Stefan Santesson <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [pkix] RFC2560bis update

> Stefan,
> 
> A good bit of work.  Some preliminary comments below, marked with [MM].  More
> MAY follow.  I'd be happy to provide some alternative text to sharpen things
> up, if that would be useful.  I hope all this goofy formatting comes across.
> 
> Mike
> 
> 4.2.2.2  Authorized Responders
> 
>    TBD --------- UPDATE THIS SECTIOIN -------------
> 
>    The key that signs a certificate's status information need not be the
>    same key that signed the certificate. It is necessary however to
>    ensure that the entity signing this information is authorized to do
>    so.  Therefore, a certificate's issuer MUST either sign the OCSP
>    responses itself or it MUST explicitly designate this authority to
>    another entity.
> 
> [MM] You are forgetting about local configuration.  See point (1) below.
> 
>    OCSP signing delegation SHALL be designated by the
>    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
>    extension included in the OCSP response signer's certificate.  This
>    certificate MUST be issued directly by the CA that issued the
>    certificate in question.
> 
>    The CA SHOULD use the same issuing key to issue a delegation
>    certificate as was used to sign the certificate being checked for
>    revocation.
> 
> [MM]  The following bit in italics could use some wordsmithing.
> 
>    Systems relying on OCSP responses MUST recognize a
>    delegation certificate as being issued by the CA that issued the
>    certificate in question if the delegation certificate and the
>    certificate being checked for revocation was signed by the same key.
> 
> [MM]  What does it mean to "recognize"?  Perhaps "accept as valid"?
>       Also, "issued by" is ambiguous.  Follow the keys.
>       For example, above.  "The key that signs . . . "
>    Systems relying on OCSP responses MAY recognize a delegation
>    certificate as being issued by the CA that issued the certificate in
>    question if the delegation certificate and the certificate being
>    checked for revocation was issued by the same CA using different
>    issuing keys.
>    id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
> 
>    Systems or applications that rely on OCSP responses MUST be capable
>    of detecting and enforcing use of the id-ad-ocspSigning value as
>    described above. They MAY provide a means of locally configuring one
>  
> 
> 
> Stefan Santesson        Expires January 21, 2013               [Page 14]
> 
> INTERNET DRAFT                 PKIX OCSP                   July 20, 2012
> 
> 
>    or more OCSP signing authorities, and specifying the set of CAs for
>    which each signing authority is trusted. They MUST reject the
>    response if the certificate required to validate the signature on the
>    response fails to meet at least one of the following criteria:
> 
>    1. Matches a local configuration of OCSP signing authority for the
>    certificate in question; or
> 
>    2. Is the certificate of the CA that issued the certificate in
>    question; or
> 
>    3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
>    extension and is issued by the CA that issued the certificate in
>    question as stated above.
> 
>    Additional acceptance or rejection criteria may apply to either the
>    response itself or to the certificate used to validate the signature
>    on the response.
>

---

From: [email-masked]
Date: Fri, 27 Jul 2012 16:06:06 +0200

Stefan,

I am puzzled.

During the last IETF meeting in Paris, it was agreed that the current 
co-editors (and you are among them) 
would issue a new version of the 2560bis taking into consideration the 
comments made during  the meeting.

However, since then, I have not seen any new draft. What I have seen 
however is a list of errata which correct 
only a few points from RFC 2560.

So my questions:

  1) do you still plan to issue a new draft of 2560bis ? 
  2) If yes to the above question, can you commit to a time frame for this 
issue  ?
  3) Are you looking for some help to commit to a date ?  If yes, as said 
during the Paris meeting I can offer my help as a co-editor.

Looking forward to your responses.

Denis

De :    Stefan Santesson <[email-masked]>
A :     Michael Myers <[email-masked]>
Cc :    [email-masked]
Date :  27/07/2012 15:52
Objet : Re: [pkix] RFC2560bis update
Envoyé par :    [email-masked]

Mike,

Thanks for the input.

I agree that the text is not ideal and could use some wordsmithing.
I just wanted to see if a sentence like this (in some edited form) could 
do the job with respect to the expressed lack of clarity of RFC 2560, 
whether CA rekeying is part of MUST support for relying parties.

/Stefan

Stefan,

A good bit of work.  Some preliminary comments below, marked with [MM]. 
More MAY follow.  I'd be happy to provide some alternative text to sharpen 
things up, if that would be useful.  I hope all this goofy formatting 
comes across.

Mike



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

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 27 Jul 2012 11:26:22 -0400

Stefan,

I don't think this is a matter of lack of clarity in RFC 2560.  I
think RFC 2560 is simply silent on what conforming relying parties
need to support.  I would also argue (contrary to your slides from
the previous IETF meeting) that 2560bis is silent on this issue as
well.  Following RFC 2560, draft -04 of 2560bis states the
requirements for an OCSP response to be valid (and 2560bis goes
further by adding a Note to point that using different keys to
sign the target certificate and the response (or OCSP responder
certificate) will cause interoperability problems since some
clients will not be able to accept such responses), but nowhere
does it state that conforming relying parties MUST be able to
accept responses that are signed with different keys.

I believe that requiring issuers to sign OCSP responses (or OCSP
responder certificates) with the same key as the target
certificate would be a same from RFC 2560, which only imposes a
requirement of "same CA," would be a change in the protocol, which
I was told I was not allowed to do when I was asked to develop
2560bis.  However, since RFC 2560 does not have any conformance
requirements in this area, it would not be a change from RFC 2560
(or the earlier drafts of 2560bis) to state that conforming
relying parties MUST be able to accept responses signed with the
same key but are not required to be able to accept responses
signed with different keys.  Similarly, while stating that issuers
SHOULD sign certificates and responses (or OCSP responder
certificates) with the same key is something that would be new
compared to RFC 2560, at least it doesn't forbid something that
was previously allowed by RFC 2560.

Dave

On 07/27/2012 09:51 AM, Stefan Santesson wrote:

Sorry, this mail got stuck in my out box. Resending it way
late.

Mike,

Thanks for the input.

I agree that the text is not ideal and could use some
wordsmithing.

I just wanted to see if a sentence like this (in some edited
form) could do the job with respect to the expressed lack of
clarity of RFC 2560, whether CA rekeying is part of MUST support
for relying parties.

The opinion in the room at last PKIX suggested that it is
not.

/Stefan

Date: Friday, 20 July,
2012 8:11 PM

To: Stefan Santesson
<[email-masked]>

Cc: <[email-masked]>

Subject: Re: [pkix]
RFC2560bis update

Stefan,

A good bit of work.  Some preliminary comments below,
marked with [MM].  More MAY follow.  I'd be happy to
provide some alternative text to sharpen things up, if
that would be useful.  I hope all this goofy formatting
comes across.

Mike