Subject: [pkix] RFC2560

From: [email-masked]
Date: Thu, 15 Apr 2010 16:22:56 +0200

Good afternoon,

I´d like to raise a question because reviewing recently the RFC2560 we can find some kind of inconsistencies or contradictions that I´d like you to verify.

So, it´s supposed that at least it´s needed to meet one of the 3 requisites (check the red text). However, Reading a litlle bit more, it´s also allowed to have a list of VAs and a specific configuration of which CAs is responsed by each VA (blue text). 

  "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
  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." 

In ítem 2.2 of the RFC, it´s said explicity that the OCSP response may be signed with a trusted certificate. 

  "All definitive response messages SHALL be digitally signed. The key 
   used to sign the response MUST belong to one of the following: 

   -- the CA who issued the certificate in question 
   -- a Trusted Responder whose public key is trusted by the requester 
   -- a CA Designated Responder (Authorized Responder) who holds a 
      specially marked certificate issued directly by the CA, indicating 
      that the responder may issue OCSP responses for that CA"

So, it seems there´s a contradiction unless this last blue text is not mandatory

This came across because, we are a CSP that have a bunch of CAs issuing certs with several different policies and we adopted a centralized VA for all the issuing CAs instead of implementing a VA for every CA that issue certs. I think this is possible but the wording of the RFC may not be so clear, at least, for the Mozilla people because they are requesting us to change indicating we´re not following the RFC2560 because we don´t follow the red text (the 3 options).

This is a typical solution for CAs that issue a lot of certificates due to having a lot of issuing CAs or different CAs with several policies. For example, in Spain, the Spanish electronic id works the same. The have issued more than 15 millions of qualified certificates and they have implemented this solution of a centralized VA.

What do you think? May I understood incorrectly the RFC wording? Do you think an update is needed?

Thanks in advance

Iñigo Barreira
Responsable del Área técnica
[email-masked] <mailto:[email-masked]> 

945067705

---

From: "Liaquat Khan" <[email-masked]>
Date: Thu, 15 Apr 2010 19:46:29 +0400

See my comment below.

Regards

LK

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 15 April 2010 18:23
To: [email-masked]
Subject: [pkix] RFC2560

Good afternoon,

I´d like to raise a question because reviewing recently the RFC2560 we can
find some kind of inconsistencies or contradictions that I´d like you to
verify.

So, it´s supposed that at least it´s needed to meet one of the 3 requisites
(check the red text). However, Reading a litlle bit more, it´s also allowed
to have a list of VAs and a specific configuration of which CAs is responsed
by each VA (blue text). 

In ítem 2.2 of the RFC, it´s said explicity that the OCSP response may be
signed with a trusted certificate. 

So, it seems there´s a contradiction unless this last blue text is not
mandatory

This came across because, we are a CSP that have a bunch of CAs issuing
certs with several different policies and we adopted a centralized VA for
all the issuing CAs instead of implementing a VA for every CA that issue
certs. I think this is possible but the wording of the RFC may not be so
clear, at least, for the Mozilla people because they are requesting us to
change indicating we´re not following the RFC2560 because we don´t follow
the red text (the 3 options).

[LK:] Is your centralized VA just using one certificate?  We recommend to
our clients that when operating a centralized VA approach that they use
individual certificates issued by each corresponding CA (with the EKU
extension set appropriately).  The private key can be the same for all these
certificates or different. 

This is a typical solution for CAs that issue a lot of certificates due to
having a lot of issuing CAs or different CAs with several policies. For
example, in Spain, the Spanish electronic id works the same. The have issued
more than 15 millions of qualified certificates and they have implemented
this solution of a centralized VA.

[LK:] yes many parties have chosen to follow this model from our experience.

What do you think? May I understood incorrectly the RFC wording? Do you
think an update is needed?

[LK:] No not really, as this falls into the local configuration option IMO. 

Thanks in advance

Iñigo Barreira
[email-masked]

945067705

firma-email-2010

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 15 Apr 2010 12:02:28 -0400

If you have centralized VA, in order to meet the RFC 2560 and many of RFC compliant clients, the centralized VA could be a trust anchor for the clients or alternatively, the centralized responder can be issued certificates by the same CA DN, public key as the certificate space it covers.  Note that the second choice implies that if a CA re-keys, a certificate must be issued using each CA key until all non-OCSP certificates issued by the CA using that key expire.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Liaquat Khan
	Sent: Thursday, April 15, 2010 11:46 AM
	To: [email-masked]; [email-masked]
	Subject: Re: [pkix] RFC2560

	See my comment below.

	Regards

	LK

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 15 April 2010 18:23
	To: [email-masked]
	Subject: [pkix] RFC2560

	Good afternoon,

	

	

	

	[LK:] Is your centralized VA just using one certificate?  We recommend to our clients that when operating a centralized VA approach that they use individual certificates issued by each corresponding CA (with the EKU extension set appropriately).  The private key can be the same for all these certificates or different. 

	Thanks in advance

	Iñigo Barreira

	945067705

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 15 Apr 2010 19:29:29 +0200

[email-masked] wrote:
> "Systems or applications that rely on OCSP responses [...]
>  [...] MAY provide a means of locally configuring one
> which each signing authority is trusted.

They MAY implement that but they don't HAVE to.

> [...] The key
> [...]
> [...]

No, it's more a glitch in your interpretation that reverses the trust 
logic that this text implies.

The text must be seen as meaning that :
- the server receives the request
- the server gets the list of responder that the requester trusts
(by whatever out of band mechanism he can, as this list is not part of 
the OCSP protocol)
- the server checks if he owns the private keys of one of this requesters
- *if* he does, *then* he can use the second option of the list.

Your interpretation currently is that the client *has* to be 
configurable to trust the public key of the server.
It's not the case. It's the server who has to use a private key that 
matches the client's trust. And nothing forbids the client to trust no 
key in this way, making option 2 unavailable for the server.

Making the client configurable for this is actually covered by the first 
part &4.2.2.2, and it's optional.

If you really, really need that option, you might propose code to do 
that to Mozilla.
But in fact, I think even having that option would not work in practice.

The reason why you have this need is that you have a lot of issuing CAs. 
That means also the local configuration would have to be updated very 
frequently.
Which would not happen with Firefox :
- First you'd have to wait for a a new version until any change is 
effective.
- But even when the new version, many users would still be using the 
older version, so it would still not be satisfying.

