_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
pkix@ietf.o=
rghttps://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
pkix mailing list
pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
______________________________________________=
_
pkix mailing list
pkix@ietf.orghttps://www.ietf.=
org/mailman/listinfo/pkix
______________________________________________=
_
pkix mailing list
pkix@ietf.orghttps://www.ietf.=
org/mailman/listinfo/pkix
_______________________________________________
pkix mailing list
pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
=A0=A0 The =
"revoked" state indicates that the certificate has been revoked
=A0=A0 eith=
er permanently or temporarily on hold (i.e. the revocation reason<=
/b>
=A0=A0 is c=
ertificateHold).
=A0=A0 either permanently or temporarily (e=
.g. placed on hold).
=A0=A0 This=
 extension MAY be present in other responses to signal that the
=A0=A0 resp=
onder implements the extended revoked definition in section 2.2.
=A0=A0 This=
 extension indicates that the responder supports the extended<=
span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB"><=
/pre>
        =A0=A0 defi=
nition of the "revoked" status to also include non-issued
        =A0=A0 cert=
ificates according to section 2.2.
        Since both
            =93unknown=94 and revoked=94 can be used, it would be desirab=
le to
            be able to include the same extension in both cases, 

            but in that case that extension should be renamed.=

        This extension can be included in all response=
s
            to signal that a responder implements the expanded
            definition of revoked.<=
/span>
        Doing so ma=
kes
            this fact auditable without having to ask for a non-issued
            cert.
        I would
            propose to rename it: "non-issued certificate=94 which me=
ans
            that the associated CA has no record of ever having issued a
            certificate 

            with the certificate serial number in the request (I still
            consider it as unnecessary in the case of =93revoked=94, but =
it
            would be very useful in the case of =93unknown=94). 

            Of course, the text from section 4.4.8 would need to be
            revised.
        I propose t=
he
            following:
        =A0
        4.4.8=A0 Non-issued certificate extension
        =A0=A0 This=
 extension MUST be included in the OCSP response when the OCSP 

        =A0=A0=A0re=
sponder knows that the CA identified in the request has no record =

        =A0=A0=A0of=
 ever having issued a certificate with the certificate serial =
=

        =A0=A0=A0nu=
mber indicated in the request.
        =A0=A0 Clie=
nts do not have to parse this extension in order to determine =
=

        =A0=A0=A0th=
e status of certificates in responses.
        =A0=A0 This=
 extension is identified by the object identifier id-pkix-ocsp-

        =A0=A0 non-=
issued-cert.
        =A0=A0=A0=A0 id-pkix-ocsp-non-issued-cert OBJECT IDENTIFIER ::=3D {id-pkix-ocsp 9}
        =A0=A0 The =
value of the extension SHALL be NULL. This extension MUST NOT be

        =A0=A0 mark=
ed critical.
        Then the te=
xt
            on page 8 would need to be rearranged.
        Your extens=
ion
            =A0variant is a significant change to what has been agreed.
        Your extens=
ion
            would need to be a single response extension, and can't be
            used to audit the behaviour of the OCSP responder 

            unless you send a request for a non-issued cert.
        Hummm !!! We have a very important point
              there. Thanks to your comment, I now realize that the
              proposed extension 

              applies to the whole response. However, this is not
              possible and I will now explain why. An OCSP responder may
              receive 

              a delegation from several CAs. With some of them, it can
              use a direct access to the database of certificates, 

              while for some others, it will use CRLs. So the meaning of
              =93revoked=94 will depend of the CA. =

        This means that the indication cannot be
              global to the OCSP response. If we use an extension, it
              can only apply 

            to an individual response and thus MUST in
              singleExtensions instead of responseExtensions.

        Since it is singleExtension, it can used to
              =93audit the behaviour of the OCSP responder=94 and I do no=
t
              grasp your rational 

            when you say =93unless you send a request for a
              non-issued cert=94. There is no need for sending anything.<=
/b>

        We want to avoid sending such fake requests fo=
r
            audit purposes as it may interfere with systems at the
            responder trying to detect existence of rouge certificates.<=
