Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt

From: David Chadwick <[email-masked]>
Date: Wed, 05 Jul 2006 10:51:24 +0100

Hi Dave

at the PKIX meeting next week I will be giving a short presentation to 
request that the AIA extension be generalised to apply to the issuer of 
any type of certificate (not just PKCs) so that it can point to 
information about the AA of an AC for example. Do you have a problem 
with this?

regards

David

David A. Cooper wrote:
> 
> All,
> 
> On Friday, I submitted draft 4 of 3280bis for posting.  A diff file 
> highlighting the changes between drafts 3 and 4 is available at 
> http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-03todraft3280bis-04_diff.html. 
> 
> 
> Draft 4 includes the following changes:
> 
> 1. References to RFCs were updated as follows:
>           RFC 2247 replaced with RFC 4519
>           RFC 2253  replaced with RFC 4514
>           RFC 2252 replaced with RFC 4512
>           RFC 2255 replaced with RFC 4516
>           RFC 2510 replaced with RFC 4210
>           RFC 2587 replaced with RFC 4523
>           draft-ietf-ldapbis-strprep-07.txt replaced with RFC  4518
> 
> 2. All references to RFC 3279 now mention RFC 4055 and RFC 4491 as well. 
> (All three RFCs are listed as informative references.)
> 
> 3. Section 4.2.1.6 (subjectAltName):  Reference to section 7.5 clarified 
> to note that the section addresses email addresses that contain 
> internationalized domain names rather than internationalized email 
> addresses.
> 
> 4. Section 4.2.1.7 (issuerAltName): Text added to clarify that the 
> issuerAltName extension is not processed during certification path 
> validation (i.e., it is not used in name chaining and name constraints 
> are not enforced).
> 
> 5. Section 4.2.1.10 (nameConstraints):  Clarified that for DNS names, 
> "host.example.com" is a match for the constraint "host.example.com".  
> Also clarified that constraints of on the directoryName name form are 
> not applied to the subject field if the subject contains an empty DN.
> 
> 6. Section 7 (Processing Rules for Internationalized Names):  made 
> changes based on comments from Kurt Zeilenga.
> 
> 7. Numerous minor typographic and syntactic errors were corrected.
> 
> Dave
> 
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 05 Jul 2006 09:51:59 -0400

David Chadwick wrote:

> request that the AIA extension be generalised to apply to the issuer 
> of any type of certificate (not just PKCs) so that it can point to 

David,

I was just looking at RFC 3281 (An Internet Attribute Certificate 
Profile for Authorization) and found the following text:

      4.3.3   Authority Key Identifier

         The authorityKeyIdentifier extension, as profiled in 
[PKIXPROF], MAY
         be used to assist the AC verifier in checking the signature of the
         AC.  The [PKIXPROF] description should be read as if "CA" meant "AC
         issuer."  As with PKCs, this extension SHOULD be included in ACs.

         Note: An AC, where the issuer field used the baseCertificateID
         CHOICE, would not need an authorityKeyIdentifier extension, as 
it is
         explicitly linked to the key in the referred certificate.  However,
         as this profile states (in section 4.2.3), ACs MUST use the v2Form
         with issuerName CHOICE, this duplication does not arise.

            name           id-ce-authorityKeyIdentifier
            OID            { id-ce 35 }
            syntax         AuthorityKeyIdentifier
            criticality    MUST be FALSE

Does this address your requirement?  I don't think this should be in 
3280bis since 3280bis only addresses public key certificates.

Dave

---

From: David Chadwick <[email-masked]>
Date: Fri, 07 Jul 2006 19:36:56 +0100

Hi Dave

When we have an AC that is signed by an AA who is not an SOA, and DNs 
are used to refer to the holders and issuers, then we have (at least) 
two certificate chains that need to be followed

the first is the PMI chain from the holder to the AA to [the next AA to] 
the SOA
the second is the PKI chain from the PKC of the issuer to [the PKC of 
the CA] to the PKC of the root CA (trust anchor)

We are proposing that you edit 3280bis to allow the AIA to be used 
inside ACs to enable the first chain above to be tracked to the SOA. 
(this is exactly analogous to its use in PKIs to find a root CA).

The authority key identifier can be used inside the AC to point to the 
first PKC for the second chain above.

The reason that 3281 has not described the first chain above is that it 
does not support delegation of authority, and all ACs must be issued by 
the SOA.

regards

David

David A. Cooper wrote:
>         The authorityKeyIdentifier extension, as profiled in [PKIXPROF], 
> MAY

--

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Jul 2006 20:11:21 +0100

Hi Dave,

> does not support delegation of authority, and all ACs must be issued by 

That was not accidental.

If it such delegation were really required, surely the proper
thing to do would be for you (or someone) to volunteer to write
an AC profile supporting such delegation.

Of course, that'd take quite a while to get done and may or may
not fit with the current PKIX charter, but stuffing one such change
into 3280bis sounds to me like a bad idea (as, IMO, is the X.509
model for AC delegation, but that's a different story:-)

Stephen.

---

From: David Chadwick <[email-masked]>
Date: Fri, 07 Jul 2006 20:47:41 +0100

Stephen Farrell wrote:
> 
> Hi Dave,
> 
> David Chadwick wrote:
> 
>> The reason that 3281 has not described the first chain above is that 
>> it does not support delegation of authority, and all ACs must be 
>> issued by the SOA.
> 
> That was not accidental.
> 

The whole infrastructure for Delegation of Authority and Recognition of 
Authority is being addressed in the 2009 edition of X.509. New 
extensions are being defined. But one of them, the AAIA extension is an 
identical copy of the AIA extension, the only difference being that CA 
is replaced by AA etc. So it seemed sensible to ask the editor of 
3280bis to make minor edits to AIA to cater for PMIs as well as PKIs 
instead of creating a whole new extension with identical purposes.

The other point to note is that the grid world has already started to 
use AIA for exactly the purpose of referring to the AA that issued an 
AC, in the same way that a PKC uses it to refer to a CA. This is quite a 
large established user base, and it would be awkward for them to have to 
change to a new AAIA extension

> not fit with the current PKIX charter,

I would not propose to write a whole ID for DoA/RoA within PKIX as it 
will take years to do. But we are already doing this within ISO anyway, 
so son of PKIX can do a profile in the future if it wishes to.

  but stuffing one such change
> model for AC delegation, but that's a different story:-)

Well at least it is a delegation model that works and is deployed. 
Unlike XACML and SAML for example that is incapable of delegation :-)

regards

David

--

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Jul 2006 16:02:09 -0400

At 7:36 PM +0100 7/7/06, David Chadwick wrote:
>Hi Dave
>
>When we have an AC that is signed by an AA who is not an SOA, and 
>DNs are used to refer to the holders and issuers, then we have (at 
>least) two certificate chains that need to be followed
>
>the first is the PMI chain from the holder to the AA to [the next AA 
>to] the SOA
>the second is the PKI chain from the PKC of the issuer to [the PKC 
>of the CA] to the PKC of the root CA (trust anchor)
>
>The authority key identifier can be used inside the AC to point to 
>the first PKC for the second chain above.
>

David,

PKIX deprecates chaining of ACs and there has been no WG consensus to 
change this position. Thus I am concerned by the text above that 
seems to conflict with this, by virtue of how you explain the planned 
use of AIA in ACs.

Did I misunderstand?

Steve

---

From: David Chadwick <[email-masked]>
Date: Tue, 11 Jul 2006 15:01:30 +0100

Hi Steve

You did misunderstand. There is no intention to make PKIX change its 
decision.

PKIX has a profile of X.509 for PKIs and PMIs. X.509 supports PMI and 
PKI chains. The PKIX profile for PKIs supports chaining of CA certs. The 
profile of PMIs does not support chaining of AA certs. Thats your choice.

PKIX has defined an AIA extension that points to a superior authority in 
a chain of certs. This extension is now worded in 3280 to be a general 
certificate extension, rather than a purely PKI extension, so it applies 
to ACs, PKCs (and XYZ certs when/if they are defined).

The PKI profile 3280 says how to use AIA in PKI chains. The ITU-T (2009) 
X.509 standard will say how to use AIA in PMI chains.
PKIX can at a future date decide to profile this or not. Its your 
choice, and ISO/ITU_T is not requiring you to do it or not do it.