So really, the only case where the local configuration is appropriate is 
when you control the client environment fully.
It's not a proper choice for CA that will be used by the general public.

Even if the RFC does not write it explicitly, that the logic most any 
implementation already follows.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 16 Apr 2010 11:09:49 +0200

Iñigo,

I agree with other opinions expressed here that there is nothing wrong with
the wording of RFC 2560.

The single VA for may CAs, where the VA is represented by a single
certificate, is allowed but requires all clients to manually configure trust
in this VA for each and every CA they rely on. While this may work in a
closed environment, it is not very practical in an open environment.

/Stefan

On 10-04-15 4:22 PM, "[email-masked]" <[email-masked]> wrote:

> (check the red text). However, Reading a litlle bit more, it´s also allowed to
> have a list of VAs and a specific configuration of which CAs is responsed by
> each VA (blue text).
> 
> 
> This came across because, we are a CSP that have a bunch of CAs issuing certs
> with several different policies and we adopted a centralized VA for all the
> issuing CAs instead of implementing a VA for every CA that issue certs. I
> think this is possible but the wording of the RFC may not be so clear, at
> least, for the Mozilla people because they are requesting us to change
> indicating we´re not following the RFC2560 because we don´t follow the red
> text (the 3 options).
>  
> more than 15 millions of qualified certificates and they have implemented this
> solution of a centralized VA.
>  
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Nelson B Bolyard <[email-masked]>
Date: Sat, 17 Apr 2010 01:05:47 -0700

> On 10-04-15 4:22 PM, Iñigo Barreira wrote:
>> I´d like to raise a question because reviewing recently the RFC2560 we
>> can find some kind of inconsistencies or contradictions that I´d like
>> you to verify. [snip]

On 2010/04/16 02:09 PDT, Stefan Santesson wrote:
> Iñigo,
> 
> I agree with other opinions expressed here that there is nothing wrong 
> with the wording of RFC 2560.

Stefan, and other participants in this thread,

I am one of the lead software developers for the PKI software used in
Mozilla products, and one of the people in the Mozilla community with whom
the good Mr. Iñigo Barreira has had an ongoing discussion about RFC 2560
for several years now, the discussion that led to this email thread.

One thing that Iñigo and I agree on very strongly:

   There is a serious need for clarification of the wording in RFC 2560.

Every year, Mozilla receives numerous requests for inclusion of root CA
certificates into its products.  Over the last 5+ years, Mozilla has found
it necessary to reject or indefinitely postpone at least one such request
per year, because NONE of the OCSP responses for the EE certificates issued
by the root CA's subordinate issuers bore a signature that could be
determined to have come from an "Authorized Responder" as defined in RFC
2560 section 4.2.2.2 (as Mozilla's developers have interpreted it), unless
the browser was individually configured to trust that OCSP response
signer's certificate as its OCSP signing authority.

In each and every case, the CA organization had already invested a large
amount in its OCSP infrastructure, and its designers believed that they
were compliant with RFC 2560.  They disagreed with Mozilla over the
interpretation of RFC 2560.

Mozilla's understanding of RFC 2560 section 4.2.2.2 is that the OCSP
response must have a signature that is verifiable by one of the following:
1) the same CA certificate with which the signature on the "certificate in
question" is verified, or
2) a certificate bearing the id-ad-ocspSigning EKU, which was issued by,
and whose signature is verifiable by, the same CA certificate with which
the signature on the "certificate in question" is verified, or
3) a certificate chosen by the relying party and configured in the relying
party's software as the relying party's OCSP signing authority.

Each of the contesting CAs has disagreed with Mozilla over that
interpretation in one of the following areas:

a) They understand "CA" or "issuer" to mean the CA organization, not a
particular CA private key and its corresponding certified public key.  So

a1) They ALL interpret section 2.6 as saying that the certificate's issuer
(organization) delegates OCSP signing authority by issuing (from some
issuing CA key under the control of that organization) a certificate
containing the special id-ad-ocspSigning EKU in the OCSP signer's
certificate. Where the RFC says "This certificate MUST be issued directly
to the responder by the cognizant CA" they understand "congnizant CA" to
mean "organization" or "legal entity", not "private key" or even "Issuer Name".

a2) Most believe the requirement in section 4.2.2.2 that "the certificate
required to validate the signature on the response ... 2. Is the
certificate of the CA that issued the certificate in question;" is
satisfied if the OCSP response signer's cert is the certificate of any
issuer directly in the certification path of the cert in question.

a3) Likewise, most believe that the alternative requirement that "the
certificate required to validate the signature on the response ... 3.
Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and
is issued by the CA that issued the certificate in question" is satisfied
if the OCSP response signer's cert with that EKU is issued by any issuer
directly in the certification path of the cert in question.

b) Alternatively, some CA's understand "local configuration" to be the
CA's configuration, not the relying party's configuration.

So, in all (or nearly all) cases, they have set up a single central OCSP
responder with a single response signing cert, typically issued directly
from the root issuer, and have carefully given that cert the special EKU
extension, and expect that the OCSP responses it signs will be fully
acceptable for OCSP inquiries regarding certs issued by other subordinate
Issuers whose CA certs were issued by that same root issuer.

I wish I could say that the text of RFC 2560 was so unambiguously clear
that there was no room for any other interpretation than mine, but in fact
it IS ambiguous, and the best I can say is that there are (at least) two
interpretations, neither of which seems entirely unreasonable.

> The single VA for [many] CAs, where the VA is represented by a single 
> certificate, is allowed but requires all clients to manually configure
> trust in this VA for each and every CA they rely on. While this may work
> in a closed environment, it is not very practical in an open
> environment.

You and I read RFC 2560 and come to that conclusion, but I believe
reasonable people can read it and come to other conclusions and many have
done just that, with very unfortunate and costly results.  A clearer
document would help us all.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Apr 2010 10:21:44 +0200

Nelson,

Thanks for the elaborate report on the issue. I believe everything you say
but I'm not convinced that the root of the problem in ambiguity in RFC 2560.

It sounds to me as if a number of implementers have poorly read and
understood RFC 2560 (alternatively have misunderstood the term CA) and then
tries twist the wordings to justify their implementation rather than fixing
the problem.

On the other hand I do believe that your interpretation of RFC 2560 is too
restrictive when you assume that a CA is restricted to the certificate that
validates the certificate in question. In the X.509 model a CA can renew its
certificate or even rekey and still function as the same CA. This is also
quite clear in RFC 4210. A CA can, however, NOT change it's name and claim
to be the same CA.

