Re: [security-services] comments re sstc-saml-holder-of-key-browser-sso-draft-07

[Nate Klingenstein <ndk@internet2.edu>]

Tom,

As always, super valuable, and if I don't say anything I've  
acquiesced.  I won't make it onto Tuesday's call due to a consulting  
engagement, but at least the spec's revved.  Between that and my  
delays getting this forward thus far, I don't think we can push it  
towards CD just yet, so this gives Tom and others one more shot at it.

> - This profile would be easier to read and more focused if all the
> (out of scope) extensions and recommendations were discussed
> exclusively in section 4.  Examples include lines 242--244, lines
> 250--253 in section 2.2 and ...

I've moved these.  If you have any others that you've noticed, please  
let me know.  It's hard for the original author to see.

> - As it stands, this profile permits an arbitrary combination of HoK
> and non-HoK assertions in a given response.  Is this advisable?  It
> leads to a more difficult implementation, does it not?

I don't think it makes the implementation more difficult,  
necessarily.  It could make the deployment more difficult, but that's  
deployers' prerogative.  I don't think this is a trap anyone's likely  
to fall into -- or that those who might fall into it would be  
substantively more likely to avoid it with explicit MUST NOT warnings.

> - In a previous set of comments, I remarked about the illogically-name
> hok:Protocol attribute.  Please address this issue (by changing the
> attribute name or recording your reasons why not).  If it helps, Scott
> gives some reasonable examples in this message:

I had some rationale in my last response, but as I said, I didn't  
care much either way as long as it was clear and different from the  
original binding attribute.  It's now hok:ProtocolBinding, for the  
record.

> - Did you consider including language such as that in the following  
> message?
>
> http://lists.oasis-open.org/archives/security-services/200809/ 
> msg00009.html

I've added as much as I can without defining the binding of  
<ds:KeyInfo> to SubjectConfirmations in an AuthnRequest, and left the  
language such that when this is done, it should compose easily with  
this spec.

> - This profile needs a version history.

Isn't this handled better already by the OASIS document repository?   
I've added a reference to it.

> - [line 271, 314] Wouldn't IssuerAltName be more appropriate than
> SubjectAltName in this context?

Heck, I don't know.  The entityID of the IdP is not really either.   
Neither of these is a field where you arbitrarily can refer to  
another, possibly independent authority for more data about the  
user.  That authority could be anyone.  I just figured IssuerAltName  
is much more likely to be jealously guarded by CA's than  
SubjectAltName.  I'm most comfortable axing this vague suggestion  
entirely, which is what I've done.  Let deployments do as they will.

> - [lines 394--395] This sentence seems to say that if a <saml:Subject>
> element is included in the request, the <samlp:AuthnRequest> element
> MUST be signed.  Is this the intent?

Yes.  I can't think of a meaningful use case for a non-trusted  
<saml:Subject> in an <samlp:AuthnRequest> under this profile.

> - [lines 407--408]  Are you referring to signing?  I suppose
> transport-level security could be used in the case of artifact
> resolution, but in any event this requirement is not clear.  The use
> of "and/or" in this sentence is not logically sound.

Good catch.  I've chosen "and".

> - [lines 413--414] The phrase "if the user agent cannot satisfy the
> <saml:SubjectConfirmation> present in the <samlp:AuthnRequest>"
> doesn't make sense.  I thought that the <saml:SubjectConfirmation>
> element in the request indicated the SP's desire to obtain an
> assertion containing such a <saml:SubjectConfirmation> element.

There can still be a failure to satisfy it, e.g. if other  
confirmation methods were included or the format requested were not  
supported by the IdP.

> - [lines 445--446] What is a "uniquely identifying <saml:NameID>"?

A uniquely identifying <saml:NameID>, e.g. one that refers to a  
specific principal at the IdP.  From my perspective, I don't think I  
can pick any clearer words.

> - [lines 462--464] This requirement is apparently contradictory.

I don't think so.  I just don't want any further requirements,  
inclusive or exclusive, on the certificate itself from this profile's  
point of view.  It's just a vector for keying information.   
Deployments are still free to use them for anything else they want.   
I tried refining the language to make this more clear.

> - [lines 470--473] The first sentence normatively specifies three
> security properties while the second sentence only mentions two.
> Moreover, the second sentence has no normative language.  Perhaps this
> is an oversight?

I've tightened the second sentence to a SHOULD, avoiding a MUST in  
case someone wants to do something weird.  The third sentence has  
been merged with the prior paragraph, and I think it covers  
confidentiality.

> - [lines 478--479] This requirement is different than ordinary Web
> Browser SSO (see errata).  Is this intentional?

Nope, oversight.

> - [lines 516--523]  Are these two paragraphs redundant?  Isn't this
> simply reiterating what is already written in the metadata spec?

This was added in response to your comments on 2 September.  The  
language in the metadata spec is pretty tight, now that I've reread  
it, so I'm comfortable pulling this completely.

http://lists.oasis-open.org/archives/security-services/200809/ 
msg00001.html

> - [lines 551--552] The fact that "the public key is a de facto
> persistent ID" could be viewed as a benefit in some circumstances.

Sure.  I won't mention this, but it could.

> - [line 297] s/spoofing/initiating/
>
> - [line 300] s/spoofed/initiated/

Not proper spec language, huh?  Can I use "forgery"? :D

> - [line 507, 515] s/http/https/

Oops.

> - [line 560] s/validation of key possession/holder-of-key subject  
> confirmation/

This list keeps growing semi-exponentially.  I hope this is the peak  
of the nit bubble, because while these are great changes, I can't  
imagine you'll find even more next time.  I know that sounds like a  
dare, but it's really not. :D

I think you've done more for this spec than I have,
Nate.