All ITU-T wants you to do is ensure that the definition of AIA is 
unambiguously worded so that it is clear to everyone that it is either a 
general purpose extension that points to an issuing authority for any 
type of certificate, or if you chose not to, to make clear that it is 
only a PKI extension that can only ever point to CAs. This is your choice.

My presentation yesterday was pointing out that the wording is still a 
bit ambiguous in that it now seems clear that the AIA extension is 
general purpose but the caissuers access method should only be used to 
point to CAs. But then we were told in the meeting that actually the 
caissuers access method also points to CRL issuers and therefore could 
also point to AAs.

All I really want is clarity and lack of ambiguity. Currently we dont 
have that situation since some people are using AIA to point to ACs, 
others to point to CRL issuers and others to point to CAs, whilst others 
(including myself) dont think that the wording actually allows this.

In fact the change of wording required for caissuers, in order for it to 
be used for CRL issuers and AC issuers is minimal as my last slide 
pointed out

regards

David

Stephen Kent wrote:
> change this position. Thus I am concerned by the text above that seems 
> to conflict with this, by virtue of how you explain the planned use of 
> AIA in ACs.
> 
> Did I misunderstand?
> 
> Steve
> 

--

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 11 Jul 2006 10:39:38 -0400

David,

While I modified the text in section 4.2.2.1 so that the text does not 
imply that the extension can only be used in public key certificates, 
there was already precedent for including the extension in attribute 
certificates.  RFC 3281(section 4.3.4) profiles the use of the AIA 
extension in attribute certificates:

   4.3.4   Authority Information Access

      The authorityInformationAccess extension, as defined in [PKIXPROF],
      MAY be used to assist the AC verifier in checking the revocation
      status of the AC.  Support for the id-ad-caIssuers accessMethod is
      NOT REQUIRED by this profile since AC chains are not expected.

Section 4.3.4 then goes on the profile the use of the id-ad-ocsp access 
method in an attribute certificate.

So, RFC 3281 clearly shows that it is acceptable to include the AIA 
extension in an attribute certificate and even implies that the 
id-ad-caIssuers access method may be used.  I am starting to believe, 
however, that it would be preferable to define a new access method for 
attribute certificates. The concern that I have is that it seems that 
for attribute certificates, in a model in which delegation is allowed, 
there is a need for the AIA extension to point to two types of 
information and I believe that each should have its own access method.  
Whether delegation is used or not, there is a need to validate the 
signature on the attribute certificate, and it would be useful to have 
the AIA extension point to the public key certificate that contains the 
key needed to verify the signature on the attribute certificate.  This 
would most closely align with the way that the id-ad-caIssuers access 
method is defined for use when included in a public key certificate or a 
CRL.  Where delegation is used, the AIA extension also needs to point to 
the attribute certificate that could precede this certificate in a PMI 
chain.

While one option would be to use the id-ad-caIssuers access method to 
point to one of these pieces of information and then define a second 
access method to point to the other piece of information, I believe that 
it would be easier to simply define two new access methods rather than 
arguing over which piece of information should be pointed to by the 
id-ad-caIssuers access method.  As it is, given the way that 
id-ad-caIssuers is used in public key certificates and CRLs, I would 
think it would be more appropriate to use this access method to point to 
the public key certificate needed to verify the signature on the 
attribute certificate, while others seem to believe that it should be 
used to point to other attribute certificates.  Given how easy it is to 
define new access methods, it seems that it would just be easier to 
define two new access methods for use in attribute certificates.

Of course, since 3280bis only addresses public key certificates, none of 
this would be included in 3280bis.

Dave