Since CA is defined by name, it is NOT equal to the CA organization. One
organization may run multiple CAs under different names, they will still be
different CAs.

Further, one can not claim that the "local configuration rules" are rules by
the issuer. The section where these rules are defined starts with:

   which each signing authority is trusted."

So these rules clearly applies to "Systems or applications that rely on OCSP
responses".

Additional comments in line;

> question" is verified, or

This is too restrictive. The CA may have renewed it's certificate since the
certificate in question was issued.

> the signature on the "certificate in question" is verified, or

Same as 1)

> party's software as the relying party's OCSP signing authority.

Correct

> particular CA private key and its corresponding certified public key.  So

They are clearly wrong. However a CA, keeping it's name, can renew its
certificate and/or rekey.

> mean "organization" or "legal entity", not "private key" or even "Issuer

They are clearly wrong for the same reason as above. CA is not the same as
CA organization.

> issuer directly in the certification path of the cert in question.

And this is clearly wrong of the same reason as above.

> directly in the certification path of the cert in question.

Also clearly wrong for the same reason as above.

> CA's configuration, not the relying party's configuration.

Absolutely not supported by RFC 2560.

> Issuers whose CA certs were issued by that same root issuer.

And this is a perfectly legal setup for _relying_parties_ that have locally
configured their OCSP responder as authorized for these CAs. Everybody else
who have not done this local configuration MUST reject their OCSP responses
(following RFC 2560).

I therefore fully understand that you (representing relying party software)
refuse to support OCSP responders who require local configuration of the RP
software to work.

> interpretations, neither of which seems entirely unreasonable.

I think we can agree that it is evidently a problem in the current case that
the meaning of the term "CA" is not clearly spelled out in RFC 2560. Once
that term is understood, I think the rest of the text is quite clear.

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 19 Apr 2010 09:36:12 -0400

-----Original Message-----
> From: Stefan Santesson

>From an implementer's perspective, it is safer to require the same
public key be used to verify both signatures (which renewal of the CA
certificate accomplishes, but which rekey does not.)

In a bridged or cross-certified environment it could be quite
tricky to ensure that two different certificates with
the same Issuer name are in fact operated by the same CA organization.
Absent cross-certificates, it is easier to ensure that they trace back
to the same TA, but there is no guarantee that implementations will make
that check.

Yes of course all CAs should properly populate name constraints and all
RPs should ensure that every TA is worthy of trust.  But ...

> that term is understood, I think the rest of the text is quite clear.

... given that Mozilla's interpretation of "CA" is obviously correct,
and
the other interpretation is a rationalization of existing practice
rather
than a legitimate misunderstanding or disagreement, some skepticism
regarding
CA reliability is healthy.

Implementing the "same public key" rule is trivial - OCSP responders can
easily select the proper signature key in cases where two CA keys are
simultaneously valid.  Or Issuer names could simply be retired instead
of rekeyed as DoD does.

Implementing the "same Issuer" rule in a manner that ensures OCSP
forgeries are impossible is complex.  I vote for the restrictive
Mozilla approach.

I also believe that in addition to clarifying the meaning of CA, giving
specific examples of prohibited behavior would be helpful to avoid
"misunderstandings".

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 19 Apr 2010 09:50:19 -0400

Stefan,

Unless I am misreading or misunderstanding you, I have to disagree with one item.

Most client implementations require that a CA use the same key to sign an OCSP Responder certificate that it used to sign a certificate whose status is being queried.  This approach reduces software and computation complexity and provides greatest security.  It is not often we get that.

Thus, I would rather stick to that interpretation as opposed to CA is defined by name.

