Thanks for the rapid feedback Judy! It would indeed have to be two sets - one for the issuer and one for the subject - as those are entirely independent values. They should follow the standard naming schemes for the shortened form - I just listed out a quick example set (and got parts of it wrong as you note) - so that we can discuss short form or long form names. It wasn't indented to be complete - just to form a sufficient basis for a TC view point on whether or not we want to handle this use case. Personally I'd like to use Certificate as the prefix rather than X.509 as the prefix - but I went with X.509 as the prefix to align with the existing attributes. I didn't use X.520 because that isn't the common usage even though X.520 does include all the definitions (so we could use X.520 on everything). That would be a little strange so perhaps Certificate rather than X.509 is a path to use? Specially on the questions: - email is the following pkcs-9 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } id-emailAddress AttributeType ::= { pkcs-9 1 } EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length)) EmailAddress - i.e. pkcs-9 1 - corrected SoP to ST ... - corrected SN to SerialNumber which is indeed the serial number in the DN and not the separate certificate serial number I've uploaded a version addressing those items - changes in red + italics to make it easier to see the changes. In terms of having sets of attributes and choosing between sets in a Locate (for Subject and Issuer) - that is a good topic to discuss. Tim. On 18/12/2015 12:59 AM, Furlong, Judith wrote: > > Tim, > > If I’m reading your proposal correctly it would add two sets of new > attributes for the DN components - one which would have the Subject > prefix and the second with Issuer prefix. That seems very duplicative. > Is there an way in which we could add new attributes for the > individual DN components (aka one set) and then handle that you want > the CN of the Subject or CN of the Issuer when you perform the Locate? > > On slide 4 you list a set of attributes – Is this the full list of DN > components you are suggesting we add to KMIP or just representative > examples? > > If it was intended to be a full list then I would suggest we look at > the required and recommended lists from RFC5280 – On the required > front you are missing DN Qualifier. From the recommended list you > should add Domain Component (RFC4519) and Title at a minimum. > > Also some questions/corrections to slide 4 > > ·Is Email supposed to be emailAddress (RFC2985) or rfc822Name (RFC822)? > > ·The abbreviation used for State or Province is ‘ST’ and not ‘SoP’ > > ·The Serial Number attribute is not abbreviated – The SN abbreviation > maps to Surname (X.520) > > ·I also assume that what you have labeled X.509 Serial Number was in > fact the Serial Number that is a DN component and not the serial > number of the certificate. If this is true then you should drop the > X.509 prefix because that value is defined in X.520 > > Judy > > Judith Furlong ConsultantProduct Manager Product Security and > Trusted Engineering **office: +1-774-803-3384 email: >
Judith.Furlong@emc.com < mailto:
Furlong_Judith@emc.com > > > *From:*
kmip@lists.oasis-open.org [ mailto:
kmip@lists.oasis-open.org ] > *On Behalf Of *Tim Hudson > *Sent:* Thursday, December 17, 2015 7:40 AM > *To:*
kmip@lists.oasis-open.org > *Subject:* [kmip] Groups - CertificateAttributes.pdf uploaded > > /Submitter's message/ > Currently there is no way to look up a certificate by a subject or > issue DN component. This proposal is to add attributes for each of the > main components in a DN. > -- Tim Hudson > > *Document Name*: CertificateAttributes.pdf > <
https://www.oasis-open.org/apps/org/workgroup/kmip/document.php?document_id=57150 > > > ------------------------------------------------------------------------ > > *Description* > Proposal to add certificate DN fields. > Download Latest Revision > <
https://www.oasis-open.org/apps/org/workgroup/kmip/download.php/57150/latest/CertificateAttributes.pdf > > Public Download Link > <
https://www.oasis-open.org/committees/document.php?document_id=57150&wg_abbrev=kmip > > > ------------------------------------------------------------------------ > > *Submitter*: Tim Hudson > *Group*: OASIS Key Management Interoperability Protocol (KMIP) TC > *Folder*: Proposals > *Date submitted*: 2015-12-17 04:40:12 >