Re: Embedded certificate image

[Stefan Santesson <[e-mail]>]

Anders,

Thanks for the clarifications provided off-line.
I just wanted to recap here on the list.

As we have concluded there are some variants for storing a locally selected
image with the certificate for local use. That is, in a way that does
benefit the certificate holder but not the relying party.
Information Card is one such technology and the system you are working on is
another.

As I think we concluded, these represent other use cases than the one the
certimage draft is addressing and IMO they are more complementary than
competing in the sense that if the issuer has provided an image, then it
will be a good candidate image for local use.

Nothing in this suggest that the certimage draft should provide a solution
for local storage of the image data.

/Stefan


On 09-07-21 11:57 AM, "Stefan Santesson" <[e-mail]> wrote:

> I¹m sorry Anders, but totally fail to see how this has anything to do with the
> discussed issue.
> 
> I don¹t see any ³competing proposal²
> Is there any chance you could give me a distinct short explanation in one
> sentence or two that would help me understand.
> 
> /Stefan
> 
> 
> 
> On 09-07-21 11:10 AM, "Anders Rundgren" <[e-mail]> wrote:
> 
>> Stefan,
>> 
>>> >I'm not sure what you mean by "competing" proposal
>> 
>> If you look back a few months on my comments to the cert-image I-D
>> you'll find pointers to an entirely different proposal which is built
>> on top of a new provisioning protocol which in turn builds on a
>> revised TPM-based key storage scheme:
>> http://webpki.org/papers/keygen2/secure-key-store.pdf
>> 
>> The "humble" goal is unifying Information Cards, PKI, and OTP because
>> they are all useful but support quite distinct use-cases.
>> 
>> Isn't this incredibly difficult to succeed with?  Probably, but there is
>> no competition at least, since most people appear awfully busy solving
>> yesterdays' problems (like PKI middleware), ignoring higher-level aspects
>> of tokens such as utility in the real world where you need to deal with
>> multiple identities and technologies.
>> 
>> In addition, "iPhone & friends" have shown that the Mobile Internet
>> finally is here while interoperable and generally available authentication
>> solutions are not.   The described solution is also designed to fill this
>> vacuum.
>> 
>> Anders
>> 
>> Stefan Santesson wrote:
>>>  
>>> Anders,
>>> 
>>> I'm not sure what you mean by "competing" proposal, but a reasonable
>>> behavior by the client is to cache the certificate image once it has
>>> obtained it, creating the situation where the image is locally stored but
>>> not embedded.
>>> 
>>> But you won't get away from that first retrieval.
>>> 
>>> /Stefan
>>> 
>>> 
>>> On 09-07-21 8:33 AM, "Anders Rundgren" <[e-mail]>
>>> <mailto:[e-mail]>  wrote:
>>> 
>>>   
>>>  
>>>>  
>>>> In the "competing" proposal, certificate images are locally stored
>>>> but not embedded in certificates.  This is a viable solution when
>>>> images are only to be consumed by the end-user.  For external
>>>> consumption (which I consider an entirely different use-case),
>>>> the existing I-D seems quite sufficient.
>>>> 
>>>> Anders
>>>> 
>>>> Stefan Santesson wrote:
>>>>     
>>>>  
>>>>>  
>>>>> This is the first of two unresolved issues listed in the Certimage draft.
>>>>> 
>>>>> Is there any reason to provide any means to embed certificate images
>>>>> in a certificate.
>>>>> 
>>>>> The reason why this might be a valid option is because we often use
>>>>> certificates in environments that have sufficient bandwidth and memory
>>>>> capacity to allow certificate images to be stored in the certificate
>>>>> itself. By storing the image in the certificate, we could save a
>>>>> network retrieval.
>>>>> 
>>>>> The main counter argument is that it would be a serious disadvantage
>>>>> if a certificate occasionally needs to be used in a constrained
>>>>> environment and the fact that the base standard that we are updating
>>>>> (RFC 3709) simply does not allow embedded images.
>>>>> 
>>>>> One way to do this could be to store images in a separate extension
>>>>> and then define  a way to reference that image from the logotype
>>>>> extension through an internal reference.
>>>>> 
>>>>> My proposed resolution is to exclude local storage from the current draft.
>>>>> Defining local embedding is adding unnecessary complexity to the draft.
>>>>> 
>>>>> If a strong reason emerges to allow local storage, then this can be
>>>>> defined in a separate draft.
>>>>> 
>>>>> /Stefan 
>>>>>       
>>>>>  
>>>>  
>>>  
>>> 
>>> 
>>> 
>>>   
>> 
>> 
>