I would rather clarify 2560 in this area and other areas, such as client side processing.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stefan Santesson
> Sent: Monday, April 19, 2010 4:22 AM
> To: Nelson B Bolyard; [email-masked]
> Thanks for the elaborate report on the issue. I believe 
> everything you say but I'm not convinced that the root of the 
> problem in ambiguity in RFC 2560.
> 
> It sounds to me as if a number of implementers have poorly 
> read and understood RFC 2560 (alternatively have 
> misunderstood the term CA) and then tries twist the wordings 
> to justify their implementation rather than fixing the problem.
> 
> On the other hand I do believe that your interpretation of 
> RFC 2560 is too restrictive when you assume that a CA is 
> restricted to the certificate that validates the certificate 
> in question. In the X.509 model a CA can renew its 
> certificate or even rekey and still function as the same CA. 
> This is also quite clear in RFC 4210. A CA can, however, NOT 
> change it's name and claim to be the same CA.
> 
> Since CA is defined by name, it is NOT equal to the CA 
> organization. One organization may run multiple CAs under 
> different names, they will still be different CAs.
> 
> Further, one can not claim that the "local configuration 
> rules" are rules by the issuer. The section where these rules 
> are defined starts with:
> 
> So these rules clearly applies to "Systems or applications 
> that rely on OCSP responses".
> 
> >>> I´d like to raise a question because reviewing recently 
> the RFC2560 
> >>> we can find some kind of inconsistencies or 
> contradictions that I´d 
> >>> like you to verify. [snip]
> > 
> >> I agree with other opinions expressed here that there is nothing 
> >> wrong with the wording of RFC 2560.
> > 
> > Mozilla products, and one of the people in the Mozilla 
> community with 
> > whom the good Mr. Iñigo Barreira has had an ongoing 
> discussion about 
> > RFC 2560 for several years now, the discussion that led to 
> this email thread.
> > 
> > Every year, Mozilla receives numerous requests for 
> inclusion of root 
> > CA certificates into its products.  Over the last 5+ years, Mozilla 
> > has found it necessary to reject or indefinitely postpone 
> at least one 
> > such request per year, because NONE of the OCSP responses 
> for the EE 
> > certificates issued by the root CA's subordinate issuers bore a 
> > signature that could be determined to have come from an "Authorized 
> > Responder" as defined in RFC 2560 section 4.2.2.2 (as Mozilla's 
> > developers have interpreted it), unless the browser was 
> individually 
> > configured to trust that OCSP response signer's certificate 
> as its OCSP signing authority.
> > 
> > In each and every case, the CA organization had already invested a 
> > large amount in its OCSP infrastructure, and its designers believed 
> > that they were compliant with RFC 2560.  They disagreed 
> with Mozilla 
> > over the interpretation of RFC 2560.
> > 
> > 1) the same CA certificate with which the signature on the 
> > "certificate in question" is verified, or
> 
> This is too restrictive. The CA may have renewed it's 
> certificate since the certificate in question was issued.
> 
> > 2) a certificate bearing the id-ad-ocspSigning EKU, which 
> was issued 
> > by, and whose signature is verifiable by, the same CA 
> certificate with 
> > which the signature on the "certificate in question" is verified, or
> 
> Same as 1)
> 
> > 3) a certificate chosen by the relying party and configured in the 
> > relying party's software as the relying party's OCSP 
> signing authority.
> > 
> 
> Correct
> 
> > particular CA private key and its corresponding certified 
> public key.  
> > So
> > 
> 
> They are clearly wrong. However a CA, keeping it's name, can 
> renew its certificate and/or rekey.
> 
> > certificate. Where the RFC says "This certificate MUST be issued 
> > directly to the responder by the cognizant CA" they understand 
> > "congnizant CA" to mean "organization" or "legal entity", 
> not "private 
> > key" or even "Issuer Name".
> > 
> 
> They are clearly wrong for the same reason as above. CA is 
> not the same as CA organization.
> 
> > a2) Most believe the requirement in section 4.2.2.2 that "the 
> > certificate required to validate the signature on the 
> response ... 2. 
> > Is the certificate of the CA that issued the certificate in 
> question;" 
> > is satisfied if the OCSP response signer's cert is the 
> certificate of 
> > any issuer directly in the certification path of the cert 
> in question.
> > 
> 
> > Includes a value of id-ad-ocspSigning in an 
> ExtendedKeyUsage extension 
> > and is issued by the CA that issued the certificate in question" is 
> > satisfied if the OCSP response signer's cert with that EKU 
> is issued 
> > by any issuer directly in the certification path of the 
> cert in question.
> > 
> 
> > So, in all (or nearly all) cases, they have set up a single central 
> > OCSP responder with a single response signing cert, 
> typically issued 
> > directly from the root issuer, and have carefully given 
> that cert the 
> > special EKU extension, and expect that the OCSP responses it signs 
> > will be fully acceptable for OCSP inquiries regarding certs 
> issued by 
> > other subordinate Issuers whose CA certs were issued by 
> that same root issuer.
> > 
> 
> And this is a perfectly legal setup for _relying_parties_ 
> that have locally configured their OCSP responder as 
> authorized for these CAs. Everybody else who have not done 
> this local configuration MUST reject their OCSP responses 
> (following RFC 2560).
> 
> I therefore fully understand that you (representing relying 
> party software) refuse to support OCSP responders who require 
> local configuration of the RP software to work.
> 
> 
> > I wish I could say that the text of RFC 2560 was so unambiguously 
> > clear that there was no room for any other interpretation 
> than mine, 
> > but in fact it IS ambiguous, and the best I can say is that 
> there are 
> > (at least) two interpretations, neither of which seems 
> entirely unreasonable.
> > 
> 
> I think we can agree that it is evidently a problem in the 
> current case that the meaning of the term "CA" is not clearly 
> spelled out in RFC 2560. Once that term is understood, I 
> think the rest of the text is quite clear.
> 
> 
> >> certificate, is allowed but requires all clients to manually 
> >> configure trust in this VA for each and every CA they rely 
> on. While 
> >> this may work in a closed environment, it is not very 
> practical in an 
> >> open environment.
> > 
> > reasonable people can read it and come to other conclusions 
> and many 
> > have done just that, with very unfortunate and costly results.  A 
> > clearer document would help us all.
> >

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 19 Apr 2010 09:59:06 -0400

Amen 

> Behalf Of Kemp, David P.
> Sent: Monday, April 19, 2010 9:36 AM
> To: [email-masked]
> From an implementer's perspective, it is safer to require the 
> same public key be used to verify both signatures (which 
> renewal of the CA certificate accomplishes, but which rekey does not.)
> 
> tricky to ensure that two different certificates with the 
> same Issuer name are in fact operated by the same CA organization.
> Absent cross-certificates, it is easier to ensure that they 
> trace back to the same TA, but there is no guarantee that 
> implementations will make that check.
> 
> Yes of course all CAs should properly populate name 
> constraints and all RPs should ensure that every TA is worthy 
> of trust.  But ...
> 
> > [...]
> >
> ... given that Mozilla's interpretation of "CA" is obviously 
> correct, and the other interpretation is a rationalization of 
> existing practice rather than a legitimate misunderstanding 
> or disagreement, some skepticism regarding CA reliability is healthy.
> 
> Implementing the "same public key" rule is trivial - OCSP 
> responders can easily select the proper signature key in 
> cases where two CA keys are simultaneously valid.  Or Issuer 
> names could simply be retired instead of rekeyed as DoD does.
> 
> Implementing the "same Issuer" rule in a manner that ensures 
> OCSP forgeries are impossible is complex.  I vote for the 
> restrictive Mozilla approach.
> 
> I also believe that in addition to clarifying the meaning of 
> CA, giving specific examples of prohibited behavior would be 
> helpful to avoid "misunderstandings".
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Apr 2010 16:09:52 +0200

David,

Comments in-line

> certificate accomplishes, but which rekey does not.)

Agree, and that is what many implementations of PKI in fact does. This is
why we often have a practice where every CA certificate in the hierarchy
have double life time compared with certificates it issues. That avoids both
rekeying and CA cert renewal.

> to the same TA, but there is no guarantee that implementations will make

Personally I think it is OK for most applications if the CA names matches,
Includes at least country, orgnaization and commonName attributes and
validates through a trusted root that is trusted for applicable usage
purposes.

But in theory it is safer to require the same key. This is simply a
non-perfect aspect of PKI.

> RPs should ensure that every TA is worthy of trust.  But ...

I don't think that is necessary.

> simultaneously valid.  Or Issuer names could simply be retired instead

I believe that it is perfectly reasonable to implement a policy that
implements "same public key" to determine "same CA". It will however exclude
legitimate CA's implementing rekeying, but I seriously doubt that there are
anyone out there that matters in this case.

> forgeries are impossible is complex.  I vote for the restrictive

I don't think it is impossible, but definitely more complex.

I don't think it is up to PKIX to decide what Mozilla as RP software should
require. I can't see anything wrong with them sticking to a "same key"
approach.

