Subject: [pkix] ACs an OCSP

From: "Erik Andersen" <[email-masked]>
Date: Fri, 11 Apr 2014 13:58:08 +0200

Is it clear than OCSP can only be used for checking status of public-key
certificates and not for attribute certificates?

Erik

---

From: Denis <[email-masked]>
Date: Fri, 11 Apr 2014 14:09:14 +0200

Erik,

Please take a look at the relevant RFCs before raising such a question 
to this mailing list:

RFC 6960:

   This document specifies a protocol useful in determining the current 
status of a digital certificate without requiring CRLs.

RFC 2560:

    In lieu of or as a supplement to checking against a periodic CRL, it
    may be necessary to obtain timely information regarding the
    revocation status of a certificate (cf. [RFC2459], Section 3.3).

Denis

> Is it clear than OCSP can only be used for checking status of 
> public-key certificates and not for attribute certificates?
>
> Erik
>
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 11 Apr 2014 14:26:29 +0200

Hi Denis,

I did study RFC 6960, especially the ASN.1, and I did not see anything that
prevents checking of attribute certificates, but knowing myself I could miss
something. I also know that in PKIX terminology a certificate is synonymous
to a public-key certificate.

Kind regards,

Erik 

From: pkix [mailto:[email-masked]] On Behalf Of Denis
Sent: Friday, April 11, 2014 2:09 PM
To: [email-masked]
Subject: Re: [pkix] ACs an OCSP

Erik,

Please take a look at the relevant RFCs before raising such a question to
this mailing list:

RFC 6960:

RFC 2560:

Denis

Erik

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

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Apr 2014 09:54:07 -0400

RFC 3281 says:

6. Revocation

   In many environments, the validity period of an AC is less than the
   time required to issue and distribute revocation information.
   Therefore, short-lived ACs typically do not require revocation
   support.  However, long-lived ACs and environments where ACs enable
   high value transactions MAY require revocation support.

   Two revocation schemes are defined, and the AC issuer should elect
   the one that is best suited to the environment in which the AC will
   be employed.

   "Never revoke" scheme:

      ACs may be marked so that the relying party understands that no
      revocation status information will be made available.  The
      noRevAvail extension is defined in section 4.3.6, and the
      noRevAvail extension MUST be present in the AC to indicate use of
      this scheme.

      Where no noRevAvail is present, the AC issuer is implicitly
      stating that revocation status checks are supported, and some
      revocation method MUST be provided to allow AC verifiers to
      establish the revocation status of the AC.

   "Pointer in AC" scheme:

      ACs may "point" to sources of revocation status information, using
      either an authorityInfoAccess extension or a crlDistributionPoints
      extension within the AC.

   For AC users, the "never revoke" scheme MUST be supported, and the
   "pointer in AC" scheme SHOULD be supported.  If only the "never
   revoke" scheme is supported, then all ACs that do not contain a
   noRevAvail extension, MUST be rejected.

   For AC issuers, the "never revoke" scheme MUST be supported.  If all
   ACs that will ever be issued by that AC issuer, contains a noRevAvail
   extension, the "pointer in AC" scheme need not be supported.  If any
   AC can be issued that does not contain the noRevAvail extension, the
   "pointer in AC" scheme MUST be supported.

   An AC MUST NOT contain both a noRevAvail and a "pointer in AC".

   An AC verifier MAY use any source for AC revocation status
   information.

So, my conclusion is that OCSP could support ACs, but I am not aware of anyone doing so.

Russ

On Apr 11, 2014, at 8:26 AM, Erik Andersen wrote:

> Hi Denis,
>  
> I did study RFC 6960, especially the ASN.1, and I did not see anything that prevents checking of attribute certificates, but knowing myself I could miss something. I also know that in PKIX terminology a certificate is synonymous to a public-key certificate.
>  
> Kind regards,
>  
> Erik

---

From: "Sill, Alan" <[email-masked]>
Date: Fri, 11 Apr 2014 13:58:04 +0000