/span>
        There is no need to sending fake requests.<=
/b>

        This is a type of change that I can't make
            unless you get support from a majority of the WG for the
            change of direction you propose.=

        The important point is that the text states:=

        =93The "revoked" state (=85) MAY also be
                returned if the associated CA has no record of ever
              having issued a certificate 

              with the certificate serial number in the request, using
              any current or previous issuing key (referred to as a

              "non-issued" certificate in this document).=94

        The test does not
              state =93MUST also be returned=94. Thi=
s
              means that it is also possible to reply =93unknown=94 if th=
e
              associated CA 

            has no record of ever having issued a certificate
              with the certificate serial number in the request.
              However, this is not 

            straightforward when reading the text and thus the
              text should be made more explicit.

Now, we get to the main point. The reason
              for adding an extension is NOT to say that an extended
              meaning of revoked 

            is being used, but that the INDIVIDUAL response is
              given using a direct access to the records of the
              certificates issued by the CA.
        The current
            text is: 

        =A0=A0 This=
 state MAY also be returned if the
        =A0=A0 asso=
ciated CA has no record of ever having issued a certificate with

        =A0=A0 the =
certificate serial number in the request, using any current or=
=

        =A0=A0 prev=
ious issuing key (referred to as a "non-issued" certificate in=
=

        =A0=A0 this=
 document).
        =A0=A0 The =
"unknown" state indicates that the responder doesn't know about

        =A0=A0 the =
certificate being requested.
        =A0=A0 NOTE=
: The "revoked" state for known non-issued certificate serial<=
span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB"><=
/pre>
        =A0=A0=A0=A0=A0=A0=
=A0=A0 numbers is allowed in order to reduce the risk of relying
        =A0=A0=A0=A0=A0=A0=
=A0=A0 parties using CRLs as a fall back mechanism, which would be=

        =A0=A0=A0=A0=A0=A0=
=A0=A0 considerably higher if an "unknown" response was returned.<=
/span>
        =A0=A0 When=
 a responder responds revoked to a status request for a non-
        =A0=A0 issu=
ed certificate, the responder MUST include the extended revoked

        =A0=A0 defi=
nition response extension (section 4.4.8) in the response,
        =A0=A0 indi=
cating that the OCSP responder supports the extended definition

        =A0=A0 of r=
evoked state to also cover non-issued certificates. In addition,

        =A0=A0 the =
SingleResponse related to this non-issued certificate;
        =A0=A0=A0 -=
 MUST provide the revocation reason certificateHold (6),
        =A0=A0=A0 -=
 MUST specify the revocationTime January 1, 1970, and;
        =A0=A0=A0 -=
 MUST NOT include a CRL References extension (section 4.4.2) or any
        =A0=A0=A0=A0=A0 CRL Entry Extensions (section 4.4.5). 
        Proposed te=
xt
            for a replacement: 

        =A0=A0 The =
"unknown" state indicates that the responder doesn't know about

        =A0=A0 the =
certificate being requested.
        =
=A0
        =A0=A0 If t=
he OCSP responder knows that CA identified in the request has =
=

        =A0=A0=A0no=
 record of ever having issued a certificate with the certificate <=
/b>

        =A0=A0=A0se=
rial number in the request, using any current or previous issuing =

        =A0=A0=A0ke=
y (referred to as a "non-issued" certificate in this document), 

        =A0=A0=A0th=
e OCSP responder SHALL respond either =93revoked =93 or =93unknown=94.
        This is
            unfortunately very common in your rewording efforts. When
            trying to fix one thing, you create new even bigger
            problems.
        An
            infrastructure that provides reproduced responses will
            respond "unauthorized". This text may be interpreted to
            interfere with such operations.
        I fear I don=92t understand your argument ab=
out
              =93unauthorized=94, but before replying see below my next
              comment.
        Further, an=
d
            worse. This is not backwards compatible. Current OCSP
            responders may respond "good" even if they have access to CA
            records.=A0
        You say: =93Current OCSP responders may resp=
ond
              "good" even if they have access to CA records=94. Originall=