> specific examples of prohibited behavior would be helpful to avoid

The problem/question is in what form such guidance should be given. I'm
still to be convinced that this motivates writing an update RFC.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Apr 2010 16:16:52 +0200

Santosh,

We can't change the fact that X.509 identifies CA by name (allows it to be
rekeyed during its lifetime and remain the same CA).

I do however think that anyone trying to rekey a CA in practice will face
large interop problems with various applications and as such, I would
discourage anyone from doing CA rekeying unless they have a very strict
control over their applications using the PKI.

I think RFC 2560 does the right thing to be agnostic on this matter even if
I totally agree with you what the best practice is.

/Stefan

On 10-04-19 3:50 PM, "Santosh Chokhani" <[email-masked]> wrote:

> Most client implementations require that a CA use the same key to sign an OCSP
> Responder certificate that it used to sign a certificate whose status is being
> queried.  This approach reduces software and computation complexity and
> provides greatest security.  It is not often we get that.
> 
>> response ... 3.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 19 Apr 2010 10:25:03 -0400

Stefan,

I do not think rekey causes harm to the approach.  A CA could rekey and still issue CRL and OCSP Responder certificates using all active keys.

Also, note that most commonly used OCSP client already require the same key.

> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Monday, April 19, 2010 10:17 AM
> To: Santosh Chokhani; Nelson B Bolyard; [email-masked]
> We can't change the fact that X.509 identifies CA by name 
> (allows it to be rekeyed during its lifetime and remain the same CA).
> 
> I do however think that anyone trying to rekey a CA in 
> practice will face large interop problems with various 
> applications and as such, I would discourage anyone from 
> doing CA rekeying unless they have a very strict control over 
> their applications using the PKI.
> 
> I think RFC 2560 does the right thing to be agnostic on this 
> matter even if I totally agree with you what the best practice is.
> 
> /Stefan
> 
> 
> > Most client implementations require that a CA use the same 
> key to sign 
> > an OCSP Responder certificate that it used to sign a 
> certificate whose 
> > status is being queried.  This approach reduces software and 
> > computation complexity and provides greatest security.  It 
> is not often we get that.
> > 
> > Thus, I would rather stick to that interpretation as 
> opposed to CA is 
> > defined by name.
> > 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Stefan Santesson
> >> Thanks for the elaborate report on the issue. I believe everything 
> >> you say but I'm not convinced that the root of the problem in 
> >> ambiguity in RFC 2560.
> >> 
> read and 
> >> understood RFC 2560 (alternatively have misunderstood the term CA) 
> >> and then tries twist the wordings to justify their implementation 
> >> rather than fixing the problem.
> >> 
> RFC 2560 
> >> is too restrictive when you assume that a CA is restricted to the 
> >> certificate that validates the certificate in question. In 
> the X.509 
> >> model a CA can renew its certificate or even rekey and 
> still function 
> >> as the same CA.
> >> This is also quite clear in RFC 4210. A CA can, however, 
> NOT change 
> >> it's name and claim to be the same CA.
> >> 
> organization. 
> >> One organization may run multiple CAs under different names, they 
> >> will still be different CAs.
> >> 
> rules" are 
> >> rules by the issuer. The section where these rules are 
> defined starts 
> >> with:
> >> 
> >>    described above. They MAY provide a means of locally 
> configuring 
> >> one
> >> This is too restrictive. The CA may have renewed it's certificate 
> >> since the certificate in question was issued.
> >> 
> >> They are clearly wrong. However a CA, keeping it's name, can renew 
> >> its certificate and/or rekey.
> >> 
> >>> a1) They ALL interpret section 2.6 as saying that the 
> certificate's 
> >>> issuer
> >> They are clearly wrong for the same reason as above. CA is not the 
> >> same as CA organization.
> >> 
> that have 
> >> locally configured their OCSP responder as authorized for 
> these CAs. 
> >> Everybody else who have not done this local configuration 
> MUST reject 
> >> their OCSP responses (following RFC 2560).
> >> 
> >> I therefore fully understand that you (representing relying party 
> >> software) refuse to support OCSP responders who require local 
> >> configuration of the RP software to work.
> >> 
> >> 
> >> I think we can agree that it is evidently a problem in the current 
> >> case that the meaning of the term "CA" is not clearly 
> spelled out in 
> >> RFC 2560. Once that term is understood, I think the rest 
> of the text 
> >> is quite clear.
> >> 
> >>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Apr 2010 16:48:39 +0200

Santosh,

I'm thinking of the case where the certificate being checked for revocation
is issued with an old CA key but the CA (and OCSP responder) since then has
rekeyed and signs the response for that certificate with a new CA key, or
alternatively, the OCSP responder certificate is issued using the new CA
key.

/Stefan

On 10-04-19 4:25 PM, "Santosh Chokhani" <[email-masked]> wrote:

> Stefan,
> 
> I do not think rekey causes harm to the approach.  A CA could rekey and still
> issue CRL and OCSP Responder certificates using all active keys.
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 19 Apr 2010 11:04:14 -0400

Stefan,

The CA can and should also use the old key to sign CRLs (to keep CAPI happy) and to sign OCSP Responder certificates (to keep OCSP clients happy)

> Sent: Monday, April 19, 2010 10:49 AM
> I'm thinking of the case where the certificate being checked 
> for revocation is issued with an old CA key but the CA (and 
> OCSP responder) since then has rekeyed and signs the response 
> for that certificate with a new CA key, or alternatively, the 
> OCSP responder certificate is issued using the new CA key.
> 
> /Stefan
> 
> 
> 
> > I do not think rekey causes harm to the approach.  A CA could rekey 
> > and still issue CRL and OCSP Responder certificates using 
> all active keys.
> > 
> (allows it 
> >> to be rekeyed during its lifetime and remain the same CA).
> >> 
> practice will 
> >> face large interop problems with various applications and 
> as such, I 
> >> would discourage anyone from doing CA rekeying unless they have a 
> >> very strict control over their applications using the PKI.
> >> 
> >> I think RFC 2560 does the right thing to be agnostic on 
> this matter 
> >> even if I totally agree with you what the best practice is.
> >> 
> >> /Stefan
> >> 
> >> 
> >>> Unless I am misreading or misunderstanding you, I have to 
> disagree 
> >>> with one item.
> >>> 
> everything 
> certificate

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 19 Apr 2010 19:30:38 +0200