The relevant point is to realize that anyone can add an extended AC to a certificate. This does not require signature by the issuing authority, only by the authority adding the AC. So you would have to set up your OCSP checking independently for each relevant authority.

Alan

On Apr 11, 2014, at 7:26 AM, Erik Andersen <[email-masked]> wrote:

> Please take a look at the relevant RFCs before raising such a question to this mailing list:
>  
> RFC 6960:
>   This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs.
> 
> 
> RFC 2560:
> Is it clear than OCSP can only be used for checking status of public-key certificates and not for attribute certificates?
>  
> Erik
> 
> 
>

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 11 Apr 2014 16:30:53 +0200

> So, my conclusion is that OCSP could support ACs, but I am not aware of anyone doing so.

OCSP is mandatory for ACs corresponding to qualified certificates in Germany. There might not be too many of them out
there, but they exist.

-- 
Johannes

---

From: Denis <[email-masked]>
Date: Fri, 11 Apr 2014 16:50:02 +0200

Hello Russ,

I do not believe that your conclusion is correct, since the only 
sentence you are using for your claim is:

    An AC verifier MAY use any source for AC revocation status information.

No text (i.e. neither RFC 2560 or RFC 6960) states that an OCSP server 
can manage AC revocation status information.

Erik observed that the same ASN.1 could be used. Maybe, but a new 
specification would then be needed to be written.

Johannes said that it is mandatory in Germany, but Germany has made very 
odd things in the past,
the major one being in the context of electronic signatures 
verifications to have a model for certificate verification
that is neither compatible with RFC 5280 nor with X.509. So I am not 
surprised that Germany is making additional odd things.

Note also that the concept of Qualified Attribute Certificate is a 
concept which does not exist at the European level at this time
and thus is specific to Germany and I would guess that there is a 
specification written in German (i.e. not in English).

Denis

>> I did study RFC 6960, especially the ASN.1, and I did not see 
>> anything that prevents checking of attribute certificates, but 
>> knowing myself I could miss something. I also know that in PKIX 
>> terminology a certificate is synonymous to a public-key certificate.
>> Kind regards,
>> Erik
>
>
>

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 11 Apr 2014 17:33:40 +0200

> Johannes said that it is mandatory in Germany, but Germany has made very odd things in the past,
> the major one being in the context of electronic signatures verifications to have a model for certificate verification
> that is neither compatible with RFC 5280 nor with X.509. So I am not surprised that Germany is making additional odd
> things.
> 

