[x500standard] Re: Trust anchor information
- From: Carl Wallace <carl@xxxxxxxxxxxxxxxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>
- Date: Mon, 07 Apr 2014 10:14:43 -0400
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:
