[x500standard] Re: Trust anchor information
- From: Carl Wallace <carl@xxxxxxxxxxxxxxxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>
- Date: Mon, 07 Apr 2014 09:30:01 -0400
Inline
From: DP-Security-Consulting <dp.sec.consulting@xxxxxxx>
Reply-To: <x500standard@xxxxxxxxxxxxx>
Date: Monday, April 7, 2014 at 9:15 AM
To: <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.
Other related posts:
