Re: [OAUTH-WG] cert spoofing in mtls & short-lived certs

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 <leifj@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.*