y
              RFC 2560 allowed 

              returning =93good=94 for OCSP responder using CRLs. Since R=
FC
              2560 provided no way to indicate that a direct access to
              the database 

              was being used or not, it was not possible to do better. 

        Now, if an OCSP responder has a direct acces=
s
              and indicates in the response that it has such an access,
              do you really believe 

              that it will return good ? I don=92t. 

        If an OCSP responder wants to return =93goo=
d=94,
              it can still do it, but in that case it will not signal
              that it is using a direct access 

            and this is perfectly backwards compatible. So I do
              not =93buy=94 your argumentation.

        Now, may be you understand better why I
              propose to rename the extension =934.4.8 Non-issued
              certificate extension=94 and 

            also to change its semantics.

=A0
        =A0=A0 Note=
: The "revoked" state for known non-issued certificate serial =
=

        =A0=A0=A0nu=
mbers is allowed in order to reduce the risk of relying parties 

        =A0=A0=A0using CRLs as a fall back mechanism=
, which would be possible when 
        =A0=A0=A0th=
e "unknown" response is returned.
        =A0=A0 When=
 a responder responds revoked or unknown to a status request <=
span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB"><=
/pre>
        =A0=A0=A0fo=
r a non-issued certificate, the responder MUST include the 
        =A0=A0=A0no=
n-issued certificate extension (see section 4.4.8) in the 
        =A0=A0=A0re=
sponse. 
        =A0=A0=A0Wh=
en a responder responds revoked to a status request for a non-=
=

        =A0=A0 issu=
ed certificate, in addition, the responder:
        =A0=A0=A0 -=
 MUST provide the revocation reason certificateHold (6),
        =A0=A0=A0 -=
 MUST specify the revocationTime January 1, 1970, and;
        =A0=A0=A0 -=
 MUST NOT include a CRL References extension (section 4.4.2) or any
        =A0=A0=A0=A0=A0 CRL Entry Extensions (section 4.4.5).
        Finally, th=
e
            last bullet on page 4 should be reworded:

Current tex=
t:
        =A0=A0=A0=A0=A0 o Section 4.4.8 specifies a new extension that indicates that the
        =A0=A0=A0=A0=A0=A0=
=A0=A0 responder supports the extended use of the "revoked" respon=
se=

        =A0=A0=A0=A0=A0=A0=
=A0=A0 for non-issued certificates defined in section 2.2.<=
/b>

        Proposed
            replacement text:
        =A0=A0=A0=A0=A0 o=A0 Section 4.4.8 specifies=
 a new extension that indicates that 
        =A0=A0=A0=A0=A0=A0=
=A0=A0=A0the OCSP responder knows that CA identified in the reques=
t =

        =A0=A0=A0=A0=A0=A0=
=A0=A0=A0has no record of ever having issued a certificate with th=
e =

        =A0=A0=A0=A0=A0=A0=
=A0=A0=A0certificate serial number present in the request, as defi=
ned 
        =A0=A0=A0=A0=A0=A0=
=A0=A0=A0in section 2.2.
        No. Again,
            this changes the scope of the extension and its audit
            properties.
        Such change
            requires WG consensus.
        See earlier comments.=

        Comment 9:=
 Solved, if =
the
            comment above may be solved.
        Comment 20=
:=A0 This comment is
            preliminary classified by you as =93not broken=94. However,
            since you asked: =93If you don=92t replace 4.2.2.3,

            then what really are you missing ?=94, I will provide you wit=
h
            an answer.
        This is the
            wrong way to state the question. Providing an ASN.1 syntax
            as in 4.2.1 is not enough: the use of every parameter MUST
            be explained 

            using English words. So if you explain the use of every
            parameter after the description of the ASN.1 syntax in
            section 4.2.1. then section 4.2.2.3 

            is no more needed and thus can be deleted.<=
/p>

The answer =
to
            your question =93what is really missing=94 is a description o=
f
            the use of every parameter listed in the ASN.1 in section
            4.2.1
        There are sufficient descriptions in the
            subsections following the ASN.1 description. Your change
            proposals are not compatible with the minimalistic 

            approach adopted by the WG.<=
/span>
        The key point is whether we want a =93good=94
              document or maintain the low quality of the original
              document.
        Comment 26=
: You asked =
for
            explanations. Let me provide you with an example when CRLs
            are being used by the OCSP responder in the background. 

            The OCSP responder needs to make sure that the CRL it uses
            is valid. If it is simply using published CRLs (i.e. no
            trusted link with the CA), it needs 

            to make sure that the CA which has issued the CRL has no
            been revoked.
        No, this is a misstatement. You don't revoke
            CAs. You revoke CA certificates. 
        Right.
        There might be a CA certificate that has been
            revoked for a reason that does not affect the OCSP
            responder.
        =A0..but the contrary may also apply.
        These are operational policies that are outsid=
e
            the scope of the protocol.
        The proposed text does not affect the
              protocol.
        The proposed text in comment 26 is plain wrong=
,
            or at least misleading. The OCSP responder does not have to
            validate the CRL up to any particular root. 

            It may for example have been configured to directly trust
            the public key used to validate the CRL.<=
/span>
        This depends how it makes sure that
              it is reading the right CRL. It may or may not use a root
              CA.
        In France,
            there is a root CA for the Administration. However, the use
            of that root CA is optional. Thus a Ministry may have its
            own root, 

            but may also have its key certified by the root CA of the
            Administration. The OCSP responder may use the root CA of
            the Ministry, 

            while a relying party may use the root CA of the
            Administration (or the reverse) to validate the CRL for the
            target certificate. 

            Thus the revocation status will be different if the
            certificate of the CA of the Ministry is revoked by the root
            CA of the Administration.
        Which reinforces my point. How the OCSP
            responder is configured to trust its information source is
            outside the scope of the protocol.=

        The OCSP protocol never claims to provide the
            same conclusion about revocation than another source the
            relying party may use.<=
/span>
        We both agree; however would you point me
              where this is said in the current draft? Since I could not
              find it, 

              I believe it is useful to highlight the point in the
              security considerations section.

        Finally, I believe that the major point
              indicated earlier comes from the original "bad writing"
              of=A0 RFC 2560.
        There is no clear distinction between what
              applies to BasicOCSPResponse and =
what applies to Single
              Response.
        On page 15 from draft-14, the text still
              states in section=A0 4.2.2.2=A0 Authorized Responder:

              =A0=A0 "It is necessary however to ensure that the entity
              signing this information is authorized to do so".

              This is vague. What is "this information " ? This text is
              within section "4.2.2=A0 Notes on OCSP Responses".

              This does not help much.

              Is it BasicOCSPResponse ? If it is , this is wrong.

              It is SingleResponse, since a single response may be
              signed by the right key and/or the right certificate, 

              but not another single response.

              How can a reader guess that it is SingleResponse ?

              Once again the quality of the text is really bad, and that
              text and some other portions=A0 (3.2=A0 Signed Response
              Acceptance Requirements)

              would need to be changed.

        Denis

=A0=A0 The =
"revoked" state indicates that the certificate has been revoked
=A0=A0 eith=
er permanently or temporarily on hold (i.e. the revocation reason
=A0=A0 is c=
ertificateHold).
=A0=A0 eith=
er permanently or temporarily (e.g. placed on hold).
=A0=A0 This=
 extension MAY be present in other responses to signal that the
=A0=A0 resp=
onder implements the extended revoked definition in section 2.2.
=A0=A0 This=
 extension indicates that the responder supports the extended<=
/span>
=A0=A0 defi=
nition of the "revoked" status to also include non-issued
=A0=A0 cert=
ificates according to section 2.2.
4.4.8=A0 No=
n-issued certificate extension
=A0
=A0=A0 This extension MUST be included in t=
he OCSP response when the OCSP 
=A0=A0=A0re=
sponder knows that the CA identified in the request has no record 
=A0=A0=A0of=
 ever having issued a certificate with the certificate serial =

=A0=A0=A0nu=
mber indicated in the request.
=A0
=A0=A0 Clients do not have to parse this ex=
tension in order to determine 
=A0=A0=A0th=
e status of certificates in responses.
=A0
=A0=A0 This extension is identified by the =
object identifier id-pkix-ocsp-
=A0=A0 non-=
issued-cert.
=A0
=A0=A0=A0=A0 id-pkix-ocsp-non-issued-cert O=
BJECT IDENTIFIER ::=3D {id-pkix-ocsp 9}
=A0
=A0=A0 The value of the extension SHALL be =
NULL. This extension MUST NOT be
=A0=A0 mark=
ed critical.
=A0=A0 This=
 state MAY also be returned if the
=A0=A0 asso=
ciated CA has no record of ever having issued a certificate with
=A0=A0 the =
certificate serial number in the request, using any current or=

=A0=A0 prev=
ious issuing key (referred to as a "non-issued" certificate in=

=A0=A0 this=
 document).
=A0
=A0=A0 The "unknown" state indicates that t=
he responder doesn't know about
=A0=A0 the =
certificate being requested.
=A0
=A0=A0 NOTE: The "revoked" state for known =
non-issued certificate serial
=A0=A0=A0=A0=A0=A0=
=A0=A0 numbers is allowed in order to reduce the risk of relying
=A0=A0=A0=A0=A0=A0=
=A0=A0 parties using CRLs as a fall back mechanism, which would be=

=A0=A0=A0=A0=A0=A0=
=A0=A0 considerably higher if an "unknown" response was returned.<=
o:p>
=A0
=A0=A0 When a responder responds revoked to=
 a status request for a non-
=A0=A0 issu=
ed certificate, the responder MUST include the extended revoked
=A0=A0 defi=
nition response extension (section 4.4.8) in the response,
=A0=A0 indi=
cating that the OCSP responder supports the extended definition
=A0=A0 of r=
evoked state to also cover non-issued certificates. In addition,
=A0=A0 the =
SingleResponse related to this non-issued certificate;<=
/b>
=A0
=A0=A0=A0 - MUST provide the revocation rea=
son certificateHold (6),
=A0
=A0=A0=A0 - MUST specify the revocationTime=
 January 1, 1970, and;
=A0
=A0=A0 =A0=
- MUST NOT include a CRL References extension (section 4.4.2) or a=
ny
=A0=A0=A0=A0=A0 CRL Entry Extensions (section 4.4.5). 
=A0=A0 The =
"unknown" state indicates that the responder doesn't know about
=A0=A0 the =
certificate being requested.
=A0
=A0=A0 If the OCSP responder knows that CA =
identified in the request has 
=A0=A0=A0no=
 record of ever having issued a certificate with the certificate 
=A0=A0=A0se=
rial number in the request, using any current or previous issuing 
=A0=A0=A0ke=
y (referred to as a "non-issued" certificate in this document), 
=A0=A0=A0th=
e OCSP responder SHALL respond either =93revoked =93 or =93unknown=94.
=A0
=A0=A0 Note: The "revoked" state for known =
non-issued certificate serial 
=A0=A0=A0nu=
mbers is allowed in order to reduce the risk of relying parties 
=A0=A0=A0us=
ing CRLs as a fall back mechanism, which would be possible when 
=A0=A0=A0th=
e "unknown" response is returned.
=A0
=A0=A0 When a responder responds revoked or=
 unknown to a status request 
=A0=A0=A0fo=
r a non-issued certificate, the responder MUST include the 
=A0=A0=A0no=
n-issued certificate extension (see section 4.4.8) in the 
=A0=A0=A0re=
sponse. 
=A0
=A0=A0 When a responder responds revoked to=
 a status request for a non-
=A0=A0 issu=
ed certificate, in addition, the responder:
=A0
=A0=A0=A0 - MUST provide the revocation rea=
son certificateHold (6),
=A0
=A0=A0=A0 - MUST specify the revocationTime=
 January 1, 1970, and;
