[x500standard] Re: Trust anchor information
- From: Carl Wallace <carl@xxxxxxxxxxxxxxxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>
- Date: Fri, 11 Apr 2014 09:54:27 -0400
Denis,
Did this address your concerns? Regarding inaccuracy, I only meant that
there was no resistance to changing the specification because ³it had
already been implemented and thus no change was possible². The spec
underwent significant change during the PKIX process (and landed in a mostly
better spot for it).
Carl
From: Carl Wallace <carl@xxxxxxxxxxxxxxxxxxxx>
Date: Monday, April 7, 2014 at 10:14 AM
To: <x500standard@xxxxxxxxxxxxx>
Subject: Re: [x500standard] Re: Trust anchor information
> Here are three goals for ³the third choice²:
> 1. In many cases (should be all), it is desirable to constrain the use of
> trust anchors. The ³third choice² allows expression of constraints that can
> be associated with an existing certificate or name/public key.
> 2. In some cases it is desirable to limit the number of bytes communicated or
> stored. Since X.509/RFC5280 only require a name and a key for a TA, the
> ³third option² allows generating an encoding that includes only these values
> (plus a key identifier), resulting in encodings that are substantially smaller
> than Certificates. In cases where the TA is not used for certification path
> validation, the name can be omitted further reducing the size of the TA.
> 3. Most path validation implementations require TAs to be represented as a
> Certificate. The ³third choice² works with these libraries by allowing
> certificates to be wrapped with constraints. The Certificate can then be
> extracted and used with existing X.509/RFC5280 compliant implementations. RFC
> 5937 defines how to use the constraints to set up the standard path validation
> algorithm inputs exposed by an X.509/RFC5280 compliant implementations. RFC
> 5914 and RFC 5937 work nicely with existing X.509/RFC5280 compliant
> implementations to add constraints to TAs.
> Here are reasons why the first and second choices does not satisfy these
> goals:
>
> - Using a Certificate object, it is not possible to achieve item 1) because
> doing so would break the signature on the certificate and it is not possible
> to achieve item 2) because most fields are not OPTIONAL.
> - Using a TBSCertificate object it is possible to achieve item 1) (by
> expressing constraints as extensions) but it is not possible to achieve item
> 2) because most fields are not OPTIONAL and it is not possible to achieve item
> 3) since a TBSCertificate is not a Certificate.
>
> From: DP-Security-Consulting <dp.sec.consulting@xxxxxxx>
> Reply-To: <x500standard@xxxxxxxxxxxxx>
> Date: Monday, April 7, 2014 at 9:58 AM
> To: <x500standard@xxxxxxxxxxxxx>
> Subject: [x500standard] Re: Trust anchor information
>
>>
>>
>> Carl,
>>
>> Your arguments do not demonstrate that what I say is inaccurate. I am only
>> speaking of the third choice, i.e. TrustAnchorInfo.
>> You provide no argument for the third choice.
>>
>> Denis
>>
>>
>>
>>>
>>> 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:
