Paul, all

30 jun 2010 kl. 08:13 skrev Paul Hoffman <[email protected]>:

> At 12:31 AM -0400 6/30/10, Shumon Huque wrote:
>> Let's concentrate on the MUST/SHOULD applicability for the four
>> identity types discussed in this document:
>> 
>>     *  CN-ID = a Relative Distinguished Name (RDN) of type Common Name
>>        (CN)
>> 
>>     *  DNS-ID = a subjectAltName identifier of type dNSName
>> 
>>     *  SRV-ID = the SRVName form of otherName from the GeneralName
>>        structure in SubjectAltName
>> 
>>     *  URI-ID = a subjectAltName identifier of type
>>        uniformResourceName
>> 
> 
> Agree.
> 
>> I don't think any of them are a MUST. It depends upon the details
>> of the application service.
>> 
>> If a service deployer is using SRV-ID or URI-ID, then presumably
>> they want to restrict the use of the certificate to a specific
>> application at a domain name. In that case SHOULD is not appropriate
>> for DNS-ID or CN-ID. In fact, you can argue that they SHOULD NOT
>> use either of those more generic forms (unless it is for backwards
>> compatibility).
>> 
>> For folks who are using straight domain names rather than the
>> application specific forms (probably the vast majority, at least
>> initially), and we want to deprecate CN-ID and steer them towards
>> DNS-ID, then I agree that DNS-ID can be a SHOULD. I don't think
>> it can be a MUST today -- there are probably many certificate
>> issuers that can't deal with anything other than CN.
>> 
>> So, if we want to attach a SHOULD to DNS-ID, it should be a
>> conditional one (the condition being that application specific
>> name forms like SRV and URI aren't being used).
> 
> I agree that we have to look at the details of the service. To me, there are 
> two types of names:
> - direct (CN-ID, DNS-ID, and URI-ID)
> - indirect (SRV-ID)
> If they are all SHOULD, and we don't say when one should not mix and match, 
> we haven't helped interoperability. I think instead, we need something like 
> "MUST have either one or more of (CN-ID, DNS-ID, and URI-ID), or SRV-ID". 
> This would be followed by "if the cert has an SRV-ID, it SHOULD NOT have any 
> of (CN-ID, DNS-ID, and URI-ID) because the meaning of combination of what is 
> received from the SRV lookup and the given DNS names is undefined."
> 
> Does that sound reasonable?

I think that both "direct" and "indirect" SHOULD be allowed at the same time.

The reason is that if you have a client that supports SRV lookups, in for 
example jabber, then you want to have the SRV name in there so the client can 
match the server cert with what the user typed.

Of course there are jabber clients out there that don't support SRV lookup and 
want to to the normal direct mappings rules.

Since the server doesn't really know what client they talk to it need to hand 
out a cert that matches both rules -> must hAve both for interop reasons.

So the direct names are not used for intermediate values, they are only used 
with names what comes/is derived user input.

Love

Skickat från min iPhone
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid

Reply via email to