Santosh Chokhani wrote:
> The CA can and should also use the old key to sign CRLs (to keep CAPI
> happy) and to sign OCSP Responder certificates (to keep OCSP clients
> happy)

Therefore, the thing to do when rekeying using the same DN is to update 
in certificates issued after the rekeying both the CRL and OCSP URLs to 
point to a new address which will use the new key.

And to keep the old URLs active with the old key.

This probably goes without saying for most people on this list, but 
let's be clear for anyone else looking for guidance.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 19 Apr 2010 14:06:16 -0400

I agree that when the new key with the same CA is used, CRL DP HTTP
pointer for new certificates could point to a CRL signed using the new
key and CA Issuers field in the AIA could have an HTTP pointer to the
new CA certificate.

Note that both CRLs should be full CRL unless IDP is asserted.

> Behalf Of Jean-Marc Desperrier
> Sent: Monday, April 19, 2010 1:31 PM
> To: [email-masked]
> Therefore, the thing to do when rekeying using the same DN is 
> to update in certificates issued after the rekeying both the 
> CRL and OCSP URLs to point to a new address which will use 
> the new key.
> 
> This probably goes without saying for most people on this 
> list, but let's be clear for anyone else looking for guidance.

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 19 Apr 2010 12:13:04 -0700

On 2010/04/19 01:21 PDT, Stefan Santesson wrote:

> understood RFC 2560 (alternatively have misunderstood the term CA) and
> then tries twist the wordings to justify their implementation rather
> than fixing the problem.

The number of CA (organizations) that have done this is large enough that
I am not inclined to lay the blame entirely at their feet. I think they
have made a good faith effort to understand and follow the RFC, and then
very late in the implementation have discovered that their interpretation
is not the one accepted by others.  They are naturally reluctant to change
their implementation because of the substantial (albeit necessary, IMO)
cost of so doing.

> In the X.509 model a CA can renew its certificate or even rekey and
> still function as the same CA. This is also quite clear in RFC 4210. A
> CA can, however, NOT change it's name and claim to be the same CA.
> 
> Since CA is defined by name, it is NOT equal to the CA organization.
> One organization may run multiple CAs under different names, they will
> still be different CAs.

>> a) They understand "CA" or "issuer" to mean the CA organization, not
>> a particular CA private key and its corresponding certified public
>> key.  So

> They are clearly wrong.

Well, RFC 2560 does not define these terms, and in general use, the term
CA sometimes means a specific named issuer, but also very commonly means
a corporation in the business of operating such issuers.  We all commonly
refer to businesses such as Verisign, Comodo, Entrust, GeoTrust, etc., as
"CAs", even though those businesses may not meet the precise definition
of CA as in the sense of a specific Issuer Name.

In practice, whether the term "CA" means "business" or "Issuer DN" is
context dependent, and in some contexts, it can be ambiguous.  I submit
that many have found RFC 2560 to be one of those contexts.  Enough have
done so that they have my sympathy.  I do not think we can dismiss them
all as having carelessly read the RFCs.

>> Where the RFC says "This certificate MUST be issued directly to the
>> responder by the cognizant CA" they understand "congnizant CA" to mean
>> "organization" or "legal entity", not "private key" or even "Issuer 
>> Name".
> 
> They are clearly wrong for the same reason as above. CA is not the same
> as CA organization.

Think about things that are "cognizant", that have "cognizance".  Which is
more likely to have cognizance?  An "Issuer DN"?  or a corporate
organization?  This is a case where the wording of the RFC leans towards
the organizational interpretation, IMO.

> I think we can agree that it is evidently a problem in the current case
> that the meaning of the term "CA" is not clearly spelled out in RFC
> 2560. Once that term is understood, I think the rest of the text is
> quite clear.

Yes.  We agree on this.  Now, how can we clarify this?  I need an
authoritative document to which I can point CAs (organizations, applicants)
to clarify this and end the debates.  Better yet would be if new CAs didn't
make this mistake in the first place because the document upon which they
had relied was utterly unambiguous about which meaning of CA it was using.

Regards,
/Nelson Bolyard

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Apr 2010 21:59:22 +0200

Nelson,

I see your problem, but I'm not entirely sure what we should do about it.

I'm open for suggestions.

/Stefan

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Apr 2010 13:07:15 -0700

>the organizational interpretation, IMO.

Fully agree with Nelson.

>had relied was utterly unambiguous about which meaning of CA it was using.

Someone, hopefully you, can write an update to RFC 2560 that clarifies this, plus clarifies the other issues that have come up in the past decade.

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 19 Apr 2010 17:10:25 -0400

> Someone, hopefully you, can write an update to RFC 2560 that clarifies this, plus clarifies the other issues that have come up in the past decade.

If an update to RFC 2560 is created, there is a related issue that I 
would like to see addressed.  (I don't know whether it would be 
considered a change or a clarification.)

I believe that there should be a requirement that a certificate MUST NOT 
include an AIA extension with an id-ad-ocsp access method unless the 
certificate required to validate the signatures on responses provided by 
the referenced responder satisfies criteria (2) or (3) from Section 
4.2.2.2.  It would be helpful if there was a clear statement that a 
certificate SHOULD (or MUST) include an id-ad-ocsp access method if the 
issuing CA supports an OCSP service for which the certificate required 
to validate the signatures on responses provided by the responder 
satisfies criteria (2) or (3) from Section 4.2.2.2 and that a 
certificate MUST NOT include an id-ad-ocsp access method that refers to 
an OCSP responder whose responses can only be verified based on local 
configuration.

I have come across a number of cases in which OCSP responses can only be 
verified based on local configuration (e.g., the scenarios that Nelson 
Bolyard has described) yet the certificates include AIA extensions with 
the id-ad-ocsp access method.  The result is that most clients that 
follow the URL in the id-ad-ocsp access method and obtain a signed OCSP 
response can't verify the signature on the response.

Dave
---------------------------------------------------------------------------
3.1  Certificate Content

   In order to convey to OCSP clients a well-known point of information
   access, CAs SHALL provide the capability to include the
   AuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1)
   in certificates that can be checked using OCSP.  Alternatively, the
   accessLocation for the OCSP provider may be configured locally at the
   OCSP client.

   CAs that support an OCSP service, either hosted locally or provided
   by an Authorized Responder, MUST provide for the inclusion of a value
   for a uniformResourceIndicator (URI) accessLocation and the OID value
   id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
---------------------------------------------------------------------------
4.2.2.2  Authorized Responders

   Systems or applications that rely on OCSP responses MUST be capable

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 19 Apr 2010 19:46:22 -0400

I agree 

> Behalf Of David A. Cooper
> Sent: Monday, April 19, 2010 5:10 PM
> To: [email-masked]
> > Someone, hopefully you, can write an update to RFC 2560 
> that clarifies this, plus clarifies the other issues that 
> have come up in the past decade.
> 
> If an update to RFC 2560 is created, there is a related issue 
> that I would like to see addressed.  (I don't know whether it 
> would be considered a change or a clarification.)
> 
> I believe that there should be a requirement that a 
> certificate MUST NOT include an AIA extension with an 
> id-ad-ocsp access method unless the certificate required to 
> validate the signatures on responses provided by the 
> referenced responder satisfies criteria (2) or (3) from 
> Section 4.2.2.2.  It would be helpful if there was a clear 
> statement that a certificate SHOULD (or MUST) include an 
> id-ad-ocsp access method if the issuing CA supports an OCSP 
> service for which the certificate required to validate the 
> signatures on responses provided by the responder satisfies 
> criteria (2) or (3) from Section 4.2.2.2 and that a 
> certificate MUST NOT include an id-ad-ocsp access method that 
> refers to an OCSP responder whose responses can only be 
> verified based on local configuration.
> 
> I have come across a number of cases in which OCSP responses 
> can only be verified based on local configuration (e.g., the 
> scenarios that Nelson Bolyard has described) yet the 
> certificates include AIA extensions with the id-ad-ocsp 
> access method.  The result is that most clients that follow 
> the URL in the id-ad-ocsp access method and obtain a signed 
> OCSP response can't verify the signature on the response.
> 
> Dave
> configuring one

---

From: "Peter Rybar" <[email-masked]>
Date: Tue, 20 Apr 2010 09:53:49 +0200

I agree with Nelson, to use of the same key to sign an OCSP Responder certificate that it used to sign a certificate whose status is being queried is preferred practice and also that instead of rekey CA certificate the use of new DN is better solution. That is what we have done in national profiles:
http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/formats/formats_crl_ocsp_en.pdf  
http://www.nbusr.sk/en/electronic-signature/approved-formats/index.html 

I would like to ask you for your opinions if an update to RFC 2560 is created, is it possible to also add an extension defined for the type SingleResponse in singleExtensions which can be used in long term validation for protection of integrity of expired certificates whose status the OCSP response provides and which is also used as positive statement that OCSP knows the certificate and its status?

Presently CertHash (positive statement) is defined in Common PKI:

id-commonpki OBJECT IDENTIFIER ::= {1 3 36 8 }
id-commonpki-at OBJECT IDENTIFIER ::= {id-commonpki 3}
id-commonpki-at-certHash OBJECT IDENTIFIER ::= {id-commonpki-at 13}

CertHash ::= SEQUENCE {
   hashAlgorithm AlgorithmIdentifier,
     -- The identifier of the algorithm that has been used the
     -- hash value below.
   certificateHash OCTET STRING
     -- The hash over DER-encoding of the entire PKC
} -- or AC (i.e. NOT a hash over tbsCertificate)..

Common PKI specification: "COMMON PKI SPECIFICATIONS FOR INTEROPERABLE APPLICATIONS FROM T7 & TELETRUST - SPECIFICATION PART 4:OPERATIONAL PROTOCOLS, http://www.common-pki.org/uploads/media/Common-PKI_v2.0.pdf "

Peter Rybar
National Security Authority
Department of Information Security and Electronic Signature 
Budatinska 30, 
850 07 Bratislava 57, 
Slovak Republic
tel.: +421 2 6869 2163
mob.: +421 902 891 155
fax:  +421 2 6869 1701
e-mail: [email-masked]
e-mail: [email-masked]

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 20 Apr 2010 08:30:15 -0400

> I agree with Nelson, to use of the same key to sign an OCSP Responder
> certificate that it used to sign a certificate whose status is being
> queried is preferred practice and also that instead of rekey CA
> certificate the use of new DN is better solution. 

Rekeying using the same DN while continuing to use the old key to resign
OCSP responder certificates seems like a new behavior for CAs.  Usually
certificates are signed using the new key following a rekey.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 22 Apr 2010 08:42:34 +0200

I would like to keep the momentum on the OCSP discussion by asking for a
show of hands on different possibilities.

My recollection of this discussion is that we have recorded practical
problems with different interpretation of "CA" in implementations of OCSP.
At the same time we have a list of other things that people would like to
see fixed with OCSP.

On the issue of defining "CA", this aspect is not entirely limited to OCSP.
(the same discussion is valid for e.g. Indirect CRLs). One could argue that
a clarification of the term "CA" should be done in a way that is generic for
all PKIX protocols and not just for OCSP. On the other hand one could also
argue that the only thing needed in this case is to clarify the rules with
respect to OCSP.

The options are:

1) Revise OCSP (Create a new OCSP RFC that obsoletes RFC 2560)
2) Update OCSP (Create an RFC that updates RFC 2560)
3) Do nothing
4) Do something else

Please indicate which of the options you would prefer with a short
motivation.

---

From: [email-masked]
Date: Thu, 22 Apr 2010 09:03:56 +0200

I´d vote for option 2, although 1 is also good.

Iñigo Barreira

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Stefan Santesson
Enviado el: jueves, 22 de abril de 2010 8:43
Para: [email-masked]
Asunto: [pkix] Show of hands - updating or revising OCSP

The options are:

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 22 Apr 2010 17:09:38 +1000

2) Update OCSP

I am less concerned with the CA orgs that used a differently named CAs or CAs further up the chain to certify responders. If more explicit text helps that is nice.

I am more concerned about CA key rollover. Various people have said "best practise" is to use a new CA name on rollover. However, it sounds like this is not just "best practise", but a "mandatory practise" if lots of software (such as NSS used by Firefox) will fail otherwise. 

Changing a CA's name has other implications. Systems that use a chain of names from an EE cert to the top of a chain as the id for an entity will break if CA names have to change. This approach (using a chain of names) has been encouraged by various people (eg Denis Pinkas?). I am not sure if it is implied or implemented in many standards or systems.

