Re: Embedded certificate image

[Stefan Santesson <stefan@xxxxxxxxxxx>]

Title: Re: Embedded certificate image

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" <anders.rundgren@xxxxxxxxx> 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" <anders.rundgren@xxxxxxxxx> <mailto:anders.rundgren@xxxxxxxxx>  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 
> > > >       
> > > >  
> > >  
> >  
> >
> >
> >
> >