[cabfpub] Ballot for limited exemption to RFC 5280 for CTimplementation

[Ryan Sleevi]

Tim, Brian,

I think this discussion of AKI/SKI/issuer name is much better suited for
the IETF list rather than here.

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?

FWIW, no replacement occurs, as easily confirmed by looking at the various
implementations.

>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).

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.

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.

On Thu, Sep 18, 2014 at 6:47 PM, Tim Shirley <TShirley at trustwave.com> wrote:

> >> That's confusing, but since it is said that the "tbs_certificate" is
> >> without the poison extension, and the CA MUST include this extension,
> >> then this "tbs_certificate" does NOT reflect what the CA produced and
> >> sent. Thus, this "tbs_certificate" is modified by the log
> >> (modifications
> >> listed: issuer name and AKI), and the result is then signed by the log.
> >
> >Thanks for explaining that. It is helpful to know why people disagree.
> >However, I still think I am right. I agree it is strange that section
> >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.
>
> 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?
>
>
>
> ________________________________
>
> 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.
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140918/feb1e59a/attachment.html