Re: Empty CRL Issuer DNs?

Sean Mullan wrote:
> MUST the CRL issuer field always contain a non-empty DN under RFC 
> 3280? On my reading, this would appear to be the case, but the RFC 
> never explicitly says so like it does for the Certificate issuer 
> field. Either way, it would be nice if this was clarified for 3280-bis.
Yes, the CRL issuer field MUST include a non-empty DN.

Section 5.1.2.3 of 3280/3280bis simply says that "[t]he issuer name 
field MUST contain an X.500 distinguished name (DN)."  It is my guess 
that this was intended to mean a non-empty DN, otherwise there would 
have been no reason to use a capitalized "MUST" since the CRL syntax 
requires that the issuer field include a DN.

There is a statement in section 4.1.2.6 (Subject) of 3280/3280bis that 
does more clearly indicate that the issuer field in a CRL must include a 
non-empty DN:

      If the subject is a CRL issuer (e.g., the key usage extension, as
      discussed in 4.2.1.3, is present and the value of cRLSign is TRUE)
      then the subject field MUST be populated with a non-empty
      distinguished name matching the contents of the issuer field
      (section 4.1.2.4) in all CRLs issued by the subject CRL issuer.

I agree that it would make sense to modify the sentence in 5.1.2.3 to 
read:  The issuer name field MUST contain a non-empty X.500 
distinguished name (DN).

Dave

Re: Empty CRL Issuer DNs?

I think it does require a non-empty DN by referring to section 4.1.2.4.

Russ

At 05:23 PM 2/28/2007, Sean Mullan wrote:

>Hello,
>
>MUST the CRL issuer field always contain a non-empty DN under RFC 
>3280? On my reading, this would appear to be the case, but the RFC 
>never explicitly says so like it does for the Certificate issuer 
>field. Either way, it would be nice if this was clarified for 3280-bis.
>
>Thanks,
>Sean
>

RE: Empty CRL Issuer DNs?

David,

I think you can safely just add this to the list of editorial nits to be added to the next update. Or for the
unlikely event there will be no update, to Authors 48.
There is no doubt that a non-empty DN is already required.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
> pkix <at> mail.imc.org] On Behalf Of David A. Cooper
> Sent: den 1 mars 2007 14:59
> To: Sean Mullan; pkix
> Subject: Re: Empty CRL Issuer DNs?
>
>
> Sean Mullan wrote:
> > MUST the CRL issuer field always contain a non-empty DN under RFC
> > 3280? On my reading, this would appear to be the case, but the RFC
> > never explicitly says so like it does for the Certificate issuer
> > field. Either way, it would be nice if this was clarified for 3280-
> bis.
> Yes, the CRL issuer field MUST include a non-empty DN.
>
> Section 5.1.2.3 of 3280/3280bis simply says that "[t]he issuer name
> field MUST contain an X.500 distinguished name (DN)."  It is my guess
> that this was intended to mean a non-empty DN, otherwise there would

RE: draft-ietf-pkix-rfc3280bis-08.txt

I don't see this as a real problem.
The fix in 08 is reasonable to me.

I agree with Stephen that we should ship the document unless we encounter something really bad.
If we require the document to be "perfect" before we ship it, we will never get it out the door.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
> pkix <at> mail.imc.org] On Behalf Of Stephen Farrell
> Sent: den 27 februari 2007 00:48
> To: Russ Housley
> Cc: Peter Sylvester; David A. Cooper; pkix
> Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt
>
>
>
> I'd ask whether or not this is a *real* problem. If it is,
> then yes, let's fix it. However, if not, then let's just get
> this out the door - 3280bis has been a long time in the
> oven already.
>
> IMO this isn't a real problem, unless someone says that it
> affects their code. I also have confidence that most of the
> important code bases for X.509 are represented here and are
> well able to object to changes that impact on their code.

RE: URN in subjectAltName

Catching up on this after having escaped on ski vacation last week.

I agree with Russ and Paul here in the sense that allowing URN in the PKIX profile using the URI alt name is problematic.
It is problematic in particular with respect to the rules of name constraining in section 4.2.1.10

I do however object to defining a new othername in rfc3280bis. I have respect for the task of defining a new
otherName (by personal experience), and it is not reasonable to hold 3280bis for this issue.

If there is a real need to accommodate URN within the internet X.509 profile, then we should solve that separately.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
> pkix <at> mail.imc.org] On Behalf Of Paul Hoffman
> Sent: den 15 februari 2007 22:32
> To: ietf-pkix <at> vpnc.org
> Subject: Re: URN in subjectAltName
>
>
> At 12:47 PM -0500 2/15/07, Russ Housley wrote:
> >Peter:
> >
> >RFC 3280 does not allow a URN.  It requires a URL.
>
> Unfortunately, I now agree with Russ. RFC 3280 makes it clear that
> the URI MUST have a FQDN in it. We blew it, but it's not fatal for

Re: URN in subjectAltName

Stefan Santesson wrote:
> Catching up on this after having escaped on ski vacation last week.
>
> I agree with Russ and Paul here in the sense that allowing URN in the PKIX profile using the URI alt name is problematic.
> It is problematic in particular with respect to the rules of name constraining in section 4.2.1.10
>   
IMO: If an URI does not contain a host, then permitted subtree match 
will fail,
excluded subtree match will succeed

BTW: http://localhost is not allwed but http://127.0.0.1 is allowed ?

> I do however object to defining a new othername in rfc3280bis. I have respect for the task of defining a new
otherName (by personal experience), and it is not reasonable to hold 3280bis for this issue.
>   
Agree
> If there is a real need to accommodate URN within the internet X.509 profile, then we should solve that separately.
>   
yes.
>
>
>
>
>   

end of WG last call

Folks,

I saw no objections on the list to the revised lightweight OCSP 
document, draft-ietf-pkix-lightweight-ocsp-profile-08.txt during the 
last call period, so it will be forwared to the IESG.

Steve

straw poll on certs in CRLs

Folks,

In the last few weeks I have seen a number of messages supporting the 
notion of a CRL extension that would enable a CA to include a CA cert 
(or certs) in a CRL.  Earlier we had some traffic on this topic, but 
is was all negative. So, it seem like its time for a straw poll, so 
we can gauge WG consensus. Since Stefan is a proponent of this 
notion, I will conduct the poll.

Plesse send a message to the list (indicating YES or NO) on the 
following question:

Should PKIX develop a standard for a non-critical CRL extension that 
can hold one or more certs for use in validating the CRL in question?

The poll begins today, and will close on March 16. I will, announce 
the results during the PKIX session at the IETF meeting in Prague.

Steve

RE: straw poll on certs in CRLs

RE: straw poll on certs in CRLs