Re: crypto-ISSUE-16: Definition for Key Expiration [Web Cryptography API]

Hi.
for determining key expiration,
are CRL or OCSP in scope of low level api?

regards
mountie.

On Mon, Aug 6, 2012 at 1:53 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Sun, Aug 5, 2012 at 9:46 PM, Web Cryptography Working Group Issue
> Tracker <sysbot+tracker@w3.org> wrote:
> > crypto-ISSUE-16: Definition for Key Expiration [Web Cryptography API]
> >
> > http://www.w3.org/2012/webcrypto/track/issues/16
> >
> > Raised by: Ryan Sleevi
> > On product: Web Cryptography API
> >
> > During the July Face-to-Face, the topic of Key Expiration was raised.
> However, a solid definition is lacking for what the semantics should be.
> >
> > Argument for Implementation Semantics:
> > - Expiration could serve as a quota-management technique. Keys may
> represent expensive resources, particularly in constrained environments.
> Therefore, an understanding of how long a key is supposed to live may allow
> a user agent to remove 'expired' keys over time.
> >
> > Argument for Application Semantics:
> > - Expiration should have no specific meaning to the implementation; it
> is simply provided to the application in an advisory capability to inform
> the application how a key can/should be used. This is particularly
> important for implementations that use pre-existing cryptographic APIs,
> such as OS APIs, as the underlying API may enforce these semantics. An
> example was given for a keypair where the private key may no longer be able
> to sign messages after a particular date, but the associated public key may
> be used to verify existing messages.
> >
> > Should expiration be handled on a per-application basis in the custom
> attributes, or is it a global attribute on all Key types that should be
> managed by the User Agent?
> >
> >
> >
>
> David, you initially scoped key expiration, so I was hoping you could
> explain a bit more of the use case and how you see it working.
>
> Vijay, you provided the example of a key that can no longer be used
> for signing, so I was hoping you could explain a bit more.
>
>
> While it is "easy" to say that expiration info reflects whatever is in
> the associated certificate, it's not a guarantee that there will even
> BE an associated certificate (eg: crypto-ISSUE-15, symmetric keys,
> ephemeral key pairs). It's also not clear what the validity period
> would be if the user has two certificates with either overlapping
> times (is it the union of the two validity periods?) or
> non-overlapping times (is it the min max? Whichever period is current
> for Now? Something else?)
>
> I will note that PKCS#11 (Linux/Mozilla) exposes this information via
> CKA_START_DATE and CKA_END_DATE on Key objects, as optional,
> non-normative parameters. Similarly, CSSM_KEYHEADER (OS X) defines
> startDate and endDate as the effective dates of the keys. I didn't see
> anything equivalent in CryptoAPI or CNG (under Key Storage Property
> Identifiers), however, so I'm not sure how universal this concept is.
>
>

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World