<div dir="ltr">Tim, Brian,<div><br></div><div>I think this discussion of AKI/SKI/issuer name is much better suited for the IETF list rather than here.</div><div><br></div><div>That is, it's not so much a question about the ballot, nor similar to the debate Erwann and I are having about the interaction with regards to both the BRs and RFC5280, but about technical details in a CT implementer needs to worry about, right?</div><div><br></div><div>FWIW, no replacement occurs, as easily confirmed by looking at the various implementations.</div><div><br></div><div>From memory (and from implementation), the only difference between the two methods is the signing key. The PreCert is not X.509/RFC5280 validated as such (at least, not under the PreCert intermediate). As to why the PreCert intermediate had basicConstraints, that was unfortunately/ironically seen as necessary by the CAs who were involved in the discussions to make it easier for their systems, but it's not necessary from the logs point of view (a PreCert intermediate is conceptually equivalent to a Proxy cert, which also doesn't require/derive authority from the basicConstraints).</div><div><br></div><div>The fact that that particular detail (basicConstraints) may create interpretation issues for some CAs is unfortunate, and highlights why it's important to have CAs involved in the standards organizations to share their experience.</div><div><br></div><div>And on that note, again, the details of the bytes on wire/memory should probably move over to IETF, and the discussion about how it relates to policies - and most importantly, what an auditor examines - can be left here, since it's very much a CA/B Forum area of expertise and opinion.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 18, 2014 at 6:47 PM, Tim Shirley <span dir="ltr"><<a href="mailto:TShirley@trustwave.com" target="_blank">TShirley@trustwave.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> That's confusing, but since it is said that the "tbs_certificate" is<br>
>> without the poison extension, and the CA MUST include this extension,<br>
>> then this "tbs_certificate" does NOT reflect what the CA produced and<br>
>> sent. Thus, this "tbs_certificate" is modified by the log<br>
>> (modifications<br>
>> listed: issuer name and AKI), and the result is then signed by the log.<br>
><br>
>Thanks for explaining that. It is helpful to know why people disagree.<br>
>However, I still think I am right. I agree it is strange that section<br>
>3.2 doesn't say anything about the poison extension. But, I think it is a big leap to infer from that omission that the precertifcate's issuer and AKI must be the subject and SKI of the precertificate >signing certificate.<br>
<br>
</span>It isn't just that it doesn't say anything about the poison extension though.  It specifically states that the issuer name and AKI will be changed to match the final issuer.  Why would it mention them being changed if they weren't different than the final issuer's in the first place?<br>
<br>
<br>
<br>
________________________________<br>
<br>
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</div></div></blockquote></div><br></div>