[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] specifying the <ds:X509SKI> element
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]