Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

[Denis Pinkas <[e-mail]>]

To the PKIX list:

    Without changing the meaning of "good" and of either "revoked" or
    "unknown", it is not possible to address the case of what is
     presently called "non-issued certificates".

The current text from RFC 2560 is:

    "The "good" state indicates a positive response to the state inquiry.
    At a minimum, this positive response indicates that the certificate
    is not revoked, but does not necessarily mean that the certificate
    was ever issued or that the time at which the response was produced
    is within the certificate's validity interval. Response extensions
    may be used to convey additional information on assertions made by
    the responder regarding the state of the certificate such as
    positive statement about issuance, validity, etc.

    The "revoked" state indicates that the certificate has been revoked
    (either permanantly or temporarily (on hold)).

    The "unknown" state indicates that the responder doesn't know about
    the certificate being requested".


    A minor change should be done to advertise that "good" may be
    returned when the certificate was never issued and CRLs are being
    used.


Replacement text for the definition of the "good" state:

    "The "good" state indicates a positive response to the state inquiry.
    At a minimum, this positive response indicates that the certificate
    is not revoked, but does not necessarily mean that the certificate
    was ever issued *(e.g. when CRLs are used by the OCSP responders)*
   or  that the time at which the response was produced is within the
    certificate's validity interval.  Response extensions may be used
    to convey additional information on assertions made by the OCSP
    responder regarding the state of the certificate such as *an **
**   indication that the OCSP responder has a direct access to the **
**   database of issued certificates*, validity, etc ... "

    Then either the meaning of "rekoved" or of "unknown" needs to be
    changed.

    draft-ietf-pkix-rfc2560bis-06 attempts to address the issue and
    proposes to keep the meaning of "unknown" unchanged and to change
    the meaning of "revoked" in the following way:

    "The "revoked" state indicates that the certificate has been revoked
    (either permanently or temporarily (on hold)). This state SHOULD also
    be returned if the responder *knows that the requested certificate 
has **
**   never been issued*. Note that the receiver of a response may have to
    consult out-of-band knowledge, or information in an extension defined
    outside of this standard, to know whether a particular responder has
    knowledge about whether a requested certificate has been issued or
    not and whether it responds "good" or "revoked" to a state request
    for a non-issued certificate".

    There is a door opened for a future extension "to know whether a
    particular responder has knowledge about whether a requested
    certificate has been issued or not".

    However, the extension proposed in 
draft-pinkas-2560bis-certinfo-00.txt,
    carries a slightly different meaning:

       - an indication that the serial number of the target
         certificate is not present in the database,

*Saying that the certificate has not been issued is not fully appropriate.*

The text should be modified in the following way:

    "The "revoked" state indicates that the certificate has been revoked
    (either permanently or temporarily (on hold)).  This state SHOULD
    also be returned if the responder *has an access to the database
    of **issued certificates and if the serial number of the target **
**   certificate is not present in that database. *

*In this case, the "revoked" state indicates either that the **
**   certificate has never been issued or that it has been issued but **
**   subsequently removed (by an attack or by accident) from the
    database **of issued certificates.*

    Response extensions may be used  to convey additional information
    on assertions made by the OCSP  responder regarding the state of the
    certificate such as *an **indication that the OCSP responder has
    a direct access to the **database of issued certificates*, validity, 
etc ... "

An alternative is to keep the meaning of "revoked" and to change
the meaning of "unknown" in the following way:

    "The "unknown" status indicates either that the server doesn't know
    about the certificate being requested *or the revocation status
    of the certificate being requested*

    Response extensions may be used  to convey additional information
    on assertions made by the OCSP  responder regarding the state of the
    certificate such as *an **indication that the OCSP responder has
    a direct access to the **database of issued certificates*, validity, 
etc ..."

There are pros and cons for each alternative. If the meaning of "revoked"
is changed it is also necessary to say what should be the values of both
revocationTime and revocationReason:

    CertStatus ::= CHOICE {
        good        [0]     IMPLICIT NULL,
        revoked     [1]     IMPLICIT RevokedInfo,
        unknown     [2]     IMPLICIT UnknownInfo }

    RevokedInfo ::= SEQUENCE {
        revocationTime              GeneralizedTime,
        revocationReason    [0]     EXPLICIT CRLReason
                                    OPTIONAL }

    UnknownInfo ::= NULL

CRLReason is imported from PKIX1Implicit88 { iso(1) 
identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19) }

CRLReason is defined in RFC 5280 as:

    CRLReason ::= ENUMERATED {
         unspecified             (0),
         keyCompromise           (1),
         cACompromise            (2),
         affiliationChanged      (3),
         superseded              (4),
         cessationOfOperation    (5),
         certificateHold         (6),
              -- value 7 is not used
         removeFromCRL           (8),
         privilegeWithdrawn      (9),
         aACompromise           (10) }


For the revocationTime should we use the content of notBefore field from 
the certificate ?

For the revocationReason should we use unspecified or keyCompromise ?

In any case, guidance should be given.

Although I understand that changing the meaning of "revoked" may be seen 
as "safer"
for old implemenations, changing the meaning of "unknown" also seems to 
be a reasonable alternative.

In this case, it might be useful (and sufficient) to say that if an OCSP 
responder is authoritative
for the target certificate, then the OCSP client SHOULD NOT use an 
alternative source
of revocation information like CRLs.

Denis


> In line;
>
> From: Piyush Jain <[e-mail] <mailto:[e-mail]>>
> Date: Sunday, October 21, 2012 7:42 PM
> To: Stefan Santesson <[e-mail] <mailto:[e-mail]>>, 
> 'Peter Rybar' <[e-mail] <mailto:[e-mail]>>, 'Carl Wallace' 
> <[e-mail] <mailto:[e-mail]>>, 'Simon 
> Tardell' <[e-mail] <mailto:[e-mail]>>
> Cc: 'Peter Rybar' <[e-mail] <mailto:[e-mail]>>, 
> <[e-mail] <mailto:[e-mail]>>
> Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>     So what is "not-issued" - not signed by the CA or not present in
>     CA database?
>
>
> Not issued means it has never been issued. What's unclear about that?
>
> Of course it is not present in the database if it is not issued.
> If you delete things from your database and don't know if this one has 
> been deleted, then you don't know that it has never been issued and 
> can't reply revoked.
>
>
>     It is unclear to folks who have been using signature verification
>     as a way to check issuance. Isn't it a fair conclusion that I do
>     not need to perform signature checks if the responder can check
>     issuance for me?
>
>
> No that is not a fair conclusion. These are entirely different things.
>
>     You said that the possibility to send revoked reply only applies
>     when the responder 'knows' that requested certificate has never
>     been issued.
>
>     Please note that the responder will encounter this kind of request
>     only in two situations. First in which the RP sends a request for
>     a certificate without checking the signature and second in which
>     the responder itself is compromised by virtue of its issuing
>     authority being compromised. In either case what the responder
>     responds with does not matter.
>
>
> Some people are pretty convinced it does (from CAB forum), they are so 
> convinced that they are prepared to break compatibility with OCSP. By 
> this little extension that hurst no-one, they don't have to.
>
>     I've no problem with your proposal to respond with 'revoked' in
>     this situation.
>
>
> Good.
>
>     I've fundamental problem with the introduction of 'non-issued'
>     concept in OCSP, which seems to provide additional security in
>     this exceptional scenario without actually providing any.
>
>
> It provides some, but not much. People keep coming back to that fact 
> that if this had been the practice of Diginotar, the security breach 
> would have been discovered a lot earlier. So there might be some gain 
> with no pain.
>
> However, in combination with an extension that adds information, this 
> might actually be increasingly valuable.
> If an OCSP responder starts receiving status requests for certs it 
> knows it has not issued, it can actually give explicit information 
> about this using an extension and it can take adequate measures.
> But in order to respond to the user, it need to pick one of the 
> responses. Either good + extension or revoked+extension.
>
> This proposal is not meant to require any OCSP responder to deal with 
> the concept of "non-issued" certs. It merely allows an OCSP responder 
> to respond to such request.
>
>     It'll be very helpful if I can see at least one practical scenario
>     where this additional text would add value.
>
>
> Stated in my previous comments.
>
> /Stefan
>
>     -Piyush
>
>     *From:*Stefan Santesson [mailto:[e-mail]]
>     *Sent:* Sunday, October 21, 2012 8:52 AM
>     *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
>     *Cc:* 'Peter Rybar'; [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>     I don't think the "not issued" is unclear.
>
>     The possibility to send a revoked reply only applies then the
>     responder "knows" that the requested certificate has never been
>     issued.
>
>     How the responder knows this is totally irrelevant, but unless the
>     responder knows this, it can't choose this option and has to reply
>     "good".
>
>     It does not make revocation checking non-deterministric.
>
>     "good" still means what is declared in the standard (The cert is
>     not known to be revoked, but it may never have been issued).
>
>     "revoked" still have a deterministic meaning, that is, don't trust
>     this cert. The old exact semantics was "the cert IS revoked". The
>     new semantic is "the cert is revoked or possibly might never been
>     issued"
>
>     The new response semantic of revoked is backwards compatible and
>     not less deterministic than the good, response.
>
>     So, I still don't see any practical problems here.
>
>     /Stefan
>
>     *From: *Piyush Jain <[e-mail] <mailto:[e-mail]>>
>     *Date: *Saturday, October 20, 2012 5:48 PM
>     *To: *Stefan Santesson <[e-mail]
>     <mailto:[e-mail]>>, 'Peter Rybar' <[e-mail]
>     <mailto:[e-mail]>>, 'Carl Wallace'
>     <[e-mail] <mailto:[e-mail]>>,
>     'Simon Tardell' <[e-mail] <mailto:[e-mail]>>
>     *Cc: *'Peter Rybar' <[e-mail]
>     <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>
>     *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>         Please see inline
>
>         *From:*Stefan Santesson [mailto:[e-mail]]
>         *Sent:* Friday, October 19, 2012 7:23 PM
>         *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
>         *Cc:* 'Peter Rybar'; [e-mail] <mailto:[e-mail]>
>         *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>         I'm sorry. I fail to the any of the problems you raise.
>
>         If you receive a request for a certificate that you know has
>         never been issued, and you choose to reply revoked, what
>         problems can you cause?
>
>         */[Piyush] It depends on how you define "never been issued",
>         which btw becomes unclear after introduction of the new text.
>         There are two interpretations/*
>
>         1)*/Certificate is not signed by the CA or/*
>
>         2)*/Certificate is not present in the database of issued
>         certificates that CA maintains./*
>
>         */One unintended consequence of first interpretation will be
>         that RPs would stop performing signature checks if their
>         responder/CA publicizes that it returns revoked for
>         "non-issued" certificates./*
>
>         */If the interpretation is 2, then this scenario is not
>         possible unless the CA is compromised./*
>
>         What in your mind is a more appropriate response?
>
>         */[Piyush] I would say the appropriate response is good (if
>         the certificate is not marked as revoked), because that is
>         what the RP will see if it consults a CRL or a responder
>         detached from the CA. /*
>
>         */Revoked for "not issued" adds no value because the only case
>         in which an RP would send a query for a "non-issued"
>         certificate is when the CA is compromised./*
>
>         It does not make OCSP more non-deterministic. If you ask
>         status for an issued cert from a non-broken CA, nothing is
>         non-deterministic.
>
>         */[Piyush] It does not make OCSP non-deterministic but it
>         makes revocation checking non-deterministic. The goal of OCSP
>         is to address operational limitations of CRLs, not functional
>         limitations.  The fact that you'll get different answers from
>         two sources, both of which are authorized by the same CA makes
>         revocation checking non deterministic. /*
>
>         If you ask for status for a non-issued certificate, or a bad
>         certificate from a broken CA, then the result is by default
>         non-deteministic and has always been. However, choosing a
>         revoked response may save the relying party, at best, but can
>         hurt no-one
>
>         */[Piyush] I agree that a revoke response does not hurt
>         anyone. But the point is that it provides a false sense of
>         additional security to the RP without providing any. As an RP,
>         I won't trust what my responder says if the authority that
>         certified it is compromised./*
>
>         What is your problem on the practical ground.
>
>         */[Piyush] /* Let's say that we still need to address this
>         scenario and revoked is the appropriate response. In that case
>
>         -The text needs to be explicit about the revocation time in
>         this situation. Revoked implies good until a certain date and
>         this distinction is important for long term archiving
>         applications. For unissued certificate the revocation time
>         should probably be set to --infinity.
>
>         -It needs to call out that in this particular scenario it is
>         addressing a functional limitation of CRLs (ability to detect
>         CA compromise) not an operational limitation.
>
>         -I think we need additional text in security considerations to
>         indicate that RP is communicating with a responder certified
>         by a compromised CA in this scenario.
>
>         /Stefan
>
>         *From: *Piyush Jain <[e-mail]
>         <mailto:[e-mail]>>
>         *Date: *Friday, October 19, 2012 7:34 PM
>         *To: *Stefan Santesson <[e-mail]
>         <mailto:[e-mail]>>, 'Peter Rybar' <[e-mail]
>         <mailto:[e-mail]>>, 'Carl Wallace'
>         <[e-mail]
>         <mailto:[e-mail]>>, 'Simon Tardell'
>         <[e-mail] <mailto:[e-mail]>>
>         *Cc: *'Peter Rybar' <[e-mail]
>         <mailto:[e-mail]>>, <[e-mail]
>         <mailto:[e-mail]>>
>         *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>             Stefan,
>
>             I think some of you interpretations below are twisted to
>             accommodate the new provisions for providing revoked
>             responses for unissued certificates.
>
>             Providing responses for expired certificates is within the
>             scope of 2560 using archive cutoff extension.
>
>             The original authors of 2560 can correct me if I'm wrong,
>             but it is my understanding that a response from OCSP
>             responder is not supposed to indicate if a certificate is
>             good or bad but to indicate if a certificate is revoked or
>             unrevoked by the issuing authority. The fact that
>             certificate is issued by the CA is checked by the RP by
>             verifying the signature on the certificate.
>
>             This draft introduces the concept of returning revoked
>             responses for unissued certificates. There are many
>             unintended consequences of this approach
>
>             -Revocation statuses become non-deterministic based on who
>             you are asking (A responder with access to CA database vs.
>             one without vs. checking status off a CRL). If I'm
>             archiving a signed document with the relevant artifacts to
>             determine the validity status of the document, this
>             becomes a huge problem. Note that a revoked status implies
>             that certificate was good between the time of its issuance
>             and that of its revocation. Any document that is signed
>             within that period should still be considered valid.
>
>             -It would confuse an implementer about what "non-issued"
>             means. The fact that the CA signed the certificate implies
>             it was issued. If a certificate is issued fraudulently,
>             based on its security practices, it is up to the CA to
>             either revoke the issued certificate, or ask its issuing
>             authority to revoke its own certificate.
>
>             -Piyush
>
>             *From:*[e-mail]
>             <mailto:[e-mail]>
>             [mailto:[e-mail]] *On Behalf Of *Stefan Santesson
>             *Sent:* Friday, October 19, 2012 7:25 AM
>             *To:* Peter Rybar; 'Carl Wallace'; 'Simon Tardell'
>             *Cc:* 'Peter Rybar'; [e-mail] <mailto:[e-mail]>
>             *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>             Peter,
>
>             An OCSP responder is by default a service providing
>             information about current certificates.
>
>             The default response you get from an OCSP responder is
>             "good" unless the cert is known to be bad or not a cert
>             the responder can provide status for.
>
>             If you need it to respond about old certificates, and as a
>             client know that the responder does this in a way that
>             suits your needs, you will need to add an extension.
>
>             Such extension will not be part of the rfc256bis effort.
>
>             Is there any text in the current draft that you think is
>             unclear on this?
>
>             /Stefan
>
>             *From: *Peter Rybar <[e-mail] <mailto:[e-mail]>>
>             *Date: *Friday, October 19, 2012 3:12 PM
>             *To: *'Carl Wallace' <[e-mail]
>             <mailto:[e-mail]>>, 'Simon Tardell'
>             <[e-mail] <mailto:[e-mail]>>
>             *Cc: *'Peter Rybar' <[e-mail]
>             <mailto:[e-mail]>>, Stefan Santesson
>             <[e-mail] <mailto:[e-mail]>>,
>             <[e-mail] <mailto:[e-mail]>>
>             *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>                     Well, yes, sort of. You can only be sure to
>                     validate a signature at the moment of production.
>
>                 What if the signature key was compromised at the
>                 moment of production but is not yet on a revocation list?
>
>                 [PR] According to clause 2.4  -  thisUpdate: The time
>                 at which the status being indicated is known to be correct
>
>                 It means when signature time-stamp time is X then any
>                 OCSP responses with thisUpdate time X+y are sufficient
>                 to validate because the status is correct.
>
>                 Y is in the interval <0, producedAt - X>
>
>                     At any later point in time the signature key may
>                     be compromised, or the algorithms involved may
>                     have become to weak. (In which case the time of
>                     revocation in the OCSP response is worth nothing
>                     to you). The risk increases as time passes. And of
>                     course, the revocation information may not be kept
>                     around after the expiry of the certificate.
>
>                     That's why you should validate signatures as soon
>                     as possible.
>
>                 For these archival purposes wouldn't it be better to
>                 have the final revocation list before removed due to
>                 expiry?  In any case, you'd need verification
>                 information collected after some grace period
>                 following moment of production.
>
>                 [PR] Grace period is not a fixed value of the time
>                 interval.
>
>                 Grace period is changeable because the first OCSP
>                 response with thisUpdate time value > than time of
>                 signature time-stamp contains correct status.
>
>                     If you need to ascertain that a signature was
>                     valid at a later time, you have to trust your
>                     system that it performed the validation at the
>                     time it first received the signature. That trust
>                     must be established through some kind of mix of
>                     policies and technical measures (such as
>                     timestamping).
>
>                 In the dark corner just beyond the dark corner that is
>                 SCVP, there's a spec (RFC 5276) that defines a binding
>                 of evidence records to artifacts that can be returned
>                 viaSCVP.  This provides for timestamping.
>
>                 [PR] The validation is simplified when OCSP response
>                 with positive statement as a hash value of requested
>                 certificate is used.
>
>                 Positive statement is evidence that OCSP know the
>                 status of certificate and also protect the integrity
>                 of certificate with a new more secure hash algorithm.
>
>                 Peter Rybar
>
>
>
>                     Simon Tardell,
>
>                     Technology Nexus.
>
>                     On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar
>                     <[e-mail] <mailto:[e-mail]>> wrote:
>
>                     Stefan,
>
>                     I have a question about the present OCSP RFC and
>                     at the end of the mail about the new situation
>                     which will happen according to your new proposal.
>
>                     The presence of the positive statement in OCSP
>                     response is important for electronic signature
>                     validations, especially for an expired
>                     certificate. Positive statement is the hash value
>                     of a certificate whose status is provided in OCSP
>                     response.
>
>                     Electronic signature validation is usually about
>                     the signatures created in the past and validated
>                     now, when the certificate is expired.
>
>                     When the certificate expires then revocation is
>                     usually removed from CRL and the revoked
>                     certificate can be provided as "good" in OCSP
>                     response.
>                     Is it acceptable? I think not.
>
>                     According to your new draft there is not defined a
>                     value of revocationTime.
>                     RFC must also define the value of revocationTime
>                     when the certificate which was never issued is as
>                     "revoked".
>                     http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06
>
>                     Have you also covered the situation when the
>                     certificate is expired, REMOVED FROM CRL and will
>                     be provided as revoked with incorrect
>                     revocationTime e.g.with the value before or after
>                     the revocationTime which was present in the
>                     removed record from CRL?
>                     Because according to sentence in your draft
>                     ""revoked" - This state SHOULD also be returned if
>                     the responder knows that the requested certificate
>                     has never been issued." the following situation
>                     can happen: when certificate is removed from CRL
>                     after expiration and CA/OCSP responder is
>                     responsible for this certificate but have not
>                     record about expired certificate and for that
>                     reason it is identified as "never been issued".
>
>                     ...
>                     revoked     [1] IMPLICIT RevokedInfo,
>                     ...
>
>                        RevokedInfo ::= SEQUENCE {
>                            revocationTime  GeneralizedTime,
>                      revocationReason  [0]     EXPLICIT CRLReason
>                     OPTIONAL }
>
>                     As you have mentioned in the mail:
>
>                     "On the "revoked" state, the old spec did not even
>                     consider the case of a certificate being requested
>                     where the OCSP responder knows that the
>                     certificate was never issued."
>
>                     "It simply recommend a known to be bad certificate
>                     to result
>                     in "revoked" in order to prevent damage as far as
>                     possible. It also opens
>                     for definition of new extensions through which
>                     such knowledge could be
>                     obtained."
>
>                     Peter Rybar
>                     National Security Authority
>                     Information Security and Electronic Signature
>                     Department
>                     Budatinska 30, 850 07 Bratislava 57, Slovak Republic
>                     e-mail: [e-mail]
>                     <mailto:[e-mail]>
>                     e-mail: [e-mail] <mailto:[e-mail]>
>
>
>                     -----Original Message-----
>                     From: [e-mail]
>                     <mailto:[e-mail]>
>                     [mailto:[e-mail]
>                     <mailto:[e-mail]>] On Behalf Of
>                     Stefan Santesson
>                     Sent: Monday, October 15, 2012 1:49 AM
>                     To: [e-mail] <mailto:[e-mail]>
>                     Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06
>
>                     All,
>
>                     I have just posted an update of rfc2560bis (OCSP
>                     update) after carefully
>                     reviewing all comments on the list.
>
>                     Some notes about the update:
>
>                     - Added the previous OCSP editors with updated
>                     affiliations.
>                     - Added some calcifications on ResponderID as
>                     suggested by Simon Josefsson.
>                     - Updated the clarifications on Authorized
>                     responders. The requirements
>                     have not changed. I just tried to improve the text.
>                     - Updated a clarification on the "revoked" state
>                     to be the preferred
>                     response if a certificate is known by the
>                     responder to never have been
>                     issued.
>                     - Some minor editorial nits.
>
>
>                     Regarding backwards compatibility I mean that none
>                     of the clarifications
>                     changes RFC 2560.
>
>                     On Authorized responders it has always been the
>                     case that a responder
>                     certificate issued with the same key as was used
>                     to issue the certificate
>                     being checked for revocation, represents a valid
>                     Authorized responder.
>                     There has never been an explicit requirement to
>                     support key rollover and
>                     key rollover support has never been in the
>                     "spirit" of the original
>                     standard as it clearly attempted to provide direct
>                     cryptographic binding
>                     between the responder and the CA.
>
>                     On the "revoked" state, the old spec did not even
>                     consider the case of a
>                     certificate being requested where the OCSP
>                     responder knows that the
>                     certificate was never issued. It is clearly
>                     counterproductive to respond
>                     good when a certificate is known to be bad. A
>                     responder must pick one
>                     response and picking "revoked" breaks nothing, but
>                     has the desired effect,
>                     that is, to prevent the certificate from being
>                     accepted. The current text
>                     makes clear that there is no mechanism in the
>                     current standard by which a
>                     client can know how a responder will respond to a
>                     request for a not issued
>                     certificate. It simply recommend a known to be bad
>                     certificate to result
>                     in "revoked" in order to prevent damage as far as
>                     possible. It also opens
>                     for definition of new extensions through which
>                     such knowledge could be
>                     obtained.
>
>                     The current updates also clearly opens a path for
>                     the CAB forum efforts to
>                     define a suitable solution for server certificates.
>
>                     I have not, even thug suggested, added any
>                     requirements on what clients
>                     should do with the checked cert as a result of a
>                     particular response. I
>                     don't believe such requirements are suitable as it
>                     is policy and not
>                     protocol. We have no right to demand that all
>                     systems MUST reject any
>                     certificate for any reason as they may have a
>                     local policy that overrules
>                     the OCSP response. This protocol only provides
>                     information about the cert
>                     status, it does not mandate validation policy.
>
>                     I have not included any of the substantial changes
>                     i the Pinkas draft. I
>                     want to wait for a list of motivation for each
>                     change before including any
>                     of them. So there changed may be up for debate
>                     before this draft is ready
>                     for WGLC.
>
>                     /Stefan
>
>
>
>                     _______________________________________________
>                     pkix mailing list
>                     [e-mail] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/pkix
>
>                     _______________________________________________
>                     pkix mailing list
>                     [e-mail] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/pkix
>
>                     _______________________________________________
>                     pkix mailing list [e-mail]
>                     <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/pkix
>
>
>
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix