Inline...
From: DP-Security-Consulting <dp.sec.consulting@xxxxxxx
<mailto:dp.sec.consulting@xxxxxxx>>
Reply-To: <x500standard@xxxxxxxxxxxxx <mailto:x500standard@xxxxxxxxxxxxx>>
Date: Monday, April 7, 2014 at 9:15 AM
To: <x500standard@xxxxxxxxxxxxx <mailto:x500standard@xxxxxxxxxxxxx>>
Subject: [x500standard] Re: Trust anchor information
Remember that when the third odd format was proposed, I asked for
changes but at that time the response was
that it had already be implemented and thus no change was possible.
This is inaccurate. RFC 5914 changed in several ways during its
progression through PKIX. First, the "third odd format" was not
"third". Initially, it was the only item (and was included in the
TAMP specification, not a standalone specification). The
TrustAnchorChoice structure evolved to include an untagged Certificate
as one option (preserving backwards compatibility with the use of
certificates as TAs) and TBSCertificate as another option. The
TBSCertificate option was added to allow reuse of parsing code,
however, this is not useful for validation as essentially all
validation libraries require a certificate. To use this option, you'd
need to generate a fake signature to use the structure with most
validation libraries. Thus, in order to express constraints, using
the TrustAnchorInfo structure to wrap certificates is preferred. When
used with RFC5937, the constraints from the TrustAnchorInfo structure
are processed and used to set the standard inputs to the path
validation algorithm. The certificate can be extracted and passed
into existing libraries. RFC5914 and RFC5937 work nicely as a thin
wrapper around existing path validation libraries that accept the
standard validation algorithm inputs.