in general, you are right, German e-signature practices and PKI standards overlap only partially. And the fact that
German CAs issuing QC provide status information for ACs over OCSP does not necessarily imply that this practice (and it
isn't even based on technical specs but merely on interpretations of the law) conforms to the standards.

My impression is that at the time when RFC 2560 was written, the concept of ACs was still considered as future. However,
RFC 2560 clearly states that OCSP aims to be a supplement to CRLs:
   This document specifies a protocol useful in determining the current
   status of a digital certificate without requiring CRLs.
and points to RFC 2459. With RFC 3280 superseding RFC 2459, the possibility of having ACs in CRLs was introduced
(issuingDistributionPoint), but RFC 2560 was not updated.
--
Johannes

---

From: 王文正 <[email-masked]>
Date: Fri, 11 Apr 2014 17:17:14 +0000

To use OCSP for ACs, you have to solve the problem of how an Attribute Authority (AA) can delegate the revocation status response job to an OCSP responder.

In section 4.2.2.2 of RFC 6969, it says

   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 do one of the following:

   - sign the OCSP responses itself, or

   - explicitly designate this authority to another entity

   OCSP signing delegation SHALL be designated by the inclusion of
   id-kp-OCSPSigning in an extended key usage certificate extension
   included in the OCSP response signer's certificate.  This certificate
   MUST be issued directly by the CA that is identified in the request.

The problem is that in the cases where an AA is not a CA, the AA can not issue an public-key certificate to the OCSP Responder. Therefore, it is not possible for the AA to desiginate OCSP signing delegation. I do not think it is suitable to let an CA do the delegation on behalf of the AA because the AA might be a different entity from the CA.

Wen-Cheng Wang

________________________________
From: pkix [[email-masked]] on behalf of Johannes Merkle [[email-masked]]
Sent: Friday, April 11, 2014 11:33 PM
To: [email-masked]
Subject: Re: [pkix] ACs an OCSP

---

From: "Erik Andersen" <[email-masked]>
Date: Sat, 12 Apr 2014 08:35:01 +0200

Thanks Wen-Cheng Wang - good point.

Regards, Erik

From: pkix [mailto:[email-masked]] On Behalf Of ???
Sent: Friday, April 11, 2014 7:17 PM
To: [email-masked]
Subject: Re: [pkix] ACs an OCSP

To use OCSP for ACs, you have to solve the problem of how an Attribute
Authority (AA) can delegate the revocation status response job to an OCSP
responder.

The problem is that in the cases where an AA is not a CA, the AA can not
issue an public-key certificate to the OCSP Responder. Therefore, it is not
possible for the AA to desiginate OCSP signing delegation. I do not think it
is suitable to let an CA do the delegation on behalf of the AA because the
AA might be a different entity from the CA.

Wen-Cheng Wang

  _____  

From: pkix [[email-masked]] on behalf of Johannes Merkle
[[email-masked]]
Sent: Friday, April 11, 2014 11:33 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [pkix] ACs an OCSP

odd things in the past,
> the major one being in the context of electronic signatures verifications
to have a model for certificate verification
> that is neither compatible with RFC 5280 nor with X.509. So I am not
surprised that Germany is making additional odd
> things.

in general, you are right, German e-signature practices and PKI standards
overlap only partially. And the fact that
German CAs issuing QC provide status information for ACs over OCSP does not
necessarily imply that this practice (and it
isn't even based on technical specs but merely on interpretations of the
law) conforms to the standards.

My impression is that at the time when RFC 2560 was written, the concept of
ACs was still considered as future. However,
RFC 2560 clearly states that OCSP aims to be a supplement to CRLs:
   This document specifies a protocol useful in determining the current
   status of a digital certificate without requiring CRLs.
and points to RFC 2459. With RFC 3280 superseding RFC 2459, the possibility
of having ACs in CRLs was introduced
(issuingDistributionPoint), but RFC 2560 was not updated.
--
Johannes

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

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 14 Apr 2014 13:00:15 +0200

王文正 wrote on 11.04.2014 19:17:

> The problem is that in the cases where an AA is not a CA, the AA can not issue an public-key certificate to the OCSP
> Responder. Therefore, it is not possible for the AA to desiginate OCSP signing delegation. I do not think it is suitable
> to let an CA do the delegation on behalf of the AA because the AA might be a different entity from the CA.

Right, but there is no reason, why an AA should not be a CA as well, and if it only issues OCSP signer certs.

-- 
Johannes

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 17 Apr 2014 16:46:18 -0400

Here is text from RFC 5755 (which
obsoleted RFC 3281) that is more unambiguous. The text in Section
4.3.4 of RFC 3281 is nearly identical.

4. Attribute Certificate Profile

4.3. Extensions

4.3.4. Authority Information Access

The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be
used to assist the AC verifier in checking the revocation status of
the AC. Support for the id-ad-caIssuers accessMethod is OPTIONAL by
this profile since AC chains are not expected.

The following accessMethod is used to indicate that revocation status
checking is provided for this AC, using the Online Certificate Status
Protocol (OCSP) defined in [OCSP]:

id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

The accessLocation MUST contain a URI, and the URI MUST contain an
HTTP URL [HTTP-URL] that specifies the location of an OCSP responder.
The AC issuer MUST, of course, maintain an OCSP responder at this
location.

name id-ce-authorityInfoAccess
OID { id-pe 1 }
syntax AuthorityInfoAccessSyntax
criticality MUST be FALSE

On 04/11/2014 10:50 AM, Denis wrote:

Hello Russ,

An AC verifier MAY use any source for AC revocation
status information.

No text (i.e. neither RFC 2560 or RFC 6960) states that an
OCSP server can manage AC revocation status information.

Erik observed that the same ASN.1 could be used. Maybe, but a
new specification would then be needed to be written.

Johannes said that it is mandatory in Germany, but Germany has
made very odd things in the past,

that is neither compatible with RFC 5280 nor with X.509. So I am
not surprised that Germany is making additional odd things.

Note also that the concept of Qualified Attribute Certificate is
a concept which does not exist at the European level at this
time

and thus is specific to Germany and I would guess that there is
a specification written in German (i.e. not in English).

Denis

RFC 3281 says:

6. Revocation

In many environments, the validity period of an AC is
less than the

time required to issue and distribute revocation
information.

Therefore, short-lived ACs typically do not require
revocation

support.  However, long-lived ACs and environments
where ACs enable

high value transactions MAY require revocation
support.

Two revocation schemes are defined, and the AC issuer
should elect

the one that is best suited to the environment in
which the AC will

be employed.

"Never revoke" scheme:

ACs may be marked so that the relying party
understands that no

revocation status information will be made
available.  The

noRevAvail extension is defined in section 4.3.6,
and the

noRevAvail extension MUST be present in the AC to
indicate use of

this scheme.

Where no noRevAvail is present, the AC issuer is
implicitly

stating that revocation status checks are
supported, and some

revocation method MUST be provided to allow AC
verifiers to

"Pointer in AC" scheme:

ACs may "point" to sources of revocation status
information, using

either an authorityInfoAccess extension or a
crlDistributionPoints

extension within the AC.

For AC users, the "never revoke" scheme MUST be
supported, and the

"pointer in AC" scheme SHOULD be supported.  If only
the "never

revoke" scheme is supported, then all ACs that do not
contain a

For AC issuers, the "never revoke" scheme MUST be
supported.  If all

ACs that will ever be issued by that AC issuer,
contains a noRevAvail

extension, the "pointer in AC" scheme need not be
supported.  If any

AC can be issued that does not contain the noRevAvail
extension, the

An AC MUST NOT contain both a noRevAvail and a
"pointer in AC".

An AC verifier MAY use any source for AC revocation
status

information.

So, my conclusion is that OCSP could support ACs, but I
am not aware of anyone doing so.

Russ

Hi Denis,

I did study RFC 6960, especially the
ASN.1, and I did not see anything that prevents
checking of attribute certificates, but knowing
myself I could miss something. I also know that in
PKIX terminology a certificate is synonymous to a
public-key certificate.

Kind regards,

Erik

---

From: 王文正 <[email-masked]>
Date: Fri, 18 Apr 2014 01:48:45 +0000

Although both RFC 3281 and RFC 5755 specify that the authorityInfoAccess extension can be used to indicate OCSP is provided for that AC, OCSP is actually can not be used for ACs beacuse it is not possible for the AA to issue an public-key certificate to the OCSP Responder for delegating the revocation status response job.

Wen-Cheng Wang

________________________________
From: pkix [[email-masked]] on behalf of David A. Cooper [[email-masked]]
Sent: Friday, April 18, 2014 4:46 AM
To: [email-masked]
Subject: Re: [pkix] ACs an OCSP

Here is text from RFC 5755 (which obsoleted RFC 3281) that is more unambiguous. The text in Section 4.3.4 of RFC 3281 is nearly identical.

4.3.  Extensions

---

From: Denis <[email-masked]>
Date: Fri, 18 Apr 2014 10:50:30 +0200

David,

This is quite interesting.

RFC 6960 was produced after RFC 5755 and it is quite curious that RFC 
6960 does not say anything about it.

One of the problem with these RFCs is that they define data structures, 
but do not say how to use them.
In particular if you get some data back from that URL in the case of an 
AC , how do you verify that the response is correctly signed ?
This is not said, so interoperability is only a dream.

Maybe all of this is only an hypothetical case.  A long time ago, I made 
presentation at the RSA Security Conference in San Francisco
with the following title:

    Why are Attribute Certificates not yet in use today ?

Ten years after that presentation, the situation has not much changed.

One among the many reasons, is that among the three main options for 
linking a certificate to "something else", two of them are insecure.

Denis

> Here is text from RFC 5755 (which obsoleted RFC 3281) that is more 
> unambiguous. The text in Section 4.3.4 of RFC 3281 is nearly identical.
>
>> No text (i.e. neither RFC 2560 or RFC 6960) states that an OCSP 
>> server can manage AC revocation status information.
>>

---

From: Denis <[email-masked]>
Date: Fri, 18 Apr 2014 10:58:19 +0200

Wen-Cheng,

One one side your right: this would be the "normal" way to do it, in 
order to allow to use an automatic and an interoperable mechanism.

One the other side, there is also the possibility to have a "local 
configuration", but it is not an automatic nor an interoperable 
mechanism. So it is unscalable.

Using OCSP for ACs has not been fully thought, but only those using ACs 
would care. Who really cares ?

Denis

> Although both RFC 3281 and RFC 5755 specify that the 
> authorityInfoAccess extension can be used to indicate OCSP is provided 
> for that AC, OCSP is actually can not be used for ACs beacuse it is 
> not possible for the AA to issue an public-key certificate to the OCSP 
> Responder for delegating the revocation status response job.
>
> Wen-Cheng Wang
> ------------------------------------------------------------------------
> *From:* pkix [[email-masked]] on behalf of David A. Cooper 
> [[email-masked]]
> *Sent:* Friday, April 18, 2014 4:46 AM
> *To:* [email-masked]
> *Subject:* Re: [pkix] ACs an OCSP
>

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 18 Apr 2014 14:25:17 +0200

Whether ACs are of interest is an interesting question.

In smart grid security, role-based access control (RBAC) seems for some
reason as an important aspect. The lifetime of a role may be shorter than
the life of a public-key certificate. An AC is then seen as a temporary
extension to a public-key certificate.

SAML is not considered here.

Validation could be a major performance issue in a constrained environment.

Erik

From: pkix [mailto:[email-masked]] On Behalf Of Denis
Sent: Friday, April 18, 2014 10:58 AM
To: [email-masked]
Subject: Re: [pkix] ACs an OCSP

Wen-Cheng,

One one side your right: this would be the "normal" way to do it, in order
to allow to use an automatic and an interoperable mechanism.
 
One the other side, there is also the possibility to have a "local
configuration", but it is not an automatic nor an interoperable mechanism.
So it is unscalable.

Denis

Although both RFC 3281 and RFC 5755 specify that the authorityInfoAccess
extension can be used to indicate OCSP is provided for that AC, OCSP is
actually can not be used for ACs beacuse it is not possible for the AA to
issue an public-key certificate to the OCSP Responder for delegating the
revocation status response job.

Wen-Cheng Wang

  _____  

From: pkix [[email-masked] <mailto:[email-masked]> ] on behalf
of David A. Cooper [[email-masked] <mailto:[email-masked]> ]
Sent: Friday, April 18, 2014 4:46 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [pkix] ACs an OCSP

 
4.3.  Extensions

---

From: "Sill, Alan" <[email-masked]>
Date: Fri, 18 Apr 2014 13:22:53 +0000

This is also the case in compute-grid environments. In practice AC's are used only for limited-lifetime proxies derived from a primary certificate. The certificate itself is never used on its own and does not carry the role, optional group or virtual-organization membership information needed to allow the certificate to be mapped to a local authorization by a relying party.

Such information is provided by the extended AC, but is present only in the limited-lifetime proxy cert. OCSP is used (though not uniformly present for all grid CAs, as CRLs are still widespread) and can be applied to revoke a certificate but to my knowledge is not in use to revoke AC information. If a revocation were requested, it would be applied at the primary certificate level.

Alan

On Apr 18, 2014, at 7:26 AM, "Erik Andersen" <[email-masked]<mailto:[email-masked]>> wrote:

In smart grid security, role-based access control (RBAC) seems for some reason as an important aspect. The lifetime of a role may be shorter than the life of a public-key certificate. An AC is then seen as a temporary extension to a public-key certificate.

Erik

From: pkix [mailto:[email-masked]] On Behalf Of Denis
Sent: Friday, April 18, 2014 10:58 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [pkix] ACs an OCSP

Wen-Cheng,

One one side your right: this would be the "normal" way to do it, in order to allow to use an automatic and an interoperable mechanism.

One the other side, there is also the possibility to have a "local configuration", but it is not an automatic nor an interoperable mechanism. So it is unscalable.

Using OCSP for ACs has not been fully thought, but only those using ACs would care. Who really cares ?

Denis

Wen-Cheng Wang

________________________________
From: pkix [[email-masked]<mailto:[email-masked]>] on behalf of David A. Cooper [[email-masked]<mailto:[email-masked]>]
Sent: Friday, April 18, 2014 4:46 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [pkix] ACs an OCSP
Here is text from RFC 5755 (which obsoleted RFC 3281) that is more unambiguous. The text in Section 4.3.4 of RFC 3281 is nearly identical.

4.3.  Extensions

   location.

      OID            { id-pe 1 }

pkix mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: 王文正 <[email-masked]>
Date: Sat, 19 Apr 2014 17:13:53 +0000

Denis,

Of course, if a local configuration is adopted to accept a non-standard way to do it, anything is possible.

However, since here we are in a WG concerning Internet Standard, folks might be interested to clarify whether current RFCs defined by  this WG can provide a standard way to check AC revocation status over OCSP.

My conclusion is that the current AC and OCSP RFCs failed to provide it because there are conflicts between AC and OCSP RFCs. I believe that an extension or 'bis' needs to be made over RFC 5755 in order to support a standard way to check AC revocation status over OCSP, but I do not know whether there are a sufficient number of folks care about it or think it is worth spending effort to define an extension or make a 'bis' to RFC 5755?

Wen-Cheng Wang

________________________________
From: pkix [[email-masked]] on behalf of Denis [[email-masked]]
Sent: Friday, April 18, 2014 4:58 PM
To: [email-masked]
Subject: Re: [pkix] ACs an OCSP

Wen-Cheng,

Denis

---

From: 王文正 <[email-masked]>
Date: Sun, 20 Apr 2014 02:31:11 +0000

Oops, I made a mistake. What I really meant is that an extension or 'bis' needs to be made over RFC 6960 in order to support a standard way to check AC revocation status over OCSP.

My initial idea is as follows.

Since an AA can not designate the OCSP responder by issuing a PKC, we need to extend BasicOCSPResponse ASN.1 Syntax to allow it to designate the OCSP responder by using an AC.

   BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL
      attrCert        [1] EXPLICIT AttributeCertificate OPTIONAL } -- This field is to be used by an AA to designate the OCSP Responder.

And then we need to specify the format of AC for an AA to designate the OCSP responder.

Wen-Cheng Wang

======================================

From: Erik Andersen [[email-masked]]
Sent: Sunday, April 20, 2014 1:36 AM
To: 王文正
Subject: RE: [pkix] ACs an OCSP

Hi Wen-Cheng Wang,

What aspects of RFC 5755 should be changed to be compatible with OCSP?

Regards,

Erik

======================================

From: pkix [mailto:[email-masked]] On Behalf Of ???
Sent: Saturday, April 19, 2014 7:14 PM
To: [email-masked]
Subject: Re: [pkix] ACs an OCSP

Denis,

Wen-Cheng Wang

======================================

Denis

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 21 Apr 2014 17:31:09 +0200

Thanks Wen-Cheng Wang.

A related question: Can the Authority Information Access extension be
included in an attribute certificate?

Erik

From: pkix [mailto:[email-masked]] On Behalf Of ???
Sent: Sunday, April 20, 2014 4:31 AM
To: [email-masked]
Subject: Re: [pkix] ACs an OCSP

Oops, I made a mistake. What I really meant is that an extension or 'bis'
needs to be made over RFC 6960 in order to support a standard way to check
AC revocation status over OCSP.

Since an AA can not designate the OCSP responder by issuing a PKC, we need
to extend BasicOCSPResponse ASN.1 Syntax to allow it to designate the OCSP
responder by using an AC.

   BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL
      attrCert        [1] EXPLICIT AttributeCertificate OPTIONAL } -- This
field is to be used by an AA to designate the OCSP Responder.

And then we need to specify the format of AC for an AA to designate the OCSP
responder.

Wen-Cheng Wang

Hi Wen-Cheng Wang,

Regards,
 
Erik

 
Denis,
 
Of course, if a local configuration is adopted to accept a non-standard way
to do it, anything is possible.
 
However, since here we are in a WG concerning Internet Standard, folks might
be interested to clarify whether current RFCs defined by  this WG can
provide a standard way to check AC revocation status over OCSP.
 
My conclusion is that the current AC and OCSP RFCs failed to provide it
because there are conflicts between AC and OCSP RFCs. I believe that an
extension or 'bis' needs to be made over RFC 5755 in order to support a
standard way to check AC revocation status over OCSP, but I do not know
whether there are a sufficient number of folks care about it or think it is
worth spending effort to define an extension or make a 'bis' to RFC 5755?
 
Wen-Cheng Wang

 

Denis

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Apr 2014 12:01:08 -0400

RFC 3281 contains the answer...

4.3.4   Authority Information Access

   The authorityInformationAccess extension, as defined in [PKIXPROF],
   MAY be used to assist the AC verifier in checking the revocation
   status of the AC.  Support for the id-ad-caIssuers accessMethod is
   NOT REQUIRED by this profile since AC chains are not expected.

   The following accessMethod is used to indicate that revocation status
   checking is provided for this AC, using the OCSP protocol defined in
   [OCSP]:

   The accessLocation MUST contain a URI, and the URI MUST contain an
   HTTP URL [URL] that specifies the location of an OCSP responder.  The
   AC issuer MUST, of course, maintain an OCSP responder at this
   location.

