The expectation/assumption is that the SubjectDN would be a stable identifier through re-issuance of certificates, regardless of whether they be short or long term. We've had basically this as a product feature for years and use of the SubjectDN as the identifier hasn't been an issue. And it's not been raised, that I'm aware of anyway, as a concern in the banking use-cases where there will be some central entity issuing these certificates to the participants. Not sure if that exactly addresses your question but that's how things got the way they are in the document.
If there's some better or additional text you'd like to see for the security considerations, please do suggest it. On Tue, Nov 14, 2017 at 4:44 PM, Leif Johansson <le...@sunet.se> wrote: > > So I reviewed the security considerations text which basically sais > that the server can avoid being spoofed by managing its set of trust > anchors. The text is better than nothing. > > However this lead me to ask another question about the use of > SubjectDN as an identifier for the subject in client metadata: don't > we expect certificates to be issued as short-term credentials from > an STS-like thing? > > If so the SubjectDN is probably going to change every time the STS > gets called (say by including a serial number) and such a SubjectDN > probably isn't the best thing to put in client metadata. > > Would it make sense to make it possible to identify subjects based > on (say) SubjectAltName as an alternative for this case? > > I don't want to hold up the process on this but I'm curious if this > has been raised or just overlooked...? > > Cheers Leif > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.*
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
