Hi Carsten,
Thank you for this review! I have asked if anyone would be willing to generate the examples for this draft, but for the time being I have removed the paragraph about this. As for the discussion about bag vs some other term, I believe I see your point, but my understanding from this thread [1] is that bag is a well defined concept and we could still use it here.
--
Best regards,
Ivaylo
On Tue, Oct 20, 2020 at 1:43 PM Carsten Bormann <cabo@xxxxxxx> wrote:
On 2020-10-20, at 03:15, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
>
> I believe we use the term bag because it is permissible for a certificate
> artifact to appear more than once. Stupid maybe, but permissible.
>
> I think that some systems/libaries considered the Issuer/Subject to be the
> key for indexing the set, and then they got confused if there was more than
> one certificate in the bag. The additional object used a different signature
> and/or hash. At least, I have some dim memory of some situation being
> described to me. I think that the names of the guilty parties were withheld.
I think we have a different perception of what “is” means.
In my shopping bag, there *is* a difference between having one or two yoghurts in there.
In the x5bag, having the same certificate twice is exactly equivalent to having it once.
So it “is” a (non-empty) set, not a bag, even if the *representation* (as an array, with a special case for the singleton) can actually have duplicates.
Given the semantics, the question how one “finds” things in that set is more of an implementation question. I don’t think offering this as a multimap(*) with some arbitrarily chosen map key is flexible enough. Normally, a simple iterator (so you get to see any and all of the elements) will be the best solution, because the implementation cannot know what the application-specific validation process is looking for, and we are talking about a very small set.
Grüße, Carsten
(*) Cannot be a map, as there is no guarantee of uniqueness of any key.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