=A0
=A0=A0=A0 - MUST NOT include a CRL Referenc=
es extension (section 4.4.2) or any
=A0=A0=A0=A0=A0 CRL Entry Extensions (section 4.4.5).
=A0=A0=A0=A0=A0 o Section 4.4.8 specifies a new extension that indicates that the
=A0=A0=A0=A0=A0=A0=
=A0=A0 responder supports the extended use of the "revoked" respon=
se
=A0=A0=A0=A0=A0=A0=
=A0=A0 for non-issued certificates defined in section 2.2.
=A0=A0=A0=A0=A0 o =A0Section 4.4.8 specifies=
 a new extension that indicates that 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0the OCSP responder knows that CA identified in the reques=
t 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0has no record of ever having issued a certificate with th=
e 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0certificate serial number present in the request, as defi=
ned 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0in section 2.2.
=A0=A0 Note=
: CA key rollover is not prohibited when issuing a certificate=

=A0=A0=A0=A0=A0=A0=
=A0=A0 for an authorized responder for backwards compatibility wit=
h
=A0=A0=A0=A0=A0=A0=
=A0=A0 RFC 2560 [RFC2560]. That is, it is not prohibited to issue =
a
=A0=A0=A0=A0=A0=A0=
=A0=A0 certificate for an authorized responder using a different
=A0=A0=A0=A0=A0=A0=
=A0=A0 issuing key than the key used to issued the certificate bei=
ng
=A0=A0=A0=A0=A0=A0=
=A0=A0 checked for revocation. However, such practice is strongly<=
o:p>
=A0=A0=A0=A0=A0=A0=
=A0=A0 discouraged since clients are not required to recognize a
=A0=A0=A0=A0=A0=A0=
=A0=A0 responder with such certificate as an authorized responder.=

=A0=A0 Note=
: For backwards compatibility with RFC 2560 [RFC2560], it is <=
/span>
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0not prohibited to issue a certificate for an authorized <=
o:p>
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0responder using a different issuing key than the key used=
 to 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0issued the certificate being checked for revocation. 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0However, such practice is strongly discouraged since clie=
nts 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0are not required to recognize a responder with such =

=A0=A0=A0=A0=A0=A0=
=A0=A0=A0certificate as an authorized responder.=

2.=A0 Protocol Overv=
iew
=A0
=A0=A0 In lieu of or=
 as a supplement to checking against a periodic CRL, it=

=A0=A0 may be necess=
ary to obtain timely information=
 regarding the
=A0=A0 revocation st=
atus of a certificate (cf. RFC5280], Section 3.3).
                          =A0=A0 Examples incl=
ude high-value funds transfer or large stock trades.
                          =A0
                          =A0=A0 The Online Ce=
rtificate Status Protocol (OCSP) enables applications to
                          =A0=A0 determine the=
 (revocation) state of an identified certificate. OCSP<=
/pre>
                          =A0=A0 may be used t=
o satisfy some of the operational requirements of
                          =A0=A0 providing more timely revocation information<=
/b> than is possible with

                          =A0=A0 CRLs and may =
also be used to obtain additional status information. <=
/pre>
                          =A0
                          This text is misleading because re=
aders may think that OCPS necessarily provides =93timely information=94.<=
o:p>
                          =A0

Proposed text replacement:
=A0
=A0
=A0
=A0
=A0=A0 An OCSP clien=
t issues a status request to an OCSP responder and 
                          =A0=A0=A0Suspends ac=
ceptance of the certificate in q=
uestion until the 
                          =A0=A0=A0responder p=
rovides a response.
                          =A0
                          =A0=A0 This protocol=
 specifies the data that needs to be exchanged between<=
/pre>
                          =A0=A0 an applicatio=
n checking the status of a certificate and the server
                          =A0=A0 providing tha=
t status.
                          =A0
                          Thus is insufficient for an overvi=
ew. More details are needed to know what the document provides,=20
in particular that the request may contain several requests for several c=
ertificates issued by different CAs.=20
The possibility of using extensions should also be advertised.=

                          =A0
                          Proposed text replacement:
                          =A0
                          =A0=A0 =
When
                              using OCSP, an OCSP client issues a
                              certificate revocation 

=A0=A0 =
status

                              request to an OCSP responder for
                                one or more certificates <=
