RE: [security-services] specifying the <ds:X509SKI> element

[ARI KERMAIER <ARI.KERMAIER@oracle.com>]

Hi Tom,

What's meant by "the DER-encoded Subject Key Identifier (SKI) extension"?
Is it the entire DER-encoded Extension object, which is a sequence of OID, critical flag and value?
Or is it the value field, which is an ASN.1 OCTET STRING, including its ASN.1 DER-encoded tags?
Or is it the bytes of the SKI value, i.e., the content of the OCTET STRING without its tags?

I would favor the last of these options, so we don't assume ASN.1 parsing capability on the part of an XML protocol implementation.

::Ari


> -----Original Message-----
> From: Tom Scavo [mailto:trscavo@gmail.com]
> Sent: Tuesday, October 07, 2008 2:33 PM
> To: OASIS SSTC
> Subject: [security-services] specifying the <ds:X509SKI> element
> 
> 
> I had a conversation with Peter Sylvester on the back channel about
> the Subject Key Identifier certificate extension and its relation to
> the <ds:X509SKI> element in HoK assertions.  I will paraphrase his
> comments by proposing new normative language for the latter.  Instead
> of what is now in the Holder-of-Key Assertion Profile, consider the
> following:
> 
> "The <ds:X509Data> element MAY contain a <ds:X509SKI> element. If it
> does, the <ds:X509SKI> element MUST contain a base64 encoding of the
> DER-encoded Subject Key Identifier (SKI) extension of an X.509
> certificate.  If the latter does not contain an SKI extension, the
> <ds:X509Data> element MUST NOT contain a <ds:X509SKI> element."
> 
> Since the content of the SKI certificate extension (if it exists) is
> not well-defined, the use of <ds:X509SKI> for the purposes of HoK
> subject confirmation is more like <ds:X509SubjectName> or
> <ds:X509IssuerSerial>, that is, it's only useful if there's an
> underlying X.509-based PKI (which is out of scope).
> 
> I see two immediate advantages of this approach.  First, it simplifies
> the normative language of the Holder-of-Key Assertion Profile, and
> second, it aligns with the Metadata Interoperability Profile as it's
> currently written.  The latter isn't a goal of the Holder-of-Key
> Assertion Profile per se, but it's still an advantage of this new
> approach, I think.
> 
> Thoughts?
> 
> Tom
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
oups.php