Re: Embedded certificate image

[Stefan Santesson <stefan@xxxxxxxxxxx>]

Title: Re: Embedded certificate image

Hi Thomas,

When discussing the particular issue at hand, it has just been considered in relation to certificate images.
However I agree that if we would create such extension, that we should make it generic.

I think that is yet another good argument that such extension should be separated from the certimage work.

What is your assessment on the actual need to store objects like an information card inside a certificate?

/Stefan


On 09-07-20 10:44 PM, "Thomas Hardjono" <ietf@xxxxxxxxxxxx> wrote:

> Stefan,
>  
> Has there been any thought about making such an extension “generic” enough that it could reference other human-friendly objects (e.g. InfoCard, OpenID identity, etc. etc).
>  
> /thomas/
>  
>  
>  
>
> From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Stefan Santesson
> Sent: Monday, July 20, 2009 1:50 PM
> To: ietf-pkix
> Subject: Embedded certificate image
>  
> 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