/span>
                          =A0=A0 issued

                                by the same CA or for one or more
                                certificates issued by =

                          =A0=A0 different

                                CAs and then suspends acceptance
                              of the certificate(s) 

=A0=A0 =
in
                              question until the responder provides a
                              response.
                          =A0
                          =A0=A0 =
This
                              document specifies the data that needs to
                              be exchanged between
                          =A0=A0 =
an
                              application checking the status of a
                              certificate and the server
                          =A0=A0 =
providing

                              that status.=A0

                          =A0
                          =A0=A0 OCSP

                                may also provide additional status
                                information using <=
/p>

=A0=A0 extensions.

                          =A0=

                          =A0=

<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 3. t=
he request contains the information needed by the responder If=

<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 any one of the prior conditions are not met, the OCSP responder=

<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 produces an error message; otherwise, it returns a definitive
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 response.
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 4. t=
he request contains the information needed by the responder.
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0
=A0=A0=A0=A0=A0 If any one of the prior con=
ditions are not met, the OCSP responder
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 produces an error message; otherwise, it returns a definitive
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 response.
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0
=A0=A0 -=A0=
 the CA who issued the certificate in question
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 -=A0 a Trusted Responder whose public=
 key is trusted by the requester
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 -=A0 a CA Designated Responder (Autho=
rized Responder) who holds a
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 specially marked certificate issued directly by the CA, indicating
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 that the responder may issue OCSP responses for that CA.<=
/span>
=A0
=A0
=A0
Most implementations only support =
the case where the OCSP Responder receives an OCSP certificate that is si=
gned by the same key=20
that was used to sign the target certificate. They do not support the cas=
e where the OCSP Responder receives an OCSP certificate=20
that is signed by a key that is different from the one that was used to s=
ign the target certificate.
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 -=A0 a CA Designated Responder (Autho=
rized Responder) who holds a
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 specially marked certificate issued directly by the CA, indicating
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 that the responder may issue OCSP responses for that CA.<=
/span>
=A0
6. Page 7, the text states:
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 A de=
finitive response message is composed of:
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0
=A0=A0 -=A0=
 version of the response syntax
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 -=A0 name of the responder=

<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 -=A0 responses for each of the certif=
icates in a request
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 -=A0 optional extensions
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 -=A0 signature algorithm OID
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 - =A0signature computed across hash o=
f the response
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 ResponseData ::=3D SEQUENCE {
<=
span style=3D"mso-spacerun:yes">=A0=A0=A0=A0=A0 version=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [0] =
EXPLICIT Version DEFAULT v1,
<=
span style=3D"mso-spacerun:yes">=A0=A0=A0=A0=A0 responderID=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ResponderID,<=
/pre>
                          <=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 producedAt=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 GeneralizedTime,
                          <=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 responses=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 SEQUENCE OF SingleResponse,

                          <=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 responseExtensions=A0=A0 [1]=
 EXPLICIT Extensions OPTIONAL }
                          =A0=

                          Proposed text replacement:
                          =A0=

                          =A0=A0 A
                                definitive response message is composed
                                of:
                          =A0<=
/p>

=A0=A0 -
                                a response status and if there is no
                                error, the following:

                          =A0=A0 -
                                the version of the response syntax,<=
/o:p>
                          =A0=A0 -
                                an identifier of the OCSP server,
                          =A0=A0 -
                                the time at which the response was
                                produced,
                          =A0=A0 -
                                single responses for each of the target
                                certificates,
                          =A0=A0 -
                                optional extensions,

                          =A0=A0 -
                                the signature algorithm OID,
                          =A0=A0 -
                                the signature computed across hash of
                                the response, and

=A0=A0 -
                                optional certificates.<=
/b>

                          =A0=

                          =A0=

Proposed text replacement:
=A0=A0 The "revoked" state indicates that the certif=
icate has been revoked,
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 eith=
er permanently or temporarily.
=A0
=A0=A0 A certificate=
 may be temporarily revoked either because it is 
