[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Embedded certificate image
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.
On 09-07-21 11:10 AM, "Anders Rundgren" <anders.rundgren@xxxxxxxxx> wrote:
>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:
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.
Stefan Santesson wrote:
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
But you won't get away from that first retrieval.
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.
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
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.