<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 25, 2016 at 12:30 PM, Doug Beattie <span dir="ltr"><<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal"><a name="1843670014__MailEndCompose"><span style="color:rgb(31,73,125)">Good questions Jeremy.
<u></u><u></u></span></a></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I hate to ask, but is rfc 5019 another RFC that must be met in order to be BR compliant, and will any errors there be warnings or full audit findings?  There are a lot of rules about cache values which we might
 not be all compliant with.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> </span></p></div></div></blockquote><div><br></div>5019 is a fully independent spec; that is, it does not Update or Obsolete RFC 2560 (OCSP)<div> </div><div>5019 is incorporated by reference in the BRs (Section 1.6.3), *but* it is listed as an AND/OR in 4.9.9</div><div><br></div><div>So if you (properly) implement 2560, you should be able to pass an audit even if you improperly implement 5019.</div><div>Unless you claim you implement 5019 in your CP/CPS, and at which point, I would argue you should have qualifications, because that is auditable and is in scope of the BRs.</div></div></div></div>