=A0=A0=A0placed on h=
old (i.e. the revocation reason =
is certificateHold) or 
=A0=A0=A0because the=
 responder is able to know, using a positive list of 
                          =A0=A0=A0issued cert=
ificates, that the serial number from the requested 
                          =A0=A0=A0certificate=
 has not yet been used by th=
e CA to issue a certificate 
                          =A0=A0=A0(i.e. the revocation reason is notIssuedOrIr=
regularlyIssued).
                          =A0
                          <=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">NOTE: The "revoked" state is used rather than the =93=
unknown=94 state, to
                          <=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 make sure that relying parties that were conformant to RFC 2560=

                          <=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 will not use CRLs as a fall back mechanism. 
                          =A0

The above sentence uses the text:<=
/span> 
=A0
=93a status request for a non-issued certificate=94 
=A0
whereas it would be more appropria=
te to state: 
=A0
=93a status request for a serial number which has not been used by the CA or used irregularl=
y to issue a certificate=94.
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0
Placing the ASN.1 description at s=
uch a place in the document is inappropriate since the ASN.1 structures h=
ave not yet been described.=20
Thus only the functional aspects should be mentioned, but not the ASN.1 i=
mplications.
<=
span style=3D"font-size:12.0pt;
mso-ansi-language:EN-GB" lang=3D"EN-GB">=A0
BTW, the description should follow=
 the same order as the ASN.1. This is not the case. 
                          =A0
                          This text should be deleted from t=
his section and the appropriate text should be added when the parameters =
of the response are described. 
                          =A0
                          The text proposed in the previous =
comment should be sufficient at this time of reading.
                          =A0
                          In
                              addition, section 4.4.8=A0 E=
xtended

                                Revoked Definition should
                              be deleted.<=
o:p>
                          =A0
                          =A0

<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 When=
 a responder responds revoked to a status request for which it 
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0kn=
ows that the serial number has not been used by the CA or has =

<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0be=
en irregularly used irregularly to issue a certificate, then <=
/span>
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0in=
 RevokedInfo the responder MUST:
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0
=A0=A0 =A0=
=A0=A0- specify the revocationTime :=A0 January 1, 1970,
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB"> =A0=A0=A0=A0=
=A0- provide the revocatio=
nReason: notIssuedOrIrregularlyIssued (7).
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0
=A0=A0 and in SingleResponse the responder =
MUST NOT include the nextUpdate.
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

   The name constraints ex=
tension, which MUST be used only in a CA
   certificate, indicates a name space within which all subject names in=

   subsequent certificates in a certification path MUST be located.
   The name constraints extension, which =
MUST be used only in a CA
   cer=
tificate, indicates a name space within which all subject names in<=
/o:p>
   subsequent certificates in =
a certification path MUST be located.
The text – =
“For URIs, the constraint =
applies to the host part of the name.” from 5280 indicates that the author assumed that URIs will always =
have the authority component, which is a wrong assumption.

   The name constraints =
extension, which MUST be used only in a CA
   certificate, =
indicates a name space within which all subject names =
in
   subsequent =
certificates in a certification path MUST be located.
The text � �For URIs, the constraint applies to the host part of the name.� from 5280 indicates that the author assumed that URIs will always have the authority component, which is a wrong assumption.
The text – =
“For URIs, the constraint applies to the host part of the =
name.” from 5280 indicates that the author assumed that URIs will always =
have the authority component, which is a wrong assumption.<=
/o:p>
The=
 text – “For URIs, the constraint applies to the host part =
of the name.” from 5280 indicates that the author assumed that=
 URIs will always have the authority component, which is a wrong assumption=
.
The text � �For URIs, the constraint applies to the host part of the name.� from 5280 indicates that the author assumed that URIs will always have the authority component, which is a wrong assumption.
The text – “For URIs, the constraint applies to the host part of the name.” from 5280 indicates that the author assumed that URIs will always have =
the authority component, which is a wrong assumption.

Intermediate CA Policy OID : =	2.16.840.1.114412.1
2.16.840.1.114412.1.1

I= ntermediate CA Policy OID :	2.16.840.1.114412.1
2.16.840.1.114412.1.1