[ogsa-wg] OGSA EAP Security profiles: Final call for comments

[Duane Merrill]

Thanks for the comments, Sven!
> C0302 Is there anyway to strengthen this from SHOULD towards MUST? I 
> guess that the SHOULD covers situations without a  PKI infrastructure 
> and other ways of trusting the source of EPRs, but allowing for this 
> edge case does reduce the security/trustworthiness that is provided by 
> strict conformance to the profile.
A very valid comment.  As you've identified, the trade-off is "loss of 
applicability to certain situations" versus "less rigorous 
trustworthiness given strict conformance".  The general consensus on 
this issue during our review telecon this morning was that that we would 
wait and see how others weigh in on this issue during public comment.  
Sven, would you mind re-raising the question of mandatory-signing during 
the upcoming public comment?

> Secure Communication:
>
> I have concerns about supplying the certificate in the document. You 
> rightly make disclaimers warning that the source and transmission path 
> needs to be trusted, but in actual use I wonder if this chain of trust 
> will be maintained with proper diligence by the creators of the 
> consuming software? I can see that it is convenient and, when properly 
> implemented, will be very useful, but it does have the potential of 
> causing security problems in poor implementations.
While the inclusion of generic key material (e.g., a secret key) in an 
EPR document may be vulnerable to untrusted source and transmission 
paths, we profile the inclusion of X.509 certs (where the public key 
that has been signed into a digital certificate), which provide their 
own trust-assurance via the certificate's Certificate Authority.  That 
public key can then be used at the message or transport level to both 
provide message protection and to authenticate the other party, and is 
as trustworthy as the certificate's CA.  Trustworthiness of arbitrary 
key material can be assured via digital signature of the EPR

> In various places throughout the document you say that a server 
> certificate is provided for "hostname verification" (e.g. line 454). I 
> think that this is restrictive as the certificate authenticates the 
> server and not just the name of the remote host that gives you access 
> to the server. I think that these statements could be rephrased.
>
Yes, we're going to rephrase the discussion to "identity verification".


-Duane