David Chadwick wrote:
> PKI chains. The PKIX profile for PKIs supports chaining of CA certs. 
> The profile of PMIs does not support chaining of AA certs. Thats your 
> choice.
>
> PKIX has defined an AIA extension that points to a superior authority 
> in a chain of certs. This extension is now worded in 3280 to be a 
> general certificate extension, rather than a purely PKI extension, so 
> it applies to ACs, PKCs (and XYZ certs when/if they are defined).
>
> The PKI profile 3280 says how to use AIA in PKI chains. The ITU-T 
> (2009) X.509 standard will say how to use AIA in PMI chains.
> unambiguously worded so that it is clear to everyone that it is either 
> a general purpose extension that points to an issuing authority for 
> any type of certificate, or if you chose not to, to make clear that it 
> is only a PKI extension that can only ever point to CAs. This is your 
> choice.
>
> others to point to CRL issuers and others to point to CAs, whilst 
> others (including myself) dont think that the wording actually allows 
> this.
>
> In fact the change of wording required for caissuers, in order for it 
> to be used for CRL issuers and AC issuers is minimal as my last slide 
> pointed out
>
> regards
>
> David
>
>
> Stephen Kent wrote:

---

From: David Chadwick <[email-masked]>
Date: Tue, 11 Jul 2006 16:18:18 +0100

Hi David

thanks for your analysis

I would like to make two points.

Firstly I am glad that you agree that AIA can be used inside ACs. So now 
we just need to have the debate over which access method(s) to use.

Secondly, you forgot to mention the use of AuthorityKeyIdentifier which 
according to 3280 is " a means of identifying the public key 
corresponding to the private key used to sign a certificate." So this 
precisely gives us the pointer we need to point to the PKC of the issuer 
of the AC in which this extension occurs. This is in line with its 
current use in PKCs. Thus we do not need the AIA to point to the PKC of 
the issuer.

The second point means that we only need to use the AIA to point to the 
AC of the issuer. And caissuers can be used for this unambiguously if we 
edit the first sentence of its description in 3280-bis. The current 
wording does in my opinion rule out its use in CRLs. So it would be 
advantageous to change the wording,regardless of the AC debate.

regards

David

--

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Jul 2006 10:49:14 -0400

At 3:01 PM +0100 7/11/06, David Chadwick wrote:
>Hi Steve
>
>You did misunderstand. There is no intention to make PKIX change its decision.
>
>PKIX has a profile of X.509 for PKIs and PMIs. X.509 supports PMI 
>and PKI chains. The PKIX profile for PKIs supports chaining of CA 
>certs. The profile of PMIs does not support chaining of AA certs. 
>Thats your choice.

I'm glad we agree on that.

>PKIX has defined an AIA extension that points to a superior 
>authority in a chain of certs. This extension is now worded in 3280 
>to be a general certificate extension, rather than a purely PKI 
>extension, so it applies to ACs, PKCs (and XYZ certs when/if they 
>are defined).

It doesn't apply to XYZ certs unless they are defined by X.509 and/or PKIX :-).

>choice, and ISO/ITU_T is not requiring you to do it or not do it.

My recollection is that ITU-T never "requires" the IETF to do 
anything re its standards, David.

>unambiguously worded so that it is clear to everyone that it is 
>either a general purpose extension that points to an issuing 
>authority for any type of certificate, or if you chose not to, to 
>make clear that it is only a PKI extension that can only ever point 
>to CAs. This is your choice.

Clarity in standards is a virtue, so removing ambiguity is in 
everyone's best interest.

>My presentation yesterday was pointing out that the wording is still 
>a bit ambiguous in that it now seems clear that the AIA extension is 
>general purpose but the caissuers access method should only be used 
>to point to CAs. But then we were told in the meeting that actually 
>the caissuers access method also points to CRL issuers and therefore 
>could also point to AAs.

CRL issuers generally are CAs, so in those instances I see no 
conflict. The question, as you note, is whether we should reword the 
access method description to explicitly accommodate AAs, or whether 
one should just define a distinct access method for AAs.

>All I really want is clarity and lack of ambiguity. Currently we 
>dont have that situation since some people are using AIA to point to 
>ACs, others to point to CRL issuers and others to point to CAs, 
>whilst others (including myself) dont think that the wording 
>actually allows this.
>
>In fact the change of wording required for caissuers, in order for 
>it to be used for CRL issuers and AC issuers is minimal as my last 
>slide pointed out

I'm open to modifying the text to accommodate AAs, if the editors 
agree and the WG does not object.

Stgeve