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

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

Thanks for the comments, Sven! 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? 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