I would like an update to explicitly state how CAs that change keys (but keep the same name) must be handled, particularly with respect to verifying OCSP responses.

-- 
James Manger

---

From: Dino Esposito <[email-masked]>
Date: Thu, 22 Apr 2010 12:00:04 +0200

Option 2.
Option 1 is good as well

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 22 Apr 2010 10:33:50 -0400

I agree with this and further this model needs to be supported in any changes made to RFC 2560 as it is also an existing deployed model.

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 22 Apr 2010 10:35:59 -0400

I prefer to attempt option 2. My fear is that if we go with option 1 it may become too tempting to revisit all previous lengthy debates on all the old issues which were finally resolved with the publication of RFC 2560. If we proceed with option 2 and then at some point determine that the changes are too extensive and complicated to write up as a separate update RFC can we not then revisit the options and decide to merge both into a single RFC?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Thursday, April 22, 2010 2:43 AM
To: [email-masked]
Subject: [pkix] Show of hands - updating or revising OCSP

The options are:

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 22 Apr 2010 10:50:18 -0400

I don't believe CA rekey should be prohibited at all. Link certificates should be mandated in the case of CA rekey but that option should not be prohibited in the RFC. Particular deployments can choose to implement that way if they desire but link certificates are there specifically to enable CA rekey environments and this model is just as valid in an OCSP environment as it is in any other.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Monday, April 19, 2010 9:36 AM
To: [email-masked]
Subject: Re: [pkix] RFC2560

-----Original Message-----
>> 1) the same CA certificate with which the signature on the
"certificate in
> This is too restrictive. The CA may have renewed it's certificate
since the

> I think we can agree that it is evidently a problem in the current
case that

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 22 Apr 2010 11:13:24 -0400

I vote for Option 1, but agree that the scope of the effort should be 
limited to:

(1) improving the readability of the document and removing ambiguities.

(2) incorporating previous updates (e.g., draft-ietf-pkix-ocspagility)

Dave

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Thu, 22 Apr 2010 18:18:17 +0300

Hi,

Option 2 (or at least option 1) is the preferred one.

Thanks,
M.D.
cell: +370-699-26662

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 22 Apr 2010 12:20:07 -0400

If 2560 is updated, should 5019 be updated as well?

-- Tim

>Sharon Boeyen
>Sent: Thursday, April 22, 2010 9:36 AM
>To: Stefan Santesson; [email-masked]
>Subject: Re: [pkix] Show of hands - updating or revising OCSP
>
>I prefer to attempt option 2. My fear is that if we go with option 1 it
>may become too tempting to revisit all previous lengthy debates on all
>the old issues which were finally resolved with the publication of RFC
>2560. If we proceed with option 2 and then at some point determine that
>the changes are too extensive and complicated to write up as a separate
>update RFC can we not then revisit the options and decide to merge both
>into a single RFC?
>
>Stefan Santesson

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Apr 2010 13:43:37 -0400

I prefer option 2.

-----Original Message-----

The options are:

---

From: Sean Leonard <[email-masked]>
Date: Thu, 22 Apr 2010 13:16:13 -0700

I would also prefer option 2, for reasons already articulated (particularly what Sharon Boeyen said--don't want to revisit previous lengthy debates).

SL

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 22 Apr 2010 16:18:26 -0400

I vote for Option 1 and agree with Dave's limits, especially item (1).

> David A. Cooper
> Sent: Thursday, April 22, 2010 11:13 AM
> To: Stefan Santesson
> Cc: [email-masked]
> > On the issue of defining "CA", this aspect is not entirely limited
to
> OCSP.
> > all PKIX protocols and not just for OCSP. On the other hand one
could
> also
> > argue that the only thing needed in this case is to clarify the
rules
> with

---

From: Melinda Shore <[email-masked]>
Date: Thu, 22 Apr 2010 13:28:05 -0800

On Apr 22, 2010, at 12:16 PM, Sean Leonard wrote:
> I would also prefer option 2, for reasons already articulated  
> (particularly what Sharon Boeyen said--don't want to revisit  
> previous lengthy debates).

I do, too, but I'm not that optimistic about avoiding
revisiting old debates that we don't intend, right now,
to revisit.  It seems to me that anything is up for
discussion if there's a compelling technical reason, in
either case, but that it would make sense to set a pretty
high bar from the outset to put old stuff up for another
decision.

Melinda

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 23 Apr 2010 14:58:09 +0200

I favour a revision (option 1).

Clarifications are needed about what means in section 3.2:

"The signer is currently authorized to sign the response".

In fact there are different ways to do this whether:

 - an OCSP responder provides status information for one or more CAs,
 -  a certificate's issuer either signs the OCSP responses itself or 
   explicitly designates this authority to another entity.

Section 4.2.2. is not sufficient.

The various models should be introduced upfront and the details for OCSP response checking 
should be per model.
 
Hence why a restructuring (i.e. revision) is needed rather than an update.

Denis

---

From: Geoff Beier <[email-masked]>
Date: Fri, 23 Apr 2010 11:28:37 -0400

I prefer option 1 with Dave's proposed restrictions on the scope of the effort.

---

From: "Doreswamy, Rangan" <[email-masked]>
Date: Fri, 23 Apr 2010 14:25:25 -0700

I would vote for Option 2, and will be willing to actively participate
in the draft process.

Thanks,
Rangan Doreswamy
Principal - Standards. 
VeriSign, Inc.
http://www.verisign.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Wednesday, April 21, 2010 11:43 PM
To: [email-masked]
Subject: [pkix] Show of hands - updating or revising OCSP

My recollection of this discussion is that we have recorded practical
problems with different interpretation of "CA" in implementations of
OCSP.
At the same time we have a list of other things that people would like
to
see fixed with OCSP.

On the issue of defining "CA", this aspect is not entirely limited to
OCSP.
(the same discussion is valid for e.g. Indirect CRLs). One could argue
that
a clarification of the term "CA" should be done in a way that is generic
for
all PKIX protocols and not just for OCSP. On the other hand one could
also
argue that the only thing needed in this case is to clarify the rules
with
respect to OCSP.

The options are:

---

From: Michael Myers <[email-masked]>
Date: Fri, 23 Apr 2010 15:57:05 -0700

I prefer option 2, especially as it relates to Section 4.2.2.2.

Mike

On Apr 21, 2010, at 11:42 PM, Stefan Santesson wrote:

> to OCSP.
> could also
> rules with