[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x] Another streamlining approach to the core
Hi Pim, hi Detlef, it's my vision of a signing server that it controls the use of the key material and the client should not interfere with that. And all the problems that may occur (client selects certificate that does not match the usage, that's already expired, that does match the policy, that's unavailable ...) must be reported to the client. We would contradict the effort to streamline the core if we import these options XKMS is about. But nevertheless do I understand that key selection options are a valid requirement for a certain type of use cases. So I would propose to ceeate a profile to enable e.g. a XKMS-alike selection mechanism. Greetings, Andreas > > Yes I've had this requirement too for another specification (ebCore > CPPA), the closest I could find it was the XKMS LocateRequest. > > It would be good to have a flexible pattern syntax that can match on a > variety of fields. For example, for use with EN 319 412-3, one would > need to be able to select based on the subject.organizationIdentifier. > > > On 17-02-17 16:17, Dr. Detlef Hühnlein wrote: >> Dear all, >> >> if the Client already knows the specific certificate, a KeySelector >> like dsig11:X509Digest is fine. >> However, we should probably also consider the case where the Client >> is only able >> to specify the class(es) of acceptable keys / certificates for the >> present use case (cf. CertificateFilter in >> https://www.oasis-open.org/committees/document.php?document_id=60049&wg_abbrev=dss-x >> ). >> Maybe both cases can be combined into one structure with a sequence >> of optional elements, >> which are to be logically ANDed (and not within a choice). >> >> BR, >> dh >> >> -----Ursprüngliche Nachricht----- >> Von: dss-x@lists.oasis-open.org [mailto:dss-x@lists.oasis-open.org] >> Im Auftrag von Andreas Kuehne >> Gesendet: Freitag, 17. Februar 2017 14:08 >> An: dss-x@lists.oasis-open.org >> Betreff: Re: [dss-x] Another streamlining approach to the core >> >> Hi Pim, >> >> thanks for pointing out the aspects of XMLDSig 1.1! >> >> Thru all the years I'm quite used to identify a certificate by issuer >> & serial. But to keep things simple I'm in favor of replacing the >> X509IssuerSerial structure with X509Digest. That doesn't add too much >> additional complexity. >> >> Other opinions? >> >> Greetings, >> >> Andreas >>> >>> On 16-02-17 20:00, Andreas Kuehne wrote: >>>> Hi all, >>>> >>>> X509IssuerSerial: well established and dtmo in use >>>> widely. >>>> >>>> So maybe we can get away with something likes this: >>>> >>>> <xs:complexType name="StreamlinedKeyInfoType"> >>>> <xs:choice> >>>> <xs:element name="X509IssuerSerial" > >>>> <complexType name="X509IssuerSerialType" >>>> mixed="false"> >>>> <sequence> >>>> <element name="X509IssuerName" >>>> type="string"/> >>>> <element name="X509SerialNumber" >>>> type="integer"/> >>>> </sequence> >>>> </complexType> >>>> </xs:element> >>> It could be time to align with XML Signature 1.1, >>> https://www.w3.org/TR/xmldsig-core1/ which adds >>> >>> /The////|dsig11:X509Digest|////element contains a base64-encoded >>> digest of a certificate. The digest algorithm URI is identified with a >>> required////|Algorithm|////attribute. The input to the >>> digest/////must/////be the raw octets that would be base64-encoded >>> were the same certificate to appear in the X509Certificate element./ >>> >>> That specification also remind us of the following (which I'm sure >>> we've all encountered from time to time): >>> >>> / The////|X509IssuerSerial|///element has been deprecated in favor of >>> the newly-introduced/////|dsig11:X509Digest|///element. The XML Schema >>> type of the serial number was defined to be an integer, and XML Schema >>> validators may not support integer types with decimal data exceeding >>> 18 decimal digits [//XMLSCHEMA-2 >>> <https://www.w3.org/TR/xmldsig-core1/#bib-XMLSCHEMA-2>/]. /This has >>> proven insufficient, because many Certificate Authorities issue >>> certificates with large, random serial numbers that exceed this limit. >>> As a result, deployments that do make use of this element should take >>> care if schema validation is involved. New >>> deployments//////should////avoid use of the element./// / >>>> Greetings, >>>> >>>> >>>> Andreas >>>> >>>> >>> Kind Regards, >>> >>> Pim >>> >>> >> >> -- >> Andreas Kühne >> phone: +49 177 293 24 97 >> mailto: kuehne@trustable.de >> >> Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 >> Hannover Amtsgericht Hannover HRB 212612 >> >> Director Andreas Kühne >> >> Company UK Company No: 5218868 Registered in England and Wales >> >> >> >> --------------------------------------------------------------------- >> 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_workgroups.php >> >> >> >> --------------------------------------------------------------------- >> 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_workgroups.php >> > > > --------------------------------------------------------------------- > 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_workgroups.php > -- Andreas Kühne phone: +49 177 293 24 97 mailto: kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612 Director Andreas Kühne Company UK Company No: 5218868 Registered in England and Wales
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]