headers
Simon Josefsson | 2 Aug 2012 01:27
Favicon
Gravatar

OCSP 2560bis - responderID clarification

The semantics of the responderID field is something that may be useful
to clarify in an RFC 2560 document.  I brought this up earlier, but it
may have been forgotten in the flurry of other issues:

http://www.ietf.org/mail-archive/web/pkix/current/msg29802.html
http://www.ietf.org/mail-archive/web/pkix/current/msg29803.html

One good reason for not clarifying this would be if the intention is
fussy or people are implementing different approaches.  Does anyone know
if that is the case?

/Simon
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply |
headers
Stefan Santesson | 3 Aug 2012 00:27
Favicon

Re: OCSP 2560bis - responderID clarification

Simon,

I fully agree,
The spec ought to say something about the expected information if the Name
choice is chosen.

The ASN.1 structure is defined, but some wording about content would be
suitable.

I can't see however that anything but the subject name of the OCSP
responder (identical to the responder certificate) would go here.

/Stefan

On 12-08-01 4:27 PM, "Simon Josefsson" <simon <at> josefsson.org> wrote:

>The semantics of the responderID field is something that may be useful
>to clarify in an RFC 2560 document.  I brought this up earlier, but it
>may have been forgotten in the flurry of other issues:
>
>http://www.ietf.org/mail-archive/web/pkix/current/msg29802.html
>http://www.ietf.org/mail-archive/web/pkix/current/msg29803.html
>
>One good reason for not clarifying this would be if the intention is
>fussy or people are implementing different approaches.  Does anyone know
>if that is the case?
>
>/Simon
>_______________________________________________
>pkix mailing list
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 3 Aug 2012 10:45
Favicon
Gravatar

Re: OCSP 2560bis - responderID clarification

Stefan Santesson <stefan <at> aaa-sec.com> writes:

> Simon,
>
> I fully agree,
> The spec ought to say something about the expected information if the Name
> choice is chosen.
>
> The ASN.1 structure is defined, but some wording about content would be
> suitable.
>
> I can't see however that anything but the subject name of the OCSP
> responder (identical to the responder certificate) would go here.

Thanks.  How about adding something like this to section 4.2.2.3?

  The purpose of the ResponderID information is to allow clients to find
  the certificate used to sign a signed OCSP response.  Therefor, the
  information MUST correspond to the certificate that was used to sign
  the response.

It should probably go early in the section, just after the first
bullet-point list.

I am not confident that this is non-controverisal, as I'm not an OCSP
expert.  I would appreciate if more people considered whether this text
makes sense or not.  I am hoping that the paragraph is trivial to
everyone experienced with OCSP.

When I wrote the OCSP support for GnuTLS I found this area to be
(Continue reading)

Permalink | Reply |
headers
Stefan Santesson | 3 Aug 2012 20:32
Favicon

Re: OCSP 2560bis - responderID clarification

Thanks Simon.

I'll include your updates. They seem fine with me.

No I don't have an XML. I use the Awesome NroffEdit tool :)

/Stefan

On 12-08-03 1:45 AM, "Simon Josefsson" <simon <at> josefsson.org> wrote:

>Stefan Santesson <stefan <at> aaa-sec.com> writes:
>
>> Simon,
>>
>> I fully agree,
>> The spec ought to say something about the expected information if the
>>Name
>> choice is chosen.
>>
>> The ASN.1 structure is defined, but some wording about content would be
>> suitable.
>>
>> I can't see however that anything but the subject name of the OCSP
>> responder (identical to the responder certificate) would go here.
>
>Thanks.  How about adding something like this to section 4.2.2.3?
>
>  The purpose of the ResponderID information is to allow clients to find
>  the certificate used to sign a signed OCSP response.  Therefor, the
>  information MUST correspond to the certificate that was used to sign
(Continue reading)

Permalink | Reply |

Gmane