On Apr 21, 2014, at 11:31 AM, Erik Andersen wrote:

> Thanks Wen-Cheng Wang.
>  
> A related question: Can the Authority Information Access extension be included in an attribute certificate?
>  
> Erik

---

From: 王文正 <[email-masked]>
Date: Mon, 21 Apr 2014 16:06:07 +0000

Eric,

Yes, both RFC 5755 and RFC 3281 explicitly allow to include the Authority Information Access extension in an AC. Please refer to section 4.3.4 of RFC 5755 or RFC 3281.

Wen-Cheng

________________________________
From: pkix [[email-masked]] on behalf of Erik Andersen [[email-masked]]
Sent: Monday, April 21, 2014 11:31 PM
To: [email-masked]
Subject: Re: [pkix] ACs an OCSP

Thanks Wen-Cheng Wang.

Erik

Wen-Cheng Wang

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 24 Apr 2014 18:55:22 +0200

> However, since here we are in a WG concerning Internet Standard, folks might be interested to clarify whether current
> RFCs defined by  this WG can provide a standard way to check AC revocation status over OCSP.

IMHO it would have been beneficial to allow (maybe under certain circumstances) trust in OCSP signer certificates issued
by the (superordinated) CA that issued the CA certificate used to issue the validated certificate. In this case a CA
could have obtained certificates for both certificate signing and OCSP signing from the same issuer. And in the case of
a CA key compromise, the OCSP responses for the certificates issued by that CA could still be trusted (unless the higher
level CA has been compromised as well).

-- 
Johannes